How do security teams know whether IOC blocklists are enough against proxy-based attacks?

Why This Matters for Security Teams

IOC blocklists are useful, but proxy-based attacks weaken their value because the address seen by defenders is often only the relay point. Residential proxies, cloud relays, and compromised endpoints can make malicious traffic look ordinary at the network edge. Security teams that rely on IP reputation alone tend to miss the real signal: whether the session, device, identity, and access path make sense together.

That matters because proxy use is not inherently malicious. Legitimate users also appear through VPNs, mobile networks, or shared egress points, so false confidence can build quickly if the team equates “blocked IP” with “blocked threat.” Current guidance suggests treating IOC blocklists as one layer in a broader detection strategy, not as a primary control. The relevant defensive question is whether the activity matches trusted patterns for authentication, user behaviour, and resource access, as reflected in sources such as the MITRE ATT&CK Enterprise Matrix and NIST control guidance.

In practice, many security teams encounter proxy abuse only after account takeover, automation abuse, or data access has already occurred, rather than through intentional perimeter blocking.

How It Works in Practice

A practical defense model separates what is visible at the network edge from what is happening inside the session. Blocklists still help with obvious repeat offenders, but teams need controls that examine authentication quality, request timing, device posture, and access consistency. If a login comes from a new region, followed by unusual API volume or rapid resource enumeration, that is more meaningful than the source IP alone.

Security operations typically combine several signals:

• Identity signals such as impossible travel, new device use, or abnormal MFA patterns
• Session signals such as bursty requests, scripted navigation, or low human interaction
• Access signals such as unusual service paths, privilege escalation attempts, or atypical object access
• Reputation signals from threat intelligence and advisories, including CISA cyber threat advisories

Detection engineering should map these behaviours to known techniques in MITRE ATT&CK, then tune controls to the specific application architecture. For example, API-heavy environments often need anomaly detection on token use, request rate, and sequence patterns, while SaaS environments may need tighter conditional access and step-up authentication. Where proxy traffic is paired with automation or AI-assisted abuse, teams should also track pattern shifts that resemble the tradecraft described in the Anthropic report on first AI-orchestrated cyber espionage campaign.

For control design, NIST SP 800-53 Rev. 5 is a useful anchor for access monitoring, incident response, and auditability, especially where session telemetry and identity assurance need to be correlated. These controls tend to break down in high-churn environments with heavy NAT, shared egress, or unmanaged devices because the environment itself makes “normal” network origin difficult to define.

Common Variations and Edge Cases

Tighter detection often increases operational overhead, requiring organisations to balance stronger behavioural controls against alert fatigue and user friction. That tradeoff is especially visible in remote-work, BYOD, and customer-facing platforms where benign proxy use is common and fixed IP reputation is a weak discriminator.

There is no universal standard for this yet, but current guidance suggests that proxy-aware defenses should be tuned to the risk of the service. High-value administrative portals, financial workflows, and sensitive data repositories justify stronger step-up checks and session analysis than low-risk public content. Where identity confidence is low, the path through the proxy matters less than whether the session can be tied to a trusted user, device, and purpose.

Emerging AI-driven attack chains make this more complicated. Adversaries may use automation to vary timing, rotate infrastructure, and blend into normal traffic, which reduces the value of static IOC blocklists even further. Security teams should therefore validate whether their detections still work when traffic is relayed through residential infrastructure, cloud hosts, or compromised endpoints, and whether they can distinguish legitimate anonymisation from hostile concealment. The MITRE ATLAS adversarial AI threat matrix is useful when proxy-based abuse overlaps with automated or model-assisted intrusion patterns.

In regulated environments, the practical test is simple: can the organisation explain why a session was trusted, challenged, or blocked, and can it do so consistently across users, devices, and regions? If not, the blocklist is probably masking a deeper visibility gap rather than closing it.

Related resources from NHI Mgmt Group

• How do security teams know whether OIDC-based roles are actually safe?
• How do security teams know whether intent-based classification is working for AI content?
• How do security teams know whether certificate-based authentication is over-trusted?
• How do security teams know whether AI logging is good enough?