r/threatintel

Turns out: very visible. Yesterday's scan found 185 out of 185 engagers on a single repo were bots. Not 90%. Not "mostly suspicious". Every single one. The repo had zero legitimate stars.

What I built

phantomstars is a Python tool that runs daily via GitHub Actions (free, no servers):

1. Scrapes GitHub Trending and searches for repos created in the last 7 days with sudden star spikes
2. Pulls star and fork events from the last 24 hours per repo
3. Bulk-fetches every engager's profile via the GraphQL API (account creation date, follower counts, repo history)
4. Scores each account on a weighted model: account age (35%), profile completeness (30%), repo patterns (25%), activity history (10%)
5. Detects coordinated campaigns using timestamp clustering and union-find: groups of 4+ suspicious accounts that engaged within a 3-hour window
6. Files an issue directly on the targeted repo so the maintainer knows what's happening

Campaign IDs are deterministic SHA-256 fingerprints of the sorted member set, so the same group of bots gets the same ID across runs. You can track a farm across multiple days even as individual accounts get suspended.

What the pattern actually looks like

It's remarkably consistent. A fake engagement campaign in the raw data:

• 40-200 accounts, all created within the same 1-2 week window
• Zero original repositories, or only forks they never touched
• No bio, no location, no followers, no following
• All of them starring the same repo within a 90-minute window
• The target repo usually has a name implying it's a tool, hack, executor, or generator

Today's scan: 53 active campaigns across 3,560 accounts profiled. 798 classified as likely_fake. The repos being targeted are mostly low-quality AI tools and "executor" software that needs manufactured credibility fast.

Notifying the affected repo

When a repo hits a 40%+ fake engagement ratio or a campaign is detected, phantomstars opens an issue on that repo with the full suspect table: account logins, creation dates, composite scores, campaign membership. The maintainer sees it in their own issue tracker without having to find this project first.

Worth noting: a lot of these repos have issues disabled, which is a red flag on its own. Those get skipped silently.

Why I built this

Stars are how developers decide what to evaluate, what to depend on, what to recommend. When that signal is bought, it affects real decisions downstream. This started as curiosity about how measurable the problem was. The answer was more measurable than I expected.

It's part of broader research into AI slop distribution at JS Labs: https://labs.jamessawyer.co.uk/ai-slop-intelligence-dashboards/

The fake engagement problem and the AI content quality problem are really the same problem. Fake stars are the distribution layer that gets garbage in front of real users.

All open source. The data is append-only JSONL committed back to the repo after every run, queryable with jq.

Repo: https://github.com/tg12/phantomstars

Findings are probabilistic, false positives exist, the README explains the full scoring model. If your account shows up and you're a real person, there's a false positive process.

Questions welcome on the detection approach, GraphQL batching, or campaign ID stability.

Wrote up an active case from this week, sharing in case it helps anyone seeing similar voicemail lures.

One of our customers got hit with a quishing email branded as Spectrum Business + RingCentral + Google Voice. The bait is the usual missed-call story, "you have a voicemail about an overdue payment." Nothing remarkable so far.

The clever part is the chain. The malicious link isn't in the email body. It's in a QR code, inside a .docx attachment, inside the email. Three layers deep before anything fires.

Whole thing is designed to push the click off the corporate laptop and onto the user's phone, which is the entire point of quishing as a technique:

Once the user scans, they get a fake "Tap the box to confirm" captcha (kit-style, blocks perimeter sandboxes from following through), then a near-perfect Microsoft login page pre-filled with the victim's email pulled from the URL path. Behind it is an AiTM proxy grabbing the password and the session cookie in real time.

Phishing Email

Attached Docx

Auth Impersonation

Full writeup with the IOCs, the captcha + AiTM screenshots, the docx internals, and some detection ideas is up on the company blog. Not posting the link inline to keep the post technical-first. I'll drop it as a comment for anyone who wants it.

Disclosure: I work at ZeroBEC

so for ref: we are re evaluating our threat intel and dark web monitoring stack and are down to the three options I mentioned above. But I feel like I am getting a whole lot of sales fluff or bs from the intel im finding from each.

