Host based IR Approach
The main categories of alerts come from the following sensor instrumentation:
Network sensors
Identity sensors
Host/Server sensors
Triaging alerts can be challenging, even when vendors provide guidance like, "Check if this activity is normal for your environment." During triage and incident response, it's essential to identify all key assumptions about an alert, understand why those assumptions were made, and evaluate their confidence levels.
As analysts gather more data and investigate signals, some findings may decrease the likelihood of an incident, while others may increase it. It’s crucial to critically assess each assumption or hypothesis, ensuring they remain valid in the current context.
Below are high-level steps for analysis, highlighting additional data to examine and specific indicators of suspicious activity that may increase the likelihood of an alert or incident being a true positive.
Network sensor alert analysis
Determine if the alert came from a network sensor or a host-based sensor?
If the alert came from a network-based sensor pivot to the host:
Find the process that is making the suspicious network connection.
Find the process command line argument for the suspicious network connection
Proceed to the host-based investigation process to investigate the binary/file that is the source of that suspicious network connection.
Identity sensor alert analysis
Determine what systems the identity logged onto and proceed to Host/Server alert analysis.
If the compromised identity did not logon to any systems proceed to identity compromise response
Host/Server sensor alert analysis
For compromised systems the following are activities that the threat actor will likely engage in. Different threat actors may have different tradecraft for the sequence that they perform these activities. Indications of certain of the below activities, or combinations, could immediately raise likelihood that the incident is a true positive.
Search for signs of defense evasion
Search for signs of privilege escalation
Search for signs of discovery
Search for signs of Command & Control
Search for signs of lateral movement
Search for signs of persistence
Search for signs of exfiltration
Host-based incident response focuses on analyzing the processes involved in suspicious activity to identify unusual or anomalous indicators. Beyond identifying distinct behaviors, the core of effective host analysis lies in scrutinizing the processes linked to suspicious actions. Each process has user space task with a specific virtual memory layout, a Process ID (Pid), an initial binary on disk, an ACL Token, environment variables etc. This section will begin with that approach.
Determining if a process is bad
Attackers frequently exploit services and well-known processes to remain undetected, leveraging techniques like masquerading, registry manipulation, and misdirection via non-standard paths. Proactive monitoring of service creation events, process behavior, and critical system executables is essential to detect and mitigate these threats effectively.
Key Steps for Evaluating Processes:
Identify Lookalike Processes
Monitor Unique Processes
Verify Parent Process and File Path
Validate Process Command-Line Parameters
Analyze Parent-Child Process Relationships
Check Process Creator
Identify Lookalike Processes
Watch for processes with names resembling legitimate applications or Windows processes (e.g., misspellings or slight variations). The most common lookalike doppelganger is variations of svchost.exe like svcchost.exe, or svhost.exe.
Monitor Unique Processes
Pay close attention to processes that are typically single-instance or exclusive. Several system processes that should only have one instance:
lsass.exe
smss.exe
services.exe
wininit.exe
system
searchindexer.exe
SearchProtocolFilter.exe
audiodg.exe
spoolsv.exe
Verify Parent Process and File Path
Confirm that the process was spawned by the correct parent process and originated from an expected file path.
Most system processes run from %systemroot%\system32
Exceptions:
Windows explorer %systemroot%
Other
Examples of anomalous paths include:
C:\Temp\
C:\ProgramData\
C:\Windows\
C:\Windows\Temp\
Place high-priority alerts on services with drivers located in these directories, as they can indicate malicious activity, even if the driver is legitimately signed.
Validate Process Command-Line Parameters
Ensure the process's command-line arguments align with standard or expected behaviors.
Some system processes don't have command line parameters, but others should.
All svchost processes should have a -k argument (tells services.exe which service group and service dlls should run under the svchost process.
Examples of common malicious process doppelgangers:
lsass.exe:
Handles authentication via Security Service Providers (SSPs) and should not spawn child processes.
Check for misspellings such as lass.exe or lsasss.exe, which often signal threats.
csrss.exe:
This essential subsystem manages console processes and threads.
Watch for misspellings like cssrss.exe, crss.exe, or csrsss.exe, as these indicate potential malware.
svchost.exe:
This shared-service process loads services from DLL files. It is managed by services.exe, the sole process responsible for handling system services.
Legitimate instances of svchost.exe will include the -k argument in their command line.
Malicious actors may disguise malware as svchost.exe, altering the description to “Host Process for Windows Services.”
Key indicators of malicious use:
Absence of -k in the command line.
Presence in non-standard directories.
Parent process is not services.exe.
Analyze Parent-Child Process Relationships
Look for anomalies in parent-child process chains that deviate from normal process creation.
All svchost.exe processes should be a child of services.exe.
User processes are usually a child of explorer.exe
Some svchost processes spawn office processes (outlook preview)
Watch for parent and child process of cmd.exe
cmd.exe parent should always be exploter.exe
Check Process Creator
Identify the user or service account responsible for creating the process to detect unauthorized activity.
High-Priority alerts for process admin activity:
Monitor for administrator accounts creating services that execute as System. This is a common privilege escalation tactic used by threat actors.
High-priority alert scenarios include services that:
Execute a malicious binary directly.
Write to a named pipe controlled by an attacker, enabling impersonation token theft.
Execute a DLL using rundll32.exe.
Processes making network connections that normally shouldn't
Office applications spawning scripts
trusted processes that typically do not interact with GUI loading desktop/user DLLs
Other indicators of maliciousness
Search for signs of defense evasion
Clearing logs:
wevutil cl security
wevutil cl system
wevutil cl applicationEDR enumeration and exclusions
Search for signs of privilege escalation
Search for signs of discovery
General discovery commands
Internet Connectivity
Admin shares
AD Enumeration
Web enumeration (nmap, NIKTO)
General discovery commands
Examples:
certutil
net share
taskkill
route print
dir
netstat
tasklist
set
ipconfig
ntfsinfo
ping
systeminfo
Internet Connectivity
certutil -urlcache -split -f https://microsoft.com temp.htmlNote default ping does 4 pings. this connectivity check only specific 2 with the -n switch.
ping -n 2 apple.com
ping -n 2 amazon.comqueries to free Internet IP/API services. These services will provide the threat actor the public IP address of the system that they are operating on.
Admin shares
AD Enumeration
BloodHound
Web enumeration (nmap, NIKTO)
Search for signs of Command & Control
Remote Access tools
Anydesk, ActionRM, etc
C&C analysis:
LOL Tools:
powershell, curl, wget, ssh
SOCK Proxies:
Tools:
Cobalt Strike, etc
Protocols:
HTTP, HTTPS, DNS, BITS
Search for signs of lateral movement
Attackers without credentials to access remote machines often target shared file systems to propagate malware. Common tactics include:
Backdooring Commonly Opened Files: Embedding malicious scripts into frequently accessed files on shared drives.
Injecting Malicious Macros: Modifying frequently used documents to add or alter embedded scripts, exploiting users who open them.
Backdooring or Creating LNK Files: Introducing compromised or new shortcut (LNK) files in shared directories to redirect users to malicious content.
Lateral Movement methods:
Legitimate credentials
Remote Desktop (RDP)
Admin shares
PSExec
WMI
Powershell remoting
WinRM, a SOAP-based API operating over TCP/5985 or TCP/5986, was developed as a successor to DCOM for remote operations. It serves as the transport layer for tools like PowerShell Remoting.
Vulnerability exploitation of web interface
PSExec Details
PsExec Operates in 3 Stages
File Deployment via SMB:
PsExec establishes an SMB connection to the ADMIN$ share on the target device and copies the PSEXESVC binary to the Windows directory.
The Impacket PsExec.py variant differs slightly, uploading a service binary with a randomized name instead of the default PSEXESVC.
Service Creation via RPC:
PsExec connects to the target device’s RPC service (port 135) to create and start a new service, typically named PsExecSVC.
The Service Control Manager (sc) is used to initiate the uploaded binary as a Windows service.
Communication via Named Pipe:
A named pipe, \\.\pipe\PSEXESVC, is created to facilitate communication between the host and the target device, enabling input/output operations.
Commands executed remotely run under the PSEXESVC.exe process, which is spawned by the services.exe parent process.
Example of Malicious Use:
An attacker could use PsExec to execute commands like sharing all drives on the target host:
net share [C-Z]=[C-Z]:\ /grant:everyone,FULL Cleanup Post-Usage:
Once the remote task is completed, the PsExec service (PsExecSVC) is stopped, and the PSEXESVC.exe file is deleted from the ADMIN$ share.
Detecting PsExec Activity
On the Target Machine:
Network Share Access:
Windows Event ID 5145 logs access to the ADMIN$ network share, indicating potential file uploads (e.g., psexecsvc.exe).
Service Installation:
Event ID 7045 records the creation of the PsExecSVC service on the target machine.
File Presence:
The presence of psexecsvc.exe in the Windows directory is a clear indicator of PsExec usage.
On the Source Host:
License Agreement Confirmation:
A registry value is created when the PsExec license agreement is accepted, signaling its use on the source system.
Execution Artifacts:
Execution history, such as Prefetch files, can provide evidence of PsExec.exe usage.
Binary and Service Indicators:
The presence or execution of the following files/services can indicate PsExec activity:
PsExec.exe (main binary).
PsExecSVC.exe (service binary).
A service named PsExecSVC.
Named pipes created with the name PsExecSVC.
DeviceProcessEvents
| where InitiatingProcessComamndLine contains "psexe"
| distinct ProcessComamndLine Monitoring executable files being written to administrative shares. The executable file will be created by the ntoskrnl.exe process, which is the kernel process that manages SMB, and the ShareName column will be ADMIN$.
DeviceFileEvents
| where InitiatingProcessFileName == "System"
| where InitiatingProcessFolderPath endswith "ntoskrnl.exe"
| where ShareName == "ADMIN$"
| where FileName == "PSEXECSVC.exe"
| project FileName, InitiatingProcessFileName, nitiatingProcessFolderPath, ShareNameMonitoring for anomalous remote connections to RPC (Port 135)
DeviceNetworkEvents
| where RemotePort == 135
| summarize count() by InitiatingProcessFileName
| sort by count_ asc??????more over port 445???
Search for signs of persistence
Scheduled tasks
Service installs
WMI event consumers
Search for signs of exfiltration
Mega
RClone
Document findings in timelines
Excel
Timeline analysis is a critical component of incident response investigations. It involves constructing a chronological sequence of events related to a security incident, allowing responders to understand how the incident unfolded and identify key moments of compromise, escalation, and attacker activity. Here’s why timeline analysis is essential:
Understanding the Incident Scope
Timeline analysis helps investigators determine the full scope of the incident, including when the attack began, how it progressed, and which systems or data were affected.
It uncovers the attacker’s entry point and lateral movement within the network.
Identifying Attack Patterns
By analyzing timestamps, responders can identify patterns in the attacker’s behavior, such as the methods used, persistence techniques, and timing of key actions.
This information is crucial for anticipating further attacker actions and crafting effective containment strategies.
Establishing Cause-and-Effect Relationships
A timeline provides clarity on how specific events are connected, such as how an initial phishing email led to credential theft, which then enabled unauthorized access to critical systems.
Validating and Correlating Data
Timeline analysis allows responders to correlate logs, alerts, and system events across multiple sources to ensure consistency and accuracy.
It highlights discrepancies or gaps in available data that may need further investigation.
Supporting Incident Containment and Remediation
Understanding when the compromise occurred helps determine the extent of remediation needed (e.g., restoring affected systems to a pre-compromise state).
It informs decisions on isolating affected systems, revoking compromised credentials, or enhancing defenses against similar attacks.
Enhancing Communication and Reporting
A well-constructed timeline simplifies communication with stakeholders by presenting a clear narrative of the incident.
It is invaluable for post-incident reporting, root cause analysis, and documenting lessons learned.
Legal and Regulatory Compliance
Timelines are often required for incident disclosure and compliance reporting, particularly in cases involving data breaches or regulated industries.
They provide evidence for potential legal action, whether prosecuting attackers or defending against liability claims.
Improving Future Defenses
Insights gained from timeline analysis can guide enhancements to detection mechanisms, policies, and procedures to prevent similar incidents in the future.
References
Tracking lateral movement through event logs: https://www.jpcert.or.jp/english/pub/sr/20170612ac-ir_research_en.pdf
Comments