How Attackers Use AI and Disposable Infrastructure: A Practical View for Blue Teams
If you work on a Cloudflare WAF, you spend much of your day looking at requests that arrive from IP addresses you do not control. Some are scanners. Some are bots. Some are people testing a login form. A smaller group is trying to find a real way in.
This article looks at a question many blue teamers ask: how can an attacker use AI, local models and cheap cloud infrastructure against a company? The goal is not to give a recipe for attacks. The goal is to build a clearer mental model of attacker maturity, so you can choose detections and controls that still work when the source IP changes every few hours.
The short version
Attackers do not need a sophisticated AI pipeline to attack a company. Most successful intrusions still begin with exposed services, weak authentication, stolen credentials, vulnerable software or a trusted third party.
AI changes the economics of some parts of an attack. It can help an operator summarize reconnaissance results, generate variations of phishing content, reason over tool output and repeat a workflow with fewer manual steps. It does not remove the need for an exposed surface, a valid identity or a exploitable bug.
A useful way to think about this is through three levels of attacker maturity.
Level 1: The opportunistic attacker
This attacker wants results with minimal effort. They may use a rented VPS, a script, a public scanner and a small set of wordlists. If they use an AI model, it is often on their own laptop or on the VPS itself.
Their infrastructure is usually simple:
[Attacker machine or VPS] --> [Company]
They care about getting a response, not about building a durable operational setup. The VPS may be paid for with cryptocurrency, but the account, email address, payment pattern and access habits can still create links back to a person.
From the defensive side, this is the easiest profile to detect. You will often see broad scanning, repeated login attempts, unusual request rates, obvious tool fingerprints and traffic from hosting providers or datacenter ASNs.
Useful controls at this level include:
- Rate limiting on authentication and sensitive endpoints.
- Managed WAF rules and bot management.
- Blocklists and reputation feeds for known malicious infrastructure.
- Strong MFA and protection against credential stuffing.
- Alerts for scanning patterns and abnormal request volumes.
A Cloudflare WAF is particularly useful here because it can reduce noise before requests reach your application. The important part is to treat WAF rules as one layer, rather than as the whole security program.
Level 2: The organized attacker
This attacker has more patience and more operational discipline. They separate their personal identity from the infrastructure used during the attack. They may use temporary VPS instances, separate accounts and infrastructure that can be discarded after use.
A common conceptual separation looks like this:
[Attacker workstation: AI model and tools]
|
| Encrypted or anonymized access
v
[Disposable VPS: network relay or attack host]
|
v
[Company]
The attacker may run the AI model locally and use the VPS only as a network relay. Alternatively, they may run a smaller quantized model directly on the VPS, especially if the workload does not require a GPU. The choice depends on cost, speed and how much they want their own endpoint to remain uninvolved.
At this level, the attacker understands that deleting a VPS does not erase every trace. Provider records, payment data, upstream network logs, backups and ISP records can still exist. For that reason, they try to reduce the number of places where their real identity and their attack infrastructure meet.
For blue teams, the source IP becomes less reliable as a primary indicator. The same operator may use different addresses, while different actors may share common hosting ranges.
More useful signals include:
- Similar request sequences from different source IPs.
- Consistent TLS, HTTP or automation fingerprints.
- Reconnaissance followed by targeted attempts against login, API or administrative surfaces.
- Short-lived sessions with a narrow focus.
- Credential use that is technically valid but contextually unusual.
At this stage, behavioral detection matters more than static blocklists. You want to correlate identity, device posture, network origin, request pattern and business context.
Level 3: The mature actor
A mature actor treats infrastructure as disposable and treats identity as a separate problem. They do not rely on one VPS, one payment method or one access path. They may use infrastructure they do not directly own, including compromised systems, rented resources obtained through intermediaries or services that make attribution harder.
Their model is closer to this:
[Isolated operating environment]
|
[Relay or intermediary infrastructure]
|
[Attack host or compromised system]
|
[Company]
The AI component may help with analysis, orchestration or documentation, but it is not the core of the intrusion. The core is still patience, valid access, a vulnerable dependency or a human being who can be deceived.
This type of actor produces fewer obvious indicators. Traffic may be slower, lower volume and more selective. They may use valid credentials, legitimate tools and normal-looking protocols. A single WAF rule will rarely stop them.
Your best defenses are structural:
- Reduce the number of internet-facing services.
- Require phishing-resistant MFA for privileged access.
- Apply least privilege and short-lived credentials.
- Monitor identity anomalies, not only network anomalies.
- Keep centralized logs across WAF, identity provider, endpoint, email and cloud platforms.
- Build detection around chains of behavior, such as reconnaissance followed by authentication followed by privilege changes.
The mature attacker is not necessarily invisible. They are harder to catch through one isolated signal. You need context across time, systems and identities.
Where MCP and AI agents fit
AI agent frameworks can connect a language model to external tools. In a legitimate security context, this can help a pentester run reconnaissance, organize findings and automate repetitive work. In the wrong hands, the same pattern can make an operator faster at working through tool output and repeating tasks.
The important point for defenders is that the AI model is not the attack. It is an accelerator around the attack. If your application has no exposed weakness, no weak identity control and no useful data to reach, an AI agent has little to work with.
That is why AI should not distract you from fundamentals. Patching, identity hardening, least privilege, secure defaults, logging and incident response still decide most outcomes.
What this means for Cloudflare WAF work
A WAF is excellent at reducing automated noise and enforcing rules at the edge. It is less effective as the only control against a patient attacker who uses valid credentials and legitimate-looking traffic.
A practical approach is to use the WAF for what it does well:
- Filter obvious automated abuse.
- Enforce rate limits and bot controls.
- Protect known vulnerable paths.
- Apply geo, ASN and reputation-based rules where they make sense.
- Generate high quality logs for downstream analysis.
Then connect those logs to the rest of your detection stack. A blocked request is useful. A pattern of blocked requests, failed logins, new device registrations and privileged access attempts is much more useful.
A better question than “who is behind this IP?”
For a blue teamer, the most productive question is often not “who owns this IP?” It is:
What is this sequence of activity trying to achieve, and which control should have stopped it?
An IP can be rotated. A VPS can be deleted. An AI model can run locally. But poor identity hygiene, exposed services, excessive privileges and missing logging remain durable weaknesses.
Focus on making those weaknesses expensive to exploit. That is where your leverage is.
Top comments (0)