Quantum Systems Cyberattack Disrupts German Military Drone Operations — Defense Contractor Detection and Hardening Guide

In late October 2025, German defense technology company Quantum Systems — a key supplier of reconnaissance drones to the German Bundeswehr and Ukrainian forces — confirmed it detected an active cyberattack attributed to "hostile actors." The intrusion disrupted drone development and production operations, and the company was forced to isolate systems and rebuild portions of its software update infrastructure to ensure integrity.

This is not an isolated event. Defense industrial base (DIB) companies, particularly those supplying operational technology into active conflict zones, have become priority targets for state-aligned intrusion sets. The objectives are consistent: intellectual property theft, pre-positioning within build and update pipelines, and disruption of military capability. When an adversary touches a drone manufacturer's development or update environment, the risk extends far beyond the corporate network — it reaches into every deployed airframe that trusts code signed and delivered by that vendor.

This post breaks down what defenders can take away from the Quantum Systems incident, how to hunt for the TTPs most commonly used against defense contractors, and how to harden the build, signing, and update infrastructure that adversaries covet.

Technical Analysis

What Is Known

• Victim: Quantum Systems GmbH, German manufacturer of military reconnaissance UAVs (Vector, Scorpion, and Twister platforms) used by the Bundeswehr and deployed operationally in Ukraine.
• Timeline: The incident was detected in late October 2025 and characterized by the company as an active cyberattack by "hostile actors" — language typically reserved for state-sponsored or state-aligned adversaries rather than financially motivated criminals.
• Impact: Disruption to drone development and production operations. The company took affected systems offline and implemented additional hardening of its software update and delivery infrastructure.
• Attribution: No formal attribution has been published, but the targeting profile — a UAV supplier to Ukraine — is consistent with Russian-nexus espionage and disruption activity that has intensified against European defense firms since 2022.
• Exploitation status: No specific CVE or initial access vector has been publicly disclosed. No CISA KEV entry is associated with this incident. The initial access method remains unconfirmed at time of writing.

Why the Update and Build Pipeline Is the Prize

When an adversary breaches a drone manufacturer, the highest-value assets are not email mailboxes — they are:

1. Code signing certificates and keys — compromise enables delivery of attacker-signed firmware to deployed fleets.
2. Software update servers / OTA delivery infrastructure — a single poisoned update is a fleet-wide supply chain event.
3. Flight controller and mission-planning source code — intelligence value for counter-UAS development and vulnerability research against deployed systems.
4. Telemetry and operational data — revealing drone locations, mission patterns, and operator identities in an active conflict.

The fact that Quantum Systems specifically hardened its update servers in response tells experienced responders exactly where the adversary's interest lay — or at minimum, where the integrity risk was assessed to be highest. Defenders at any organization that builds, signs, and delivers software should treat that as the lesson: assume your pipeline is the target, and instrument it accordingly.

Typical Attack Chain Against DIB Targets

While the specific vector here is undisclosed, IR engagements against defense contractors in 2025-2026 have repeatedly shown this pattern:

1. Initial access: Spear-phishing of engineering staff, exploitation of internet-facing VPN/remote access appliances, or compromised third-party credentials.
2. Persistence: Webshells on perimeter appliances, rogue scheduled tasks/services, and abuse of legitimate remote management tooling.
3. Lateral movement: Targeting of build servers, artifact repositories, and PKI/HSM-adjacent systems with harvested credentials.
4. Collection & staging: Source code and design documents staged for exfiltration over HTTPS to cloud storage or attacker infrastructure.
5. Optional disruption: Wiper deployment or destruction of build/update infrastructure — a pattern seen in Russian-nexus operations against Ukrainian-adjacent targets.

The detections below focus on the highest-fidelity, lowest-noise behaviors in that chain: anomalous access to signing and update infrastructure, persistence on build servers, and exfiltration staging.

Detection & Response

Sigma Rules

