The First Hour: Triaging a Security Alert

Your EDR just fired at 02:14 on a Saturday: rundll32.exe spawning powershell.exe with an encoded command on a finance workstation. The next sixty minutes decide whether this becomes a Tuesday-morning anecdote or a breach notification letter. The first hour is not about fixing anything. It is about not making things worse while you figure out what you are actually looking at.

Triage is a decision, not a feeling

Every alert lands in one of three buckets: false positive, benign true positive (policy violation, red team, developer doing something weird), or a real incident. Your job in the first hour is to pick the bucket with evidence, not vibes.

Start with the five questions every responder asks, in this order:

1. What fired? Read the detection logic, not just the alert title. A Sigma rule for encoded PowerShell means something different than "suspicious activity."
2. What process tree? Parents and children tell you more than the offending binary. rundll32 -> powershell -> certutil is a story; svchost -> WmiPrvSE is a different one.
3. What user context? A domain admin's token in the process is a different severity than a service account.
4. What network activity? Outbound connections during the alert window are your fastest confirmation.
5. What else happened on that host? The alert is rarely the start of the story.

On a Linux host, the first-look commands are muscle memory:

ps auxf --sort=start_time | tail -40        # process tree, newest last
ss -tulpn                                    # listening sockets + owning process
ss -tnp state established                    # live outbound connections
last -20                                     # recent logins
journalctl --since "1 hour ago" -p err       # errors in the window

On Windows via PowerShell:

Get-CimInstance Win32_Process |
  Select-Object ProcessId, ParentProcessId, Name, CommandLine |
  Format-List
Get-NetTCPConnection -State Established |
  Select-Object LocalPort, RemoteAddress, OwningProcess
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 50

The bug that ships: destroying your own evidence

The most common first-hour mistake is treating triage like remediation. Do not reboot the box "to see if it comes back." Do not run a full AV scan — it will quarantine the malware you needed to analyze and write all over the disk. Do not log in as a domain admin to "check things" — you may hand the attacker a fresh token.

Quiet, read-only observation beats heroic action. If the EDR can isolate the host without killing it, that is your containment lever for later — note it, don't pull it yet.

Try this

You get this alert: powershell.exe -enc UwB0AGEAcgB0AC0A... on WS-FIN-014, user j.chen, at 02:14. Write down, before you touch the host, exactly which five data points you would pull first and what each one would tell you. Then decode the -enc blob ([System.Text.Encoding]::Unicode.GetString([Convert]::FromBase64String(...))) and ask: does what it does change your classification?

Pitfalls

• Alert fatigue bias. The fourth identical-looking alert this week is how real intrusions get ignored. Every alert gets the five questions.
• Clock drift. A host whose clock is 40 minutes off will corrupt your timeline later. Record w32tm /query /status or timedatectl output for every machine you touch.
• Talking on the compromised channel. If the attacker is in your email, your triage notes in Outlook are being read. More on that in the communications lesson — for now, keep your scratch notes off corporate mail.