CSA (312-39) SOC Simulation Lab
Learn how to investigate registry-based persistence mechanisms by identifying the core Windows Event IDs used in SOC detection engineering.
Scenario Context
You are a Tier 3 SOC Analyst handling an escalation. A suspicious PowerShell execution was flagged by your EDR on a developer's workstation (DEV-WKS-092). The script appeared to be attempting to establish persistent access across reboots via the Windows Registry.
Because the EDR agent briefly lost connectivity during the execution, the exact registry telemetry wasn't sent to the EDR console. You need to drop into the raw SIEM logs and hunt through the Windows Security Event Logs to confirm if the adversary successfully modified a persistence key.
Security Environment
You execute a targeted search in Sentinel/Splunk to look for activity hitting the critical CurrentVersion\Run registry hive on that specific host. You need to filter down the massive volume of object access logs to find the exact event indicating a modification.
Query: index=windows host=DEV-WKS-092 source="WinEventLog:Security" ObjectName="*\CurrentVersion\Run" EventCode=[TARGET_EVENT_ID]
Expected Result:
LogName: Security
EventID: ????
Task Category: Registry
ObjectName: \REGISTRY\USER\S-1-5-21-...\Software\Microsoft\Windows\CurrentVersion\Run
ObjectValueName: SystemUpdate
NewValue: C:\Users\Public\svchost.exe
To pull this exact log, you must know the correct Event ID for registry modifications.
Question
Expert Insight
1. What is happening?
Adversaries frequently abuse the Windows Registry to maintain persistence (e.g., modifying `Run` or `RunOnce` keys). To detect this, SOC engineers ensure that System Access Control Lists (SACLs) are configured on critical registry hives. When these keys are touched, the Windows kernel generates specific Object Access event logs. Knowing the distinction between these event IDs separates junior analysts from senior threat hunters.
2. Why D (4657) is correct
Event ID 4657 specifically means "A registry value was modified." While the EC-Council question broadly says "access the Registry key", in SOC operations, 4657 is the definitive event ID we search for when hunting for registry-based persistence or tampering. This event is incredibly high-value because its payload includes the `ObjectName` (the key path), `ObjectValueName` (the specific value modified), and crucially, the `OldValue` and `NewValue`.
3. Why the others are wrong
- A. 4656: "A handle to an object was requested." This is notoriously noisy. It only tells you a process *asked* the OS for permission to access an object, not that it successfully read or modified it.
- B. 4663: "An attempt was made to access an object." This is typically used for File System auditing (tracking file reads/writes) rather than granular registry value modifications.
- C. 4660: "An object was deleted." This is highly useful for tracking anti-forensics (e.g., an attacker deleting a key to hide their tracks), but does not help us identify the creation of a new persistence mechanism.
4. Real-world SOC Application
When an EDR alert fires for suspicious PowerShell, and the telemetry drops, falling back to SIEM is mandatory. By querying `EventID=4657` along with the host and timeframe, you can extract the `NewValue` field. If `NewValue` reveals a path like `C:\Users\Public\payload.exe`, you have instantly confirmed successful persistence and identified the exact binary you need to isolate and analyze.
MINI LESSON: KQL Hunting for Registry Persistence
If you are working in Microsoft Sentinel (or Microsoft Defender XDR), you can proactively hunt for adversaries modifying Run keys using Kusto Query Language (KQL). Here is a standard detection engineering query pattern:
SecurityEvent
| where EventID == 4657
| where ObjectName contains @"\CurrentVersion\Run"
| project TimeGenerated, Computer, Account, ProcessName, ObjectName, ObjectValueName, NewValue
Pro-Tip for ExamRange users: Event ID 4657 will ONLY generate if you have enabled the "Audit Registry" subcategory in your Advanced Audit Policy configuration AND applied a SACL to the specific registry keys you wish to monitor.
Ready for the next incident?
Enhance your detection engineering and incident response skills.
Explore more CSA simulations