r/blueteamsec

How does your SOC check when someone is trying to kill EDR agents like BYOVD attacks? On the attackers side do you have a dedicated pen tester/red teamer trying these attacks?

An operator left their full working directory exposed on an open HTTP server. Hunt.io crawled it, 2,616 files, and rebuilt the campaign from the corpus.

• Three exploitation paths in parallel: an asyncio credential brute-forcer, a CVE-2021-33044/33045 auth-bypass chain, and P2P relay abuse reaching cameras by serial number
• The relay path never authenticates the connecting party, only the session, via a cloud-issued token obtainable with the fixed SDK credentials in every Dahua client
• Two CVE labels in the tooling don't hold up: CVE-2024-39943 is an unrelated Rejetto HFS flaw, and CVE-2025-31702 is a narrower post-auth case, not the unauthenticated relay abuse (that path is a separate non-CVE issue documented by ITRES)
• Full PTCP tunnel breakdown, including the Inverted STUN packet and the bind-to-127.0.0.1 technique

Neutral attribution throughout, the corpus shows how the operation was built and run, not who ran it.

Check the full breakdown, IOCs and mitigation strategies:
https://hunt.io/blog/operation-cameraswarm-dahua-cameras-compromised

I revisited this malware variant that I came across in the wild to demonstrate to everyone how it works. Stay safe and I hope this helps someone learn something!

A user receives Uber OTP codes via WhatsApp every day since August 5. The sender shows up as Uber with a verified business account. The user has never registered an Uber account.

Context first: Uber does deliver OTPs over WhatsApp, so the channel alone proves nothing. These look are real codes, from Uber legitimate WhatsApp Business account, not smishing.

Technical hypothesis. The OTP trigger on the WhatsApp channel doesn’t seem to have effective per-recipient rate limiting, while SMS appears to be capped. That would explain the channel choice, you hammer where there’s no limit. The trigger also seems independent of account state, it fires whether the number is registered or not.

I checked for a link to a separate exposure. The user’s email shows up in infostealer and combolist data, but the phone number is not present in that data. The two look unrelated.

What I can’t place is the threat actor’s objective. Only the victim receives the code, so either a contact will eventually ask them to forward it, which puts us in social engineering, or the code is irrelevant and this is harassment, noise, or number enumeration. So far no one has reached out asking for a code.

Thanks to anyone willing to weigh in.

Zoom's annotation parser read a count off the wire and copied twice that many bytes into a fixed 128-byte buffer with no bounds check, letting any participant corrupt memory on every other client in the call, with no action from the victim.

Fixed in Zoom Workplace 7.1.5 and 7.0.6, VDI 7.0.11 and 6.6.16, Rooms and Meeting SDK 7.1.5.

Disclosure: our team's (A Security) research, reported to Zoom and fixed with them.

Writeup on two open directories we recovered, with a defender-focused breakdown of the camera and router compromise techniques and the network behavior their proxy tooling produces.

Detection and mitigation angles worth pulling out:

• Edge devices opening outbound connections on port 4444 (chisel reverse tunnels) is a strong compromise signal
• Sequential ONVIF and RTSP discovery and repeated hits on camera ports show up better at the network boundary than in camera logs, which are usually shallow or absent
• Credential guessing was the primary access path before any CVE was tried, so default and weak creds on cameras and routers are still the main exposure
• Exploited camera CVEs are years old and long patched (Hikvision, Dahua); TP-Link Archer and MikroTik were the router targets
• Every targeted device answered directly from the internet, so pulling cameras and routers behind a VPN or onto isolated VLANs removes most of this

Outcomes against the government and military sites in the operator's bash history are not confirmed from the files. Full mitigations and ATT&CK mapping in the post:
https://hunt.io/blog/russian-speaking-operator-ukrainian-camera-toolkit 

Chaining 3 CVEs to exfiltrate sensitive ERP data.

Built this around a question I kept coming back to when looking at BloodHound graphs:

The shortest path to an objective is easy to calculate, but is it actually the quietest path?

NoiseHound takes BloodHound CE data and scores attack paths against their expected detection surface rather than treating hop count as the primary optimization target.

Each supported BloodHound edge is mapped against things like Windows Security events, Sysmon, EDR/ITDR heuristics, MITRE ATT&CK techniques, audit dependencies, and an estimated noise score.

The important part is that the scores don't have to remain static.

NoiseHound supports environment profiles so things like 4662 auditing, Sysmon, PowerShell logging, MDI, or manually calibrated edge scores can change the ranking for the environment you're actually testing.

There is also a calibration harness for recording what actually fired in a detection lab and producing an environment profile from those results. The repo currently includes measured audit, Defender for Endpoint, and Elastic SIEM profiles.

Other pieces currently implemented:

• BloodHound ZIP/JSON ingestion
• live BloodHound CE / Neo4j ingestion
• k-quietest-path ranking
• detection-probability ranking
• Pareto frontier over noise/hops / P(detection)
• AD CS ESC1–8 synthesis
• Sigma rule coverage analysis
• environment-aware scoring
• text / JSON / standalone HTML reports
• defensive detection-gap mode

The defensive mode flips the same model around: given the quietest path, what telemetry or detection gap makes that path quiet, and which control would increase its score the most?

One design constraint worth calling out: these aren't presented as universal “OPSEC scores.” Detection depends heavily on audit policy, EDR, SIEM content, tooling, SOC correlation, and the environment itself. Static scores are the baseline; environment and measured calibration are intended to replace them where better evidence exists.

NoiseHound doesn't execute anything against the target—it operates on BloodHound data that has already been collected.

GitHub:
https://github.com/warpedatom/noisehound

I'm particularly interested in feedback on the edge-to-telemetry mappings and scoring model from people doing AD red teaming, detection engineering, or BloodHound research.