BAE Systems Cyber Incident Disrupts US Bankruptcy Noticing Center: Third-Party Compromise Detection and Response Playbook

A cyber incident affecting defense contractor BAE Systems has rendered several services of the US Bankruptcy Noticing Center (BNC) unavailable, disrupting the electronic distribution of court notices to creditors, attorneys, and parties in bankruptcy proceedings across the federal judiciary. While attribution and intrusion vector details remain limited at the time of writing, the operational impact is already concrete: a single vendor compromise has cascaded into degraded service for a piece of US federal judicial infrastructure.

For defenders, this incident is a live case study in third-party and supply-chain risk. The BNC is operated on behalf of the federal courts, and BAE Systems is among the largest defense and government services contractors in the world. If your organization depends on a managed service provider, an IT integrator, or any vendor with persistent access to your environment — and virtually every enterprise does — this incident is directly relevant to your threat model. The question is not whether your perimeter is hardened; it is whether you can detect and contain a compromise that enters through a trusted third party.

What We Know and Why It Matters

Based on reporting from Infosecurity Magazine, several BNC services went offline following a cyber incident at BAE Systems. Key facts as publicly reported:

• Affected entity: BAE Systems, a major defense and government services contractor.
• Impacted service: Multiple functions of the US Bankruptcy Noticing Center, which handles noticing for federal bankruptcy cases — a workflow with statutory deadlines and legal consequences for failure.
• Nature of impact: Service unavailability, which is consistent with either destructive/disruptive attack activity, precautionary shutdown of affected systems during containment, or both.
• Details not yet public: Initial access vector, threat actor attribution, whether data was exfiltrated, and the full scope of affected BAE Systems infrastructure.

No CVE has been associated with this incident in public reporting, and defenders should be skeptical of any early claims tying this to a specific vulnerability until BAE Systems or federal authorities publish technical findings.

The Defensive Lesson: Availability Is the Blast Radius

The most instructive aspect of this incident is the impact pattern. Bankruptcy noticing is not a boutique internal tool — it is time-critical legal infrastructure. Disrupting it creates downstream effects across courts, law firms, creditors, and debtors nationwide. This mirrors the pattern we have seen across recent third-party incidents: adversaries (or the operational reality of containment) convert a single vendor compromise into systemic availability loss.

Organizations on the receiving end of this pattern — i.e., any entity that consumes services from a provider that gets breached — need a detection and response posture that assumes vendor-side compromise and monitors for its local symptoms: anomalous vendor account behavior, unexpected service interruptions, abnormal maintenance activity, and mass changes to systems the vendor manages.

Technical Analysis: Anatomy of a Third-Party Disruption

With the intrusion vector undisclosed, practitioners should plan against the most common patterns observed in contractor and managed-service compromises over the past 18 months:

1. Credential-based initial access — Phished, infostealer-harvested, or reused credentials for VPN, remote access portals, or SaaS tenants, frequently without MFA or with MFA fatigue/bypass.
2. Abuse of legitimate remote management tooling — Adversaries living off the land with RMM platforms (ConnectWise, AnyDesk, ScreenConnect-style tooling) or PsExec/WMI for lateral movement, precisely because these tools are expected in a vendor-managed environment.
3. Service disruption via mass service termination or encryption — Whether by ransomware or deliberate sabotage, availability loss at scale typically manifests as rapid stopping/disabling of services, deletion of backups and shadow copies, and in the destructive case, encryption of data stores.
4. Identity compromise as the bridge — Contractor environments are frequently breached via Active Directory / Entra ID escalation, since vendor admin accounts often hold broad, long-lived privileges.

Detection Priorities for Vendor-Managed Environments

The detections below target the highest-fidelity local symptoms of this class of incident: (a) mass service disruption, (b) backup/shadow-copy destruction preceding encryption or sabotage, and (c) anomalous use of remote management and lateral movement tooling by accounts that should not be running it. These are tuned to minimize noise — they focus on behaviors that have no legitimate high-volume counterpart in most environments.

Detection & Response

