Reading the extortion economy: what TamperedChef and ROADtools tell defenders

Three telemetry signals, each multi-gated against false positives, correlated into one extortion-chain verdict.

The decisive design choice in this tree is the same one that governs our scanner: every signal is multi-gated. A signed binary alone is not an alert, because signed binaries are the norm. A vulnerable kernel version alone is not an alert, because lots of hosts run old kernels safely. A Graph API call alone is not an alert, because legitimate admin tooling calls Graph constantly. The alert fires on the conjunction: a signed binary whose certificate matches a reuse cluster, on a host whose kernel is in range and showing escalation behaviour, followed by an identity-recon burst from the now-privileged principal. Any one signal is noise; the chain is the signal.

Signal A: instrumenting signing-certificate reuse

TamperedChef is interesting to defenders not because the malware is novel but because Unit 42 clusters the activity by certificate and code reuse. The operators sign their tooling, and the certificates recur across what would otherwise look like unrelated campaigns. That recurrence is the detection.

The instrumentation has three parts. First, ensure your EDR captures the signer identity on every binary-execution event: the certificate thumbprint, the subject, the serial, and the validity window. Most modern EDR does this; the gap is usually that nobody queries it. Second, maintain a denylist of certificate serials and thumbprints associated with known TamperedChef clusters, refreshed daily from threat-intel feeds (Unit 42's timely-threat-intel publishes cluster indicators). Third, add a behavioural heuristic for certificates you have never seen: a binary signed by a publisher that appeared in the last N days, or that has fewer than a handful of prior signing events in your environment, is suspicious in a way a long-established Microsoft or Adobe signer is not.

# Pseudocode — signed-binary delivery heuristic (EDR query)
for evt in binary_execution_events(window="24h"):
    cert = evt.signer            # thumbprint, serial, subject, not_before
    signals = 0
    if cert.serial in tamperedchef_reuse_denylist:   signals += 2   # strong
    if cert.not_before > now() - days(14):            signals += 1   # new signer
    if prior_sightings(cert.thumbprint) < 5:          signals += 1   # rare signer
    if signals >= 2:
        alert("signed-trojan delivery", host=evt.host, cert=cert, evt=evt)

The denylist hit is weighted to fire on its own; the new-signer and rare-signer heuristics are deliberately weak individually and only combine into an alert together, so a legitimate newly-onboarded internal signing certificate does not page anyone. The key operational point: a code-signing certificate is a durable cluster key. Once you have it, it detects every binary the cluster signs, across every campaign, until the operators rotate, and rotation costs them money, which is exactly the asymmetry you want.

Signal B: instrumenting the copy_file_range LPE

CVE-2026-31431, the copy_file_range flaw Unit 42 covers in "Copy Fail," is a Linux kernel out-of-bounds primitive (CWE-787) that takes an attacker from local code execution to root. It matters most on container and orchestrator hosts, where a container escape plus a root LPE is the difference between "compromised one pod" and "compromised the node and everything scheduled on it."

There are two complementary instrumentations. The first is purely inventory-driven and free: enumerate the kernel version on every host and flag anything in the vulnerable range against the published advisory band. This is a surface assessment, not a detection: it tells you where the primitive could be used, which is where to prioritise patching and where to watch hardest. The second is behavioural: watch for the syscall and audit-log signature of exploitation, an unusual burst of copy_file_range calls coupled with an unexpected privilege transition (a setuid that should not happen, a process that gains capabilities it was not granted). Gate the alert on both: the host is in the vulnerable kernel range and the behavioural signature fires.

# Surface check (inventory) — where could copy_file_range LPE be used?
#   FAIL/PRIORITISE if kernel in [5.10 .. 6.6.49] AND host is a
#   container / orchestrator node (k8s kubelet, containerd, docker).
# Behavioural detection (auditd / eBPF) — is it being used now?
#   ALERT if: copy_file_range syscall burst from a non-root process
#             AND a subsequent uid==0 transition for that lineage
#             AND host kernel-version-in-range (surface gate).

The surface check is the cheap win: it runs against the host-inventory you already keep and turns a CVE advisory into a prioritised patch list scoped to the hosts where the bug actually bites. The behavioural detection is the higher-fidelity layer for the hosts you cannot patch immediately. Together they cover both "where is the risk" and "is it being exploited right now," and the version-in-range gate keeps the behavioural alert from firing on a patched host where the same syscall pattern is benign.

Signal C: instrumenting cloud-identity reconnaissance

ROADtools is the one that most defenders under-instrument, because it operates entirely in the cloud control plane where endpoint EDR cannot see it. It is a legitimate open-source Azure AD / Entra ID exploration framework, the same tool red teams and researchers use, pointed at a compromised tenant to map the identity estate: users, groups, directory roles, application registrations, service principals, and the over-permissive app registrations that are the real prize. Unit 42's "Paved With Intent" documents nation-state operators using exactly this tradecraft, and the criminal extortion crews have adopted it because it works.

The detection lives in cloud audit telemetry, not on the host. ROADtools recon has a characteristic shape: a single principal issues a burst of Microsoft Graph and Azure AD directory-enumeration calls in a short window, reading /applications, /servicePrincipals, /directoryRoles, /users, and /groups at a volume and velocity that a human admin doing normal work does not produce. The multi-gate: a high-volume enumeration burst and reads of the sensitive directory-structure endpoints and, ideally, correlation to a principal that is also implicated by Signal A or B.

# Cloud-recon detection (Entra ID / Graph audit logs)
#   ALERT if a single principal, within a short window:
#     • issues > T enumeration calls (tune T to your tenant baseline)
#     • reads /applications + /servicePrincipals + /directoryRoles
#       + /users at directory scale
#     • is NOT on the known automation / SOC-tooling allowlist
#   ESCALATE if the same principal surfaces an over-permissive app reg
#     (Mail.ReadWrite + offline_access + Directory.ReadWrite.All,
#      no Conditional Access, signInAudience = AzureADMultipleOrgs)

The over-permissive app-registration finding is worth special attention because it is both a detection signal and a standing risk. An app registration that requests Mail.ReadWrite, offline_access, and broad directory write scopes, with no Conditional Access policy gating it, is precisely what ROADtools-style recon hunts for: it is a persistence and exfiltration primitive an attacker can abuse without ever touching an endpoint again. Finding and removing those app registrations is a hardening action; watching for the recon that hunts them is a detection. Do both.

A composite real-world scenario

The setting is a mid-market manufacturer with a hybrid estate: Windows and Linux servers on-premises, a fleet of container hosts running a Kubernetes platform, and an Entra ID tenant fronting Microsoft 365 and a handful of line-of-business SaaS apps. The SOC runs EDR on endpoints and ships Entra sign-in and audit logs to a SIEM, but the three feeds are not correlated: each is a separate dashboard nobody watches in real time.

The intrusion begins with a signed installer delivered by a contractor's phished mailbox. The binary is signed with a certificate that, unknown to the SOC, recurs across a TamperedChef cluster. Signal A would have fired, since the certificate serial is on a published reuse denylist, but the EDR captured the signer metadata and nobody queried it. The implant lands on a Linux container host. The kernel is 6.6.31, squarely in the copy_file_range vulnerable range. The attacker runs the LPE, escalates to root on the node, and now controls every workload scheduled on it. Signal B's surface check would have flagged that host as a patch priority weeks earlier; the behavioural detection would have caught the syscall-plus-privilege-transition burst. Both were absent.

From the compromised node the attacker recovers a service-principal credential mounted into a pod and authenticates to the Entra tenant. They run ROADtools-style enumeration: a burst of Graph calls reading applications, service principals, directory roles, and users. Signal C would have fired on the enumeration burst from a service principal that normally does nothing of the kind. They find an over-permissive app registration with mailbox read-write and no Conditional Access, and they use it to stage exfiltration. Days later the extortion note arrives: data theft, not encryption (T1657), exactly the economy Unit 42 describes.

Every step of that chain emitted a signal the SOC already collected. The failure was not visibility; it was correlation. Each feed saw its slice and none of them connected A to B to C. The decision tree above is the correlation the SOC was missing, and the multi-gate on each signal is what would have let them run it without drowning in false positives.

What to do about it: the detection contract

We summarise the instrumentation as a contract your detection program should satisfy. Six controls, each mapped to one of the three signals or to the correlation that ties them together.

Commodity tooling reuses certificates, code, and tradecraft. Reuse is detectable by definition. The attacker's economy of scale is your signature of scale, if you instrument the middle of the chain.

The instrumentation, in concrete terms, is a set of queries against telemetry you almost certainly already retain: EDR binary-execution events with signer metadata, host inventory with kernel versions, and Entra/Graph audit logs. None of the three signals requires a new sensor. What they require is the query, the multi-gate, and, the part most programs are missing, the correlation rule that turns three separate dashboards into one chain verdict.

How Celvex contributes to this

We are honest about the boundary. CelvexGroup's external validation finds and proves the standing risks that the extortion economy exploits: the exposed vulnerable kernel surface, the over-permissive app registration, the management-plane exposure that grants initial access. The behavioural detections in this piece, the EDR certificate query, the syscall-burst alert, the Entra recon correlation, live in your SOC's telemetry, not on our external scan. What we ship is the half of the problem that an external attacker sees first, and a Proof Capsule that hands your SOC the context to wire up the rest. The two halves are complementary: we close the doors the crews walk through, and the detection contract above catches them when they find one we did not get to first.

Bottom line

The cyber-extortion economy runs on commodity tooling, namely TamperedChef's reused signing certificates, the copy_file_range LPE, and ROADtools' cloud-identity recon, and the steal-and-extort model Unit 42 documents is harder to recover from than encryption ever was. But commodity is the defender's opportunity, not the attacker's. Reuse is detectable by definition; the signal lives in telemetry you already collect; and the middle of the kill chain, where these tools operate, is where detection is cheapest and dwell time longest. Instrument the three signals, multi-gate each one against false positives, and, the control most programs are missing, correlate them into a single extortion-chain verdict. Until you do, every one of those signals is a dashboard nobody is watching, and the chain runs to completion in the gap between them.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held. That is what we ship.