The forensic gap is the most useful part of Microsoft's write-up. Its researchers name three candidate vulnerabilities and confirm none of them, because the affected hosts carried both the older and the newer flaws at the same time when the activity ran [22][4]. This is what investigating a long-exposed application looks like when the patch backlog is deeper than one cycle.
The dates decide how much a patch programme could have helped. The newest flaws were disclosed on January 28, 2026, and the intrusion ran during December 2025 [3][4]. Counting back from the disclosure, that is 28 days if the activity ended on December 31 and 58 if it began on December 1 [21]. So either an older flaw sat open for months, or the newer ones were in use before anyone published them. A service-level agreement measured in days from disclosure does not cover either case.
The detection argument follows from the toolchain rather than from the entry point. Microsoft says the attackers leaned on living-off-the-land techniques, legitimate administrative software and quiet persistence [6], and it makes the evasion explicit in one step: sideloading a malicious DLL through wab.exe reduces detections that key on well-known dumping tools or direct-handle patterns [14]. Its own recommendation is behaviour-based detection across identity, endpoint and network [7]. Read that as a budget statement: coverage built on named-bad-binary lists was the control that did not fire here.
The virtual machine deserves attention for what it does to visibility. The alert that fired was on the creation of the scheduled task itself [12], and the task was named TPMProfiler and forwarded host TCP 22022 to port 22 inside the guest [13]. An agent running on the host can see a task being registered under SYSTEM and an unusual listening port. The activity inside the guest itself falls outside that view.
This is a vendor blog that ends by pointing customers at Microsoft's own vulnerability management to find unpatched instances [20]. The load-bearing detail works against that pitch, since an inconclusive attribution is a poor advertisement, and most of the hardening list is unbranded labour: remove public access to admin paths and raise logging on the Ajax Proxy [16], hunt for RMM artefacts such as ToolsIQ.exe left behind after exploitation [17], rotate the service and admin credentials reachable from the helpdesk host and isolate what was touched [18].
The board-deck version reads: three CVEs, patch them, close the item. It is incomplete on its own terms, because the vendor cannot say which one mattered [4] and because the intrusion did not stop at the application, moving from domain group enumeration through reverse SSH and RDP to a password-data request against a domain controller [10][11][15]. The tradeoff worth naming is where the next dollar of assurance goes. Patch velocity is measurable and comforting; an accurate inventory of internet-facing applications that hold domain-joined service accounts is tedious and tells you which compromises are survivable. Microsoft's own framing is that a single exposed application can reach full domain compromise when it is unpatched or insufficiently monitored [5], and the second clause is the one most organisations cannot evidence.
The decision this quarter is which of those two lists a security review is built on. The consequence next quarter arrives with the update Microsoft has promised [19]: if it names one CVE, patch timing becomes the story again, and if it does not, the exposure list is all anyone has to reason with.
