0% found this document useful (0 votes)
62 views

Soar in Soc

Uploaded by

iamwhitedevil210
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
62 views

Soar in Soc

Uploaded by

iamwhitedevil210
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 38

Part - III

SOAR in SOC: Threat


Hunting

By
Asif Khan
Sr. Cyber/Digital Forensics Expert

https://www.linkedin.com/in/asif-
khan-b5379a126/
Index

I. What is SOAR in SOC?

II. Threat Hunting with SOAR: Overview

III. SOAR Playbooks for Threat Hunting

1. Suspicious IP Playbook

2. Unusual Privilege Escalation Playbook

3. Suspicious File Activity Playbook

4. Beaconing Detection: Detailed Technical Overview

5. Lateral Movement Hunting in Threat Hunting


What is SOAR in SOC?
SOAR platforms integrate various tools and workflows used in a SOC to:
1. Automate repetitive tasks.
2. Orchestrate workflows between tools.
3. Provide in-depth reporting and dashboards.
4. Enable threat hunters to focus on high-value analysis by reducing manual efforts.
SOAR typically involves:
• Automation: Eliminating repetitive tasks like enrichment, triage, or data correlation.
• Orchestration: Interfacing with tools like SIEM, EDR, IDS/IPS, firewalls, and cloud
monitoring platforms.
• Incident Management: Streamlining the investigation and remediation process.

Threat Hunting with SOAR: Overview


Threat hunting is the proactive search for undetected threats in your environment. SOAR
enhances threat hunting in multiple ways:
1. Data Enrichment: Automates the process of gathering additional context (e.g., WHOIS
data, threat intelligence, geolocation) about suspicious indicators.
2. Custom Playbooks: Defines specific workflows for hunting and responding to threats.
3. Integration with SIEM and EDR: Collects and correlates data to identify patterns of
malicious activity.
SOAR Playbooks for Threat Hunting
Playbooks define automated processes for specific hunting scenarios. Here are some examples:

1. Suspicious IP Playbook
Purpose:
The Suspicious IP Playbook is designed to identify, analyze, and respond to malicious or
suspicious IP activity in a corporate environment. This playbook focuses on automating initial
investigation tasks while providing actionable intelligence for L2 Threat Hunters to further
explore and respond to threats.

1. Trigger Event
The playbook begins when a suspicious IP is flagged by:
• SIEM Alerts (e.g., unusual outbound traffic to a known malicious IP or high-frequency
DNS queries to an unknown domain).
• EDR Solutions detecting abnormal connections.
• Threat Intelligence Platforms (TIPs) reporting new indicators of compromise (IOCs).
Example: The SIEM generates an alert for traffic originating from an endpoint to an IP address
flagged by a TIP as a known C2 (Command and Control) server.

2. Automation Steps
The playbook automates the following tasks:
Step 1: IOC Enrichment
• Query the flagged IP address in Threat Intelligence Platforms like VirusTotal,
AlienVault OTX, or Recorded Future.
• Retrieve contextual data such as:
o Reputation score
o Geolocation information (country, ISP, etc.)
o History of malicious activities (e.g., spam, malware hosting, C2 server usage).
• Lookup the IP in internal Threat Intelligence Databases for any previous sightings in
the environment.
Technical Workflow:
Step 2: Network Contextualization
• Query the Firewall Logs and NetFlow Data:
o Identify traffic patterns involving the flagged IP.
o Determine whether the IP is receiving or sending abnormal volumes of traffic.
• Query DNS Logs for any domain resolutions linked to the IP.
• Query Proxy Logs to check for web traffic involving the IP.
Technical Workflow Example:
Run an API query to the firewall (e.g., Palo Alto or Cisco):
Step 3: Endpoint Query
• Query EDR Tools (e.g., CrowdStrike, Carbon Black) to identify endpoints
communicating with the IP:
o Collect details like process name, file path, user account, and execution time.
o Check whether any binaries were downloaded from the IP.
• Check Host-based Indicators such as:
o Newly created files.
o Registry changes.
o Persistence mechanisms like scheduled tasks or startup programs.
Technical Workflow Example:
Step 4: Threat Score Calculation
Aggregate the data collected and calculate a threat score:
• IP reputation (high-risk IP = +50).
• Frequency of connections (e.g., >100 per hour = +30).
• Processes associated with the IP (e.g., PowerShell = +20).
• Data exfiltration potential (e.g., large outbound transfers = +50).
Automated Decision-Making:
If the threat score exceeds a predefined threshold (e.g., 70):
• Proceed to the containment phase (isolation, blocklist, etc.). If the score is below the
threshold:
• Escalate the investigation to an L2 analyst.

3. L2 Hunter Manual Investigation


