BAE Systems Cyber Incident Halts US Bankruptcy Court Notices — Third-Party Incident Response and Detection Playbook

A cyber incident at BAE Systems — the defense and aerospace contractor that operates critical infrastructure on behalf of the US federal government — has taken the Bankruptcy Noticing Center (BNC) offline, halting the distribution of bankruptcy court notices nationwide for a full week. The BNC is not a convenience; it is the centralized mechanism by which the US bankruptcy court system sends legally required notices to creditors, debtors, trustees, and attorneys. When it stops, legally mandated deadlines, case timelines, and due-process obligations are affected across every federal judicial district.

This is the second time in recent memory that a contractor-operated judiciary noticing system has become a single point of failure — and it is a textbook illustration of a risk category I see consistently underweighted in enterprise risk registers: the operational blast radius of a third-party cyber incident. You do not need to be breached for your operations to stop. Your vendor does.

No CVE, malware family, or specific intrusion vector has been publicly disclosed as of this writing, and I will not speculate beyond what is observable. What defenders can act on right now is well established: the detection patterns for the classes of attacks that produce week-long outages of contractor-operated services, the third-party risk controls that should have been in place, and the continuity engineering that determines whether a vendor outage is an inconvenience or a national-level disruption.

Technical Analysis: What a Week-Long Outage Tells Us

The affected system

• System: US Bankruptcy Noticing Center (BNC), operated by BAE Systems under contract to the Administrative Office of the US Courts
• Impact: Complete halt of bankruptcy notice generation and distribution across all US bankruptcy courts
• Duration: Approximately one week of disrupted service
• Root cause: Publicly described only as a "cyber incident" or "security incident" at the contractor — no CVE, intrusion vector, or attribution disclosed

Reading the incident profile

A multi-day, nationwide outage of a document processing and distribution system follows a small number of well-understood incident archetypes:

1. Ransomware / destructive encryption — the most common cause of week-plus outages. Restoration requires either clean backups, full environment rebuild, or protracted negotiation-free recovery. Encryption events at document-processing pipelines are especially damaging because integrity, not just availability, is in question: can the notices queued during the incident be trusted?
2. Precautionary shutdown after intrusion detection — defenders take systems offline to contain an active intrusion (business email compromise pivot, VPN/edge device compromise, or valid-account abuse). Recovery time is driven by forensic scoping, credential resets, and re-validation of system integrity before reconnection to government networks.
3. Destructive or wiper-style activity — less common but consistent with nation-state interest in defense contractors, where BAE Systems sits squarely in the targeting envelope.

From a defender's perspective, the exploitation status question here is not about a CVE — it is about the confirmed, active, real-world disruption of a government-critical service. That places this firmly in the "assume breach techniques are in play" category. The techniques most consistently observed in incidents that produce this outage profile are valid-account abuse against remote access infrastructure (MITRE ATT&CK T1078), edge device exploitation (T1190), and mass encryption or service disruption for impact (T1486, T1489, T1490).

Why contractors are the target

BAE Systems is a defense industrial base (DIB) prime contractor. DIB entities are persistently targeted by nation-state actors and ransomware groups alike — for espionage value, for the sensitivity of the government data they process, and because a single contractor compromise can cascade into dozens of government programs. The BNC incident demonstrates the cascade in reverse: the espionage or extortion motive matters less than the fact that a centralized, single-operator service with no evident failover carried an entire federal function.

The defensive lessons generalize to every organization:

• Concentration risk: A single contractor operating a centralized service is a single point of failure for the entire dependent ecosystem.
• Integrity risk during outage: Queued legal notices pending during the incident window must be validated before processing — an attacker with access to the pipeline could alter notice content, amounts, addresses, or deadlines.
• Recovery time objectives are fiction until tested: A week of downtime means either backups were compromised, restore procedures failed, or integrity verification took priority over speed. Each has a distinct remediation path.

Detection & Response

Because no specific intrusion vector has been disclosed, the detection content below targets the behavioral archetypes that produce this outage profile — the same hunts I would run across any environment operating document-processing pipelines, vendor-connected service accounts, or centralized noticing/mail infrastructure. These are the detections that matter before your vendor's incident becomes your headline.

Sigma Rules

The first rule targets mass file modification consistent with encryption of a document pipeline. The second targets ransomware's near-universal precursor: destruction of volume shadow copies and backup catalogs. The third targets anomalous service account behavior — the valid-account abuse pattern that dominates contractor-environment intrusions.

---
title: Mass File Rename or Modification Consistent With Document Pipeline Encryption
id: 3f8a1c94-2b7d-4e56-9a01-6c5d8e2f4b7a
status: experimental
description: Detects a high volume of file rename or modification events within a short window, consistent with mass encryption of a document processing or noticing pipeline. Tunable threshold; baseline document-processing hosts first.
references:
  - https://attack.mitre.org/techniques/T1486/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.impact
  - attack.t1486
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|endswith:
      - '.pdf'
      - '.tif'
      - '.tiff'
      - '.docx'
      - '.xml'
      - '.dat'
  condition: selection
