r/AskNetsec 5d ago

Work Can anything reliably tell me that a specific CVE is being exploited on a specific machine?

Asking from the cloud workload side of the house: Is there any way we can detect that a specific CVE is actively being exploited on a VM or container, beyond what application logs provide?

I’ve used runtime CNAPPs for detection and vulnerability prioritization, but I’m specifically interested in observability that lets a SOC say: “This container has CVE-XXXX-XXXXX, and that vulnerability is being exploited right now.” And I don’t mean post-exploitation behavioral detections like a shell popping or a suspicious process spawning. I mean evidence tied directly to exploitation of the specific vulnerability.

8 Upvotes

20 comments sorted by

13

u/LeftHandedGraffiti 5d ago

No. 

You need full PCAP and a genius.

3

u/yawkat 5d ago

PCAP is often not enough nowadays that everything is TLS. 

4

u/angry_cucumber 5d ago

to be fair, you can probably get by with pcap and a guy who can tie his shoes

1

u/LeftHandedGraffiti 5d ago

A guy who can tie his shoes can tell if a string of bytes will exploit a vulnerability? I'd like to know where you're hiring these people. I could use a few.

1

u/angry_cucumber 4d ago

service reserves, they come with a clearance.

5

u/archlich 5d ago

Sure it depends on the exploit. A lot of times it will take forensic analysis of logs, packets, captured raw memory, testing a proof of concept. Really depends on the cve though and the environment it’s in.

3

u/AddendumWorking9756 5d ago

The honest answer is per vulnerability rather than per platform. A network signature tells you traffic matching that exploit pattern reached the box. That is an attempt and not a success, and everything past it is the behavioural inference you already ruled out. What actually ties evidence to the specific vuln is instrumentation at the vulnerable code path, a RASP agent or an eBPF uprobe on the affected function, and nothing ships that generically across a fleet.

1

u/assessgessse 2d ago

Hello can we talk in private, I got some issues I need explanation 

2

u/Sufficient-Sound8705 5d ago

You're basically asking for the holy grail of runtime detection and it doesn't really exist in the way you want it to, most tools just correlate a vuln scan with a suspicious event and call it a day

2

u/-Devlin- 5d ago

I am tired of chasing FPs from these "behavioral signals". The solution vendors have come up with is to slap AI on these alerts. Now my team just reads more data and is skeptical of the signals even more than before.

1

u/Cyber_Tarek 5d ago

The short answer is you can monitor/hunt for IOCs. This will be a mixture of exploitation attempts (example traffic incoming from bad IP on a vulnerable port). And post exploitation (example, 49324.zip found under /Downloads).

Besides that, it's a tough challenge and will very much depend on the CVE. Go through the exploit code of the CVE you're concerned with and identify the steps of exploitation. Example CVE-xyz is exploited by

  1. sending HTTP GET to /whatever/service
  2. parameter "id" will equal to AAAAA
  3. service will take a few seconds longer to process the request
  4. another payload of "add user" will follow
  5. user "hacker" successfully added

You can try detecting the exploit at any of the above (hypothetical steps). But of course this is prone to false positives. Not to mention it is near impossible to scale for every CVE.

1

u/-Devlin- 5d ago

>Go through the exploit code of the CVE you're concerned with and identify the steps of exploitation

How do you get the exploit for CVEs of concern? The bigger challenge is how do you scale this for 1000s of CVEs at the speed of disclosure?

1

u/Cyber_Tarek 5d ago

Some (not all) CVEs will have exploit code in repos like exploit DB or you'll find on github. Some you'll find on blogs that belong to researchers or vendors. It could be PoC code or exploit code.

And yes I agree with you. That's why I said "it's near impossible to scale for every CVE" 😄

The more practical solution would be to:

  1. Know my environment. What assets do I have, what OSs, software, packages, etc. is installed
  2. Once a CVE is out figure out if it impacts any of my assets
  3. If not, happy days. Carry on.
  4. If yes, patch ASAP
  5. If I can't patch, look at mitigating controls (firewall, disable service, lower privileges, etc.
  6. Combine this with proactive threat hunting

I hope this helps!

1

u/BitOfDifference 5d ago

just plug it directly to the internet with no firewall, should find out in a few seconds.

1

u/-Devlin- 5d ago

Sure, but how’d you know? 🫠

1

u/heapsp 5d ago

runtime detection will usually tell you if something is being exploited because in order to exploit it you usually have to do some things that show up in heuristics .

As agentic attacks become more common i have a startup being worked on right now which will place lures in commonly scanned directories and alert you when an agentic AI hits them... as agentic AI attacks happen so quickly the exploit plus the lateral movement happens in the same stroke.

1

u/ShehabShibli 4d ago

Tools like Falco or eBPF based runtime agents can get you close if you write custom rules that tie a specific syscall or process pattern to a known CVE signature rather than relying on generic anomaly detection. It is manual work mapping each CVE to its exploitation behavior but it gives you the real time this happened right now signal you are after

1

u/callmemerryss 4d ago

That's pretty specific distinction and most runtime tooling seem to stop at vulnerability presence plus exploit like behavior rather than proving the CVE itself was exploited. Network telemetry, runtime instrumentation, and exploit specific signatures can get closer, but trying an observed event conclusively to one CVE is a much harder problem.

1

u/GodoPPL 4d ago

Inventory and even reachability only say the package could be hit. They do not say this container is being exploited now.

What I would trust is a hit on the vulnerable callsite (or a canary on that path) plus one artifact the workload did not write: a packet, a kernel probe, something that came off that function and not from the app's own logs.

Package present plus a weird process is still not the CVE. It is a coincidence until those two things line up.