RSS Feed
« Black Hat USA 2014 | Main | Using Mobile Substrate with Android Applications »

Introducing Windows Exploit Suggester

February 22, 2017 Update

This post provides an update on two topics regarding Windows Exploit Suggester—a best usage guide and some minor updates/changes recently made to the script.

Exploit References

I’ve now added information about specific exploits (where applicable) directly in the command output. This data was always present for more recent vulnerabilities, but required the user to view the source of the Python script to find it. I’ve finally added this so that it can save a bit of time when looking for references to current exploits. This is the default, but it can be removed with the —quiet/-q flags.

Hardcoded MS11-011

Second, MS11-011 is now hard-coded to be ignored for the following versions of Windows. This is due to the bulletin database not being updated when the web bulletin was updated.
“V1.2 (March 18, 2011): Added Windows 7 for 32-bit Systems Service Pack 1, Windows 7 for x64-based Systems Service Pack 1, Windows Server 2008 R2 for x64-based Systems Service Pack 1, and Windows Server 2008 R2 for Itanium-based Systems Service Pack 1 to Non-Affected Software. This is an informational change only. There were no changes to the security update files or detection logic.”

Reduce Output

Moving on to some general usage. A couple things that create the idea of false-positives are that the script assumes EVERYTHING is installed on a Windows system. So, it will flag .NET vulnerabilities, Telnet, WebDAV, IIS, etc. even though they aren’t present in the system. This is the nature of parsing the database and one way to narrow this down is to use the —local/-l and —remote/-r flags to identify exploits that you actually care about and want to use.

Patch Validation

Finally, sometimes a client states they already have a patch installed. This is usually in reference to a specific bulletin, for example, MS16-075. Now we can actually just get a list of relevant security update numbers by using the -p/—patches flag.

$ ./ -d 2017-02-09-mssb.xls -p ms16-075
[*] initiating winsploit version 3.2…
[*] database file detected as xls or xlsx based on extension
[*] searching all kb’s for bulletin id MS16-075
[+] relevant kbs [‘3164038’, ‘3163018’, ‘3163017’, ‘3161561’]
[*] done

We can use these KB number to cross-reference with the patchlist provided in the systeminfo output to validate a false-positive.This still assumes that the output from the systeminfo command is accurate, and in reality this is not always the case. You can feed in the “wmic qfe list full” command output in with the —hotfixes flag to manually force a list of hotfixes that might otherwise not appear in the systeminfo output.

Any questions, let me know!

Introduction (July 11, 2014)

Privilege escalation is an art form that revolves around information gathering, and enumeration of the target host. The idea is to find the quickest, and easiest way to escalate from a local user account to that of an Administrator. A common method for escalating is using a known exploit to target a vulnerability exposed on the unpatched host. This method is probably the fastest, and with the right information and toolkit of precompiled exploits and Metasploit modules, it is a quick win during any engagement. 

Let’s assume you have access as a local user to a partially patched Windows 7 Service Pack 1 machine. Are there any public exploits available? Which one do you run? Which exploits work with 32-bit and 64-bit architecture? Are there any Metasploit modules available to gain that coveted Meterpreter session? These questions can all be answered by manually reviewing the missing patches, and comparing that to the public exploits. Unfortunately, that is exceedingly time-consuming and thus unrealistic, this is why I sought to automate the process.

After searching online for a Window’s “exploit suggester” tool, I was surprised to find that none existed! Without further ado, I introduce “Windows Exploit Suggester” or for short “winsploit”, a tool created to automate the privilege escalation exploitation process targeting unpatched systems. This script takes, as input, the Microsoft Security Bulletin Database which is available free to download and is updated constantly by Microsoft.

It also needs the “systeminfo” command output on a target Windows host. Typically a low-privilege user is able to execute the “systeminfo” command, and when assessing the patch levels of a target host, it can provide a wealth of information (including hotfixes applied!).

Finally, it cross-references the previous information to that of a static list of Metasploit modules and publicy available proof-of-concept exploits for each bulletin number. When this information is combined, the end result is the ability to quickly analyse whether or not a target Windows host is vulnerable to many publicly available exploits.

Setup & Usage

You can find this tool on GitHub under the Windows-Exploit-Suggester repository. The tool is written in Python 2.7 and requires the xlrd library (for Excel spreadsheet parsing). This is most easily installed using pip.

$ pip install xlrd –upgrade

