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.

Öncelikle bu konunun bir reklam olmadığını, sadece liseli gençler olarak düzenlediğimiz bu etkinliğin daha fazla kişiye duyurulması amacıyla paylaşıldığını belirtmek isterim.

Kısaca: Biz 4 kişi HASBL CTF adında Jeopardy formatında olacak bir CTF düzenliyoruz, katılım linki en aşağıda mevcuttur.

Peki CTF nedir? CTF yani; Capture The Flag (Bayrağı Yakala), siber güvenlik alanında farklı kategorilerdeki becerilerimizi test etmek ve geliştirmek amacı güden bir yarışma formatıdır. Amacımız kategoriye göre verilen sorudaki açığı bularak cevaba (flag'e) erişmektir:

Kendimizden bahsetmem gerekirse biz sosyal bilimler lisesinde 11. sınıf öğrencisi olan 4 kişiyiz ve birçok CTF'e katıldıktan sonra; "Neden soru yazmayı da denemiyoruz?" dedik ve kendi CTF yarışmamızı yapmak istedik. Elimizden gelenin en iyisini yaparak bir şeyler yaptık işte...

Etkinlik detaylarına geçmek gerekirse:

Kategoriler:​

• Web: Açtığınız Instance'da zafiyet bulup flag'e ulaşmak.
• OSINT (Açık Kaynaklı Bilgi/İstihbarat): Soruda verilen foto/video, sosyal medya hesap adı vb. ortamlarda kanıt inceleme ve analiz ederek flag'e ulaşmak.
• Cryptography (Kriptografi): Şifre kırma diyebiliriz basitçe. Kod ve/veya verinin mantığını çözerek şifrelenmiş flag'i okunabilir hale getirerek flag'e ulaşmak.
• Reverse/Reverse Engineering (Tersine Mühendislik): Derlenmiş bir yazılımı yada makine kodunun bazı programları kullanarak nasıl çalıştığını çözüp okunabilir hale getirme ve flag'e ulaşmak.
• Pwn (Zaafiyet/Sömürü): Hedef olarak verilen sistemin güvenlik açıklarını bularak sisteme sızıp yetki yükseltme ve flag'e ulaşmak.
• Forensic (Adli Bilişim): Dijital kanıtların (log, disk görüntüsü, wireshark vb.) inceleyerek flag'e ulaşmak.

Kategorilerin tanımını yaparken ben bile kötü bir şey yapıyormuş hissiyatına kapıldım ama emin olun öyle bir şey yapmıyoruz kesinlikle 

Tarih:​

• 29 - 30 - 31 Mayıs tarihlerinde 48 saat sürecek.

Platform:​

• CTFd altyapısı üzerinden kendi sunucularımızda (Google Cloud) gerçekleşecek.
• CTF Time üzerinden de yarışma duyurusu yaptık ama kabul bekliyoruz, CTF'lerde önemli olduğu için kabul aldığında eklerim buraya.

Kurallar: Kurallar sitemizde yer almakta ama kısaca önemli birkaç kurala değineyim.​

• Takımlar en az 1, en fazla 4 kişilik olabilir.
• Flag paylaşımı yapmak yasak.
• Yarışma boyunca write-up yayınlamak yasak.
• Yarışma sürecinde yarışmacıların birbirine saygılı olması ve sportmen olması önem arz etmekte.

Kayıt ve Daha fazla bilgi için:​

• Kayıt ve daha fazla bilgi için sitemizi bağlantı kımından ziyaret edebilirsiniz.
• Yarışma sürecince kayıtlar açık olacak ve belirli bir şart olmaksızın isteyen herkes katılabilecek.
• Ödüller daha belli değil (TBA) maalesef..
• Lise düzeyinde kısıtlı süre ve bütçede hazırladığımız bu etkinlikte hata olacaktır ama bunları düzeltmeye ve kendimizi geliştirmeye özen gösteriyoruz.
• Sitede ve yarışma genelinde bir öneriniz, sorunuz olursa; bunları duymakta, cevaplamakta ve geliştirmekten memnuniyet duyarız.

Şimdiden ilgi gösteren herkese ve CuteTopia Sub'ına bu konuyu açamama izin verdiği için teşekkür ederim.

OtterCookie is not “BeaverTail but again.”

That is the part I think matters.

BeaverTail mostly grabbed saved stuff from a developer machine.

OtterCookie keeps watching the machine after that: Socket.IO / Engine.IO, live victim rosters, clipboard, keystrokes, screenshots, browser data, wallet artifacts, dev secrets.

Less “dump the box once.” More “sit on the box while the dev keeps working.”

The annoying detection problem:

developer workstations are already garbage fires.

Node tooling, random high ports, local services, package installs, Vercel/npm traffic, Socket.IO noise. A lot of this looks dumb but normal.

So where is the line?

What would make you look at outbound Socket.IO / Engine.IO from a dev workstation and say: yeah, this is not normal Node nonsense anymore?

No creds / victim names / live paths / exploit steps in the write-up.

Hi everyone, I'm reviewing a "Critical - Ransomware" alert ("VSS Shadow Copies Deletion Attempt detected") and I have a question about the timestamps and mitigation logic.

Here is the timeline from the report:

• 06:28:24 - vssadmin.exe executes delete shadows /for=C: /oldest
• 06:30:28 - diskshadow.exe is executed (presumably a fallback)
• 06:31:06 - SentinelOne executes "Kill" (11/11 processes) and "Quarantine". Mitigation status is "Success / Mitigated".

The dilemma: There is a 3-minute gap between the first execution and the final Kill action.

Does the SentinelOne agent intercept and block the deletion command at the kernel level in real-time (06:28), or is there a risk the shadow copies were actually purged before the Kill at 06:31?

SentinelOne, in the alert, consistently uses the word "attempted", which implies the deletion failed... but is Sentinel just being optimistic, or can I trust that "attempted" means the backups are 100% safe despite the delayed Kill?

Most detection rules focus on obvious indicators, such as hashes or C2 domains. Advanced actors like APT29 do not play that game.

NOTE: Keep your feedback focused strictly on the detection rule and the telemetry. I am sharing this research to contribute to the community, not to compete with anyone. If you are just going to derail the thread with off topic arguments, I do not need your feedback.

WHAT I FOUND:

Adversaries are running unsigned executables from C:\Windows\Temp\ and loading Python compiled modules ((dot)pyd files) from AppData\Local\Temp. In isolation this looks like normal software installation. In context it is adversary staging.

THE DETECTION LOGIC:

I built my alerts based on the exact path and signature correlations from my lab notes. The alert triggers on these specific combinations:

• Temp: An image executing from Temp or Image loading module or DLL from Temp.
• ProgramData: A process in ProgramData loading image or image loading from ProgramData.
• Legit + Unsigned: A signed legitimate process loading an unsigned .exe or .pyd module.
• Temp + Legit: Execution from Temp loading legitimate signed System32 DLLs.

WHY EVENTID 7 MATTERS: Process Creation (EventID 1) tells you WHAT ran. Image Load (EventID 7) tells you WHAT IT IS LOADING.

Example from the telemetry: Image: C:\Windows\Temp\python(dot)exe ImageLoaded: C:\Users\pbeesly\AppData\Local\Temp_MEI29522_ctypes(dot)pyd Signed: false

APT29 staged python.exe and loaded modules BEFORE executing the final payload. Most rules miss this because they only watch process creation.

TOOLS WORTH MONITORING (even if legitimate):

• PsExec64(dot)exe for remote execution
• sdelete64(dot)exe for anti forensics
• PSEXESVC(dot)exe for lateral movement

FALSE POSITIVES: Software installers, portable apps, and Python development environments will trigger this. That is standard tuning for your specific environment.

SIGMA RULE:-

title: Suspicious Executable Activity from Temp Directories
id: 42461076-ab43-408d-bc8d-97016a04e2cf
description: Detects unsigned executables in Temp loading modules or DLLs, common in APT29 and malware staging
status: experimental
date: 2026/05/11
author: Manish Rawat
references:
   - https://attack.mitre.org/techniques/T1574
   - https://github.com/OTRF/Security-Datasets

logsource:
 product: windows
 category: Image loaded
detection:
 selection:
   EventID: 
     - 7
   Image|contains:
     - \\ProgramData\\
     - \\Temp\\
     - \\temp\\
 selection_ImageLoaded_location:
     ImageLoaded|contains:
       - \\Temp\\
       - \\temp\\
       - \\ProgramData\\
 selection_ImageLoaded_exe:
     ImageLoaded|endswith:
       - .exe
       - .pyd
 selection_signaturestatus:
     SignatureStatus: 
        - 'Unsigned'
        - 'Unavailable'
        - 'Invalid'
 selection_Signed:
     Signed: 
       - 'false'
       - '-'
 condition: 
       (selection or selection_ImageLoaded_location) 
       or (selection_ImageLoaded_exe and (selection_ImageLoaded_location or selection )) 
       or (selection_signaturestatus and (selection or selection_ImageLoaded_exe or selection_ImageLoaded_location)) 
       or (selection_Signed and (selection or selection_ImageLoaded_exe or selection_ImageLoaded_location)) 

falsepositives:
 - Software installers using temporary directories
 - Legitimate portable applications
 - Python development environments 
severity: medium
tags:
 - attack.t1059.006
 - attack.t1574

This is the raw lab logic. I am still tuning it for production.

Note: Detecting only double \\Temp\\ logic is making this detection weak (only 24 events triggered), but with individual \\Temp\\ detection, it is getting much more results (300+ events triggered). I know individual \\Temp\\ detection can lead to false positives, but we can narrow it down based on a 90 days or 30 days baseline.

SPL:

(EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*")) OR ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*") OR (ImageLoaded IN ("\*.exe", "\*.pyd") ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*") OR (EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*"))) OR (SignatureStatus IN ("Unsigned", "Unavailable", "Invalid") (EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*")) OR ImageLoaded IN ("\*.exe", "\*.pyd") OR ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*")) OR (Signed IN ("false", "-") (EventID=7 Image IN ("\*\\\\ProgramData\\\\\*", "\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*")) OR ImageLoaded IN ("\*.exe", "\*.pyd") OR ImageLoaded IN ("\*\\\\Temp\\\\\*", "\*\\\\temp\\\\\*", "\*\\\\ProgramData\\\\\*"))  