Once the automation completes, L2 Threat Hunters can perform the following advanced tasks:
Advanced Threat-Hunting Techniques:
• Deep Packet Inspection (DPI):
o Extract PCAP data of the communication to analyze payloads.
o Identify if the traffic contains encoded data (indicative of C2 activity or
exfiltration).
• Behavioral Analysis:
o Check for abnormal user or system behaviors on endpoints communicating with
the IP (e.g., unusual working hours, access to sensitive data).
• Correlate with Historical Data:
o Search for historical connections to the same IP or related domains across the
network.
o Determine if the IP is part of a larger campaign.
Example Scenario:
1. An endpoint communicates with a flagged IP, 185.220.101.1.
2. PCAP analysis reveals that the payload contains Base64-encoded data.
3. Decoding the payload reveals sensitive information (e.g., credentials, database exports).
4. Correlation shows that 5 other endpoints are communicating with the same IP, indicating
lateral movement.
Tools to Use:
• Wireshark for packet analysis.
• EDR tools for process and file analysis.
• SIEM queries for correlation (e.g., Splunk, QRadar).

4. Response Actions
If malicious activity is confirmed, the following actions can be automated or manually executed:
Automated Actions via SOAR:
1. Block the IP:
o Add the IP to the firewall blocklist.
o Update web proxies to block future connections.
2. Isolate the Endpoint:
o Use EDR to quarantine affected devices.
3. IOC Sharing:
o Share the IP and associated IOCs with internal threat intelligence platforms and
partner organizations.
Manual Actions for L2 Hunter:
• Conduct detailed forensics on isolated endpoints (e.g., memory dumps, log extraction).
• Identify the root cause of the compromise (e.g., phishing email, exploited vulnerability).
• Create detailed incident reports for management and regulatory compliance.
5. Metrics and Reporting
Use SOAR to track and visualize:
• Time to detect and respond to suspicious IP activity.
• Number of IPs flagged, investigated, and blocked.
• Frequency of malicious IP activity by geography or category.
Dashboard Example:
• KPIs:
o Average time to resolve (TTR) for IP alerts.
o Percentage of IP alerts escalating to confirmed incidents.
o Distribution of IP categories (malware, phishing, C2).

6. Continuous Improvement
• Feedback Loop: Regularly update playbooks based on lessons learned.
• Threat Intelligence Updates: Keep IOC databases and TIPs updated with the latest
threats.
• Training: Conduct periodic training for L2 hunters to improve manual investigation
skills.

Example Scenario Summary


1. Trigger: Outbound traffic to 185.220.101.1 flagged by the SIEM.
2. Automation: SOAR enriches the IP with threat intelligence, queries firewall logs, and
checks EDR for endpoint activities.
3. L2 Investigation: Packet analysis reveals data exfiltration via Base64-encoded payloads.
Lateral movement detected.
4. Response: Block IP, isolate endpoints, and escalate the incident for full forensics.
2.Unusual Privilege Escalation
The Unusual Privilege Escalation Playbook is designed to proactively detect and respond to
unauthorized or suspicious privilege escalation attempts in an enterprise environment. Privilege
escalation often indicates a breach where an attacker gains elevated access, enabling further
exploitation, lateral movement, or persistence. This playbook enables L2 Threat Hunters to
automate detection, streamline response, and uncover root causes of such incidents.

Key Objectives
1. Detect privilege escalation events using various data sources (SIEM, EDR, AD logs,
etc.).
2. Automate data enrichment and correlation for suspicious events.
3. Reduce the time to respond (TTR) by automating remediation steps like isolating
endpoints or disabling accounts.
4. Enable hunters to uncover patterns, such as potential lateral movement or exploitation of
vulnerabilities.

Technical Workflow for the Playbook


Below is the detailed step-by-step technical workflow, including tools, techniques, and
automation processes.

1. Trigger Event
The playbook is triggered when a suspicious privilege escalation event is detected. Triggers can
include:
• Active Directory Logs:
o Event ID 4670: Permissions on an object were changed.
o Event ID 4672: Special privileges assigned to a new logon session.
• Endpoint Detection and Response (EDR):
o Detection of tools like Mimikatz, SharpUp, or custom scripts attempting to
escalate privileges.
• SIEM Alerts:
o Correlation of anomalous user activity logs (e.g., standard user suddenly
accessing high-privilege resources).
Example Trigger:
• A user account (jdoe) is granted domain admin privileges without a corresponding
helpdesk ticket or request.

2. Data Collection and Enrichment


SOAR automatically collects and enriches data related to the event from integrated tools and data
sources.
2.1. Enrich User Context
• Query Active Directory for user details:
o Get-ADUser jdoe -Properties *
o Gather data such as Department, Role, LastLogon, and Group Memberships.
• Check for unusual behavior:
o Was this user previously in a low-privilege group?
o Was there recent suspicious logon activity (e.g., from unknown IPs)?
2.2. Enrich System Context
• Query EDR for endpoint activity:
o Fetch running processes and active network connections:

• Identify if exploit tools (e.g., winPEAS, Seatbelt) were run.

Review Windows Event Logs for privilege escalation activities:

2.3. Threat Intelligence Correlation


• Use Threat Intelligence Platforms (TIPs) to verify:
o Whether recently executed binaries have known malicious hashes (via VirusTotal
or internal databases).
o Whether suspicious IP addresses or domains associated with the endpoint have
prior malicious activity.
2.4. Analyze Logs for Behavior Patterns
SOAR queries SIEM for:
• Recent logon locations.
• Failed logon attempts preceding the escalation.
• Lateral movement indicators, such as:
o Kerberos ticket requests (Golden Ticket/Pass-the-Ticket attacks).
o SMB or WMI connections.

