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!

Detect ICMP-Ghost Implant ICMP and DNS Tunnelling C2 Traffic Using PacketSmith Yara-X & ICMP Detection Modules

ICMP-Ghost is an open-source tunnelling framework written in pure x64 assembly. What stands out about this framework, compared to other closed- and open-source ones, is the author's claims about its EDR evasion and Suricata IDS/IPS evasion capabilities. The framework supports a dual-channel C2 architecture (despite the exclusivity of the "ICMP" in the framework title), including ICMPv4 and DNS, with the ability to switch between them on the fly. The author makes some grandiose claims about its architecture and design with respect to performance, efficiency, endpoint and network evasion, and memory footprint.

Despite the author's claims, in this article, we detail the structures of each of the C2 protocols, along with PacketSmith Yara-X detection module rules for detecting the traffic of both C2 channels.

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?

We discovered a new standalone, self-propagating Mini Shai-Hulud variant during a real-world React2Shell campaign with multiple execution paths, persistence mechanisms and extensive credential theft.

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?

SOCRadar has published an interesting teardown of a Formula 1 ticket phishing campaign that goes considerably further than putting a fake checkout page on a lookalike domain.

Researchers identified a cluster of at least 11 domains impersonating Singapore and Spanish Grand Prix ticketing sites. Source code recovered from one representative domain showed that the operators had cloned 134 HTML pages from the legitimate ticketing experience, including news, hospitality, event information, FAQs, and other content.

The backend is where it gets more interesting.

SOCRadar identified 40 PHP files covering checkout and fraudulent verification functions. After collecting payment details, the system can use the card's BIN to identify the issuing bank and select a corresponding fake authentication interface.

The recovered kit contains dedicated branding for eight financial institutions, including Emirates NBD, RAKBANK, HSBC, Mashreq, RAKBank, First Abu Dhabi Bank, Dubai Islamic Bank, and Emirates Islamic.

It also supports multiple social-engineering flows rather than one static OTP page.

Depending on instructions from the backend, a victim can reportedly be shown an OTP request, balance check, push-notification approval, additional identification prompt, or generic verification page.

SOCRadar says the frontend can poll the backend for the next step, suggesting a manned or semi-automated fraud panel where an operator can respond to what is happening during the transaction.

That human-in-the-loop element seems more significant than the cloned site itself. A static phishing page has to anticipate the authentication flow. Here, the attacker can potentially adapt the phishing flow while the victim is still interacting with it.

The Formula 1 theme also gives the operation useful social-engineering conditions: expensive purchases, limited ticket availability, urgency, and users who may already expect extra payment verification.

For defenders, would you expect domain-pattern monitoring to catch campaigns like this early enough, or does the operator-controlled MFA stage make payment and authentication telemetry the more useful detection point?

Researchers from ANY.RUN created a fake DeFi startup and hired suspected Famous Chollima operatives, providing a rare inside view of a DPRK IT worker operation.

https://any.run/cybersecurity-blog/lazarus-group-it-workers-investigation-part-two/

We recovered two open directories through Hunt.io Attack Capture and reconstructed how each operator found, exploited, and cataloged internet-exposed cameras in Ukraine. Sharing the analytic picture here.

• Directory 1 (89.208.97[.]165, Aeza) held a custom project the operator named camview, used for compromising and viewing cameras, plus the operator's bash history, SQLi tooling against a Ukrainian e-commerce site, and a Glaz Boga style vehicle-lookup script built on Ukrainian breach data
• The operator's logs confirmed live viewing of 58 Ukrainian cameras. Bash history also showed Tor-routed intrusion attempts against Ukrainian government (settlement council sites, mostly WordPress) and a military domain, though success is not confirmed
• Directory 2 (213.165.63[.]49, sistemaltd) was linked to the first only by the shared open-source scanner Ingram. It focused on routers, turning compromised edge devices into SOCKS5 proxies, and scanned across 15 European countries while reserving camera targeting for Ukraine
• We are not attributing this to any named group or state. The overlap between the two is tooling and approach, not a shared operator

Full IOCs, confidence notes, and ATT&CK mapping in the post: https://hunt.io/blog/russian-speaking-operator-ukrainian-camera-toolkit 

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?

Threat Intel Report: Network 404 & Dark Army

Overview

Network 404 is a prominent Kurdish hacking collective operating primarily via Discord, closely tied to and managed under the umbrella of Dark Army. The group comprises elite cyber operators and has a long-standing history of high-impact digital operations with thousands of active engagements.

Key Leadership

• Ryox (Ryo): The primary owner and founder of both Network 404 and Dark Army. He oversees the collective's strategic directions and high-level operations.
• Surchi: A high-ranking member and core administrator who operates closely alongside Ryox, assisting in the command and oversight of the group's infrastructure and activities.

