Signed Binary Proxy Execution via PyCharm

About the Project

Signed Binary Proxy Execution is a method of executing a command or executable by proxy of an another signed executable. This method can be leveraged by those in the offensive computing community to bypass defensive mechanisms. By leveraging an executable that has been digitally signed, the trust of that application is being used to perform a particular malicious action. This post explores leveraging Signed Binary Proxy Execution via Pycharm, a popular Python IDE.

Understanding The Landscape of Signed Binary Proxy Execution

There is a handful of LOLBINS that allow for this technique to be achieved. While not a LOLBIN, a perfect example of Signed Binary Proxy Execution is via PsExec. PsExec, a tool that allows for both remote and local code execution is often used for lateral movement and it’s also signed by Microsoft. Josh Abraham wrote an excellent blog post on leveraging psexec and several other Windows utilities which can be found here. There’s several Microsoft signed utilities that can be used, but what about beyond that? What’s on your desktop right now that could be used to indirectly execute code? This is what lead me to poking around at IDEs.

In IDEs We Trust

Achieving Execution

I’m a huge fan of JetBrains' IDEs and an active Python developer so naturally, PyCharm is installed within the Arch Cloud Labs ecosystem. Modern IDEs do a lot, from verbose debugging utilities to remote syncing and deployment; there’s a lot of power within an IDE. The real question is how much of said power are you using in your development environment? Are you pushing from dev-to-prod via their remote sync feature? Maybe that’s something best left to a CI/CD pipeline or perhaps you just prefer to use ssh/rsync/scp/etc… on the command line. Regardless, IDEs are packed with many a feature that can be abused so let’s explore how IDEs achieve this functionality and if it can be leveraged externally to the IDE.

A quick dir within the installation directory and filtering on the .exe extension revealed several binaries with some pretty interesting names. As shown below runnerw.exe, runnerw64.exe, WinProcessListHelper.

dir_list

By providing an argument of notepad.exe to both runnerw.exe or runnerw64.exe, notepad.exe is spawned as a child process.

spawn_notepad

As highlighted in the red box, a JetBrains signed application (runnerw64.exe) can launch another application. Going beyond this, it’s possible to chain multiple commands to achieve further execution. A PowerShell one-liner in combination with runnerw64.exe can download and execute a staged payload.

one_liner

The process explorer output below shows how noisy this particular example is on a host.

proc_explorer_one_liner

Now that we have our initial shell, it’s time to do some recon. Sure enough, PyCharm provides this opportunity out of the box. WinProcessListHelper.exe will perform the equivalent of tasklist as shown in the image below. list_running_procs

I intentionally ignored interpreters or run times that are shipped, as there’s nothing too unique about running a Python script from a non-standard location. Depending on the plugins and add-ons installed within an environment, there are endless possibilites that could be further explored for continuing the attacker’s kill chain.

Beyond The Blog

This is not a comprehensive review of the functionality that can be done by PyCharm, but rather a weekend project diving down a particular offensive technique. I’m sure there’s something I’ve missed or that can be explored more. Feel free to Tweet and tell me! I encourage you dear reader to go forth and explore to find what may lie in your own environment. Thank you for reading.