Week 3 - Cold Access#

Step 1: Build a timeline from PCAP#

1. Filter POP3 sessions to confirm email retrieval activity.
2. Identify suspicious HTTP session to attacker host 34.250.131.104.
3. Correlate follow-up traffic (especially ICMP) after exploit page fetch.

Step 2: Extract delivered exploit content#

1. Parse HTTP 200 responses from PCAP.
2. Isolate the HTML response from the attacker-controlled host.
3. Save payload as exploit.html for static analysis.

Step 3: Analyze exploit JavaScript and WASM#

1. Inspect object confusion primitives (DOMRect, AudioBuffer).
2. Locate TrustedCage scan logic and dispatch marker (0x1f8d).
3. Extract wasmBuffer byte array and reconstruct executable shellcode chunks.

Step 4: Disassemble reconstructed shellcode#

1. Rebuild JIT chunk stream from f64.const immediate values.
2. Disassemble x64 instructions with Capstone.
3. Validate WinExec resolution, command offset, null-termination, and call sequence.

Step 5: Verify every question with evidence#

1. Map each question to at least one direct artifact (packets, code, disassembly line).
2. Avoid assumptions from public PoCs unless supported by local evidence.
3. Finalize answer set with explicit proof and sanity checks.

Vulnerability primitive#

From exploit.html:

1
var domRect = new DOMRect(1.1,2.3,3.3,4.4);
2
var node = new AudioBuffer({length: 3000, sampleRate: 30000, numberOfChannels : 2});
3
var channel = node.getChannelData(0);

The exploit abuses confusion between DOMRect and AudioBuffer-related memory to pivot into arbitrary read/write.

TrustedCage dispatch scan#

1
//dispatch_table_from_imports address
2
var trustedCage = intView[1];
3

4
function findImportTarget(startAddr) {
5
  var dispatchMap = 0x1f8d;
6
  ...
7
}
8
var startAddr = 0x40600;

This locates the import/dispatch table entry (dispatch_table_from_imports) by scanning for marker 0x1f8d from offset 0x40600.

JIT execution pivot#

1
var code = i32tof(startAddr + codeIdx * 4 + 0xc, trustedCage);
2
domRect.x = code;
3
node.copyFromChannel(dst, 0, 0);
4
intView[0] = intView[0] + 0xe + 0x100;
5
node.copyToChannel(dst, 0, 0);
6
exported();
7
exported();

The exploit overwrites dispatch-linked code flow to redirect execution to sprayed shellcode.

Question 1: Initial attack vector#

Q: What was the initial attack vector used by the adversary, and through which protocol was it delivered?

Answer:

1
The attack began with a phishing email retrieved via POP3 that contained a malicious link.
2
Following the link directed the victim to an adversary-controlled page hosted over HTTP at
3
http://34.250.131.104/

Analysis:

• The packet sequence shows mailbox interaction over POP3 before the malicious browsing event, indicating email-delivered lure activity rather than drive-by exploitation.
• Shortly after POP3 activity, the victim issues an HTTP request to 34.250.131.104, where the malicious HTML/JS exploit is delivered.
• This ordering (POP3 -> user click -> HTTP exploit fetch) supports phishing as the initial vector and HTTP as the exploit delivery protocol.

Key Indicators:

• POP3 session activity preceding exploit traffic.
• HTTP GET to attacker-hosted page at http://34.250.131.104/.
• Temporal correlation between email retrieval and malicious page access.

Question 2: Protocol used to notify exploitation success#

Q: What protocol has been used to notify that the exploit was successful?

Answer:

1
ICMP

Analysis:

• After loading the malicious page from 34.250.131.104, the exploit reaches command execution through WinExec with embedded command string ping db.
• This command does not require HTTP callback or DNS exfiltration payload staging; instead, it generates direct ICMP echo traffic as a low-noise success beacon.
• In the packet timeline (export.txt), ICMP echo requests and replies appear immediately after the exploit execution phase, matching expected ping behavior.

Key Indicators:

