Anchoring a fraud investigation to something the attacker could not edit
An investigator reconstructs an intrusion from server logs, network flows and application records. Each of those was writable by the environment under investigation, which is the first thing the other side's expert will say.
What can a forensic investigator anchor a timeline to?
Almost nothing inside the compromised environment. Logs, database records and application events were all writable by the party under investigation, and anti-forensic cleanup makes gaps ambiguous. The only durable anchor is something signed by a credential the attacker never held.
- Logs from compromised systems are evidence with a known defect: the party under investigation could write them.
- Anti-forensic activity is routine in sophisticated intrusions, and absence of evidence becomes ambiguous rather than exculpatory.
- A record signed by a credential outside the compromised environment anchors the timeline at the point of authorisation.
Part of Cyber insurance and risk transfer
The problem with reconstruction
An investigator builds a timeline from artefacts. In an intrusion the artefacts come from systems the attacker controlled, for some period, with some level of privilege.
| Artefact | Attacker's ability to affect it |
|---|---|
| Application logs | Write, delete, or prevent generation |
| Operating system logs | Clear, with administrative access |
| Database records | Modify directly |
| Network flow records | Usually outside their control — the strongest common source |
| Third-party service logs | Outside their control, if the service was not compromised |
| Backups | Depends on whether backup credentials were reached |
The fourth and fifth rows are why investigators reach for network telemetry and cloud provider logs first. They are outside the compromised boundary, which is exactly the property that makes them useful.
What anti-forensics does to the analysis
Sophisticated intrusions include cleanup: log clearing, timestamp manipulation, tool removal. The consequence for an investigation is not only missing data but ambiguity.
- A gap in logs may mean nothing happened, or that records were removed
- A timestamp may be accurate or manipulated
- An absence of evidence of an action is not evidence of absence
- The scope of compromise becomes a range rather than a finding
This matters commercially. An insurer, a regulator or a court asks what happened; an investigator who must answer in ranges produces a report that settles less than the parties hoped.
What an external anchor provides
A signature produced by a credential held outside the compromised environment — in a secure element on a person's device — cannot be forged by someone holding the servers.
# Compromised environment can say anything about this:
application logs, database rows, system events
# It cannot produce this:
a valid signature over a specific statement, from a
credential whose private key never left a secure element
on a device the attacker does not hold
# So the investigator gets:
"At 14:22, this named individual authorised exactly this
payment. The signature verifies. Everything after that
point is reconstruction; this point is fixed."The value is not that it explains the whole intrusion. It is that one point in the timeline is not subject to the reconstruction problem, and it happens to be the point where money moved.
Three questions it answers cleanly
- Was this payment authorised by a human? Either a valid receipt exists or it does not. There is no middle position.
- What did they authorise? The signed statement contains the beneficiary, amount and account. Not a reference to a record that may have changed.
- Which payments lack authorisation? Comparing executed payments against valid receipts identifies the unauthorised set directly.
The third is the one investigators find most immediately useful. It converts a search into a set difference.
Where this is weakest
Being clear about this matters for anyone relying on it in an adversarial setting.
| Scenario | What the receipt shows |
|---|---|
| Attacker had no credential | No receipt — the payment is unauthorised, cleanly |
| Employee was deceived into signing | A valid receipt — the fraud is real and the authorisation was genuine |
| Employee was complicit | A valid receipt — which is now evidence against them |
| Attacker compromised the employee's device at the moment of signing | A valid receipt for what the employee was shown |
Rows two and three are worth noting. A receipt does not establish that the transaction was legitimate; it establishes who stood behind it. In a complicity investigation that is precisely what you want.
Preserving receipts as evidence
Ordinary forensic handling applies, with one addition.
- Collect the receipts with normal chain of custody.
- Also collect the issuer's published key as it stood at the relevant time, and document where it came from.
- Record the verification procedure and its output, so it is reproducible by the other side.
- Preserve the verification tooling version, since a dispute may turn on how the check was performed.
The second point is the one commonly missed. If the issuer rotates keys, verification years later needs the key that was current at signing, and the rotation history needs to be documented rather than reconstructed.
Three questions a receipt answers cleanly
| Question | How it resolves |
|---|---|
| Was this payment authorised by a human? | A valid receipt exists, or it does not |
| What did they authorise? | The signed statement, not a reference |
| Which payments lack authorisation? | Executed set minus receipted set |
The third converts a search into arithmetic, which is why investigators find it the most immediately useful property.
Objections and honest limits
“A receipt proves the transaction was legitimate.” It does not, and saying so would be wrong. It establishes who stood behind it. If the employee was deceived or complicit, the receipt is valid and becomes evidence about them.
“Anti-forensics is rare.” Log clearing and timestamp manipulation are standard in sophisticated intrusions, and their effect is ambiguity rather than absence — which is worse for a report that has to state conclusions.
Preserving receipts as evidence
- Collect with normal chain of custody. Nothing exotic.
- Collect the issuer key as it stood at signing. With the rotation history documented, not reconstructed.
- Record the verification procedure and output. So the other side can reproduce it.
- Preserve the tooling version. A dispute can turn on how the check was run.
Terms used here
- Anti-forensics
- Deliberate destruction or manipulation of evidence, producing ambiguity rather than clean absence.
- Compromise boundary
- The set of systems an attacker controlled, whose records inherit that control.
- External anchor
- Evidence produced outside the boundary, which the compromise cannot have altered.
Frequently asked questions
Why are server logs weak evidence in an intrusion? They were writable by the environment under investigation. Opposing experts will say so, and anti-forensic cleanup makes gaps ambiguous.
Does a receipt prove a transaction was legitimate? No. It establishes who authorised it. If an employee was deceived or complicit, the receipt is valid and becomes evidence about them.
What is the most useful application? Comparing executed payments against valid receipts. It converts a search for unauthorised transactions into a set difference.
What is commonly missed in preservation? Collecting the issuer's published key as it stood at signing, with its rotation history documented rather than reconstructed later.
Why are server logs weak in an intrusion? They were writable by the environment under investigation, and cleanup makes gaps ambiguous rather than absent.
What is most often missed in preservation? Collecting the issuer key as it stood at signing, with its rotation history documented rather than reconstructed later.
Where this fits in Manav
Manav produces the artefact underwriting, claims and forensics all lack: a per-action receipt verifiable without the insured's cooperation, and a measurable coverage rate.
Sources and further reading
- NIST — digital forensics and evidence handling resources
- MITRE ATT&CK Enterprise techniques
- Federal Rule of Evidence 902 — Evidence That Is Self-Authenticating
- Forensic accounting standards on evidence sufficiency.