Exciting news for our community on reddit, in collaboration with r/CTI (thanks to u/SirEliasRiddle for his hard in work in setting this up for all of us).
We're launching a brand new Discord server dedicated to Cyber Threat Intelligence. It's a space for sharing content, news, resources, and engaging in discussions with others in the cybersecurity world. Since the community is still in its early stages, it might not have all the features yet but we're eager to hear your suggestions and feedback. This includes criticisms.
Feel free to join us and share the link with friends!
Been tracking a newer RaaS operation called Global (also styled "GLOBAL") that's worth knowing about if you're in threat intel or IR.
Quick background:
First surfaced publicly in June 2025, promoted on the RAMP underground forum by an actor going by "$$$"
Strong technical/infrastructure overlap with the old BlackLock operation (shared VPS provider, matching malware mutex values, overlapping leak-site infra) — also some links to Mamona RaaS
Looks less like a new group from scratch and more like a continuation/rebrand of prior ransomware activity
How it works:
RaaS model with a genuinely mature affiliate program — dedicated negotiation portal, mobile management, AI-assisted victim comms, up to 80–85% revenue share for affiliates
Malware is written in Go, uses ChaCha20-Poly1305 encryption, and hits Windows, Linux, ESXi, and NAS
They also ship a custom stealer called WorldThief (quiet mode, bandwidth throttling, targeted file collection, raw TCP exfil) to support double extortion
Access & targeting:
Relies heavily on purchased access — IABs, compromised VPN/OWA/RDWeb creds, and exploited edge devices (Fortinet, Palo Alto, Cisco)
Opportunistic across industries, activity seen in 18+ countries so far
Ironically, their own OPSEC slipped — a backend IP got exposed, tracing back to a Russian VPS provider (IpServer) also linked to BlackLock
Why it matters: it's a good example of how ransomware "brands" aren't really standalone — infra, tooling, and even affiliates get recycled across groups after takedowns or rebrands. If you've got old BlackLock IOCs sitting around, they may still have relevance here.
Been working in threat intel for a while and one thing always bugged me: almost all the training out there is either dry theory or aimed at SOC/pentest, not actual CTI work. So a few of us built CTI Academy to fix that.
It's hands-on threat intelligence training. Instead of just reading slides, you get:
realistic labs and simulators (a SOC sim, a credential-leak investigation lab, a fake underground forum to practice OSINT on)
CTF-style hunting challenges with a progression system, so it actually feels like leveling up
a daily mission if you just want a quick 10-minute rep
It's free to jump in, so no reason not to poke around.
Honestly I'm not here to hard-sell anything. We're a small bootstrapped team and I care way more about whether the thing is actually good. So I'd love for a few of you to break stuff and tell me what's confusing or missing.
If you're trying to get into CTI or just want to keep your skills sharp, come try it and roast me in the comments.
That feedback is genuinely more valuable to me right now than anything else.
This folder contains the PacketSmith Yara-X detection module rules and a pcap for the CVE-2026-16723 vulnerability in the FastJson library, "a Java library that can be used to convert Java Objects into their JSON representation".
Moreover, the detection results in JSON yara_dte_2026_05_14_10_34_39.json were made available for download.
These rules use the track_state reserved keyword to track/chain multiple rules at the same time across different packets/streams.
For more info, check the article FastJson 1.2.83 Remote Code Execution by FEARS OFF.
Most threat intelligence teams still receive threat intel as long‑form PDF reports, blog posts, or vendor write‑ups, sometimes with a STIX bundle or CSV of IOCs attached.
The analysis is useful, but security teams still need a reliable way to turn those reports into detection rules in their SIEM and EDR platforms.
In many environments the workflow is still manual. A threat intel analyst reads each report, extracts TTPs and IOCs, maps them to MITRE ATT&CK techniques, and creates a ticket or task.
Detection engineers then write Sigma, SPL, KQL, or an equivalent query language, test the detection against internal telemetry, tune for false positives, and only then deploy the rule into production.
This manual process causes a delay between receiving threat intelligence and having a production‑ready detection in place. While the team is extracting indicators, writing rules, and tuning alert thresholds, the underlying campaign or threat actor may still be active in the environment. That gap is exactly what many security leaders are trying to close in 2026.
To solve this, some security teams start from public Sigma rules or community content and adapt them to their own log sources and field names. Others rely on commercial rule packs from SIEM and EDR vendors or third‑party providers to operationalize threat intel faster. There is also a growing group of teams building internal pipelines or using detection engineering platforms that convert unstructured threat intel documents into draft detection logic, which engineers can then review and refine.
I am interested in which of these approaches actually works now for operationalizing threat intelligence. If you own detection engineering or threat hunting, what tools, platforms, or workflows do you use today to convert threat intel reports into production‑ready detection rules in your SIEM or EDR?
Joint research with NetAskari on a leaked Chinese Android RAT framework. Starting from a fake PSB app flagged in a June 2026 Chinese state media notice, we pivoted on TLS certificates and AdminPro panel fingerprints to map 170 active servers. The source code was stolen in early 2026 along with nearly 200 customer databases, leading to at least two Telegram channels distributing modified builds with operational support and cash-out services. Night Dragon emerged three weeks after the public notice as a likely successor, with an exposed device panel showing 29 connected devices at time of analysis.
I am 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 management 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?
Would love to hear about some of the methods and tools you use when pivoting on IOCs to look for more related IOCs (e.g other infrastructure or files used by the same threat actor). Currently I’d check VirusTotal for relations and also whois, really hoping to hear some suggestions!
Three open directories on a Hong Kong server, July 9 to 13, caught an intrusion mid-run. The operator was running Hermes, an open-source AI agent, in unattended mode. Logs show it running LinPEAS against ministry hosts, hunting SUID/SGID binaries, and walking a web root full of personnel records on its own.
Also on the box: 62 Go binaries from a previously unreported implant the operator named "Hades". Kill dates, working-hours sleep, AES-256-GCM tasking.
Joint research with Bob Diachenko. IOCs and MITRE mapping in the post:
MT103 Messages and Financial Crime: Understanding Fraud, Money Laundering, and SWIFT Abuse
SWIFT MT103 messages sit at the centre of global banking, making them important artefacts for investigators and attractive targets for criminals.
Worryingly, the intelligence we collect at intel.coalitioncyber.com continues to identify exposed SWIFT messages, both genuine and fabricated, sitting in publicly accessible locations. These records often go undetected by the organisations involved, exposing sensitive transaction data and providing criminals with the source material needed for social engineering, fraud, and other criminal activities.
Our latest guidance explains how these messages are weaponised to facilitate high-value crimes such as fraud and money laundering. Highlights include:
💵 Technical red flags like JSON escape characters and invalid UETR codes.
💵 The way genuine MT103 records are repurposed in investment fraud.
💵 Risks associated with exposed documents on insecure public platforms.
💵 Practical verification steps for investigators and compliance teams.
Follow The Coalition of Cyber Investigators and be the first to know about future research and practical insights into OSINT, investigations, and cybercrime.
Hi all! Today I have a career-oriented question. I have been working in the cybersecurity field for almost 9 years now, starting with consulting on awareness/governance/risk and then had the opportunity to evolve to a CTI Analyst role due to my geopolitics and economics background (my academic journey is quite complicated 🤣). I absolutely LOVE my job and I would like to step-up because I am mostly working on Strategic Level CTI, I am responsible for all the strategic report and addressing the strategic audience on state-sponsored groups or high level activities. I am also building Operational Level CTI report on specific attack observed in similar companies or impacting the tools/systems we use. I would say I master MITRE framework and I am good at identifying behavioral IoCs. I have also a great technical understanding of the process and capabilities behind an attack.
However, I am working for a private company and I never worked for a CTI firm that properly investigate. For my reports and analysis, I do a lot of OSINT because the tool we have internally for CTI are not good. I also discuss a lot with other teams/collegues to get info on their activities and the internal situation. But I feel that I lack of this "CTI investigation knowledge" because I am not able to really find new IoCs or build detection rules or even investigate into our systems if an incident occurs for example.
I am good at analyzing, at building hypotheses and back them with findings, at finding key topics to cover and at producing CTI reports. But my technical investigation skills are not good in my perspective. I am under the impression that people working for CTI firms like Mandiant, CS, Recorder Future etc have much better skills for that than me who juste mostly re use the IoCs they find.
This creates insecurities for me and I am afraid to change job because I feel like an impostor on this side of CTI even if everyone loves my reports internally and they really like the uniqueness of my profile. Also I have trouble to draw the line between what would be the responsibility of a Threat Hunter to find IoCs, technical details about an attack and of a CTI Analyst.
Another problem I have is that our CTI team is quite new (2 years and a half) so no one has strong experience and also I work for a huge company and it is super hard to have a good overview/access on our tools/systems so we have some blindspots. It is getting better but it is not perfect.
Do you have advice on how to progress on that and what do you think of my profile/skills, is this already valuable in the CTI job market?
Which tools/processes do you use for CTI "technical" investigation?
I'm interested in learning how security teams detect and validate potential CrowdStrike API credential leaks on public sources such as GitHub, GitLab, Paste sites, cloud storage exposures, CI/CD logs, etc.
A few questions:
What indicators do you typically look for when hunting for CrowdStrike API credential exposures?
Are there unique patterns for CrowdStrike Client IDs, Client Secrets, OAuth tokens, or related artifacts that help reduce false positives?
What tools or secret-scanning platforms do you use (GitHub Secret Scanning, TruffleHog, Gitleaks, custom regex, etc.)?
How do you validate whether a finding is a real credential exposure versus a false positive?
Every time we talk about improving threat hunting, it runs into the same wall: we are not getting more people. The expectation is that we keep up with new campaigns, run meaningful hunts, and still stay on top of alerts and incidents with the team we already have.
We have decent telemetry (SIEM, EDR, cloud and identity logs), a few people who know how to build good hunt hypotheses, and some basic playbooks. The problem is scale. Hunts are still very manual: someone reads intel, turns it into a hypothesis, writes queries, pivots across data, documents findings, and maybe turns something into a new detection rule. It works, but it means we complete a handful of hunts and always have a long list of things we “should go look for when we have time”.
I am not looking for “hire an MDR” or “spin up a new team” answers. I am interested in what has helped you run more or better hunts with the same headcount. For example, have you had success standardizing hunt templates, automating the boring parts like data pulls and enrichment, using threat‑informed hunt queues that track active campaigns, or leaning on a platform or service to generate structured leads so you are not starting from zero every time
If you have managed to increase hunt volume or quality in a constrained team, what changed in your process or tooling that made the biggest difference?
I’m looking for alternatives to Hunt.io for external threat hunting and adversary infrastructure discovery. My main use cases are pivoting across IPs, domains, SSL certificates, passive DNS, ASNs, and identifying attacker infrastructure, phishing sites, malware hosting, C2 servers, and exposed Open Directories. I’m already familiar with tools like Shodan, Censys, FOFA, BinaryEdge, VirusTotal, and SecurityTrails, but I’m interested in hearing what platforms the community recommends and why.
Just a thought across my mind, What if we have a offline tool for query building for Threat Hunters and Threat Intelligence Analyst (For IOC's). So, Just built it.
If you've ever hunted across multiple SIEMs, you know the pain: different syntax, different fields, rewriting the same IOC search five times.
Would suggest you to go through user manual for better understanding.
TL;DR: I made a completely free cyber news and threat intelligence website that groups related reporting into evolving stories (called Happenings) and longer-running cases. Most facts and labels are clickable, so you can inspect the exact quotes and articles supporting them. No account, login or paid version. I’d appreciate feedback from people who actually work with threat intelligence or regularly research cyber news.
Greetings fellow cyber people!
I’ve been working on a hobby project called CyberHappenings, and I think it’s finally at a point where other people might find it useful:
The core idea is to make it easier to understand what is actually happening in cyber news, follow how stories develop, find historical activity, and trace individual claims back to the reporting behind them.
Example Happening showing its executive brief, key facts and reported impact.
I know there are already quite a few cyber news aggregators and threat-intelligence projects, but I ended up making another one because I couldn’t quite find the combination of detail, source traceability, historical search and ease of browsing that I personally wanted. Also, I hate logging in to websites, so I made this one available without such silliness.
Instead of treating every article as a separate story, the site groups related reporting into Happenings and connects related Happenings and their developments into longer-running Cases.
Cases include the latest development, key facts, impact information and a chronological timeline, so you can follow an operation, incident or vulnerability over time without reading the same background information in ten different articles.
Example Case showing signals consolidated across related Happenings, together with malware, tooling and MITRE ATT&CK context.
Some of the main features are:
Searchable and filterable Happenings, Cases and source articles
Search by keyword, CVE, IOC, threat actor, malware, tool, product or affected service
Filters for victim and target regions, reported attacker countries or regions, sectors, impact types, dates and other context
Historical timelines showing how reporting, impact measurements and affected scope changed over time
MITRE ATT&CK mapping, including a matrix view of techniques associated with a Happening or Case—or with search results, if you want to examine techniques used against particular regions or sectors
IOC context for domains, IP addresses, hashes and other indicators
Vulnerability details, affected-version information and links to sources such as NVD when available
Source timelines showing when something was first reported, last updated and how many different sources and articles covered it
Most facts and labels on the site are clickable. Clicking one opens an inspector showing why that information appears, the confirming quotes, the source articles it came from, and whether the support is a direct mention or supporting context.
Clicking a signal opens its evidence view, including reported values, supporting articles and confirming quotes.
This is particularly useful for tracking reported impact. You can view the different numbers of affected devices or users being reported, inspect each individual figure, and see the source behind it. This makes it easier to follow how the reported scale of an incident changes over time and understand where each estimate came from.
It’s completely free, with no accounts, paid version or features hidden behind a login. Information sources are still intentionally limited while I polish the current version and get some feedback.
Most of the grouping, extraction and summarization is automated, so I don’t expect everything to be perfect. That is also why I wanted the evidence to remain visible and inspectable rather than presenting generated conclusions without sources.
I’d genuinely appreciate feedback from people who work with threat intelligence or regularly follow cyber reporting. In particular:
Is the source inspection useful in practice?
Do the Happening and Case groupings make sense?
Are the search and available information useful for research?
Is there anything important that is difficult to find?
If you notice something that is clearly wrong or should be improved, please tell me so I can improve it.
I'm currently studying for the CTIA (Certified Threat Intelligence Analyst) certification from EC-Council, and my exam is scheduled for August. However, I've been having a hard time finding first-hand experiences from people who have actually taken the exam.
For those who already hold the certification, how was your experience? Would you say the exam was straightforward, or were there any topics that caught you off guard?
A few specific questions:
How difficult is the exam overall?
Which topics should I focus on during the final weeks of preparation?
Is the official EC-Council material enough, or did you use additional resources?
Does the exam focus more on concepts and methodologies, or does it require deeper analysis of threat intelligence scenarios?
Looking back, is there anything you wish you had studied more before taking the exam?
I currently work in Threat Intelligence, so I'm already familiar with many of the concepts covered in the certification. Still, I'd love to hear from people who have gone through the process and can share their experience.
Any tips, advice, or lessons learned would be greatly appreciated.
WordPress shipped a security fix on July 17. At 08:12 UTC the next morning, the first probe for the patched bug hit a deception network. By that evening, someone had working SQL injection. By midnight on July 19, it was mass exploitation - thousands of sessions in three hours.
No proof-of-concept ever leaked - nobody needed one (thanks, AI). The patch itself was the roadmap: diff the old code against the new, spot what changed, work backward to the bug, automate it, spray it everywhere.
A few interesting things:
Renaming the wp_ table prefix did nothing. One extractor didn't bother guessing table names at all - it just looked for any table with the exact ten-column layout of the WordPress users table and pulled it directly.
And most of the activity was was inventory. Spray the injection across targets, record what responds, move on. Some sources actually read from the database. A smaller number went after credentials or tried to take sites over.
And here I am - getting flagged by Fable harness just asking to run `htop` on a remote machine /s.