• Victim host starts sending Echo (ping) request packets right after exploit trigger.
• Corresponding Echo (ping) reply packets confirm target reachability.
• Timing correlation between exploit execution and ICMP burst provides strong attribution of ICMP as the success notification channel.

Question 3: Related CVE#

Q: What CVE is related to this vulnerability?

Answer:

1
CVE-2024-5830

Analysis:

• The delivered script contains a V8 renderer exploitation pattern based on object confusion and sandbox escape primitives, matching public technical characteristics of CVE-2024-5830.
• The chain uses memory corruption primitives, TrustedCage dispatch hunting, and WebAssembly-assisted execution redirection consistent with this CVE family.
• The exploit comment context and shellcode strategy further corroborate that mapping.

Key Indicators:

• DOMRect / AudioBuffer confusion primitives in JavaScript.
• TrustedCage dispatch map scan (0x1f8d) and import table pivot.
• WebAssembly and JIT-assisted payload execution flow.

Question 4: Specific assembly instruction enabling final command string execution#

Q: Which specific assembly instruction helps enable the execution of the final command string?

Answer:

1
mov byte ptr [rcx + 8], 0

Analysis:

• The shellcode calculates the command pointer using mov edx, 0x252 followed by add rcx, rdx, which places rcx at the command-string location.
• WinExec expects a null-terminated command string (lpCmdLine). If the terminator is missing, adjacent sprayed bytes can be interpreted as part of the command and break execution.
• The instruction mov byte ptr [rcx + 8], 0 explicitly writes a null byte at the boundary of the 8-byte command region, ensuring safe and deterministic API parsing.
• This is why it is the instruction that helps enable successful execution of the final command string.

Key Indicators:

• Pointer setup sequence: mov edx, 0x252 -> add rcx, rdx.
• Boundary write: mov byte ptr [rcx + 8], 0.
• Immediate follow-up execution path to WinExec via indirect call rax.

Question 5: Final stage delivery technique#

Q: What technique has been used to deliver the final stage of the payload within the exploit?

Answer:

1
JIT Spraying

Analysis:

• The exploit stores payload bytes inside WebAssembly constants, then leverages JIT compilation to materialize those bytes in executable memory regions.
• Reconstructing immediate values from the WASM body yields contiguous x64 shellcode fragments, which is the hallmark behavior of JIT spraying.
• This technique enables in-memory staging of final code without writing an executable payload to disk.

Key Indicators:

• Repeating f64.const chunk pattern inside wasmBuffer.
• Reconstructed shellcode stream from 8-byte chunks.
• Direct transition from JS/WASM primitives to native instruction execution.

Question 6: Function used to execute final command#

Q: Which custom or native function has been called to execute the final command in the exploit?

Answer:

1
WinExec

Analysis:

• Disassembly shows module discovery via PEB/LDR traversal, a common shellcode pattern for API resolution without import table dependencies.
• The shellcode computes an absolute function pointer by adding 0x707d0 to a discovered module base and then transfers control through call rax.
• Given the execution context and argument preparation sequence, this resolved target corresponds to WinExec.

Key Indicators:

• Pointer walk instructions against process loader structures.
• add rax, 0x707d0 before final indirect call.
• Indirect invocation path (call rax) after command pointer setup.

Question 7: Full command executed at the end#

Q: What is the full command executed at the end of the exploit?

Answer:

1
ping db

Analysis:

• The final reconstructed 8-byte payload chunk is 70 69 6e 67 20 64 62 00.
• ASCII conversion gives p i n g [space] d b \0, i.e., ping db with explicit null termination.
• This command choice aligns with observed post-exploit ICMP activity, validating both static and behavioral evidence.

Key Indicators:

• Final shellcode chunk: 70696e6720646200.
• Decoded command string: ping db.
• Runtime corroboration through ICMP ping traffic.

Question 8: Offset added to retrieve command string#

Q: What is the offset value added to a register to retrieve the command string?

Answer:

1
0x252

Analysis:

