Introducing PoshC2 v5.0

PoshC2 v5.0 is here and there are significant changes and improvements that we’re very excited to reveal!  There’s been a move to Python3, much improved documentation, significant functionality and quality of life improvements, and more.  Read on for a detailed description of it all!

Repositories

We have had a bit of a change around with repository names, as described here.

This brings us back to PoshC2 being the latest and greatest repository, and PoshC2_old being the obsolete repository.

Documentation

The documentation for PoshC2 has been completely re-written and updated, with emphasis on red team trade-craft when using PoshC2 and on extending and customising it to suit any situation or environment.

It will still be updated regularly, but there will be less focus on what all the different techniques are, and more on how to use PoshC2 itself. Check it out at https://poshc2.readthedocs.io.

Python3

PoshC2 has been completely updated to use Python3. With Python2 becoming End-of-Life in January 2020, it was quite an important change to make.

Posh Commands

Efforts have been made to abstract the potentially difficult nuances of setting up and using PoshC2 away from the user.  Remember having to change into the PoshC2 directory, setup and use a Python virtual environment, to avoid dependency version clashes with the rest of your system?  That’s a thing of the past.

The install script now installs a number of posh-* commands to your /usr/bin directory, before setting up the virtual environment ahead of time. These scripts then encapsulate the use of that environment for the user, allowing PoshC2 to be run and configured from any directory, and it will seamlessly use the virtual environment and other configurations behind the scenes.

For example, PoshC2 can be configured from any directory using your editor of choice by issuing:

posh-config

It can then be installed and run as a service simply by executing:

posh-service

Conversely so it can be stopped using:

posh-stop-service

The Implant-Handler can now be started using posh with a username which is used for logging purposes:

posh u crashoverride

…and you’re good to go.

Use of these scripts is recommended, as any further logic will also go into them and we will work to ensure that PoshC2 works seamlessly when they are used, while other techniques may not be maintained.

Prompt

PoshC2 now has an intelligent new prompt that can aid users when performing red teaming!

https://poshc2.readthedocs.io/en/latest/_images/autocompletions.png

This prompt has context-sensitive auto-completions, intelligently suggesting commands based on the current prompt, such as PowerShell commands in a PowerShell prompt and so on. A unique command history is stored per context, so you won’t have to scroll back through PowerShell commands on a C# implant.

https://poshc2.readthedocs.io/en/latest/_images/autosuggestions.png

In addition to this, the prompt features fish-shell-like auto-suggestions in dark grey text based on commands from that prompt’s history, so if you want to repeat or edit log commands you can complete the suggestion by pressing the right-arrow key or ctrl+e.

Combined with the help and searchhelp commands, we hope that this will allow users of PoshC2 to quickly explore PoshC2s functionality and enable veteran users efficiency and speed of operation for those crucial engagements.

SharpSocks

SharpSocks has undergone some significant improvements and integration into PoshC2. It started out as a standalone cmdlet that can be initiated from any PS session, but we have now fully integrated this so the users can be in any implant and type sharpsocks to get this going. A full separate blog has been written with all the changes for SharpSocks and can be found here:

Introducing SharpSocks v2.0

New Payloads

Several new payloads have been added out-of-the-box, including a DotNet2JS payload using James Forshaw’s DotNet2JScript technique, and a new C# payload for PowerShell Implants.

Sharp Implant Improvements

AMSI Bypass

.NET 4.8 introduced Antimalware scanning for all assemblies, including those loaded using Assembly.Load(byte[] bytes), which previously went unchecked and is used by our PowerShell-less C# implant to load C# executables and run them in memory.

This release features a new bypass-amsi command for the C# implant which will patch AMSI in memory and allow flagged modules to be loaded and executed.

Aliases

We fully appreciate that nobody has time to type out long commands over and over. To that end, we’ve streamlined the run-exe commands for the C# Implant. Now, instead of run-exe Seatbelt.Program Seatbelt all it’s just seatbelt all.

We’ve added aliases for all our favourite commands, but you can add your own in Alias.py. See the documentation for more details.

Lateral Movement Methods

In addition to integrating SharpSocks, we’ve integrated PBind, another great tool written by Doug McLeod. This is now full integrated into PoshC2 and users can type invoke-wmijspbindpayload with the relevant arguments to try and attempt execution on another endpoint using SMB named pipes. The default SMB named pipe for PoshC2 is jaccdpqnvbrrxlaf.

invoke-wmijspbindpayload -target  -domain  -user  -pass ''

In addition to the lateral movement command, PoshC2 will automatically create several payloads that are named PBind payloads. These, like the normal payloads, can be executed against a remote host in whichever technique you prefer to use; dcom, wmi, psexec, etc.

Once you have initiated the payload on a remote host, it will automatically open an SMB named pipe ready for connection. You must know the secret key, the encryption key and the pipe name to communicate, but we already have you covered for this as it tells you what commands to run to interact with the PBind implant:

If you want any other information on PBind, a previous blog covers the techniques in more details and the comms methods including a diagram.