So I was hoping for a bit of feedback from here.

If anyone has/is actually deploying any of these, and had the choice to change again today, which would you pick today .

considering dark web depth, DRP strength, ease of integration. No need for Short stories like “we chose X over Y and here is what we learned” or sales guys jumping in. just the straight up would be awesome. thanks in advance.

Sharing a quick heads-up from an active IR case in case it helps anyone else triaging similar emails this week.

A customer received a phishing email that looked like a generic Adobe / DocSend "New Secured Document" lure. Standard stuff on the surface, but the interesting parts:

• Sender: noreply-<random string>@jobote.com ("Adobe-Docsend" as display name)
• "View Document" button links to mailtracking.jobote[.]com/f/a/{token} - which is Jobote's own legitimate tracking/redirect subdomain for their referral product, being abused as a clean-reputation redirector
• Final payload is a ConnectWise ScreenConnect installer - attacker uses it for hands-on-keyboard access after install
• Reply-To is literally noreply at yourdomain[.]com - an unfilled template placeholder, which is a strong pivot IOC for hunting other emails from the same kit/operator

Phishing Email

ScreenConnect Download Redirection

​Not making any claim about how the jobote[.]com SparkPost tenant got abused (compromised account, stolen API key, abused customer subaccount, etc.) - that's for SparkPost to investigate. But the abuse pattern matches what we've been seeing more broadly: attackers riding low-reputation but legitimate ESP/tracking infrastructure to bypass URL reputation filtering before dropping a remote-access tool.

Pivots worth hunting on:

• Reply-To containing yourdomain[.]com (placeholder strings in Reply-To = high signal)
• X-MSFBL header containing customer_id=107475
• Any mailtracking.jobote[.]com URLs in inbound mail
• Apple Mail headers on ESP-injected mail (deliberate misdirection or sloppy operator)
• Reported to SparkPost abuse and notifying Jobote directly so they can rotate keys / audit.
• Firewall logs for access to cherylbirch[.]com

Disclosure: I work at ZeroBEC. Happy to drop the full writeup in a comment if anyone wants the headers / IOCs to feed into their own tooling.

Hey guys.. I’m planning to make a move.. I wouldn’t call it a career shift but its quite the move; anyway

I have been doing MSSP for 3 years for now
Working as SOC Analyst, Detection Engineering and DFIR.. and now back to the SOC as L2.. Ik quite the downgrade for reasons that are out of my control.. anyway

I know these positions might seems so random but I have to say some of them I had to do because of the pay.. as for my passion it always will be DFIR & CTI, which brings me to the main reason for this post; I kinda wants to move to CTI completely
I have always been interested and mesmerized by how CTI work and how these actionable intel helps, I always read about reports tracking APTs groups and make use of mistakes to attribute.. amazing!! And I kinda already doing such stuff (small) like this but I want to get better specifically the tracking & hunting (real CTI) but I honestly don’t know how I can improve such skills and I really need your advice and guidance, thanks

Real-world situation.

https://preview.redd.it/uanj9t7zki1h1.png?width=1070&format=png&auto=webp&s=a157959cb596f4ffb69d185c0d459970b680f121

Head over to Netomize's blog to learn about how we detect the exploitation of the CrushFTP Vulnerability (CVE-2025-31161) with PacketSmith's Yara detection module, using the newly introduced track_state and flow_state keywords to the correlation engine.

npm supply chain attacks are no longer “theoretical”.

TanStack. Axios. Trivy. Bitwarden. SAP. Intercom.

Attackers are abusing:

• GitHub Actions
• OIDC tokens
• npm lifecycle hooks
• trusted CI/CD pipelines

We built an AI-assisted hunting pipeline to detect the behavioral kill chain behind these attacks instead of chasing IOC crumbs.

Real queries. Real telemetry pitfalls. Real lessons learned.

