CTF: Silence of the RAM - Tushar's Write-up

BIG shout out and thanks to Tushar Arora for putting this together for our SOC team. It is always exciting to see the junior analyst expand their minds, while supporting other's growth. I am very thankful for his willingness to put together this scenario and submit the formal write-up/solution as a blog post. Keep up the good work Tushar. You have my vote for being promoted to the next level😆

Thanks Tushar and much respect! ✌

----------------------------------------------- 

First-up, let’s start with the scenario provided, highlighting the information that might help us:

The Scenario

On December 03, 2025 at 06:59 AM UTC, the Help Desk received a ticket from a user reporting "my system became extremely sluggish and unresponsive, eventually freezing completely and forcing a system reboot."

Later, on the same day at 07:45 AM UTC it was transferred to the SOC team for review. When the SOC team attempted to correlate the user's report with EDR telemetry, they discovered a massive anomaly: The sensors were blind.

The logs reveal a complete "blackout" window leading up to the reboot. During this time, the EDR agent sent no heartbeats, no logs, and no alerts. SOC assumed that the host is offline.

However, since the system rebooted and came back online, the dashboard lit up. We are now seeing critical alerts indicating potential PowerShell and script engine activity which were blocked by the EDR. The high frequency of these alerts suggests an automated script or mechanism attempting to execute repeatedly, likely indicating persistence.

The SOC team believes the attacker used the "blackout" window to establish themselves.

Before isolating the host, the SOC team performed a "Smash and Grab" triage:

1. The SOC retrieved a suspicious executable found in the user's Recycle Bin.
2. They captured a System Memory Dump of the currently infected state.

Your mission, should you choose to accept: You have the "Dead" logs (Event Viewer) and the "Live" memory. Bridge the gap. Find out what happened during the silence, how they got back in, and identify the active command and control (C2) channel.

Objective:
Investigating the case in hand while covering incident response report basics: Who, What, When, Where Why, and How.

Evidence Package provided:
• Evidence/Memory.dmp: Full RAM capture taken post-reboot (Current Infection).
• Evidence/Logs:
• Raw EVTX: System, Security, PowerShell, SysMon logs exported from the victim.
• Artifacts/recovered_payload.zip: The executable retrieved from the Recycle Bin.

Unified Timeline Creation and Event Correlation:
Instead of correlating events across multiple log sources (System, Security, PowerShell, Sysmon), the raw .evtx artifacts were processed into a unified timeline using Eric Zimmerman’s EvtxECmd. This allows for identifying the sequence of events such as (Process Creation -> Service Stop -> File Deletion) from a single file.

Drawback: Timestamps in Unified timeline are not accurate to the seconds and are rounded up. For example: 2025-12-03T05:59:29.9509534Z becomes 5:59:30 AM UTC. Thus, to keep the accuracy, timestamps are validated from raw event log files itself.

By stitching together all the provided logs and sorting them by time, we created a master timeline that shows a complete sequence of all events that occurred during the incident, regardless of their log source, in a single file.

The Write-up

Overview:
Forensic analysis of the system logs and memory capture of host DESKTOP-4S97VHS confirmed that the host was compromised via a malicious file named AdobeFlashUpdate.exe downloaded through Microsoft Edge. The attacker successfully escalated privileges by injecting into the Local Security Authority Subsystem Service (lsass.exe), which was then used to drop and execute a specialized evasion tool (AdobeUdpate.exe). This tool utilized the Windows Error Reporting framework (WerFaultSecure.exe) to intentionally crash the Cortex XDR agent (cyserver.exe), creating the observed "blackout" window. The security blackout lasted approximately 50 minutes, beginning at 05:59:30 UTC when WerFaultSecure.exe was triggered to handle the crash, and ending when the system successfully rebooted at December 03, 2025 at 06:49:37 UTC.

During this period (50 minutes) of blindness, the attacker established persistence by creating a local administrator account named "servicemgmt", enabling the OpenSSH service, and modifying firewall rules to allow inbound traffic on port 22. Post-reboot, the attacker successfully regained access via SSH and attempted, but failed, to establish further persistence using WMI Event Subscriptions.

Figure 1: Map of threat actor's activities. 

Recommendations:
• Configure high-priority alerts for the unexpected termination or crashing of security agent processes.
• Disable the OpenSSH Server (sshd) on standard workstations unless explicitly required.
• Configure the perimeter firewall to only permit SSH

Next Steps:
• Perform a sweep of the environment for the attacker's IP 10.0.0.118 and the specific C2 port 1935 to identify any other potentially compromised hosts.
• Immediately disable/delete the unauthorized "servicemgmt" account and reset the credentials for the user "Vic." Investigate if domain credentials were scraped from memory during the lsass.exe injection.
• Immediately remove the active SSH connection, PID 3468.
• Search the SIEM for the file hashes associated with AdobeFlashUpdate.exe (SHA256:451C3BB3971A88BD08D0F463B33C682412F97651AE69329BC832022EDEAC7BFB) and the evasion tool AdobeUdpate.exe (SHA256:BCF5445A8036A0546C9DEE6F4FA3E49FC8B9D29D35EFDA24EBA1ED71EF6E4677).

Analysis:

While looking at the created timeline, multiple FileCreateStreamHash events (Event ID 15) were seen starting at 5:56:10 AM UTC. The last event in the stream indicated that a file named TargetFilename: C:\Users\Vic\Downloads\Unconfirmed 215709.crdownload:Zone.Identifier being downloaded from msedge.exe.

