Swiss Government SharePoint Breach: 200 Accounts Compromised — Detection and Hardening Guide for On-Prem SharePoint Defenders | Security Arsenal

Switzerland's federal IT office has confirmed that attackers exploited security vulnerabilities to breach Microsoft SharePoint servers operated by the government, compromising approximately 200 accounts. While the technical details released so far are limited, the pattern is one every defender running on-premises SharePoint should recognize immediately: internet-facing collaboration platforms remain one of the highest-value, highest-exploitation-rate targets in the enterprise stack.

This is not an isolated event. On-premises SharePoint has been under sustained attack throughout 2025 and into 2026, with nation-state operators and financially motivated groups alike treating unpatched SharePoint farms as a reliable initial-access vector. When a federal government's IT office takes a hit, your organization's exposure should be your next conversation.

What is at stake in a SharePoint compromise:

Account takeover at scale — 200 compromised accounts means harvested credentials, session tokens, and potential downstream phishing infrastructure using legitimate government identities.
Document repository access — SharePoint typically holds sensitive internal documents, contracts, personnel records, and interagency communications.
Persistence via webshells — SharePoint exploitation almost universally ends with ASPX webshells dropped into the LAYOUTS directory, giving attackers durable access even after the initial vector is patched.
Lateral movement — SharePoint service accounts frequently hold broad permissions across the domain, making a compromised farm a springboard into the wider environment.

If you run on-premises SharePoint — any version — treat this as an actionable warning. The sections below give you concrete hunting and hardening steps.

Technical Analysis

Affected Products

Based on the victim profile and the current threat landscape, the exposed attack surface for this class of incident includes:

Microsoft SharePoint Server 2016, 2019, and Subscription Edition — on-premises deployments only. SharePoint Online (Microsoft 365) is not exposed to server-side exploitation of this type because Microsoft operates and patches the infrastructure.
Internet-facing or DMZ-exposed SharePoint farms, particularly those with end-user authentication portals published to the public internet.
Farms running behind on cumulative updates — SharePoint patching is notoriously deferred because updates require farm-wide maintenance windows. Attackers know this and scan aggressively for it.

The Swiss federal IT office has not publicly attributed the intrusion to a specific named actor or disclosed the precise vulnerability chain at the time of this writing. No CVE identifier has been officially confirmed in the public reporting, and we will not speculate on one. What we do know from the current exploitation climate is that SharePoint attacks in 2025–2026 overwhelmingly follow the same playbook: unauthenticated or low-privilege exploit against a public-facing web endpoint, followed by in-memory or on-disk webshell deployment, followed by credential and configuration theft.