Sigma Rules

The following rules target observable behaviors common to disruptive incidents: deletion of shadow copies and backup tampering, mass service stopping/disabling, and execution of remote management tooling from unexpected locations. Deploy them against Windows endpoints and servers, especially systems managed or accessible by third-party vendors.

---
title: Shadow Copy Deletion via vssadmin or wmic
description: Detects deletion of volume shadow copies, a high-fidelity precursor to ransomware encryption and destructive attacks. Legitimate use is rare outside of specific backup administration windows.
logsource:
  category: process_creation
  product: windows
detection:
  selection_vssadmin:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains:
      - 'delete shadows'
      - 'Delete Shadows'
  selection_wmic:
    Image|endswith: '\wmic.exe'
    CommandLine|contains: 'shadowcopy delete'
  selection_powershell:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - 'Get-WmiObject Win32_Shadowcopy'
      - 'Remove-WmiObject'
  condition: 1 of selection_*
falsepositives:
  - Legitimate storage reclamation by backup administrators (rare; whitelist by account and maintenance window)
level: high
---
title: Mass Service Stop or Disable via sc.exe or net.exe
description: Detects command-line stopping or disabling of services, which at scale indicates destructive activity, anti-forensics, or ransomware attempting to release file locks on databases and backup agents.
logsource:
  category: process_creation
  product: windows
detection:
  selection_sc:
    Image|endswith: '\sc.exe'
    CommandLine|contains:
      - ' stop '
      - ' config '
      - ' delete '
  selection_net:
    Image|endswith: '\net.exe'
    CommandLine|contains: ' stop '
  filter_legitimate:
    CommandLine|contains:
      - ' sc stop spooler'
  condition: (selection_sc or selection_net) and not filter_legitimate
falsepositives:
  - Administrators stopping individual services for maintenance — baseline expected service names and admin accounts; alert on volume (same host stopping >5 distinct services in 10 minutes) at the SIEM layer
level: medium
---
title: Remote Management Tool Execution from Unusual Path
description: Detects execution of common RMM and lateral movement tools from user-writable or temporary directories, a strong indicator of attacker-staged tooling as opposed to legitimately installed vendor software.
logsource:
  category: process_creation
  product: windows
detection:
  selection_tools:
    Image|endswith:
      - '\psexec.exe'
      - '\psexec64.exe'
      - '\anydesk.exe'
      - '\screenconnect.exe'
      - '\teamviewer.exe'
      - '\ngrok.exe'
      - '\chisel.exe'
      - '\plink.exe'
  selection_suspicious_paths:
    Image|contains:
      - '\AppData\'
      - '\Temp\'
      - '\Users\Public\'
      - '\ProgramData\'
      - '\Windows\Temp\'
  condition: selection_tools and selection_suspicious_paths
falsepositives:
  - Some RMM agents self-update into ProgramData — validate against your organization's known RMM deployment paths and hash inventories
level: high

Tuning guidance: Rule 2 (service stop) is intentionally scoped to command-line utilities and should be paired with a SIEM-level aggregation threshold — a single sc stop is noise; ten in five minutes on one host is an incident. Rule 3 assumes you maintain an inventory of sanctioned RMM tools and their install paths; if you do not, building that inventory is itself a deliverable of this engagement.

KQL Hunting Queries (Microsoft Sentinel / Defender)

The following query hunts for hosts exhibiting the disruptive-activity cluster: shadow copy tampering plus mass service manipulation, and separately flags vendor/service accounts authenticating from unusual sources — the earliest local symptom of a third-party credential compromise.

