I am interested in how attackers manage to identify vulnerable versions of software on client machines, behind a large network or stand alone at home. I am not interested in portscanning at all, as the majority of software on a client machine will not be actively listening.

I am specifically interested in techniques to determine versions of vulnerable software on a client machine. For example, a given machine may have Adobe Reader and Flash, Windows Media Player, VLC and Java installed. It may be that all of these apps were vulnerable, or only one.

I would imagine it would be advantageous to an attacker to be able to determine which if any application was vulnerable, as launching attacks may alert the user and so I wonder how attackers may accomplish this.

I thought I recalled a scenario in which using a browser exploit the attacker was able to read file information from the local file system, which would do the trick.

What other avenues of attack could be used to gain this information directly or indirectly?

Could network management software which reports software versions be used maliciously? If so, what would be an example scenario?

In many cases of reported attacks a specific vulnerability was used, out of all the possibilities. I don't think attackers were that lucky as spamming a hundred attacks would raise attention and perhaps be picked up.

I would think there is some methodology for detecting various versions of software, perhaps without detection. This would also be true for drive by download attacks....where there may be 30 different attacks but instead of the page simply loading all and trying its luck can load an appropriate attack. Or, is it actually more common for such sites to spam as many attacks as they can without caring if media players and pdf readers randomly open and display an error on the client machine?

Any insight or sources on this are much appreciated.

  • Are you talking about targeted attacks to a specific network, or just malware serving websites and common 'exploit everyone' techniques used to create botnets etc?
    – john
    Jun 2, 2011 at 23:17
  • Hi @John, both. I guess it comes down to an unsophisticated attack does not need to know versions and will simply spam exploits, while a sophisticated attack may use social engineering, information leakage or a stepping-stone exploit to determine file versions before an attack. Jun 3, 2011 at 1:25
  • I disagree with the term unsophisticated and sophisticated, as mass-attacks use pretty sophisticated 0day exploits usually, but see my answer below.
    – john
    Jun 3, 2011 at 6:10

6 Answers 6


In the typical case (which is not targeted attacks), the attacker does not need to know the versions of your software. The common, unsophisticated attacker, is renting or has bought an exploit-kit, such as zeus, crimepack, eleanor or other.

These 'kits' typically come with zero-day exploits inside. They work by creating a web server, a php page on some random host, that just serves malware and exploits the victim's browser or his java or his flash or downloads a pdf and exploits his pdf reader etc.

By merely clicking on the link and browsing to the affected page, or downloading and running a pdf/doc/xls file, the handling application is exploited and the attacker drops his executable on the host (which can be a botnet client or a fake antivirus program or anything).

The php page created by the exploit kit (or other tools, even metasploit), just tries out all or any of the exploits provided in the kit that you choose. One of them will work, depending on how updated your subscription services to the malware kit is.

All the above are not the best method for targeted attacks but can still work. In the targeted attack scenario, an information gathering phase will be done before the attack, where the attacker will try to determine things like software running on the hosts and the versions, by using leaked information, from a large amount of sources, such as browser fingerprinting, emails etc.


There are a multitude of ways that people and applications leak information about software versions.

If you can see documents that people post or share, the document format typically explicitly or implicitly identifies the version of software that produced it. People post bug reports and questions on forums asking for help with software.

If you can get them to visit your web site, you'll get a huge amount of information about their browsing environment which is highly correlated with other software they use.

There are programs that report on software version information, either for enterprise security management, or for popularity contests, or the like.

And you can often just guess, based on knowledge of other software they use, when they got a new computer, what industry they work in, etc.

