Real breaches, each put through the same four questions: one control that worked, one that did not, one number worth watching, and what should have been done instead. Every entry cites a primary source, because the point of this section is that you can take it to a meeting.
NO. 27/Cross-sector/12 September 2026
Twenty-one agencies, eleven countries, and the logs were deleted
CISA Advisory AA25-239A, Countering Chinese State-Sponsored Actors Compromise of Networks Worldwide to Feed Global Espionage SystemCVE-2024-21887CVE-2024-3400CVE-2023-20273CVE-2023-20198CVE-2023-46805CVE-2018-0171
Twenty-one agencies from eleven countries put their seals on this advisory, which is the first thing to notice about it. PRC state-sponsored actors have been inside telecommunications backbone routers, provider edge and customer edge routers since at least 2021, and have used those compromised devices and their trusted connections to pivot into further networks. The named sectors are telecommunications, government, transportation, lodging and military infrastructure. The equipment spans Cisco IOS XE, NX-OS and IOS XR, Palo Alto PAN-OS and Ivanti Connect Secure, with Juniper, Fortinet, Nokia, Sierra Wireless and SonicWall suspected. What is taken is call data logs, a limited number of private communications, and material subject to court-ordered law enforcement requests.
What worked
The advisory does not say. It notes a single case in which "The APT actors were stopped before further actions could be taken" and gives no account of how, which is the only defensive outcome in the whole document.
What failed
The evidence, deliberately. This is the entry in this section where the forensic failure is the finding.
The actors modify access control lists to add their own IP addresses, so their traffic is permitted by policy rather than hidden from it. Then they disable logging, stop logs reaching central servers, delete and clear what is on the device, and revert configuration files so the modifications leave no trace. An investigation that starts on the router starts with nothing.
Underneath that sit the ordinary failures the advisory describes as avoidable. Five exploited vulnerabilities, the oldest from 2018, all with patches available. Weak and default SNMP community strings. TACACS+ and RADIUS traffic in cleartext or weakly protected forms. Cisco Type 5 and Type 7 password storage where Type 8 belongs. Management services listening on the internet. Guest Shell enabled on devices that have no use for it, which the advisory notes is "not monitored closely".
The number
21 agencies
from eleven countries co-sealed this advisory, which is a fair proxy for how widely the same actors were found in the same kind of equipment.
What to do instead
Get the logs off the device first, before anything else on this list. The actors’ entire evasion strategy is to control what the router remembers, and it only works while the router is the only place that record lives. Forward to a central server with immutable storage and a retention period long enough to investigate with, at informational level or better, and treat a device that stops sending as an incident rather than as a monitoring gap.
Then move the management plane out of reach. CISA’s wording is to place every management service, SSH, HTTPS, SNMP, TACACS+, RADIUS, SCP and SFTP, strictly into a dedicated out-of-band management network or a management VRF. That one change removes most of what the rest of the advisory describes.
Then patch the five and fix the defaults. CVE-2024-21887, CVE-2024-3400, CVE-2023-20273, CVE-2023-20198 and CVE-2018-0171 are the priority list. Change every weak and default SNMP community string and move to SNMPv3 only. Switch to Type 8 password storage. Require public-key authentication for administrators and disable password authentication where you can. Turn off Guest Shell and Smart Install.
And audit the configuration as a detection rather than as housekeeping. An access control list carrying an address nobody recognises, an unexpected tunnel, a new SPAN or ERSPAN session, a packet capture command, a TACACS+ redirect: each is a specific thing to go and look for, and not one of them will alert on its own.
A search for monitoring software, and ransomware forty-four hours later
The DFIR Report, From Bing Search to Ransomware: Bumblebee and AdaptixC2 Deliver Akira
A user searched Bing for ManageEngine OpManager and was lured to opmanager[.]pro, a lookalike domain, where they downloaded a trojanised MSI. It dropped the Bumblebee loader, which called home. Five hours later the operator deployed an AdaptixC2 agent, created domain accounts with Enterprise Admin privileges and installed RustDesk. Over the next two days they moved by RDP to a domain controller, used wbadmin to extract the NTDS.dit Active Directory database, and pushed roughly 77GB out to a server in Ukraine across two transfer sessions of about four and a half hours each. Akira ransomware landed approximately 44 hours after initial access, executed 39 times in the child domain, with shadow copies deleted through WMI.
What worked
One detection is recorded and it is worth knowing about: a Sigma rule for system file execution location anomaly fired, because it looks for commonly abused Windows binaries such as consent.exe running outside their normal path. No named control stopped the intrusion, and the report does not claim one did.
What failed
Two days of Enterprise Admin. The report documents the intrusion rather than the defence, so this is read from the timeline rather than from a statement anybody made.
New domain accounts were created with Enterprise Admin privileges on the first day and used for two more. A remote access tool was installed and left running. Two transfer sessions of about four and a half hours each moved 77GB to a single external address. The directory database was extracted with wbadmin, a built-in backup utility. Any one of those is a detection most organisations believe they already have.
CISA’s advisory on this ransomware family puts the pace in context. In some incidents, Akira operators "exfiltrated data in just over two hours from initial access". Forty-four hours was not fast for this actor.
The number
44 hours
from a search result to ransomware, with roughly 77GB exfiltrated and Enterprise Admin accounts created on the first day.
What to do instead
The report carries no mitigations, so these come from CISA’s joint advisory on this ransomware family, which does.
Start with the two that decide the outcome. Offline, immutable backups covering the whole estate, proven by an actual restore rather than by a green tick. And MFA on everything reachable from outside, especially the VPN, which is where this family gets in when it is not a poisoned download.
Then make privilege creation loud. An account added to Enterprise Admins is a handful of events a year in most organisations and it should wake somebody. CISA’s list includes reviewing domain controllers and directories for new or unrecognised accounts, which is the same control read from the other end and much too late.
Then watch the built-in tools. wbadmin against NTDS.dit, vssadmin deleting shadow copies, WMI removing recovery: all administrative utilities doing administrative things, which is exactly why they are used. Alert on the behaviour and accept the false positives, because the true positive is this.
Then segment, and put a clock on administrative access. CISA recommends just-in-time access for admin-level accounts, which turns two unattended days of Enterprise Admin into a window somebody had to ask for.
And give people a software catalogue. This began with a search engine, a lookalike domain and an installer, which is the same opening as two other entries in this section.
Huntress, Post-DEF CON Phishing Uses Malicious Google Doc to Deliver Malware
On 9 August an account impersonating a CoinDesk executive direct-messaged a Huntress researcher, asking for help organising an online conference and sharing a Google Doc. The document carried a custom Apps Script sidebar offering an encryption key, which failed to decrypt anything as promised and then presented ClickFix-style instructions and a manual download instead. A second document arrived the next day dressed as a DocSend share. Huntress assesses that a large number of Black Hat and DEF CON attendees were targeted, on both macOS and Windows.
What worked
Huntress names no control that blocked this, and the researcher did not execute the payloads, so there is no defensive outcome to report. Two of the attacker’s own mistakes are recorded instead. The macOS ClickFix command redirected to a local address and looped 108 times before the browser gave up, leaving that vector non-functional. And both stolen code-signing certificates, from Discord and from Lenovo, produce signatures that do not validate.
What failed
The certificate store, which is the part of this to take away. The Windows chain installs a fraudulent certificate authority into the system root store with a ten year validity, which lets the operator intercept HTTPS traffic, and Huntress observed it used against VirusTotal. A machine that trusts an attacker’s certificate authority is a machine whose encrypted traffic is readable and whose security lookups can be answered by the person it is looking up.
The rest is the familiar shape. Users were instructed to bypass Gatekeeper on macOS. Stolen certificates from real companies were used even though they no longer validate, because hardly anybody checks. And the implant silently discards every error condition, which Huntress describes exactly: "A dead server, a rejected host, and a successful compromise all produce the same result on screen, which is nothing at all."
The number
10 years
the validity of the fraudulent certificate authority installed into the Windows root store, which let the operator intercept HTTPS traffic including lookups to VirusTotal.
What to do instead
Monitor the trusted root certificate store. Additions are rare, high-signal, and almost never legitimate outside your own management tooling. This is one of the few entries in this section where a single detection would have caught the thing that mattered most.
Then treat a request to bypass a platform protection as the end of the conversation. Huntress puts it as well as it can be put: unexpected requests to run terminal commands, bypass Gatekeeper, install a manual update or enter a device password are each, on their own, enough to stop.
Then say something to staff before a conference rather than after one. This campaign targeted attendees by name and by interest, and the approach arrived through a social platform rather than corporate mail, where none of your controls apply and none of your logging reaches.
And if a machine ran it, the response is larger than what you can see. Isolate it, collect the evidence, reimage. Assume every credential on the machine is gone: revoke active sessions, reset passwords, rotate API keys and other secrets, and check cryptocurrency wallets if there are any. That is Huntress’s own list, and the wallet line is there for a reason.
A decade of poisoned search results, run as a business
The DFIR Report, BengalSEO Part 1: Anatomy of the Operation
The DFIR Report traces an SEO poisoning operation running since at least 2015 out of Rajasthan, India, which ranks fraudulent lure pages high in search results for tax software, antivirus, streaming, gaming and credit card activation. A click enters a traffic distribution system that fingerprints the browser and puts the visitor through a Cloudflare Turnstile or hCaptcha challenge before deciding what to serve. The outcome is either MayaBot malware or a tech support scam phone number. The researchers found 84 active operator GitHub accounts between January 2024 and March 2026, 180 registered domains reachable through one subdomain service alone, and a single Matomo analytics instance tracking 146 unique domains.
What worked
Nothing defensive. This is an infrastructure investigation rather than an incident response, and the nearest thing to a win in it is a hosting provider suspending an account, which took part of the operation offline. The detail worth keeping is how it was unpicked: the operators’ own GitHub commits exposed email addresses that tie them to registered business entities. Poor operational security on the attacker’s side is not a control anybody can deploy, but it is the reason this report exists.
What failed
The trust people place in the top of a search results page, which nothing at your perimeter touches.
The operation also sits on infrastructure you cannot block wholesale. Cloudflare fronts 81.1% of it, and lure pages are hosted on GitHub and Google Sites, which are services your staff need for work. Blocking the hosting means blocking the business.
And the CAPTCHA at the front is not what it appears to be. It is not there to keep bots off the operators’ site. It is there to keep your tooling out, filtering automated scanners so that a sandbox sees a benign page and a person sees the lure.
The report carries no mitigations at all, which is honest for a Part 1 about attribution rather than defence, and is why the section below cites a second document.
The number
146 domains
tracked through a single one of the operation’s analytics instances, alongside 84 operator GitHub accounts active between January 2024 and March 2026 and 180 registered domains behind one subdomain service.
What to do instead
The report offers none, so these come from the FBI’s June 2026 public service announcement on malicious traffic distribution systems, which describes the same mechanism.
For organisations the FBI lists four things: monitor endpoints, change default file associations so that a downloaded script does not execute on a double click, run user training and awareness, and audit and patch your web hosting administration, because a compromised site of yours is what feeds a system like this in the first place.
Then the one that matters most for a workforce, which is not on anybody’s list because it is not a security control. Publish the canonical download location for every application you support and make it easier to reach than a search. This entry and the counterfeit installer campaign elsewhere in this section are the same failure approached from two directions, one as consumer fraud and one as enterprise compromise.
Then treat a CAPTCHA gate in front of an unexpected download as a signal rather than an obstacle. It exists to make sure your sandbox never sees what your user sees, so a page that challenges automation before serving a file is telling you what it thinks of automation.
And expect your own estate to end up as somebody’s infrastructure. This operation runs on legitimate services throughout, and a hosting provider suspension is what ended a slice of it.
Paste this into Terminal to prove that you are human
Microsoft Threat Intelligence, TerminalFix campaign deploys a reverse tunnel through multistage intrusion
A compromised website shows a fake Cloudflare CAPTCHA that asks the visitor to copy a command and paste it into Windows Terminal or PowerShell. The command pulls down a ZIP holding a legitimate Windows binary and a malicious dui70.dll beside it, which sideloads. Payload fragments are hidden inside PNG images. It persists through the registry and a scheduled task that re-runs every 60 minutes, enumerates Active Directory, and ends by standing up a reverse tunnel out over 443 that gives the operator "persistent, network-level proxy access through the compromised host". Organisations across multiple industries are affected.
What worked
Microsoft names nothing that stopped it, and is careful about why: it "did not observe the downstream actions described below in the analyzed chain", which is a limit on what the analysis could see rather than evidence that a control held.
What failed
The gap between the clipboard and the shell. There is no exploit anywhere in this chain and no vulnerability to patch. A person was persuaded to run a command and the machine did what they told it to, with their own rights.
ESET’s telemetry puts the scale of that technique beyond any single campaign: ClickFix "skyrocketed by over 500%" in the first half of 2025 and became "the second most common attack vector after phishing". That is an extraordinary position for something which is, mechanically, a paste.
After that, the familiar trust abuses. The malicious DLL rode a legitimate signed Windows binary through sideloading. The payload lived inside PNG files, which Microsoft notes makes "file type and content inspection more difficult". And the tunnel leaves on 443, like everything else on the network.
The number
500%
growth in ClickFix detections in the first half of 2025 in ESET telemetry, putting it second only to phishing as an attack vector.
What to do instead
Configure Windows Terminal to warn when pasted text contains multiple lines. It is one setting, it is in Microsoft’s own list, and it interrupts the precise moment this technique depends on.
Then close the clipboard-to-shell path properly. AppLocker or Group Policy to restrict PowerShell and the Run dialog, an App Control policy that stops native Windows binaries launching from Run, PowerShell Constrained Language Mode, and script block logging so that when somebody does paste something you still have the text afterwards.
Then hunt the sideload. LockScreenContentServer.exe running from a path it does not belong in is a specific and cheap detection, and DLL sideloading in general deserves a rule that does not depend on knowing which legitimate binary gets used next.
Then teach the pattern rather than the campaign. Any page that asks a visitor to copy something into a terminal, a Run box or a browser console is hostile, without exception, regardless of how the page is branded. That one sentence is the defence, and it survives every rename of the technique.
And if a host ran it, treat the tunnel as network access. Microsoft’s guidance is to assume network-level access through the compromised host and rotate every credential reachable from it.
The download site was counterfeit and the tamper protection held
Microsoft Threat Intelligence, Counterfeit installers to system compromise: Tracking a deceptive software download campaign
Counterfeit download sites impersonating well known software vendors served malicious installers to people looking for ordinary applications. Microsoft confirms compromises across medical devices and healthcare, manufacturing, gaming, technology, logistics, government and higher education, primarily affecting China-based operations of multinational organisations and Chinese-speaking users. Once run, the malware persists through scheduled tasks running as SYSTEM, tries to weaken the endpoint’s own protection, deletes volume shadow copies, disables Windows Update, and calls out to attacker infrastructure on a roughly 60 second cadence.
What worked
This is the rare entry where the answer runs long. Microsoft reports that Defender "detected and disrupted activity across multiple stages of the attack, including automated containment through attack disruption". SmartScreen, network protection and web content filtering blocked the fake download domains. Behavioural and cloud-delivered antivirus caught the execution. Network protection blocked the command and control callbacks. Attempted SMB lateral movement to further hosts was blocked. Attack disruption contained the device and the account.
The single load-bearing control was Tamper Protection, and it deserves naming on its own. The malware’s first move against the endpoint was to write broad Defender exclusions through Add-MpPreference and straight into the registry. Tamper Protection refused those writes with the payload already running as SYSTEM. That refusal is the difference between an incident and a compromise.
What failed
The download, and the judgement in front of it. Somebody reached a convincing spoof of a vendor’s own site and ran what it handed them, and nothing before the endpoint stopped that.
After execution the evasion worked as designed, even though the outcome did not. The payload ran under msiexec, a signed and trusted Windows component. It impersonated a Philips speech driver and ran svchost.exe from paths svchost never lives in. It injected into other processes rather than running as itself. More than twenty distinct payload names were written through the msiexec route alone, and two content-distinct copies of an identically named archive landed within roughly 69 seconds, which defeats any rule keyed to a file name or a hash. Microsoft draws the right conclusion: "Hunt behavior, not file names."
The number
69 seconds
between two content-distinct copies of the same-named archive being written to disk, in a campaign that produced more than twenty distinct payload names through a single execution route.
What to do instead
Turn on Tamper Protection everywhere, and verify it is on rather than assuming. It is the control that carried this incident, refusing Defender exclusion and registry writes from a payload that already held SYSTEM. An endpoint agent an attacker can tell to ignore a directory is an endpoint agent with an off switch.
Then alert on the tamper sequence rather than on any one part of it. A scheduled task created as SYSTEM, then shadow copies deleted through vssadmin, then a service disabled, is a short and specific chain that almost nothing legitimate produces. Microsoft names it as the alert to build, and it is cheap.
Then block the delivery. Treat look-alike download archives as malicious in web and mail flow, and correlate the referrer: FileOriginUrl and FileOriginReferrerUrl tell you an executable arrived from a search result rather than from your software catalogue, which is this entire campaign in one field.
Then use the prevalence and age rule. Blocking executables that do not meet a prevalence, age or allowlist test is the attack surface reduction rule matching this exactly, and it is one of the few that stops something nobody has seen before.
And give people a legitimate place to get software. Every counterfeit installer campaign competes with your own software distribution, and it wins whenever yours is slower or needs a ticket.
One remote support session, then the domain controllers
Microsoft Threat Intelligence, Impersonating IT support: how threat actors turn a remote session into enterprise-wide access
First contact is a Microsoft Teams message from outside the tenant, from somebody presenting as IT or the helpdesk, and the ask is a remote support session. Inside that session the operator uses PowerShell to install an MSI quietly, which drops a portable Node.js runtime and an obfuscated JavaScript implant giving persistent command execution. Then host and Active Directory reconnaissance, screenshots, and movement over Windows Remote Management on TCP 5985 to dozens of hosts across multiple regions, aimed at domain controllers and certificate authorities.
What worked
Teams did its part, and Microsoft says so before saying where it ends. The platform applies "external tenant labeling, Accept/Block prompts, message previews, and phishing indicators" at the point of first external contact, and then: "this attack chain depends on convincing the user to bypass those warnings." A warning that is correct, visible and overridden is still a control that worked. The organisations where somebody read it and stopped are the ones that never appear in a write-up.
What failed
The remote session, as a category. Once a person has granted screen control to a stranger there is no further boundary in the chain, and everything after that point is the attacker operating as the user, with the user’s rights, inside a session the user consented to.
CISA made the same observation about a different toolset in its advisory on remote monitoring software, and the sentence generalises: portable executables of legitimate remote access tools "provide a way for actors to establish local user access without the need for administrative privilege and full software installation, effectively bypassing common software controls and risk management assumptions". Your application allowlist is not consulted, because nothing was installed.
Then the management protocol. WinRM on 5985 reached dozens of hosts, which means it was not restricted to management workstations. Microsoft’s remediation list says to restrict it, and WinRM launched from a user-context process is an unusual event with a low false positive rate. That is the one alert standing between a single compromised laptop and the domain controllers.
And everything in the chain was signed or built in. The runtime was a genuine Node.js build from its official distribution, execution ran under msiexec, and staging happened in the user’s own LocalAppData. No unsigned binary was required at any point.
The number
4 years
since CISA first documented help desk themed phishing that ends in a remote access session, in the federal campaign it dated to June 2022. The tooling has changed. The shape has not.
What to do instead
Restrict who can reach your staff. Teams external access left open is the front door here, and scoping it to the domains you actually collaborate with is a change most organisations can make this week and almost nobody notices afterwards.
Then give the helpdesk an identity people can check. An internal verification phrase, or a rule that support is only ever initiated through your own ticketing system and never through a chat message, removes the pretext instead of the payload. Both Microsoft’s list and CISA’s end in the same place, which should tell you where the leverage is.
Then restrict WinRM to authorised management workstations, and alert on WinRM launched from a user-context process. If you take one technical action from this entry, take that one. It is the step where one laptop became dozens of hosts.
Then treat a remote support session as a privileged action with a record. Device or identity checks before the session opens, MFA and a compliant device enforced through Conditional Access, and a log that says who connected to whom and when.
And if it happened, the machine is not the incident. Microsoft’s guidance is to "assume the operator obtained network-level access" and to rotate every credential reachable from the affected host. Reimaging the laptop and closing the ticket is how this comes back.
A million emails, a fabricated thread, and an invoice for fifty thousand dollars
Microsoft Threat Intelligence, Protecting organizations from AI-assisted executive impersonation and invoice fraud
Between 3 and 5 August 2026 an operator sent more than a million phishing emails to enterprise finance staff, from domains registered on 31 July. The messages impersonate the recipient’s own chief executive and ServiceNow, and they carry fabricated invoices inside fabricated email threads built to look like a conversation already under way. 87.7% of the campaign went at US companies, accounts payable departments were the target, and IT services, business advisory and consumer goods were the sectors most hit. The ask is an ACH payment of nearly $50,000.
What worked
Microsoft does not name a control that stopped this before delivery. What it gives instead is a list of tells in the forged material, and the most useful of them is a formatting artefact rather than a linguistic one: the fake quoted thread is left aligned instead of tabbed the way a real mail client renders a reply. That is a property of how the message was produced, so it survives a change of pretext in a way that "watch out for urgent requests from the chief executive" does not.
What failed
The payment process, and nothing before it was ever going to be the answer. A million emails is a volume play that needs one person in accounts payable to act once, and everything that makes it work sits downstream of the mail gateway: a payment instruction that arrives by email, names a plausible counterparty, and appears inside what looks like an existing thread. There is no malware, no attachment that executes and no compromised account, so the entire technical security stack is pointed somewhere else.
The sending infrastructure was three days old. Domains registered on 31 July were sending on 3 August, which asks any reputation-based filter to judge a sender it has never seen, on its first appearance, at volume.
The number
$50,000
the ACH payment requested per targeted organisation, in a campaign of more than a million emails of which 87.7% went to companies in the United States.
What to do instead
Put the control where the money is. This is a fraud against a payment process and no mail filter is the right layer for it. Any change to vendor bank details, and any payment over a threshold you set, gets verified by a call to a number already on file, never a number that came with the request. Write it down as policy, tell accounts payable that it will never be waived for urgency, and mean it, because urgency is the entire pretext.
Then do the mail controls anyway, because they raise the cost. SPF, DKIM and DMARC published properly on your own domain break the impersonation of your own chief executive that this runs on, and Zero-hour auto purge pulls delivered copies back once a campaign is recognised. Both are on Microsoft’s list.
Then teach the artefact rather than the story. Show the finance team a fabricated quoted thread in your own mail client, with the alignment wrong, and let them see it once. A person who has seen the tell recognises the next campaign. A person who has only been warned about invoice fraud recognises only the version they were warned about.
And score sender domain age at the gateway. It is a cheap rule with a high yield, and this campaign’s infrastructure was three days old when it started sending.
Eight years on, the routers are still answering to the community string in the manual
CISA Advisory AA26-194A, Improve Router Hygiene to Protect Against Russian State-Sponsored TargetingCVE-2018-0171CVE-2008-4128
FSB Center 16 actors continue to take networking equipment worldwide, and CISA frames this as a hygiene problem rather than an exploitation one. Two routes carry it. Cisco Smart Install, still reachable on TCP 4786 and still unpatched against CVE-2018-0171. And SNMP agents answering to common or default community strings over SNMPv1 and SNMPv2, which have no meaningful authentication to begin with. What the actors take is configuration, pulled out over TFTP, and the credentials inside it. The sectors named are Communications, the Defence Industrial Base, Energy, Financial Services, Government Services and Facilities with state and local called out specifically, and Healthcare and Public Health.
What worked
The advisory does not say. Like the other hardening documents in this series it describes the exposure and the fix without naming a victim, a detection or a control that held.
What failed
Age, in two directions.
Cisco fixed CVE-2018-0171 in 2018 and CISA is still telling people to disable Smart Install in 2026. SNMPv1 and SNMPv2 were never designed to authenticate anybody, and the community string that gets accepted is frequently the one printed in the manual. Neither of these requires research, tooling or a novel idea.
The deeper failure is the class of device. Routers and switches sit outside most endpoint detection coverage, outside most patch cadences and outside most asset inventories, and a foothold there is underneath the layer that everything above it trusts. The advisory also raises end-of-life hardware, where there is no patch to apply and the honest answer is that somebody has to buy something. That is the part of this that does not get fixed inside a change window.
The number
8 years
since Cisco fixed CVE-2018-0171, which CISA is still naming in 2026 as a live route into critical infrastructure networks.
What to do instead
Disable Smart Install on every device, today. It is a provisioning feature that almost nobody uses past the first day, and it listens on TCP 4786 whether you use it or not.
Then deal with SNMP. Move to SNMPv3 with authPriv, turn off v1 and v2, change the community strings that are still the shipped defaults, and grant read-only where read is all that is needed. If you cannot change version yet, take CISA’s interim position: allowlist the object identifiers that can be read, and write an intrusion detection rule for inbound Set-Requests against the sensitive ones.
Then close the management plane. Access control lists on the management protocols, and block the ports at the edge: UDP 69 for TFTP, TCP 4786 for Smart Install, UDP 161 and 162 for SNMP, TCP and UDP 10161 and 10162 for SNMPv3. A router that answers management protocols from the internet is a router somebody else is also administering.
Then look for what they leave behind. CISA’s detection guidance is to monitor for local account logins on network devices and for credentials that do not match your naming convention. That is a cheap, specific check, and in most organisations nobody has ever run it against the network gear.
And put the end-of-life list in front of whoever signs for capital spend, with this advisory attached to it. On those devices the recommendation is replacement, and pretending otherwise just moves the risk onto next year.
The helpdesk rings your personal phone, and the lure is a passkey
Microsoft Threat Intelligence, Passkey-themed social engineering leads to identity and cloud compromise
Since May 2026 Microsoft has tracked a campaign that opens with a call or a message to the target’s personal phone number from somebody claiming to be the organisation’s IT helpdesk. The pretext is a security improvement: enrol a passkey, re-register your MFA, sort out single sign-on. The link goes to an adversary-in-the-middle page that takes the session. The operator then registers their own authenticator app or phone number as an additional method on the account, and reads: SharePoint, OneDrive and Exchange, at scale, as the person whose identity they now hold.
What worked
Microsoft does not name a control that stopped this. What the write-up establishes instead is where the visibility went, which is more useful here than a detection story would have been, and it is the reason the section below is longer than this one.
What failed
The phone in the victim’s pocket. First contact is to a personal number, which no corporate telephony control touches, and the link is opened on a personal device. Microsoft states the consequence plainly: if the victim opens the phishing link "on a personal mobile device that is not onboarded to Microsoft Defender for Endpoint, the related activity may be absent from endpoint telemetry." The compromise happens entirely outside the estate you monitor and arrives in your tenant looking like a successful sign-in.
Then the second factor. Anything that is not phishing-resistant is relayed straight through the proxy, and device code flow is abused for the same end. The irony of the lure is the finding: the campaign persuades people to enrol a passkey and works precisely because they had not already got one.
Then the persistence, which outlives the password. The operator adds their own authentication methods, so a password reset on its own leaves them signed in and able to come back. Any response that stops at the credential has not ended the incident.
The number
under 1,000
files or emails touched in any one hour by the operator, which sits below the 1,000-event threshold in Microsoft’s own hunting query for this activity.
What to do instead
Phishing-resistant MFA is the answer and the campaign knows it, which is why the lure is a passkey enrolment. Enforce FIDO2 through Conditional Access, and while you are in there block device code flow and authentication transfer flow. Most organisations use neither for anything, and the few people who do can be scoped into a named exception. Those two changes close the path that makes the rest of this optional.
Then give the helpdesk a script. An internal authentication phrase, or a callback to the number in the directory rather than the one that rang you, costs nothing and is the control the attacker cannot buy around. Microsoft’s own list ends on verifying helpdesk identity before any credential or MFA reset, which is a process problem rather than a product one.
Then treat authentication method registration as a security event in its own right. A new authenticator app or phone number added to an account should generate an alert somebody reads, and registration of security information should sit behind strict Conditional Access. This is the step that turns a one-hour session into standing access, and it is the cheapest place to catch it.
And write the response down before you need it. Revoke sessions and refresh tokens, reset the credential, and remove the authentication methods the operator added, in that order. Turn on Microsoft Graph activity logs and mailbox auditing now, because the reading is quiet by design and without those logs there is nothing to reconstruct it from.
Detection was not the limiting factor. Response time was.
Darktrace, Hiding in Plain Sight: Uncovering a Multi-Stage Ransomware Attack Through Behavioral Detection
Compromised VPN credentials put an operator on the network. Over the next three days they scanned east to west across a broad range of ports, triggered Active Directory replication consistent with a credential dump, ran command and control over SSL, pushed data out to Wasabi cloud storage, and encrypted thousands of files. The customer had behavioural detection running and it saw all of it, stage by stage, while the intrusion was still reversible. Three days is a long time to be inside a network that is watching you.
What worked
The detection, and Darktrace is unusually blunt about which half of the problem it solved: "detection was not the limiting factor; response time was." The scanning was flagged. The replication anomaly was flagged. The command and control was flagged. More than 30 rare outbound connections to a Wasabi endpoint were flagged before a single file was encrypted, along with close to 3GB going to one external address and just under 4GB to another. None of that needed a signature or prior knowledge of the tooling, which is the case for behavioural detection made about as well as a vendor can make it.
What failed
Everything downstream of the alert. Autonomous Response was licensed and switched on in this environment, and the report says it "was not fully configured across the impacted devices, allowing the attack to progress to ransomware deployment." So the control that would have cut the sessions was bought, enabled, and inert on the machines that mattered. Nobody acted by hand either; the three days are the proof of that.
The uncomfortable reading is that this customer spent their detection budget correctly and finished in the same place as somebody who had spent nothing. Darktrace says as much in the counterfactual: "Prompt investigation and containment of devices exhibiting anomalous behavior could have prevented lateral movement, data exfiltration, and ultimately ransomware deployment." Every one of those stages was on a screen when it happened.
The number
3 days
from the first use of the compromised VPN credentials to encryption, with alerts raised at every stage in between and none of them acted on.
What to do instead
Go and check which of your automated response actions are actually armed, on which machines. Not whether the product is licensed, and not whether the feature is on in the console, but whether it will act tonight on the hosts that decide the outcome: domain controllers, file servers, the VPN concentrator, the jump boxes. A response capability configured across most of an estate is one the attacker routes around, and the part that was missed is never random. Ask for the coverage list rather than the coverage number.
Then write down who may cut a session, and when, and without whose permission. This intrusion ran for three days through alerts that a person could have acted on, and the reason teams default to watching is almost never that they did not believe the alert. It is that nobody has told them in writing that they are allowed to pull a host off the network at two in the morning and be wrong about it.
Then take the exfiltration signal seriously on its own. Rare-destination cloud storage is the most useful single rule here: more than 30 connections to a Wasabi endpoint from a host that had never spoken to it, carrying gigabytes, in an environment where nothing legitimate uses that provider. If your egress alerting is tuned on total volume rather than on destination rarity, that traffic looks like a backup job.
And rotate the VPN credentials and check what else they open. This started with valid credentials on remote access, which is the same first step as most of what lands in this section.
Reverse Engineering the Six Stages of MacSync Stealer and RAT
Huntress, 29 July 2026
Huntress recently investigated an incident where the victim searched Google for how to install Claude on a Mac, clicked a sponsored result, and landed on a weaponised claude.ai/share conversation dressed up as an Apple Support install guide. It told them to open Terminal and paste a single curl command. MacSync is a six-stage kill chain, not a smash-and-grab.
What worked
Huntress does not name a control that held here. Read that as a finding in itself: these write-ups are built from what responders actually found, and one with no successes in it is usually describing a network that had none.
What failed
The victim went looking for Claude. Their browser history opens with a Google search for how to install Claude Code on a Mac and, two clicks later, lands on a page that appears to show the answer. In between was an ad, and the ad is the whole trick. The result they clicked was not the organic anthropic.com listing but a paid Google Ads placement. This is malvertising in its current, least exotic form. The term was originally used to describe a booby-trapped banner that launched an exploit when loaded. What it means
The number
2 minutes
Their prefixes are still in the config strings /tmp/openssl-arm64/ and /tmp/openssl-x86_64/, and there are two compile banners rather than one, stamped about 2 minutes apart.
What to do instead
Start with what not to chase. The file hashes and the per-delivery 8-hex identifiers change every build, so they're low-value on their own. Anchor on the behaviours, which don't change: curl -k with a Base64-decoded URL piped into zsh, the loader's execution and its ~/.zshrc persistence.
Akira Hits Safe Mode: Ransomware Rebooting Around EDR
Huntress, 12 August 2026
After gaining access via an exposed SonicWall VPN, an Akira affiliate rebooted the victim host into Safe Mode with Networking to defeat EDR, a first for this ransomware variant in our telemetry. Safe Mode is a boot mode that only loads essential drivers and services, disabling most third-party software. As such, the reboot stopped the Huntress agent and disabled Microsoft Defender's real-time protection; Defender couldn't quarantine the file until the attacker rebooted back to normal mode.
What worked
Huntress records one thing that held. “Eventually, a scheduled Defender scan detected the ransomware binary at 07:43:50 UTC.”
What failed
Huntress groups the failures under four headings: initial access: SonicWall SSL VPN, no MFA; living on the domain controller: recon, the akira way; collection and exfiltration: WinRAR to the cloud; and AnyDesk: the delivery and c2 channel. “The intrusion started where many Akira intrusions start: a SonicWall SSL VPN. Beginning around 03:45 UTC on August 4, 2026, the SonicWall logged a burst of failed logins (Unknown User Login Attempt / "User login denied due to bad credentials") against multiple usernames from several external IPs: a straightforward credential spray.”
The number
10 minutes
This AnyDesk session (including the preceding Safe Mode reboot) lasted less than 10 minutes, showing how well-oiled these Akira intrusions have become.
What to do instead
Catch the credential spray before it becomes a foothold: Alert on bursts of failed VPN logins against multiple usernames from one source. Correlate those failures with a successful login from the same IP or ASN within a short window.
Named for the doctrine distinction between a lesson observed and a lesson learned: a lesson is not learned until behaviour has changed and somebody has checked. Pretending otherwise is how the same finding turns up in three consecutive post-incident reports.