https://labs.nettitude.com/blog/extending-c2-lateral-movement-invoke-pbind/

FPC script

Amongst the various scripts that are added to /usr/bin is the fpc (Find PoshC2 Command) script, added to aid in reporting. This script allows you to search for PoshC2 commands, filtering on keywords in the command, the command output and by user.

Credential management

We’ve improved the credential management in PoshC2, and now when you run Mimikatz’s logonpasswords, the credentials will automatically be parsed and stored in the database, and can be displayed or manipulated using the creds command.

Remainder

There’s also a myriad other improvements such as to logging, tracking file hashes on upload, UX improvements, internal modularisation and refactoring and module updates, with a lot more in the pipeline to come. Stay tuned on Twitter (@Nettitude_Labs, @benpturner, @m0rv4i) for the latest updates or join the PoshC2 slack channel by emailing labs at nettitude dot com.

Roadmap

There’s a lot planned for PoshC2 but the main upcoming features are detailed below.

Docker

The bad news is that support for any platform other than Debian flavours of Linux has been retired. While PoshC2 is written in Python3 and can be maintained to work across multiple platforms, we have instead elected to only support Debian-based distributions.  However, we are working to bring Docker support to PoshC2 to add the ability to run PoshC2 from a Docker container, allowing full and stable execution across any platform that supports Docker, including Windows and Mac OSX.

A docker branch has been created with a Dockerfile added in addition to a number of Docker commands that can be used to manage the containers, but this is still very much in an unstable format.

OpSec

One of the biggest concerns when running a red team engagement is operational security, and to that end we’re working on improving both the offensive side by making more of the inner workings of PoshC2 configurable, but also the reporting side by improving file upload tracking, hosts and users compromised and so on.

This will complement improvements to the HTML report and improve the OpSec and reporting side of things considerably.

Full changelist

The full changelist is below:

  • Added Harmj0y’s KeeThief to modules
  • Added RastaMouse’s Watson to modules
  • Added SafetyDump for minidumping in memory
  • Added file hashing when a file is uploaded
  • Rework imports to improve dependency management
  • Break up ImplantHandler into PSHandler.py, PyHandler.py and SharpHandler.py
  • Add ability to upload a file to an ADS
  • Update BloodHound
  • Pull out unpatched payloads into file for easy management
  • Add base64 encoded versions of the shellcode to the payloads directory
  • Add a configurable jitter to all implants
  • Update the notifications config if it is changed in the Config.py
  • Add NotificationsProjectName in Config.py which is displayed in notifications message
  • Add fpc script which searches the Posh DB for a particular command
  • Modify InjectShellcode logged command to remove base64 encoded shellcode and instead just log loaded filename
  • Add aliases for common sharp modules
  • Fix Shellcode_migrate payload creation
  • Start randomuris with a letter then proceed with random letters and numbers as e.g. msbuild errors if task name starts with a number
  • Fix issue with cred-popper and keylogger using same variable and conflicting
  • Add SCF files to the opsec command
  • Add posh commands on *nix for abstracting the use of pipenv and set up the env in the install script.
  • Move to python3 as python2 is EoL in 2020
  • Misc performance improvments, such as reduced cylomatic complexity and only processing the command once per input
  • Store creds in the DB, add ability to add creds/have them automatically parsed from mimikatz and add ability to specify use of a credId for some commands
  • Add create-shortcut command
  • Don’t show powershell one liner when domain fronting as it tries to connect directly
  • Added set-killdate command
  • Added posh-stop-service linux command
  • Updated Mimikatz
  • Added SafetyKatz
  • posh-config uses $EDITOR variable
  • New Sharp_Powershell_Runner payload compilation with mono
  • Added DotNet2JS Payload generation
  • Added get-computerinfo and get-dodgyprocesses to c# core
  • Misc small fixes
  • Updated help and readme
  • Add new prompt with intelligent autocompletions, autosuggestions and smart history
  • Log when a user logs on or logs off in the C2 server output
  • Add ability to broadcast messages in the C2 server output using the ‘message’ command
  • Add quit commands to Sharp and Python handlers
  • output-to-html renamed to generate-reports
  • Force setting of username for logging
  • Show Implant type at Implant prompt
  • Update User Agent string to match current Chrome
  • Added New SharpSocks
  • Addd * suffix for usernames for High Integrity processes
  • Added lateral movements to Sharp Implant (SMB/DCOM/WMI)
  • Add AMSI bypass for C# Implant
  • Updated PBIND hosts in opsec
  • Added invoke-mimikatz output from PBIND to be parsed
  • Updated PBIND to send stderror if the command does not work
  • Added remove-label for implants
  • Updated PSHandler to add DomainFrontURL to sharpsocks if in use
  • Updated RunAs-NetOnly
  • Added RunAs-NetOnly which uses SimpleImpersonation to create a token
  • Removed print statement on pbind-loadmodule
  • Updated pbind-command and pbind-module
  • Updated the pbind commands
  • Updated invoke-wmijspbindpayload
  • Added PBind payloads to PoshC2
  • Updated opsec error when username is None
  • Add output-to-html retired message
  • Add Matterpreter’s Shhmon
  • Updated ‘tasks’ command to add ImplantID
  • List PowerShell modules pretty like C# modules
  • Add new Sharp modules
  • Port the .NET AMSI Bypass to PowerShell
  • Updated Get-ScreenshotMulti to Continue if Screen is Locked
  • Correct Jitter time equation in PS implant
  • Print last commit and timestamp in header
  • Prompt improvements
  • Updated C2Server / SharpSocks Error responses
  • Updated HTML output
  • Update fpc.py to use virtualenv and only copy fpc to /usr/bin
  • Updated help
  • Expand on opsec no-nos
  • Update inject-shellcode help