• Checking the zone identifier information to check where this file came from, the file was being referred from 10.0.0.118:3000 from file server location hxxp[://]10.0.0[.]118:8080/AdobeFlashUpdate[.]exe. 

Figure 1: File being downloaded as recorded under sysmon logs.

Q: Forensic artifacts indicate the initial payload was tagged with the 'Mark of the Web' (Zone.Identifier) upon creation. Analyze the file stream events. What is the Filename of the executable downloaded by the user's browser? From where it was downloaded?

A: AdobeFlashUpdate.exe | ReferrerUrl=http://10.0.0.118:3000/ HostUrl=http://10.0.0.118:8080/AdobeFlashUpdate.exe

• File hash after full download: 451C3BB3971A88BD08D0F463B33C682412F97651AE69329BC832022EDEAC7BFB 

• Searching for file hash reputation on threat intel feeds and Google dorks, no results were observed.

Figure 2: No file reputation as per hash search on Virus total.

Q: What is the Hostname and the Timezone offset (UTC+/-) of the workstation at the time of the incident?

A: DESKTOP-4S97VHS, UTC-8

[Detour: Timezone explanation]:
The workstation hostname was identified as DESKTOP-4S97VHS from the <Computer> field across Sysmon, Security, and System logs. It’s important to understand how Windows logs handle time:

---------------------------------

1. Logging Time (UTC):
Windows Event Logs store timestamps in UTC via the SystemTime field, also called Zulu time. This represents when the event was recorded, not the local time configured on the host. For example: 

For example: <TimeCreated SystemTime="2025-12-03T06:49:48.8155687Z" /> indicates when the event was logged, in UTC; and not the local timezone for the host.

Figure 3: Difference between local logged-time and the actual configured time on victim's machine.

2. Local Time (Human-Readable):
Some System events include local time rendered for human readability, such as Event ID 6008, which reported an unexpected shutdown at 10:28:17 PM on 2025-12-02, reflecting the workstation’s local time (shown above).

3. Configured Timezone (Bias):
The system’s actual timezone is defined by the bias, which specifies the difference between local time and UTC. Kernel-General Event ID 24 shows CurrentBias = 480, meaning 480 minutes must be added to local time to obtain UTC, corresponding to a UTC-8 offset. 

• UTC = Local Time + 8 hours
• Local Time = UTC − 8 hours

Figure 4: Looking for time zone BIAS, we found the bias is configured as 480.

By comparing the local shutdown time with the UTC logging timestamps, we confirm the workstation was configured with UTC-8 (PST) at the time of the incident. This illustrates the distinction between UTC logging time, locally rendered event time, and the persistent timezone configuration.

To learn more about time see:

𝗗𝗶𝗴𝗶𝘁𝗮𝗹 𝗙𝗼𝗿𝗲𝗻𝘀𝗶𝗰𝘀 𝗧𝗶𝗽: 𝗧𝗶𝗺𝗲 𝗭𝗼𝗻𝗲𝘀 𝗶𝗻 𝗪𝗶𝗻𝗱𝗼𝘄𝘀 𝗥𝗲𝗴𝗶𝘀𝘁𝗿𝘆 :
Remote Desktop Protocol: How to Use Time Zone Bias:
TimeZone Information:

---------------------------------

Going through the timeline, a network connection event was seen, which occurred right after the execution of AdobeFlashUpdate.exe. Notably, shortly after the network connection, command “whoami” was executed with parent process as AdobeFlashUpdate.exe.

• At 05:56:35 UTC, AdobeFlashUpdate.exe was launched by explorer.exe, suggesting a user mode execution.
• At 05:56:36 UTC, a network connection was initiated by the suspicious executable, towards destination IP 10.0.0.118 and port 1935
• Port 1935 is the default port used by the Real-Time Messaging Protocol (RTMP), a TCP-based protocol designed for low-latency transmission of audio, video, and data.
• This raises a few flags:
• Executable was not launched from a trusted installation path, and
• AdobeFlashUpdate.exe, if legitimate, should not be communicating with a streaming service port.
• Following this, command line “whoami” was seen at 05:56:50 UTC with parent process as C:\Users\Vic\Downloads\AdobeFlashUpdate.exe.
• This execution confirms Initial reconnaissance by AdobeFlashUpdate.exe.
• This also indicates that an initial reverse shell was established using AdobeFlashUpdate.exe.

Figure 5: AdobeFlashUpdate.exe establishing a network connection, which was followed by execution of whoami.exe

Shortly after the network connection, at 05:58:55 UTC, an unusual file create event was observed. Lsass.exe created an executable AdobeUdpate.exe under system folder (C:\Windows\System32\AdobeUdpate.exe).

File Hash: BCF5445A8036A0546C9DEE6F4FA3E49FC8B9D29D35EFDA24EBA1ED71EF6E4677

Treat intel verdict: 48/71 security vendors flagged this file as malicious.

 Figure 6: File is malicious as per threat intel.

• Note the intentional misspelled executable here; “AdobeUdpate” instead of “AdobeUpdate”.
• Even though, in case the executable name was something else and legitimate, lsass.exe or any other system process should not be writing any process into the system directory itself.
• In a live incident scenario, the hashes for both executables should have been blocked by now to contain the threat.

Figure 7: An executable was written by lsass.exe under system directory.

Further review of the event timeline indicates that the same lsass.exe process (PID 728) initiated the execution of cmd.exe (PID 5600) from the system directory. Subsequently, cmd.exe spawned a powershell.exe (PID 7336) process.

• This execution chain is anomalous, as lsass.exe does not normally launch command-line interpreters or scripting engines. Such behavior is indicative of potential process injection, credential abuse, or post-compromise activity and should be treated as suspicious.

Q: Post-infection, the attacker migrated to a critical system process to hide their presence. Logs show this system process behaving anomalously by writing a new binary to disk. What is the Image Name of this abused system process?

A: lsass.exe

Q: Identify the unauthorized executable written by the system process found in the previous question. What is the Filename of this dropped binary?

A: AdobeUdpate.exe

Figure 8: Process execution chain by lsass.exe

At 05:59:29 UTC, below command was executed from the above powershell (PID 7336).

Command executed: .\AdobeUdpate.exe 3280 50000

PID of AdobeUdpate.exe: 5712

• Command line indicates that 2 parameters were passed while execution, which is unclear as what they could be.  

Figure 9: Suspicious executable AdobeUdpate.exe was executed from powershell.

Just after the execution of AdobeUdpate from powershell, execution of WerFaultSecure.exe was seen in security logs at 05:59:30 UTC. 

• WerFault secure is the Windows Error Reporting framework which is used to collect crash dumps from protected processes (lsass, or any other antivirus process).

• Thus, if WerFaultSecure.exe was seen, that means a protected process might have crashed.

• Command observed: 
C:\Windows\System32\WerFaultSecure.exe /h /pid 3280 /tid 3284 /encfile 196 /cancel 264 /type 268310
• Note the pid in the above command (3280), which matches with the argument that was passed in the parent process AdobeUdpate.exe.

Figure 10: AdobeUdpate.exe triggered execution of WerFaultSecure.exe for a process with pid 3280.

Searching for the process ID 3280 under Sysmon logs, we can see that it belongs to Palo Alto Networks process cyserver.exe

 Figure 10.1: Additional evidence for PID 3280.

Q: [Updated]: The unauthorized executable in the previous question caused a process to crash. What is the name and PID of this process that crashed?

A: cyserver.exe with PID 3280

A quick internet search revealed that the cyserver.exe process specifically handles the communication and data exchange between the Traps agents deployed across the network and the Traps management console. It collects and aggregates security data from the agents, processes it, and generates reports for analysis and monitoring purposes.

Thus, based on these facts, it is evident that AdobeUdpate.exe utilized WerFaultSecure.exe to deliberately crash cyserver.exe. Since cyserver.exe is responsible for generating reports and logs, it is clear that this action caused the blackout mentioned by the SOC team.

Searching for any other processes executed by previous powershell (PID: 7336), ScriptBlock “net user /add servicemgmt MyP@ssw0rd” was observed at 06:01:33 UTC.

• This command creates a new user “servicemgmt” with the displayed password.

• The above indicates that the attacker created a new user perhaps for persistence.

Filtering security logs with event code 4720 (account creation), we can see the answer to the question.  

Figure 11: SID for newly created user.

Q: A local user account was created shortly before the system outage. What is the Security ID (SID) associated with this new principal?

A: servicemgmt | SID: S-1-5-21-3600098720-2357510703-1039409092-1004

Following this, multiple commands were observed from PowerShell as mentioned below:

Timestamp (in UTC)	Command	Purpose
06:01:56 UTC	Set-Service -Name sshd -StartupType Automatic	Configures the OpenSSH server service (sshd) to start automatically on boot. Ensures persistence across reboot.
06:01:58 UTC	start-service sshd	Immediately starts the OpenSSH service if it isn’t already running.
06:02:02 UTC	New-NetFirewallRule -DisplayName "OpenSSHService" -Protocol TCP -LocalPort 22 -Action Allow	Creates a Windows Firewall rule allowing inbound TCP port 22 (SSH). Opens the system to remote SSH connections.
06:04:19 UTC	net user	Lists all local user accounts on the system. Perhaps attacker is checking if “servicemgmt” was created
06:04:46 UTC	net localgroup administrators /add servicemgmt	Adds the user servicemgmt to the local Administrators group. Privilege escalation / persistence: grants full admin rights to a user.
06:16:22 UTC	net localgroup administrators	Lists all members of the Administrators group. Verification step: confirms the user was successfully added.
06:28:42	Get-Service sshd	Checks the status of the SSH service.
06:41:57	New-NetFirewallRule -DisplayName "OpenSSHServic" -Protocol TCP -LocalPort 22 -Action Allow	Creates another firewall rule allowing port 22 (note the slightly different name). Redundant or sloppy duplication: common in manual attacker activity or scripted persistence.

Figure 12: User added to administrator group.

Q: This new user was immediately added to a privileged local group. What is the RID (Relative ID) of that group?

A: 544

Q: Prior to the reboot, the system's network traffic filtering rules were altered via the command line. Locate the specific parameter used to name this new configuration. What is the DisplayName value?

A: OpenSSHService and OpenSSHServic

Figure 11: powershell logs showing firewall rules addition.

The above sequence indicates manual or scripted persistence via SSH backdoor setup on victim host.

Timestamps mentioned above are for the scriptblock creation events. A significant difference was seen between this and CommandInvocation event for the associated script.

• This supports the fact that the user mentioned their system became extremely sluggish and unresponsive. 

Focusing on PowerShell logs itself, starting at 06:53:46 UTC, there was a surge in PowerShell operational events. These events were related to PowerShell startup, execution of remote script and execution of pipeline.

One particular event was seen at 2025-12-03T06:53:54.5701428Z UTC, where script block text was “echo zhQemtXa; $jWQyd = Set-WmiInstance -Namespace root/subscription -Class __EventFilter -Arguments @{EventNamespace = 'root/cimv2'; Name = "UPDATER"; Query = "SELECT * FROM Win32_ProcessStartTrace WHERE ProcessName= 'msedge.exe'"; QueryLanguage = 'WQL'} $bvjH = Set-WmiInstance -Namespace root/subscription -Class CommandLineEventConsumer -Arguments @{Name = "UPDATER"; CommandLineTemplate = "powershell.exe -nop -w hidden -noni -e aQBmACgAWw…A7AA=="} $jWQydToConsumerBinding = Set-WmiInstance -Namespace root/subscription -Class __FilterToConsumerBinding”

As per the command a WMI event filter named UPDATER was created which fires an event whenever msedge.exe is started.

Q: The attacker attempted to execute a script that failed which triggered alerts as mentioned by SOC team. Which standard Windows application was the Target of this script?

A: msedge.exe

Q: [Updated]: What exactly was the attacker trying to achieve from the above script?

A: WMI Persistence

Decoding the base64 using CyberChef, it shows a very strong indicator of an obfuscated, in‑memory payload, most commonly seen in fileless malware utilizing in-memory execution.

Figure 13: Attacker attempted to drop a fileless malware, or establish persistence using WMI event subscription.

On a good note, as per SOC, these Powershell and script engine activities, were blocked by the EDR.

Moving back to our initial timeline, at 6:49:39 AM UTC, a successful boot for the system was observed, which started at ‎06:49:37 UTC as indicated by system logs.

Figure 14: System reboot observed.

With the system reboot, Cortex XDR health service also started again, which helped in preventing the previously mentioned WMI persistence attempts.

Figure 15: Cortex XDR health service started again around 06:51:12 UTC

Q: "Calculate the exact duration of the security blackout. How many seconds elapsed between the execution of the binary used to disable the security-critical service and the subsequent Operating System startup. 

Note: A variance of +/- 5 seconds is accepted to account for log timestamp differences."

A: Approx. 3007 seconds

Explanation: The security blackout lasted approximately 50 minutes, beginning at 05:59:30 UTC when WerFaultSecure.exe was triggered to handle the crash, and ending when the system successfully rebooted at 06:49:37 UTC.

Phase 2: Analyzing malware file (Static Analysis)

As per the instructions, the file can be accessed from https://github.com/r00t36/CTF-Silence-of-the-RAM and opened on CyberChef to answer the questions:

• Decoding the base64 provided on the above link, we can see the Magic number ASCII “MZ” in the output which confirming that the deleted file was an executable.

Figure 16: Provided artifact is an executable.

Q: What is the SHA256 hash of the dropped executable provided in the artifacts?

A: Using SHA2 with 256 size, the SHA 256 hash for this executable was “bcf5445a8036a0546c9dee6f4fa3e49fc8b9d29d35efda24eba1ed71ef6e4677”.
• Searching this executable hash under master-timeline and Sysmon logs, it was confirmed that the hash belongs to AdobeUdpate.exe.

Q: What was the artifact name before deletion?

A: AdobeUdpate.exe

Figure 17: Deleted executable has same hash as AdobeUdpate.exe.

• Since SOC team recovered this from recycle bin it indicates that the attacker was probably trying to cover their tracks.
• Next, we utilized “strings” utility from cyberchef itself to look for executable metadata including readable strings, import functions and any details that might help in understanding the executable.
• Strings utility is used to perform static analysis of a file.
• Focusing on the highlighted output in the screenshot below, following can be inferred:

Figure 18: Performing static analysis using strings revealed its nature.

• Similar strings were observed as we noted earlier when WerFaultSecure.exe handled a crash related to PID 3280 (cyserver.exe).

Q: [Updated]: Analyze the malware strings. The evidence suggests the attacker exploits the system's native reaction to the process crash identified previously. What is the exact name of the Windows Reporting binary/process referenced in the strings, which the malware likely targets?

A: WerFaultSecure.exe

• Strings relating to “Target paused”, “WER paused”, “*create PPL process”, “Kill WER successfully/failed” indicates the artifacts functionality and the ASCII used in their development.
• Since we know that after the execution of AdobeUdpate.exe, cyserver.exe became unresponsive, it could relate to the “Target paused” seen here.
• Additionally, “WER paused” might indicate that at some point during the execution, AdobeUdpate paused Windows Error Reporting as well.
• Other strings reveal that the executable had the ability to create a PPL processes (process to run in protected state, example: any anti-malware service).
• Analyzing the strings further revealed the original name of the exploit (EDR-Freeze), a short description indicating that the tool is used to freeze EDRs as seen in our case and its path under the developers’ environment.

Figure 19: Executable metadata revealed its name, usage, and a short description.

Figure 20: Probably the executable path in developers’ environment.

Q: What does the artifact file name signify?

A: $R at the beginning of the artifact file signifies that the file resided in Recycle bin; this could mean cleanup activity.

Phase 3: Memory Forensics

Next, post-reboot we’ve a RAM capture for the host, which helped us in analyzing the events occurred afterwards.

Volatility3 was used to analyze the RAM capture (.dmp file), and the outputs from multiple Volatility plugins were exported to text files. Storing the plugin results in .txt format facilitated efficient review and eliminated the need to rerun plugins during subsequent analysis.

Figure 21: Volatility plugins output data was saved under txt files.

• Starting with the network connections, an “established” network connection was observed at 2025-12-03 07:04:56.000000 UTC from host IP 10.0.0.84 port 22 towards attackers IP 10.0.0.118 and port 47686.
• Owner responsible for the connection was sshd.exe with PID 3468.

Q: Analyze the active network connections in memory. What is the IP address of the attacker?

A: 10.0.0.118

Q: Which specific Windows service process (Image Name) is responsible for handling this outbound network connection?

A: sshd.exe

• As per the timestamp, the event occurred post-reboot indicating they’re inside the network after the system reboot, perhaps by utilizing the ssh changes they made earlier.

Figure 22: SSH connection towards attacker IP post-reboot.

• Searching for this PID 3468 under process tree, revealed that ssh process started at 06:49:53 UTC (around 15 seconds after reboot), and the network connection to attacker was established at 07:04:56 UTC.

Figure 23: SSH process originally started at 06:49:53 UTC

• Confirming all the SSH processes, 2 other child and grandchild ssh processes were observed. 

• PID for the final SSH process is 9772, which upon searching under Sysmon logs confirmed that it was executed under user “DESKTOP-4S97VHS\servicemgmt”.

Figure 24: SSH process tree (1); Final ssh process executed under user "servicemgmt" (2)

• Same can be confirmed from volatility windows.sessions as well to confirm the session information for the desired process.

Figure 25: Using volatility to confirm that ssh was running under servicemgmt user

• Filtering the files - Windows.filescan.FileScan - present in Recycle Bin of the host, it can be seen that the provided artifact ($RDK1PPK.exe) was under the user with SID S -1-5-21-3600098720-2357510703-1039409092-1001. The SID when checked - windows.getsids - belongs to user “Vic”.

Figure 26: Provided artifact was found under user "Vic" Recycle Bin

• To check the deletion time for the file, we utilized windows.mftscan.MFTScan. The deletion timestamp for the file $RDK1PPK.exe was 07:01:06.000000 UTC.

Q: The Master File Table (MFT) is a system file in the NTFS file system (having the name $MFT) that stores metadata information about all files and directories on an NTFS volume. Using this what was the Deletion Timestamp (UTC) associated with the above file from phase 2?

A: $RDK1PPK.exe  deleted at 07:01:06.000000 UTC

Figure 27: File deletion timestamp.

While performing additional analysis and looking for all the network connections to and from attacker IP 10.0.0.118; at 06:53:05 UTC, user servicemgmt had a network connection established from host 10.0.0.84 to attacker IP 10.0.0.118. During the connection, it executed AdobeFlashUpdate.exe again from C:\Users\Vic\Downloads\AdobeFlashUpdate.exe path.

• It is to be noted that this event occurred at 06:53:05 UTC and ssh auto-restarted at  06:49:53 UTC after the reboot. 

This event was then followed by network connections between 07:02:37-07:03:19 EST, where powershell.exe was involved as well.

• This is indicative of the events occurring while attacker still had access to the system and when they’re attempting to establish WMI persistence (around 06:53:54 UTC), and delete the evidences (07:01:06.000000 UTC) mentioned before.

Figure 28: Attacker relaunching AdobeFlashUpdate.exe post-reboot to gain reverse shell.

The network connections at 07:02:37 and 07:02:38 were towards attacker IP 10.0.0.118 and destination port 4444, which is commonly used for Metasploit handlers or reverse shells. Since these connections might have been terminated earlier, they did not appear in the memory dump. 

Before the observed network connections an SSH connection was also seen at 06:51:03 UTC originating from source IP 10.0.0.118 (attacker IP) towards destination host IP 10.0.0.84. Perhaps, this is the SSH connection that attacker used as a backdoor to regain access and then launched AdobeFlashUpdate to gain reverse shell as mentioned above, which was then followed by WMI persistence attempts to be more stealthy. 

Q: An administrative logon was observed from the above process. At what time first logon from this user was observed?

A: 06:51:06 UTC

Figure 29: SSH connection seen post-reboot

Figure 30: Security log confirming the logon.

Appendix 1:
Notable Events table

Timestamp (UTC)	Action / Event	Actor / Source	Context & Significance
5:56:10	File Download	msedge.exe	User downloads Unconfirmed...crdownload (Referenced from AdobeFlashUpdate.exe).
5:56:35	Process Execution	explorer.exe	User launches AdobeFlashUpdate.exe from Downloads.
5:56:36	Network Connection	AdobeFlashUpdate.exe	Connects to C2 10.0.0.118 on port 1935 (RTMP/Streaming port).
5:56:50	Command Execution	AdobeFlashUpdate.exe	Executes whoami. Indicates initial reconnaissance/reverse shell.
5:58:55	File Creation	lsass.exe	lsass.exe (System process) drops AdobeUdpate.exe (misspelled) into C:\Windows\System32. Lsass dropping a file indicate privilege escalation.
5:59:00	Process Injection	lsass.exe	lsass.exe spawns cmd.exe.
5:59:06	Script Execution	cmd.exe	cmd.exe spawns powershell.exe (PID 7336).
5:59:29	Evasion Tool Execution	powershell.exe	Executes .\AdobeUdpate.exe 3280 50000. Targeted PID 3280 is cyserver.exe (Cortex XDR).
5:59:30	Process Crash	WerFaultSecure.exe	WerFaultSecure.exe runs, indicating cyserver.exe (EDR) has crashed. "Blackout" Begins.
6:01:33	Persistence (Account)	powershell.exe	Creates backdoor user servicemgmt with password MyP@ssw0rd.
06:01:56 - 06:02:02	Persistence (SSH)	powershell.exe	Configures sshd to auto-start and opens Firewall Port 22.
6:04:46	Privilege Escalation	powershell.exe	Adds servicemgmt to Administrators group.
6:49:37	System Reboot	System	Kernel starts (Event ID 12). The system recovers from instability/crash.
6:49:53	Service Start	sshd.exe	OpenSSH service starts automatically post-reboot.
6:51:03	Re-Entry	sshd.exe	Attacker 10.0.0.118 connects via SSH to 10.0.0.84. "Blackout" Ends.
6:51:12	EDR Recovery	Service Control	Cortex XDR health service restarts.
6:53:05	Payload Execution	servicemgmt	Backdoor user executes AdobeFlashUpdate.exe again.
6:53:54	Persistence (WMI)	powershell.exe	Attempt to set up WMI Event Subscription which would trigger upon execution of msedge.exe (Blocked by EDR).
7:01:06	Anti-Forensics	Explorer/System	Malicious file deleted/moved to Recycle Bin.
7:04:56	C2 Established	sshd.exe	Active SSH tunnel confirmed in memory dump (PID 3468).

Once again, big thanks and much respect to Tushar for putting this together. As stated above, it is awesome to see the junior analysts expanding their minds while sharing knowledge. Keep up the good work!!