Outsourcing Exploits: 'bandcampro' Uses Gemini CLI for Dental Botnet
Just caught the analysis of 'bandcampro' on HackerNews. It’s fascinating—and honestly a bit worrying—to see a solo actor effectively outsourcing their operational overhead to Google's open-source Gemini CLI. We often talk about AI writing malware, but here we have a threat actor using the LLM actively to manage a live botnet of eight dental clinics.
The logs from March to April show the actor wasn't just generating code; they were using the CLI to brute-force credentials and configure residential proxies to obscure their traffic. The dental vertical is a soft target, but leveraging AI for rapid password cracking iteration changes the timeline significantly.
From a detection standpoint, this creates a weird anomaly. We're looking for script kiddie behavior masking behind legitimate API calls. If you're monitoring endpoint traffic, watch for unexpected python or bash sessions interacting with generativelanguage.googleapis.com.
Here’s a basic KQL query I’m throwing at our Sentinel tenant to flag potential LLM-assisted C2 activity:
DeviceNetworkEvents
| where RemoteUrl contains "generativelanguage.googleapis.com"
| where InitiatingProcessFileName in ("python.exe", "python3", "bash", "gemini")
| project Timestamp, DeviceName, InitiatingProcessCommandLine, RemoteUrl
| summarize count() by DeviceName, InitiatingProcessCommandLine
Has anyone else started incorporating AI provider endpoints into their IoC lists, or are we treating this as too much noise given legitimate dev usage?
We started blocking Google Gemini and OpenAI API endpoints at the perimeter for non-dev workstations last quarter. It’s noisy because users try to use web interfaces, but the CLI traffic is a massive red flag. In the 'bandcampro' case, the volume of requests likely gave them away. Standard automation scripts don't usually 'think' this hard about proxy rotation.
Interesting angle on the proxy setup. Using AI to parse 'living off the land' binaries (LOLBins) for proxy configuration makes the malware significantly lighter. The actor doesn't need to ship a full proxy module; they just ask the CLI how to configure the Windows registry for a proxy using reg.exe.
As an MSP owner with a few dental clients, this hurts. They rarely have dedicated SOC staff. If the attacker is using AI to speed up the recon phase, the dwell time before detection is going to plummet. I'm pushing out stricter GPOs to restrict CLI access, but if they are already inside...
Valid point, MasterSlacker. However, blocking domains often fails if actors switch to direct IP resolution. We’ve had better success inspecting the TLS JA3 signatures specific to the Gemini CLI client, as they differ from standard browsers.
You can spot this by filtering for non-browser User-Agents in your logs. A quick way to hunt for this activity in your outbound proxy logs is:
grep -E "googleapis|generativelanguage" /var/log/squid/access.log | awk '{print $7}' | sort | uniq -c | sort -rn
This usually highlights the automated CLI traffic immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access