Who is accountable for stopping proxy-based persistence after intrusion?

Why This Matters for Security Teams

Proxy-based persistence is dangerous because it lets an intruder keep using legitimate access paths after initial intrusion, often by chaining stolen credentials, forwarding rules, or abused service accounts. That makes the problem bigger than endpoint cleanup. Security operations has to detect the persistence pattern, IAM has to revoke or reissue the identities involved, and infrastructure teams have to close the network routes that make the proxy viable. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it treats identity, logging, and boundary protections as linked obligations, not separate chores. The NHIMG view of identity risk is equally blunt: the Ultimate Guide to NHIs shows how often non-human identities remain overprivileged, unrotated, and poorly governed. When persistence hides behind a proxy, teams often assume the issue is contained once the malware is removed. In practice, many security teams encounter repeated access only after the attacker has already reused the proxy path to move laterally or re-enter through a trusted channel.

Effective response starts with identifying the persistence mechanism, then mapping every identity and route it depends on. A proxy can be a compromised server, a reverse shell endpoint, a cloud relay, or a service account used to tunnel requests. The key question is not just “what was breached?” but “what still authenticates the attacker?”

At that point, the response should combine three actions: revoke the identity, invalidate the path, and confirm the abuse is gone. For NHI-heavy environments, that often means rotating secrets, disabling orphaned service accounts, reviewing token issuance, and checking whether the proxy was used to hide behind a trusted workload identity. The Salt Typhoon US telecoms breach is a good reminder that stolen credentials and long-lived access paths can persist well beyond the initial intrusion window.

Operationally, security teams should validate egress logs, authentication logs, and downstream service access together rather than in silos. That means checking whether the proxy terminated TLS, relayed API calls, or simply forwarded traffic to preserve attacker access. If the environment supports it, apply conditional revocation and continuous verification through policy controls such as least privilege, session binding, and network segmentation. The important point is that “stop” means more than kill the process.

• Confirm which identity, token, or key powered the proxy.
• Revoke or rotate every credential that could recreate the path.
• Inspect egress rules, forwarding rules, and trusted tunnels for abuse.
• Validate that no alternate proxy, backup account, or API key remains active.

These controls tend to break down in environments with shared administrative access, unmanaged service accounts, or cloud-to-cloud integrations where revocation cannot be verified quickly.

How It Works in Practice

Tightening proxy controls often increases operational overhead, requiring organisations to balance rapid containment against service continuity. In practice, accountability should be assigned by control plane, not by blame alone. Security operations owns detection and triage, IAM owns identity invalidation and secret rotation, and infrastructure or network teams own the routes, forwarding rules, and outbound filters that let the proxy continue to function.

The response sequence usually looks like this: detect unusual proxy behaviour, identify the authenticating identity, revoke or quarantine that identity, and then prove the route is no longer usable. For service accounts and API keys, the fastest safe option is often just-in-time replacement rather than trying to preserve the old credential set. That aligns with current guidance in identity governance and with the broader NHIMG guidance on NHI lifecycle control, which emphasises rotation, offboarding, and visibility as part of one loop. NIST’s SP 800-53 Rev 5 supports this model through access control, audit logging, and boundary protection requirements.

A practical containment workflow usually includes:

• Disable the proxy host, account, or tunnel endpoint immediately if business impact is acceptable.
• Rotate credentials for any account that authenticated to or through the proxy.
• Check for alternate sessions, refresh tokens, delegated tokens, and cached credentials.
• Review egress proxy logs, DNS logs, and cloud control-plane activity for reuse.
• Confirm that the same access cannot be re-established from a different host or region.

This is where many response plans fail: they revoke one access path but leave a second identity, token, or outbound relay intact. These controls tend to break down when proxying is embedded in managed SaaS integrations or third-party support channels because ownership of the relay is shared and revocation authority is ambiguous.

Common Variations and Edge Cases

Tighter proxy containment often slows incident response, especially when the proxy supports legitimate business traffic, so organisations have to balance disruption against the risk of letting persistence continue. There is no universal standard for every proxy scenario, and current guidance suggests treating the proxy as both a network object and an identity-bearing control point.

One edge case is a reverse proxy that is not malicious by itself but has been repurposed with stolen credentials. Another is a cloud application proxy where the attacker abuses refresh tokens or service-to-service trust instead of the proxy host. In those cases, stopping persistence requires more than blocking an IP. It may require re-authenticating dependent workloads, invalidating delegated permissions, and reviewing the full trust chain for overbroad access. The NHIMG data point that only a small share of organisations have full visibility into service accounts explains why these cases are missed so often.

Another wrinkle is delegated administration. A team may own the proxy technology, but IAM may own the credential lifecycle and SecOps may own the detection logic. Accountability is therefore shared, yet the programme owner remains responsible for forcing closure across all three lanes. Where proxy persistence intersects with third-party access, that owner should require proof of revocation, not just a ticket closure or verbal confirmation.

Related resources from NHI Mgmt Group

• Why do still-valid secrets matter after public disclosure?
• Who is accountable for stopping identity-based attacks when IAM and PAM are involved?
• Who is accountable when mailbox permissions, tokens, and browser controls are not reviewed after an intrusion?
• Who is accountable when organisations keep relying on passwords after repeated credential-based breaches?