Handling a Suspected Compromise Without Destroying Evidence

Security Basics for Support Technicians

Chapter 7 · Handling a Suspected Compromise Without Destroying Evidence

Chapter 6 ended with a warning: don't quietly fix a suspicious finding the moment you spot it. This chapter covers exactly what to do instead — the same "evidence over guesswork" discipline `log1` built this entire subject around, and the same "capture before mitigate" sequencing `incident1`'s own Chapter 6 taught, both applied here to the specific moment a support technician finds a possible compromise.

Evidence First Isn't Optional — It's the Whole Point

Per `log1`'s own foundational argument, real evidence beats guesswork every time. Applied here: the very first thing that happens after a suspicious discovery determines whether anyone investigating it later has anything real to work from, or only someone's memory of what they think they saw.

The Capture-vs-Mitigate Tension, Resolved

`incident1`'s own Chapter 6 named this tension directly for general incidents: fixing something immediately can destroy the exact evidence needed to understand it, but leaving something broken indefinitely just to preserve evidence isn't right either, especially when it's actively causing harm. A live forwarding rule quietly leaking mail is exactly this case — every minute it stays in place is another minute of exposure.

Step 1 — Capture (minutes, not hours)

Document exactly what was found: a screenshot of the configuration, the precise rule/setting/file in question, when it appears to have been created if that's visible, and the time you found it. This step should take minutes, not become its own investigation.

Step 2 — Mitigate the active harm

Once the finding is documented, stop the ongoing exposure — disable the forwarding rule, revoke the suspicious session, whatever specifically is causing continued harm right now. The order matters: mitigating before capturing risks losing the exact evidence that explains what happened; delaying mitigation for hours "to be thorough" risks letting real harm continue for no good reason.

Step 3 — Escalate with what you've captured

Hand off the documented finding through your organization's own incident process — this is exactly the point where `incident1`'s own classification and escalation material takes over.

What Not to Do

Instinct	Why it's a problem
Delete logs or suspicious files immediately	Destroys the exact evidence an investigation needs, per `log1`'s own founding warning
Reset the account without saving what was found	Closes the door without anyone ever learning what was behind it
Quietly clean it up and close the ticket	Hides the finding from anyone who could confirm whether other accounts are affected too
Confront who you suspect is responsible directly	Risks tipping them off to cover their tracks before anything is confirmed

Worked Example: Resolving Chapter 6's Forwarding Rule

Returning to the ticket from Chapter 6 — the mail-forwarding rule quietly copying every message to an external address. Applying the sequence above: the technician screenshots the rule's exact configuration and creation timestamp, notes exactly when and how it was found, then disables the rule within minutes to stop the ongoing leak, and immediately escalates the documented finding through the organization's incident process rather than continuing to investigate alone.

Past this point, it isn't a one-person job anymore

Once a finding is documented and the immediate harm is stopped, continuing to investigate solo — trying to figure out the full scope, who else might be affected, or who's responsible — isn't thoroughness, it's a decision that should belong to your organization's own incident process, not to one technician working alone. `incident1`'s own material on escalation applies directly here: asking for help at this point isn't a failure, it's the correct next step.

Hands-On Exercises

Exercise 1

Explain why this chapter puts capture before mitigate, rather than the other way around, and why the capture step should still be measured in minutes, not hours.

📄 View solution

Exercise 2

Explain why quietly cleaning up a suspicious finding and closing the ticket is listed as a problem, even when the immediate technical issue is genuinely resolved.

📄 View solution

Exercise 3

Explain why confronting a suspected internal wrongdoer directly is treated as a mistake, using this chapter's own reasoning.

📄 View solution

Chapter 7 Quick Reference

Capture first (minutes) — screenshot/document exactly what was found, then mitigate the active harm, then escalate with the evidence in hand
Never delete logs, suspicious files, or configuration before documenting them
Never reset an account or "clean up" a finding without saving what was there first
Never confront a suspected internal wrongdoer directly — it risks tipping them off
Past initial capture-and-mitigate, this stops being a one-person job — escalate through `incident1`'s own process
Next: Chapter 8, confidentiality and data handling in support work