Most security incidents don't start with a dramatic alert. They start with a support ticket that says something like "my computer is slow" or "there's a weird pop-up I can't close." The technical work of triaging these reports — distinguishing real threats from benign performance issues — is one of the most underrated skills in IT support.

Here's the structured procedure I use to work through suspicious activity reports without either over-responding to normal system behavior or under-responding to actual incidents.

Starting Point: What Did the User Actually Observe?

The first goal is getting a precise description of the behavior, not just the conclusion the user drew from it. "My computer has a virus" is a conclusion. "A window opened by itself, and my cursor moved without me touching the mouse" is an observation.

Key diagnostic questions:

• When did it start? Pinpointing onset helps correlate with events: a software installation, an email they opened, a website they visited.
• Is it constant or intermittent? Constant, reproducible behavior is much easier to investigate.
• What exactly did you see, hear, or notice? Capture specific details — window titles, file names, error messages, behavioral changes.
• Did you do anything differently recently? New software, USB drive plugged in, clicked an email attachment.
• Has anyone else used this machine?

Resist the urge to assume. A user reporting "random pop-ups" might have malware — or might have a legitimate application running with notifications they never configured. The questions determine which path you're on.

Triage: Classifying What You're Dealing With

Before touching anything on the machine, mentally classify the report into one of three categories:

Performance/software issue — Slow machine, application crashes, update failures. No indicators of unauthorized activity. Standard troubleshooting applies.

Suspicious but unconfirmed — Something anomalous that doesn't have an obvious benign explanation. Investigate before concluding.

Likely incident — Clear indicators of compromise: active unknown processes, unexpected network connections, modified files, signs of data access the user didn't perform.

The classification determines the procedure. A performance issue goes through standard troubleshooting. A suspected incident triggers the incident response flow — isolation first, investigation second.

Decision Tree for Initial Assessment

User reports suspicious behavior
         │
         ▼
Can you identify a clear benign cause? ─── YES ──► Standard support flow
         │
         NO
         │
         ▼
Are there active process, network, or ─── YES ──► Treat as incident
file anomalies?                                    Isolate immediately
         │
         NO
         │
         ▼
Did the user interact with anything  ─── YES ──► Elevated suspicion
suspicious recently?                              Deeper investigation
         │
         NO
         │
         ▼
Monitor + document + low-priority follow-up

What to Actually Look At on the Machine

For anything beyond a clear performance issue, check these before drawing any conclusions:

• Running processes: Anything with no clear purpose, running from an unusual location, or consuming resources disproportionately?
• Network connections: Any established connections to external IPs that the user's normal software wouldn't explain?
• Recently modified files: Especially in user directories and temp locations
• Startup entries and scheduled tasks: Any recent additions?
• Event logs: Authentication events, service installs, log clearing events from the past 24-48 hours

This isn't a full forensic investigation — it's a 10-minute technical read that either confirms the benign explanation or identifies enough anomalies to escalate the response.

Escalation Criteria

Escalate beyond standard support when:

• You find process or network anomalies you can't explain
• The machine has access to sensitive data or systems
• Multiple users or machines are showing similar behavior
• The user has administrative privileges on the machine
• There's evidence of credential or authentication activity the user didn't perform

Escalation isn't admitting defeat — it's the correct procedural response when the scope or complexity exceeds the standard support scope. Document what you've found before handing off.

Avoiding False Positives (And False Negatives)

False positives waste time and erode user trust. A svchost.exe process running from System32 is not malware. A software update tool making outbound connections to its vendor's servers is expected. Not everything unusual is malicious.

False negatives are the more dangerous failure. Assuming a slow machine is "just" a performance issue because you found one plausible explanation — without checking for signs of infection — is how incidents go undetected for weeks.

The discipline is in not stopping the investigation when you find the first plausible answer. Ask whether there's a consistent technical story across all the observable symptoms. If there is, it probably isn't malware. If the story has gaps, keep looking.