How the Attack Typically Works (Defender's View)

The attack chain for modern SharePoint server compromise is well-established:

Reconnaissance — Attackers enumerate SharePoint version and patch level via HTTP response analysis, leaked scanner data, or Shodan/Censys pivots.
Initial exploitation — A vulnerability in the ASP.NET / SharePoint request handling pipeline is triggered with a crafted HTTP request to an endpoint under /_layouts/15/. Successful exploitation executes code in the context of the IIS worker process (w3wp.exe) running the SharePoint application pool.
Webshell deployment — The attacker writes an ASPX file into the SharePoint web root, most commonly under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\ (or 15\ for SharePoint 2013-era paths). This provides durable, file-backed command execution.
MachineKey and credential theft — Attackers frequently extract the ASP.NET machineKey from web.config or the SharePoint configuration database. With the machineKey, they can forge valid __VIEWSTATE payloads and maintain access even after the original vulnerability is patched — this is the single most dangerous post-exploitation artifact in SharePoint incidents.
Account compromise — With code execution on the server, attackers harvest cached credentials, service account secrets from the configuration database, and session tokens — consistent with the ~200 compromised accounts reported in this incident.

Exploitation Requirements and Status

Authentication: Most current SharePoint exploitation chains require no authentication or only low-privilege access.
Network position: The farm must be network-reachable — internet-facing farms are the primary targets, but internal farms are hit during intrusions that begin elsewhere.
Exploitation status: SharePoint server exploitation is confirmed, widespread, and active in the wild. Multiple SharePoint flaw chains have been added to the CISA Known Exploited Vulnerabilities catalog over the past 18 months. Defenders should assume scanning and exploitation attempts against any publicly reachable SharePoint instance are continuous.

Detection & Response

This is a technical threat. The detections below target the highest-fidelity observables from the SharePoint exploitation playbook: IIS worker process spawning child processes, ASPX file drops in the SharePoint web root, and suspicious requests to LAYOUTS endpoints.

Sigma Rules

These three rules are tuned for low false-positive rates. The w3wp.exe spawning command interpreters rule is the single most reliable SharePoint exploitation signal in any environment — legitimate SharePoint does not spawn cmd.exe or powershell.exe under normal operations.

YAML

---
title: IIS Worker Process Spawning Command Interpreter - Possible SharePoint Exploitation
id: 3f7a1b92-6c4e-4d58-a921-8e2c5b0f4a31
status: experimental
description: Detects the IIS worker process (w3wp.exe) spawning command interpreters or scripting engines, a hallmark of webshell execution following SharePoint server exploitation. Legitimate SharePoint operations do not spawn cmd.exe, powershell.exe, or similar child processes.
references:
  - https://attack.mitre.org/techniques/T1505/003/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith: '\w3wp.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cscript.exe'
      - '\wscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\whoami.exe'
      - '\net.exe'
      - '\nltest.exe'
      - '\ipconfig.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare custom SharePoint solutions or legacy timer jobs invoking scripts (investigate the application pool identity and command line before tuning)
level: high
---
title: ASPX File Written to SharePoint LAYOUTS Directory - Webshell Deployment
id: 8c2d4e61-9a73-4b5c-bf06-2d8e9a1c7f45
status: experimental
description: Detects creation of ASPX files in the SharePoint TEMPLATE\LAYOUTS directory by non-administrative processes. Webshell deployment into LAYOUTS is the standard persistence mechanism following SharePoint exploitation. Baseline legitimate patching activity during maintenance windows.
references:
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.initial_access
  - attack.t1190
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\Web Server Extensions\15\TEMPLATE\LAYOUTS\'
      - '\Web Server Extensions\16\TEMPLATE\LAYOUTS\'
  selection_ext:
    TargetFilename|endswith:
      - '.aspx'
      - '.ashx'
      - '.asmx'
  filter_legit_installers:
    Image|endswith:
      - '\msiexec.exe'
      - '\setup.exe'
      - '\psconfig.exe'
      - '\psconfigui.exe'
  condition: selection_path and selection_ext and not filter_legit_installers
falsepositives:
  - SharePoint cumulative update installation (filter msiexec/psconfig and restrict to approved maintenance windows)
  - Deployment of custom farm solutions by administrators
level: critical
---
title: Suspicious HTTP Request to SharePoint LAYOUTS Endpoint with ToolShell-Style Patterns
id: 5b9e3f07-2d14-4c88-9e60-7a1f4b3d8c29
status: experimental
description: Detects inbound HTTP POST requests to SharePoint ToolPane.aspx or other LAYOUTS endpoints with suspicious referrer or oversized bodies, consistent with known SharePoint exploitation scanner behavior and ViewState deserialization attacks. Deploy against IIS W3C logs ingested into your SIEM.
references:
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri-stem|contains:
      - '/_layouts/15/ToolPane.aspx'
      - '/_layouts/16/ToolPane.aspx'
  selection_method:
    cs-method: 'POST'
  filter_referrer:
    cs-referer|contains:
      - '/_layouts/SignOut.aspx'
  condition: selection_uri and selection_method and not filter_referrer
falsepositives:
  - Legitimate administrative use of tool pane functionality is rare in production; any hit warrants review of source IP and authenticated user
level: high

KQL — Microsoft Sentinel / Defender Hunt Query

This query hunts for the post-exploitation behavior chain in Defender for Endpoint data: IIS worker processes spawning suspicious children, and ASPX drops into SharePoint directories. Run it across the last 30 days, then pivot on any w3wp.exe instance that fired.

KQL — Microsoft Sentinel / Defender

// Hunt: SharePoint exploitation post-compromise behavior
// Part 1: w3wp.exe spawning command interpreters or discovery tools
let SuspiciousChildren = dynamic(["cmd.exe","powershell.exe","pwsh.exe","cscript.exe","wscript.exe","mshta.exe","rundll32.exe","whoami.exe","net.exe","net1.exe","nltest.exe","ipconfig.exe","certutil.exe","bitsadmin.exe","vssadmin.exe","wevtutil.exe","reg.exe"]);
let ProcessHits = DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ (SuspiciousChildren)
| project ProcessTime=TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, ProcessId, ReportId;
// Part 2: ASPX/ASHX writes into SharePoint LAYOUTS or web root paths
let FileHits = DeviceFileEvents
| where TimeGenerated > ago(30d)
| where FolderPath has_any ("Web Server Extensions\\15\\TEMPLATE\\LAYOUTS", "Web Server Extensions\\16\\TEMPLATE\\LAYOUTS", "inetpub\\wwwroot\\wss")
| where FileName endswith_any (".aspx", ".ashx", ".asmx")
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| where InitiatingProcessFileName !in~ ("msiexec.exe", "psconfig.exe", "psconfigui.exe", "setup.exe", "TiWorker.exe")
| project FileTime=TimeGenerated, DeviceName, ActionType, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256, ReportId;
ProcessHits
| union FileHits
| sort by ProcessTime desc

Velociraptor VQL — Endpoint Forensic Hunt

Use this artifact to sweep SharePoint servers for webshell artifacts: recently created executable ASP.NET files in LAYOUTS directories and live w3wp.exe processes with suspicious children.

VQL — Velociraptor

-- Hunt for SharePoint webshell artifacts and suspicious IIS child processes
-- Collect: recently written ASPX/ASHX/ASM files in SharePoint LAYOUTS paths
LET layout_files = SELECT
    FullPath,
    Size,
    Mtime,
    Ctime,
    Btime
FROM glob(
    globs=[
        'C:/Program Files/Common Files/Microsoft Shared/Web Server Extensions/*/TEMPLATE/LAYOUTS/**/*.aspx',
        'C:/Program Files/Common Files/Microsoft Shared/Web Server Extensions/*/TEMPLATE/LAYOUTS/**/*.ashx',
        'C:/Program Files/Common Files/Microsoft Shared/Web Server Extensions/*/TEMPLATE/LAYOUTS/**/*.asmx'
    ],
    accessor='ntfs'
)
WHERE Ctime > now() - 90*24*3600
ORDER BY Ctime DESC

-- Collect: w3wp.exe processes and their children for live-execution review
LET iis_procs = SELECT
    Pid,
    Ppid,
    Name,
    CommandLine,
    Exe,
    Username,
    CreateTime
FROM pslist()
WHERE Name =~ 'w3wp'
   OR CommandLine =~ '(powershell|cmd\.exe|whoami|certutil|net user|nltest)'

SELECT * FROM layout_files
UNION ALL
SELECT * FROM iis_procs

Remediation / Verification Script

This PowerShell script audits a SharePoint server for the highest-risk post-exploitation artifacts: unauthorized ASPX files in LAYOUTS, recent web.config modifications (machineKey tampering indicator), suspicious IIS child processes, and pending SharePoint patch status. Run it elevated on every farm server.

PowerShell

#Requires -RunAsAdministrator
# SharePoint Compromise Assessment - Security Arsenal
# Run on EVERY server in the SharePoint farm

$ReportPath = "C:\Temp\SharePoint_SecurityAudit_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt"
New-Item -Path "C:\Temp" -ItemType Directory -Force | Out-Null

Write-Output "=== SharePoint Compromise Assessment - $(Get-Date) ===" | Tee-Object $ReportPath

# 1. Check for ASPX/ASHX files created or modified in LAYOUTS in last 90 days
Write-Output "`n[1] Recent executable files in SharePoint LAYOUTS directories:`n" | Tee-Object $ReportPath -Append
$layoutsPaths = @(
    "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS",
    "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS"
)
foreach ($path in $layoutsPaths) {
    if (Test-Path $path) {
        Get-ChildItem -Path $path -Recurse -Include *.aspx,*.ashx,*.asmx -ErrorAction SilentlyContinue |
            Where-Object { $_.CreationTime -gt (Get-Date).AddDays(-90) -or $_.LastWriteTime -gt (Get-Date).AddDays(-90) } |
            Select-Object FullName, CreationTime, LastWriteTime, Length |
            Format-Table -AutoSize | Tee-Object $ReportPath -Append
    }
}

# 2. Check web.config files for recent modification (machineKey theft/tamper indicator)
Write-Output "`n[2] Recently modified web.config files:`n" | Tee-Object $ReportPath -Append
Get-ChildItem -Path "C:\inetpub\wwwroot\wss" -Recurse -Filter "web.config" -ErrorAction SilentlyContinue |
    Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-90) } |
    Select-Object FullName, LastWriteTime | Format-Table -AutoSize | Tee-Object $ReportPath -Append