3. Detection and Validation


L2 Threat Hunters validate if the privilege escalation is legitimate or malicious by analyzing the
enriched data.
Indicators of Malicious Activity:
1. Escalation from non-admin to admin roles:
o A user is added to the Domain Admins group without a valid change request.
2. Abnormal access locations:
o Privilege escalation originates from an unusual geographic region or time zone.
3. Use of known exploit tools:
o Tools like Mimikatz, PowerSploit, or Empire are detected on the system.
4. Suspicious process execution:
o Processes like cmd.exe, powershell.exe, or svchost.exe spawning unexpectedly
after escalation.
Example Scenario: Pass-the-Hash Attack
• An attacker uses stolen NTLM hashes to escalate privileges.
• Event Log Analysis:
o 4624 (Logon Success) for a privileged user.
o 4672 (Special Privileges Assigned) immediately afterward.
• Detection:
o SOAR identifies lateral movement attempts from the same system, indicating
further compromise.

4. Automated Response Actions


Once the activity is confirmed as malicious, SOAR initiates automated response actions to
contain the threat:
4.1. Immediate Containment
1. Disable the compromised account:
powershell
Copy code
Disable-ADAccount -Identity jdoe
2. Isolate the affected endpoint:
o Use EDR to block all network traffic except to the SOC forensics tools.
Command:

4.2. Kill Malicious Processes


• Terminate processes like mimikatz.exe or other identified tools:
>>kill -9 <process_id>
4.3. Suspend Privileged Sessions

• End all active sessions for the compromised account:

>>logoff /id:<session_id>

5. Root Cause Analysis


L2 hunters investigate how the attacker performed privilege escalation.
Potential Root Causes:
1. Vulnerable Software:
o Example: Exploitation of unpatched software like CVE-2021-34527
(PrintNightmare).
2. Credential Dumping:
o Example: Use of tools like Mimikatz or dumped credentials from LSASS.
3. Password Reuse:
o Example: Admin accounts reusing weak or compromised passwords.
Hunting Techniques:
• Search for exploitation of specific vulnerabilities:
>>grep "CVE" /var/log/patch-management.log
• Correlate PowerShell execution logs (Script Block Logging, Event ID 4104):
>>Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational"

6. Reporting and Follow-Up


SOAR generates a detailed incident report for stakeholders. Key components include:
1. Summary of the event (who, what, when, where).
2. Root cause and attack vector (e.g., Pass-the-Hash, exploitation of CVE).
3. Actions taken (e.g., account disabled, endpoint isolated).
4. Recommendations to prevent recurrence:
o Enforce privileged access management (PAM) solutions.
o Patch vulnerabilities exploited during the incident.
o Implement two-factor authentication (2FA) for privileged accounts.

Scenario Example: SOAR in Action


1. Trigger: SIEM detects Event ID 4672 (Special privileges assigned).
2. SOAR Workflow:
o Pulls AD logs for jdoe.
o Correlates with EDR logs, finding Mimikatz.exe executed.
o Enriches IOC data, revealing the use of a malicious IP for remote access.
3. Response:
o Disables jdoe and isolates the endpoint.
o Terminates suspicious processes.
4. Outcome:
o Hunters discover the attacker exploited an unpatched system to dump credentials.

Playbook Metrics
Measure the playbook's effectiveness with:
1. Mean Time to Detect (MTTD):
o Average time between escalation and detection.
2. Mean Time to Respond (MTTR):
o Average time taken to contain the escalation.
3. False Positive Rate:
o Percentage of non-malicious escalations flagged.
3.Suspicious File Activity Playbook
The Suspicious File Activity Playbook is designed to help threat hunters investigate and
respond to suspicious file activity. This could involve unusual file access, file modifications,
encryption (indicative of ransomware), or unauthorized file downloads and uploads. Here’s a
detailed step-by-step technical guide tailored for L2 Threat Hunters in a corporate SOC
environment.

Trigger Events for Suspicious File Activity


The playbook is initiated when suspicious file activity is detected. Common triggers include:
1. SIEM Alerts:
o Unusual file access patterns (e.g., accessing sensitive data).
o Bulk file changes (e.g., encryption or deletion).
o Files modified or accessed outside normal working hours.
2. Endpoint Detection and Response (EDR):
o Alerts for file tampering, unauthorized access, or malware-infected files.
3. User and Entity Behavior Analytics (UEBA):
o Behavior deviations, such as a non-privileged user accessing sensitive files.
4. DLP (Data Loss Prevention):
o Alerts for large data transfers or unusual data exfiltration attempts.

Technical Workflow of the Playbook


