Custom Exploit Development: Defending Against T1587.004

Develop Capabilities: Exploits (T1587.004) is a resource development technique tagged PRE. The adversary builds their own exploits to take advantage of bugs in software and hardware.

An exploit is code that triggers unintended behavior by abusing a flaw. The development happens on the adversary's side of the fence. What you can see and control is what the exploit meets when it arrives.

How attackers use it

MITRE says an exploit takes advantage of a bug or vulnerability to cause unintended behavior in hardware or software. Rather than finding or modifying exploits online, or buying them from vendors, the adversary builds their own.

They may use information about vulnerabilities to focus development effort. The page mentions that, in the process, adversaries may uncover exploitable flaws through methods such as fuzzing and patch analysis.

As in legitimate development, different skills are needed. They may be in-house or contracted, and a contractor can count as an extension of the adversary's capability when the adversary shapes requirements and keeps initial exclusivity.

MITRE lists many places the finished exploit may appear:

• Exploit of public-facing applications.
• Exploitation for client execution.
• Exploitation for privilege escalation.
• Exploitation for stealth.
• Exploitation for credential access.
• Exploitation of remote services.
• Application or system exploitation.

The common point is patch analysis. When a vendor ships a fix, the fix itself shows where the bug was. The time between a patch and your deployment of it is time during which someone may be building an exploit from the patch.

How to detect it

MITRE says much of this activity is outside the visibility of the target organization. It points detection efforts toward the behaviors where exploits get used: exploit of public-facing applications, exploitation for client execution, privilege escalation, stealth, credential access and remote services, plus application or system exploitation.

That is a long list, so a few practical signals help narrow it.

• Internet-facing services that crash, restart or log errors in odd patterns. Failed exploit attempts often look like faults.
• Web server or application processes that spawn shells or unexpected child processes.
• Unusual outbound connections from servers that normally only receive traffic.
• Privilege changes on a host that do not match an admin action.
• Security tool alerts on memory protection violations.

You cannot watch every flaw. You can watch the processes that matter most, and you can shorten the window in which you are exposed.

Knowing where you are exposed comes first. If a vulnerability is announced in a library, you need to know which of your applications bundle that library and whether the vulnerable code is reachable. A software inventory and a dependency scan answer the first question, and an exploitability check helps with the second.

Click through it at your own pace, or open it full screen.

How to reduce the risk

MITRE lists Pre-compromise as the mitigation. It says this technique cannot be easily mitigated with preventive controls since it is based on behaviors performed outside of the scope of enterprise defenses.

The adversary builds the exploit out of your reach. What you control is the flaw it needs.

• Patch quickly, with the internet-facing systems first. Fixes show adversaries where flaws are, so speed matters.
• Know what you run. Keep an inventory of software and libraries, including indirect dependencies.
• Prioritize by exposure and exploitability, not only by score. A flaw in code that is reachable from the internet outranks one that is not.
• Reduce attack surface. Remove services, features and packages that you do not use.
• Isolate internet-facing systems so that one compromise does not reach everything.
• Use memory protection and exploit mitigation features that the operating system provides.
• Test your response. Practice rolling out an emergency patch before you need to.

For dependencies, Safeguard offers a free in-browser dependency scan at https://gold.safeguard.sh/scan. You do not need to log in, the file never leaves your machine, and it handles up to 100 dependencies. It is a quick way to see which known flaws are present in what you ship.

Consider how to prioritize when several flaws are announced at once. Start with three questions. Is the vulnerable component reachable from the internet or from an untrusted user? Is there public information that an exploit exists or is being developed? What does the system hold or control if it falls?

Flaws that answer yes to the first and second questions go to the front, and flaws in sensitive systems follow. Everything else follows a normal patch cycle. That ordering respects MITRE's observation that adversaries focus development effort using information about vulnerabilities, so the vulnerabilities that attract attention are the ones most likely to see an exploit.

Where a patch is not available, look for a mitigation: disable the feature, restrict access to the service, add a filtering rule or isolate the system. Write down the date you applied the workaround and the date the real fix goes in, so that the temporary measure does not become permanent by accident.

Check your own environment

• Can you list every internet-facing application and the libraries each one includes?
• How long does a critical patch take from release to deployment on those systems? Write the number down.
• Do web server processes have restrictions on spawning shells?
• Linux, read-only: ps -eo pid,ppid,user,cmd --forest shows process trees. Look for shells under web server processes.
• Debian family Linux, read-only: apt list --upgradable lists pending package updates.
• Windows, PowerShell, read-only: Get-HotFix | Sort InstalledOn -Descending | Select -First 10 shows recent updates.

Quick check

Sources

• MITRE ATT&CK T1587.004: Exploits