# 3. Check for suspicious child processes of w3wp.exe (live)
Write-Output "`n[3] Live w3wp.exe child processes (should be empty or near-empty):`n" | Tee-Object $ReportPath -Append
$w3wpPids = Get-CimInstance Win32_Process -Filter "Name='w3wp.exe'" | Select-Object -ExpandProperty ProcessId
Get-CimInstance Win32_Process | Where-Object { $w3wpPids -contains $_.ParentProcessId } |
    Select-Object ProcessId, Name, CommandLine, CreationDate | Format-Table -AutoSize | Tee-Object $ReportPath -Append

# 4. Verify installed SharePoint build vs latest available
Write-Output "`n[4] SharePoint build version (compare against latest CU at https://learn.microsoft.com/en-us/officeupdates/sharepoint-updates):`n" | Tee-Object $ReportPath -Append
$spConfig = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\16.0" -ErrorAction SilentlyContinue
if (-not $spConfig) {
    $spConfig = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0" -ErrorAction SilentlyContinue
}
$spConfig | Select-Object Version, Location | Format-List | Tee-Object $ReportPath -Append

# 5. List local admins and recently created accounts (post-exploitation check)
Write-Output "`n[5] Local administrators and accounts created in last 90 days:`n" | Tee-Object $ReportPath -Append
Get-LocalGroupMember -Group "Administrators" -ErrorAction SilentlyContinue |
    Select-Object Name, ObjectClass | Format-Table -AutoSize | Tee-Object $ReportPath -Append