If you've some suggestion or feedback, please feel free to DM. Detection insights are valuable to me. If you hate this post, then do what you want to do.

A Brazilian company (wascript.com.br) runs one platform that 126 different Chrome extensions all share. They look like separate products, WaSeller, waTidy, FR VENDAS PRO, ENOCRM, Cliente Flow, and dozens more, but it's one codebase, one backend, one set of hidden behaviors.

WaSeller alone has 100K users.

I found this network using my own tool for detecting malicious browser extensions, which flagged the cluster by shared code and infrastructure across all 126 listings.

None of the listings tell you that:

• When you log into WhatsApp Web, the extension sends your name, email, device ID, and your Facebook/Google/TikTok tracking cookies to a server run by whoever sold you the extension.
• Every voice message you send goes through their servers before it reaches the person you're sending it to.
• The extension downloads and runs JavaScript from a different Brazilian company's server. Google never checks this code.
• The 100K-user version has a live Google Tag Manager tag built in. The operator can push any new code to every user from a dashboard with no Chrome Web Store update.
• A bridge inside WhatsApp Web gives the extension full access to your contacts, your messages, and the ability to send messages as you.

No privacy policy on any listing. The manifest only asks for tabs, storage, alarms.

Full list of all 126 extension IDs (check if you have one), tech details, and IOCs: MalExt Sentry - Malicious Browser Extension Tracker