What is confirmed
Monitoring detected suspicious activity inside a weather-services OT environment
In a forensic-services request issued on 18 September, Air Traffic and Navigation Services said monitoring detected suspicious activity in operational-technology environments supporting weather-related services to Air Traffic Services. Preliminary work identified malware commonly associated with the early stages of ransomware attacks.
ATNS said its technical teams contained the incident and removed malware, but requested an independent investigation to determine the source, attack vector, timeline, affected systems, possible data loss, operational impact, and remaining risk.
Three claims need separate confidence levels
Attribution limit
A destination in China is evidence to investigate, not an actor identity
ATNS says monitoring indicated possible exfiltration to external IP addresses located in China. An IP’s hosting country does not establish who controlled it: compromised servers, rented infrastructure, proxies, and relays routinely separate an operator from the final observed address.
- Preserve the exact destination addresses, ports, protocols, timestamps, byte counts, DNS history, and the internal systems that initiated connections.
- Determine whether the traffic contained operational data, credentials, archives, telemetry, or legitimate vendor communication.
- Correlate the destination with threat intelligence and hosting history, but label conclusions by confidence and evidence.
- Keep the separate alleged insider-data-theft matter described in the same procurement document out of the OT intrusion timeline unless evidence connects them.
Investigation
Preserve what cleanup can destroy
| Evidence area | Questions to answer | Common loss |
|---|---|---|
| Network | Which OT and IT systems communicated externally, and what moved? | Short firewall retention and overwritten packet or flow records |
| Endpoints and servers | What executed, persisted, changed, or collected data? | Reimaging before memory, logs, tasks, services, and files are captured |
| Identity and remote access | Which accounts, vendors, jump hosts, or tokens crossed the boundary? | Session detail lost when credentials are rotated without preserving authentication records |
| Operational systems | Did weather or air-traffic-supporting services degrade or enter an unsafe state? | Cyber cleanup recorded without the process and safety timeline |
| External providers | What evidence exists in cloud, telecom, vendor, and managed-security systems? | Assuming the affected organisation holds every relevant log |
Response
Run containment, continuity, and forensics as one coordinated plan
- 1
Stabilise the operational service. Confirm safe weather and air-traffic-supporting operations, establish manual or alternate procedures, and include operational owners in every containment decision.
- 2
Capture volatile and external evidence. Collect memory, running processes, active connections, endpoint state, network telemetry, identity records, and copies of logs held outside the affected environment.
- 3
Map IT-to-OT paths. Review jump hosts, management services, vendor access, shared identity, update channels, data historians, and monitoring infrastructure for the initial path and lateral movement.
- 4
Scope possible exfiltration. Reconstruct what data was staged or sent, who could access it, and how its loss could support follow-on targeting or operational disruption.
- 5
Recover from trusted state. Rebuild affected systems where integrity is uncertain, rotate exposed trust material, validate configurations, and monitor closely when services return.
Defender note
Containment is an event; confidence comes from reconstruction
Removing malware can stop immediate activity without answering how it arrived, what it reached, or whether persistence remains elsewhere. In safety-relevant OT, the response needs both a cyber timeline and an operational timeline so defenders can prove not only that systems are clean, but that the service remained trustworthy.