1. Event Ingestion
• Source Logs:
o File system logs (Windows, Linux, or MacOS).
o SIEM (e.g., Splunk, Elastic Stack) for file access alerts.
o EDR alerts from tools like CrowdStrike, Carbon Black, or Microsoft Defender.
o DLP logs for abnormal file transfer events.
• Automation:
o Use SOAR to aggregate logs from the above sources and normalize data.
o Example: Parse Windows Event IDs 4663 (File Accessed) and 5145 (Network
Share Access).
2. Data Enrichment
Once suspicious activity is flagged, enrich the alert with additional data:
1. File Metadata Analysis:
o Gather details like file path, name, type, size, hash, and timestamp.
o Use file hash to query threat intelligence platforms (e.g., VirusTotal, Hybrid
Analysis, or Recorded Future).
o Example:
>> import requests

>>hash = "d41d8cd98f00b204e9800998ecf8427e"
response = requests.get(f"https://www.virustotal.com/api/v3/files/{hash}", headers={"x-apikey":
"YOUR_API_KEY"})
print(response.json())
2. User Context:
o Identify the user account that accessed or modified the file.
o Correlate with Active Directory (AD) logs:
▪ Look for anomalous login times or privilege escalations.
o Example: Query SIEM for Event ID 4624 (Successful Logon).
3. Process Analysis:
o Check processes interacting with the file using EDR.
o Example:
▪ Was the file accessed by a suspicious PowerShell script or cmd.exe?
o Command for live systems:
>> lsof | grep <file_name>
4. Network Correlation:
o Cross-reference with network traffic logs:
▪ Was the file uploaded to a remote server?
▪ Is there evidence of data exfiltration via FTP, HTTP, or cloud storage?

3. Threat Hunting Techniques


Once the data is enriched, the playbook uses advanced techniques for in-depth investigation:
a. Pattern Analysis
• Baseline Behavior:
o Compare the current file activity to historical patterns.
o Example: A user typically accesses 10 files a day, but suddenly accesses 500 files
within an hour.
• Hunting Tools:
o Use SOAR to run anomaly detection models:
▪ Integrate with UEBA tools to detect deviations.
b. File Content Analysis
• Automated Static Analysis:
o Use tools like YARA rules to scan for known malware signatures.
o Example YARA rule:
>>rule SuspiciousFile
{
meta:
description = "Detect suspicious files"
strings:
$a = "powershell -enc"
$b = { 6A 40 68 00 30 00 00 }
condition:
any of them
}
• Dynamic Analysis:
o Sandbox the file in an isolated environment (e.g., Cuckoo Sandbox, Any.Run) to
observe behavior.
• Hash Comparison:
o Compare the hash of the file with known malicious hashes in threat intelligence
databases.
c. Endpoint Forensics
• Windows Forensics:
o Query Prefetch files to check if the file was executed.
o Example:
>>dir /A:C %SystemRoot%\Prefetch
• Linux Forensics:
o Check ~/.bash_history or /var/log/syslog for evidence of file manipulation.
d. Network Traffic Analysis
• Investigate if the file was part of a data exfiltration attempt.
• Use network monitoring tools (e.g., Zeek, Wireshark) to analyze outbound traffic.
• Example:
>>tshark -r capture.pcap -Y "http contains <suspicious_file_name>"

4. Automated Response Actions


Based on findings, SOAR can initiate automated responses:
1. File Quarantine:
o Isolate the suspicious file from being accessed further:
▪ For Windows:
>>Add-MpPreference -ExclusionPath "C:\path\to\suspicious_file"
o For EDR tools, initiate quarantine via API or GUI.
2. User Lockdown:
o Temporarily disable the user account that accessed the file.
o Example: Use Active Directory PowerShell module:
>>Disable-ADAccount -Identity <UserName>
3. Endpoint Isolation:
o Isolate the compromised host from the network using SOAR integration with
EDR.
o Example via CrowdStrike API:
>>curl -X POST -H "Authorization: Bearer <API_KEY>" -d '{"action": "contain"}'
https://api.crowdstrike.com/devices/entities/devices-actions/v2
4. IOC Propagation:
o Update blocklists in firewalls, proxies, or endpoint tools.
o Share hashes and domains with threat intelligence feeds.

5. Incident Reporting and Documentation


• Ticketing Integration:
o Log findings into incident management systems (e.g., ServiceNow, Jira).
• Hunting Report:
o Document findings, steps taken, and final conclusions.
o Use SOAR to auto-generate reports with enriched data.

Real-World Scenarios
Scenario 1: Ransomware Alert
• Trigger: SIEM flags multiple files being encrypted in rapid succession.
• Workflow:
1. SOAR collects file metadata and matches the encryption tool with a known
ransomware strain.
2. Endpoint is isolated.
3. IOC (file hash, domain, IP) is added to blocklists.
Scenario 2: Unauthorized File Exfiltration
• Trigger: DLP alerts on sensitive files being uploaded to an unknown domain.
• Workflow:
1. SOAR pulls logs to identify the user and file details.
2. Traffic is analyzed for further exfiltration attempts.
3. Host is quarantined, and files are flagged for investigation.

Conclusion
The Suspicious File Activity Playbook is a vital tool for L2 Threat Hunters. By automating
repetitive tasks like log collection and IOC enrichment, SOAR allows hunters to focus on deeper
investigation and analysis. Using techniques like anomaly detection, file sandboxing, and
endpoint forensics, this playbook empowers hunters to identify and respond to suspicious file
activities swiftly and effectively.

