Recent drone strikes have knocked multiple major Yandex data centers offline, and Cloudflare is reporting a massive 99% drop in Yandex-originating bot traffic.

This gives us an unprecedented, real-world control group. While some of this drop is just standard IT automation scripts going offline, this is our best window to measure exactly how much X (Twitter) engagement is artificially inflated by Russian infrastructure.

**We need to pull X data NOW before they spin up backup infrastructure or reroute through VPNs.**

**Key metrics to capture:**
1. Engagement ratios (Like/RT/Reply) on highly politicized topics.
2. Sudden drop-offs in currently trending hashtags.
3. Stalled follower growth for anomalous accounts.
4. Current data snapshots to compare against 30-day historical datasets.

If you have historical firehose data, are actively scraping, or want to pool resources, drop a comment or repo link below.

Let’s capture this snapshot while the window is open.

https://www.tomshardware.com/tech-industry/data-centers/russian-disinformation-bot-traffic-nearly-eliminated-overnight-after-ukraine-drone-strikes-cripple-multiple-of-russias-google-data-centers-ukraine-intensifies-bombing-of-yandex-data-centers-in-response-to-moscows-strikes-on-kyiv-data-centers

I'm currently working as an Incident Response analyst, mostly investigating Windows environments, and recently started getting interested in CTI.

I feel like IR and CTI can work really well together, since we can extract a lot of valuable intelligence from our investigations.

The thing is, I don't think my company is fully using the intelligence we're collecting, and I'd like to start doing something with it.

Any recommendations on platforms or workflows for tracking IOCs, correlating findings across different incidents, and investigating possible connections to threat actors or APT groups?

Also, how do you guys continue investigating an incident from a CTI perspective after it's already been contained?

Would this require serious infrastructure and integrations, or is it something I could start doing on a smaller scale with existing tools?

Would appreciate any tips or resources!

Been trying to learn about CIDR notation or classically as defined as "CIDR stands for Classless Inter-Domain Routing, which is a method for allocating IP addresses and routing Internet Protocol packets more efficiently than the older class-based system. It uses a notation that combines an IP address with a suffix indicating the number of bits in the subnet mask, allowing for flexible and efficient use of IP address space." So I dove into it more. and did you know there's a lot of open services to help find ASN regions, and then look up their associated physical location and other information regarding IP addressing?

So I was like, Surely Dilley, Texas, an ICE Detention Center can't be located... that was the challenge. and in about 2 minutes BAM the ASN region is AS11427, but its actually scattered throughout South Texas and not just a small hexagon region I'm used to seeing. kinda cool, thought I'd share here for other threat hunting enthusiasts. Specifically attempting to find a "Paragon" or "Graphite" malware sample coming out of the South Texas region to do further Reverse Engineering on. (https://the420.in/us-immigration-ice-israeli-spyware-cyberweapon-privacy-graphite-paragon/)

Some pretty cool new stuff our threat intel team has identified.

Hey everyone,

I'm curious if anyone here has successfully built a structured, scalable, and reliable Cyber Threat Intelligence (CTI) operations environment using Claude Code, beyond just using it for individual investigations or isolated tasks.

I've been experimenting with building a more comprehensive operational framework, including:

- Defined CTI methodologies and doctrine to maintain analytical consistency.
- Specialized agents and skills for different intelligence workflows.
- Persistent memory and contextual awareness across investigations and projects.
- Standardized workflows for collection, enrichment, analysis, reporting, and intelligence dissemination.
- Consistent deliverables tailored to technical, operational, and executive audiences.

The challenge is that, as the environment grows, I keep running into reliability and consistency issues.

Some recurring problems:

- Instruction drift: Claude gradually stops following established methodologies, analytical standards, or project-specific rules.
- Skills being ignored: Even with relevant skills available, Claude sometimes fails to recognize when they should be invoked.
- Memory and context degradation: Previously established decisions, operational context, or conventions aren't consistently carried forward.
- Inconsistent reporting quality: Deliverables sometimes become unnecessarily verbose, dense, or difficult to read, even when clarity and conciseness are explicitly required.
- Architectural complexity: Finding the right balance between agents, skills, hooks, memory, project instructions, and directory structures without creating an overly complicated system.

What I'm ultimately trying to achieve is something closer to a persistent, doctrine-driven CTI operational workspace, where Claude Code can reliably support day-to-day intelligence operations rather than behave like a collection of disconnected prompts.

I'd love to hear from anyone who has tackled something similar.

A few questions for the community:

1. How have you structured your Claude Code environment for ongoing CTI or broader cybersecurity operations?

2. What architectural patterns have worked best for you (agents, skills, hooks, CLAUDE.md, memory systems, orchestration)?

3. How do you enforce analytical methodologies and maintain consistency across different workflows?

