r/threatintel

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

We're paying for threat intel feeds that market themselves as "operational" and "actionable." In practice, we get glossy PDFs for executives, CSV and STIX bundles on a schedule, and portal access where we export data by hand. None of it arrives in a form that connects cleanly to our detection engineering workflows. My team spends half a day every time a "high priority" bulletin arrives: parsing the report, pulling out domains and hashes, mapping TTPs to our environment, and then forcing it into whatever format our SIEM expects.

Two weeks later, the same feed sends another report with overlapping but slightly different indicators, and the cycle repeats. By the time we have a rule in production, the campaign has already been around for days or weeks. Reports describe behaviors like "creates a new service for persistence," while our environment is a mix of Windows event logs, Sysmon, and custom agents.

Turning those descriptions into detections means knowing which events exist, which fields matter, and how that behavior would appear in the logs. We end up spending more time on data wrangling than on actual detection engineering or threat hunting.

How are other teams making threat intelligence actually operational? I need a clean path from "new threat report" to "production-ready SIEM rule" without burning a week per report.

So, to give some background. I lead the threat intelligence program of a major bank. Now we receive tons of IOCs/CVEs and brand abuse/impersonation cases and we do take action on them accordingly.

But whenever we create a presentation, it's always numbers

- no. Of IOCs we received, sources (regulator/commercials)

- social media/brand abuse/impersonation/rogue apps count & takedown status.

But execs don't understand these numbers. How can I present the data such that they are assured that we are safe from any kind of threat & prepared for what's coming in the future.

Been researching lots of things but didn't quite get anything. Would really appreciate your views and guidance here.

I’m currently on my last year pursuing a BA in Criminology and I’m planning to venture in Digital Forensics/ Cybersecurity
I’m completely new in this field but at the same time have a deep passion for it. I’d love to work with Law Enforcement or Corporate as long as investigations are involved.
I’m also planning to volunteer in relevant institutions/ parastatals as I finish school for the experience and learning.
Any recommendations or advice on roadmaps I should follow?

You can tune detections and automate a lot of repetitive work, but some alerts still take up way too much time.

What kind of alerts are the hardest to deal with?

iCyS Capture the Flag: Sisterhood of the Traveling Packets — powered by Flare & SANS, running August 17–19.

Flare partnered with SANS and WiCyS to put together a CTF for people who've never done one. If you have Tor Browser and an hour, you have everything you need. No downloads, no paid tooling, no prior CTF experience.

The scenario: a ransomware collective got careless with their OPSEC. You'll work through their dark web leak site and turn their mistakes against them: forensics, exploitation, and a bit of decoding. Hunters become the hunted, etc.

What's in it:

• Fully browser-based, live August 17–19
• First 250 solvers get a Sisterhood of the Traveling Packets shirt via the Flare merch store
• First three solvers get a SANS on-demand course + an annual WiCyS membership (if you're not already a member)

Who can play: WiCyS members and non-members, US and international, entry through senior career levels.

Sign up here: https://forms.wicys.org/zohodocs1545/form/FlarexWiCySCTF2026/formperma/qXgVqwzo1aOl53aDwB9cU1z9hrovwku5NSg9BY8wMAo

Happy to answer questions in the comments!

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 

The LiteLLM supply chain attack exposure data is in, and the 40-minute PyPI window everyone reported was the last act, not the whole story.

Our record-level analysis of 2,188 organization records found:

→ 95% of affected orgs show collection activity before the poisoned LiteLLM packages even reached PyPI on March 24
→ The actual compromise chain started 5 days earlier, tracing back to a hijacked Trivy scanner in LiteLLM's build pipeline
→ Exposure spans 6 CI/CD platforms, not just GitHub Actions
→ The credential mix goes well beyond AI keys: Stripe payment keys, Twilio/SendGrid tokens, and npm/Docker publishing credentials all turned up in the dataset
→ Harvested data is already being brokered on Telegram, bundled with two other TeamPCP campaign stages

LiteLLM is a transitive dependency of MLflow, CrewAI, DSPy, OpenHands, and Arize Phoenix, so plenty of orgs in the dataset never knowingly installed it.

Full breakdown with IOCs, remediation steps, and the exposure dataset methodology on our blog.

Hey everyone!
I'm fairly new to threat intelligence, and I've been trying to understand which attribution details are actually worth paying attention to.
When you look up an IOC, what's most useful to you: the malware family, campaign, threat actor, related tools or infrastructure, or something else?

We found a new Mini Shai-Hulud variant that makes the worm a general Linux post-exploitation payload and continues through with Github and NPM propagation.

Hi guys,

I handle threat intelligence for a bank & we receive multiple URLs/APKs impersonating our organization.

We check for legitimacy & immediately send it for takedown if it's not related to us or if it's malicious.

I wanted to know if anyone of you also side by side does forensics/malware analysis of such APKs to know the TTPs & relevant information pertaining to that APK?

If Yes, please let me know the procedure being followed at your end.

TLDR - I realize that my experience has little overlap with this field, so I'd like to know what kind of projects I can do to fill the gap. Or if there are alternatives to projects, I'd like to know what those are. Stuff that would go on my resume, essentially.

I have about 3.5 years in cloud tech support and a bachelor's in computer science.

The bread and butter services I support are virtual networks, web application firewalls, ddos response, dns, etc. Tons of network/dns/firewall troubleshooting, linux, writing firewall rules, log analysis, assisting customer incident responses, and so on.

I learned about this field after asking AI what jobs involve things like researching CVEs, which I did for customers and really enjoyed.

Are there any other roles I should look into? I work for a cloud provider. If it helps, I have a sandbox account at work where I can build my own infra but can't expose any endpoints to the public.

i'm trying to find a real way to show the value of our threat intel program rn, beyond the "we have feeds and reports" story.

budget covers commercial feeds and vendor reports, plus whatever we pull from open source and community intel. the program looks mature but when mngmnt asks what we're getting for that spend, the answers feel thin. counting reports or iocs doesn't tell you whether breach risk went down or detection got better.

my boss flagged the roi framing. his point was that threat intel is insurance, and you don't measure insurance the way you measure a return. fair, but it doesn't answer the real question, which is how you show this stuff is working.

what i want to track: detection rules that came out of intel, plus time to detection on campaigns we already knew were coming. same goes for visibility gaps we closed because someone flagged them first, before they became an incident.

if you own a threat intel budget and have a reporting format that's held up under management review, especially one that explains this to a non-technical audience without a dollar-return angle, what did you use?

[removed]

Looking for advice. I've been in an active investigation for a year and uncovered mass abuse of a major cloud platform bgp abuse and mass forced malicious proxying. Nothing can be done without the carrier assistance or government intervention its so rampant. I've attempted reporting but am concerned traffic is being misrouted to avoid detection. What would you do?

I’m getting into threat hunting and one area I’m struggling with is distinguishing genuinely malicious/suspicious activity from normal behavior. For example, when investigating an unknown process, hash, IP, or domain, how do you determine whether it’s actually a true positive or just benign/false positive activity?
Are there any good resources, labs, methodologies, or practical guides that helped you build this intuition and get better at identifying unusual behavior?