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.
Unit 42, 6 October 2026CVE-2026-88771CVE-2026-88772
Drafted from the advisory Nobody here has read this one yet. The four answers below are quoted from the source document and attributed to it, so you can check every one of them against the advisory itself. Nothing in this entry was written here.
We discovered that an Iranian state-aligned threat actor has been masquerading as the Dubai Airports IT department to deliver trojanized coding challenges to high-value targets. Unit 42 tracks the activity as CL-STA-1178. This activity includes a campaign we call “Blinder Tunnel,” that targeted Iraqi critical infrastructure in March 2026, following infrastructure staging that was observed as early as November 2025. We named the campaign Blinder Tunnel after infrastructure terms the attackers used, as well as the malware’s tunneling capabilities.
What worked
Unit 42 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
Unit 42 groups the failures under four headings: dubai airports careers portal, recruitment coding challenge, three-step infection chain, and stage one: malicious.csproj file. “Starting in late March 2026, the threat actor launched a social engineering campaign disguised as a professional recruitment process to compromise a specific individual, likely a software engineer. We identified this campaign through VirusTotal, following multiple file submissions from a submitter based in Iraq.”
The number
63 second
Beacon (63-second interval): This timer drove the primary C2 loop.
What to do instead
Cortex AgentiX Agentic Assistant streamlined this investigation by allowing the team to query the data using natural language, providing deeper context and insights, and suggesting clear recommendations on what researchers should do next. Figures 16 and 17 show examples of this.
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.
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.
MGM Resorts SEC Form 8-K, October 2023, and contemporaneous reporting
Scattered Spider identified an MGM Resorts employee on LinkedIn, called the IT help desk impersonating them, and talked their way into a password reset that yielded administrative access to MGM's Okta tenant. MGM pulled systems offline to contain it; ALPHV still encrypted more than a hundred ESXi hypervisors, and MGM disclosed roughly $100 million of impact to its Las Vegas and regional operations.
What worked
They did not pay. Caesars, hit by the same crew in the same window, reportedly did. MGM took an operational beating instead: slot machines, digital room keys and reservations down, guests queuing at the desk with paper. That is what refusing looks like from the inside, and the fact that they came back without paying is the part worth putting in front of your own executives before an incident, not during one.
What failed
Everything upstream of the phone call. The help desk could reset a privileged account's credentials and its MFA on the strength of a voice and details anyone could read off LinkedIn, and there was no callback, no manager confirmation, no out-of-band check. Then containment came too late to matter: by the time the Okta sync servers were pulled, the operators already held the environment, and the hypervisors were encrypted anyway. Worth being clear about that, because the shutdown is often described as the thing that stopped the encryption. It did not.
The number
10 minutes
the length of the phone call that produced administrator access to MGM's Okta tenant.
What to do instead
Treat identity verification at the help desk as a security control with a written procedure, not as a customer service judgement call. High-privilege resets need a second channel: a callback to the number in the HR record, a manager approval, or an in-person check. Then go and test it, by having someone your desk does not know attempt exactly this call. Most organisations that believe they are covered here have never tried it, and the ones that have usually stop believing it. The technical lesson is smaller than the procedural one: no amount of MFA helps when the help desk will re-enrol the factor for whoever asks.
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.
