Adversaries may buy, steal, or download exploits to use during targeting. An exploit takes advantage of a bug or vulnerability to cause behavior the software's authors did not intend. MITRE lists this technique under Resource Development, with the platform marked PRE because it happens before any compromise.
The point worth taking from it: an attacker does not need to be a skilled exploit developer. They only need to find or pay for one that fits what you run.
How attackers use it
MITRE describes several sources. Free exploits can be downloaded from the internet. Adversaries may also buy them from third parties, which MITRE says can include technology companies that specialize in exploit development, criminal marketplaces including exploit kits, and individuals. They may also steal and repurpose exploits from others, including other adversaries.
An adversary may monitor exploit provider forums to track what exists and what is new. MITRE points out that there is usually a delay between discovery of an exploit and the moment it becomes public, and that adversaries may target the systems of people known to do exploit research in order to get that knowledge early.
Once acquired, exploits can be used at many points in an intrusion. MITRE links the technique to exploitation of public-facing applications, client execution, privilege escalation, stealth, credential access, and remote services.
Three things stand out in MITRE's text. First, the supply is varied. Exploits come from free downloads, from criminal markets, from specialist companies, and from other attackers. A defender cannot cut off any single source.
Second, the timing. MITRE notes that there is usually a delay between discovery of an exploit and its publication, and that adversaries may target exploit researchers for early knowledge. That means some exploitation can start before a fix is public.
Third, the reach. MITRE links acquired exploits to many stages: public facing applications for initial access, client execution, privilege escalation, credential access, and exploitation of remote services for movement. A single exploit can help at more than one step.
How to detect it
MITRE is direct that much of this activity takes place outside the visibility of the target organization, which makes the acquisition step difficult to detect.
Its guidance is to focus on behaviors that relate to the use of exploits instead. In practice that means the detection work belongs to the techniques it names: exploitation of public-facing applications, client execution, privilege escalation, credential access, and remote services.
For each, ask what telemetry would show a failed or successful exploit attempt. Crashes of internet-facing services, unexpected child processes spawned by an application, and new privileged sessions after an application error are the kind of signals worth routing to an analyst.
Build the detection around each place an exploit would be used. For internet facing applications, review web and application logs for requests that cause errors and for unexpected processes started by the web server user.
For endpoints, look at the processes started by document readers and browsers. For privilege escalation, watch for a normal user process that ends up running as a more privileged account. For remote services, look for crashes followed by new sessions.
None of these is certain. The aim is to turn the invisible purchase into visible effects: a crash, a child process, a new session. Even a basic alert on each, reviewed by a person, helps.
Keep the evidence. When an exploit attempt is blocked or fails, save the request, the source, and the time. A failed attempt tells you which flaw someone believed you had, and that is useful for deciding what to check next.
Review those records against your inventory. If an attempt targets a component you do not run, note it and move on. If it targets one you do, confirm that the fix is in place and look for earlier attempts that may have succeeded.
How to reduce the risk
- Accept the limit first. MITRE's own mitigation entry for this technique says it cannot be easily mitigated with preventive controls, because the behavior happens outside the scope of enterprise defenses and controls.
- Shorten the time between a fix being available and a fix being applied on anything reachable from the internet. Known exploits are most useful to attackers against unpatched systems.
- Keep a current inventory of software and versions so you can answer in minutes whether a newly disclosed flaw affects you.
- Rank patches by whether an exploit exists and whether the system is exposed, instead of by score alone.
- Invest in detection and containment for the exploitation techniques MITRE links to, since you will see those even when you cannot see the purchase.
The demo below walks through checking whether a flaw is both exploitable and reachable, which is the question that decides patch order when exploits are cheap.
Finally, plan for the time before a patch exists. Know how to isolate or turn off an exposed component, who can approve it, and how to monitor in the meantime. A mitigation that can be applied within hours is worth more than a patch that takes weeks.
One last point on process. Agree in advance who can take an exposed service offline, and what information they need to decide. The hardest part of responding to a known exploit is rarely the technical work. It is getting a decision made quickly, so write the decision path down.
Check your own environment
- Can you list every internet-facing application and its exact version today?
- When a critical advisory lands, who decides priority, and how long does that take?
- Do you have a way to tell which flaws have a public exploit?
- Are application crashes and unexpected child processes on exposed servers logged and reviewed?
Try it yourself
This walkthrough shows how to separate flaws that have a known exploit and a reachable path from the rest of the backlog.
Click through it at your own pace, or open it full screen.
Quick check
Why is acquisition of exploits hard to detect?
It happens on forums, marketplaces, and in other organizations, outside the visibility of the target. MITRE says to focus on behaviors that use exploits.
What does MITRE say about the gap between discovery and publication?
There is usually a delay between an exploit being discovered and being made public, and adversaries may target exploit researchers to gain that knowledge.
Sources
- MITRE ATT&CK, Exploits (T1588.005): https://attack.mitre.org/techniques/T1588/005
