How it works
Records are located, staged, compressed and sent out through web services, cloud storage, email or covert channels. The same outcomes are reachable by an authorised person acting outside their purpose, and administrative access can be used to destroy or deface rather than to take.
The part that decides the consequences
Everything else in this wiki describes how someone obtains access. This describes what happens next, and it is the stage that determines whether an incident is an operational inconvenience or a regulatory and commercial event.
It is also the stage most likely to involve no malicious software at all. Data leaves through the same channels the business uses — cloud storage, email, collaboration tools, an API. The traffic is encrypted, the destination is a well-known service, and the account is legitimate.
That is why detection here is built on volume, timing and role rather than on signatures. There is no malicious byte pattern in a large download; there is only a person or process reading far more than it usually does.
Exfiltration in practice
Staging usually precedes transfer. Data is located, collected somewhere convenient, and compressed — often into an archive with a name designed to be unremarkable. That staging step is the best detection opportunity, because it happens on systems you control and produces distinctive activity.
Transfer then favours whatever is least likely to be inspected: a sanctioned cloud storage provider, a collaboration platform, an outbound API call. Blocking these wholesale is rarely possible because the business depends on them, which means the control has to be volume and destination anomaly rather than category blocking.
Covert channels — encoding data into DNS queries, or trickling it slowly to stay under thresholds — are used where egress is genuinely restricted. They are slower, which is itself a defensive win, and DNS query volume to a single domain is an unusually reliable signal because it has few benign explanations.
The insider case
An insider does not need to obtain access; they have it. Most of the security stack is oriented outward and is simply not looking at an authorised person using authorised permissions for an unauthorised purpose.
The categories differ in ways that matter for response. Malicious insiders act deliberately and often around a triggering event — a resignation, a dispute, a competing offer. Negligent insiders cause the same exposure without intent, typically by moving data somewhere convenient. Compromised insiders are not insiders at all: an external attacker using their credentials, which is indistinguishable from the malicious case until attributed.
The controls that work are unglamorous and organisational. Least privilege limits what any single person can reach. Separation of duties prevents one identity both acting and erasing the record. Timely offboarding closes the window that stale access leaves open — and stale access is the most common finding in this category by a wide margin.
Behavioural monitoring helps and needs to be deployed carefully. Watching employees carries legitimate privacy and legal constraints, and a programme that ignores them creates a different problem. Scope it to sensitive data, be transparent that it exists, and involve the relevant functions before rather than after.
Destruction and defacement
Where the objective is disruption rather than gain, administrative access is used to destroy state or alter public content. This overlaps with wiper malware but does not require malware — legitimate administrative tooling deletes data perfectly well.
Two things determine the outcome, and both are decided beforehand. The first is whether backups are genuinely out of reach: immutable, versioned, in a separate trust domain, and restorable — a backup reachable with production credentials is part of the blast radius rather than the recovery from it.
The second is whether the audit trail survives. Attackers target logs precisely because absence of evidence prevents scoping, and an incident you cannot scope is one you cannot credibly declare closed. Shipping logs off-host in real time to somewhere the production identity cannot write is what preserves the ability to answer what happened.
Also known as
What defenders may observe
- Unusual archive creation or bulk reads
- Outbound volume to rare or newly-seen destinations
- Sensitive data accessed outside normal role patterns
- Access conflicting with job function or occurring during a notice period
- Mass delete or overwrite activity
- Backups, versioning or audit logs targeted before the impact
Prevention and mitigation
- Classify data and apply least privilege so bulk access is not ubiquitous
- Monitor egress volume and destinations; apply DLP on the paths that matter
- Limit and audit bulk export, and require justification for large extracts
- Separate duties so no single identity can both act and erase the record of acting
- Keep immutable, versioned backups outside the production trust domain
- Run a rapid joiner-mover-leaver process — stale access is the common finding
Initial response priorities
- Stop continued access while preserving evidence.
- Determine the records, systems and legal obligations involved.
- Restore from verified copies and notify the appropriate response owners.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.