Finally, much malware is designed to attack multiple versions. And even if it isn't, the cost of trying an exploit is often so low, that people just do wholesale attacks (like spam), just hoping to find a vulnerable client. That is probably the most common approach in real life, outside of sophisticated spearfishing attacks.

  • Thanks for your answer Neal. I would have thought spamming different exploits would be inefficient as it may alert the user? Can you expand on programs that report software versions information and how they may be used in an attack? Jun 2, 2011 at 15:39
  • 1
    @sonny My pleasure. I note that your question is very broad, so my answer is very broad. I do suggest that you get more specific in your question (starting by just incorporating the hints you've given in comments already), then we can address them in the answers. E.g. you didn't note any concern with alerting a user. Please expand on what your actual goal is.
    – nealmcb
    Jun 2, 2011 at 16:09
  • Hi Neal, I will edit my question to be more specific, thanks. Jun 2, 2011 at 16:19
  • question edited to be more precise Jun 2, 2011 at 22:58

Before performing an active scan of resources I tend to look on the Job boards and identify developer positions that are open. Not always, but often they will list the specific version of a software suite in use. HR folks can be pretty clueless when it comes to this, and will often want "as much detail as possible" when making a requisition.

Further, if the target uses third parties for resourcing you can often get even more information. Believe it or not but I have been able to identify upwards of 30 applications before, while sitting in the lobby, before beginning an engagement with nothing but an ipad and a web browser.

Once you've gone this far you can start profiling likely vectors and investigate possible exploits etc. If the organization is looking to hire an AV admin or security tools person you might even get lucky enough to know what kind of defenses your target has for targetting in your lab before beginning the engagement.

Ideally before you even show up on site you can have a bag of tricks you know is likely to get you in quietly and escalate to a privilege level that will demonstrate the need for a better security posture. Worst case, you trip an IDS you didn't know was there and the hammer comes down, demonstrating the security is "adequate" for someone with your limited timeline.

  • Hi Ori, could you go into more detail on your second paragraph? Cheers Jun 2, 2011 at 17:10
  • Essentially you'll see things like "Looking for a Java Developer with recent Websphere background" if the HR department has any awareness of security. If they Don't you'll see things like "Looking for a Java Developer with Websphere 6.0 and 6.1 experience for a 7.0 upgrade. Plus if the developer has worked on Redhat 5.1 platform." Third party hiring agencies tend to be particularly bad in my experience and provide descriptions closer to the latter than the former.
    – Ori
    Jun 2, 2011 at 17:13

I'm not sure actually which kind of attack you are talking about. But most time it's specific to the exploit. For example there are many remote internet browsers exploits for different ones, but metasploit can run a simple web page, that can identify which browser client used, (Firefox, Chrome, IE ..) and run appropriate exploit. But if you're talking about local BOF exploits, DLL Hijacking etc, attacker doesn't actually knows, if victim will use vulnerable app to open file, but there are still enough chance to exploit if popular software exploit is used.

  • Well ignore the browser for a second...let's say a machine has Windows Media Player, MS Office, VLC, and Adobe Flash and Reader installed. All have had exploits in the past, but if all are up to date with patches should be fine. VLC had a vulnerability prior to versions 1.1.9 that would allow arbitrary code execution...going after the adobe products would be a better bet, but if there was a way to determining that VLC <= 1.1.9 was installed, the attacker would surely go for that. Jun 2, 2011 at 9:00
  • As I wrote above, with local BOF exploits, IMHO there is no way to remotely determine which software and version does victim use, if software doesn't listen to any port, or send any packets. You need something to access remotely. But that's software independent, maybe users use multicast streams with VLC that will help you to determine version or you can use social engineering. I hope you get the point.
    – Tornike
    Jun 2, 2011 at 12:28

Nmap makes this pretty easy. Quick summary of the relevant option from: http://nmap.org/book/man-briefoptions.html

Nmap 5.51SVN ( http://nmap.org )
Usage: nmap [Scan Type(s)] [Options] {target specification}
  -sV: Probe open ports to determine service/version info
  --version-intensity <level>: Set from 0 (light) to 9 (try all probes)
  --version-light: Limit to most likely probes (intensity 2)
  --version-all: Try every single probe (intensity 9)
  --version-trace: Show detailed version scan activity (for debugging)

SEE THE MAN PAGE (http://nmap.org/book/man.html) FOR MORE OPTIONS AND EXAMPLES
  • 1
    Well no, nmap isn't useful at all. nmap is useful for determining versions of software listening on ports, but as I say in my question I am interesting in how attackers determine version of vulnerable software not listening on ports. Jun 2, 2011 at 8:57
  • If an app isn't listening on a port, it isn't visible directly. You can infer application usage from nmap info, or from publicly posted information (this is often a good way to identify a target) - another option is to exploit the externally listening app and then escalate from there.
    – Rory Alsop
    Jun 2, 2011 at 9:14
  • I excluded portscanning from my question, as I am interested in the indirect ways to determine versions of software on client machines. It is possible with various methods and I am hoping for an answer that may enumerate them, at least in part. I don't mean to be rude, but portscanning is completely irrelevant to my question. Jun 2, 2011 at 11:30
  • 1
    Okay - you will find though, that from an external perspective (excluding physical access) your route in has to be through applications/services which are listening on ports... just sayin'
    – Rory Alsop
    Jun 2, 2011 at 11:35
  • 1
    Rory, you did not read my question. I excluded portscanning, and was talking about applications that do not listen on any port. My question is about determining software versions indirectly or perhaps by using some other more immediate exploit to do so, or using the methods Neal mentioned. I understand you have been on the site a lot longer and no doubt have more experience, but your reply and continued insistence comes across as condescending and implies you did not read the question. Ports or portscanning are irrelevant to my question. Thanks. Jun 2, 2011 at 16:58

Another way to look at this issue is that companies need to be able to react quickly when an application has a vulnerability. This requires that the IT department have the ability to definitively track installed applications, components, and patches using automation and standard tools. There are industry efforts to standardize on software asset tags (19770-2) which are XML files installed with an application, component, and/or patch that identify the installed software, and in the case of a component or patch, which application they are a part of. The tags have authoritative publisher information, version information, file listing with name of the file, secure hash of the file, and size, that can be used to corroborate that the installed application is on the system, and that the binaries have not been modified by a third party. The tags are digitally signed by the publisher.

When a vulnerability is known, IT departments can use their asset management software to immediately identify the systems with vulnerable software and can take steps to update the systems. THe tags can are part of the patch or update can be used to validate that the patch is installed. This way IT departments can leverage resources such as NIST's National Vulnerability Database, as a feed into their asset management tools so that as soon as a vulnerability is posted by a company to the NVD, the IT department can immediate compare the new vulnerabilies to their up-to-date software inventory.

There is a group of companies working via an IEEE/ISTO non-profit called TagVault.org (www.tagvault.org) with the U.S. government on a standard implementation of ISO 19770-2 that will enable this level of automation. At some point, these tags conforming to this implementation will likely be mandatory for software sold to the U.S. government at some point in the next couple of years.

So in the end, it is a good practice to not to be public about which applications and specific versions of software you are using, but it may be difficult as pointed out earlier. What you want to make sure is that you have an accurate, up-to-date software inventory, that it is regularly compared against a list of known vulnerabilities such as NIST's NVD, and that the IT department can take immediate action to remdiate the threat. This along with up-to-date intrusion detection, virus scanning, and other techniques to lock down an environment will at least make it very difficult for you environment to be compromised, and if/when it does, that it will go undetected for a long period of time.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .