Adversaries may acquire information about vulnerabilities to use during targeting. A vulnerability is a weakness in hardware or software that could be exploited to cause unintended behavior. MITRE places this technique under Resource Development, and the platform is PRE, so it takes place before any intrusion.
This is the information step that comes before an exploit. It is also the one defenders can learn from most directly, because you read the same public databases.
How attackers use it
MITRE says adversaries may find vulnerability information by searching open databases or by gaining access to closed ones. They may monitor disclosures to understand the state of existing and newly discovered weaknesses.
There is usually a delay between discovery and public disclosure, and MITRE notes that adversaries may target the systems of organizations known to do vulnerability research, including commercial vendors, to get ahead of that delay.
Knowing about a weakness may lead an adversary to search for an existing exploit or to try to develop one. The outcome of this step is a shortlist of software worth attacking.
The separate ATT&CK entries for exploits and vulnerabilities reflect two stages. The vulnerability entry is about knowing; the exploit entry is about having something that works. Many attackers stop at the first stage and go looking for the second, or build it.
MITRE's mention of closed databases is worth noting. Some information is available only to paying members or to insiders. Compromising a research organization is one way to reach it, which makes vendors and researchers targets in their own right.
For defenders the important lesson is symmetry. The public databases that help attackers choose targets are the same ones you use to decide what to patch.
How to detect it
MITRE states that much of this activity takes place outside the visibility of the target organization, so detecting the research itself is difficult.
Its guidance is to focus on behaviors relating to the potential use of exploits for those vulnerabilities. That includes exploitation of public-facing applications, client execution, privilege escalation, stealth, credential access, and remote services.
A practical reading: assume anyone with internet access learns about a new flaw at the same time you do, or earlier. Your detection effort should sit on the exposed systems that run the affected software.
Since you cannot see the research, shift to the use. For each new high impact disclosure that affects your stack, check logs for exploit attempts from the date of disclosure. Probing often begins quickly after a public advisory.
Look for patterns that match the affected component: requests to a specific path, a specific header, or a specific parameter named in the advisory. Add a short alert, review it for a few weeks, then remove it when the issue is patched.
Where you build software, review dependency updates the same way. A disclosure in a library you use is a signal to check your own manifests.
Pay attention to how fast the first attempts arrive for your own stack. If your logs show probing for a flaw within a day of its disclosure, you have learned how much time you really have, and you can set your patch targets from that number instead of a guess.
How to reduce the risk
- Be honest about what is preventable. 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.
- Know what you run. A flaw announcement is only useful if you can match it to your software inventory the same day.
- Track disclosures for the components in your stack and decide an owner for triage, so announcements do not wait for a weekly meeting.
- Prioritize by exposure. A flaw in an internet-facing service matters before the same flaw on an isolated internal host.
- Reduce what is exposed in the first place, so fewer disclosures apply to you.
- Protect your own research and advisory data if you handle it, since MITRE notes that researchers are themselves targets.
The demo below shows how to watch disclosures against your own inventory. Pair it with the dependency scan mentioned above if you want to check a manifest quickly.
Finally, write down the response. For a new critical disclosure: confirm whether you are affected, decide whether to isolate or patch, apply, verify, and record. A written sequence turns a stressful day into a routine one.
A final habit is to subscribe to the advisory feeds for the vendors you rely on, and to route them to a shared mailbox or channel rather than one person. Disclosures do not wait for holidays, and a single reader is a single point of failure.
Check your own environment
- Do you have a current list of packages and versions for every production service?
- Who is notified when a new flaw affects something on that list?
- How many internet-facing services run software with a known fix not yet applied?
- Can you check a dependency manifest quickly?
For the last point, the free in-browser dependency scan at https://gold.safeguard.sh/scan needs no login, keeps the file on your machine, and covers up to 100 dependencies. The Gold directory at https://gold.safeguard.sh is another place to look up a package.
Try it yourself
A walkthrough of watching new disclosures against the software you actually run.
Click through it at your own pace, or open it full screen.
Quick check
Where do adversaries find vulnerability information, according to MITRE?
In open vulnerability databases, or by gaining access to closed ones. They may also target organizations that do vulnerability research.
What should detection focus on for this technique?
Behaviors that use the vulnerabilities, such as exploitation of public-facing applications, since the research itself is invisible to you.
Sources
- MITRE ATT&CK, Vulnerabilities (T1588.006): https://attack.mitre.org/techniques/T1588/006