We've been running a graph of public internet infrastructure as a research tool for the last ~3 years. 46B data points and 39B edges spanning DNS resolution, BGP routing, WHOIS registration, hosting, and GeoIP, plus 39 threat-intel feeds wired in. Today we opened it as an MCP server so analysts can query it from Claude, Cursor, or any MCP-compatible client.

What it does: ask infrastructure questions in plain English (or Cypher) and get traversal-grade answers in one round trip. Pivot from a suspicious hostname to its IPs, ASN, prefix, co-tenants, and registration history in a single agent turn. Audit per-edge evidence behind any threat score. Track BGP route changes within 5 seconds of them happening.

30-day free trial, no credit card, no query limits during the trial, full graph access. The trial is meant to be real working time, not a teaser.

The pivot I use most often: from a suspicious hostname to every other hostname that has ever shared an IP with it. In a traditional REST stack that's resolve, pull passive DNS, fan out, dedupe, score. Five calls minimum, agent context window gets shredded by call three. In Cypher it's one round trip:

MATCH (start:HOSTNAME {name: "your-target.com"})-[:RESOLVES_TO]->(ip:IPV4)
MATCH (sibling:HOSTNAME)-[:RESOLVES_TO]->(ip)
WHERE sibling <> start
RETURN sibling.name, ip.name
LIMIT 25

Tested live against six domains: 140ms to 275 ms across the full graph.

Two caveats worth naming before you try it:

1. The pivot returns infrastructure-shared hostnames, not behavioural-similarity ones. A CDN edge IP (CloudFront, Fastly) returns hundreds of co-tenants that aren't related. Filter on ASN, prefix age, or threat-feed presence to extract signal from noise.

2. Targets that own their infrastructure (large enterprises with their own ASN) return zero co-tenants. Absence is itself a signal; the graph makes it legible. We just ran news.ycombinator.com against the same pattern and it returned one IP on M5HOSTING (AS21581). Boutique-hoster signature.

Other patterns that have been useful:

- whisper.explain(identifier) returns the per-edge evidence chain behind any threat score: which feed, which signal, which timestamp. Not a composite ML number. Lets you audit the score before pivoting on it.

- BGP feed aggregated from ~1200 peers (RIPE RIS, RouteViews, plus our own sessions). Route changes propagate into the graph in under 5 seconds. Useful for tracking infrastructure rotation during an investigation in real time, not the next-morning snapshot.

- The MCP wrapper means agents can chain pivots: this domain to its IPs to ASN reputation to other prefixes from that ASN to fresh registrations on those prefixes runs in a single agent turn instead of dozens of API calls.

Background, since this sub fairly asks. I'm Kaveh Ranjbar, ex-ICANN Board, ran K-root, 15 years at RIPE NCC. My co-founder Soroush and I built this because we got tired of stitching DNS to BGP to WHOIS to GeoIP across multiple sources during real investigations.

Known limits worth knowing:

- Multi-hop queries land in 150ms to 400ms, not microsecond. Single-anchor lookups are much faster.

- WHOIS coverage is partial in some ccTLDs.

- Threat scoring exposes per-edge evidence; no composite black-box score.

Install instructions and the two-minute MCP setup are in the first comment below.

Curious what infrastructure-pivot patterns folks here use that aren't well-served by existing tools. We're building Cypher templates from real analyst workflows, so weird or specific pivots are the most useful feedback.

Trying to sanity-check the below.

Say an org has an old subdomain with a CNAME pointing to a cloud resource that no longer exists. Pretty standard dangling DNS issue.

Attacker claims the abandoned cloud alias, gets a valid cert for the real subdomain, and hosts a tiny remote resource there.

Now a targeted employee opens an email that loads that resource from the hijacked subdomain. If cookies are scoped broadly to the parent domain, the browser/mail client may send session cookies automatically to the attacker-controlled subdomain.

So the path is basically:

dangling CNAME → claimed cloud alias → valid cert on real subdomain → remote resource loads → parent-domain cookies leak → possible access to internal apps like HR, finance, CRM, support/admin consoles

My question: would you treat this as a critical pre-attack exposure, or just attack-surface hygiene until there is evidence of abuse?

Also curious who usually owns this in your org.