Adversaries may gather information about the software installed on a victim's hosts. MITRE lists this under Reconnaissance with platform PRE, last modified in September 2026. Details include types and versions, and the presence of components that suggest added defenses, such as antivirus and SIEMs.
The aim is simple. If an attacker knows which software and version you run, they can look up what is wrong with it.
How attackers use it
MITRE says collection can be direct, through active scanning such as listening ports, server banners, and user agent strings, or through phishing for information. Adversaries may also compromise sites and include content that collects host information from visitors.
The data may also be exposed in job postings, network maps, assessment reports, resumes, or purchase invoices.
MITRE adds a specific example: analyzing metadata from victim owned files, such as PDFs, documents, images, and sound files hosted on the victim's websites. Metadata may reveal software versions, configurations, or timestamps that point to outdated or vulnerable software, and the information can be cross referenced with known CVEs to find ways in.
Results can lead to more reconnaissance, to developing or obtaining capabilities, and to initial access through supply chain compromise or external remote services.
It is worth separating the two things attackers want from software information. The first is exploitability: a version with a known flaw is a candidate target. The second is defensive posture: knowing which antivirus or SIEM you run tells them what to avoid or work around.
MITRE's metadata example is the one most organizations overlook. A PDF that reads well can still carry the name and version of the tool that produced it, along with timestamps. Publish a hundred of those and you have described your office software in detail.
The sources MITRE lists, job postings, network maps, assessment reports, resumes, and purchase invoices, point at something else: the information leaves through people and paperwork, not through your servers. A line in a job posting asking for experience with a named product is a reasonable thing to write and a very clear signal to a reader.
How to detect it
MITRE notes that this activity may have a very high occurrence and false positive rate, and may take place outside your visibility, which makes detection difficult. Its advice is to focus on related stages of the adversary lifecycle, such as initial access.
MITRE adds that internet scanners may be used to look for patterns associated with malicious content designed to collect information from visitors.
Probing of banners and ports shows in perimeter and web server logs, as many requests from one source in a short period. Treat it as context, because internet wide scanning is constant.
You can also look at your own exposure the way an attacker does: fetch your public files and read their metadata, and read your own banners. What you find is what they can find.
A separate, more useful habit is inventory. If you know every package and version you run, a new disclosure takes minutes to match instead of days.
There are two defensive habits that help most. The first is to look at yourself first. Run the header and metadata checks above against your own public assets on a schedule and treat any version string as a finding.
The second is to measure your response time. When a new advisory lands for a component you run, how long does it take to know if you are affected? If the answer is days, the exposure window is set by your inventory, not by the attacker.
How to reduce the risk
- MITRE says this technique cannot be easily mitigated with preventive controls, because it is based on behaviors performed outside the scope of enterprise defenses and controls. Its guidance is to minimize the amount and sensitivity of data available to external parties.
- Strip metadata from files before publishing them. Most office and PDF tools have an export option for this.
- Reduce version detail in banners, headers, and error pages.
- Remove software and version names from job postings where they are not needed to hire.
- Keep a software inventory, including dependencies, and patch internet facing components first.
- Retire software you no longer use, so there is less to find.
A dependency inventory deserves a special mention here. Modern applications pull in many packages, and the version of each is software information that matters. The interactive demo below shows how an inventory is built and read.
If you also publish software, remember that your own manifests and release notes tell outsiders what you depend on. That is normal for open source and worth knowing for everything else.
Check your own environment
Two read-only checks. The first reads the metadata of a PDF you plan to publish, using exiftool on Linux or macOS.
exiftool report.pdf
Look at fields such as Creator and Producer. The second reads server headers from a site you own, using curl.
curl -sI https://yourdomain.com | grep -i -E '^(server|x-powered-by):'
Then ask:
- Do published files carry tool names and versions?
- Do headers reveal the framework and its version?
- Can we list every package and version in production?
For that last question, the free in-browser dependency scan at https://gold.safeguard.sh/scan needs no login, the file never leaves your machine, and it covers up to 100 dependencies. The Gold directory at https://gold.safeguard.sh is also available for looking up packages.
Try it yourself
A walkthrough of building an inventory of dependencies and reading it the way an attacker would.
Click through it at your own pace, or open it full screen.
Quick check
How can file metadata help an adversary?
It may reveal software versions, configurations, or timestamps that indicate outdated or vulnerable software, which can be matched to known CVEs.
Name two sources of software detail besides scanning.
Job postings, network maps, assessment reports, resumes, or purchase invoices.
Sources
- MITRE ATT&CK, Software (T1592.002): https://attack.mitre.org/techniques/T1592/002