// Hunt 1: Disruptive activity cluster — shadow copy deletion or mass service stops
let timeframe = 7d;
let disruptive_cmds = dynamic(["delete shadows", "shadowcopy delete", "sc stop", "sc delete", "sc config", "net stop"]);
DeviceProcessEvents
| where TimeGenerated > ago(timeframe)
| where FileName in~ ("vssadmin.exe", "wmic.exe", "sc.exe", "net.exe", "net1.exe", "powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any (disruptive_cmds)
| summarize Commands = make_set(ProcessCommandLine), CommandCount = count()
    by DeviceName, InitiatingProcessAccountName, bin(TimeGenerated, 10m)
| where CommandCount >= 3 or Commands has_any ("delete shadows", "shadowcopy delete")
| sort by CommandCount desc;

// Hunt 2: Vendor/service account logons from new source IPs (baseline deviation)
// Requires a historical baseline — extend lookback for training window as appropriate
let lookback = 14d;
let baseline = 90d;
let recent =
    SigninLogs
    | where TimeGenerated > ago(lookback)
    | where ResultType == 0
    | where UserPrincipalName has_any ("svc-", "vendor", "bae", "_admin") // tune to your vendor naming convention
    | summarize RecentIPs = make_set(IPAddress) by UserPrincipalName;
let historical =
    SigninLogs
    | where TimeGenerated between (ago(baseline) .. ago(lookback))
    | summarize HistoricalIPs = make_set(IPAddress) by UserPrincipalName;
recent
| join kind=inner historical on UserPrincipalName
| mv-expand RecentIP = RecentIPs
| where set_difference(pack_array(RecentIP), HistoricalIPs) != dynamic([])
| project UserPrincipalName, RecentIP, HistoricalIPs;

For environments ingesting firewall/VPN logs via CEF or Syslog into Sentinel, adapt Hunt 2 against CommonSecurityLog by pivoting on SourceIP and SourceUserID for vendor account names. The baseline-deviation approach is what keeps this query out of the noise trap: you are alerting on change, not on presence.

Velociraptor VQL Hunt

This artifact triages endpoints for evidence of disruptive tooling and anomalous RMM execution — useful when you need to rapidly assess whether a vendor-adjacent compromise has touched systems in your own environment.

-- Hunt for shadow copy tampering and attacker-staged remote tooling
SELECT Pid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(delete\s+shadows|shadowcopy\s+delete|sc\.exe\s+(stop|delete|config)|net(1)?\.exe\s+stop)'
   OR (Exe =~ '(?i)(appdata|users\\\\public|programdata|\\\\temp\\\\)'
       AND Name =~ '(?i)(psexec|anydesk|screenconnect|teamviewer|ngrok|chisel|plink)')
ORDER BY CreateTime DESC

Follow up on any hits with a Velociraptor Windows.System.VSS review (via the built-in artifact or SELECT * FROM vssadmin-equivalent checks) and an SRUM/USN Journal pull to establish the timeline of file-level activity preceding service disruption.

Remediation and Hardening Script

The script below is a defensive posture script for environments consumed by third-party vendors: it audits local and domain vendor-style accounts, flags disabled shadow copy protection, verifies that critical services have recovery options configured (so a single sc stop doesn't cascade), and inventories RMM tooling present on the host for comparison against your sanctioned list.

#Requires -RunAsAdministrator
# Vendor-Compromise Readiness Audit — Security Arsenal
# Run on vendor-managed servers and endpoints; output is a per-host posture report.

$report = [ordered]@{}
$report.Hostname = $env:COMPUTERNAME
$report.Timestamp = (Get-Date).ToString("o")

# 1. Shadow copy / VSS protection state — should NEVER be disabled outside backup ops
$report.ShadowCopies = Get-CimInstance Win32_ShadowCopy | Select-Object VolumeName, InstallDate
$report.VSSServiceState = (Get-Service VSS).Status

# 2. Vendor-style local accounts (hunt for unexpected privileged accounts)
$report.PrivilegedLocalAccounts = Get-LocalGroupMember -Group "Administrators" -ErrorAction SilentlyContinue |
    Select-Object Name, ObjectClass, PrincipalSource

# 3. RMM / remote access tooling inventory — compare against sanctioned list
$sanctionedRMM = @() # Populate with your approved tools, e.g. "ScreenConnect Client (yourid)"
$installed = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*,
             HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -match "AnyDesk|TeamViewer|ScreenConnect|ConnectWise|Splashtop|LogMeIn|Atera|Ninja|Datto" } |
    Select-Object DisplayName, DisplayVersion, InstallDate
$report.RMMToolsFound = $installed
$report.UnsanctionedRMM = $installed | Where-Object { $sanctionedRMM -notcontains $_.DisplayName }

# 4. Critical services without recovery options (restart on failure mitigates mass-stop impact)
$report.ServicesWithoutRecovery = Get-CimInstance Win32_Service |
    Where-Object { $_.StartMode -eq 'Auto' -and $_.State -eq 'Running' } |
    ForEach-Object {
        $recovery = (sc.exe qfailure $_.Name) -join " "
        if ($recovery -match "RESET FAILURE COUNTER\s*:\s*0") { $_.Name }
    }

# 5. Recently modified service configurations (possible tampering)
$report.RecentServiceChanges = Get-WinEvent -FilterHashtable @{LogName='System'; Id=7040} -MaxEvents 50 -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Message

$report | ConvertTo-Json -Depth 4 | Out-File "$env:COMPUTERNAME-vendor-audit.json"
Write-Host "[+] Audit complete: $env:COMPUTERNAME-vendor-audit.json"
Write-Host "[!] Review UnsanctionedRMM and PrivilegedLocalAccounts first."

Review the output centrally: unsanctioned RMM tools and unexpected local admins are your two highest-signal findings when assessing exposure to a vendor-side compromise.

Remediation and Response Recommendations

Because the intrusion vector for this incident is not yet public, remediation guidance is structured around the confirmed impact pattern — third-party compromise with service disruption — rather than a specific patch.

Immediate actions (0–24 hours) for organizations sharing vendors or managed-service relationships with impacted parties:

1. Inventory your exposure. Enumerate every third party with persistent access (VPN, RMM agents, delegated admin in Entra ID/AD, API keys, service accounts). For each, identify the credentials, network paths, and privileges involved. You cannot contain what you have not mapped.
2. Rotate and constrain vendor credentials. Enforce MFA (phishing-resistant where possible), remove standing vendor privileges in favor of just-in-time elevation, and set service account credential rotation to a defined cadence. Disable any vendor accounts not tied to an active engagement.
3. Validate your own integrity signals. Run the detections above. Confirm shadow copies are intact, backup infrastructure is segmented and was not reachable from vendor-accessible segments, and no unsanctioned RMM tooling exists on managed systems.
4. Pre-stage containment for vendor paths. Know, in advance, how you would surgically sever a vendor's access (firewall rules, conditional access policies, disabling delegated admin relationships) without taking your own operations down. The BNC outage demonstrates that availability loss during containment is the norm, not the exception — plan your cutover paths now.

Short term (1–4 weeks):

5. Implement egress and lateral-movement segmentation around vendor-managed systems. Vendor service accounts should reach only the assets they manage, over only the ports required, with all sessions logged to your SIEM — not the vendor's.
6. Contract and telemetry requirements. Ensure your MSAs require breach notification timelines (24–72 hours), forensic cooperation, and log sharing. A customer of BNC-scale services should not learn of a provider's incident from the press.
7. Monitor official channels. Track updates from BAE Systems, the Administrative Office of the US Courts, and CISA for confirmed technical details, IOCs, and any subsequent CVE association. If indicators or a vulnerability identifier are published, re-run targeted hunts against historical telemetry covering at least the preceding 90 days — dwell time in contractor environments routinely exceeds initial reporting windows.

For entities dependent on the BNC specifically: coordinate with the Administrative Office of the US Courts on alternative noticing procedures and document any statutory deadline impacts for your legal teams; availability incidents with legal-workflow consequences require business continuity action, not just IT action.

The Bottom Line

This incident is not about bankruptcy noticing. It is about the structural reality that a compromise at one well-defended contractor became a disruption to federal judicial operations. Your environment almost certainly contains the same dependency pattern. The organizations that weather the next one will be those that mapped their vendor trust relationships, baselined vendor account behavior, and rehearsed surgical containment — before they needed to.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub