Attackers use an internal proxy to relay their traffic through systems inside the target environment, helping hide the original source and reach otherwise restricted assets. Defenders should watch for unexpected tunnelling, proxy configuration changes, unusual internal relay hosts, and authentication patterns that do not match normal user or service behaviour.
How internal proxies help attackers stay hidden
An internal proxy is useful to attackers because it gives them a relay point inside the environment, so traffic appears to come from a trusted internal host rather than from the attacker’s real origin. That changes how defenders see the activity, especially when the proxy is used to reach segmented systems, pivot between networks, or blend into normal east-west traffic.
The technique is most effective when the relay host already has legitimate reach, or when the attacker can make it look like ordinary application traffic. In practice, that means defenders need to think about traffic origin, trust boundaries, and whether a host is acting as an unexpected intermediary rather than just a destination or source.
What attackers are actually trying to achieve with the relay
Using an internal proxy is not just about anonymity. It is often about preserving access while reducing friction, because the proxy can forward requests to assets that would otherwise reject direct connections or trigger external-source controls. The same pattern can support scanning, credential use, lateral movement, command relay, and data transfer once the attacker has foothold inside the environment.
This is why Command and Control (C2) Guide is directly relevant here: proxying is one of the ways adversaries hide command channels and keep remote control usable under network scrutiny. When the relay is internal, the traffic can also look less suspicious to perimeter-focused monitoring.
Signals that the proxy is being abused, not just used
The strongest clues are behavioural inconsistencies. A host that suddenly starts forwarding traffic for multiple destinations, shows unusual tunnelling patterns, or presents proxy configuration changes without a clear operational reason deserves attention. So do authentication events that do not fit the host’s normal role, especially when a service account or administrative context is involved.
Look for repeated connections from one internal node to many restricted assets, unexpected use of nonstandard ports, or a system that begins acting like a relay after a period of inactivity. If the proxy behaviour aligns with a legitimate change window, it may be benign. If it appears on a workstation, server, or service that should not broker traffic, treat it as potential abuse.
Attackers often pair the relay with living-off-the-land behaviour so the traffic blends into routine administration or application activity. That makes host-level context important, because the same protocol can be normal in one role and highly suspicious in another.
Risk and Threat Considerations
An internal proxy creates a trust problem when defenders assume internal sources are inherently safer. Once an attacker can relay through a trusted host, segmentation, source-based allowlists, and simple geolocation checks lose much of their value. The technique also increases the chance that malicious activity is attributed to the relay host rather than the true operator.
Failure mechanism: The attacker turns a trusted internal system into an intermediary, then uses that position to bypass source controls, obscure attribution, and reach assets that would normally be harder to contact directly.
Impact: This can enable stealthier lateral movement, more durable command and control, and broader reach into protected systems before defenders recognise the host is acting as a relay.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1090 — Proxy | Internal proxy use is a proxy-based adversary relay technique. |
| T1021 — Remote Services | Attackers often use proxies to reach internal services and expand lateral access. | |
| Recommendation — Map relay behaviour to T1090 and hunt for pivoting hosts and hidden access paths. Correlate proxy use with service reachability and lateral movement paths. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Proxy relays are a boundary-control problem involving allowed traffic paths. |
| Recommendation — Enforce flow restrictions so only approved intermediary hosts can broker internal connections. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Unexpected proxy changes and tunnelling are network-control and configuration issues. |
| Recommendation — Monitor and review internal proxy configurations, routes, and trust relationships. | ||
Practitioner Guidance
What to verify: Confirm whether the host is supposed to proxy traffic at all, and if so, whether its destination set, protocol mix, and authentication patterns match its documented function. A proxy that is technically legitimate can still be operationally suspicious if it starts serving new paths or new user populations.
Decision rule: If the relay host is not an approved intermediary, treat the behaviour as a containment issue first, then investigate whether the host was used to pivot, stage tooling, or reach restricted assets. If it is approved, compare the observed flows against its normal baseline before deciding it is harmless.
Practitioner takeaway: The key question is not whether an internal proxy exists, but whether it is acting within its expected role, because abuse is revealed by unexpected mediation, not by tunnelling alone.