Background

SpaceResearcherFake.com is a defence-adjacent aerospace engineering firm contracted by a government agency to develop surveillance software for high-altitude reconnaissance satellites. The work is classified at a sensitive tier. Staff in IT and R&D are selected through multi-stage background checks including security clearance vetting.

Internal systems held satellite payload specifications, proprietary algorithms, encrypted telemetry codebases, and active research datasets spanning several years of government-funded development.

The Insider

DuplicateVikingVenga had been an IT Administrator at the company for seven years. His role gave him privileged access across the server infrastructure — domain controllers, backup systems, research file servers, and the internal deployment pipeline.

In late 2020, he was passed over for a senior infrastructure role he had applied for. The rejection was attributed to incomplete documentation in his HR file rather than performance. He submitted his resignation shortly after. His last working day was recorded as February 28, 2021.

Due to his long tenure and the trust placed in him, no access review was conducted upon resignation. His credentials, admin privileges, and remote VPN access remained fully active through his notice period and were not formally revoked on departure.

Governance Breakdown

Offboarding did not trigger privileged access review. Remote access stayed active. Trust substituted for control.

The Attack

Between February 20 and February 27, DuplicateVikingVenga used his still-active VPN credentials to remotely access the company's internal network on six occasions, each outside normal working hours. Every session authenticated successfully using his own credentials.

During these sessions he embedded a logic bomb inside a routine scheduled maintenance script that already existed across the server infrastructure. The script ran weekly as part of standard disk cleanup operations. He modified it to carry a destructive WORM payload set to activate on March 2, 2021 — two days after his last working day.

The WORM was designed to execute three things in sequence:

  • Propagation first: moved laterally across the network using existing admin-level trust relationships, optimised to reach backup servers and the offsite replication target before any production system was touched.
  • Boot destruction: overwrote the master boot records on critical research and infrastructure servers, rendering them unbootable.
  • Backup sabotage: corrupted the backup catalog and overwrote recent recovery points. Offsite replication had already received the WORM during propagation, eliminating clean recovery points.

March 2, 2021

03:17 AM
The scheduled maintenance script executed across the server fleet.
Within 22 minutes
All critical servers were offline.
07:00 AM
The operations team found infrastructure fully unresponsive. Recovery attempts failed as backup systems returned corrupted or incomplete restore points.
Recovery window
Full infrastructure recovery took nine days. Several systems could not be restored from backup and were rebuilt from bare metal.

March 18, 2021

During forensic review, the company confirmed a significant volume of research data was permanently lost. Satellite payload algorithm documentation, telemetry processing code spanning 14 months of active development, and simulation datasets used for orbital accuracy modelling were unrecoverable. The government agency was notified. A formal investigation was opened.

What the Logs Showed

SpaceResearcherFake.com operated a SIEM solution. It was logging events across the network perimeter and authentication systems throughout the entire period.

Every action DuplicateVikingVenga took was logged: the off-hours VPN sessions, the script modification, the lateral propagation traffic, and the backup catalog writes at 03:00am.

None of it produced an alert. The SIEM had no correlation rules connecting these events into a pattern. Internal east-west traffic between trusted servers was not treated as a monitoring surface. The backup environment sat on the same trust boundary as production with no anomaly detection applied to write activity against recovery points.

The Signal Was There

The data was there. The signal was never built.

Governance Questions
  1. Why were the SIEM and other solutions not using UEBA to monitor user behaviour?
  2. Why did resignation not trigger an immediate privileged access review and staged de-provisioning plan?
  3. Why could a routine maintenance script be modified without integrity controls, approvals, or change monitoring?
  4. Why were backup systems and offsite replication on the same trust boundary as production?
  5. Why were there no SIEM correlation rules that link: off-hours VPN → admin script changes → lateral movement → backup catalog writes?