4.Beaconing Detection: Detailed Technical Overview


Beaconing refers to periodic communication initiated by a compromised device to a Command
and Control (C2) server controlled by an attacker. Beaconing is commonly used by malware to:
• Maintain persistence in a compromised environment.
• Exfiltrate data in small packets.
• Receive commands from the attacker.
Detecting beaconing requires analyzing network traffic, event logs, and endpoint behaviors for
patterns indicating periodic, abnormal communication. With SOAR, the detection of beaconing
can be automated and enhanced with contextual intelligence.

Key Characteristics of Beaconing


1. Periodic Traffic Patterns:
o Malware often sends out heartbeat signals or "beacons" to its C2 server at regular
intervals.
o These intervals might be consistent or randomized to evade detection.
2. Unusual Domain/Host Communication:
o Communication with suspicious or never-before-seen domains, IPs, or URLs.
o Use of Dynamic DNS (DDNS) services or randomized subdomains.
3. Low Volume Data Transfers:
o Attackers often use small data packets to avoid triggering data loss prevention
(DLP) tools.
4. Encrypted Traffic:
o HTTPS or custom encryption protocols may hide payloads or commands.
5. Domain Generation Algorithms (DGA):
o Malware may use DGAs to generate new domains dynamically, making it harder
to block communication.

Steps to Detect Beaconing Using SOAR


1. Collection of Network Traffic Data
• Use tools like NetFlow, Zeek (formerly Bro), or SIEMs to collect and analyze network
data.
• Focus on outbound traffic logs (e.g., destination IPs, ports, protocols, and domain
names).
• Example Tools:
o NetFlow from network appliances like Cisco or Palo Alto.
o Zeek for detailed network logging.
2. Data Enrichment via Threat Intelligence
• Automate enrichment of indicators (IP addresses, domains) using Threat Intelligence
Platforms (TIPs) integrated with SOAR.
• Example enrichment sources:
o VirusTotal
o AbuseIPDB
o Recorded Future
o AlienVault OTX
• SOAR Action: When a suspicious IP or domain is flagged, query TIPs and log the
reputation score.
3. Correlation Across Systems
• Use SOAR to query logs from various tools like:
o SIEM: Check for correlated alerts related to flagged traffic.
o EDR: Investigate processes initiating outbound connections.
o IDS/IPS: Check for matching signatures or abnormal traffic patterns.
• Automated Correlation Playbook:
1. Fetch logs from the SIEM for the flagged destination.
2. Query EDR for processes responsible for network connections.
3. Use SOAR to aggregate this data and provide a unified report.
4. Analyzing Periodicity
• SOAR can be used to automate the analysis of traffic periodicity.
• Techniques:
o Use scripts or tools (like Splunk SPL queries) to calculate the time intervals
between communication events.
o Look for consistent or pseudo-random intervals.
o Compare time-stamped logs for multiple endpoints to identify coordinated
communication patterns.
• Example: Periodicity Detection Logic:
>>from datetime import datetime
import numpy as np

def analyze_periodicity(timestamps):
# Convert timestamps to datetime
intervals = [timestamps[i] - timestamps[i - 1] for i in range(1, len(timestamps))]
# Check for consistent intervals
if np.std(intervals) < threshold:
return "Beaconing Pattern Detected"
return "No Consistent Pattern"
5. Detecting Domain Generation Algorithms (DGA)
• Malware using DGAs generates domain names algorithmically, often creating hundreds
of domains daily.
• Use SOAR to:
o Analyze DNS logs for high query rates to unique domains.
o Cross-reference domains against known DGA patterns using ML-based tools like
PyDG or FluXOR.
• Example: DGA Detection Logic:
o Identify domains with:
▪ High entropy (random-looking names).
▪ Few or no WHOIS records.
▪ Short lifetimes or frequent changes in IP resolution.

Technical Example of Beaconing Detection with SOAR


Scenario: Malware is communicating with a C2 server at regular intervals.
1. Trigger:
o A SIEM alert flags an endpoint making outbound connections to an unknown IP
address.
2. SOAR Playbook Actions:
o Step 1: Enrich the IP with Threat Intelligence.
▪ Query IP reputation using VirusTotal and AlienVault OTX.
o Step 2: Analyze Traffic Periodicity.
▪ Retrieve logs of all outbound traffic from the endpoint.
▪ Analyze time intervals between connection attempts using periodicity
detection scripts.
o Step 3: Query for Associated Endpoints.
▪ Check if other endpoints are communicating with the same IP/domain.
o Step 4: Correlate Endpoint Activity.
▪ Query EDR for suspicious processes initiating the connection.
▪ Look for unusual parent-child process relationships (e.g., explorer.exe
spawning powershell.exe).
o Step 5: Notify Analysts and Take Action.
▪ If confirmed malicious, SOAR isolates the endpoint and blocks the IP at
the firewall.
3. Output:
o SOAR generates a detailed report highlighting:
▪ Periodicity of connections.
▪ Processes initiating the traffic.
▪ Related endpoints.

Advanced Techniques for Beaconing Detection


1. Machine Learning for Beaconing
• Use ML models to detect beaconing patterns in network traffic.
• Features to analyze:
o Time intervals between requests.
o Packet sizes and payload lengths.
o Destination domains/IP entropy.
• Tools like Splunk MLTK, Elastic ML, or custom Python models can help.
• Example ML Model: A clustering algorithm (e.g., K-Means) can group similar traffic
patterns to identify anomalous clusters.
2. Detecting Randomized Beacons
• Attackers often introduce jitter (random delays) to avoid detection.
• Use statistical methods like standard deviation or entropy analysis to detect jittered
periodicity.
• Example:
o Calculate the deviation in time intervals and flag sequences with consistent, albeit
noisy, patterns.
3. DNS Tunneling Analysis
• Many C2 communications use DNS queries to hide data transfer.
• Analyze DNS logs for:
o Abnormally long domain names (indicating encoded data).
o High volumes of DNS queries to a single domain.
4. TLS/SSL Certificate Analysis
• C2 servers using HTTPS may use self-signed or unusual certificates.
• Extract certificate metadata and analyze:
o Issuer name.
o Certificate validity dates.
o Reuse of certificates across multiple servers.

Real-World Example
Case Study: Detecting Beaconing in a Corporate Environment
1. A finance department endpoint starts making periodic HTTPS connections to
xy1yz.payrollcheck.net.
2. SOAR Playbook is triggered:
o Enriches xy1yz.payrollcheck.net with Threat Intelligence (classified as a low-
reputation domain).
o Retrieves PCAPs for traffic to the domain.
o Identifies periodic HTTPS requests with no user interaction.
3. Actions Taken:
o EDR isolates the endpoint.
o DNS logs reveal another endpoint querying the same domain.
o A malware sample is retrieved from the endpoint and analyzed.

Conclusion
Detecting beaconing is a complex but critical part of threat hunting. SOAR simplifies the process
by automating:
• Data collection (logs, threat intelligence).
• Periodicity analysis.
5.Lateral Movement Hunting in Threat Hunting
Lateral movement refers to the techniques attackers use after gaining access to an initial system,
allowing them to move across the network to achieve their ultimate objectives—whether that’s
data theft, privilege escalation, persistence, or sabotage.
For L2 Threat Hunters, lateral movement detection is a critical skill, and SOAR platforms
amplify their capabilities by automating and orchestrating complex detection and investigation
processes.

What is Lateral Movement?


Lateral movement typically involves:
1. Credential Dumping: Using tools like Mimikatz to harvest credentials from a
compromised system.
2. Pass-the-Hash/Pass-the-Ticket: Leveraging hashed credentials or Kerberos tickets for
authentication.
3. Remote Execution: Utilizing protocols like SMB, RDP, or PsExec for remote command
execution.
4. Exploitation: Exploiting vulnerabilities in applications or misconfigured systems to gain
access.
5. Persistence: Installing backdoors or creating rogue accounts for continuous access.

Common Indicators of Lateral Movement


• Unusual Authentication Patterns:
o Login attempts from one system to multiple systems in a short time.
o Authentication failures followed by successes.
• Abnormal Use of Tools:
o Unauthorized use of administrative tools like PsExec, WMI, or PowerShell.
• New or Modified Services:
o Creation of suspicious services (e.g., svchost.exe impersonation).
• Unauthorized Access to Critical Systems:
o Lateral access to domain controllers, database servers, or other high-value targets.
SOAR Playbooks for Lateral Movement Detection
Here’s how you can use SOAR platforms for lateral movement detection:
Playbook Workflow: Suspicious Logins
1. Trigger:
o A SIEM alert for anomalous authentication activity.
▪ Example: Multiple failed login attempts followed by a success.
2. Steps:
o Enrichment:
▪ Query logs for user activity over the last 24 hours.
▪ Correlate with geolocation data (e.g., impossible travel times).
o Analysis:
▪ Check if the IP address matches known malicious sources in threat
intelligence.
▪ Query the endpoint for processes or tools used during the login (e.g.,
PowerShell or Mimikatz).
o Action:
▪ If confirmed malicious:
▪ Disable the user account.
▪ Isolate the endpoint.
▪ Notify the incident response team.

Playbook Workflow: Suspicious SMB Activity


1. Trigger:
o SIEM detects unusual SMB traffic between endpoints.
2. Steps:
o Enrichment:
▪ Query the network for the source and destination IPs.
▪ Analyze the files being accessed or modified.
o Analysis:
▪ Look for tools like PsExec, which uses SMB for remote execution.
▪ Query EDR logs for processes initiated by the SMB session (e.g., cmd.exe
or powershell.exe).
o Action:
▪ If lateral movement is detected:
▪ Block SMB traffic for the source machine.
▪ Capture memory dump for forensic analysis.
▪ Notify the SOC team.

Playbook Workflow: Unusual Service Creation


