A working examiner's read of the fortnight's most interesting compromises. What happened, how it happened and what it means for anyone who has to reconstruct the event afterward.
This edition covers two weeks, November 1 to 14. Nothing in it needed a clever exploit. The largest crypto theft on record started with a coding test sent to a job candidate who already had a job. A ransomware crew erased four hypervisors, both of their management appliances and the backups behind them without touching a single vulnerability. The one flaw Microsoft confirmed as exploited this month was a message file that makes Outlook hand a password hash to a stranger. A shipping giant learned that the systems it buys come with the risks their old owners never fixed. And a VPN gateway let attackers past multi-factor authentication through a login path nobody meant to leave open.
The common thread is trust. In every story the attacker used something the victim had already approved: a developer tool, an internal AI assistant, vCenter's own configuration feature, a mail client, an acquired platform, a second way to sign in. Each of those leaves records that look like ordinary administration. The evidence is not in any one log line. It is in the order the lines appear. Here is the fortnight, read the way an examiner reads a disk: not as headlines but as events that leave traces.
Binance: the $6.3 billion theft started with a job offer
Last edition closed on the theft itself. On October 29 an attacker drained about $6.3 billion from Binance hot wallets on ten blockchains, most of it in about 20 minutes. The open question was how the attacker got Binance's own systems to sign. On November 3 Binance published an initial post-mortem. The answer runs back five months to three engineers' computers.
The sequence below is Binance's, as summarized by StepSecurity and HackerNoon. In June an engineer Binance calls Engineer A went looking for an AI coding tool and installed a tampered Homebrew package. Binance says it detected the anomaly at the time, replaced the device and rotated the related credentials. In September a second engineer, Engineer B, was approached through a legitimate job-hunting site. The contact moved to a video call and then to a chat app. Engineer B was asked to complete a short coding assignment and ran it on a work computer. The setup step deleted the genuine pyenv from the Homebrew folder, put a doctored copy in its place and opened a connection to a server the attacker controlled.
On October 20, Binance says, the attacker used Engineer B's computer and an internal AI tool to take control of the computers of Engineers A and C. Binance has not named the tool or said how it allowed that. On October 29, between 17:15 and 19:56 UTC, the attacker worked from Engineer C's computer. Using credentials stolen from Engineer A, including a token with permission to deploy containers, the attacker deployed a container and ran a malicious script. That reached a wallet signing service and started transactions outside the normal withdrawal process. Nine minutes later the first XRP Ledger wallets began to empty. On Ethereum the signing service approved 50 EIP-7702 authorizations that pointed a hot wallet at an attacker's contract. Binance cleared that delegation at 00:10 UTC on October 30.
The money side has moved fast. Binance revised the loss to about $6.34 billion and says about $2.85 billion has been frozen or intercepted, subject to reconciliation and market prices. It says it will absorb the financial impact itself. By October 31 it had replenished 98% of the affected token assets. Selected withdrawals reopened on November 1. The FBI attributes the theft to North Korea's TraderTraitor activity. Binance has not made that attribution itself. It says it has rebuilt the affected wallet system and the internal AI tool, replaced the affected devices and retired the related credentials. None of that has been independently verified yet, though Binance says an outside expert will review it.
For an examiner, three things in this account stand out. The first is how small the foothold was. StepSecurity, working from the published sequence, puts the two pyenv files, genuine and doctored, at 3,344 and 3,414 bytes. A 70-byte difference in a developer tool's shim is the kind of change that only a file hash baseline or a careful timeline catches. The second is that the attack ran through things engineers trust: a package manager, a take-home test and a company AI tool. Every one of those runs with the engineer's own rights, so its activity looks like the engineer working.
The third is a gap the post-mortem leaves open. Engineer A's device was replaced and the credentials rotated in June. Yet in October the attacker controlled Engineer A's computer and used Engineer A's stolen credentials. Either the June cleanup missed something or the attacker got back in by another route. That is exactly the question an image of the June laptop would answer, if one was kept. When a device is replaced after a suspected compromise, preserve the old one before it is wiped. Months later it may be the only record of how the attacker first got in.
BlackNevas: four ESXi hosts erased with no exploit at all
On November 13 Kaspersky's Global Emergency Response Team published one of the most detailed hypervisor intrusions we have seen in public. Over a 10-day period an attacker destroyed an organization's whole virtualization estate: four ESXi hosts, every virtual machine on them, both vCenter Server Appliances and the backup infrastructure behind them. Kaspersky does not name the victim. It found no hypervisor vulnerability, no guest escape and no memory corruption. Every action on ESXi went through legitimate management interfaces.
The attacker reached the vCenter appliances with credentials taken from ordinary systems inside the perimeter. The order of what came next is the lesson. Days before the main attack the attacker disabled antivirus on the backup environment. Then the backup services were stopped, the recovery infrastructure was encrypted and administrator access was disrupted. Only then did the hypervisors go. In Kaspersky's words, the order of operations reduced the defenders' ability to restore production when they needed it most.
The timings are precise enough to build detections from. The attacker logged in to a vCenter appliance as root over SSH. Forty-three seconds later a shell script fetched and installed MeshAgent, an open-source remote management agent. The whole session lasted 2 minutes and 26 seconds. About four hours later the attacker came back through MeshAgent and installed Ligolo-ng, a reverse tunnelling tool, as a systemd service named vmware-vdma.service so that it would pass for part of the appliance. To get onto the hosts themselves the attacker used vCenter Host Profiles, the feature administrators use to push one configuration to many hosts. A configuration read came first. The push to enable SSH followed 10 minutes and 18 seconds later. The host's SSH service was running 33 seconds after that. The next SSH session came from the vCenter appliance's own address.
The wiper overwrote roughly the first 2 KB of each virtual disk file. That destroys the protective MBR and the primary GPT header at the start of the disk. Kaspersky makes a point that is easy to miss in an emergency: GPT keeps a backup header at the end of the disk, so an overwrite of the first 2 KB does not by itself make the partition table unrecoverable. Whether the data comes back depends on what else was touched. Before anyone declares a virtual disk lost, have it imaged and examined.
Attribution is careful. The ransom notes named BlackNevas, a group first seen in November 2024. Kaspersky did not recover the binary, so it bases the link on the command-line style, which resembles the Trigona and BlackNevas family. It says that comparison strengthens attribution but does not replace a hash or a reverse-engineered match. A separate Kaspersky report on November 6 described two older cases with the same shape. In one, a PRTG monitoring server held broad access to ESXi and the same root password worked on several hosts. In the other, The Gentlemen ransomware group found Proxmox root credentials in plain-text notes on an administrator's workstation.
The forensic point is about where the evidence lives. Broadcom's own documentation says ESXi logs to a ramdisk that has limited space and is cleared at reboot. A host that is rebooted to "get it back up" has erased its own account of the attack. Forward ESXi and vCenter logs to remote storage before you need them. If an incident is under way, collect them before anyone restarts a host. Kaspersky's detection advice is worth quoting directly: the strongest rules correlate legitimate actions into an abnormal sequence rather than alerting on any one administration command. A Host Profile change that enables SSH, followed by an SSH session from vCenter, followed by a new systemd unit with a VMware-like name, is that sequence.
Outlook CVE-2026-124194: a message file that hands over your hash
Microsoft's November Patch Tuesday on November 10 was the largest on record. BleepingComputer counts 1,235 flaws, 142 of them Chromium fixes in Edge. Other outlets give totals between about 1,090 and 1,360 depending on what they count. Microsoft marked one of them as exploited before the fix: CVE-2026-124194, which Microsoft calls an Outlook spoofing vulnerability. CISA added it to the Known Exploited Vulnerabilities catalog with a federal deadline of November 24.
The mechanism is old and effective. According to Microsoft's description, an unauthenticated attacker sends a specially crafted message file and persuades the user to open it. Opening the file makes Outlook connect to a network location the attacker controls. Windows offers the user's NTLM credentials to that location, which hands the attacker an NTLMv2 hash to crack offline. Microsoft says exploitation needs network connectivity and user interaction.
Two kinds of evidence matter here. The first is the message itself. It is sitting in a mailbox, which on a workstation usually means a PST or OST file. Look inside its properties and attachments for a UNC path such as \\host\share or a WebDAV address pointing outside the organization. The second is the network. The connection leaves the workstation at the moment the user opens the file, so egress logs showing SMB on port 445 (or WebDAV over HTTP) to an unfamiliar external address at that time are strong corroboration. Many organizations already block outbound SMB to the internet. This is the attack that rule exists for.
One caution for examiners. A suspect message is still live ammunition after it has been collected. Review it on an isolated machine with no route out, whatever tool you use to open it. If the mailbox has been preserved as a PST or OST, our guide to opening a PST file without Outlook covers the ways to review it without a full Outlook install. Then treat any account whose hash may have left the building as compromised until its password has changed.
Maersk: the breach came with the acquisition
On November 11 Maersk confirmed that a threat actor had breached a system and stolen data. The system belongs to LF Logistics, which Maersk bought from the Li & Fung Group in 2022. The affected system is the OCF/LF Logistics platform. Maersk says the incident is isolated to a local system. It has found no impact on other Maersk systems or on customer and partner systems connected through APIs and EDI. It says current evidence indicates no sensitive data has been disclosed and it does not expect any disruption to shipping.
The ransomware group WhiteArmor tells a bigger story. It listed Maersk on its leak site and demanded $5 million in bitcoin within 30 days. It claims about 100 GB from the platform, including nearly 30,000 driver records, plaintext passwords, 33 SUPER_ADMIN accounts, signed delivery receipts and 27,842 mobile device logs with phone numbers, email addresses and IMEI numbers. None of that is verified. Leak-site claims are written to pressure the victim. They are not evidence.
They are useful to an investigator all the same. A specific claim is a test. If the platform's own logs and database show which tables were read and when, the claimed contents can be checked against them one by one. A claim of 33 SUPER_ADMIN accounts either matches the number the system actually holds or it does not. The harder problem is the one acquisitions create. A system bought four years ago may still keep its old owner's logging defaults, retention periods and administrator habits. Plaintext passwords, if the claim is true, are that kind of inheritance. After an acquisition, find out what the acquired systems log, how long they keep it and who can read it, before an incident forces the question.
SonicWall CVE-2026-19868: MFA on paper
CVE-2026-19868, in SonicWall advisory SNWLID-2026-0014, is an authentication enforcement flaw in the SonicOS SSL-VPN service. SonicWall says it has investigated a report indicating potential exploitation. CISA added it to the KEV catalog on November 6 on evidence of active exploitation. It only applies where SSL-VPN logins use SAML. There, someone holding valid credentials for an alternate login method can get past the SAML authentication and the multi-factor checks tied to it. The federal deadline is November 20. The fixed releases are SonicOS 7.3.4-7013 for Gen7 (7.3.3-7015 and older are affected) and 8.2.3-8015 for Gen8 (8.2.2-8015 and older). SonicWall lists no workaround.
The examiner's test is simple and worth running even after patching. A real SAML login leaves two records: one on the firewall and one at the identity provider, with the MFA check attached. A bypassed login leaves only the first. Pull SSL-VPN logins for the period before the patch and match each one to a sign-in at the identity provider. Any VPN session with no matching identity provider sign-in needs an explanation. Reset that account's credentials and work out what the session reached. The evidence of a bypass is the record that is missing, which is why both sides have to be kept.
On the watchlist
- Chrome CVE-2026-125350. Google fixed a use-after-free in Chrome's XML component on November 9, in 157.0.8103.50/.51 for Windows and macOS and 157.0.8103.50 for Linux. Google says an exploit exists in the wild. It is the eighth exploited Chrome zero-day of 2026. Chromium-based browsers such as Edge need the matching fix. CISA's deadline is November 24.
- OpenSSH CVE-2026-123158. CISA added an OpenSSH authentication bypass to the KEV catalog on November 9. It affects certain Linux systems that use musl libc without PAM, with Alpine Linux named. It does not affect every OpenSSH install. The fix comes from your distribution. Containers built on Alpine are the place to look.
- The rest of the November 9 batch. GPUStack CVE-2026-102895 (an authentication bypass giving remote admin, fixed in 2.2.0), FreeSWITCH CVE-2026-116779 (command injection through SIP MESSAGE handling, fixed in 1.11.3) and IBM Aspera Faspex CVE-2026-123218 (an authorization bypass to full admin, fixed in 5.0.19 PL1). The federal deadline was November 12.
- Check Point CVE-2026-123039 and UnrealIRCd CVE-2026-114713. CISA added both on November 13. CISA lists the Check Point flaw as an incorrect permission assignment for a critical resource across multiple products. If you run Check Point gateways, read the vendor advisory for the affected builds.
The forensic read
Every attack in this edition ran through something already trusted. Binance's attacker used a package manager, a take-home test and the company's own AI tool. BlackNevas used vCenter's own configuration feature and a remote management agent dressed as a VMware service. The Outlook flaw made the mail client volunteer a credential. Maersk's intruder came in through a platform that arrived with an acquisition. The SonicWall bypass used a second login path the firewall already allowed.
When the tools are legitimate, single events prove little. An SSH session from vCenter is normal. So is a Host Profile push, a new systemd service, an outbound connection or a VPN login. What is not normal is the order. Reconstruction depends on having every piece of that order recorded somewhere the attacker could not reach: hypervisor logs forwarded off the host, identity provider records kept next to VPN logs, egress logs kept long enough to matter and an image of the device that was replaced in June. None of this is expensive. All of it has to be in place before the incident, which is what our Digital Evidence Readiness Self-Audit is built to check.
That is the through-line Sherlock Forensics cares about. An intrusion is not over when the attacker leaves. It is over when someone can show what happened in a form that holds up to scrutiny. If a developer workstation, hypervisor, mailbox or VPN of yours is in scope for any of these stories, our incident response team can preserve the evidence and build the timeline. An incident response retainer means the first hour is already planned the next time. Next edition, the week of November 15.
Sources
- Binance's $6.34 billion hack: developer machines, AI tooling and wallet signing, StepSecurity: www.stepsecurity.io
- Binance's post-mortem is out: the $6.3 billion hack started with a job offer, HackerNoon: hackernoon.com
- ESXi ransomware: why it is dangerous and how to defend against it, Kaspersky Securelist: securelist.com
- How misconfigurations in virtual environments can lead to compromise, Kaspersky Securelist: securelist.com
- Microsoft November 2026 Patch Tuesday fixes 1,235 flaws, Outlook zero-day, BleepingComputer: www.bleepingcomputer.com
- Maersk confirms data breach as WhiteArmor ransomware demands $5 million, BleepingComputer: www.bleepingcomputer.com
- Exploited SonicWall SSL-VPN flaw lets attackers bypass SAML-enforced MFA (CVE-2026-19868), Help Net Security: www.helpnetsecurity.com
- Google issues Chrome security update for eighth actively exploited zero-day of 2026, The Hacker News: thehackernews.com
- CISA adds 4 exploited flaws to KEV: GPUStack, FreeSWITCH, OpenSSH, IBM Aspera, eSecurity Planet: www.esecurityplanet.com
- CISA adds two Known Exploited Vulnerabilities to catalog, November 13, CISA: www.cisa.gov
- Known Exploited Vulnerabilities catalog, CISA: www.cisa.gov
Previous in this series: Weekly Security Roundup: October 22 to 31, 2026.