DEW #158 - Perplexity open sources their Bumblebee tool, Project Glasswing Update & A history lesson in residential proxies
also im hiring so come apply!
Welcome to Issue #158 of Detection Engineering Weekly!
✍️ Musings from the life of Zack:
Over the weekend, I was clearing out some brush in the woods behind my house since we want to create a play area for the kids. Once we get the deadwood and sticks away, we want to clear some plants as well. I pulled out my phone and scanned the plants to identify them, just in case it was poison ivy, and lo and behold, we have blueberry bushes everywhere! And I mean everywhere, I’ve asked my neighbors to come dig some up if they want some for their yards.
I’ll be in NY next week for work, and will be attending Sprawl on Thursday. If any readers are attending, let me know!
Lastly, my org at Datadog just opened up two engineering manager positions for our detection engineering team. We are expanding our detection engineering here at Datadog and would love to have some folks come in and help shape it in the age of AI. U.S. based applicants at this time :).
💎 Detection Engineering Gem 💎
Perplexity Is Open-Sourcing Bumblebee by Perplexity
Perplexity, a major AI company in the AI search space, released a Go-based secret scanner dubbed Bumblebee. Bumblebee is a secrets scanner, but it has a much more focused approach to targeting open-source software and 3rd-party vendor supply chain attacks. Every week, I read and likely link threat landscape stories involving an open-source supply chain attack. Perplexity deployed this tool in a clever framework to quickly orient to emerging attacks and check their exposure on developer laptops:
I’m sure Perplexity uses its own product to create its “threat intelligence feeds” listed at the top left, then passes them to its Perplexity Computer Agent. The agent collects as much context as possible around the attack and drafts a pull request to their exposure catalog, which is essentially a database of known malicious packages derived from their feeds.
The updated catalog kicks off a separate workflow to scan Perplexity’s fleet of laptops for emerging threats, while continuous scans are run on known-compromised packages from previous campaigns. The “worst case” scenario is finding successful compromises of devices, but the beautiful thing about this is the reliability of the build-and-scan pipeline, scouring for new campaigns. The package inventory and audit logs are excellent for false-negative analysis, especially in scenarios where a more subtle campaign that doesn’t perform smash-and-grab attacks can help responders with threat hunting.
I’ll say this again, as a word to all my readers who work in detection & response: please upskill in software supply chain security! We need to understand how these campaigns operate so we can hook into CI/CD pipelines to generate detections and audit logs for hunting.
🔬 State of the Art
Built a SOC from scratch with no prior SOC experience (Reddit Post) by After_Marsupial_3531
I am seeing more and more discussions on Reddit about security operations programs, and this one specifically impressed me because the author rolled out a full SIEM stack as an apprentice at an MSSP. They essentially have three people in their team: themselves, a CISO, and a salesperson. What they managed to do with zero experience and launching an MSSP service is nothing short of a miracle:
I have zero experience in a mature SOC — and neither does anyone else on the team. I’m figuring things out as I go, and I’m not always sure whether what I’m doing is actually sound or consistent with industry standards.
When I hear about stories like this, I immediately jump to the worst-case scenario. No experience in a SOC, fresh out of an apprenticeship and architecting a competitive managed service seems like a recipe for disaster. But they managed to launch it with real customers, primarily looking at EDR & M365 telemetry. Elastic Security was their stack of choice, probably due to its simplicity of out-of-the-box rules and its being an open architecture.
The resulting discussion is great, as they were looking for feedback on their deployment. There is definitely some memeing in the comments, with good nuggets and insights for the author, such as finding a way to create a crown jewels or critical assets list and prioritizing high-risk scenarios a small business would face.
Project Glasswing: An initial update by Anthropic
I don’t know what it is about this year’s developing AI & security space, but 1 month feels like 6 months in terms of technology acceleration. Anthropic just gave their 1-month update for Project Glasswing, and the results are impressive. They released Mythos to a limited set of company partners they deemed to be Internet-essential software companies, and also ran it on 1,000+ open-source projects. The results speak for themselves, but there are some nuances:
A lot of work goes into verifying vulnerabilities, both their presence and their reproducibility. Anthropic spent a lot of human energy, rightly so, to make sure that these vulnerabilities wouldn’t waste a human’s time. They employed independent security firms to help verify their findings and touted a 90%+ true positive rate. The nuance here is the patch cycle itself.
I do think this year is a landmark year for rapid vulnerability discovery and disclosure, but we are certainly not close to it being the year of rapid vulnerability patching. The bottleneck is the process of fixing, testing, merging, and deploying patches at scale. I hope Anthropic continues to invest in this space and moves towards rapid deployment of patches. Our industry, conferences, and community reveres vulnerabilities as the pinnacle of achievement for a researcher.
Maybe it’s my blue team bias, but the pinnacle achievement for me is protecting others. I’m unsure if more disclosed vulnerabilities protect others, because the externalities around patch time, exploit time, and volume may make our situation much worse.
If you haven’t read the Project Glasswing analysis above before reading this one, please do, because this episode is very relevant to my analysis. Shocker, it tends to agree with JAGS and the crew here :).
What I love about this episode is the sober grounding around the concept of “10xing vulnerabilities” due to these models. There is a lot of talk about the volume of patching from early-access vendors in Glasswing, but this tends to overlook the critical part: customers actually applying the patch!
Much like I said in my Glasswing update, I will be impressed if we can have companies that build and sell appliances, IoT devices, or even endpoints take a more opinionated approach to forcing patches. JAGS gave some ideas around this, such as giving a window for people to apply before a vendor forces the update. This has its risks, especially around governance, customer success, and usability, but if we want to tout the success of AI in security, then the boring part of patching needs to be solved just as much as the exciting part of vulnerability discovery.
Manage extensions in enterprise environments by Microsoft Visual Studio (Documentation)
Following GitHub’s disclosed security breach, someone on Reddit posted the documentation for managing, securing, and deploying Microsoft Visual Studio extensions. It was released five days ago, so it’s likely this was posted in response to the VSCode extension attack on GitHub, which resulted in its public disclosure. For the most part, these protections are great, but I worry about a few things.
First, it assumes you have a list of all extensions that every developer uses, that you can accept and apply a deny-all afterward. For those who work with a large engineering team: good luck with that! Second, trusted publisher allow lists wouldn’t have stopped the Tanstack attack since the trusted publisher itself was compromised. Third, besides the private registry, I wish there was a native way to grab an inventory of these extensions for analysis, much like what Bumblebee from Perplexity does.
Microsoft be Microsoftin’.
☣️ Threat Landscape
The Future and Past of Residential Proxies by Qurium
I learned the term “botnet” in my first year of college in 2008. The concept seemed cool: you infect a device, build a Rolodex of infected devices, and collect them like Pokémon cards. I never really understood the financial appeal because everything leading up to the massive DDoS botnets, such as Mirai, was mostly around selling access to perform DDoS attacks to make a statement. The recent development of residential proxies in the last two years, though, exposes a much more lucrative financial model and a more serious threat than DDoS attacks.
Qurium’s piece here eloquently lays out the history of this evolution and gives great context for those who worry about residential proxy abuse. It’s worth reading less for the individual provider callouts and more for the ecosystem shape. The interesting story is how Android supply-chain compromise, proxy SDKs, DDoS botnets, and commercial residential proxy markets start to blur together.
Qurium is on the receiving end of this abuse and has been mapping the providers, botnets, Android supply chain compromise, and proxy monetization layers that enable it. The useful takeaway is not that every residential proxy provider is malicious. It is that the line between “commercial proxy service,” “compromised device pool,” and “botnet infrastructure” is getting harder to see from the outside.
Lawmakers Demand Answers as CISA Tries to Contain Data Leak by Brian Krebs
Krebs provided a follow-up update on the initial break of his CISA Leak story, in which he obtained letters from lawmakers asking CISA to answer questions about how the leak happened. He posted a picture from one of the letters, and it looks like Krebs' story was the first reference in their letter. I wonder if he prints these out and frames them?
With CISA funding and workforce being slashed, as Krebs points out, it's hard to understand whether this leak happened due to reduced security controls, a burnt-out staff, or discontent. CISA took over a week to rotate some credentials, including an RSA private key, after having researchers from Trufflehog and GitGuardian reaching out multiple times.
Cybercriminal VPN used by ransomware actors dismantled in global crackdown by Europol
Europol seized servers and assets, and even interviewed an administrator of “First VPN”, a residential proxy network. These networks allow users to purchase access to typically unwitting endpoints, such as cellphones, routers, and VPSes, to conceal malicious activity and make it much harder for defenders to distinguish legitimate IP addresses from malicious ones.
I’ve always been impressed by these joint operations, especially those led by Europol. They have to coordinate across countries and jurisdictions, and they manage to navigate the bureaucracies of these agencies to execute coordinated takedowns that can include seizing physical servers, domains, and other infrastructure.
Supply Chain Attack Targets Laravel-Lang Packages with Credential Stealer by Iyas Makari
Aikido’s Iyas Makari publishes their research on a supply-chain attack targeting Laravel. Laravel is a PHP framework used by developers to build and manage PHP applications and is widely used by websites worldwide. There are two interesting findings from this report I want to call out:
I am worried that supply chain attacks affecting PHP applications are more likely to reach VPS servers themselves. This can open the door for more Mirai/Kimwolf-style residential proxy botnet infections, where the goal is to monetize access to compute rather than keys
The actor pushed malicious packages and pointed them to an orphaned commit on a fork, making it much harder to detect on the main repository
I don’t think bullet 1 is happening yet, as Makari reverse-engineered the infostealer itself, which performs typical infostealer-like things such as swiping secrets and API keys. But those secrets do exist in deployed web applications, and not to sound biased, but I don’t ever think of a PHP website hosted on a VPS is as “secure” compared to what we are used to in SaaS land :).
🔗 Open Source
Perplexity’s package scanning and supply chain security project linked from the Gem above. It’s a single Go binary you can run on your endpoints, typically paired with an MDM solution. It’ll scan for malicious packages and generate alerts, audit logs and build asset inventories.
Much like the prompt injections you see people post about on LinkedIn, where a description in their profile has a prompt that an AI recruiter uses when sending out messages, honeyslop does this but for codebases. It’ll add prompt injections as code itself, where AI vulnerability harnesses will read and report on fictitious vulnerabilities so you know when you receive an AI slop report.
GitHub native course for readers to learn about NTLM-relay style attacks, tools and frameworks. It has several sections that first introduce what an NTLM relay attack is, and then expands out to concepts like coercion attacks, different tools and advanced techniques.
malsnitch is a neat malware analysis helper that looks for secrets inside malware artifacts. It takes strings output, FLOSS JSON, or Binary Ninja exports and pulls out things like C2 credentials, crypto keys, API tokens, Discord webhooks, Telegram bot tokens, and hardcoded exfil configs. This is nice if you are tracking malware families that have hardcoded C2 servers that frequently change so you can update your blocking lists. These pivots can help uncover additional infrastructure, or map out existing infrastructure for your own security research.




