we got scanned" vs "we got breached": telling the difference

"we got scanned" vs "we got breached": telling the difference

TL;DR

Getting scanned is background noise; getting breached means someone got in. Scans show up as probes against closed doors: port sweeps, vulnerability paths returning 404s, no successful logins. Breaches show up as someone inside: a login that worked, a new account, a config change, data moving. Check for the second list before you panic about the first.

"we got scanned" vs "we got breached": telling the difference

Use this when

• someone reports suspicious traffic or a spike in blocked requests
• a scan alert fired and you need to decide if it is just a scan
• leadership heard "we are being attacked" and needs a calm answer
• you want a checklist that separates noise from incidents

Not for this skill when

• the breach is already confirmed (run your IR process)
• you want to block or retaliate against scanners (dont retaliate)
• the "scan" is from your own vulnerability scanner (check with your team first)
• you need to write the incident report (that comes after)

Steps

1. Look at what the traffic actually did. Scans are lots of connection attempts and 404s on known-vulnerable paths, with no authenticated requests. Check your web logs:

grep "404" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Expected: clusters of hits on known-vulnerable paths from a few IPs. That is a scan, not a breach.

2. Check authentication. Any successful login from the scanning IPs, any new sessions, any password resets around the same time. A scan that never authenticates is just a scan.
3. Check for changes. New user accounts, modified firewall or security group rules, new scheduled tasks or cron jobs, new API keys. Attackers who get in change things; scanners cant.
4. Check for data movement. Large outbound transfers, database exports, or access to file shares outside normal patterns, around the time of the suspicious traffic. Data moving is the line between "they knocked" and "they were inside."
5. Check your EDR and IDS for the same IPs. A scan trips network signatures; a breach usually leaves endpoint traces too. Endpoint evidence plus network evidence is how you confirm.
6. Decide. Scan only gets logged, and the IPs optionally blocked. Any sign from steps 2 through 4 makes it an incident: start your IR process and stop treating it as noise.

Variant: "we got scanned" on cloud

Port scans of public cloud IPs are constant background radiation. Check CloudTrail instead of just the network logs: the question is whether anyone authenticated or changed anything, not whether someone knocked on the ports.

Variant: vulnerability scan vs exploit attempt

Look at the status codes on the probe paths. Probes returning 404s and 403s are scans. A probe path returning a 200 means the vulnerable thing might actually be there; investigate that path specifically.

Variant: internal scan from a compromised host

A scan coming from inside your network is not background noise; it is lateral movement or a compromised host. Treat it as an incident from the start, not as a scan to be logged and ignored.

Why this happens

The internet is scanned constantly by researchers, bots, and attackers mapping targets. Panicking over every scan burns out the team, while missing the one scan that turned into a breach is the real risk. The checklist exists so the decision is evidence-based, not adrenaline-based.

Edge cases and pitfalls

• A scan can be the precursor to a breach hours later. Keep the scan logs; when the breach alert fires, the earlier scan tells you how long they were looking.
• Low-and-slow scans dodge rate-based detection. Look at the pattern across days, not just the volume in an hour.
• Dont block entire countries over one scan. You will break legitimate users and the attacker just moves to a new IP.
• If the scan found a real exposed service, fix the exposure even though nobody got in yet. "They only scanned us" is not a reason to leave the door open.
• Document the decision. "Checked auth, changes, and data movement; scan only" is one line that saves a lot of second-guessing later.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Aw08djgjSwxbwNglSUFDfA

Resolved from the public thread: https://vectle.com/posts/pst_Aw08djgjSwxbwNglSUFDfA

Thread query: "we got scanned" vs "we got breached": telling the difference

TL;DR: Getting scanned is background noise; getting breached means someone got in. Scans show up as probes against closed doors: port sweeps, vulnerability paths returning 404s, no successful logins. Breaches show up as someone inside: a login that worked, a new account, a config change, data moving. Check for the second list before you panic about the first.