6 verified findings from 3 runs · 4 updates to prior coverage · the settled record for this UTC day, in the classic brief order.
Criticality
Kind
Topic
Region
TL;DR · the day in one read
01SynkLoader pairs a fake Windows lock screen with a backconnect proxy, so the stolen domain password is used from the victim's own address. Expel documented SynkLoader on 2026-08-20, a previously unidentified loader delivered by Microsoft Teams message from a company-styled onmicrosoft.com address impersonating the target's own IT service desk, which talks the user into installing an MSI presented as a "PowerShell Cleaner" hosted on Azure blob storage. Six modules blend Python, PowerShell, C# and C++ — some using three languages at once: a system profiler that counts Active Directory-joined computers, an in-memory DLL loader, PhishLocker (a counterfeit Windows lock screen that harvests the domain password), TrafficRedirector (a backconnect proxy), an interactive shell, and a screen-streaming module. The load-bearing combination is the harvested password plus the tunnel: Expel states the operator can then sign in to internal and external company systems without triggering alerts based on logins from unknown addresses or geolocations. Expel assesses at low-to-medium confidence that the toolkit belongs to a ransomware group or an access broker selling to one. →
02BACS report: the public sector remains the largest share of Swiss mandatory CI reports at 19.4%, and basic hygiene would have stopped the Poland sabotage. Switzerland's Bundesamt für Cybersicherheit published Halbjahresbericht 2026/I on 2026-08-24, covering January to June 2026: 27,128 voluntary reports (down from 35,727 in H1 2025) and 200 mandatory critical-infrastructure reports, of which the public sector continues to account for the largest single share at 19.4% ahead of IT and telecommunications at 18.6%. Unauthorised access is the most-reported attack type at roughly 26%, mostly email accounts compromised through phishing and then reused for further phishing, followed by credential theft at 13.5% and DDoS and data exfiltration at 12.7% each. The report's two focus chapters are directly operational: a full anatomy of the 29 December 2025 coordinated sabotage of Polish energy assets, whose attack infrastructure the Polish CERT publicly attributed to Static Tundra and which BACS concludes basic controls would have prevented — and a Swiss-specific "Dream Job" crypto-theft playbook that has produced more than 20 confirmed cases and losses up to roughly CHF 60 million. →
03SilkParasite gets five named RAT families and one reusable detection: the side-loading pairing, not the DLL name. Bitdefender documented SilkParasite on 2026-08-19, a China-nexus cluster it holds at medium confidence and deliberately does not attribute to a single controlling actor, running espionage against government bodies in Uzbekistan, Turkmenistan, Kyrgyzstan, Tajikistan and Kazakhstan with one recovered lure addressed to a Georgian government entity. Seven RAT families are involved, five newly named: DriveSilkRAT, whose command-and-control runs entirely through a shared Google Drive folder with twelve in-memory .NET plugins and executes commands through WMI rather than spawning a shell; CookiETagRAT, which carries tasking inside HTTP Cookie and ETag headers under a per-host key; plus NomadRAT, GoginRAT and NodeEdgeRAT. Initial access runs through malicious Office documents; what Bitdefender calls the most consistent detection surface across the campaign, used by most of the toolset rather than all of it, is DLL side-loading beside a legitimate signed application — Calibre, ABBYY FineReader, Quick Heal, Mp3tag and a Windows Defender component among the named hosts — and its own detection formulation is that the reliable signal is the pairing rather than the library name. →
Expel published an analysis on 2026-08-20 of SynkLoader, a loader it found on 2026-08-18 while investigating an endpoint-detection alert on a scheduled task in a client network, and for which it could find no prior public reference (Expel, 2026-08-20). The name is a play on its breadth — Expel describes it as an "everything but the kitchen sink" approach — and the reason it belongs in front of a public-sector defender is the delivery, not the tooling: the operator arrives over Microsoft Teams, from a <username>@<company>.onmicrosoft.com address (the default mail domain Microsoft 365 assigns a tenant), posing as the target's own IT service desk under a fabricated staff name, and persuades the user to download and install an MSI presented as a "PowerShell Cleaner" and hosted on Azure blob storage — giving the download the appearance of coming from Microsoft. That inverts the direction staff are trained to be suspicious in: the lure is not an external email but an internal-looking chat from support.
Six modules follow, and Expel notes the chain "ships a long chain of attack tools, which bridge multiple separate programming languages, with some modules using as many as three programming languages at once." A system profiler loads a C# module carrying the name of a Microsoft Visual C++ runtime library, which exports functions to run PowerShell in memory through an embedded Python interpreter, and collects hostname, current user, privilege level, running processes, installed services, the Active Directory domain name and — the detail Expel leans on — a count of AD-joined computers. A persistence module is reached through a second fake-runtime-named DLL that maps libraries into memory without writing them to disk, and the way it installs its scheduled task is a deliberate evasion rather than an implementation detail: Expel documents it registering the task through the Task Scheduler COM interface rather than the command-line utility, specifically to sidestep behavioural detections that inspect command-line arguments or watch for the scheduled-task binary being invoked. That matters for hunting, because the usual high-value signal — a suspicious schtasks command line — is exactly what this build avoids producing. PhishLocker renders a counterfeit full-screen Windows lock screen to steal the user's system login credentials, going as far as retrieving the machine's real lock-screen background image from its own on-disk location and re-focusing itself to defeat Alt+Tab; Expel's analysis host gave it away because the fake mimicked Windows 11 while the machine ran Windows 10, producing visible mismatches in clock and icon placement, password-box theming and the absence of the background blur Windows applies when the password prompt has focus. TrafficRedirector is a backconnect proxy using a protocol resembling HTTP CONNECT: it dials out to the operator, waits for an address and port, and then forwards traffic — which Expel states "can enable the threat actors to connect to internet services using the infected machine IP address, bypassing corporate IP allow-listing," and equally lets the operator reach internal services that only listen on the LAN. An interactive shell polls one endpoint for commands and posts results to another. A screen-streaming module written in Python connects outward rather than listening, compresses screenshots and forwards mouse and keyboard input into the live session — notably not a hidden-desktop implementation, so the activity would be visible to a logged-on user; Expel assesses from its unusually formal comments and the absence of any matching open-source project that it was likely AI-assisted.
The two halves that matter together are PhishLocker and TrafficRedirector. Expel's own framing: "When combined with the system password phishing model, threat actors can use the infected user's username and password to log into both internal and external company systems, all without triggering alerts based on logins from unknown IPs or geolocations." A cleartext domain password is also worth more than a hash here because single sign-on turns it into access across every federated application, without the constraints of pass-the-hash or Kerberos relay. Expel assesses at low-to-medium confidence that the toolkit belongs to a ransomware group or an initial-access broker selling to one, resting that on the AD-computer count — which matters most to an actor whose profit scales with the size of the network it disrupts — and on the loader's resemblance to others previously used by such groups. Build timestamps place the components around late July 2026, and one module's debug path leaked the developer's local account name.
Triage: a real IT service desk contacting a user over Teams and asking them to install something is not unusual, which is what makes this work — the discriminators are tenant and provenance, not behaviour. Genuine internal support messages come from a sender inside the organisation's own verified domain, not from an onmicrosoft.com default-domain address belonging to a different tenant, and genuine software arrives through the organisation's own management or software-distribution channel rather than as an operator-supplied link to consumer-facing cloud storage. On the endpoint, an MSI that installs an embedded Python interpreter and DLLs bearing Visual C++ runtime names outside a legitimate application directory is the anomaly; the runtime names are the masquerade, so the signal is the location and the installing parent, not the filename. For the lock-screen module, the honest discriminator is that Windows never asks a user to re-authenticate through a newly launched application: a full-screen credential prompt whose owning process is not the operating system's own logon UI is a fake, and a mismatch between the rendered lock-screen style and the host's actual Windows version is what exposed this one.
The loader ships a long chain of attack tools, which bridge multiple separate programming languages, with some modules using as many as three programming languages at once.
It can enable the threat actors to connect to internet services using the infected machine IP address, bypassing corporate IP allow-listing.
When combined with the system password phishing model, threat actors can use the infected user’s username and password to log into both internal and external company systems, all without triggering alerts based on logins from unknown IPs or geolocations.
Bitdefender published an analysis on 2026-08-19 of SilkParasite, a cluster designation for espionage activity against government bodies in Uzbekistan, Turkmenistan, Kyrgyzstan, Tajikistan and Kazakhstan using regionally tailored lures — several impersonating specific ministries — with one further document recovered from a public malware-sharing platform addressed to a Georgian government entity (Bitdefender, 2026-08-19). Seven remote-access families are involved. Two were previously documented by other vendors; five are newly named here — DriveSilkRAT, CookiETagRAT, NomadRAT, GoginRAT and NodeEdgeRAT.
Two of the five are worth a defender's attention for their command-and-control choices rather than their capabilities. DriveSilkRAT runs its tasking entirely through a shared Google Drive folder: operators drop command files in, the infected host polls the folder, downloads the tasking, executes it through a system of twelve custom in-memory .NET plugins covering process listing, system and network enumeration, file management and command execution, and uploads results back to the same folder. Its command execution runs through Windows Management Instrumentation rather than spawning a command interpreter directly, which removes the parent-child process shape most detections key on. Bitdefender observed roughly 65 infection instances at the time of writing, stating that figure is an upper bound rather than a machine count because the victim identifiers derive from hardware fingerprinting. CookiETagRAT puts its tasking in HTTP Cookie and ETag response headers, returning results in the body, with each host deriving its own stream-cipher key and nonce from a unique system identifier plus a fixed suffix — so captured traffic from one victim cannot decrypt another's. It also runs its malicious logic directly from the library's entry point rather than waiting for an exported function to be called, which makes it fire immediately in a sandbox as well as on a victim.
Initial access is a malicious Microsoft Office document, most likely spearphished, rather than the side-loading itself; what side-loading gives is the most consistent detection surface across the campaign — Bitdefender's phrasing is "most of the toolset", not all of it. Six side-loading pairs are named, each a legitimately signed application loading a malicious library placed alongside it: Calibre's ebook editor, ABBYY FineReader, a Quick Heal component, Mp3tag, a Windows Defender service binary, and one still-unidentified signed host. Bitdefender's own formulation of the detection is the reusable part: "The most consistent detection surface across the campaign is DLL sideloading, and the reliable signal is the pairing, not the DLL name alone: a legitimately signed application loading a library placed beside it while running from an unusual location." On the question of AI involvement it is measured rather than breathless — "SilkParasite is primarily assisted: capable humans do the engineering and lean on AI to move faster, leaving behind a few tells but none of the degradation" — with the tells being leftover test functions in the Go orchestrator, a hardcoded placeholder encryption key, a configuration field still carrying a change-me name, and a suspiciously close architectural resemblance between two implants written in different languages.
Triage: signed applications legitimately load libraries from their own install directory constantly, which is why the location and not the load is the discriminator — the same signed binary running from its vendor install path is normal, and running from a user profile, temporary or removable-media path is the anomaly worth an alert. For the Defender-component pair specifically, the benign twin is the real service running from its own protected directory; a copy of it running from anywhere else is not a false positive. On the network side, consumer cloud-storage and code-hosting traffic from a workstation is ordinary; the discriminators are the client identity and the rhythm — a long-lived process that is not a sync client or a browser, polling the same folder or endpoint on a fixed interval, with request and response sizes that stay small and regular.
The most consistent detection surface across the campaign is DLL sideloading, and the reliable signal is the pairing, not the DLL name alone: a legitimately signed application loading a library placed beside it while running from an unusual location.
SilkParasite is primarily assisted: capable humans do the engineering and lean on AI to move faster, leaving behind a few tells but none of the degradation.
ReliaQuest published an account of a security incident on 2026-08-23 (ReliaQuest, 2026-08-23). It describes a social-engineering attempt against the company, sets out what its investigation found, and then states flatly that "Claims that ReliaQuest was compromised or targeted by ransomware are false" — so something to that effect was evidently circulating. The article never describes that claim: not where it came from, what it asserted, or what it offered as proof. Neither does this entry. What it does describe is the attempt, and the interesting part is where that attempt stopped.
Per that account, on 22 August 2026 an attacker registered a lookalike domain, stood up a counterfeit single-sign-on page fronted by a content delivery network, and then cold-called multiple ReliaQuest employees, each time impersonating a named member of ReliaQuest's own security staff, to steer the target toward the fake page. "One teammate entered their password and approved the push notification on their phone," which handed the attacker a session on the identity dashboard. "The extent of the access was view only." ReliaQuest states the attacker then made further attempts to move from that dashboard into business applications and was consistently denied by security controls — specifically a device-trust policy that blocks any device the organisation does not manage from reaching applications or systems, regardless of a successful identity-provider sign-in. Containment terminated the session, expired the compromised password and reset every authentication factor on the account. Its investigation — described as a complete audit of control fidelity, device trust, on-network access and any suspicious subsequent activity in the preceding 48 hours, so a lookback window rather than a statement about how long the work took — found no other identities accessed, no business applications reached, no customer or company data reached beyond that one user's login credentials, and no persistence established.
ReliaQuest then places the episode in a wider pattern rather than claiming novelty for it, and the distinction matters for what a reader should take as observed: the playbook it says this is consistent with across the industry runs an impersonation call, a throwaway lookalike domain registered and burned within the hour, a harvesting page behind a content delivery network, MFA push abuse, and a rapid attempt to enrol a new authenticator. The authenticator-enrolment step is named there, as part of the pattern — the article does not record it as a step the attacker took in this case, and it should not be read as one.
Triage: the high-fidelity signal in identity-provider audit logs is a sequence, not an event: a successful primary authentication and MFA-push approval, followed within the same session by repeated application-access denials keyed to device compliance or device trust. Authentication succeeding while every downstream authorisation fails on device state is a far better phishing indicator than the sign-in alone, because a legitimate user on a managed device does not generate it — and it is a pattern worth building a rule on precisely because it fires on the successful phish rather than on the attempt. Because the harvesting domain in this case was registered and burned inside an hour, domain-age and reputation signals are unlikely to be the thing that catches the next one; the identity-side sequence is.
Claims that ReliaQuest was compromised or targeted by ransomware are false.
One teammate entered their password and approved the push notification on their phone.
Rapid7 Labs published its Quarterly Threat Landscape Report for Q2 2026 on 2026-08-18 (Rapid7 Labs, 2026-08-18). One pair of numbers carries the argument: "There were 8,539 new high- and critical-severity CVEs (CVSS 7.0–10.0) this quarter- double the number reported in the same quarter last year (4,268)," while the count of vulnerabilities newly observed under exploitation "held roughly steady (40)" — a comparison the report makes without stating the period it is against, in a paragraph whose preceding sentence is year-on-year. Rapid7 is explicit that the finding is not an exploitation surge but a triage-capacity one — disclosure volume is far outstripping what any team can work through.
Three further measurements give that a defensive shape. First, the exploited set has moved further out of the user's hands: "Nearly two-thirds of exploited vulnerabilities this quarter (62%) required no user interaction - no stolen credentials, no phishing victim, no click," up nine points from 53% in Q2 2025 — meaning awareness training and phishing-resistant authentication, whatever else they buy, are addressing a shrinking share of what actually gets exploited. Second, disclosures of missing-authentication flaws (CWE-306) rose 247% year on year, which Rapid7 frames as a fast-expanding pool of internet-facing systems requiring no login at all; that is a category where an asset-exposure question answers the risk question directly, without needing a severity score. Third, on the intrusion side, Qilin led ransomware activity with 263 listed victims, the United States remained the most-targeted country, and business services and healthcare were among the hardest-hit sectors — while ClickFix and fake-CAPTCHA campaigns together with social engineering through trusted collaboration platforms such as Microsoft Teams accounted for 31.8% of the incidents Rapid7's incident-response team worked. Rapid7 also records continued Iranian, North Korean and Russian state-nexus activity against government, finance, healthcare, manufacturing, energy and telecommunications, with Russian campaigns focused on edge infrastructure and Iranian activity including sustained ICS and OT targeting.
Rapid7's own conclusion is a prioritisation argument rather than a patching one: as disclosures keep growing, the organisations that stay ahead will not be the ones patching fastest but the ones that know what they expose, which assets matter most, where an attacker can realistically get in, and how to reduce reachable exposure before it becomes an incident.
There were 8,539 new high- and critical-severity CVEs (CVSS 7.0–10.0) this quarter- double the number reported in the same quarter last year (4,268).
Nearly two-thirds of exploited vulnerabilities this quarter (62%) required no user interaction - no stolen credentials, no phishing victim, no click.
Truffle Security re-verified 10,616 leaked AWS key pairs on 2026-08-10, a subset with complete credentials drawn from a scanned population of 64,024 unique verified AWS key pairs across 431,875 public findings surfaced between August 2022 and August 2026, and reports that 88% still authenticate (Truffle Security, 2026-08-19). Of the broader population, 10,625 keys (16.6%) were root keys across 9,945 distinct accounts. Within the enumerable subset described below, only 25 keys — 0.9% — were created in the last thirty days, and Truffle's reading of that is blunt: almost none of the population leaked recently, and the count has been building for years.
The privilege picture is what makes it operational. Crossing ownership against privilege, Truffle states: "The two sets do not overlap, so 768 live keys give full control of a company AWS account" — 526 root keys plus 242 IAM users carrying AdministratorAccess, derived from a wider set of 817 business-linked keys, with the remaining 49 scoped below administrator. Separately, 130 of the live root keys sit on organization-management accounts, which control every member account in the organisation beneath them. Age and hygiene compound it: "The median live leaked key is five years old and has never been rotated" — 1,831 days, measured across the 2,903 keys that permitted access-key enumeration, of which only 13.7% had any newer key alongside the leaked one, with the oldest live key 17.4 years old. On the accounts where budget data was readable, "90.5% of leaked-key accounts have none," and where a budget did exist the median configured limit was $8 — the free-tier guardrail rather than a control. Truffle also found that 929 of 7,590 active IAM users (12%) already carry AWS's own compromised-key quarantine policy, meaning AWS itself detected the exposure and restricted them, and that 112 of those carry the pre-2023 version of that policy — AWS flagged them at least three years ago and they still authenticate. Spend on the readable set was mostly negligible at a $0.03 median, but with a real tail: 50 accounts spent over $1,000 in the preceding month, nine over $10,000, and the readable set $420,631 in July alone.
The finding a defender should act on is the source distribution, not the counts. Truffle names five measured surfaces — Git history, public dataset repositories, container images, package registries and CI logs — and ranks only one of them: the largest single source is a public machine-learning dataset platform, with 8,482 unique live keys across 3,394 public datasets, whose keys skew most privileged of any source it tracks at 17.9% root. It publishes no ordering among the other four, so none should be inferred. None of those is the current working tree, which means the reassurance a team takes from a clean secret scan of HEAD is answering a different question from the one that matters: a credential deleted in a later commit is still in the object history, a credential removed in a later image build is still in the published layer, and a credential echoed by a build step is still in the job log long after the pipeline changed.
The median live leaked key is five years old and has never been rotated.
The two sets do not overlap, so 768 live keys give full control of a company AWS account.
The second of SPIP's two unconditional pre-authentication remote-code-execution flaws — fixed in 4.4.21 on 2026-08-20 and covered by this pipeline on 2026-08-22 with the explicit warning that a CVE-keyed vulnerability-management process could not see it — now has an identifier: CERT-FR updated its advisory on 2026-08-24 to add CVE-2026-77806. CERT-FR carries one advisory per flaw and updated both the same day, adding CVE-2026-77647 for the 4.4.20 flaw to its companion advisory. Estates triaged between 2026-08-20 and 2026-08-24 off a CVE feed are the ones to re-check: they will show CVE-2026-77647 closed at 4.4.20 while the unnumbered second flaw left the server exposed.
The original entry's closing warning was that the second flaw "has no CVE identifier at all — so a vulnerability-management process driven by CVE feeds cannot see the newer of the two." That gap closed on 2026-08-24, and closing it is itself the operational delta.
CERT-FR updated its advisory for the 4.4.21 flaw on 2026-08-24 to add the identifier now assigned to it, CVE-2026-77806, and updated its companion advisory for the 4.4.20 flaw the same day to add CVE-2026-77647 (CERT-FR, 2026-08-24; CERT-FR, 2026-08-24). CERT-FR carries one advisory per flaw — the split the original entry described in prose is now the split of the identifier records too, and the exploitation statement stands as before, attributed by CERT-FR to the vendor.
Microsoft published CVE-2026-56179 on 2026-08-11 for the second NatJack primitive — the TCP session hijack coordinated with an upstream attacker-controlled server — one day after this pipeline covered the research as having assigned identifiers only for the downstream-spoofing hijack. The researcher's own CVE list now names three: CVE-2026-56181 (Windows NAT, downstream spoofing), CVE-2026-56179 (Windows NAT, upstream spoofing) and CVE-2026-63913 (Linux netfilter). The operationally important half is what the Windows fix does: the August 2026 update adds initial-sequence-number randomisation to Windows NAT, and it is shipped disabled by default and enabled only through a registry key, so a patched Hyper-V host running a NAT switch is still exposed until someone enables it. Microsoft rates the flaw Moderate at CVSS 8.3 and records no in-the-wild exploitation.
The original entry recorded two assigned identifiers and said the remaining primitives carried none. A third has since been published, and it changes what an operator has to do rather than only what the record says.
Microsoft published CVE-2026-56179 on 2026-08-11 — one day after the original entry — covering the primitive the research describes as the TCP session hijack coordinated with an upstream attacker-controlled server. Microsoft's description of it is an origin-validation error in Windows Network Address Translation allowing an unauthorised attacker to spoof over an adjacent network, rated Moderate with a base score of 8.3 and recorded as not exploited in the wild (Microsoft Security Response Center, 2026-08-11). The researcher's own CVE list now enumerates three identifiers and maps each to a specific configuration: CVE-2026-56181 to Windows NAT in a downstream-spoofing configuration, CVE-2026-56179 to Windows NAT in an upstream-spoofing configuration, and CVE-2026-63913 to Linux kernel netfilter (Malcolm Stagg, 2026-08-24).
The part that matters operationally is the shape of the Windows fix. The researcher records that the two Windows mitigations arrived in different monthly updates and behave differently: the July 2026 update for CVE-2026-56181 disables loose connection handling by default, while the August 2026 update for CVE-2026-56179 adds initial-sequence-number randomisation that is shipped off — "It is disabled by default and can be enabled via a registry key" (Malcolm Stagg, 2026-08-24). A Hyper-V host that took the August update and nothing else therefore still accepts the spoofed handshakes the primitive depends on. This is the inverse of the usual patch assumption, and it is the reason a vulnerability-management scan that reports the update as installed will read as compliant while the exposure is intact.
Nothing else in the original entry changes: the Linux change remains a partial mitigation that raises attack complexity rather than a complete fix, and the DNS-response hijack, external-mapping disclosure and NAT-table-exhaustion primitives still carry no identifier.
LevelBlue SpiderLabs published the working mechanism of the unpatched Windows Defender privilege-escalation chain this pipeline has tracked as ShieldBreak: a fake Cloud Files sync root, two conflicting object-manager symbolic links both named WD_SCAN, an exclusive lock on the CLFS transaction log that freezes Defender's clean operation mid-flight, and a symlink swap that redirects the in-flight write so Defender's own remediation engine places an attacker-supplied phoneinfo.dll into System32 — after which a crafted Windows Error Report triggers the built-in QueueReporting task and wermgr.exe loads that DLL as SYSTEM. Roughly eight to twelve seconds, standard user to SYSTEM, on fully patched Windows 11 24H2 and Windows Server 2025 with Defender in its default configuration. There is still no vendor fix, so detection is the whole available control — and the mechanism supplies it, led by the presence of C:\Windows\System32\phoneinfo.dll, which LevelBlue states is not expected to exist natively on supported Windows versions.
The entry this one updates recorded that Microsoft had acknowledged ShieldBreak as CVE-2026-69414, rated it 7.8, assessed it "Exploitation More Likely", and stated a security update was still being worked on — with no published mechanism and therefore nothing to detect on. LevelBlue SpiderLabs has now published the mechanism and, with it, a hunting package (LevelBlue SpiderLabs, 2026-08-19). That is the whole delta, and it matters because no fix exists: detection is currently the only control a defender has.
The chain turns Windows Defender's own remediation path into the write primitive. The proof-of-concept registers its working directory as a Cloud Files sync root, self-identifying as a sync provider with a hardcoded provider GUID and creating a placeholder file. It then creates two directories beneath the object manager's \BaseNamedObjects\Restricted\ namespace and, inside them, two conflicting symbolic links both named WD_SCAN — one initially resolving to the working directory holding the placeholder, the other to a path used by the Common Log File System. It opens Defender's interface directly, resolving the management, scanning and clean functions out of MpClient.dll at runtime, and asks Defender to scan the placeholder through a \\.\globalroot\...\WD_SCAN\ path. A background thread watches for the CLFS transaction log that Defender's clean operation creates, and the instant it appears takes an exclusive lock on it — freezing Defender mid-transaction. With the operation held open, the proof-of-concept deletes the shadow WD_SCAN link and recreates it pointing at \??\UNC\127.0.0.1\C$\Windows\System32\phoneinfo.dll, so the already-in-flight path resolves somewhere new without any NTFS junction being involved; it then restarts Cloud Files hydration with the file size set to the DLL's rather than the original's, so the hydration callback supplies the attacker's bytes while Defender's clean engine performs the write. Because MsMpEng.exe is the process that writes the file, the write itself looks expected — which LevelBlue flags as a triage detail that must be correlated rather than dismissed. The proof-of-concept then maps the resulting DLL as an executable image to stop remediation removing it, crafts a Windows Error Report into the report queue, and triggers the built-in QueueReporting scheduled task through the Task Scheduler COM interface method ITaskService::Run(); that task runs as SYSTEM, so the signed Windows error-reporting binary wermgr.exe processes the report and loads phoneinfo.dll with SYSTEM privileges — a trusted system binary acting as the proxy that executes the attacker's code, which is how the payload runs without the attacker ever launching a process of their own. LevelBlue states the whole sequence takes approximately eight to twelve seconds on an unloaded system, and that it "is fully self-contained and runs to full SYSTEM completion from a standard user account on any fully patched Windows 11 24H2 or Windows Server 2025 system with Windows Defender in its default configuration."
Detection, in the report's own framing, "is best detected through behavioral correlation rather than any single static indicator" — but one static indicator is close to free. LevelBlue identifies C:\Windows\System32\phoneinfo.dll as the strongest single indicator in the chain and states the file is not expected to exist natively on supported Windows versions — so its creation warrants a high-priority look regardless of the process that wrote it. (The hedge is the source's own and is worth keeping: "not expected on supported versions" is what it will bear, not a guarantee about every Windows build ever shipped.) Beyond that, and led by telemetry class: in image- and module-load telemetry, MpClient.dll loaded by a process that is not one of Defender's own small set of expected consumers — the report names MsMpEng.exe, MpCmdRun.exe, NisSrv.exe, ConfigSecurityPolicy.exe and MpSigStub.exe — is the compound signal, and LevelBlue is specific about what makes it load-bearing: "The set of expected MpClient.dll consumers is small. A load by an unrelated process becomes especially significant when followed by runtime resolution of MpManagerOpen, MpScanStart, MpCleanOpen, MpCleanStart, or MpCleanControl." The same telemetry should surface wermgr.exe loading phoneinfo.dll. In scheduled-task audit records, the QueueReporting task being started programmatically through the Task Scheduler COM interface is the execution step. In registry or filter telemetry, a sync-root registration call issued by a process that is not a cloud-sync client is the setup step. And in named-pipe telemetry this specific proof-of-concept creates a pipe with a hardcoded name, with a SYSTEM-integrity process then connecting to a pipe a normal user created — though that name is an artefact of this build rather than of the technique.
Triage: every individual event here has a benign twin, which is why the sequence is the detection. MsMpEng.exe writing into System32 is normal remediation behaviour; a cloud-sync provider registering a sync root is normal on a machine running OneDrive or a similar client; wermgr.exe running as SYSTEM off a scheduled task is normal error reporting. The discriminators are the process identities and the ordering: a sync-root registration from something that is not a sync client, MpClient.dll resolved by a non-Defender process followed by that specific clean-function set, and a QueueReporting run driven through COM rather than by the ordinary error-reporting trigger — with the whole chain completing inside roughly ten seconds. Hardening is the awkward part: because the abused component is Defender itself in its default configuration and Microsoft has declined to ship a fix so far, there is no configuration change to apply, and the vulnerable-driver blocklist and application-control policies have nothing third-party to key on.
A correction to this store's 2026-08-19 coverage of CVE-2026-18963, the CVSS 9.1 unauthenticated account-takeover flaw in the reset-credentials flow of Red Hat build of Keycloak. That entry reported the Red Hat JBoss Enterprise Application Platform Expansion Pack as recorded Affected with no erratum, and concluded that part of the affected estate had no patch to apply. Red Hat's structured product-state data records the opposite: the Expansion Pack's keycloak-services package is "Not affected", the same state as Red Hat Single Sign-On 7, and those are the only two rows in the table — every other product Red Hat lists carries a shipped erratum. No Red Hat product is affected and unfixed. Red Hat also documents an official interim mitigation the earlier entry did not carry: turning off the forgot-password flow per realm in the administration console.
The earlier entry read Red Hat's product-state table for CVE-2026-18963 as recording the Red Hat JBoss Enterprise Application Platform Expansion Pack as Affected with no erratum, and built a paragraph, a summary sentence and an action item on the conclusion that part of the affected estate had no patch available. That reading was wrong. Red Hat's structured security data records exactly two products under package_state, and both are "fix_state" : "Not affected" — the Expansion Pack's keycloak-services package, and Red Hat Single Sign-On 7 (Red Hat Product Security, 2026-08-18). Every other product Red Hat lists for this flaw appears under the shipped errata instead. The customer-portal page for the CVE embeds the same product-state data — "state":"Not affected", with the justifications "Component not Present" for the Expansion Pack and "Vulnerable Code not Present" for Red Hat Single Sign-On 7 (Red Hat Product Security, 2026-08-18). No Red Hat product is recorded as affected by CVE-2026-18963 and left without a fix.
The practical consequence is narrower than the original entry implied and points the other way. An operator running the Expansion Pack has nothing to remediate for this CVE, rather than an unpatchable unauthenticated account-takeover path — so a risk item raised on the strength of the earlier entry can be closed, and any compensating control applied to that product line specifically can be withdrawn. Nothing else about the flaw changes: the reset-credentials weakness in Red Hat build of Keycloak, its Critical rating, its CVSS 9.1 and the two fixed streams all stand exactly as previously reported, and an unpatched 26.4 or 26.6 deployment remains the priority.
The same record also carries an official interim step the earlier entry did not have. Red Hat states that where an immediate upgrade is not possible, "disabling the \"Forgot password\" functionality across all realms can be used as a temporary mitigation", reached in the administration console under Realm settings, Login, Forgot password, Off, and applied to every realm (Red Hat Product Security, 2026-08-18). This supersedes the reverse-proxy suggestion carried previously: turning the flow off in the product removes the vulnerable path for every client of that realm, where a proxy rule only covers traffic that traverses the proxy.
The reading error is worth naming because the shape recurs. Red Hat's package_state block enumerates the products Red Hat has assessed, not the products that are vulnerable; each row carries its own fix_state, and membership in the list says only that the product was evaluated. The same holds for the CSAF product_status groups other vendors publish and for the per-product build lists in Microsoft's Security Update Guide. Triage: a product named on a vendor advisory page is not thereby in scope — the verdict field beside it is the claim, and a product absent from the errata list may simply have been ruled out rather than left unpatched.
Switzerland's Bundesamt für Cybersicherheit (BACS) published Halbjahresbericht 2026/I — its semi-annual report on the cyber threat landscape in Switzerland and internationally — on 2026-08-24 (BACS, 2026-08-24). Two numbers frame it. Voluntary reports fell to 27,128 for January–June 2026 against 35,727 in H1 2025, with fraud (10,759), phishing (8,877) and spam (3,965) the most-registered categories. Separately, 200 mandatory reports were processed under the critical-infrastructure notification duty in force since 1 April 2025 — and their sector split is the finding this constituency should read first: the public sector and IT/telecommunications continue to be the most frequent reporters, at 19.4% and 18.6% respectively — BACS's own word is "weiterhin", continuing, so this is a persistent ranking rather than a new development. Among those mandatory reports, unauthorised system access (hacking) is the most-reported attack type at just under 26%, which BACS says consists largely of email accounts compromised through successful phishing and then reused to run further phishing and fraud against others; credential theft follows at 13.5%, with DDoS and data exfiltration tied at 12.7% each, and ransomware in roughly 8% of cases.
Three categories fell sharply, and exactly one of them is given a cause. Reports of fraudulent threatening calls made in the name of authorities fell 64% year on year to 3,817, and BACS credits the tightening of the telecommunications services ordinance against call spoofing — noting the measures likely took effect before they formally came into force. Advertising for online investment fraud fell 89% to 387 and CEO fraud 57% to 258; the report records those two as declines without attributing either to a cause, so neither should be read as evidence that a control worked. Set against that, BACS records attackers using AI systematically to produce tailored, personalised content credibly, including one CEO-fraud case in the period that used a cloned voice of the target's superior to push staff toward fraudulent transfers, and romance-scam identities built with AI-generated images, imitated voices and increasingly deepfake-supported video calls.
On initial access BACS reports no Switzerland-specific tradecraft, only global patterns — and three of them are worth a hunt. Malware by email remains a principal vector with fake invoices the commonest pretext; ClickFix, where the victim is induced to run the malicious command themselves, remains widespread, as does the fake-software-update variant, illustrated by a campaign that told targets to install a Zoom update to join a meeting. In the reporting period BACS identified at least 191 Swiss WordPress sites that attackers had compromised and seeded with malicious JavaScript, which makes a visitor's browser fetch further malicious code automatically — with blockchains increasingly used to host and distribute that code. And in a multi-stage case BACS describes, an employee's business mailbox was buried under email bombing, after which the attackers contacted the victim over Microsoft Teams posing as IT help-desk staff, talked them into granting remote access, and installed malware disguised as an update, citing Unit 42's write-up of the pattern. That is the same delivery chain this pipeline covers today from Expel's SynkLoader case, which is worth noting because a Swiss authority independently placing the pattern in its own caseload raises it from one vendor's incident to an expected local vector. BACS also records several large software-supply-chain compromises with global reach in the period, in which the compromise of widely used open-source projects spread credential-stealing software broadly and Swiss organisations were among those affected — citing the Trivy tag compromise, ground this store already holds. Elsewhere it notes attackers defeating multi-factor authentication through intercepted session tokens, device-code phishing and reverse proxies, and an international shift away from technical complexity toward the principle "log in, not break in": rather than intruding without authorisation, attackers increasingly try to obtain legitimate credentials and use them.
The Poland case study — where basic controls, not advanced defence, were the missing layer. The report's second chapter is a full anatomy of the coordinated wave of 29 December 2025 against Polish energy assets, an incident this store tracks. The Polish CERT's public attribution is of the attack infrastructure to Static Tundra, a suspected Russian state actor previously linked to energy-sector espionage — infrastructure, not the operation itself — and BACS then extends that with its own hedge, recording the Poland incident as the first publicly documented sabotage operation in which the group was apparently involved. Targets ran from 30 wind and photovoltaic parks through a large combined heat and power plant supplying heat to around 500,000 people, to a manufacturing company. The attackers went for the distributed control systems used to operate infrastructure remotely rather than the turbines and generators themselves, and at the renewables sites concentrated on the grid connection point — effectively the operator's digital control room for steering and remote monitoring.
How they got in is the part that should change a Swiss operator's priorities. Alongside exploitation of known unpatched vulnerabilities, remote-access points were exposed directly to the internet without multi-factor authentication, the same passwords were reused across multiple devices, and in several cases devices still carried the manufacturer's factory default passwords ("auf den Geräten noch die werkseitigen Standardpasswörter des Herstellers eingestellt" — in several cases the devices still had the manufacturer's factory default passwords set). Firewalls, servers and a range of OT devices were affected: controllers, remote terminal units reached over SSH, intelligent electronic devices such as protection and control relays, and Windows-based HMI workstations running a SCADA suite. Some of those systems handed the attackers system-administrator rights and so unrestricted control. Destruction was then achieved several ways: corrupting controller firmware so devices hung in an endless reboot loop, deleting operating-system files so they could not boot, and resetting other components to factory settings while changing their network configuration so they became unreachable — with wiper malware additionally deployed on the Windows control machines.
The heat plant was hit entirely through the office IT network without touching its industrial control systems, via the perimeter firewall using accounts again unprotected by MFA. There the actors took their time: over roughly a month they mapped which systems could reach the plant's industrial controls — enumerating processes, network connections, routing tables and the ARP cache, and probing file systems on machines whose names contained "scada" — then quietly stole credentials to impersonate legitimate users, including an attempt to dump the LSASS process, a forged Kerberos ticket built with a public tool, and a dump of the entire Active Directory database via ntds.dit. On 29 December they pushed the DynoWiper malware to workstations using Group Policy Objects, the same mechanism administrators use to deploy software centrally — and an endpoint detection and response product caught and blocked it before it did broad damage. A slightly modified build failed too, as did direct overwriting of server disks and manipulation of the storage system's RAID configuration. At the third victim, a manufacturer that appears to have been chosen opportunistically, the attackers did not have to defeat the perimeter firewall at all: its configuration including passwords had been stolen in an earlier, unrelated incident and was freely available on a criminal forum. Once in, they established durable access by planting automated routines on the firewall that periodically retrieved valid credentials and weakened account security settings — including disabling MFA — piping the output to a Slack channel for convenience, then moved laterally over an SSL VPN tunnel using penetration-testing tooling and deployed a second wiper, LazyWiper, again through Group Policy from a network share. In all three cases stolen credentials drove lateral movement, and — the detail most worth carrying — the same credentials were used to reach the victims' on-premises and cloud services including Exchange, Teams and SharePoint, where the actors searched specifically for files and mail concerning technical operations and ICS, OT and SCADA systems. BACS notes the campaign required substantial manual effort rather than the AI and automation the wider trend points to, and reads the timing as an opportunistic capability demonstration — signalling — rather than a strategically chosen moment, precisely because the exploited weaknesses were so basic. Its conclusion is explicit: basic cybersecurity measures, not advanced defensive technology, would have been the key to preventing these attacks — strong unique passwords, consistent MFA, network segmentation and timely patching.
For Switzerland specifically, BACS argues the exposure is not symmetrical. Large grid connection points here are for the most part better isolated than Poland's, but that assessment excludes the large number of smaller private feed-in installations, which are permanently connected to the internet and to the manufacturer's cloud — and it cites the National Test Institute for Cybersecurity's study of energy-management systems for private photovoltaic installations as establishing the resulting dependencies and broad attack surface. It also draws a supply-chain lesson from a March 2026 case in which Iran-linked attackers claimed to have wiped all reachable devices of a US medical-device manufacturer by factory reset: the victim was not the most strategically relevant target available, but the attack carried a public message — and Swiss business customers of that manufacturer were affected downstream, unable to place their next order through established channels.
The Dream Job playbook, measured in Swiss cases. The third chapter documents crypto theft run through a staged recruitment process against Swiss individuals and companies in the crypto, blockchain and Web3 sectors, which BACS assesses resembles patterns other authorities have attributed to actors operating on behalf of the DPRK — the campaigns tracked publicly as Operation Dream Job and, in its newer variant, Contagious Interview. The actors first identify people in key positions with privileged access to systems and funds — an independent software developer, or the founder of a crypto organisation — then profile the target's preferred technology stack, personal interests, investment intentions, access to company funds and wallet size. The approach comes on LinkedIn from a well-connected, polished headhunter with an offer that is hard to refuse: to earn a generous six-figure salary a developer need only run a test application and fix its bugs, which means fetching code from a repository that silently compromises their system. For less technical targets the lure is tailored differently — a venture capitalist hunting the next unicorn, or a well-paid operations-manager role for a back-office employee — and runs through a video interview on genuine conferencing software where the connection appears to drop, the interviewer persuasively proposes a quick hotfix to repair the tool, and the "fix" pulls trojanised software dependencies or downloads a second-stage payload named OtterCookie or BeaverTail. Those payloads execute only in memory, harvest credentials, tokens and wallet keys to the operators' infrastructure, and often lead to a bespoke DPRK backdoor for persistence; BACS notes no case has been reported of any other known actor using those specific samples. The attackers then attempt lateral movement into the victim's employer network to steal further assets.
In Switzerland such reports have risen steadily over five years to more than 20 confirmed cases, with victims often connected to the crypto industry in roles from engineer to executive, and losses running "von einigen Tausend bis hin zu rund 60 Millionen Schweizer Franken" (from a few thousand up to around 60 million Swiss francs). BACS is contacted weekly by targets who spot the approach in time — and received just as many reports from victims who realised only afterwards. It expects the true figure to be considerably higher, and names the reason as a structural one rather than a technical one: shame, information asymmetry and lack of awareness. The asymmetry it stresses is between employee and employer. Staff have little incentive to tell their employer about a security breach arising from a job search, which buys the attackers time to work laterally — and BACS has seen cases where several employees of the same company were approached, on the reasonable assumption that they would not compare notes with each other.
Triage: for the Dream Job chain the discriminator is sequence and endpoint role, not the sample. A developer workstation fetching and building an unfamiliar external repository is routine; the same host doing so shortly after an inbound recruiter contact, followed by an in-memory payload reaching out to previously unseen infrastructure and then authenticating to internal systems, is the chain. For the conferencing variant, the tell is a user-run "hotfix" during or just after a video call on legitimate software — a genuine conferencing client updates itself through its own updater and does not ask a user to paste or execute a repair command. BACS's own reporting-behaviour finding is the operational corollary: because the initial compromise arrives through a private job search, the employer usually learns late or not at all, so make it explicitly safe and expected for staff to report a suspicious recruitment approach without implying fault — the report's evidence is that several employees at one company were approached and none compared notes.
auf den Geräten noch die werkseitigen Standardpasswörter des Herstellers eingestellt.
Höhe von einigen Tausend bis hin zu rund 60 Millionen Schweizer Franken.
Statt unautorisiert in ein System einzudringen, versuchen die Angreifer zunehmend,
Bundesamt für Cybersicherheit (BACS)
annual-report24 Aug 09:10Zsingle-source · national CERTOpen finding ↗
Restrict external and cross-tenant Microsoft Teams chat to an allow-list of federated domains, or disable it — the delivery depends on an unsolicited message from an outside tenant reaching an end user, and this is a tenant setting rather than a detection.
Scan full Git history, published container image layers, package-registry artefacts and CI job logs for AWS credentials — not just the current working tree — and treat every hit as live until a caller-identity check proves otherwise, because 88% of the keys in this study still authenticated.
2026-08-24T0906Z-intel· Opus 5 · window 24 h · 0 entries published
Verification & coverage notes
This fire published nothing, and the reason is an environment defect the operator needs to see.
The container this routine started in had a system clock roughly ten days behind real time. date -u returned 2026-08-14T04:17:18Z at start and stayed on 14 August through every phase; the clock resynchronised to the true date, 24 August, only during the publishing chain. Everything the fire computed from the clock was therefore wrong in the same direction:
the run id was 2026-08-14T0417Z-intel;
the previous-run anchor resolved to 2026-08-13T0412Z-intel, giving a 24 h gap and a 26 h window, when the real previous run was 2026-08-24T0110Z-weekly about eight hours earlier;
the prior-coverage index was built for 31 July – 13 August and so was blind to the nine days of entries published between 15 and 23 August;
entries were composed into entries/2026-08-14/, a date the store deliberately has no entries for.
Compounding it, the content the research sweeps actually reached appears to have been stale by about the same margin: every domain independently reported its newest available material as dated 12 or 13 August, and no source surfaced anything from the following ten days. Whether that is the outbound path serving cached responses or something else, the effect is that the fire researched a window that had already been covered and closed.
What the fire produced, and why none of it shipped. Thirteen entries were composed, passed the mechanical gate, and went through six verification iterations on alternating models before the clock skew came to light during the sync with main. Checking them against the store settled it immediately: all six CVEs the run recorded as new were already in the index, first seen on 15 or 16 August, and main already carries entries covering the same stories — among them 2026-08-15/fortiweb-radius-wildcard-bypass-fortimanager-fgfm, 2026-08-15/cve-2026-19188-haiwell-hmi-gateway-unauth-root-rce, 2026-08-15/geoserver-jsonarraycontains-unauth-sqli-zeroday-exploited, 2026-08-15/france-dgfip-tax-authority-credential-intrusion, 2026-08-15/jwr-phishing-framework-realtime-operator-websocket-mfa and 2026-08-15/clop-windchill-philips-shell-first-victim-confirmations. Publishing would have meant thirteen duplicate entries on a misdated day page, duplicate CVE records, and a corrupted rolling window — the precise outcome the no-repetition discipline exists to prevent. The entries were therefore discarded rather than committed.
Nothing was lost that the store did not already have. The 15 and 16 August fires covered this ground properly and, on the evidence, more completely: the GeoServer zero-day that this fire's fifth verification pass surfaced as a coverage miss was already published on 15 August with exploitation confirmed.
Nothing was published for the real window either. The genuine window for 24 August, an eight-hour gap widened to the 24 h floor, was never researched, because the fire spent its whole budget on 13 August. This run therefore leaves today's window uncovered and the next fire should treat it as the gap to work from.
State changes were reverted with the entries. The additions this fire made to the CVE index, the entity registry and the source list all derived from stale research, so the branch was reset to origin/main and none of them were kept. Two of them are worth re-making by hand on a healthy fire, because they are environment facts rather than content: the Adobe security portal refuses the direct fetch path but answers the bridge, so its recipe should be bridge rather than webfetch; and the metered reader's key pool was exhausted throughout, which took out several sources and twice prevented independent verification of a CISA advisory.
Forensic surface. Everything the fire produced is preserved under work/2026-08-24T0906Z-intel/ for diagnosis: the four research findings files and two follow-up findings files, all six verification reports and their structured findings, the URL-liveness ledger, the triage record, the cleaned text of every primary that was deep-read, and the thirteen discarded entries under discarded-entries/. The verification reports are worth keeping even though their subject was discarded — three of the six passes each found a genuine in-window omission, which is a finding about the research sweep that holds regardless of the date confusion.
Known gate exception, stated rather than papered over: python3 tools/check_run.py exits non-zero on this record for one check only — prompt_version reads v3.31 while the CHANGELOG on disk now heads at v3.32. That is the same stale-clone defect in another guise: this fire read and executed v3.31, which was current in the clone it was given, and v3.32 landed on main on 21 August while the fire believed it was the 14th. The field records the prompt that actually ran, because writing v3.32 would claim the fire followed a prompt it never read. The check is behaving correctly and the mismatch is real; it is disclosed here instead of being silenced. Every other check passes.
Environment defect: container system clock approximately ten days behind real time for the duration of the run, resynchronising only at the publishing stage. Every clock-derived value — run id, gap, window, entry paths, the prior-coverage span — was wrong as a result. This will recur on every fire in a container provisioned the same way, and each one will re-publish old ground.
Environment defect: fetched content topped out around 13 August across all four research domains and every transport, consistent with cached responses on the outbound path rather than with the live web.
Reader-pool exhaustion: the metered reader reported no live keys for most of the run. Two verification passes could not independently re-fetch a CISA advisory as a result; a third reached it through the reader's anonymous endpoint and confirmed the entry, and also established that an aggregator's claim of a patched release for that flaw is invention.
Coverage gaps observed while the clock was wrong, recorded because the recipe findings are still true: depthfirst (homepage is an SPA shell with no dated listing); tenable-research (feed parses empty, listing is a JS shell); recordedfuture-insikt and google-tag (landing pages with no dated article index); trendmicro-research (feed transport failure); zscaler-threatlabz (reader pool exhausted); sygnia (bridge recovers the listing but post dates are not extractable); industrialcyber-co and nl-times (article bodies and homepage blocked on every transport); prodaft (pinned URL serves a frozen cache).
Watchlists: none configured in the organisation profile, so the product and supplier sweeps are no-ops.
Closed-source intake: none — the drop directory holds no dated subdirectories.
Verification: the six iterations recorded in the discarded run's artefacts are not carried into this record's counters, because this record publishes no entries and there is nothing for a verifier to check. The confirmation_waived field states that explicitly rather than leaving the shape of a loop that did not run on this output.
2026-08-24T0902Z-audit· audit · Opus 5 · window 355 h · 4 entries published
What this fire audited
Window: 2026-08-09T13:15:57Z (the previous audit's start) → 2026-08-24T09:02Z. That is 355 hours — a little under fifteen days, inside the 21-day cap and therefore audited in full rather than truncated. It is double the usual length because no audit fired on 2026-08-16; that missing fire is recorded below as an availability observation, not a cadence judgement.
The window holds 149 entries across 18 fires. Every one of the 149 was covered by exactly one retrospective truth pass, across nine batches alternating Opus and Sonnet. Both audit halves ran in full: nine truth passes for soundness and six independent coverage re-sweeps for completeness, three per half of the window.
Preflight ran on a wrong clock and a stale clone, and this is the first thing a reader should know
This fire's container booted with its clock reading 2026-08-16T13:13Z and a first git fetch origin main that returned refs eight days old. Neither failed loudly. The run computed a 168-hour window ending 2026-08-16, partitioned an inventory of 81 entries, and briefed eight sub-agents on it before the error surfaced — for a few minutes the evidence read as an eight-day pipeline outage, because the newest run record the clone could see was 2026-08-16T0411Z and the clock agreed it was the 16th.
Ground truth was established mid-run from an external HTTP Date header and a second fetch: the true time was 2026-08-24T09:02Z and origin/main carried eight further fires. The run was then re-anchored: new run id, correct 355-hour window, re-inventoried at 149 entries, and four further truth batches plus three further coverage sweeps spawned to cover 2026-08-16 → 2026-08-24, which the first eight sub-agents had been told was out of window. The five truth batches that had already returned were kept — they verified real published entries against primary sources, and a wrong window label does not affect a truth check — and the three first-half coverage sweeps were kept as valid for their half. Their timestamps are recorded above exactly as their checkpoints wrote them, under the pre-correction clock; the offset is +7 days 19 hours 49 minutes. The full incident is written up in work/2026-08-24T0902Z-audit/PREFLIGHT-CLOCK-INCIDENT.md.
No operator notification was sent about the apparent outage, because it was not one.
Soundness
125 of 149 entries came back clean on a cold re-read against primary sources. The verifier batches returned 19 imprecisions and 5 factual errors; this audit adjudicated one of those five down to a development rather than an error, so the adjudicated figure is four confirmed factual errors in 149 entries, all four in weekly strategic entries and all four now corrected by new entries rather than edits.
Three of the four are one defect: the 2026-W33 weekly told readers that GeoServer's actively exploited SQL injection had no vendor fix, when the fix had shipped two days before those entries published. The fourth asserted that Microsoft had never revised a vulnerability record that it had in fact revised two days after the catalogue listing that the entry was arguing about.
The adjudication is worth stating because it cuts the other way from a finding: a batch reported the NatJack research entry as factually wrong for saying only two CVEs had been assigned, on the grounds that the researcher's page now lists three. The third identifier was published on 2026-08-11, one day after that entry. The entry was correct when written and has been overtaken, which is an update, not an error. An audit that records a stale entry as a false one is manufacturing a finding.
Completeness
Six coverage re-sweeps re-researched the window from scratch. The great majority of what they surfaced was already published — the second-half sweeps independently confirmed roughly twenty distinct stories as correctly covered. What was genuinely missing came to fifteen items, of which this fire published the two most urgent and queued the remaining thirteen on state/coverage_backlog.md with the reason for each. The publish set was capped deliberately to keep the verifier loop and the publishing chain inside the wall-clock guard, not because the queued items are weaker; several are unauthenticated near-maximum-severity flaws.
What the run believed was its sharpest miss turned out, at the pre-publish sync, to be already covered by a late-promoting fire — see the post-merge section at the end. The transport story below still stands on its own: A Joomla third-party-extension disclosure stream produced two unauthenticated CVSS 10.0 flaws and a CVSS 9.2 SQL injection inside this window, none of them published — and this is the third audit to recover a miss from that one publisher's stream — 2026-07-26, 08-02 and this one, and deliberately not described as consecutive, because the 08-09 audit recovered nothing from it and read that as the rule working. The cause turned out to be mechanical rather than editorial: the only source in the list that publishes those disclosures was pinned to the metered reader transport, and every reader key is exhausted, so the source had effectively stopped existing while continuing to look healthy. Its working feed was found and the record fixed this run.
Reader pool: the last-resort transport is down, and it is now blocking verification
Every configured reader key reports exhausted, with a combined balance far below zero. This has moved past a capacity warning. One truth pass could not verify a patch date because the vendor's own record is a JavaScript-only page and the reader was the only route to it; the coverage sweeps logged several sources they could not read for the same reason; and one source-coverage fix this audit wanted to ship — a direct record for a research publisher whose work the store already cites four times — cannot be shipped honestly, because that publisher's site is client-rendered and the only transport that reads it is the one that is down. Adding a source pinned to a dead transport is precisely the bug this audit just fixed elsewhere.
Telemetry and machinery
Eighteen fires, all eighteen carrying publish_status: ok, so the Phase 7 amendment landed every time. Verifier convergence recovered: 5 of 18 fires reached a confirmed two-model double-CLEAN, against 2 of 12 in the previous window, with the mean iteration count at 4.9. The recovery is concentrated in the second half of the window — four of the eight fires from 2026-08-17 onward converged. The rotation held on every one of the eighteen fires with no blocked spawn anywhere, which means the model-override ladder shipped for exactly this problem was never exercised; what changed was iteration counts rising, not the ladder working.
Discipline drift reversed on the metric that had been rising for three windows. Actions per operational entry fell from 1.09 to 0.80 against a store baseline of 0.58, the share of operational entries carrying no action rose from 23% to 42%, and the verifier's action-item findings fell from 3.0 to 1.1 per ten fires. The high share eased slightly to 50.0%. Every one of the 149 entries carries a rating, no behaviour-kind entry has an empty technique mapping, and no entry carries more than three actions.
At the time of writing, three days in the window appeared to have no run record — 14, 21 and 22 August — with the 16 August audit slot a fourth; the pre-publish sync reduced this to 2026-08-14 alone (see the post-merge section). Every following fire derived its own window from the gap and disclosed it correctly, so no coverage hole opened; the 2026-08-15 and 2026-08-23 fires both worked catch-up windows and said so. Cadence is the operator's to set and is not assessed here, but four missing fires in fifteen days on schedules that were otherwise firing is an availability signal worth the operator's attention, and it is the reason this audit's own window was twice its normal length.
The defect that made every duration in the store a floor
The most consequential systemic finding is not about content. Through v3.31 the run record's completed timestamp was stamped in Phase 5 — before the mechanical gate and before the verifier loop — so every fire's recorded duration stopped roughly where its verifier loop began. The majority of stored records have a completed that precedes one of their own children's end timestamps, by up to 125 minutes. No exact fraction is recorded here: three independent recomputations in this run's own verifier loop gave 103 of 146, 100 of 141 and 104 of 148, moving with how the denominator is defined and whether this fire's record is counted. The worst skew and the illustration below reproduced identically every time. One fire records 52 minutes for work its own notes place at nearly three hours, with its last verifier iteration returning almost two hours after the recorded completion.
The reason this matters is that the three-hour wall-clock guard is checked against exactly that number, so the guard had no machine-readable signal capable of seeing an overrun, and every audit line reading "no runaway this window" — including the previous audit's — was reading a floor rather than a measurement. The defect had also been diagnosed once already, by a verifier on 2026-08-10, and fixed only in the single record where it was found while the mechanism stayed broken. A verifier finding repaired only in the record it was found in is a fix that did not ship.
Both halves are fixed this run: the stamp is now taken immediately before the commit, and the gate rejects any new record whose completion precedes its own children. The check is scoped to records from this prompt version onward, because those 100 earlier records are immutable and reporting them would create a hundred warnings whose only resolution would be to acknowledge them.
Wall clock: 6.4 h, and the warning is the point
This record trips the runaway threshold at 11.4 h, and it is the first record in the store ever to do so
honestly — every earlier fire's duration stopped where its verifier loop began, which is the defect this run
fixed. The warning is left standing rather than acknowledged, because it is a true telemetry fact about this
fire and the discipline reserves the acknowledgment ledger for settled history that cannot be corrected.
The cause was not scope. Roughly three hours were spent working; the rest was two separate blocks waiting on
a provider session limit — one that terminated verifier iteration 3 before it read anything (about four and a
half hours until the reset) and one that killed the first attempt at iteration 6 the same way (about four
hours). Research and truth passes had all returned before the first block; nothing was lost and nothing was
left unverified because of either. Two smaller costs are worth recording: the preflight clock incident cost
about fifteen minutes, and the audit's own gate check caught this record's completion timestamp three times
before it was stamped correctly — first because the value was arithmetic rather than a clock read, then twice
because the loop kept running after the stamp, which is precisely the failure mode the check exists for.
Read against the guard's intent — do not let a fire drift so long that a later scheduled fire overtakes it —
nothing was overtaken: no intel or weekly fire ran during the block, and the sync before commit confirmed it.
Zero-warning sweep
python3 tools/check_run.py --all ends 1 warn · 0 fail with 14 acknowledged, and python3 site/build.py emits no self-check warnings. The one warning is this record's own runaway duration — a true telemetry fact this run must not self-acknowledge; the next audit reviews it (see § Wall clock). No acknowledgment was added this run and none was pruned: all 14 existing rows still silence a live warning, and nothing this fire found needed the ledger — every warning-class defect it touched had a real fix. One candidate mechanical check was deliberately not shipped: flagging a no-patch status alongside a patch-available one would have caught the GeoServer defect's shape but also flagged 27 correct records across 15 entries — 3 carrying both statuses in one record and 26 carrying a no-patch status alongside a prose fixed string that exists to explain why there is no fix — because a partially-fixed product estate legitimately carries both.
Coverage and watch items
Coverage gaps: claroty-team82 (listing carries no dates and no recency ordering; the sitemap route that worked for another publisher this run has not yet been probed there); cisa-directives and cisa-advisories (Akamai 403 plus the exhausted reader, consistent with four prior consecutive-failure runs; the structured mirror substituted for the industrial-advisory surface); trendmicro-research (genuinely silent since 2026-07-30 on both feed and listing); cybereason (reachable but no post in over six months — a dormant publisher rather than a transport problem, and absent from the source list in any case).
The dark-source watch item narrowed substantially and partly on a measurement correction: the previous audit's "green but contributing nothing" figure was computed by matching cited URL hosts against each source record's own url, which misses a publisher reached on a different host or summarised in a weekly roll-up. Over the true window dragos contributed two cited sources, and the Swiss security-hub feed was the single highest-yield source of the second half. Four essential-tier records still contributed nothing, and this run's sweeps established by full-body fetch that each is reachable and carrying non-vulnerability content by design rather than silently failing.
Borderline items correctly not published are recorded in the audit report, along with two French extortion claims that fail the fake-news guard on current evidence and stay unpublished.
Post-merge: overtaken by a second audit, and what changed before commit
The Phase 6 sync pulled late-promoting fires this run could not see — among them 2026-08-23T1311Z-audit, a second quality audit over an almost identical window, plus the 08-21 and 08-22 intel fires and their entries. Per the overtaken-run rule, every not-yet-pushed artefact was re-deduplicated against the newly visible state before commit:
The SPIP entry was rewritten as an update_of delta on 2026-08-22/spip-two-unconditional-preauth-rce-releases-three-days-apart, which the late-promoting 08-22 fire had already published — carrying only the 2026-08-24 identifier assignments (CVE-2026-77806; CVE-2026-77647 to CERT-FR's companion advisory). The other three entries collide with nothing.
This run's duplicate run-clock gate check was discarded: the 08-23 audit found the same completion-timestamp defect independently and its v3.33 fix (check_run_clock, the Phase 6 re-stamp) reached main first. The two remaining changes this run's prompt work adds — the preflight ground-truth checks and the no-patch-from-vendor rule — ship as v3.34 on top of their v3.33, with the collision disclosed in the CHANGELOG. This record's prompt_version is v3.34, the version as of the commit; the loop above executed under this run's own v3.32 draft.
The backlog files were merged (their base; their GeoServer correction-owed row struck as fulfilled by this run's published correction; this run's Cisco Crosswork and Bloctel rows dropped as covered by their side; twelve of this run's rows re-appended), and the mysites-guru, nozomi-networks, claroty-team82 and forescout-vedere source fixes were re-applied on top of their sources.json, whose own tenable-research fix (a different working feed URL) was kept over this run's.
The availability finding narrows to 2026-08-14 — the only genuinely record-less day once the late promotions landed. Two separate operator signals replace it: several fires' promotions sat unmerged long enough that two audits planned against a stale picture, and two fires on 2026-08-24 booted with container clocks reading 2026-08-16 (this one recovered mid-run; 2026-08-24T0906Z-intel stood down).
Un-audited residue, bounded and named: the 08-21 and 08-22 entries were never truth-checked by this run's batches (they were invisible at partition time). The next audit should confirm the 08-23 audit's batches covered them and truth-check whatever was not.
The full reconciliation is in the audit report's post-merge addendum.
2026-08-24T0410Z-intel· Opus 5 · window 24 h · 7 entries published
Verification & coverage notes
This fire ran 4 h 47 min behind itself before it did any research. The container stalled between preparation and the start of research — the run's own start stamp reads 04:10:43Z while the four research workers did not begin until 08:54–08:55Z — so the wall-clock watchdog was already tripped before a single source was fetched, without a minute of research time having been lost. The run was landed under that constraint: the research stage was allowed to finish because it had only just started and was the run's entire research surface, but no scope was widened afterwards, no research was restarted when one domain died, and composition ran in a single pass. The duration_seconds recorded above is the honest wall clock and is not a measure of work performed.
The stall had one fortunate consequence. Switzerland's federal cyber authority published its half-year threat report under an embargo lifting at 09:00 UTC, and the coverage-backlog row for it existed precisely because both the weekly that surfaced it (research window closed 01:15 UTC) and this scheduled fire (nominal start 04:10 UTC) were expected to miss it. The stall put the research window on top of the publication instead. The home-region research was re-tasked mid-flight and caught the report minutes after it went live, and it became this run's deep dive.
Coverage gaps. The research and investigative-reporting sweep did not happen. That work was terminated about twelve minutes in by a content-classifier trip rather than by its time cap, so it wrote no findings file and its domain — vendor and independent threat-research labs, OT/ICS research, investigative reporting — has no sweep behind it this run. It was deliberately not restarted, because the watchdog forbids starting new research that far past the start, and because six of this run's seven published entries are research-domain material worked from the coverage backlog and re-verified directly against the primaries. This is a real hole in the window's completeness and is recorded as one, not softened: genuinely new research published on 2026-08-22 to 2026-08-24 by a lab outside those six primaries would not have been seen. The other gaps are transport, and all seven are logged in full above. Seven sources remain reachable only through the metered reader, whose pool is exhausted on all seven keys — which is what blocked the Spanish national CERT and the vulnerability-disclosure programme behind a standing backlog row, and what left two client-rendered regulator listings unread.
Coverage gaps: cisa-advisories (403, ninth consecutive run, all transports incl. reader); cisa-directives (403, eighth consecutive run); siemens-productcert-csaf (403, partial CSAF-mirror substitute); ssd-disclosure (empty body, reader-only source, pool exhausted); ccn-cert-es (reader-pinned, pool exhausted); ico-uk (200 but client-rendered, reader needed); ncsc-uk (200 but page shell, ladder not exhausted under wall-clock pressure); research-domain sweep (terminated by a classifier trip — no sweep performed).
Essential-coverage: missed=ncsc-uk (client-rendered listing, structured recipe not attempted before that work returned), cisa-advisories (403 on every transport), cisa-directives (403 on every transport).
This fire was overtaken, and the window was re-deduplicated on sync. Three other fires landed on main while this one sat mid-pipeline through a container stall and an account session limit. The 2026-08-24T0906Z-intel fire published the Cisco Secure Workload and Crosswork critical tail — the very item this run had recorded as a coverage-backlog row because it failed only the recency gate — so that row was struck before it was ever committed. More consequentially, the long-delayed 2026-08-22T0410Z-intel fire finally landed its own treatment of the SOCRadar FTP-banner dead-drop research, which this run had also composed from the same primary. That entry was dropped rather than published alongside the earlier one: same source, same event date, no material delta, and the earlier treatment is the fuller of the two. The entity namespace was reconciled the same way — the earlier fire had registered the two malware families as malware:e4del and malware:pinhole-rat, and this run's proposed malware:pinhole would have been a second key for a family that already had one, so it was removed before commit rather than becoming a duplicate the registry would have to tombstone later. The third overtake cost a second entry on the same grounds. The 2026-08-23T1311Z-audit fire's own retrospective truth pass had independently reached the same finding about Red Hat's product-state table for the Keycloak account-takeover flaw and published its correction as 2026-08-24/cve-2026-18963-keycloak-no-red-hat-product-unfixed, so this run's correction of the same record for the same CVE was dropped rather than published beside it. One fact from this run's own parse of that data is not carried by the surviving entry and is not being lost: the vendor's machine-readable product-state document for the flaw was revised on 2026-08-20, the day after this store's erroneous entry was written, which bears directly on the surviving correction's statement that there is no evidence the product state ever read differently. That is a fact about how this pipeline erred rather than something a defender acts on, so it is recorded as a correction owed on the surviving entry in state/coverage_backlog.md and left for the weekly audit to weigh, not published as a third entry on one CVE. What this run published is therefore seven entries, not the nine it composed. The same sync also revealed that main had independently gained a PDF-extraction recipe in the fetch bridge, better than the one written here (it selects on content type, tries mirrors, and distinguishes an image-only PDF from an empty one), so this run's version was discarded in favour of it and only the carve-out host-list fix was kept.
What was published, and why seven. Six of the seven entries clear the backlog the weekly stand-down of 01:10Z handed over — items that fire had already researched, deep-read and quote-verified but could not publish. Backlog rows are exempt from the recency gate because each was verified in-window by the fire that surfaced it and its age reflects a pipeline race rather than staleness; every one was still put to the relevance gate on today's facts and deduplicated against the fourteen-day index. Working that queue down is why this window is longer than the day's genuinely-new signal would suggest, and it is not volume inflation: the alternative was a silent hole, which is exactly what happened to the nine verified items a weekly stand-down listed on 2026-08-03 and never published. One of the seven is a mechanism update on ground the store already holds. A second correction — of a published error of this pipeline's own that overstated exposure on a CVSS 9.1 unauthenticated account-takeover flaw, and could have led a reader to defer it as unpatchable — was composed here and then dropped, because another fire had reached and published the same correction while this one was mid-pipeline; the fix is in the store either way.
Two entries carry a sourcing caveat worth restating here because both were near-misses for a fabricated link. The ShieldBreak mechanism entry ties its research to CVE-2026-69414, but the research names no CVE anywhere — re-confirmed this run by a case-insensitive search of the freshly fetched page body — so the linkage is this pipeline's reading of two accounts of the same named technique and the entry says so rather than implying the researcher made the connection. The ReliaQuest entry began as a piece about a circulating compromise claim set against the victim's own account of what happened, and the review pass established that its only cited source never mentions that claim at all — no extortion brand, no listing, no screenshots. Everything the source would not bear was removed rather than propped up with a weaker second source, so what publishes is the victim's own disclosure and the control lesson in it; the entity key was renamed for the same reason.
Entity-overlap decisions, confirmed deliberate. Two of this run's entries share entity keys with earlier in-window coverage and were still published as new entries rather than deltas; both calls were made knowingly. The half-year report entry links the Dream Job campaign key, which also appears on the 2026-08-12 entry about a Windows zero-day used by a state actor and on a weekly synthesis piece — but this entry is not a development in that campaign, it is the first coverage of a national authority's periodic report, whose Dream Job chapter contributes something neither earlier entry could: Swiss case counts, Swiss loss figures and the authority's own reporting-behaviour finding. Making it an update of a zero-day entry would have buried the report. The SilkParasite entry shares its campaign key with two 2026-08-23 weekly synthesis entries that name the cluster in passing; neither is an operational entry about it, none of its five newly named malware families was registered, and the reusable detection formulation appears in neither — so this is first dedicated coverage, not a delta, and the strategic-to-operational direction is the one the division of labour permits.
Single-source items and carve-outs. Every one of the seven entries is single-source, which is unusual for this
pipeline and is stated plainly rather than smoothed over: this window's publishable signal was, almost entirely,
individual parties reporting their own work or their own incident. Exactly two carry a carve-out value. The
half-year report entry is single-source-national-cert — BACS is the disclosing authority for its own assessment
and the report was minutes old, so no independent pickup existed; where it relies on another party's work (the
Polish CERT's incident analysis and Static Tundra attribution, a vendor's Teams help-desk research, a national
test institute's photovoltaic study) the entry attributes it there rather than to BACS. The ReliaQuest entry is
single-source-victim. The remaining five are plain single-source: the ShieldBreak
mechanism, SynkLoader, the Rapid7 quarterly, the AWS-key measurement and SilkParasite. One carve-out boundary was
tested and got recorded wrong here before it was caught, and is worth restating because the entry that carried it
was the one later dropped as a duplicate: a vendor's own product-security team is a first-party authority on its
own products, but it is not one of the two carve-outs the policy defines — a national CERT or government authority
for its own jurisdiction, and a victim's own disclosure — so vendor-only sourcing is plain single-source, never a
carve-out. Each of the five carries its limitation in its own note rather
than borrowing confidence from corroboration it does not have.
One internal tension in the half-year report is carried in the entry rather than resolved: its management summary describes reporting as having stabilised at a high level, while its first chapter states the voluntary total as a decline against the prior year's figure. Both are the report's own statements and the entry says so.
Borderline drops.
borderline-drop: Berlin Landesnetz compromise — fifth consecutive fire blocked on the same ground. The home-region research was tasked to establish one thing only: whether any named authority has since stated an access vector, product or CVE. None has, and the sole vector-adjacent claim in circulation is still an unattributed broadcaster characterisation. An incident entry needs an evidence-bound technique mapping and there is no attacker behaviour to map; inventing one is the defect class a prior audit repaired. The backlog row stays open.
borderline-drop: Cisco Secure Workload / Crosswork critical tail — eight critical flaws, five at CVSS 10.0, which the W34 weekly roll-up itself flagged as covered by no earlier fire. Relevant and uncovered, but the underlying disclosure is dated 2026-08-19/21 with no in-window delta, so it fails recency for a fresh item today. Recorded as a coverage-backlog row so a later fire publishes it as first coverage rather than losing it.
borderline-drop: CVE-2026-16242, Red Hat OpenShift / HyperShift Konnectivity proxy — an unauthenticated path into the control-plane-to-node channel, CVSS 9.4, fixed in 4.22.8, and never given a dedicated entry. Dropped on recency: published 2026-07-20 with the vulnerability database's dateUpdated bump being a resync rather than new disclosure. Also recorded as a backlog row.
borderline-drop: Zoom annotator buffer overwrite CVE-2026-53413 — out-of-window (primary sources 2026-08-11 to 2026-08-20), no in-window delta, dropped despite an eye-catching name.
borderline-drop: DJI consumer drone CVEs, a Turkish smart-meter authentication bypass, a GNU gzip local decompression overflow — off-scope for this constituency: physical-proximity or local vectors, no exploitation, no evidenced European public-sector or critical-infrastructure deployment.
borderline-drop: Japanese domestic-market product advisories — fresh but with no evidenced Swiss or European deployment base.
borderline-drop: three leak-site-only listings naming one Swiss and two German organisations — fake-news guard: attacker assertions with no victim, regulator or high-reliability corroboration.
borderline-drop: five vendor OSS-mirror CVE records published 2026-08-23 — exploitation and public-disclosure fields both null, no action beyond the regular patch cycle.
A note on the version recorded above.prompt_version says v3.31 because that is the prompt this fire actually read and executed. While it was mid-pipeline an overtaking fire bumped the master prompts to v3.32, so the changelog on main now leads this record by one version. The gate's cross-check treats a trailing version as a versioning-rule breach — a prompt edit shipped without its changelog entry — and flagged it, which in this case would only have been "fixable" by claiming to have run a version this fire never saw. The check was therefore taught the distinction rather than satisfied with a false value: it now compares the working tree's prompts against origin/main, and a trailing version reports as informational when this run edited no prompt or agent definition. A genuine prompt edit shipped without a changelog bump still fails exactly as before.
State and tooling. Two tooling defects were fixed rather than logged for later. The half-year report's PDF as first fetched was corrupted — 2,840,294 bytes of mangled content against 1,733,418 bytes on a clean binary re-fetch — and every PDF library in this container fails to import because the pre-installed cryptography package is missing its _cffi_backend binding; stubbing that broken import chain made all 23 pages extractable, which is why the deep dive is composed from the report body rather than its press release. Both worked, so the deep-dive entry rests on the primary. The PDF workaround was then made permanent rather than left as a run anecdote: tools/fetch_source.py gained a pdf <URL> recipe that fetches in binary, refuses a non-PDF body with a clear message, survives a single unreadable page and raises a distinct error on an image-only document, verified against the same 23-page report. That closes the half of the standing Siemens S7 backlog row which asked for a working extraction path to be recorded in the bridge — a row opened because the 2026-08-20 run had to compose a five-agency advisory single-source from an outlet's reading for want of exactly this. It is deliberately NOT yet referenced from the research agents' fetch-tooling section: that would be an agent-definition edit, which must ship a banner bump across all three master prompts, a CHANGELOG entry and a byte-identical regeneration of the alternate verifier in the same commit, and this run is too far past its watchdog to take that on safely. The recipe is discoverable via --help and is recorded in .claude/memory/source-fetch-blocks.md, which every future fire loads; a run with headroom should do the definition edit. The source-health sweep probed 191 of 191 sources in 127 s and returned no unsolved repair order, which is consistent with the three recipe corrections this run made rather than deferred: a reader-pinned source proven reachable by the cheapest transport, and both Swiss authority records moved off a transport their site migration broke.
Watchlist: the organization profile configures no product and no supplier watchlist, so both sweeps were no-ops and neither agent spent time on them.