Introducing PoshC2 v4.8 – includes C# dropper, task management and more! – Part One

We recently released version 4.8 of PoshC2, which includes a number of fixes and improvements that help facilitate simulated attacks. This is the first post in a series of posts that will include some of the details around the fixes and updates, alongside a number of other posts which will show some of the other cool features we have been working on in the background.

C Sharp (#)

As of PoshC2 version 4.6, a C# implant has been available. The main driver behind this implementation was to stay clear of System.Management.Automation.dll when an environment is heavily monitored and the EDR product can detect loaded modules inside a running process. Granted, not all EDR products are currently doing this, as it can create a hit on performance at the endpoint level, but its important to understand the OPSEC implications of running different C2 droppers.

This has been a work in progress since the release and is continually improving, and we believe this will be the way forward in months to come against advanced blue teams with a good detection and response capability across the organisation. Currently the implant is fully functional and allows an operator to load any C# assembly and execute this in the running process. This allows the user to extend the functionality massively because they’re able to load all the great modules out there in the wild, created by other infosec authors. The way this is loaded uses the System.Reflection namespace. The code can then be called using .NET reflection, which searches inside the current AppDomain for the assembly name and attempts to either run the entry point given or the main method of the executable. An example usage is as follows, for both run-exe and run-dll:

run-exe:

run-dll:

Task Management

One of the issues we’ve overcome in this release was around tracking tasks; there was no way to determine what output related to which issued command. This was largely due to the implant not using task ID’s that were tracked throughout the entire command process flow.

Typically, this was fine because you know what command you’re running, but when multiple people are working on the same instance, or if multiple similar commands are run, then it could be difficult to figure out what output came from which command. This also made tracking failed commands fairly difficult if not impossible to find. The following screenshots shows the output inside the C2Server and the CompletedTasks HTML file:

Figure 1: How commands were issued and returned against an implant

Figure 2: The old format of the tasks report

Furthermore, tasks were only logged in the database when the implant responded with some output. Now, tasks are inserted as soon as they are picked up by the implant with a start time, and updated with a completed time and the desired output when they return. This allows us to track tasks even if they kill the implant or error and never return, and to see how long they took. It also allows us to reference tasks by ID, allowing us to match them in the C2Server log and to only refer to the task by its ID in the response, decreasing message length and improving operational security. An example of the output is shown below:

Figure 3: The new task logging

The generated report then looks like this:

Figure 4: The new report format

User Logging

The astute amongst you will have noticed the new User column in the report above. Another improvement that has been made in relation to tracking tasks is user logging. Now when you start the ImplantHandler you are prompted for a username; it is possible to leave this blank if required, but when PoshC2 is being used as a centralised C2Server with multiple users it’s important to track which user ran which task as shown in the examples below:

Figure 5: You are now prompted for a username when you start the ImplantHandler

All tasks issued from that ImplantHandler instance will be logged as that user, both in the C2Server log and in the report.

Figure 6: If a username is set it is logged in the task output

Figure 7: The username is also logged for the task in the report

For scripting and/or ease of use, the ImplantHandler can also be started with the -u or --user option, which sets the username, avoiding the prompt:

python ImplantHandler.py --user "bobby b"

Beacon Timing

The way beacon sleep times were handled was inconsistent amongst implants, so now we’ve standardised it. All beacon times must now be in the format of value and unit, such as 5m, 10s or 2h. This is then displayed as such for all implant types in the ImplantHandler. As seen below, the fourth column states the current beacon time in seconds, whereas now we show only the output in the newer format.

Figure 8: The old beacon time format

Figure 9: The new beacon time format

Validation has also been added for these, so attempting to set an invalid beacon time will print a suitable error message and do nothing.

Figure 10: The validation message if an invalid format is set

We’ve also changed the implant colour coding so that they are only flagged as timing out if they haven’t checked in for a multiple of their beacon time, as opposed to a hard coded value.

Previously the implants would be coloured as yellow if they hadn’t checked in for 10 minutes or more, and red for 60 minutes or more. Now they are coloured yellow if they have not checked in for 3x beacon time, and red for 10x beacon time, granting far more accurate and timely feedback to the operator.

Figure 11: Implant colour coding has been improved so that the colour is dependent on the beacon time

C2Viewer

The C2Viewer was a legacy script used to just print the C2Server log, useful when multiple people want to be able to view and manipulate the output independently.

There were a few issues with the implementation however, and there was a possibility that it would miss output as it polled the database. Additionally, as this was an additional script, it added maintenance headaches for updates to task output.

This file has now been removed, and instead if you want to view the output in the same way, we recommend that you run the C2Server and pipe it to a log file. You can print the log to stdout and a log file using tee:

python -u C2Server.py | tee -a /var/log/poshc2_server.log

This output can then be viewed and manipulated by anyone, such as by using tail:

tail -f -n 50 /var/log/poshc2_server.log

This method has the added benefit of storing all server output. While all relevant data is stored in the database, having a backup of the output actually seen in the log during usage can be extremely useful.

Further details can be found in the README.md.

Internal Refactoring

We’re also making strides to improve the internals for PoshC2, refactoring files for clarity, and cutting cyclic dependencies. We aim to modularise the entire code base in order to make it more accessible and easier to maintain, including making changes, but as this is a sizeable change we’ll be doing it incrementally to limit the impact.

Conclusion

There have been quite a few changes made, and we’re aiming to not only improve the technical capabilities of PoshC2, but also the usability and maintainability.

Naturally, any changes come with a risk of breaking things no matter how thorough the testing, so please report any issues found on the GitHub page at: https://github.com/nettitude/PoshC2.

The full list of changes is below, but as always keep an eye out on the changelog as we update this with any changes for each version to make tracking easier. This is the first blog of a series of blogs on some additional features and capability within PoshC2. Stay tuned for more information.

  • Insert tasks when first picked up by the implant with start time
  • Update task when response returned with output and completed time
  • Log task ID in task sent/received
  • Add ability to set username and associate username to tasks issued
  • Print user in task information when the username is not empty
  • Improved error handling and logging
  • Rename CompletedTasks table to Tasks table
  • Method name refactoring around above changes
  • Pull out implant cores into Implant-Core.py/.cs/.ps1
  • Rename 2nd stage cores into Stage2-Core.py/.ps1
  • Stage2-Core.ps1 (previously Implant-Core.ps1 ) is no longer flagged by AMSI
  • Use prepared statements in the DB
  • Refactoring work to start to break up dependency cycle
  • Rename DB to Database in Config.py to avoid name clashes
  • Pull some dependency-less functions into Utils.py to aid dependency management
  • Fix download-file so that if the same file is downloaded multiple times it gets downloaded to name-1.ext name-2.ext etc
  • Adjust user/host printing to always be domain\username @ hostname in implants & logs
  • Fix CreateRawBase payload creation, used in gzip powershell stager and commands like get-system
  • Added ImplantID to Tasks table as a foreign key, so it’s logged in the Tasks report
  • Added Testing.md for testing checklist/methodology
  • Fix Get-ScreenshotAllWindows to return correct file extension
  • Fix searchhelp for commands with caps
  • Implant timeout highlighting is now based on beacon time – yellow if it’s not checked in for 3x beacon time and red if not checked in for 10x beacon time
  • Setting and viewing beacon time is now consistent across config and implant types – always 50s/10m/1h format
  • Added validation for beacon time that it matches the correct format
  • Fix StartAnotherImplant command for python implant
  • Rename RandomURI column in html output to Context, and print it as domain\username @ hostname
  • Move service instructions to readme so that poshc2.service can just be copied to /lib/systemd/system
  • Removed C2Viewer.py and added instructions for same functionality to readme just using system commands

Extending C2 Lateral Movement – Invoke-Pbind

Invoke-Pbind is a mini post exploitation framework written in PowerShell, which builds C2 communications over SMB named pipes using a push rather than a pull mechanism. Pbind was initially created to overcome lateral movement problems, specifically in restricted environments where the server VLAN could not directly talk to the user VLAN (as it should be in every environment). The tool was designed to be integrated with any C2 framework or run as a standalone PowerShell script.

Video Demonstration

If you just want to skip to the video tutorial, then you can find that here and at the end of this post.

The Problem: Segregation and Strict Firewalling

This is useful when you have compromised an organisation and have C2 comms over HTTPS, traversing the corporate proxy server out of the network from user’s workstations, but the target dataset that you are looking to obtain is located down server VLAN with a firewall restricting both inbound and outbound traffic. In that scenario, firewall rules are always going to allow for specific traffic to traverse over pre-approved services. The following diagram illustrates one such situation, where the environment allows limited services from the user VLAN to the server VLAN, but allows no ports in the reverse direction.

What options exist for C2 comms

The following are some options for C2 comms and their mitigations, resulting in failure.

Method Mitigation Result
Direct Internet Access Blocked by Firewall Outbound Fail
Traverse Through HTTP Proxy Blocked by Firewall Outbound Fail
TCP Reverse Shell Blocked or likely detected scanning for open ports Fail
TCP Bind Shell Blocked by Firewall Inbound or service running on open ports, no closed ports detected Fail
ICMP Blocked by Firewall Outbound Fail
Daisy over SMB in User VLAN TCP port 445 blocked from servers to workstations Fail
Daisy over HTTP in User VLAN Same as standard reverse all blocked ports Fail
DNS Authoritive DNS is only permitted by the Proxy server, thus not possible for C2 comms from the server VLAN. Fail

To be clear, at this point the problem isn’t about getting execution, it’s about having reliable C2 comms that afford the user output for all commands executed and to use the implant as a foothold or staging point to further attacks against servers in the restricted environment.

The Solution

“A named pipe is a logical connection, similar to a Transmission Control Protocol (TCP) session, between the client and server that are involved in the CIFS/SMB connection. The name of the pipe serves as the endpoint for the communication, in the same manner as a port number serves as the endpoint for TCP sessions. This is called a named pipe endpoint.” – https://msdn.microsoft.com/en-us/library/cc239733.aspx.

.NET has a class for creating and interacting with named pipes:

Where TCP port 445 is open into a server environment, we can overlay the SMB protocol and use a named pipe to share data between the workstation and server, providing a method for exchanging data (comms). The following commands make up the basis of creating a named pipe with an access rule that allows “everyone” access:

Since the days of abusing IPC$ with anonymous access (CVE-199-0519), and RID cycling your way to a plethora of goodies, Microsoft have said “no – though shall not pass” – non Microsoft direct quote. In a domain environment, any user can create a domain authenticated session to the $IPC share, which can then be piggy backed to gain access to the named pipe. Here is a simple script in PowerShell to create an authenticated session. One quick problem to overcome: While the ‘AccessRule’ applied to the pipe may look like it allows “everyone” access to the named pipe, this is not actually the case.

Interacting with a named pipe is also fairly straight forward as long as you know the data type of what is being read; as we create the server we know how to handle to pipe as shown by using a simple StreamReader:

Design

When we came up with Invoke-Pbind, the following principles were implemented.

Client/Server Model

To allow for inclusion in a C2 framework, two script blocks were created, client and server. The server starts and sets up the named pipe on a remote target (server). The client then connects to the named pipe and exchanges messages over TCP port 445 (SMB). The client runs through an existing C2 implant and by using script blocks and run spaces, it is possible to use the client non-interactively for better interaction with most C2 frameworks.

Token Passing

When sharing a common space such as a named pipe, it is imperative that messages exchanged between the client and server are not overwritten prior to being picked up by their counterpart. Control messages are used in combination with TRY and IF statements to create rules for when a client or server should read or write from the named pipe.

Security

During the generation of the script blocks, at run time, a unique key is generated and used to encrypt messages between client and server. Pbind supports AES 256 encryption. To initiate a connection to the named pipe from a client, a shared secret is also supported to stop tampering with the named pipe. If the client does not provide the correct secret, the named pipe will close.

Injection/Execution

There are two main methods included that inject the implant into target hosts. These are modified versions of Invoke-WMIExec and Invoke-SMBExec (credit to Kevin Robertson for these scripts); both scripts have been updated to support passing passwords, where previously they only accepted hashes for authentication. The implant is a self-executing script block that is passed as the payload. The script runs WMIExec by default but contains a switch parameter to invoke SMBExec:

To provide additional deployment flexibility the script also includes an exe method. This method uses CSC and Windows .Net automation DLL to compile the implant into an executable that can then be deployed and executed through any means.

NOTE: Creating a named pipe does not require administrator credentials so the executable can be run as a non-privileged user. On the other hand, WMIExec and SMBExec require administrator privileges.

The exe option continues to generate unique variables that are hardcoded into the executable, for use in cryptography and such like. The exe option can be used offline to create an executable implant and is not tied to an interactive session through a C2. To talk to the implant, the script supports a CLIENT option that is used to interact with a deployed implant, the options for which are provided when the implant is compiled:

This flexibility allows for the deployment through any means:

  • DCOM
  • RDP
  • Shared Folders
  • WinRM
  • SCCM
  • Anything……

There are a number of options that are configurable. If no options are selected, the script reverts to pre-set or randomly generated values. The following options are configurable:

  • KEY – Defaults to a randomly generated AES 256 Key – Allows for a key to be specified, commonly used in client mode.
  • SECRET – Defaults to random 5 character value – Allows for specific secret to be used.
  • PNAME – Defaults to random 8 character value – Allows for specific pipe name to be chosen.
  • TIMEOUT – Defaults to 60 second – Used to change the wait time for the client to connect to the Implant, used in slow networks.
  • EXE – Generates a stand-alone executable;
  • CLIENT – Runs the script in client mode to connect to a deployed Executable;
  • TARGET – used to specify a remote IP Address.
  • Domain/User/Password/Hash – used to provide credentials for authentication.
  • Domain2/User2/Password2 – used to map a drive to the target system, when a hash is being used as the primary authentication mechanism.
  • Dir – used in EXE mode to output the generate executable.
  • Automation – used in EXE mode, directory location of the Automation DLL.

Interaction

There are 3 main functions that have been created to interact with the implant from a client. The first and probably the most useful, especially when we introduce templates, is Pbind-Command. This simply registers a command in a variable that is read in by the client and passed to the implant (server) before being executed. A simple example is shown below:

Pbind-module c:\folder\powerup.ps1The second is Pbind-Module, which allows you to read in any other ps1 file and have it injected into memory on the implanted host. Pbind-Command can then be used to execute any of the functions in the ps1 script. This has a limitation and does not work well within a C2 setup, because all scripts have to be local to the client. In most cases the client is already running on a target workstation and would require all scripts to be uploaded to the client before being sent on to the implant.

Pbind-Squirt was a designed to help resolve the limitations of Pbind-Module. The idea for this function was to embed a number of scripts as base64 objects into the script that can then be called and auto executed into memory on the client. The only one that has been embedded is PowerUp, to assist with asset review on newly implanted hosts.

However, in practice neither Pbind-module nor Pbind-squirt were optimal and instead a new solution was constructed, called ‘Templates’. Effectively this was just a better way to interact with the Pbind-Command function. It was decided that by creating a number of small scripts which can automate tasks, it is possible to carry out similar ideas to Pbind-module and Pbind-squirt. Tasks such uploading mimikatz and extracting passwords, uploading PowerView and running queries or uploading invoke-SMBExec and attacking other machines, can all be scripted using a similar template to the one below:

The best way to see how the script runs is to download the script and have a go. The screenshot below shows a simple example of running the script locally under the context of another user, while also executing commands.

Video Tutorial

We have created a video tutorial to help illustrate the use of Invoke-Pbind.

Download

github GitHub: https://github.com/nettitude/PoshC2/blob/master/Modules/Invoke-Pbind.ps1

Python Server for PoshC2

We are delighted to announce the release of our PoshC2 Python Server, allowing cross-platform support.

Over the past six months we have been working on a Python server for PoshC2, which allows it to be run on almost any Unix or Windows based system that is capable of running Python. We have thoroughly tested the server on Kali, and Debian based Linux distributions without any issues. The server-side repository has been named ‘PoshC2_Python’ so as not to confuse it with the Windows PowerShell server version, ‘PoshC2’, which is still widely used in a client environment or enclave when needed. Update (12 Nov 2019): this is no longer the case. The repository names have been updated so that PoshC2 is where this version now lives.  PoshC2_old is for the legacy version. Here are a few of the main advantages we’ve identified of running PoshC2 via Python:

  • Removes the need for Windows
  • Team Collaboration
  • AutoComplete on the Implant Handler
  • GraphViz Visualisation
  • Lower CPU Utilization

Team Collaboration

The Python code enhances the flexibility of PoshC2. One of the main features is cross-platform support, therefore the server will run on both Windows and Unix based systems. The main feature of running the server on Linux is to enhance the team collaboration piece, which has always been limited via a Windows system. The Python server can be installed as a service; see the ‘Systemctl Service’ section below for more details on how to achieve this. It also allows multiple users to connect remotely and run their own implant handler to interact with each implant, while viewing the output from journalctl. Alternatively, the server session can be run from a screen terminal and multiple users can view the same screen session. The best results would be to run this as a systemctl service so it survives a reboot and will automatically re-start.

Almost all features have been ported over to Python from the server side, apart from the compiled executables that were ordinarily generated using .NET’s command line compiler csc.exe. However, instead of generating .NET binaries, we have introduced new template files that are written in C++ that can be modified and used as a template. See the ‘Templates’ section below for more information. This gives the user the ability to modify the template files, customize the binary, change the process the shellcode is injected into, the injection method, hardcode a domain name or any other additional functionality you can think of to enrich the dropper.

This is an example of the C2 server up and running. Similarly to PoshC2, the server window is usually viewed side by side to the Implant Handler to maintain consistency. The server will populate all the payloads only the fly, including the one liners, shellcode, HTA and macro files.

Systemctl Service

The PoshC2 server can now automatically be started as a service using systemctl within Linux. You can choose to either have this functionality enabled or not during the install; by default the service is not created, but it can be enabled by following the steps below. The advantages of having the C2 server installed as a service are endless, but most importantly if you are on a live engagement and the server for some reason fails or reboots, your C2 server will be resilient and bounce back once the system is back up and running.

To add the service, create the following file with the code in the block below:

#> vim /lib/systemd/system/poshc2.service

Once the file is in the correct location, the systemctl command will know how to enable the service, should you require this. To enable the service, run the enable command, followed by start, as shown below.

#> systemctl enable poshc2.service

#> systemctl start poshc2.service

You can also stop or restart the service if you need to change the config or re-run the server for any reason.

#> systemctl stop poshc2.service

#> systemctl restart poshc2.service

The best feature of running PoshC2’s python server as a service is the fact you can view the server output using the journalctl log. If you are running the server on an engagement with multiple users, it is very easy to share the output by running this command when you login via SSH.

#> journalctl -n 20000 -u poshc2.service -f –output cat

Reporting

While this hasn’t changed significantly since the first iteration of PoshC2, it’s one of the most important elements of the tool.  It will fundamentally assist in the SOC detection and response phase of your engagements, i.e. when assessing the response of the Blue Team.  It is, of course, also a professional requirement to have full logs of offensive activity.

One addition to the reporting section is the introduction of the opsec command which is in the pre-implant help. This will provide a list of all files uploaded to the system, including a unique list of hosts touched for reporting purposes.

The output-to-html now uses a GraphViz implementation which is still a work in progress, but aims to visually represent the compromise in action, including all hosts that are connected to the C2 server and how they are communicating back to the infrastructure. For example, if you have a host daisy chaining via an implant this will be displayed on the GraphViz output below. These files are generated when the output-to-html function is run within the pre-implant handler window. All icons are customizable via the output file that is generated or you can switch these out editing the files folder in PoshC2.

It should be noted that proxy aware implants and daisy payloads are still all functioning within the Python server and work the same way as in PoshC2. For more information on Daisy Chaining please refer to the documentation or the following blog:

Z:\Desktop\pyshc2.png

The HTML output has also been improved and now has some additional JavaScript that allows the commands to be searched and all output data truncated for easier viewing. The output can also be searched using the same method. If there are any additional reporting requirements you would like to see in here, please hit us up on Slack or Twitter.

Videos will be released shortly on how to get started with PoshC2, including customizing the Config.py file and editing the source files for better optimization.

Quick Install

To install PoshC2 on Ubuntu from a terminal, run the following:

curl -sSL https://raw.githubusercontent.com/nettitude/PoshC2_Python/master/Install.sh | bash

To get started, follow the instructions on the readthedocs webpage, which walk you through how to customize your install and have a better chance of not being detected within your engagement.

If you have any issues regarding crypto, this could be due to a dependency installation failure. The best way to get around this has been to create a virtualenv in Python and then install the requirements file manually for that virtualenv. For more information, read how to create a virtualenv in Python online.

Wine SharpSocks

But what about SharpSocks? Never fear, SharpSocks works with Wine! If you need to find out how to get Wine installed for SharpSocks, there is a file called Install_SOCKS that has step-by-step instructions on how to achieve this. For those who don’t know what SharpSocks is, the following blog post discusses our release of a SOCKS server for PoshC2in detail.

Templates

As previously mentioned, PoshC2 now has template files that can be optimized prior to starting the service. An example of why you might want to do this is environment detections such as domain name or user. The template files are created using C++; by default there is an executable that creates a file which migrates automatically, and one that stays in the same process.

Signtool

To reduce the likelihood of the binary files being detected, you could also sign the executables that are generated from PoshC2 by using a code signing certificate. This will add some legitimacy to the binary when calling out to the internet.

#> signtool.exe sign /f code_signing_cert.pfx /p password Posh64.exe

Delay

As part of the initial payload, the PowerShell script will attempt to execute. If the C2 Proxy or implant cannot reach the server, the process will wait for 300 seconds (5 minutes) and retry. If required, it will then wait for 600 seconds (10 minutes) and try one final time. This has been implemented as a backup in case your C2 infrastructure is locked down too securely and for some reason doesn’t accept the implant first time. This could be due to a number of environmental detections, including the external IP address. The implant could have passed the domain check but come from a non-whitelisted IP address. This will give you the opportunity to evaluate the IP address and add to the whitelist if this should have been part of the organisations external IP address range given to you. This can all be modified if the timings need to be increased for any reason; all of this code is in the Payloads.py file.

Autoloads

Autoruns have always been a great feature for us. There is nothing worse than having to tell the C2 tool to load the following PowerShell module before running the command when this can all be coded into the tool. PoshC2 has implemented a lot of these by default, but if you want to customize them you can amend the autoloads by editing the AutoLoads.py file and adding extra lines.

Modules

The philosophy of PoshC2 has always been to use a selection of amazing PowerShell cmdlets that have been written by others in the industry. The PoshC2 folder has a Modules folder where all the scripts are loaded from. You can simply add any PowerShell script that conforms to the PowerShell standard into this folder and load using the Implant Handler:

loadmodule Invoke-Mimikatz.ps1

Python Dropper

As you will notice, we have made a small start on the Python dropper to allow for Unix support. This has not been exhaustively tested, however, it is a start at making it possible to support execution on the likes of a macOS based system or similar. There is currently a requirement to have pycrypto on the box that is executing the payload but we are working on solutions to implement the crypto piece without requiring this dependency. Something along the lines of in memory module imports, or similar. If anyone would like to contribute to this side of the PoshC2, please don’t hesitate to get in touch.

A Python implant has limited features right now. Currently you can set the beacon timer and execute commands on the host.

PoshC2 Execution Tips

A pro tip for executing PoshC2 on a client device that is highly monitored and has PoshC2 v5 with script block logging, module logging and transcript Logging is combining the work Dave Hardy did with the PoSHBypass (including the authors of the bypass techniques) and the transcript logging bypass we put together using this gist code snippet:

The script block logging, Module Logging & AMSI bypass was put together here by Dave Hardy:

The Transcript Evasion technique was from here:

From an OpSec perspective, similarly to most C2 frameworks and adversaries, PoshC2 has some default IoCs that it is highly recommended you optimize to avoid detection. These items include:

  • Comms URLS
  • UserAgent
  • Use Domain Fronting
  • Change Default Migration Process (netsh.exe)
  • Change Default Persistence Methods
  • Template Files

When you start PoshC2 ,you have to optimize the Config.py file which will provide you a list of default URLs that can be used. These are publicly available and will most likely get signatured in time. To ensure you are providing the best chance of remaining undetected, you should optimize these URLs. This also goes for the UserAgent string. Prior to sending in any payloads, it is necessary to do reconnaissance against a target. This will often include techniques like web bugs or similar. This will give you a change to identify the default UserAgent for the target estate. This could range from IE11, Chrome, Firefox or even Edge. You should re-configure the UserAgent configuration to be in line with the corporate estate to merge into normal business traffic on the proxy.

As most of us know, domain fronting is the best form of hiding censorship when performing Red Teaming. Unless the organization is performing SSL inspection, there is no way this type of communication can be detected. If the organization is using SSL inspection, its best to use a site that falls into one of these two categories to have the best chance of going under the radar:

  • Financial Services
  • Health Care

Frameworks such as Cobalt Strike and Metasploit also have common indicators of comprise (IoC), such as ‘notepad.exe’ for Metasploit and ‘rundll32.exe’ for Cobalt Strike. PoshC2 has a similar default process that is used for migration; this is netsh.exe. When performing the default migration within PoshC2, e.g. running the ‘migrate’ command, it will always start the process netsh.exe unless directed by the user on the command line. It is highly recommended that you customize this option; the new PoshC2 ‘Inject-Shellcode’ or ‘migrate’ function also has the ability to spoof the parentpid. Note, this works on Windows 7 but has had some failures on Windows 10. Also, the default method for process migration was using the win32 API call ‘CreateRemoteThread’. PoshC2 now has the ability to use ‘RtlCreateUserThread’ which is not quite as widely used across C2 frameworks. This was largely due to the help from @uint_ptr, who is our in house Windows wizard!

You can use the migrate command with all of the above in mind as follows:

  • migrate -procpath c:\windows\system32\searchprotocolhost.exe -suspended -RtlCreateUserThread
  • migrate -procpath c:\windows\system32\svchost.exe -suspended -RtlCreateUserThread -ParentID 4502

From a logging and monitoring perspective, it is always good practice to migrate to a process that is expected to go out to the internet, e.g. Internet Explorer, Outlook, Lync or similar. If the client has an endpoint product that tracks process migration and history, going from netsh.exe out to the internet should be suspicious. Keep this is mind when selecting the process to migrate into.

Here is an example of parent process spoofing in Windows 7. The following command was ran to migrate the process searchprotocolhost.exe and set the parentid of explorer (pid: 432). Note, this was all done using a standard user account.

  • migrate -procpath c:\windows\system32\ searchprotocolhost.exe -suspended -RtlCreateUserThread -ParentID 432

Persistence is also another function that should be completely optimized. PoshC2 has some default persistence methods, however, these are likely to be highly signatured and should be changed accordingly. There are many methods of persistence you can use, depending on your privileges. COM Hijacking is highly recommended or WMI if elevated. DLL Hijacking is also fairly difficult to detect; if you want to create a custom DLL that can be used for DLL hijacking, here is a simple code snippet that can be used to launch another process when the DLL is attached, which is perfect for DLL hijacking.

AMSI Checker

A new feature we’ve added is an Anti-Malware Scan Interface (AMSI) checker. We have baked this into the core-implant module. This does a quick process check using PowerShell and determines if the amsi.dll is loaded into the core implant. If this module is loaded, it will notify you through the C2Server response and provide a way of unhooking this DLL.

The way we unhook this module is using the work Adam Chester (@_xpn_) put together on exploring PowerShell AMSI and logging evasion. The way this function works is by using C# to pinvoke various Win32 API calls to identify where a certain DLL is loaded and its export functions reside in memory. As we own the memory for our process, we can simply overwrite the code in memory, returning the same response as if the malware check was benign.

For visibility, it is possible to identify if PoshC2 is running in another process by using Process Explorer which comes as part of the sysinternals suite (https://docs.microsoft.com/en-us/sysinternals/). This allows you to see if any .NET assemblies have been loaded into the running process. If the process is in fact PoshC2, there is a known Indicator of Compromise when running the CLR v4.0.30319 because you will see a DLL loaded called ‘posh’. This does not appear in .NET version two, as shown in the examples below.

Python 3

In the not too distant future, this will be ported over to Python v3. Currently it’s only designed to work in version 2.7.

Conclusion

In conclusion, both the traditional Windows PoshC2 and the Python Server PoshC2 repositories will be actively maintained by various contributors.  We encourage you to use it, provide feedback and generally contribute to the project.  You can always grab the latest version from GitHub.

github GitHub: https://github.com/nettitude/PoshC2.