How AI Lowered the Barrier to Multi-Stage Cybercrime
Unit 42’s investigation shows how one operator used AI assistants to support credential theft, data exfiltration, VoIP fraud planning and reconnaissance.
Artificial intelligence did not replace conventional attack tools in the operation investigated by Palo Alto Networks Unit 42. Instead, it acted as an accelerator: generating reconnaissance summaries, producing scripts, organizing stolen data and supplying specialist guidance across several criminal objectives.
Unit 42’s analysis describes an operator using the handle BUGSTER who combined the Hermes Agent framework, DeepSeek V4 and an AI-assisted development environment to pursue credential theft, database exfiltration, VoIP fraud planning, Wi-Fi password cracking, cryptocurrency reconnaissance and command-and-control activity. The activity primarily affected targets in India, including universities.
The significance is less about a novel malware family than about operational breadth. A single operator with what Unit 42 characterizes as relatively basic tooling was able to move between web attacks, cloud and database exposure, telecommunications research and local wireless activity. The case demonstrates how AI can reduce the expertise required to coordinate distinct stages of cybercrime, while leaving many familiar defensive signals intact.
What Unit 42 confirmed
Unit 42 identified an operational environment in which Hermes Agent served as the main AI interface. The operator controlled separate Hermes profiles through Telegram, with profiles dedicated to general criminal assistance, VoIP fraud advice and carrier research. DeepSeek V4 was ultimately used as the primary reasoning engine. Cursor was configured as a secondary development tool, with the environment set to enable broad agent functionality and bypass normal permission and sandbox checks.
The infrastructure also hosted a Python-based listener for Windows reverse-shell connections, along with supporting payloads and scripts. Unit 42 reported a Base64-encoded PowerShell reverse shell delivered through VBScript, several Windows shell variants, and a QubesOS setup script using SSH and ncat. These details show that the AI systems were connected to conventional administrative and scripting tools rather than operating as an independent autonomous malware platform.
In one campaign against an Indian university’s online education platform, the operator used AI-generated reconnaissance to organize the target’s exposed attack surface. The reported sequence included subdomain enumeration, identification of 12 subdomains, WordPress REST API enumeration, extraction of 13 active user IDs, preparation of a username and password list, and a targeted brute-force attempt. Unit 42 said the tooling identified one valid WordPress login. The research does not establish what access, if any, followed from that credential.
A separate intrusion had a more substantial confirmed outcome. The operator obtained an administrator account protected by a weak password and exfiltrated a MongoDB database from another Indian public university. The dumped collections contained more than 5,200 student and faculty records, including personally identifiable information. The accompanying manifest also recorded exposed infrastructure such as cloud load balancing, edge routing, database services and a third-party cloud-storage account.
Unit 42 additionally observed enumeration of an Indian e-commerce site. The collected material included a storefront API token, three administrator email addresses, two phone numbers and payment merchant identifiers. The research describes a report containing a section for planned follow-up opportunities, but it does not confirm that those proposed actions were carried out.
AI-supported criminal specialization
The VoIP activity illustrates how the operator used AI as an on-demand subject-matter adviser. The Hermes profile named “alice” was configured with a knowledge base and conversation history focused on telecommunications fraud. Another profile, “pandarouter,” was used for carrier research and route-related investigation.
Unit 42 found detailed planning around establishing a telecommunications front, obtaining carrier access, mixing legitimate and fraudulent traffic, circumventing caller-identity controls and monetizing non-compliant routes. However, the researchers found no call logs, SIP traces or evidence of active call routing. Their assessment was that the VoIP operation remained in planning or an early setup phase, rather than being a confirmed completed fraud campaign.
The same environment supported a wireless-password-cracking workflow. A Linux device positioned within range of target networks collected WPA authentication material and transferred it through an SSH tunnel to cloud GPU instances for processing. Results were returned through Discord webhooks. Because the process required proximity to the targeted wireless networks, Unit 42 assessed that the operator had local access to the relevant locations. The research does not identify those locations or confirm successful compromise of a particular wireless network.
Unit 42 also identified a Go-based credential-scanning toolkit capable of searching webpages and extracting exposed secrets, including environment-file values, signed cloud-storage URLs, cloud service-account keys, content-delivery-network API keys and private keys appearing in log files. A companion Python script collected domain lists for scanning. These tools created risk across both application and cloud environments because publicly exposed credentials could enable access beyond the original web target.
For cryptocurrency reconnaissance, the operator queried the DeBank API for major Ether and token holders. The resulting files documented 45 cryptocurrency “whales,” including estimated net-worth information. Unit 42 assessed that this information was likely intended for future targeting, but found no follow-on activity during the investigation.
Infrastructure and safety-control bypasses
Unit 42 identified a single United States-based server used to host several core services, including Hermes Agent, a command-and-control listener and a Cursor proxy. The report lists the server address as 162.243.3[.]92 and identifies a commercial proxy at 104.238.38[.]202. These indicators should be treated as historical research artifacts and investigated in context rather than blocked blindly without validation.
The operator tested multiple language models, including GLM 5.2 and models accessed through OpenRouter, before selecting DeepSeek V4. The research documents repeated attempts to override model safety behavior through system-prompt manipulation. In the Cursor environment, a proxy script forced agent mode, bypassed permission checks, disabled the IDE sandbox and automatically approved MCP servers.
These configurations are important for defenders operating their own AI tools. The problem was not simply that a model generated code. The surrounding environment granted the model broad authority, connected it to messaging and development systems, and removed safeguards that would normally require human approval. AI governance therefore needs to cover the agent runtime, credentials, tools and external integrations—not only the model’s content policy.
Attribution and confidence
Unit 42 assessed that BUGSTER was a financially motivated, multi-domain criminal operator with no prior reporting identified by the researchers. The assessment describes an English-speaking operator using informal and frequently broken grammar. The available evidence does not establish a named criminal group, government connection or broader campaign ownership.
Unit 42 also assessed that the Hermes-and-DeepSeek combination may be gaining traction among cybercriminals, citing separate activity involving the same toolchain. That is a researcher judgment about an emerging pattern, not proof that every user of those tools is connected or malicious.
Detection and investigation priorities
Organizations should begin with ordinary identity, application and cloud telemetry. Review WordPress REST API access, author and user enumeration, unusual login attempts, authentication failures followed by success, and administrative access from unfamiliar networks. The university case shows why a successful login should be correlated with subsequent requests, privilege changes, database access and bulk downloads rather than treated as an isolated authentication event.
For databases and cloud services, monitor administrator logins using weak or previously unseen credentials, unexpected exports, large collection reads, new service-account activity and access to cloud storage from unfamiliar hosts. Compare application inventories with externally visible subdomains, API endpoints and administration portals. Secrets scanning should cover public web content, logs, environment files, repositories and object-storage configuration.
Endpoint and network teams should investigate unexpected PowerShell, VBScript, Python, SSH and ncat activity, especially where those processes form a chain or run from development servers. Reverse-shell listeners, outbound connections to unusual infrastructure, and scripts that automatically forward results to messaging or webhook services deserve review. The reported indicators—162.243.3[.]92 and 104.238.38[.]202—can support retrospective searches, but behavioral detections are more durable than reliance on those two addresses.
Wireless monitoring teams should look for unexplained collection of WPA authentication material, unusual access-point proximity events and transfers from local Linux systems to cloud compute providers. Telecommunications providers should apply their own compliance, caller-identity and traffic-anomaly controls, while recognizing that Unit 42 did not confirm active calling in this case.
What organizations should do now
- Reduce exposed attack surface: inventory subdomains, WordPress installations, administrative portals, APIs, databases and cloud-storage integrations. Remove or restrict services that do not need public access.
- Strengthen identity controls: eliminate weak and reused passwords, require phishing-resistant MFA where practical, limit administrative accounts, and review dormant credentials and service accounts.
- Protect secrets: scan public content and logs for exposed keys, rotate any discovered credentials, restrict token scope and lifetime, and avoid embedding secrets in scripts or webhook configurations.
- Monitor data access: alert on unusual database exports, bulk reads, administrator activity, and access to student, faculty, customer or payment-related records.
- Secure AI development environments: retain sandboxing, permission prompts and human approval for sensitive actions. Restrict agent access to source code, production systems, credentials, messaging platforms and cloud consoles.
- Control AI integrations: inventory model gateways, MCP servers, IDE proxies, Telegram bots and other agent connectors. Apply least privilege, strong authentication, logging and rapid token revocation.
- Use the supplied indicators carefully: search historical DNS, firewall, proxy, endpoint and authentication logs for the defanged addresses, then investigate related behavior and account activity.
Conclusion
The Unit 42 investigation shows an important change in attacker economics: AI can let one operator coordinate activities that previously demanded several specialized skill sets. The observed campaign still depended on weak passwords, exposed services, ordinary scripts and insufficiently controlled credentials. That is encouraging for defenders. Strong identity security, reduced exposure, comprehensive logging and tightly governed AI agents can disrupt the same attack chain, even when the adversary uses automated assistance.