CSA (312-39) SOC Simulation Lab

Step into the role of a Tier 3 SOC Analyst investigating a potential Timestomping attack. Learn to correlate core Windows Security Event Logs to track adversary actions designed to evade detection and destroy forensic timelines.

Scenario Context

At 3:00 AM, a high-fidelity SIEM alert triggers for "Suspicious System Time Modification" on a critical internal database server. There are no approved change windows or automated NTP synchronization tasks scheduled for this hour. Adversaries often alter the system clock (Timestomping - MITRE ATT&CK T1070.006) to break SIEM correlation rules, invalidate Kerberos tickets, or obscure the timestamps of dropped malware. You need to investigate the Windows Event Viewer logs to determine what happened and who is responsible.

Security Environment

Windows Event Logs Timestomping Log Correlation

                # SIEM Raw Log Search (Index: win_sec)

                # Log Entry 1:

                Time: 03:01:12 AM | EventCode: 4624 | LogonType: 10 (RemoteInteractive)

                TargetUserName: "svc_dbadmin" | IpAddress: "10.50.2.100" | LogonID: 0x1F3A

                # Log Entry 2:

                Time: 03:01:15 AM | EventCode: 4616 | ProcessName: "C:\Windows\System32\cmd.exe"

                SubjectLogonId: 0x1F3A | PreviousTime: "2024-10-24T03:01:15Z" | NewTime: "2022-01-01T00:00:00Z"

                # Log Entry 3:

                Time: 12:00:02 AM (Simulated) | EventCode: 4688 | ProcessName: "C:\Windows\Temp\payload.exe"

                SubjectLogonId: 0x1F3A

*Note: Notice how the attacker executes a payload immediately after altering the time, causing the SIEM to potentially ingest the payload execution event out of sequence or discard it entirely due to time-range filters.

Question:

A SOC analyst receives an alert indicating that the system time on a critical Windows server was changed at 3:00 AM. There are no scheduled maintenance tasks at this time. Unauthorized time changes can be used to evade security controls, such as altering timestamps to obscure malicious activity. The analyst must identify the relevant event codes that log system time modifications and related suspicious behavior.

Which of the following Windows Security Event Codes should the analyst review to investigate potential tampering?

Analyst Hint: To investigate this alert, you need two pieces of evidence: 1) The exact event that records the system time being changed, and 2) The event that tells you WHO successfully authenticated to the server right before the change occurred.

Expert Insight: Senior Analyst Debrief

What is happening: An attacker has compromised an administrative account via RDP (Logon Type 10) and is manipulating the system clock. By changing the system time drastically to the past, any subsequent malicious actions (like file creation or execution) will be stamped with old dates. This helps the attacker evade SIEM alerts that only look at events generated in the last 24 hours.

Why the correct answer is correct (Option C)

C. 4616 and 4624: To perform a thorough investigation, the analyst must review Event ID 4616 (System time was changed) to confirm the exact before-and-after timestamps and identify the process used (e.g., cmd.exe using the `date` or `time` commands). Furthermore, the analyst must review Event ID 4624 (An account was successfully logged on) to identify the user session, source IP address, and credentials that were used to perform the tampering.

Why the other options are wrong

A. 4625 and 4634: Event 4625 is a Failed Logon, and 4634 is a Logoff. While useful for tracking brute-force attempts or session durations, they do not track the system time change itself.

B. 4616 and 4618: While 4616 is correct for the time change, 4618 indicates "A monitored security event pattern has occurred." It is rarely used to correlate the identity of the user who performed the time change.

D. 4608 and 4609: These events indicate Windows is starting up (4608) or shutting down (4609). They are unrelated to manual time manipulation.

SOC Mini-Lesson: Tying Actions to Actors via LogonID

When you detect a critical administrative action like Event 4616, the alert alone is not enough. You must build a narrative.

In Windows Event Logs, almost every administrative action includes a SubjectLogonId (e.g., 0x1F3A). This is a unique, temporary hexadecimal identifier assigned to a specific logon session.

Step 1: Find the malicious action (Event 4616). Note the SubjectLogonId.
Step 2: Pivot your SIEM query to search for Event 4624 where the TargetLogonId equals that exact same hex value.
Step 3: You have now successfully correlated the action to the exact user, IP address, and workstation the attacker used.

Takeaway: Do not investigate alerts in a vacuum. Always correlate the action (what happened) with the authentication event (who did it and from where) using the LogonID.

Ready for more SOC scenarios?

Practice real-world log analysis and threat detection with ExamRange.

Explore CSA Simulations