Switzerland's federal IT provider BIT confirms a SharePoint Server intrusion: ~200 federal user and technical accounts compromised while the July patches were already being installed

Switzerland's Bundesamt für Informatik und Telekommunikation — the federal IT service provider that operates the Confederation's own data centres — disclosed on 2026-08-04 that attackers reached its on-premises SharePoint Servers and took the credentials of roughly 200 accounts (Der Bundesrat / BIT, 2026-08-04). BIT names the actors as previously unknown and states the intrusion was "mutmasslich" — presumably — enabled by exploitation of the SharePoint flaws Microsoft disclosed in mid-July 2026; no source names a specific CVE for this intrusion, and none should be inferred. Both user accounts and technical service accounts were affected, passwords were reset immediately, and BIT states there is no indication that anything beyond those credentials was exfiltrated (Der Bundesrat / BIT, 2026-08-04).

The timeline is the operationally interesting part, and it is uncomfortable. BIT began installing the July security updates immediately after Microsoft released them. Security staff nonetheless noticed anomalies on the SharePoint servers on Tuesday 28 July, blocked internet access to SharePoint and closed the vulnerabilities once the suspicion was confirmed, and only during forensics on Friday 31 July established that account credentials had been compromised (Der Bundesrat / BIT, 2026-08-04). A patch programme that started on time still left a window in which an internet-facing farm was reachable and exploitable, and the compromise of credentials was confirmed three days after the anomaly itself. For any organisation measuring its own exposure by "we patched promptly", that gap is the lesson: promptness is measured against the attacker's start, not the vendor's release.

Why a rebuild rather than a patch. BIT is reinstalling the affected servers from scratch as a precaution and keeping internet access to SharePoint closed for non-federal users until that work completes, while federal staff keep internal access through alternative routes. The reason that is proportionate is visible in the wider wave: The Record reports that in this exploitation campaign attackers were extracting machine keys from Microsoft's Internet Information Services (The Record, 2026-08-04), and CISA describes the same behaviour — stealing IIS machine keys and performing deserialization techniques to gain persistence and deploy malware (CISA, 2026-07-14). Machine keys sign and encrypt ASP.NET ViewState and session material, so an attacker holding them can mint tokens a fully updated server still accepts. Neither source states that this specific mechanism was used against BIT, and BIT does not describe post-exploitation activity — but it is the reason patching alone does not close out this class of intrusion, and rebuilding does.

The credentials are the live risk, not the documents. BIT notes that confidential information and specially protected personal data are not permitted on the SharePoint platform by federal policy, which bounds the data-exposure question. It does not bound the identity question: roughly 200 valid federal accounts, including technical accounts, are exactly the material an intruder converts into onward access elsewhere in the estate. Technical and service accounts are the sharper end of that — they typically authenticate non-interactively, are excluded from interactive-logon MFA, often carry broader-than-necessary rights, and their password rotation is frequently coupled to application configuration rather than to an identity lifecycle.

Detection concepts, telemetry class first. In web and application access logs on SharePoint front-ends, unauthenticated POSTs to SharePoint administrative endpoints are the exploitation attempt itself; CISA names AMSI signature classes for the ToolPane authentication-bypass and sign-out request-body patterns, and an AMSI hit on a SharePoint web application is the cheapest positive signal available (CISA, 2026-07-14). In process-creation telemetry with parent lineage, any child process under the IIS worker hosting a SharePoint application pool — a script interpreter, an encoded command line, a certificate or key utility — is anomalous on a healthy SharePoint server. In file and configuration telemetry, reads or exports of ASP.NET machine-key material outside a documented farm operation are the persistence step. In authentication telemetry after remediation, successful sessions carrying valid but unexpected tokens, and technical accounts authenticating from source hosts or at times inconsistent with their automation pattern, are what a forged-token or credential-reuse follow-on looks like. In egress telemetry, a collaboration server initiating outbound connections is worth a look on its own — a document server is a destination, not usually a client.

Triage: farm maintenance, Microsoft update installers and backup agents also spawn child processes under IIS-adjacent service accounts and also read farm configuration, so the child-process signal alone is noisy. The discriminators the cited guidance supports are whether the activity falls inside a scheduled maintenance window, whether the parent is the SharePoint timer or administration service rather than the internet-facing application-pool worker, whether the binary is signed and in its expected path, and whether a technical account is being used from more than the one source host it should ever appear on.