Get-LocalUser | Where-Object { $_.PasswordLastSet -gt (Get-Date).AddDays(-90) } |
    Select-Object Name, Enabled, PasswordLastSet, LastLogon | Format-Table -AutoSize | Tee-Object $ReportPath -Append

Write-Output "`n=== Assessment complete. Review $ReportPath ==="

Remediation

Immediate Actions (Next 24–48 Hours)

Confirm your patch level. Compare your installed SharePoint build against the latest cumulative update at Microsoft's SharePoint Updates page. If you are more than one CU behind, you are exposed — plan an emergency patching window.
Run the assessment script above on every farm server. Any unexpected ASPX file in LAYOUTS, any recently modified web.config, or any w3wp.exe child process is a presumptive compromise. Escalate to your IR retainer immediately.
Review IIS logs for the last 90 days. Hunt for POST requests to /_layouts/ endpoints from external IPs, requests with no referrer or unusual user agents, and any request followed within minutes by a new ASPX file appearing on disk.
Rotate credentials defensively. If there is any indication of compromise: reset all SharePoint service account passwords, all farm administrator credentials, and force password resets for user accounts that authenticated during the suspected window. The Swiss incident demonstrates that account compromise is the standard outcome — 200 accounts in that case.

Critical Post-Compromise Step: MachineKey Rotation

If you confirm or suspect any code execution on a SharePoint server, patching alone is not sufficient. Attackers who extract the ASP.NET machineKey retain the ability to forge authenticated payloads indefinitely:

Rotate the machineKey in every web.config across the farm after patching.
Recycle all application pools and restart IIS farm-wide (iisreset /noforce on each server, sequenced to maintain availability).
Treat all ViewState-bearing sessions issued before rotation as untrusted.

Network-Level Hardening

Remove SharePoint from the public internet if business requirements allow. If external collaboration is required, place the farm behind a WAF with virtual patching rules for SharePoint exploitation patterns, and enforce pre-authentication (Entra ID Application Proxy or equivalent).
Block outbound traffic from SharePoint servers except to explicitly required destinations. Webshells and C2 channels die when egress is denied.
Restrict inbound management ports (WinRM 5985/5986, RDP 3389, SMB 445) to designated jump hosts only.

Platform Hardening

Enable AMSI integration for SharePoint (supported in Subscription Edition and later builds) to inspect in-memory script execution.
Deploy Microsoft Defender for Endpoint (or your EDR of choice) to every farm server with the process creation telemetry needed for the detections above — SharePoint servers are too often excluded from EDR "because of performance."
Enable Sysmon or equivalent process creation auditing with command-line logging; without it, the w3wp.exe child process detection is blind.
Forward IIS W3C logs to your SIEM centrally — local logs are the first thing sophisticated attackers clear.

If You Find Evidence of Compromise

Do not rebuild in place without forensic capture. Preserve memory, the SharePoint content and configuration databases, IIS logs, and the file system timeline before remediation. Engage your incident response partner — webshell-based intrusions routinely involve follow-on access that survives naive cleanup.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub

Swiss Government SharePoint Breach: 200 Accounts Compromised — Detection and Hardening Guide for On-Prem SharePoint Defenders