What BIT Confirmed

Switzerland’s Federal Office for Information Technology and Telecommunication runs IT for much of the federal administration. BIT confirmed that roughly 200 accounts were compromised. Microsoft had already released security updates, and BIT had begun deploying them before suspicious activity was detected. The agency said the cyberattack was suspected to have been enabled by exploitation of recently disclosed SharePoint vulnerabilities.

The agency, known as BIT, disclosed the breach on August 4. The intrusion started earlier, and the gap between those two dates tells most of the story.

What was the July 2026 SharePoint exploitation wave? On July 14, Microsoft disclosed five vulnerabilities in on-premises SharePoint Server. Attackers were exploiting four of them within two days. CISA confirmed active exploitation of several the same day patches shipped, leaving defenders almost no window to act first.

Seven Days From First Signal To Public Disclosure

BIT observed something strange happening on their SharePoint servers on July 28. Their login patterns were not as usual.

Confirmation happened only on July 31. The experts concluded that the credentials of some of the accounts were compromised. The breach was publicly disclosed on August 4, seven days after the initial anomaly was detected.

Immediate reaction was given upon confirmation. BIT blocked all external internet connections to the SharePoint environment. It updated its servers, changed all passwords, and began the process of rebuilding the servers from scratch.

Exact Exploited Vulnerability Remains Unconfirmed

Neither BIT nor any other party has provided the information about which vulnerability was exploited by the hackers. The public disclosure does not establish which specific CVE was exploited.

None of the hacking groups has claimed responsibility for the attacks. No ransomware groups has leaked the information on the agency to the Internet and no extortion demands has been made public.

Security Updates Were Available Before Detection

This is the part worth sitting with. Microsoft had released security updates before BIT detected suspicious activity on July 28. BIT says it began deploying those updates immediately after publication.

The pattern is not new for on-premises SharePoint. Earlier this year, internet scan data counted more than 1,300 SharePoint servers still reachable from the internet and still unpatched against a flaw already confirmed under active exploitation.

This was flagged in early July, when CISA and Microsoft disagreed publicly about whether a SharePoint flaw was really being exploited. CISA said yes and set an urgent deadline. Microsoft rated exploitation “less likely.” That ambiguity is precisely the kind of thing that stretches a patch cycle from days into weeks. A month later, a national IT agency is reinstalling servers.

Policy Limited The Damage More Than Technology Did

It is one small detail that makes this look like a credential breach more than a disaster. According to BIT’s policies, no confidential information and highly sensitive personal information should be kept on the SharePoint platform.

The attackers were able to get access to the accounts. They were not able to access the information which would make this case a national security issue. There has been no indication of anything being stolen beyond the credentials themselves.

This has happened because of good data classification practices, not because of controls preventing the intrusion. The attackers were still able to gain entry, still had valid credentials, and forced a complete rebuild of the system.

Valid Credentials Complicate Detection

Once an attacker has gained access through valid credentials on the server that they should never have accessed, anything else that comes after is perceived to be normal. Logins go through successfully. Sessions proceed as expected. What triggered BIT’s alarm was an anomaly in the activity, not a malicious file.

On the other hand, execution governance sees the issue as one of control. It does not ask whether the action looks suspicious or not. Execution governance limits what the unverified process can do when it reaches the kernel boundary without first interacting with actual system resources.

Conclusion: Patch Availability Is Not Verified Protection

The BIT breach is not a story about an unavailable fix.

Microsoft had already released updates for the SharePoint vulnerabilities under consideration, and BIT says deployment was underway. Suspicious activity was detected on July 28, and subsequent investigation confirmed that roughly 200 accounts had been compromised.

Confidential information and highly sensitive personal data were not stored on the affected SharePoint platform. That classification policy limited the consequence, but it did not prevent the intrusion, protect the credentials, or remove the need to rebuild the servers.

Why This Threat Matters

The incident shows why patch availability and operational protection are not the same thing.

• A published update provides no protection until deployment is completed and verified.
• Internet-facing SharePoint combines application exposure, server risk, and identity access in one attack surface.
• Credentials obtained after exploitation can make later activity appear legitimate.
• Valid sessions may generate anomalies without producing a traditional malware alert.
• Password resets do not establish that the underlying server is trustworthy.
• Data classification can reduce the impact of a breach even when preventive controls fail.

The exact exploited vulnerability remains unconfirmed. That uncertainty does not reduce the response requirement. A known-vulnerable server, compromised accounts, and unexplained authentication activity are enough to require full investigation.

Where Defensive Control Must Operate

Xcitium Vulnerability Assessment helps identify internet-facing SharePoint deployments, missing security updates, outdated versions, and remediation gaps before an available patch becomes a missed control.

Once account compromise occurs, Xcitium ITDR helps identify abnormal authentication, suspicious credential use, unexpected session behavior, and activity that no longer matches the legitimate account owner.

If exploitation reaches code execution on a supported SharePoint host, Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, governs unknown post-exploit scripts, tools, and payloads before they receive unrestricted access to real system resources.

That execution layer is secondary to patching and identity recovery. It does not replace either one.

Restore Trust Beyond the Patch

Updating SharePoint closes the known vulnerability. It does not prove that the server, credentials, sessions, or related secrets remained trustworthy before the update.

Recovery should verify patch completion, remove unnecessary internet exposure, revoke affected sessions, rotate compromised credentials and relevant server secrets, review historical authentication activity, and rebuild systems where integrity cannot be established.

The objective is not only to close the flaw.

It is to prove that trust has been restored across the server, the identities, and the data they can reach.