1. Trigger:
o SIEM detects a new service creation event.
2. Steps:
o Enrichment:
▪ Query logs for the user who created the service.
▪ Look for known lateral movement tools (e.g., PsExec, wmic.exe).
o Analysis:
▪ Cross-reference the service name with known attack patterns (e.g.,
suspicioussvc.exe).
o Action:
▪ If suspicious:
▪ Stop and disable the service.
▪ Investigate other endpoints the user has accessed.
▪ Notify the L2 hunter team.

Advanced Techniques for Lateral Movement Detection


1. Monitoring SMB Traffic
• Technical Details:
o SMB (Server Message Block) is commonly used for file sharing and remote
administration.
o Malicious actors often use SMB in tools like PsExec or for accessing shared
resources.
• Detection:
o Look for unusual SMB traffic to/from non-standard endpoints.
o Query SMB logs for suspicious patterns, such as excessive file reads or writes.
• Scenario:
o Attacker accesses a shared folder, downloads sensitive files, and uploads
malicious scripts for execution.
• Hunting:
o Search for SMB Session Setup AndX requests in logs.
o Correlate these requests with suspicious activities like file deletion or renaming.

2. Hunting for Pass-the-Hash Attacks


• Technical Details:
o Attackers use NTLM hashes instead of plaintext credentials to authenticate.
• Detection:
o Look for NTLM authentication events without corresponding plaintext logins.
o Query logs for accounts with simultaneous logins to multiple endpoints.
• Scenario:
o An attacker dumps NTLM hashes using Mimikatz and authenticates to another
endpoint.
• Hunting:
o Use Windows Event IDs (e.g., 4624 for logins and 4625 for failed attempts).
o Look for abnormal patterns, such as high-frequency login attempts.

3. Identifying Abnormal RDP Sessions


• Technical Details:
o Remote Desktop Protocol (RDP) is a common vector for lateral movement.
• Detection:
o Query logs for RDP connection attempts outside business hours.
o Look for logins from suspicious geographic locations.
• Scenario:
o An attacker uses stolen credentials to access a server via RDP and deploys
malware.
• Hunting:
o Monitor Event ID 4624 for successful RDP logins.
o Look for mstsc.exe (Microsoft Terminal Services Client) in process logs.

4. Detecting Golden Ticket Attacks


• Technical Details:
o Attackers forge Kerberos tickets to authenticate to any system.
• Detection:
o Look for abnormal Kerberos ticket-granting service (TGS) requests.
o Query logs for unusual SPNs (Service Principal Names) in TGS requests.
• Scenario:
o An attacker forges a ticket to gain domain admin privileges.
• Hunting:
o Search for Event ID 4769 (Kerberos service ticket request) with unusual account
names.
o Look for tickets with unusually long lifetimes.

Tools and Data Sources for Lateral Movement Hunting


Key Tools:
1. SOAR:
o Automate detection and response workflows.
o Example: Cortex XSOAR or Splunk Phantom.
2. EDR (Endpoint Detection and Response):
o Monitor processes and file activity.
o Example: CrowdStrike, Carbon Black.
3. SIEM:
o Correlate logs from various sources.
o Example: Splunk, QRadar.
4. Packet Captures (PCAP):
o Analyze network traffic for lateral movement.
o Example: Wireshark.
Data Sources:
• Windows Event Logs:
o Event IDs for lateral movement:
▪ 4624: Successful login.
▪ 4625: Failed login.
▪ 4672: Privileged account logins.
▪ 7045: New service installation.
• Firewall Logs:
o Look for RDP, SMB, or SSH traffic anomalies.
• DNS Logs:
o Identify suspicious domains used for C2 communication.
• Threat Intelligence Feeds:
o Correlate IOCs with known campaigns.

Example Scenario: Lateral Movement via PsExec


1. Initial Detection:
o SIEM alerts on suspicious login to a server at 3 AM.
o Logs indicate the use of PsExec for remote command execution.
2. Hunting Steps:
o Query EDR logs for processes spawned by PsExec (e.g., cmd.exe,
powershell.exe).
o Cross-reference with user activity logs to validate if the account was
compromised.
o Analyze the network for SMB traffic between the source and target system.
3. SOAR Response:
o Isolate the source endpoint.
o Disable the user account.
o Notify the SOC team and create a case for further investigation.

Conclusion
Lateral movement hunting is one of the most complex but rewarding aspects of threat hunting.
By leveraging SOAR, L2 Threat Hunters can automate routine tasks, focus on analyzing
advanced threats, and detect lateral movement efficiently. Always enrich alerts with context from
EDR, SIEM, and threat intelligence to make informed decisions.
6.Real-World Scenario: Detecting and Mitigating Lateral
Movement via PsExec

Scenario Overview:
An attacker has gained access to a corporate environment by exploiting a vulnerable endpoint.
They use PsExec to move laterally across the network, targeting a database server containing
sensitive financial data.

Step-by-Step Technical Walkthrough

