With all the chaos going on right now, I'm here to remind you that LLM-aided/agentic attacks are still just... intrusions. They may evolve at different rates, but they fundamentally boil down to the same observability and alerting requirements that a human intruder would for detection. In the middle of "vulnpocalypse", the strongest takeaway shouldn't be that LLMs are getting more advanced, it should be that organizations should be investing in basic security fundamentals and posture management to help detect and defeat these threats.

So... I named a malware campaign awhile ago. I just googled said name and lo and behold-- all NSFW. I'm not sure if this is an effective commentary on how sheltered I am, or if I should simply have my naming rights revoked.

I wish it wasn't so annoying to query social media platforms at scale-- would be really interesting to see what kind of overlaps/bots appear if you start digging into the millions of Xeets or Reddit posts or whatever side by side.

Do you want to elaborate on that or just leave it on old school ingenuity?

Update to the above: More than a singular run, still literally just exfiltrating Chrome History. 🥱 Whatever the operator is doing in this whole saga, they're seemingly not very keen on doing anything super malicious aside from being annoying.

Have you seen any credential theft whatsoever? I'd be very interested; I've reverse engineered this, analyzed well over 1000 executions in production environments at scale, and not once have I seen any behavior consistent with credential theft. I have, however, seen numerous AI RE runs call the browser reboot feature App-Bound Encryption bypass. Which... it is not. In the singular run we observed with an additional payload, a chrome history download was performed on the host; it didn't touch any credential files.

virustotal.com/gui/file/0c14… It has since been uploaded to VirusTotal if that helps in the meantime. :)

May be thinking of the CS Beacon though-- this case was from awhile ago.

I believe it had a valid license key; ElasticSearch's previous tooling had to be modified to facilitate handling of the newer format and was the basis for how we got at the beacon. github.com/elastic/labs-rele… Will follow up on Monday!

Yes; the vRx binary was unsigned. A pass with Shellter V12 on the binary had modified a single instruction to redirect flow to the Shellter packed portion and subsequently the Cobalt Strike beacon. C2 was at tlcnode[.]com.

Hey @M_haggis and Jose, Huntress dude here. Vicarus vRx wasn't the primary payload; the Vicarus binary carried a Shellter payload, which in turn contained a Cobalt Strike beacon.

I'm sad that we're closing our doors, but I'm happy that this project did what it was designed to do-- some good in the world while helping give a place for the next generation of developers and security professionals to gain hands on experience solving real world problems.

Most of our nerds aren't on Twitter-- or at least I don't know their handles. I paid out of my own pocket for hosting and infrastructure. Contributors were free to work on what they wanted, to help secure and prevent malware proliferation on PyPI. Many have gone on to pursue great things at massive enterprises.

Vipyr was a "Trusted Reporter" in PyPI, a status given to internal collaborators on package ecosystem security. Our reliability was our pride point-- we worked closely on internal API development for reporting systems, and we wielded that responsibility carefully. Vipyr was one of the few organizations capable of quarantining a public package by mere reporting. We demonstrated this in the Microsoft DurableTask compromise by TeamPCP.

Some stats for nerds: - We scanned 11.4 million packages across 583,356 projects. 11.2 million of the packages that entered the scanner completed-- a >98% success rate on package publish -> package scan. - From ingest to scan complete, our average scan response time was 46 seconds-- packages were known-bad within 60 seconds of upload. - Our best reporting year was 2024-- 989 malicious packages were reported; in March alone this amounted to 535 reports. - Our busiest day was 12,763 scans on November 29, 2024. - Dragonfly, Vipyr's internal framework, ran on a 2x1vCPU2GB k8s deployment for almost two consecutive years with zero unplanned outages. Overall the project ran between $125-$150 per month. - We ran a mirrored/redundant staging cluster and database, which was instrumental when a developer accidentally dropped our entire schema in production. - We maintained a 100% accuracy rate with PyPI across their observed window. That is-- we have never sent a false report on all accountable records. (This is untrue, I sent a bad report back in the inception of Vipyr, before we had databases available and I was authoring emails by hand.) - Our reporting predates our database records-- estimates place our malicious package corpus around 2000 reports-- we can accountably trace 1381 true positive reports in our database alone-- while the remainder are validated from e-mail records predating tracking on either our or PyPI's end.

Today, Vipyr Security-- a home grown open source security organization I started-- is closing its doors. We did some cool shit-- ended up in some publications by ESET, Unit42-- even knocked down the durabletask compromise on PyPI. But all good things must come to an end.

Super happy to work at a company like @HuntressLabs that allows and enables us to wreck adversaries in literally every way you can dream up. This time? Vuln research! Few things on this, to clear the air in a more casual tone, for those that stumble upon this: - We were responding to an actively-exploited v2026.3.1.10 instance. (Fully patched.) - While doing that investigation, we were digging into the "how" instead of the "who", "what", and "where"; as that telemetry no longer existed. - In the course of that investigation, we discovered a plausible series of vulnerabilities that could explain that behavior. To be abundantly clear-- we do not know what the adversary exploited in the v2026.3.1.10 instance. I don't want that to be what people walk away with-- we instead found a plausible explanation, and worked with the excellent security team at N-Able to help shore up their defenses. A lot of unknowns, a lot of questions, and I wish I had the answers.

Across the forehead if memory serves me right.

One of the weird quick wins here for agentic code generation is switching pipelines/architecture to very opinionated tooling and checks. I've found reasonable success using agents to generate (non-production) Rust codebases, and I blame that chiefly on how pedantic the ecosystem can be with regards to formatting, errors, complexity, etc. Because this all exists in CI/CD time, flowing code into live systems becomes a little more resilient when the agent has to jump through hurdles to get things to placate pedantic linters, static analysers, perf/mem analysis platforms, etc.