At 11:35 UTC on 24 October, an attacker rooted the firewall management server of a US government-affiliated organization, according to Dream. That server stored an LDAP service account password, because it had to log VPN users in to Active Directory. With root access, the attacker decrypted the password and listed every user and group in the domain.
That server is a DevOps security problem. DevOps security protects the people, tools and automated systems that build, run and update software. This article reads three attacks from October 2026 through one question: which automated system in the middle held standing authority, and what did it fail to check? The answer gives a team an order for its controls.
What Is DevOps Security?
DevOps teams write code, ship it and run it in production, often with the same small group of engineers. DevOps security covers that whole loop. Code scanning and keeping CI/CD secrets out of repositories are the familiar parts. The cases below sit on the operator side, which has four parts:
- Privileged endpoints: the laptops of engineers who can reach production, and the editor extensions that run on them, as the trojanized Claude Code extension in Cursor’s marketplace showed.
- Signing and release services: anything that signs transactions, builds or packages.
- The management plane: admin web interfaces, APIs and consoles for firewalls, clouds and servers.
- Update mechanisms: the unattended processes that put new code onto a running system.
One Weak Point, Tested Case by Case
The claim to test is this. In each case, an automated system between people and production held standing authority: it could sign, log in to the directory, or write files the web server runs. It did not check whether the request, or its own temporary state, was legitimate. The evidence supports that claim to different degrees.
Binance: A Signing System That May Have Signed on Request
Binance said a compromised DevOps engineer’s laptop “may have been the entry point”. It said this potentially let an attacker reach a service container and submit unauthorized withdrawal transactions. It found no evidence that wallet private keys leaked. Our Binance incident analysis covers the rest of the case.
TRM Labs writes that “the most likely explanation” is that the attacker could make Binance’s hot wallet signing system sign transactions of its choosing. One Ethereum transaction carried 50 pre-signed authorizations, one per transaction count, and one matched. TRM says the batch suggests the access was limited in time, or that signatures had to be requested through a system.
Either reading fits the mechanism. A signer produced 50 authorizations across a range of counts, a request TRM says should be treated as an indicator of compromise. Binance has not published a root cause, so this case supports the claim only as a likely explanation.
An earlier TraderTraitor case gives firmer evidence. Japan’s National Police Agency says the group posed as a LinkedIn recruiter in March 2024 and sent a wallet software employee a Python script disguised as a pre-employment test. In May it used session cookie data to impersonate that employee. It then tampered with a legitimate DMM Bitcoin transaction request, causing a loss of 4,502.9 BTC.
In the Bybit theft of February 2025, Bybit said “the credentials of a Safe developer were compromised.” That access let the attacker “totally deceive signers into approving a malicious transaction.” In both cases the signing flow accepted a request it could not tell apart from a real one. Our TraderTraitor group profile covers the group’s wider methods.
PHP2Shell: A Management Server With a Reusable Directory Login
Unit 42 says the PHP2Shell flaws are actively exploited against PAN-OS management interfaces exposed to the internet. Dream reports that one attacker found about 19,000 such interfaces with the FOFA search engine. About 5,000 answered a version scan, 240 matched its targets, and an automated batch rooted 24. Unit 42 says it independently verified the attacker’s tooling and confirmed the reported results.
The middle system here is the internal management server from the opening. It held standing authority over the directory for a routine job, and Dream says the stored password was encrypted, “but with root access the attacker has the master key.” Dream cannot tell whether later password spraying, backdoor accounts or SAML key theft worked. Our PHP2Shell product status page lists the fixes.
WordPress 7.1.4: An Updater That Left an Installer Within Reach
A self-updating CMS is not a CI/CD pipeline, but its updater is privileged automation that changes production code unattended. WordPress 7.1.4 fixes a weakness that “can lead to remote code execution during the upgrade window.” Wordfence explains that a full core update unpacks the installer into a predictable directory under wp-content/upgrade. On many servers that directory is reachable from the web.
Here the temporary state is the problem. The updater did not check that its staging copy was out of reach while it worked. The window lasted only seconds in Wordfence’s lab, and Wordfence reports exploitation attempts, not confirmed compromises. Our WordPress 7.1.4 update guide covers branches and checks.
| Question | Binance | PHP2Shell | WordPress 7.1.4 |
|---|---|---|---|
| Middle system | Hot wallet signing system. | Internal firewall management server. | Core updater. |
| Standing authority | Signs withdrawals. | Stored LDAP login for VPN users. | Writes files the web server runs. |
| What went unchecked | Possibly whether each signing request was legitimate (our reading of TRM’s most likely explanation). | Who could use the stored login once the server was rooted. | Whether the staging copy was reachable from the web. |
| Outcome reported | Unauthorized withdrawals; Binance estimates about $6.3 billion impact. | Every directory user and group listed. | Exploitation attempts; no confirmed compromises reported by Wordfence. |
Where the Pattern Does Not Hold
These three cases were chosen because they surfaced in the same week, so they are not a sample. Their actors differ. TRM attributes the Binance theft to North Korea’s TraderTraitor, Dream reads PHP2Shell as Chinese-nexus, and the WordPress probing is unattributed by Wordfence.
Their entry points also differ: a possible endpoint compromise, a PHP flaw in an exposed interface chained to a kernel flaw, and a race condition. The PHP2Shell server was taken by an exploit, not fooled by a request, and in WordPress no successful attack has been reported. So the pattern is not evidence of a trend but a way to rank controls: find automated systems with standing authority and ask what each fails to check.
Prepared Slowly, Executed Fast
Speed is often quoted as one number. These cases give three different measures, and they point in different directions.
- Attacker preparation took days or weeks. Brandefense’s own on-chain trace shows the Binance operator wallet funded through Tornado Cash from 07:39 UTC on 28 October, about 36 hours before the theft. Dream’s PHP2Shell timeline starts with setup on 8 October, and the first government firewall was rooted on 23 October.
- Execution after the foothold took minutes. TRM says most of the roughly $6.36 billion moved in about 20 minutes. Dream says the management server fell less than 90 minutes after the edge firewall.
- Defender response came fast where a third party could act. Tether froze 971.1 million USDT in the main receiving wallet 37 minutes after the main sweep, according to TRM.
In our reading, the Binance and PHP2Shell attacks were prepared slowly and executed fast. The Wordfence figure is a different kind of number: its first rule match came nine minutes after the rule went live. That is the time to first detection, not time to compromise. Defenders also have an earlier window: removing exposure and catching recruitment lures before the fast phase starts.
Where Does AI Fit, and What Is Only Assumed?
Fast attacks invite the assumption that AI did the work, so the evidence matters. Dream found that Claude Code had been installed on the attacker’s infrastructure. It also found an offensive security platform called aiscan configured with the Chinese models DeepSeek and Kimi. Its session logs held user messages in Chinese.
Dream is careful about what this proves. It says it has “no direct evidence that the AI tools were specifically used to write the exploit or the post-exploitation scripts.” It adds that the style of about 40 scripts suggests AI-assisted development. It also says the operation “does not appear to be a fully autonomous nation-state attack.”
For Binance, no investigator has reported AI use, and Binance has not said how the laptop was compromised. Our earlier coverage raised AI-assisted reconnaissance only as a Brandefense hypothesis. In our assessment, the 50 pre-signed authorizations point to careful human planning. Wordfence’s WordPress report does not mention AI.
AI tools sat on one attacker’s systems, and Dream reads the script style as AI-assisted. No source shows that AI wrote the exploit, and none reports AI use at Binance or in the WordPress attacks. The controls below work either way.
A DevOps Security Checklist, in Order
The order follows the mechanism. Exposure comes first because it needs no credentials and is found in bulk: Dream’s funnel went from 19,000 search results to 24 rooted firewalls. In the PHP2Shell case, that exposure led to the identity system. Request checks come next, because they limit damage whatever the entry point.
- Take the management plane off the internetRemove public access to firewall, hypervisor and cloud admin interfaces. Unit 42 advises trusted internal IP addresses only; Palo Alto’s advisory adds a jump box as the only system allowed in.
- Make the signer check each requestThe signing service should match every request to an approval record kept outside the system that submits it. Reject authorization types you do not expect, as TRM advises for EIP-7702.
- Treat directory logins on management servers as tier-0Give LDAP bind accounts on management servers the least privilege they need. Protect those servers like domain controllers, and keep them off the network path of internet-facing devices.
- Close the update pathBlock web access to update staging directories while updates run. Keep CI/CD and deployment secrets in a secrets store, not in pipeline files or code.
- Harden privileged endpointsGive engineers with production access managed, monitored laptops. CISA says TraderTraitor sends fake job offers that push targets to download trading apps.
- Watch preparation, then rehearse the first hourAlert on unexpected code appearing at wallet addresses, new exposure and unusual signing requests. Decide in advance who can freeze, revoke or isolate, and test it.
Write these owners and actions into your incident response plan. For step one, External Attack Surface Management lists which admin interfaces answer from the internet, the kind of view a FOFA search gives an attacker.
A good first move this week is one question for each team. Which automated systems in our stack can sign, log in or deploy on their own, and what do they fail to check? The answer is your DevOps security backlog.