Alternatively, it can be downloaded from the website directly ( I was unable to use the version in the Ubuntu 12.04 repositories as it was incompatible, so had to use pip directly. 

Once the dependencies have been met, we will download the Microsoft Security Bulletin Database using the —update flag. This flag just scrapes the bulletin database from Microsoft and saves it as a local Excel file and will serve as our local bulletin database.

Once we get the local database file downloaded, we will need some “systeminfo” command output from our low-privilege user. I am using an example build from a Windows 7 Service Pack 1 32-bit machine in this scenario. Once I’ve gathered this data, I’ll run the tool against it, and include the Microsoft Bulletin database file.

Looking at the raw output, there are plenty of exploits to pick from! We can weed through the client-side attacks, assuming we’re not interested in Internet Explorer bugs at this time, and focus in on MS13-053. This exploit is quite reliable, and is better known as the pprFlattenRec exploit ( The best thing about it is that it’s in Metasploit!

Everything this tool does could be done manually, but it has the ability to act as a quick solution when escalating privileges on a Windows host. I have found it helpful in many instances, especially when new bulletins come out and new Metasploit modules get released.

This tool also has the ability to tell you about any exploits possible about a target operating system. For example, lets say we want to know all of the public exploits available for a Windows 2008 R2 Server Itanium. This can be achieved with the —ostext flag, which is a loose representation of the operating system, service pack, and architecture (defaults to 32-bit).

This feature is really useful when you are able to fingerprint a target’s operating system and want to know if any Remote Code Execution bugs exist. Although not necessarily privilege escalation, it is a relevant feature to the tool.


As with any automated tool, there are always limitations. These are some that I have identified through the use of the tool and it’s capabilities.

1 DAY ONLY — Of course this relies on known bulletins, exploits, and bugs but for an unpatched host it is a quick-win that can speed up the effectiveness of privilege escalation. It requires an entry to be present within the Microsoft Security Bulletin database, and with unsupported software (XP), these entries won’t exist! 

FALSE POSITIVES — The command output also assumes that you have every feature in Windows. For example, it will flag vulnerabilities relating to IIS even if IIS is not present on the machine! It assumes that it is a fully-featured Windows installation with all services so some intelligent manual filtering will have to be made when looking for an exploit.

INACCURATE SYSTEMINFO — There is also the presence of “File 1” entries in the ‘systeminfo’ command output which will skew the results because it cannot detect the relevant hotfixes. If there are “File 1” entries, additional commands will have to be executed to gather the hotfix data (querying the system registry directly, or using wmic). Once this data is collected it can be fed into the tool using the —hotfixes flag.


In summary, targeting an unpatched host is but one method of privilege escalation, and this tool makes that process much faster for Windows hosts. Time is essential when performing assessments, so any edge can really help. Please feel free to contact me regarding any bugs, comments, concerns, or feature requests so that I can take a look at them and make the tool even better! 

Reader Comments (4)

There is error.

Traceback (most recent call last):
File "./", line 1140, in <module>
File "./", line 281, in main
wb = xlrd.open_workbook(args.database)
File "/usr/lib/pymodules/python2.7/xlrd/", line 370, in open_workbook
biff_version = bk.getbof(XL_WORKBOOK_GLOBALS)
File "/usr/lib/pymodules/python2.7/xlrd/", line 1323, in getbof
raise XLRDError('Expected BOF record; found 0x%04x' % opcode)
xlrd.biffh.XLRDError: Expected BOF record; found 0x4b50
July 12, 2014 | Unregistered Commenteroffsecguy
Your article has a typo:
TypoError in line 5: '...Windows 2007 Service Pack 1...'
Engine suggests replacing '2007' with '7'.

False positive? Please report that so we can fix that out!
July 12, 2014 | Unregistered CommenterTypoBot
@offsecguy, what version of python-xlrd are you using? I had to install it using pip and not the apt repository. If that doesn't fix it send me an email and I can take a look in greater detail.

@typobot, got it!
July 14, 2014 | Registered CommenterSam Bertram
Really love the idea of the tool. Some constructive criticism: try to get rid of that one dependency if it's possible to not use an excel file for Microsoft's bulletin and to add some intelligence to determine what features are on the Windows box, although I know this would be very difficult if you're not actually running on the target system. Also it seems like this tool doesn't support XP, so I think you should find a way to support it even though Microsoft may not have any bulletin information about it; the information has to be elsewhere. If you could implement these things, this tool would be even more awesome and useful. Keep up the good work.
July 15, 2014 | Unregistered CommenterLuke

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.