The following rules target behaviors a SOC can realistically implement: non-administrative processes accessing code signing material, suspicious child processes on build/update servers, and webshell-style process lineage on perimeter web servers. Scope selection paths and host filters to your environment before deployment.

---
title: Suspicious Access to Code Signing Certificate Material
id: 3f8a2c14-7b9d-4e51-a6c2-9d4e5f6a7b8c
status: experimental
description: Detects non-standard processes reading code signing private keys or certificate stores, a key objective in supply chain intrusions against software and firmware vendors.
references:
  - https://www.bleepingcomputer.com/news/security/german-military-drone-operations-disrupted-by-cyberattack/
  - https://attack.mitre.org/techniques/T1552/004/
author: Security Arsenal
date: 2026/01/14
tags:
  - attack.credential_access
  - attack.t1552.004
logsource:
  category: file_event
  product: windows
detection:
  selection_paths:
    TargetFilename|contains:
      - '\\Certificates\\'
      - '\\codesign\\'
      - '\\signing\\'
      - '.pfx'
      - '.p12'
  filter_legit:
    Image|endswith:
      - '\\signtool.exe'
      - '\\msbuild.exe'
      - '\\devenv.exe'
      - '\\jenkins.exe'
  condition: selection_paths and not filter_legit
falsepositives:
  - Build engineers exporting certificates during legitimate release work — restrict to build host service accounts
level: high
---
title: Shell Spawned by Build or CI Server Process
id: 8c4d5e6f-2a3b-4c5d-9e1f-0a2b3c4d5e6f
status: experimental
description: Detects command shells or scripting engines spawned by CI/CD build server processes (Jenkins, TeamCity, GitLab Runner) outside of expected job execution patterns, consistent with post-exploitation of build infrastructure.
references:
  - https://www.bleepingcomputer.com/news/security/german-military-drone-operations-disrupted-by-cyberattack/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/14
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\\jenkins.exe'
      - '\\java.exe'
      - '\\gitlab-runner.exe'
      - '\\teamcity-agent.exe'
      - '\\w3wp.exe'
      - '\\nginx.exe'
      - '\\httpd.exe'
  selection_child:
    Image|endswith:
      - '\\cmd.exe'
      - '\\powershell.exe'
      - '\\pwsh.exe'
      - '\\wscript.exe'
      - '\\cscript.exe'
      - '\\rundll32.exe'
  filter_ci:
    CommandLine|contains:
      - 'mvn '
      - 'gradle'
      - '\\build\\scripts\\'
  condition: selection_parent and selection_child and not filter_ci
falsepositives:
  - Build pipelines that legitimately invoke shell steps — baseline per pipeline and alert on deviation
level: high
---
title: Outbound Connection from Isolated Build or Update Server
id: 5e6f7a8b-1c2d-4e5f-a6b7-8c9d0e1f2a3b
status: experimental
description: Detects network connections from software update, build, or signing servers to external destinations. These systems should have tightly allowlisted egress; unexpected outbound traffic is a strong indicator of C2 or exfiltration.
references:
  - https://www.bleepingcomputer.com/news/security/german-military-drone-operations-disrupted-by-cyberattack/
  - https://attack.mitre.org/techniques/T1041/
author: Security Arsenal
date: 2026/01/14
tags:
  - attack.exfiltration
  - attack.t1041
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    Image|endswith:
      - '\\powershell.exe'
      - '\\curl.exe'
      - '\\rclone.exe'
      - '\\bitsadmin.exe'
      - '\\certutil.exe'
      - '\\mshta.exe'
  filter_internal:
    DestinationIp|startswith:
      - '10.'
      - '172.16.'
      - '192.168.'
      - '127.'
  condition: selection and not filter_internal
falsepositives:
  - Legitimate package downloads during builds — allowlist known artifact repositories and CDNs by destination
level: high

KQL — Microsoft Sentinel / Defender Hunt

This query hunts for anomalous process execution and outbound connections from build, signing, and update infrastructure. Tag your critical pipeline hosts in a watchlist (here CriticalPipelineHosts) containing hostnames of build servers, update servers, and PKI/signing systems.