1. Initial Detection
• Trigger:
o A SIEM alert flags multiple login attempts from an endpoint (e.g., HR-Laptop01)
to a file server (Finance-Srv01) during non-working hours.
o Event ID 4624 (Logon Success) is detected, followed by Event ID 7045 (Service
Installed).
• Log Details:
o Source IP: 192.168.1.101 (HR-Laptop01)
o Destination IP: 192.168.1.102 (Finance-Srv01)
o Service Name: PsExecSvc
o Process Name: powershell.exe
Immediate Response with SOAR:
• SOAR Action:
1. Query Active Directory (AD) for the source user credentials associated with HR-
Laptop01.
2. Enrich the flagged IPs and services with threat intelligence.
3. Run an automated script to query endpoint activity using EDR tools (e.g.,
CrowdStrike, Carbon Black).
2. Data Enrichment and Contextual Analysis
• SOAR Playbook Workflow:
1. EDR Query:
▪ Logs reveal that PsExec was executed by powershell.exe.
▪ Parent-child relationship:
▪ Parent: explorer.exe
▪ Child: powershell.exe -> PsExec.exe
2. Threat Intelligence Check:
▪ The IP (192.168.1.101) is clean, but the service PsExecSvc matches
known indicators of compromise (IoCs) from a recent malware campaign.
3. Network Analysis:
▪ SOAR collects NetFlow logs:
▪ Large SMB traffic from HR-Laptop01 to Finance-Srv01 is
detected.
▪ Network packet captures (PCAPs) show a suspicious file
stealer.exe being transferred via SMB.

3. Identifying Indicators of Lateral Movement


• Technical Indicators:
o Windows Logs:
▪ Event ID 7045: PsExec service installed.
▪ Event ID 4672: Special privileges assigned to a new logon session.
▪ Event ID 5145: File accessed over the network (stealer.exe uploaded to
Finance-Srv01).
o EDR Findings:
▪ PsExec was used to create a service on Finance-Srv01.
▪ A suspicious process (stealer.exe) was executed shortly after the service
was created.
o Firewall Logs:
▪ SMB traffic on TCP port 445 from HR-Laptop01 to Finance-Srv01.
4. Advanced Threat Hunting
• Manual Steps for L2 Hunters:
1. Query the Windows Event Logs:
▪ Filter for Event ID 7045 to locate newly installed services.
▪ Command:
Powershell code
>>Get-WinEvent -FilterHashtable @{LogName='System'; ID=7045} | Where-Object {
$_.Message -like '*PsExecSvc*' }
2. Analyze Processes with EDR:
▪ Search for PsExec.exe executions and their parent processes.
▪ Command:

>>edr-query --host HR-Laptop01 --process PsExec.exe --child-processes


3. Network Analysis with PCAPs:
▪ Extract and inspect SMB traffic for transferred files:
Bash code
>>tshark -r capture.pcap -Y "smb and ip.addr==192.168.1.102"
▪ Output:
>>Transferred File: stealer.exe
Size: 25MB

5. Automated SOAR Response


• Containment Actions:
o Isolate HR-Laptop01 from the network using the EDR platform.
▪ Command:
>>edr-isolate --host HR-Laptop01
o Block SMB traffic between HR-Laptop01 and Finance-Srv01 at the firewall.
▪ Command:
>>firewall block --src-ip 192.168.1.101 --dst-ip 192.168.1.102 --protocol tcp --port 445
o Quarantine the malicious file stealer.exe on Finance-Srv01:
▪ Command:
>>edr-quarantine --file /path/to/stealer.exe --host Finance-Srv01
o Disable the compromised AD user account:
▪ Command:
>>Disable-ADAccount -Identity "jdoe"

6. Forensic Analysis
• Memory Dump Analysis:
o Collect memory dumps from HR-Laptop01 and Finance-Srv01 for analysis.
▪ Command:
>>volatility -f memdump.img --profile=Win10x64 pstree
▪ Output:
>>Process: powershell.exe -> PsExec.exe -> stealer.exe
o Analyze stealer.exe with sandbox tools like Cuckoo Sandbox or Any.Run.
• Registry Analysis:
o Check for persistence mechanisms:
▪ Command:
>>Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run'
• Network Forensics:
o Inspect DNS logs for malicious domain lookups related to stealer.exe.

7. Reporting and Follow-Up


• Incident Report:
o Summarize the attack:
▪ Origin: HR-Laptop01 compromised.
▪ Vector: PsExec lateral movement.
▪ Payload: stealer.exe deployed on Finance-Srv01.
o Actions Taken:
▪ Endpoint isolation.
▪ File quarantine.
▪ User account disabled.
▪ Firewall rules updated.
• Root Cause Analysis:
o Vulnerability:
▪ The attacker exploited an unpatched SMB vulnerability (e.g.,
EternalBlue).
o Recommendations:
▪ Patch all systems to fix SMB vulnerabilities.
▪ Implement network segmentation to limit lateral movement.
▪ Enforce multi-factor authentication (MFA) for privileged accounts.

Key Takeaways for Threat Hunters


• Detection:
o Monitor for anomalous service creation (Event ID 7045) and unusual SMB traffic.
• Response:
o Use SOAR to automate containment actions like endpoint isolation and user
account lockdown.
• Investigation:
o Perform process and file analysis using EDR tools and memory forensics.
• Prevention:
o Apply regular patching, implement privilege management, and monitor for known
attack patterns.

You might also like