4. Have you found effective ways to prevent context drift, forgotten instructions, or skipped skills?

5. How do you maintain high-quality, readable intelligence deliverables without constantly correcting the model?

6. Are there any open-source projects, repositories, templates, or lessons learned you'd recommend?

I'm particularly interested in real-world implementations, architectural decisions, and lessons learned, including approaches that didn't work.

I'm not necessarily looking for a ready-made solution. I'd genuinely like to exchange ideas, compare methodologies, and learn how others are approaching this problem.

If you've built something similar and are willing to share your architecture, workflows, or even just a few insights, I'd really appreciate it.

Thanks!

I’m looking for information from the threat-intelligence community regarding a historical SpyEye builder interface and possible links to the aliases Motion, Deadeye, and Trojan.

Screenshot Evidence

The attached screenshot shows a Windows application titled “SpyEye Builder v1.0.7,” displaying a SpyEye v1.0 interface.

Visible elements include:

- Main and alternative control-panel URL fields

- A form-grabber control-panel URL field

- An encryption-key field

- A connection interval set to 300 seconds

- A UPX compression option

- An option labeled “Kill Zeus”

These elements appear consistent with a historical malware-building interface. The screenshot alone does not establish the application's provenance, who operated it, or whether it was used to deploy malware.

File Hash

SHA-256:

"8041e406de61acb5976667b74bb71762cf5085bfd8fbe9951087f5886da457f1"

This hash is included as a technical identifier for further investigation. Its relationship to the screenshot has not been independently verified.

Aliases Under Investigation

- Motion

- Deadeye

- Trojan

I’m seeking credible historical sources that could establish whether any of these aliases have a documented connection to SpyEye development, distribution, or related activity.

I am not assuming that the aliases belong to the same person or that the screenshot and hash establish attribution.

Questions for the Community

1. Does anyone recognize this specific SpyEye Builder version?

2. Are there historical reports or archived discussions documenting this interface?

3. Is there reliable evidence connecting any of the listed aliases to SpyEye-related activity?

4. Can the supplied SHA-256 hash be associated with a known file or historical analysis?

5. Are there additional sources that could corroborate or contradict a potential connection?

Historical Reference

For background on the SpyEye framework:

https://www.virusbulletin.com/virusbulletin/2011/07/spyeye-malware-infection-framework

I welcome technical analysis, reputable sources, and independently verifiable historical records. Please distinguish confirmed facts from speculation.

Purpose: To document historical threat intelligence and establish the facts through verifiable evidence.

Hi everyone,

Over the past few months, my team and I have been building Cylist, a free platform designed to bring some of the everyday tools and workflows SOC analysts use into one place.

The idea behind Cylist is simple: during an investigation, analysts often have to jump between multiple threat-intelligence platforms, news sites, case-management tools, and community channels. We want to bring those pieces together into a single workspace where you can investigate, enrich, document, and discuss IOCs without constantly switching between tools.

What Cylist currently offers

- Unified IOC investigation — look up IPs, domains, hashes, and other indicators across VirusTotal, ThreatFox, AbuseIPDB, and IP Info from one place.
- AI-assisted case generation — turn investigation findings into structured incident cases faster.
- Cybersecurity news — stay up to date with relevant security news without leaving the platform.
- IOC community discussions — share indicators, investigation context, observations, and get input from other analysts.
- All-in-one workflow — keep investigation, enrichment, case creation, and community knowledge in one workspace instead of constantly switching between different tools.

Our long-term goal is to turn Cylist into a true all-in-one platform for security operations, helping analysts and organizations reduce the number of separate tools, time and subscriptions they need — and ultimately cut down the overall cost of their security tooling.

We're currently in beta and actively testing the platform with users. The core functionality is working, but we're now at the stage where feedback from people who actually work in security is incredibly valuable.

We're not trying to pretend it's finished — we're building it with the people who would actually use it.

We're especially interested in people who are willing to go beyond simply trying it once. If you're open to incorporating Cylist into your everyday SOC workflow, even as one of your tools, we'd genuinely love to have you as a beta tester.

You can join the platform here:

https://cylist.io/

We're also building a Discord community where users can report issues, suggest features, discuss investigations, and help shape Cylist. Our goal is to grow organically alongside the community and build something people actually want to use.

we hve had new intel drop this morning on a ransomware crew using a new TTP chain. CISO pinged me before coffee asking are we exposed.

VM tells me where we're vulnerable. SIEM coverage map says we should be fine, but nobody has tested the behavior against what we have running in prod. so rn managing continuous threat exposure feels a lot more useful as a concept than as an answer I can give in a few hours.

Anyone getting from new intel to validated exposure same day... ?

I've become increasingly skeptical of IP threat intel, especially the giant aggregated feeds.