// Hunt: anomalous processes and egress on build/signing/update infrastructure
let CriticalHosts = _GetWatchlist('CriticalPipelineHosts') | project SearchKey;
let SuspiciousProcs = dynamic(["powershell.exe","pwsh.exe","cmd.exe","curl.exe","rclone.exe","bitsadmin.exe","certutil.exe","wscript.exe","mshta.exe","nltest.exe","psexec.exe","whoami.exe","net.exe"]);
union
( DeviceProcessEvents
  | where TimeGenerated > ago(7d)
  | where DeviceName has_any (CriticalHosts)
  | where FileName in~ (SuspiciousProcs)
  | where InitiatingProcessFileName !in~ ("jenkins.exe","java.exe","gitlab-runner.exe","msbuild.exe","devenv.exe","dotnet.exe","node.exe")
  | project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, SHA256
),
( DeviceNetworkEvents
  | where TimeGenerated > ago(7d)
  | where DeviceName has_any (CriticalHosts)
  | where RemoteIPType == "Public"
  | where InitiatingProcessFileName in~ (SuspiciousProcs) or InitiatingProcessFileName endswith "rclone.exe"
  | summarize Connections=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), RemoteIPs=make_set(RemoteIP), RemoteUrls=make_set(RemoteUrl) by DeviceName, InitiatingProcessFileName
  | where Connections < 50  // rare egress, not routine update traffic
)
| sort by TimeGenerated desc

For environments ingesting Linux build servers via Syslog, add a companion hunt against Syslog for new AuthorizedKeysFile modifications, unexpected cron entries, and sshd accepted logins from non-bastion source IPs on those hosts.

Velociraptor VQL — Pipeline Host Triage

Deploy this artifact against build, update, and signing servers to enumerate persistence mechanisms and unsigned/anomalous executables in a single collection:

-- Triage build/update infrastructure: persistence + suspicious executables
SELECT * FROM foreach(
  row={
     SELECT Name, CommandLine, Exe, Username, Pid
     FROM pslist()
     WHERE Username =~ 'SYSTEM|NETWORK SERVICE'
       AND CommandLine =~ 'powershell|cmd\.exe|rundll32|regsvr32|wscript'
  },
  query={
     SELECT Name, CommandLine, Exe, Username, Pid,
            'SuspiciousSystemProc' AS Finding
     FROM scope()
})
UNION ALL
SELECT
  '' AS Name,
  Key.FullPath AS CommandLine,
  Data.value AS Exe,
  Key.Name AS Username,
  0 AS Pid,
  'RunKeyPersistence' AS Finding
FROM glob(globs='HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run*\\**',
          accessor='registry')
UNION ALL
SELECT
  '' AS Name,
  FullPath AS CommandLine,
  '' AS Exe,
  '' AS Username,
  0 AS Pid,
  'RecentExecutableDrop' AS Finding
FROM glob(globs='C:\\ProgramData\\**\\*.exe')
WHERE Mtime > now() - 604800

The third clause surfaces executables dropped into ProgramData in the last 7 days — a common staging location during intrusions. Adjust the time window and paths to match your IR scoping needs.

Hardening and Verification Script

Use this Bash script on Linux-based build/update servers to verify integrity controls and tighten egress. Run it as part of your post-incident validation or as a periodic hardening audit:

#!/bin/bash
# harden_pipeline.sh — verify integrity and egress controls on build/update servers
set -euo pipefail

echo "=== [1] Verify no unexpected users have sudo/root access ==="
getent group sudo wheel 2>/dev/null || true
awk -F: '($3 == 0) {print "UID0 account:", $1}' /etc/passwd

echo "=== [2] Audit SSH authorized_keys for unauthorized additions (last 30 days) ==="
find /home /root -name authorized_keys -mtime -30 -exec ls -la {} \; 2>/dev/null || true

echo "=== [3] List cron persistence across all users ==="
for u in $(cut -d: -f1 /etc/passwd); do crontab -u "$u" -l 2>/dev/null | grep -v '^#' | sed "s/^/[$u] /"; done
ls -la /etc/cron.d/ /var/spool/cron/ 2>/dev/null || true

echo "=== [4] Verify code signing key access is HSM/KMS-backed, not file-based ==="
find / -xdev \( -name '*.pfx' -o -name '*.p12' -o -name '*.key' \) -not -path '/etc/ssl/*' 2>/dev/null | head -20

echo "=== [5] Check egress firewall allows only required destinations ==="
iptables -L OUTPUT -n -v 2>/dev/null || nft list chain ip filter OUTPUT 2>/dev/null || echo "No host firewall rules found — implement egress allowlisting"

echo "=== [6] Verify package/artifact integrity tooling is enabled ==="
command -v cosign >/dev/null && echo "cosign present" || echo "WARN: cosign not installed — deploy artifact signing verification"
command -v aide >/dev/null && echo "aide present" || echo "WARN: no file integrity monitoring detected"

echo "=== [7] Recent outbound connections from non-service accounts ==="
ss -tnp 2>/dev/null | grep ESTAB | grep -vE '(10\.|172\.16\.|192\.168\.|127\.)' | head -20 || true

Remediation

Whether you operate in the defense sector or simply ship signed software to customers, the Quantum Systems incident translates into concrete action:

1. Isolate and instrument the pipeline. Build, signing, and update servers belong in a dedicated, tightly segmented security zone — not on the flat corporate network. Egress from these systems should be allowlist-only (artifact repositories, update endpoints, nothing else). Deploy EDR with tamper protection and stream all telemetry to a SIEM the pipeline hosts cannot reach.

2. Protect signing keys as if already targeted. Move code signing private keys into FIPS 140-2 Level 2+ HSMs or cloud KMS with strict access policies. No .pfx/.p12 files on disk. Require dual-control approval for signing operations and alert on any signing event outside scheduled release windows. If you suspect compromise, plan for certificate revocation and key rotation — and test that you can rotate before you need to.

3. Assume credential compromise of engineering staff. Enforce phishing-resistant MFA (FIDO2/passkeys) for all developer, CI/CD, and remote access. Audit service accounts used by CI runners — they are frequently over-privileged and unmonitored. Adversaries targeting DIB firms lead with spear-phishing of engineers; make that path expensive.

4. Harden remote access infrastructure. If your environment runs VPN or remote access appliances, treat them as your most likely initial access vector. Ensure they are on current firmware, behind a management allowlist, and monitored for webshell indicators (unexpected files in web root, anomalous child processes of the web server).

5. Build update-integrity verification into the product. Signed firmware is necessary but not sufficient — deployed devices should verify signature chains, support secure boot, and provide attestation. If your update server is breached tomorrow, your customers' deployed fleet should still reject malicious payloads.

6. Establish an intelligence-sharing channel. Defense contractors should participate in sector ISACs (e.g., ND-ISAC, relevant national CERTs such as BSI/BSI-CERT in Germany) and monitor advisories on state-aligned activity against the DIB. The adversaries hitting Quantum Systems are hitting your peers.

7. Rehearse the supply chain IR scenario. Your IR plan almost certainly covers ransomware. Does it cover "attacker may have had access to our signing infrastructure for 90 days"? Tabletop that scenario — including customer notification, certificate revocation, and fleet re-provisioning — before you have to execute it live.

Conclusion

The Quantum Systems attack is a reminder that modern military capability runs through commercial software pipelines, and adversaries know it. For defenders, the actionable lesson is not the specific intrusion — it's the target selection. Build systems, signing keys, and update infrastructure are now front-line assets. Instrument them, isolate them, and assume hostile interest. The organizations that treat their delivery pipeline with the same rigor as their crown-jewel data will be the ones that detect the next incident in days rather than discovering it in a press release.

Related Resources

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