What happens when attackers exploit an unpatched application and gain a foothold?

Why a Foothold Changes the Attack from Intrusion to Control

Once an unpatched application is exploited, the issue is no longer the initial bug. The attacker now has an execution path inside a trusted environment, which changes the problem from prevention to containment. From there, the usual objective is to turn a single code flaw into durable access: establish persistence, steal credentials, identify reachable systems, and move toward higher-value assets. That is why post-exploitation speed matters as much as patch speed.

Practitioners often underestimate how quickly this phase can unfold. MITRE ATT&CK Enterprise Matrix helps map the likely follow-on behaviors after initial access, while The 52 NHI breaches Report shows how compromised identities and secrets are frequently the accelerant that turns a foothold into broader compromise. In practice, many security teams encounter lateral movement only after the attacker has already used the first host to harvest trust and blend into normal administration activity.

What Attackers Typically Do Next in the Environment

The first hour after exploitation is often about maximizing options, not causing obvious damage. Attackers usually probe for secrets in configuration files, environment variables, deployment artefacts, and service accounts. If those secrets are reusable, they can open additional applications, cloud consoles, or CI and delivery systems without needing to stay on the original host.

Common post-exploitation actions include:

• Dropping a web shell or similar backdoor to preserve access.
• Dumping credentials from memory, files, or token stores.
• Disabling logging or deleting artifacts to slow detection.
• Enumerating adjacent systems and privileged paths.
• Moving laterally toward databases, admin panels, or identity providers.
• Exfiltrating data or deploying monetization payloads such as miners.

These steps align with the patterns documented in the MITRE ATT&CK Enterprise Matrix, and they become especially dangerous when a compromised application also exposes non-human identities. NHIMG’s The State of Secrets in AppSec research is relevant here because leaked secrets are not just a hygiene issue, they are often the mechanism that lets an attacker turn one compromised app into many compromised systems. These controls tend to break down when legacy services share static credentials across environments because one foothold can then unlock multiple trust zones at once.

Where the Response Breaks Down and What Changes the Risk

Tighter containment often increases operational overhead, requiring organisations to balance rapid isolation against service continuity. That tradeoff becomes visible when the exploited application is customer-facing, highly integrated, or depends on shared service accounts. In those environments, revoking access too aggressively can interrupt legitimate traffic, but delaying action gives the attacker more time to pivot.

There is no universal standard for every application stack, but current guidance suggests the best response is to assume the attacker will search for secrets, tokens, and privileged sessions immediately. For cloud-native systems, that means short-lived credentials, strong segmentation, and fast credential rotation. For applications with NHI dependencies, it also means verifying whether the foothold exposed API keys, workload tokens, or automation accounts that outlast the original process.

Where organisations most often fail is not in patching alone, but in the downstream cleanup. If logging is incomplete, token lifetimes are long, or privileged accounts are reused, the attacker can keep operating even after the original flaw is fixed. That is why post-exploitation readiness should be treated as part of application security, not just incident response.

Related resources from NHI Mgmt Group

• What happens when attackers use valid employee credentials to access internal systems?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?