falsepositives:
  - Legitimate batch document conversion jobs; baseline scheduled pipeline processing windows and suppress known job accounts
level: high
---
title: Shadow Copy and Backup Catalog Deletion via Command-Line Tools
id: 9d2e5b17-4c8a-4f31-8b62-1a7e3c9d5f08
status: experimental
description: Detects execution of vssadmin, wmic, bcdedit, or wbadmin with arguments consistent with shadow copy deletion or backup catalog destruction — a near-universal ransomware precursor that precedes multi-day outages.
references:
  - https://attack.mitre.org/techniques/T1490/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.impact
  - attack.t1490
logsource:
  category: process_creation
  product: windows
detection:
  selection_vssadmin:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains:
      - 'delete shadows'
      - 'resize shadowstorage'
  selection_wmic:
    Image|endswith: '\wmic.exe'
    CommandLine|contains: 'shadowcopy delete'
  selection_bcdedit:
    Image|endswith: '\bcdedit.exe'
    CommandLine|contains:
      - 'recoveryenabled no'
      - 'ignoreallfailures'
  selection_wbadmin:
    Image|endswith: '\wbadmin.exe'
    CommandLine|contains: 'delete catalog'
  condition: 1 of selection_*
falsepositives:
  - Rare; some storage management and provisioning scripts use these legitimately — investigate every hit
level: critical
---
title: Interactive Logon by Service Account Outside Expected Source Systems
id: 5b1c7e38-6d4f-4a92-bc47-8e2f1a6d3c95
status: experimental
description: Detects interactive or remote interactive logons (Type 2/10) by accounts with service naming conventions, consistent with valid-account abuse of contractor/vendor service credentials — the dominant initial-access pattern in third-party environment intrusions.
references:
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.defense_evasion
  - attack.persistence
  - attack.privilege_escalation
  - attack.initial_access
  - attack.t1078
logsource:
  category: authentication
  product: windows
detection:
  selection:
    TargetUserName|contains:
      - 'svc_'
      - 'svc-'
      - '_svc'
      - 'service'
    LogonType:
      - 2
      - 10
  filter_known_hosts:
    IpAddress|startswith:
      - '10.10.5.'
      - '10.10.6.'
  condition: selection and not filter_known_hosts
falsepositives:
  - Misconfigured scheduled tasks or RDP-based service administration; replace filter subnets with your actual approved service-account source ranges before deployment
level: high

KQL — Microsoft Sentinel / Defender

This hunt query looks for the compound pattern most predictive of an impending outage event: a service account authenticating from an unusual source, followed within a short window by suspicious process execution on the same host. It is designed to catch valid-account abuse before it reaches the encryption or disruption stage. It assumes you ingest SecurityEvent and DeviceProcessEvents (or their equivalents via CEF/Syslog for Linux estate) into Sentinel.

let Lookback = 7d;
let SuspiciousProcs = dynamic(["vssadmin.exe", "wmic.exe", "bcdedit.exe", "wbadmin.exe", "psexec.exe", "nltest.exe", "adfind.exe"]);
let ServiceAccts =
    SecurityEvent
    | where TimeGenerated > ago(Lookback)
    | where EventID == 4624 and LogonType in (2, 10)
    | where TargetAccount has_any ("svc_", "svc-", "_svc") or TargetAccount has "service"
    | summarize FirstSeen=min(TimeGenerated), Sources=make_set(IpAddress) by TargetAccount, Computer;
ServiceAccts
| join kind=inner (
    DeviceProcessEvents
    | where TimeGenerated > ago(Lookback)
    | where FileName in~ (SuspiciousProcs)
    | project ProcTime=TimeGenerated, DeviceName, FileName, ProcessCommandLine, InitiatingProcessAccountName, InitiatingProcessAccountDomain
    ) on $left.Computer == $right.DeviceName
| where ProcTime between (FirstSeen .. FirstSeen + 4h)
| project TargetAccount, Computer, FirstSeen, Sources, ProcTime, FileName, ProcessCommandLine, InitiatingProcessAccountName
| order by FirstSeen asc;

For a Linux-heavy document pipeline ingested via Syslog, hunt the equivalent behavior — mass file modification and service restarts:

Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("rm -rf", "shred", "openssl enc", "gpg --encrypt")
   or (ProcessName =~ "systemd" and SyslogMessage has_any ("Stopped", "Failed") and SyslogMessage has_any ("notice", "mail", "print", "queue"))
| summarize EventCount=count(), Samples=make_set(SyslogMessage, 5) by Computer, ProcessName, bin(TimeGenerated, 1h)
| where EventCount > 20
| order by TimeGenerated asc;

Tune the threshold against your baseline. The signal that matters is the change in volume, not an absolute number.

Velociraptor VQL

For post-incident scoping on any host involved in a document pipeline, this artifact hunts for the two highest-fidelity artifacts of a disruption event: ransom notes on disk and processes with backup-destruction command lines still resident or recently executed.