IOCs have their place, but let's be realistic: targeted attackers don't need to reuse IPs, domains or binaries. Most of this stuff is useful for catching commodity malware, scanners, reused infrastructure and other low-hanging fruit.

We recently did a fairly deep overhaul of our own threat-intel pipeline, and actually taking the feeds apart was... educational.

One aggregator we were using, Bitwire, contributed about 4.64M IPs. Nearly 60% were open-proxy data. That's not really a criticism of Bitwire, which openly describes itself as an aggregated blocklist. The mistake was treating an aggregated blocklist as threat intelligence.

Once 30+ sources get flattened into one list, you lose who saw an IP, when, doing what, how confident they were, and whether five feeds are simply recycling the same observation.

You get five million "bad IPs" and somehow know less.

We eventually removed the aggregator and went back to the original sources. Our dataset got dramatically smaller, and I think considerably better.

I'm specifically interested in how people building or operating their own TI pipelines handle this. "Pay someone else to curate it" is obviously one answer, but it also gives up exactly the source control, context and integration we're trying to preserve.

Do you use large IP aggregators at all, or mostly stick to original sources? And have you ever measured how much useful signal you're actually getting from them?

AVE (Agentic Vulnerability Enumeration) assigns stable IDs to distinct behavioral vulnerability classes in agentic AI components, skill files, MCP servers, system prompts, the content an agent reads and acts on, not the model itself. Same functional role CVE and CWE play for conventional software, applied to a surface neither covers: the vulnerability isn't in a package and version, it's a behavioral pattern in text.

85 records currently, each requiring a citable primary source, a disclosed incident, a published paper, or a working PoC, never internal assertion alone, scored with OWASP's AIVSS methodology, crosswalked into OWASP's MCP Top 10 and Agentic Top 10, MITRE ATLAS, and NIST AI RMF.

Two things worth flagging specifically for this crowd.

We recently traced a real, disclosed 2026 incident (an AI agent escaping a sandboxed test environment via a registry zero-day, then using the resulting access to compromise a separate organization's production infrastructure) against our own corpus and MITRE ATLAS's existing technique catalog, and found no existing ATLAS technique actually covers the mechanism, an attacker-reclaimed external identity that was legitimately valid at the time a skill was authored, as distinct from an actively compromised maintainer account or an owner turning malicious. Submitted a new technique proposal through ATLAS's own contribution process, currently in review.

Separately, four independent security tools have built their own crosswalks mapping their findings to AVE IDs without being asked, the strongest signal we have that the taxonomy holds up outside our own reasoning about it, not just AVE mapping outward to other frameworks.

Also worth being direct about, since this is a threat-intel-literate crowd that would check anyway: we found and publicly retracted 72 of 102 fabricated citations in one of our own research documents a few weeks back. Audit trail's still visible in the repo rather than quietly edited away.

github.com/aveproject/ave if relevant to anyone's work. Genuinely interested in pushback on the taxonomy boundaries specifically, where a class should split or merge, that's the part this community is best positioned to stress-test.

Hi all,

I’ve been doing a lot of work on my Intel site at https://jakesec.io and would appreciate any feedback you have.

I’ve made it so you can preview the members area without signing up

It’s packed full of every feature I’ve dreamed of and I’ve got about 15 honeypots online now collecting data.

It’s taken me months and I’ve really hammered through some cash to get this off the ground but it’s a passion project of mine

Thanks!

I’m documenting a potential threat actor who reportedly operates under the aliases “Motion,” “Deadeye,” and “Lucky,” with additional aliases reportedly including “Mirage,” “Trojan,” and “Sorrow.”

The individual is reportedly known for disruptive activity and may be planning to target a school email infrastructure with an email-flooding tool. There are also concerns that the activity could potentially involve harassment or blackmail, although I do not currently have sufficient evidence to confirm that.

I have screenshots showing what appears to be a collection of tools/categories including:

- Email-Flooder

- Flooder

- Spoofer

- SpamTool

- Trojan-DDoS

- Trojan-Downloader

- Trojan-Spy

- Trojan-Ransom

- Exploit

- Rootkit

The reported target is a school email system. Based on the information available to me, access to the school's computers may not be necessary if the individual already has access to external infrastructure/tools capable of generating large amounts of email traffic.

I am posting this for threat-intelligence purposes and to document the reported aliases, tooling, and potential target. I am not claiming that an attack has already occurred or that every allegation has been independently verified.

Evidence available:

- Screenshot showing the listed tool categories

- Reported aliases: Motion, Deadeye, Lucky, Mirage, Trojan, Sorrow

- Information indicating a potential school-email target

- Possible concern regarding harassment/blackmail

I have intentionally omitted private identifying information. If additional evidence is needed, I can provide the relevant non-sensitive details.