Recognizing When a "Routine" Ticket Is Actually a Security Incident

Chapters 2 through 5 were about stopping an attack before it succeeds. This chapter is about what happens after one already might have — recognizing the moment an ordinary-looking ticket is actually an early sign that something has already gone wrong, not a normal request to work through as usual.

Where This Sits Relative to `incident1`

This site's own Incident Response & Ticketing Workflows course teaches classification, severity, and escalation — but all of that starts from a ticket already recognized as a security-relevant incident. This chapter covers the step before that: noticing that a given ticket even belongs in that category in the first place. `incident1`'s own material picks up exactly where this chapter leaves off.

Symptoms Worth a Second Look

• "I'm getting weird emails from myself" — a classic sign of a spoofed or compromised mailbox, not a glitch worth dismissing
• Unexpected password-reset emails the user didn't request — someone else may already be attempting to take over the account
• An unfamiliar sign-in notification — "new device" or "new location" alerts the user doesn't recognize
• Several users reporting similar odd behavior around the same time — a pattern, not an isolated glitch, and worth treating differently from a single one-off report
• An unfamiliar file, process, or browser extension the user didn't install — a possible sign of malware, especially following Chapter 3's baiting material
• Unusual slowness paired with unusual network activity — often has a perfectly mundane explanation per `perfdiag1`/`netdiag1`, but worth asking the question rather than assuming the boring explanation automatically

The One Question That Actually Matters

Not every odd symptom is an attack — most aren't. But a genuine security lens means actually asking, for each one: could this innocuous-looking symptom also be an early sign of compromise? — rather than reaching for the most boring available explanation by reflex, every single time.

The Same Symptom, Read Two Ways

Both Failure Modes Have a Real Cost

Treating every odd symptom as a full security incident produces the same problem Chapter 4 warned against for over-verification: alert fatigue, wasted investigation time, and a support process people learn to route around. But never asking the question at all means genuine early warning signs quietly pass by unnoticed until the damage is much larger. The goal isn't maximum suspicion — it's asking the one question above, consistently, and only escalating when the answer to it is genuinely "yes, this could be."

Worked Example: The Sync Bug That Wasn't

A user reports their email "isn't syncing right on their phone" — missing some messages, sent items appearing they don't remember sending. The routine read is a sync glitch, worth a quick app restart. Reading it through the lens above instead, a check of the account's own mail rules turns up a forwarding rule the user never created, quietly copying every incoming message to an external address. This is a well-known pattern in real account-compromise cases: once an attacker gains access, a forwarding rule lets them keep reading the mailbox even after the original login is noticed and the password changed.

Hands-On Exercises