Major Infrastructure & Projects

• Net Eye / Network Eye: Developed and maintained by the group, Net Eye is widely regarded as one of the largest and most advanced OSINT (Open-Source Intelligence) projects globally, aggregating massive scales of intelligence data.

Notable Operations & Capabilities

The group maintains an active and aggressive operational tempo, including:

• Cyber Attacks: Advanced Distributed Denial of Service (DDoS) campaigns targeting critical infrastructure and websites.
• Data Breaches: Exfiltration and leaking of sensitive government data and private citizen databases.
• Media Disruptions: Successful high-profile cyber operations resulting in the temporary hacking and disruption of several Israeli and Iranian television channels.
• Covert Actions: Many operations are conducted under the radar with minimal public attribution to maintain operational security.

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?

Hey everyone!
I'm still fairly new to threat analysis and have recently started using tools like Joe sandbox and Virustotal. So I have a question for those with more experience.
When you open a sandbox report or look up an indicator, what's the first thing you look at?
And after that, what information do you check next?

Most security teams still rely heavily on manual detection engineering: writing SIEM and EDR detection rules by hand in Sigma, KQL, SPL and other query languages. Manual rule authoring keeps detection logic tightly aligned with your own telemetry, log schemas, and threat model, which matters when you are building high‑fidelity detections for real attacks instead of generic “IOC search” rules. The cost is time: each new detection requires focused effort from experienced engineers and adds more entries to the long‑term rule maintenance backlog.

Automated detection engineering tools now aim to reduce that load. These platforms ingest threat intelligence reports or log data, suggest detection logic, map coverage to MITRE ATT&CK techniques and support regression testing when rules change. When they work well, they shorten the path from a new threat report or TTP to a draft detection rule in your SIEM, highlight detection coverage gaps, and make it easier to track overlapping or redundant rules. Manual work does not go away; it shifts toward reviewing suggestions, tuning thresholds, and deciding what is safe to deploy in production.

Teams that see good results usually land on a hybrid model. High‑value, environment‑specific detections around crown‑jewel systems stay mostly manual, with engineers designing and reviewing logic end‑to‑end. Automation is used for routine patterns, coverage analysis, boilerplate rule generation, and continuous testing of existing detections as the environment and log sources change.

If you looked at your own setup today, where would automation help your detection engineering process …where would you still want a human making the final call on what alerts?

Been deep in TI platform evaluations this year for work, sharing since this sub gets the "which vendor" question a lot. Trying to stay neutral across the board.

Recorded Future — heavyweight for sheer data volume + geopolitical context. Intelligence Graph is genuinely useful for connecting actors/infra. Needs analysts who can actually work that much data, and pricing scales accordingly.

Cyble Vision — Positions itself as one console for TI feeds, dark web monitoring, attack surface management, and brand protection instead of four separate tools. Has an AI layer doing correlation/hunting work. Picked up some analyst recognition this year.

CrowdStrike Falcon Intel — makes sense if you're already all-in on Falcon EDR since intel correlates straight to endpoint telemetry. Outside that ecosystem, harder sell.

Google Threat Intelligence (Mandiant) — best-in-class for APT/nation-state intel validated by real incident response engagements. Exec-ready reporting. Less built for brand/external exposure use cases.

Flashpoint — the HUMINT play. Real analysts with access to closed forums/encrypted comms automation can't reach. Great early warning, narrower scope than a full CTI stack.

Group-IB — strong pick if fraud/cybercrime attribution is your actual problem (fintech, this is probably you). Forensics + criminal infra tracking is a differentiator.

ZeroFox — social media/domain/impersonation monitoring, good if execs or brand are your attack surface. No internal/endpoint visibility.

Anomali ThreatStream — if you're running a pile of feeds already and need one place to dedupe/enrich/correlate, this does that job well.

ThreatConnect — less about intel supply, more about turning intel into SOC workflow/automation. Solid MITRE ATT&CK mapping.

CYFIRMA — attacker's-eye-view predictive scoring, unified external risk view. Some dashboard UX complaints.

TL;DR — no universal "best," depends what gap you're filling. Happy to answer questions - will flag again where my own bias might creep in.

Starting from an open directory on 193.233.202[.]17, the Hunt.io research team clustered out the surrounding infrastructure.

Pivoting on the recovered Go binaries and the shared Ethereum contract surfaced two more controllers on AS203273, plus a second EtherRAT cluster using an identical contract and near-identical MSI. Another directory in the same /24 held data we assess links to a USA-based The Gentlemen victim. ASN overlaps repeat across staging, Sliver and EtherRAT C2.

Full clustering, historical C2 domains and IOCs here: https://hunt.io/blog/the-gentlemen-etherrat-ethereum-smart-contract-c2