• The shellcode loads 0x252 into edx and immediately applies it to the base command pointer register via add rcx, rdx.
• This is a direct offseting operation used to reference the embedded command-string region in memory.
• The subsequent null-termination and API call flow confirms this offset is specifically tied to command retrieval.

Key Indicators:

• mov edx, 0x252.
• add rcx, rdx command pointer derivation.
• Follow-on mov byte ptr [rcx + 8], 0 and call rax sequence.

Question 9: Structure searched for import/dispatch table#

Q: Which structure/location does the exploit search to find the import/dispatch table?

Answer:

1
dispatch_table_from_imports

Analysis:

• The exploit explicitly labels and searches for the dispatch/import target using findImportTarget().
• It scans memory for marker 0x1f8d starting at 0x40600, which is used to locate the dispatch_table_from_imports region within the TrustedCage-related memory layout.
• This location is then used to redirect execution flow into attacker-controlled code paths.

Key Indicators:

• Commented reference to dispatch_table_from_imports in script.
• Marker-based scanning logic (0x1f8d).
• Start offset 0x40600 feeding dispatch pivot logic.

Question 10: V8/DOM object confusion pair#

Q: Which two V8/DOM object types does the exploit confuse?

Answer:

1
DOMRect and AudioBuffer (Float32Array channel data)

Analysis:

• The payload instantiates DOMRect and AudioBuffer, then manipulates cross-object state to produce invalid type assumptions and memory aliasing.
• Channel-backed typed-array operations are used to read/write memory through corrupted object relationships.
• This confusion pair is the core primitive enabling the later TrustedCage and dispatch-table stages.

Key Indicators:

• Explicit new DOMRect(...) and new AudioBuffer(...) creation.
• getChannelData(0) and typed-array based memory manipulation.
• Cross-object pointer pivoting prior to dispatch redirection.

Evasion and execution techniques used in this exploit chain#

1. Phishing-to-browser pivot: Initial access uses social engineering (email lure) rather than binary delivery, reducing endpoint signature opportunities.

2. In-browser exploitation path: The chain stays inside browser renderer context and leverages JavaScript + WebAssembly primitives before native API invocation.

3. TrustedCage dispatch abuse: The exploit scans memory for a dispatch marker (0x1f8d) and pivots execution by manipulating import/dispatch structures.

4. JIT spraying for shellcode staging: Shellcode bytes are embedded as WASM immediates and materialized in executable JIT memory, avoiding traditional dropped payload artifacts.

5. Runtime API resolution: The shellcode resolves WinExec dynamically using loader structure traversal and an RVA add (+0x707d0), reducing static IOC exposure.

6. Minimal proof command design: The command ping db is compact, null-terminated in memory, and behaviorally verifiable through ICMP without requiring noisy second-stage download traffic.

Investigation-specific observations#

1. Evidence-first validation is critical: Public exploit assumptions (for example, calc.exe) were incorrect for this artifact. Byte-level extraction from provided PCAP gave the true command.

2. Command extraction requires reconstruction: The final command is not obvious in raw script text due to JIT/WASM encoding flow; chunk reconstruction and disassembly are necessary.

3. Behavioral corroboration strengthens confidence: Static shellcode decoding (ping db) matched dynamic network outcome (ICMP burst), closing the loop across host and network perspectives.

Defensive Takeaways#

1. Monitor suspicious email-to-browser pivots. Alert when POP3/IMAP retrieval is followed by outbound browsing to newly seen or low-reputation hosts.

2. Hunt for abnormal browser exploitation signals. Correlate sudden renderer instability, unusual WASM-heavy pages, and anomalous post-page network behavior.

3. Detect low-noise success beacons. ICMP bursts to internal hostnames immediately after suspicious web sessions can indicate exploit proof execution.

4. Strengthen web isolation and exploit mitigations. Keep browser versions current, enforce isolation/sandbox hardening, and reduce direct endpoint exposure to untrusted web content.

5. Use layered detections, not single indicators. Combine network telemetry, script analysis, memory behavior, and timeline analytics for browser exploit response.