NEWS-WORTHY:
The most expensive Cyber attack EVER !!! (wired)
Not-Petya is estimated to have cost 40 BILLION US Dollars.
City of Atlanta 17 million Ransom Event
More on the costs of the City of Atlanta Ransomware attack, cost 17 MILLION US Dollars
APT32 proves what we say about logging - Monitor Scheduled Tasks
Why Malware Management, some might say Threat Intel is so important to consume and identify artifacts. Hunt for Scheduled Tasks in your environment
MALWARE OF THE MONTH
Sadly, none of interest this month ;-(
SITE-WORTHY
1. BDIR - Mitre ATT&CK
Guests - Jim Schwar
Harlan Carvey's Blog
TOOL-WORTHY
BDIR - WinLogBeat and FileBeat
Sample WinLogBeat and FileBeat .ymk files to start with
Guests - Jim Schwar
Splunk - Splunk.com
TOPIC OF THE DAY
Logging - How many tricks does it take to get to the center of a Log-iPop?
This all started with a Tweet: Jim tweeted - “SIEM is incredibly hard and complex to do right. It takes hundreds/thousands of man hours to tune it well and have rich actionable data. But most people want a quick fix, so they fail miserably”
Michael's response “Mmmm disagree” and this podcast was born
INTERVIEW: Jim Schwar
So what is difficult about audit logging?
Enabling it
Set the “right” things
Collecting it
Parsing it
The SEIM/Log Management solution
Queries
Alerts
Refinement
Endpoint collection ?
Reduction of noise
AV and Logging Agent
Specifically Events Codes:
4624 - Success login
4625 - Failed logon
4634 - Logged off
4647 - User initiated logoff
4648 - A logon was attempted using explicit credentials
What are you looking for ?
NOT winlogon, lsass or svchost?
Target different from the host?
4688 - Process Created
4768 - Kerberos Auth
4769 - Kerberos Service Ticket was requested
Kerberoasting detection
Fail_Code="0x0" | where Ticket_Enc_Type="0x17"
4770 - Kerberos Service Ticket was renewed
4771 - Kerberos Pre-Auth
ARTICLES:
Malware Management
How to get started using IR Analyst reports to detect and hunt for artifacts
Extra Data in Windows Event Logs
This really only pertains to older systems, but it can save a lot of space if you are a high volume shop (I know cutting out the event descriptions has saved over 100 gigs a day)
The default linux kernel settings are not sufficient to high volumes of data (i.e. log servers), and tuning needs to be done for various items. But the biggest pain points for me are:
Read/Write Memory and Packet backlog
This document is for the Splunk Streamapp, but the same settings are relevant for any syslog server.
Transparent Huge Pages
ulimits
CONNTRACK
Keeps track of connections too long, and does not have enough entries for a host with a lot of systems connecting on ephemeral ports
Splunk UF depends on Windows Event Log Service
The basic problem here is, the UF will start to corrupt logs if it is started before the Event Log service, or if the Event Log service is restarted due to patching, etc… They way to resolve the issue is to make the service dependent on the Event Log service with a tweak the the UF’s service startup with a registry key.
This issue has existed since at least 6.3 and Splunk support refuses to add the registry key by default, make this widely known, or at the very least add a flag to the installer to add the keys. So you have to either push it through GPO or some other method in an environment.
It is also good to run a daily check of logs for the string "FormatMessage error" to find out which hosts are corrupting their logs and restart the service. An “empty” app on a deployment server that is set to restart the agent can be pushed out by Splunk Admins to resolve the problem if a support team or other management options are available.
Time Consuming Issues, that need to be dealt with consistently
Are the agents installed on all of your assets?
Is the data coming in clean?
Are there any broken systems that are generating tons of error logs? (A single host can jam up logging for hundreds/thousands)
Are appliances (specifically network devices) still configured to send the appropriate details of logs?
New hosts sending data that require a syslog filter to be updated. (This can largely be minimized by sending different types of hosts to different log ports)
Time formats in different log formats.
Message data NOT needed in your log to shrink the size of the message being consumed into Log Management
Reduce the misc, message data IN YOUR LOGS WHEN CONSUMING THEM. Blow tHIS AWAY.
4624
This event is generated when a logon session is created. It is generated on the computer that was accessed.
The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).
The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.
The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
The authentication information fields provide detailed information about this specific logon request.
Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
Transited services indicate which intermediate services have participated in this logon request.
Package name indicates which sub-protocol was used among the NTLM protocols.
Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
4625
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon.
This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
4634
This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer.
4647
This event is generated when a logoff is initiated but the token reference count is not zero and the logon session cannot be destroyed. No further user-initiated activity can occur. This event can be interpreted as a logoff event.
4648
This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials. This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command.
4688
Token Elevation Type indicates the type of token that was assigned to the new process in accordance with User Account Control policy.
Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account.
Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group.
Type 3 is a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.
4768
Certificate information is only provided if a certificate was used for pre-authentication.
Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120. EditMore Resources
4769
This event is generated every time access is requested to a resource such as a computer or a Windows service. The service name indicates the resource to which access was requested.
This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event. The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket.
Ticket options, encryption types, and failure codes are defined in RFC 4120.
4770
Ticket options and encryption types are defined in RFC 4120.
4771
Certificate information is only provided if a certificate was used for pre-authentication.
Pre-authentication types, ticket options and failure codes are defined in RFC 4120.
If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.
-----------------------------------------------------------------------------------------------
