From pentest findings to SOC detections

24.06.20264 min readAtalaia team

Most teams use a pentest report once. The findings become tickets, the tickets get fixed, and the report is archived. But a pentest is also the closest thing you have to a labelled attack against your own systems: known techniques, known targets, known times. That is exactly the data detection engineers want.

This guide shows how to turn findings into detections your SOC can run, using MITRE ATT&CK for shared language and Sigma for portable rules.

Why fix and detect

Fixing the bug closes one door. Detection tells you when someone tries the handle on that door, or on the next one you have not found yet. The two answer different questions:

• The fix answers: can this specific attack still succeed?
• The detection answers: is someone attempting this class of attack right now?

A detection built from a finding also catches regressions. If a later release reopens the hole, your alert may be the first place you hear about it.

The process, finding by finding

1. CollectAsk the testers for source IPs, timestamps and raw requests. Agree this before the engagement starts.
2. MapAssign each finding an ATT&CK technique describing what the attacker did, not what the bug was.
3. LocateFind the logs that recorded the activity: web server, WAF, cloud audit, identity provider.
4. WriteExpress the observable behaviour as a Sigma rule.
5. TestReplay the rule over the pentest window. It must fire on the tester's traffic and stay quiet on normal days.

Mapping findings to ATT&CK

Map the attacker's action. A server-side request forgery is a bug class; the attacker's goal when exploiting it in the cloud is often to read instance credentials. Typical web and cloud findings map like this:

Recording the technique ID on each detection lets you see coverage across the matrix and spot techniques you test for but never detect.

A Sigma rule from an SSRF finding

Suppose the testers reached the metadata address through an image-fetch parameter. The web server logged the query string. A Sigma rule for that behaviour:

title: Possible SSRF Targeting Cloud Metadata Service
id: 8f2b6c1e-4d7a-4b0e-9c3f-2a1d5e6f7a80
status: experimental
description: |
  Detects requests whose URL or query contains the link-local cloud
  metadata address or a common alias. Built from pentest finding PT-2026-11.
references:
  - internal://pentest/2026/PT-2026-11
tags:
  - attack.credential_access
  - attack.t1552.005
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains:
      - '169.254.169.254'
      - 'metadata.google.internal'
      - '%31%36%39%2e%32%35%34'
      - '0xa9fea9fe'
  condition: selection
falsepositives:
  - Internal health checks that legitimately reference the address
level: high

Convert it to your platform's query language with the Sigma CLI, then run it over the pentest window:

pip install sigma-cli
sigma plugin list                  # find the backend for your log platform
sigma plugin install "$BACKEND"
sigma convert -t "$BACKEND" ssrf_metadata.yml

Pick the backend, and a processing pipeline if your field names differ, to match your log platform. The encoded variants in the rule come from the same thinking as a good retest: if the testers tried one encoding, attackers will try several.

Pair the web rule with a second, stronger signal where you can: cloud audit logs showing the instance role's credentials used from an address outside your network. That catches the outcome, not just the attempt.

Test and tune

• True positive: the rule fires on every tester request in the window. If it misses some, look at what they changed.
• False positive: run it over a normal week. Add narrow exclusions with a comment explaining each one.
• Ownership: each rule has an owner, a runbook link and the pentest finding ID it came from.
• Version control: keep rules in a repository with review and CI, the same as application code. Lint them with sigma check.

What to do on Monday

1. Take your last pentest report and list each finding with an ATT&CK technique.
2. Ask the testers, or check your notes, for source IPs and the test window.
3. Search your logs for their activity. Note any finding that left no trace.
4. Write one Sigma rule for the highest-impact finding and test it over the window.
5. Next engagement, agree in the scope that testers share timestamps and sources, so detections become part of the deliverable.

Done this way, each test leaves the line both harder to break and better at noticing when someone tries.

Where this sits on the line