-- Hunt for ransom notes and backup-destruction tooling on pipeline hosts
SELECT FullPath, Size, Mtime
FROM glob(globs=['C:/Users/*/Desktop/*.txt', 'C:/Users/*/Documents/*README*.txt', 'C:/*README*.txt', 'C:/*RECOVER*.txt', 'C:/*DECRYPT*.txt'])
WHERE Mtime > parse(string=now() - 604800)

-- Separately: check running processes for impact-stage tooling
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(vssadmin.*delete|wmic.*shadowcopy|bcdedit.*recoveryenabled|wbadmin.*delete.*catalog)'

Remediation and Hardening Script

This PowerShell script audits the highest-risk condition this incident highlights — stale, over-privileged, or interactively-used service accounts — and verifies backup resilience posture. Run it on domain controllers and pipeline servers.

# 1. Find service accounts with interactive logon rights (should be none)
Get-ADServiceAccount -Filter * -Properties LastLogonDate, PasswordLastSet, MemberOf |
  Select-Object Name, LastLogonDate, PasswordLastSet, @{N='Groups';E={$_.MemberOf -join ';'}} |
  Export-Csv -Path .\svc_account_audit.csv -NoTypeInformation

# 2. Find accounts whose passwords have not rotated in 180+ days
Get-ADUser -Filter {Name -like "svc*" -or Name -like "*service*"} -Properties PasswordLastSet, Enabled |
  Where-Object {$_.Enabled -eq $true -and $_.PasswordLastSet -lt (Get-Date).AddDays(-180)} |
  Select-Object Name, PasswordLastSet

# 3. Deny interactive logon for service accounts via local policy check (verify GPO applied)
secedit /export /cfg .\secpol_export.cfg | Out-Null
Select-String -Path .\secpol_export.cfg -Pattern "SeDenyInteractiveLogonRight|SeDenyRemoteInteractiveLogonRight"

# 4. Verify Volume Shadow Copy protection is intact and restore points exist
vssadmin list shadows
Get-ComputerRestorePoint -ErrorAction SilentlyContinue | Select-Object -Last 3

# 5. Confirm backup catalog integrity and last successful backup date
wbadmin get versions

# 6. Test that backup deletion requires elevated, authenticated context (attempt should fail as standard user)
whoami /priv | Select-String "SeBackupPrivilege"

Remediation: The Third-Party Incident Playbook

No patch or CVE applies here — the remediation is structural. These are the actions I would put in front of any CISO whose operations depend on contractor-operated services, ordered by priority:

1. Map your concentration risk this week. Inventory every business-critical function that depends on a single vendor or contractor, and document what happens operationally if that vendor is offline for 7, 14, and 30 days. The BNC outage shows that "the vendor handles it" is not a continuity plan — it is an assumption. For each dependency, define a manual or alternate-channel fallback and test it. The judiciary's fallback here was effectively "wait," which is why a week of silence became national news.

2. Enforce vendor security requirements contractually, with verification. Require incident notification SLAs (24 hours for operational-impacting events), evidence of tested backups with restoration time objectives, network segmentation between your data and the vendor's broader environment, and the right to independent assessment. FedRAMP, DFARS 252.204-7012, and CISA's Secure by Design guidance provide baseline frameworks; for DIB contractors, CMMC requirements exist precisely because self-attestation has repeatedly failed.

3. Treat data integrity during a vendor outage as an open question. Any documents, notices, or transactions queued at a vendor during an incident window must be re-validated against an authoritative source before processing resumes. If the bankruptcy courts resume notice distribution without integrity verification of the queued backlog, altered notices become a legal and fraud exposure, not just an IT problem.

4. Harden service account hygiene in your own environment. The dominant intrusion pattern in contractor environments is valid-account abuse. Eliminate interactive logon capability for service accounts, enforce gMSA or managed identity where possible, rotate credentials on a fixed schedule and immediately after any vendor incident notification, and alert on any service account authenticating from outside its approved source set (the third Sigma rule above).

5. Prove your backups restore, and prove they survive. A week-long outage strongly implies backup compromise, restore failure, or integrity-verification delays. Maintain immutable or offline backup copies, test full restoration of your most critical pipeline quarterly — timed — and alert on any deletion of shadow copies or backup catalogs (the second Sigma rule above, at critical severity).

6. Pre-stage your own incident communications. The judiciary and BAE Systems communicated through press coverage and court-by-court notices. If your vendor goes dark, your customers will learn about it from the news unless you tell them first. A pre-drafted vendor-outage communication template, approved by legal, cuts days off your response.

7. Report and share. Incidents affecting federal contractors trigger mandatory reporting obligations (DFARS 72-hour reporting for covered defense information; CIRCIA rulemaking is extending similar obligations across critical infrastructure). Even where not mandated, share indicators through your ISAC. The next organization in this attacker's target list benefits directly from what you saw.

The uncomfortable truth of this incident is that the bankruptcy courts likely did nothing wrong technically — and still lost a week of nationwide operations. That is the defining risk of the modern enterprise: your security posture is now the minimum of your own controls and those of every contractor you depend on. Defend accordingly.

Related Resources

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