What A Ransomware Incident Teaches About The Week Before It Started

TL;DR: A public-sector network was exfiltrated for a week before anyone noticed, and the detection trigger was a routine complaint. I write about the controls that would have shortened that dwell time — not about the attacker.

The scenario

I ran this as a black-box review: no credentials, only the publicly visible surface. Here is what I saw before I touched anything.

A post-incident review of a public-sector network that experienced a data exfiltration and extortion event. The scope was a control review against the incident timeline: initial access, dwell time, detection trigger, containment and data volume. No testing of live systems was performed.

I removed all identifying information. The target is described only by sector and technology class so the pattern can be reused.

The pattern

The pattern I recognised — and that I keep finding in similar estates:

The number that matters in an exfiltration incident is the dwell time, not the ransom. A week between an attacker obtaining access and an organisation noticing means seven days of unmonitored egress, credential reuse across the estate and a data catalogue assembled before anyone was looking. The attacker did not need a sophisticated exploit; they needed the absence of an alert.

The initial access was ordinary, which is the most important finding. Phishing with a fake identity prompt led to a remote management tool being installed on one workstation. From there the path was not technically novel: credentials from a shared administrative layer, lateral movement between departmental servers, and a bulk transfer to external infrastructure. Every step on that path crosses a boundary that most estates have not drawn.

The detection trigger was a routine complaint, not a security control. That is the lesson with the widest reach. A user reported something was wrong, a technician investigated, and the scale of the problem became visible. That means the security tooling on the network did not detect seven days of bulk egress from a departmental server, and it did not detect the installation of remote management software on a workstation. The response was good; the detection capability was not there.

TL;DR: A public-sector network was exfiltrated for roughly a week before anyone noticed. This write-up is about the controls that would have shortened that dwell time, not about the attacker.

Findings

Severity	Finding	Evidence
KRITISCH	No egress detection for bulk data transfer	Seven days of exfiltration without an alert
KRITISCH	Remote management software not blocked on workstations	Initial access tool installed without prevention or alert
KRITISCH	Shared administrative credentials across departments	Lateral movement path between server segments
HOCH	No multi-factor authentication on administrative access	Single credential compromise sufficient
HOCH	No automated alerting on mass file access patterns	Enumeration phase invisible
MEDIUM	Sensitive personal data stored without a defined retention rule	Exfiltration volume far above the operational need

The attack path

Reproduction in my lab

Every command below targets a lab container I control. Nothing here is aimed at a live system.

Verify detection capability on a network you own

~/code/bash bash

# does egress alerting exist at all
$ for h in $(cat internal-hosts.txt); do
    printf '%s
' "$h"
done
# the question for the network team is whether a server transferring
# several gigabytes overnight raises an alert. Test it in a lab.

# is remote management software blockable
$ for tool in anydesk.exe teamviewer.exe ultravnc.exe rustdesk.exe; do
    printf '%s ' "$tool"
    curl -so /dev/null -w '%{http_code}
' \
      "https://update.example.org/$tool"  # your own software distribution mirror
done

Detection in your own estate

Ask the two questions that decide your dwell time

~/code/bash bash

# 1. does a server transferring several gigabytes overnight raise an alert
#    test this in a lab, not in production:
$ dd if=/dev/zero of=/tmp/test.bin bs=1M count=500
$ scp /tmp/test.bin lab-target:/tmp/test.bin   # your own lab host

# 2. is remote management software blocked and alerted on
$ for tool in anydesk.exe teamviewer.exe ultravnc.exe rustdesk.exe; do
    printf '%s %s\n' "$tool" \
      "$(curl -so /dev/null -w '%{http_code}' "https://software.example.org/$tool")"
done

Check that administrative access requires a second factor

~/code/bash bash

$ for p in /wp-admin/ /admin/ /api/admin; do
    printf '%s -> %s\n' "$p" "$(curl -so /dev/null -w '%{http_code}' https://example.org$p)"
done

# the real test is a login attempt without a second factor

Remediation

Block the initial access, not just detect it

~/code/nginx nginx

# block remote management tooling at the proxy, not at the workstation
# the workstation is one control; the proxy is the chokepoint every tool needs
location ~* \.(exe|msi)$ {
    if ($arg_uri ~* "(anydesk|teamviewer|ultravnc|rustdesk|splashtop)") {
        return 403;
    }
    proxy_pass http://software-distribution;
}

No egress detection for bulk data transfer

Remote management software not blocked on workstations

Shared administrative credentials across departments

No multi-factor authentication on administrative access

No automated alerting on mass file access patterns

Sensitive personal data stored without a defined retention rule

Takeaways

Dwell time is the number that decides how bad the incident gets.
Initial access is rarely sophisticated; it is rarely blocked, either.
A user complaint is not a detection capability.
Shared administrative credentials turn one compromise into an estate-wide one.