Posts

Detecting PoshC2 – Indicators of Compromise

As a counterpart to the release of PoshC2 version 6.0 we are providing a list of some of its Indicators of Compromise (IoCs), particularly as used out-of-the-box, as well as some other effective methods for detecting it in your environment.

We also introduce the new PoshC2 Detections GitHub repository at https://github.com/nettitude/PoshC2_IOCs that will be continually updated as development continues, in order to assist blue teams with detecting PoshC2, particularly when used by less sophisticated attackers that do not alter or configure it to change the default IoCs. We encourage the community to contribute to and help update and improve this repository.

It is worth noting that PoshC2 is open source, so while these are IoCs for PoshC2 if used it its default state, ultimately it can be altered either through configuration or by changing the source code itself. The default configuration is subject to change, however where possible the location of that value is pointed out to the reader in order to allow these values to be monitored and updated, in addition to providing the GitHub repository.

Communications

One way to detect PoshC2 is to focus on the communications. Compromised hosts have to communicate with the C2 server somehow in order to pick up tasks and return task output. This is unavoidable and PoshC2 can currently only do this through the use of HTTP(S) requests.

That isn’t to say this this makes it easy to detect; a huge amount of HTTP traffic is present in most environments and the flexibility of the protocol allows for traffic to be hidden and routed through legitimate websites using techniques such as Domain Fronting and reverse proxies.

An example of HTTP comms when domain fronting.

An example of HTTP comms when domain fronting.

Something very helpful for catching C2 communications is SSL Inspection. By being able to inspect SSL traffic leaving the perimeter, the contents of that traffic can be checked and statistics acquired for detecting C2 communications. Without this, network defenders are largely blind, particularly against domain fronted communications which travel via legitimate third-party websites.

If SSL Inspection is implemented then the HTTP traffic can be viewed, and while PoshC2 encrypts the contents of the HTTP bodies, the HTTP URLs and headers can still be viewed.

URLs

PoshC2 has two different ways of generating URLs to use for communications. Operators can either use a static list of URLs or provide a wordlist from which random URLs will be generated, and these files are stored at resources/urls.txt and resources/wordlist.txt respectively, with the static URL list being the default option. These URLs are then loaded into the database when the project is first created, and a random URL is chosen by each implant each time it beacons. The default URL list is below:

While these URLs were originally copied from legitimate requests, if you see several of them being repeated to a site, particularly if they do not seem relevant to that site and if the response does not make sense, then it could be PoshC2 beacon traffic.

HTTP Responses

PoshC2 also has static HTML responses that it responds with. The default is six HTTP 200 responses and one 404 response. These are stored in files at resources/responses/ and also loaded into the database when the server is first created. The server responds with a random 200 response to POST requests that do not error or require a specific response, and with the single 404 response to all unexpected URLs or when the C2 server errors. Other responses return context relevant data, such as tasks, implant code and so on.

This static HTML file then at resources/responses/404_response.html is an IoC and if returned from a webserver that you are investigating is suggestive of PoshC2. Similarly, the 200_response* files in the same directory are IoCs if returned by POST requests.

Note however, that it is recommended that operators change these files before creating a PoshC2 project, as is the use of a C2 proxy, so as with the other indicators the absence of this particular response is not unexpected for a PoshC2 installation.

SSL Certificate

PoshC2 by default creates a self-signed certificate for its HTTP server, the values for which are stored in poshc2/server/Config.py file. These values are not in the ‘normal’ configuration file config.yml and are less documented and are therefore harder to change.

An experienced operator will not expose their C2 server to the internet, but will instead use a proxy server with a valid certificate and filter firewall traffic to the C2 server that is not from that proxy, however if these steps are not taken and a certificate with the below values is presented then it is another strong indicator that PoshC2 is in use, likely by less sophisticated adversaries.

The issuer data can be viewed using Chrome and the default values suggest this is a PoshC2 server.

The issuer data can be viewed using Chrome and the default values suggest this is a PoshC2 server.

JA3 Signatures

Another method for signaturing C2 traffic without SSL Inspection is to fingerprint the Client Hello packet that initialises the TCP connection. The specific bytes that make up the packet are dependent upon the type of connection being formed and the underlying packages and methods used to do so.

As these packets are sent before encryption has been established they are cleartext and can be intercepted and read. It turns out that the packet contents are quite unique and can be fingerprinted. Salesforce have an excellent blog post on JA3 fingerprinting, but essentially the details are extracted from the packets that make up this TCP handshake and hashed to create a quick and easy signature, that can be used to identify not only that PoshC2 is in use, but also the specific implant type.

The current Windows 10 PoshC2 signatures are below:

PowerShell: c12f54a3f91dc7bafd92cb59fe009a35

Sharp: fc54e0d16d9764783542f0146a98b300

JA3 fingerprinting has been incorporated into security products such as Splunk and Darktrace to provide quick and easy identification of C2 traffic, and can be utilised with these fingerprints. These fingerprints are available and will be maintained in the PoshC2 Detections GitHub repository.

Telemetry

Another mechanism for detecting C2 traffic, with or without SSL Inspection, is through the use of telemetry.

PoshC2’s default values for beacon time and jitter in the config.yml file are 5 seconds and a 20% jitter, as can be seen below, which is both a fast beacon rate and a small jitter, making it relatively easy to detect using this method.

With these values the implants are going to beacon every 4-6 seconds by default, with an average of 5 seconds.

After capturing some traffic, filtering by the C2 server host and only checking TLS Client Hello packets, we can see that the TLS connection is created roughly every five seconds, confirming what we expect.

We can see the difference between each session initialisation is between 4 and 6 seconds.

We can see the difference between each session initialisation is between 4 and 6 seconds.

By exploring this small sample of data, we can determine that the average time between the requests is 5.05 seconds, with a standard deviation of 0.81 or 16%, close to the 5 second beacon with the 20% jitter we expect from PoshC2’s defaults.

Security products that can provide telemetry data, e.g. Splunk can be used to detect C2 traffic in this way by checking for repetitive beacons at a relatively fixed frequency, whether it’s at the above defaults for PoshC2 or at any frequency, given that it is configurable.

PowerShell Implant

PoshC2 has three implant types; PowerShell, C#, and Python, with the latter being a lightweight implant type mostly intended for compromising *nix hosts.

The PowerShell Implant runs by loading System.Management.Automation.dll, the engine behind PowerShell.exe, into the desired process and executing PowerShell commands directly using this DLL.

The PowerShell implant supports full PowerShell execution from any process (here netsh.exe) by loading System.Management.Automation.dll.

The PowerShell implant supports full PowerShell execution from any process (here netsh.exe) by loading System.Management.Automation.dll.

While this does not utilise PowerShell.exe, bypassing many restrictions and controls, it is still subject to PowerShell specific constraints such as Constrained Language mode and ScriptBlock logging. The latter, in particular, can be used to detect PoshC2 and any other malicious PowerShell commands, whether via PowerShell.exe or otherwise.

Note, however, that ScriptBlock logging was only enabled in PowerShell v5.0 and above, so if PowerShell v2.0 is available on the target then a downgrade attack can be performed and PowerShell 2.0 used, bypassing Constrained Language mode, ScriptBlock logging, AMSI and other controls added in v5.0.

PS Logging

Enabling ScriptBlock logging and Transcript Logging for PowerShell allows logging of processes running PowerShell commands.

There are multiple IoCs here, not least that the Host Application is not PowerShell.exe, as should be expected, but instead netsh.exe.

PowerShell transcripts provide valuable information. Alerting on Host Applications that are not PowerShell.exe is a good way to find PowerShell implants from any C2 framework.

PowerShell transcripts provide valuable information. Alerting on Host Applications that are not PowerShell.exe is a good way to find PowerShell implants from any C2 framework.

Similarly in the Event Viewer for ScriptBlock logging:

PowerShell ScriptBlock logging can reveal a wealth of information, here including the beacon URLs for PoshC2 and again netsh.exe as a host process.

PowerShell ScriptBlock logging can reveal a wealth of information, here including the beacon URLs for PoshC2 and again netsh.exe as a host process.

This also includes the ‘command line’ of the ScriptBlock being executed, which includes the beacon URLs from which a random element is being chosen, therefore listing all the C2 URLs that are in use by this implant.

Aside from the wealth of information ScriptBlock logging provides for any threat hunter, an event command line specific to PoshC2 that can be used to identify the PowerShell implant is below:

The $ServerClean variable is specific to PoshC2 and a clear IoC.

The $ServerClean variable is specific to PoshC2 and a clear IoC.

CommandLine= $ServerClean = Get-Random $ServerURLS

This ScriptBlock is part of the beaconing process and will be repeated frequently in the Event Viewer making it easy to identify.

System.Management.Automation.dll

As mentioned earlier, the PowerShell implant does not function by invoking PowerShell.exe, but instead by loading System.Management.Automation.dll into the implant process.

This means that this is an IoC, and if we find a process that should not have this DLL loaded, particularly if it is an unmanaged code binary (so not .NET) then it is highly likely that this is a process that has been injected into by a PowerShell implant, PoshC2 or otherwise.

System.Management.Automation.dll, the engine behind PowerShell, is a .NET library.

System.Management.Automation.dll, the engine behind PowerShell, is a .NET library.

netsh.exe is a C++ binary and should not be loading .NET libraries.

netsh.exe is a C++ binary and should not be loading .NET libraries.

We can see this DLL loaded into an implant process using Process Hacker:

System.Management.Automation.dll loaded into netsh.exe.

System.Management.Automation.dll loaded into netsh.exe.

Similarly we can view the .NET Assemblies in the process:

We can view the .NET Assemblies in the netsh.exe process and see PowerShell is loaded.

We can view the .NET Assemblies in the netsh.exe process and see PowerShell is loaded.

This tab shouldn’t even be present for a genuine netsh.exe process as it is unmanaged code!

The module is not loaded in a genuine netsh process and the .NET tabs are not available.

The module is not loaded in a genuine netsh process and the .NET tabs are not available.

An operator can be smarter about their migration by injecting into .NET processes, however it is still unlikely that a legitimate process (that isn’t PowerShell.exe) would load System.Management.Automation.dll, so this is a great IoC to look out for in your environment.

This can be implemented at scale by searching for loaded modules in an EDR product, for example in CarbonBlack with a query of:

modload:System.Management.Automation* AND -process_name:powershell.exe AND process_name:powershell_ise.exe

This searches for process with System.Management.Automation.dll or System.Management.Automation.ni.dll (the Native Image version) loaded into a process when that process is not PowerShell.exe or PowerShell_ISE.exe. Other legitimate exclusions may need to be added for your particular environment.

Here we can see various processes that have loaded System.Management.Automation.dll into memory that are likely implants.

Here we can see various processes that have loaded System.Management.Automation.dll into memory that are likely implants.

C# Implant

The C# or Sharp implant is PoshC2’s ‘next gen’ implant, written (unsurprisingly) in C#. The key difference from a detection perspective is that this implant does not require loading System.Management.Automation.dll in order to function. Most of the functionality of the C# implant is custom-written and while it can load System.Management.Automation.dll in order to execute PowerShell, this is an operator decision and is by no means necessary.

A similar process to the above can be applied, but is a little harder to implement. .NET processes load the mscoree.dll library which is the core library behind the .NET CLR (Command Language Runtime), so again any unmanaged code processes that are loading this library could have been migrated into. The issue here is finding these processes, as it’s not as simple as searching for just ‘module loaded and process name is not powershell.exe’.

A blacklist can be created of common target processes that are unmanaged, always available and should not be loading the .NET runtime, and these can be monitored, as well as noting this during manual triage.

Implant loads mscoree.dll if it is not already present in the process – another IoC if the process is supposed to be unmanaged.

A C# implant loads mscoree.dll if it is not already present in the process – another IoC if the process is supposed to be unmanaged.

Note that the PowerShell implant will also load this library as it is also a .NET process, however the presence of System.Management.Automation.dll marks it as an implant that can run PowerShell.

The C# implant has the ability to load compiled binaries into memory over C2 and run them, which is extremely powerful. There are indicators of this however, as a new virtual runspace is created for each module and their namespace is listed in the AppDomain to which they are loaded.

Viewing the .NET Assemblies in Process Explorer or Process Hacker for example then reveals what modules have been run.

In the C# implant loaded modules have their namespace visible in the AppDomain, making it clear what has been loaded into the implant.

In the C# implant loaded modules have their namespace visible in the AppDomain, making it clear what has been loaded into the implant.

Above we can see the Core and dropper_cs modules that make up the core functionality of the C# implant, as well as some native modules from Microsoft that are required to run. These modules will always be present in the PoshC2 C# implant and are a clear IoC. We also see Seatbelt and SharpUp, two common C# offensive modules from SpectreOps, and we can surmise that they have been on the target.

In General

Migration

We have used netsh.exe as the example implant process in this post and that is for a good reason. The default migration process for PoshC2 in the C# and PowerShell implants is C:\Windows\System32\netsh.exe, so when the migrate or inject-shellcode commands are used and a specific process ID or name is not set, then a new netsh.exe process is spawned and migrated into.

This itself is a common IoC for PoshC2, as netsh.exe is not typically frequently run in environments, and certainly not on most end user’s hosts. Therefore, if there is a sudden uptick in the number of these processes being run in the environment or if several are running on a host then it could be worth investigating.

Persistence

PoshC2 has three quick persistence commands available to the PowerShell implant. Each of these installs a PowerShell.exe one liner payload to the registry in the key at HKCU\Software\Microsoft\Windows\CurrentVersion\themes with a name Wallpaper777, Wallpaper555 or Wallpaper666, depending on the command being run.

This payload is then triggered by either:

  • A registry key at HKCU\Software\Microsoft\Windows\CurrentVersion\run with the name IEUpdate
  • A Scheduled Task, also with the name IEUpdate
  • A shortcut file placed at %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\IEUpdate.lnk

All of these can be alerted upon and used to determine that the adversary using PoshC2, in addition to alerting on the invocation of PowerShell.exe with encoded parameters, and so on.

Binary payloads

Some of the more common payloads that are dropped on targets are the PoshC2 executables and DLLs that can be run using rundll32.exe.

For the DLLs, there are different versions for PowerShell and Sharp implants across versions 2 and 4 of PowerShell and x86 and x64 bit architectures, however all the DLLs have a single entry-point common to all: VoidFunc.

All the DLL payloads have the same single entry point of VoidFunc.

All the DLL payloads have the same single entry point of VoidFunc.

This entry-point is hard-coded in PoshC2 and cannot be changed without hacking the compiled binary itself.

For the common executable and DLL payloads we’ve also added Yara rules for detecting them. These are based on signaturable parts of the binaries that will not change across different installs of PoshC2, for example with different comms options. These are also available in the new PoshC2 Detections GitHub repository.

In Summary

We’ve looked at a few different detections for catching PoshC2 when used out-of-the-box. Using these in your environment will help protect against the less sophisticated users of PoshC2 in addition to further understanding how the tool works.

Any new detections or amendments can be added to the https://github.com/nettitude/PoshC2_IOCs repository and we encourage the community to add their own detections or rules and configurations for other security tools to help build a centralised data store for everyone.

Introducing PoshC2 v6.0

We are pleased to release the latest version of PoshC2 – v6.0. Version 6.0 includes a number of significant and exciting features, in addition to the usual plethora of bug fixes and small improvements. In this blog post, we take a look at some of the more significant changes and feature rich enhancements to make it easier for operators.

Download PoshC2 v6.0

You can download PoshC2 v6.0 from GitHub:

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

Postgres Support

Reporting and auditing actions is an essential part of any C2 framework. As operators, we need to reliably determine all actions that have performed, in case there’s an incident as well as for accurate reporting. PoshC2 normally uses SQLite databases in the project directory to store its data, but we found that for large projects or a very high number of implants the performance of this database can become an issue and start to slow down.

For this reason, we’ve added support for Postgres databases, allowing teams to point their PoshC2 install at a Postgres instance and have the project data stored in a performant database on a separate server, if desired.

Using Postgres in PoshC2 is easy, simply change the DatabaseType value in the config.yml from SQLite to Postgres, and set the PostgresConnectionString as follows. The only other thing to note is you must create the database manually before adding the connection string.

That’s all there is to it!

Daisy Chaining

Daisy chaining implants has been an incredible feature of PoshC2 for some time now. The ability to have one implant beacon to another existing implant allows operators to compromise environments that can’t reach the Internet, by having communications route through an active implant that can. These implants can be daisy-chained to an arbitrary length which is extremely useful and powerful, but sometimes setting up daisy-chaining felt a little arcane, and if you didn’t make the right sacrifice to the right deity at the right time it may not work and troubleshooting the issue was not the easiest.

To help with this, we’ve added a wizard. Simply run startdaisy from the implant you want to use as the daisy server and it will guide the operator through the different options and situations before starting the daisy server on the current implant, and generate new daisy payloads that can be used to connect to this instance.

Once the daisy implant has been obtained, the operator can simply run startdaisy on that implant if they want to go deeper, or just use the implant as they would normally if one layer pivoting is all that’s required.

It should be noted that binding to a non-localhost IP address requires elevation, but daisy-chaining can still be used on the localhost without elevation. This is useful for elevation of privilege attacks, for example, creating implants as other users that cannot or should not have traffic leaving the environment, such as SYSTEM implants.

Dynamic Code Execution

Most red teams need the ability to quickly adapt to situations, to take advantage of fleeting opportunities or tackle difficult problems innovatively and creatively.

To help with this, we’ve added a quick and easy way of being able to write and run code down on a C# implant. PoshC2’s ‘Dynamic Code’ feature creates a DynamicCode.cs file in the project payloads directory. This file can then be edited at will in your editor of choice and run in the implant instantly.

Once done, saving it and running dynamic-code from a C# implant will compile this code and execute it in memory, on the target, on the fly.

This should enable teams to prototype and run their own code snippets or C# scripts quickly, allowing them to improvise, adapt and overcome obstacles they encounter.

AMSI Bypass

We’ve also updated the AMSI bypass for C# implant as well as help obfuscate the initial PowerShell cradle, which may help when fighting off Windows Defender. There were recently a few good blog articles from the security community that have helped us with this, as follows:

@_RastaMouse also has a GitHub repository that has the AMSI ScanBufferBypass that is leveraged in the C# implant shellcode, which evades the System.Reflection.Assembly.Load methods. Hopefully this means you can have more success on engagements rather than fighting with Windows Defender in order to help improve your client’s security posture.

Sharp PowerShell

Another significant change is the addition of PowerShell execution in the C# implant.

By using the sharpps command, operators can execute PowerShell in memory on the target from a C# implant, effectively adding the full power of PowerShell and the PowerShell implant to the C# implant. Similarly, modules can be loaded using the pslo (PowerShell loadmodule) command.

#OpSec Warning: Note that while PowerShell.exe is never touched or used, this will load the System.Management.Automation.dll into memory for the implant process when a sharpps or pslo command is first run.

SharpSploit integration

SharpSploit is a fantastic resource and has been included with PoshC2’s modules for some time now, but usage had been quite manual through the run-dll command.

We have started to integrate SharpSploit into PoshC2 more in order to leverage this tool more easily, starting with its Mimikatz commands:

We will continue to expand in this area over the next few months, so watch this space.

Indicators of Compromise

A key consideration when using a C2 framework is the Indicators of Compromise (IoCs) it has, and how well known they are.

Many of PoshC2’s IoCs are well fingerprinted, but can be altered in the config.yml file, such as the UserAgent string, default migration process, server header and more.

Previously, the HTTP responses that were returned by the server were simple inline pages in the configuration file, making it difficult to alter these to reflect real HTML pages. These have now been pulled out into standalone files in resources/responses folder so they can be easily edited.

A file is randomly selected and used as a response for HTML requests.

Searching history

PoshC2 already allows interactive command searching similar to bash using the Ctrl-R key combination, but a much requested feature was the ability to search through the command history in a similar way to the searchhelp command, which returns a list based off a regex search.

A searchhistory command has now been added which does exactly this, allowing operators to find all relevant commands, helpful both on engagements and when reporting, or even updating your notes with the cool commands you used during a live engagement.

C# Portscanner

Rob Maslen’s (@rbmaslen) PortScanner module has been added to PoshC2 and integrated into the C# implant so we can now fully utilize this in engagements where the PowerShell implant may get detected.

This fast and effective port scanner is loaded and run in memory by the C# implant and can be executed as shown below. It will also show closed ports for when you may need to tunnel through the network using already pre-approved ports on the firewall.

fpc script improvements

The fpc (Find PoshC2 Command) script is installed by PoshC2 to help with reporting and logging. When run from the command line, it allows users to search the PoshC2 database for commands or command output containing certain keywords. Rich Hicks (@Console) has significantly enhanced this script by improving its output to include the user and timestamp that run the particular command, in addition to adding a new filter for the taskId.

This script has also been updated to add support for Postgres.

RedELK Support

Working with @OutflankNL we’ve helped add support for PoshC2 to their awesome RedELK tool. This Red Team SIEM provides phenomenal oversight and insight into the actions being performed both by the Red Team and by the Blue Team when investigating an incident caused by that C2 instance, alerting the Red Team that they have been compromised. For more information, see the RedELK page here: https://github.com/outflanknl/RedELK.

Download PoshC2 v6.0

You can download PoshC2 v6.0 from GitHub:

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

Roadmap

We still have a lot of planned improvements for PoshC2. Some of the prioritised changes are below:

  • Refresh the documentation.
  • Continue improving the ease of configuration for PoshC2’s IoCs (Indicators of Compromise), such as the HTTP responses and URLs used.
  • Provide the community with increased detections for PoshC2’s default IoCs, such as behavioural IoCs, yara rules and so on.
  • Continue refactoring PoshC2 for ease of development and testing.
  • Link pre-compiled third-party modules to their respective repositories for credit, updating, investigation etc.
  • Move to ISO standard date formats (yyyy-MM-dd).
  • Add an (optional) embedded RedELK Red Team SIEM to PoshC2’s C2 server.
  • Update Nettitude’s Red Team Training Course to cover in detail advanced usage of PoshC2 and knowledge of its IoCs, including altering core behavioural and static IoCs.
  • Add a python3 dropper.

Other Updates

A large number of other updates and fixes have been added in this version, some of which are briefly summarised below. For updates and tips check out @nettitude_labs, @benpturner and @m0rv4i on Twitter.

  • Updated SharpHound to the latest version 3.0.4
  • Kali Linux is the supported Operating System of choice now, with the Dockerfile building from the base Kali rolling image.
  • Clockwork SMS support has been retired and Pushover support enhanced, with the ability to set the API keys from the Implant Handler.
  • The Implant Handler display has been altered slightly, with labels on the right and displayed in blue.
  • Modules are now no longer loaded from the modules directory if a full path is specified to the loadmodule command.
  • The C# dropper now explicitly states the format it expects numbers, such as jitter, to avoid formatting issues when implants are running in other locales.
  • Beacon times will only be updated in the UI and server side when a beacon successfully accepts the beacon update task.
  • Implants will now retry up to five times to POST task data back if the request fails.
  • Kevin-Robertson’s Powermad module added (Thanks to Roxana Kovaci (@rkovaci)).
  • Install Script now checks it is running as root and exits if now with a user friendly message (Thanks to @jaredstroud).
  • Add m0rv4i’s SharpCookieMonster module.
  • Added updated PowerUpSQL from @NetSPI and new SweetPotato.exe module from @CCob
  • Added a sharp command safety check in the PS implant to catch commands that are likely for the C# implant and prompt for confirmation.
  • Update Rubeus module (Thanks to Tom MacDonald (@BaffledJimmy))
  • Updated the SharpHound3 help for increased operational security and stealth (Thanks to Ross Bingham (@PwnDexter))
  • Added ability to auto-hide implants that have not beaconed in for over 30 beacons with the –a option to the implant handler.
  • Added a static warning to the top of the ImplantHandler in red when the Kill date is less than 7 days away (thanks to @Felix).
  • Fixed: Encryption of special characters in commands could silently fail, particularly critical when entering a password with a special character in it.
  • Fixed: Generated HTML reports being truncated
  • Fixed: Various Upload and Download-file issues. (Thanks to @clhefton and @chppppp)
  • Fixed: Missing mono assemblies for installing on Ubuntu
  • Fixed: startanotherimplant-keepfile command not working in Python implant
  • Fixed: SharpSocks support via Domain Fronted URLs.
  • Fixed: Mimikatz credential parsing for creds command.
  • Fixed: Python2 dropper didn’t work in Python versions before 2.7.0 (Thanks to @RustyBower).
  • Fixed: PowerShell implants install-servicelevel-persistence (Thanks to @developerbart)
  • Fixed: Typo in backup folder name when starting PoshC2 with a different configuration (Thanks to @er28-0652).
  • Fixed: Many, many issues with the PoshC2.psm1 PowerShell module for PoshC2 on Windows via Docker (Thanks to @justin-p).
  • Fixed: Various SharpSocks issues (Thanks to Roxana Kovaci (@rkovaci)).
  • Fixed: Kill date format handling inconsistent across locales (Thanks to @KidneyThief).
  • Fixed: Python dropper.sh now explicitly uses python2 (Thanks to @clhefton).

Introducing SharpSocks v2.0

It has been over a year since we released the first version of SharpSocks, our proxy-aware reverse HTTP tunnelling SOCKS proxy. This post aims to provide a State of the Nation update for users. It details some of our experiences using it, how the experience and performance has been massively improved, and some of our observations along that journey for those interested in some of the juicy technical details under the hood.

TLDR – SharpSocks performance has been massively increased and is now fully integrated into PoshC2 so you can type sharpsocks to get this going straight away.

What’s the point of a SOCKS proxy?

When performing a simulated attack (red team), or indeed many other types of test, SOCKS proxies become an integral tool during the “Act on Objectives” phase of the kill chain. For example, if the target is behind the network perimeter, is a system accessible via RDP, is an intranet site or is a Citrix hosted application, the SOCKS proxy becomes an essential tool. It can allow access to those “internal only” resources, through an established implants C2 (Command and Control). The diagram below shows a typical scenario in a red team:

Currently, there are plenty of SOCKS proxy implementations that can be used in this scenario (which are very good) but these are usually built in to the various C2 frameworks. The initial goal of SharpSocks was to be “framework agnostic”, such that it could be deployed to a machine, independent of whether an implant was operating or not.

When a SOCKS Proxy is deployed via other C2 frameworks, the beacon frequency must be increased to provide quick feedback (usually 1-5 seconds), as a consequence of the volume of data being sent and received increasing considerably. In addition, there are connections to potentially sensitive services, which can generate events or Indicators of Compromise (IOCs) thus increasing the risk of detection.

By separating the SOCKS proxy from your main C2 Implant comms:

  • You can deploy the SOCKS Proxy to an unrelated machine and communicate through separate infrastructure.
  • Even if the SOCKS Proxy activity gets detected, it will not result in losing your initial foothold. If the SOCKS and C2 Implant are combined then there is a higher chance of detection.

Downsides to the “Separation” :

  • Additional setup, C2 infrastructure, separate commands and tools.
  • The actual code of gets larger.
  • The configuration becomes a lot more complicated.

It also does not help the fact that we like developing in C#, while everyone else wants to pwn stuff with Linux. In order to get around this, the use of SharpSocks with PoshC2 was supported by Wine. The SharpSocks client would work on a Linux OS but this was definitely less than optimal. Sooooo…

SharpSocks Server is now cross platform .Net Core

The main announcement is that at least on the SharpSocks side it has been ported to .Net Core (no more Wine thankfully; more on this below) and that its traffic is routed through PoshC2. In terms of PoshC2, which is detailed here: Introducing PoshC2 v5.0, major improvements have been made in its usability, in order to make SharpSocks a primary component rather than a tack on to the side.

Considering the risks we mentioned above, in deploying the SOCKS Proxy and implant on the same host and going back through the same infrastructure, is it still possible to deploy SharpSocks separately?

The answer is yes; absolutely the primary design goal of SharpSocks being deployed as a standalone SOCKS tool is still available.

State of the Nation

Some of the other project goals were to deliver a tool with the following features:

  1. Performance; ensure that the user experience of any protocol being tunnelled such as RDP is good.
  2. Proxy aware when sending traffic outside of the network.
  3. Allow for the easy customisation of the URLs used, the encryption mechanism and the data transport locations.

Over the last year, SharpSocks has seen regular usage on engagements where we have deployed PoshC2. One theme of threat intelligence led simulated attacks (CREST STAR, CBEST, TIBER etc.) is the use of a range of tools (i.e. C2 Frameworks) in order to simulate different levels of threat actor sophistication. PoshC2 is used in conjunction with commercial offerings and our own private Remote Access Tool (RAT) to simulate different types of adversaries.

Generally, feedback on SharpSocks use has been positive by our team, however the consistent themes of frustration have always been ease of use and performance. By far one of the most embarrassing situations as a developer you can get yourself into is when you completely forget how to setup your own tool. SOCKS proxying by nature is slow, however compared to other similar tools, SharpSocks still wasn’t the fastest.

This is where this updated release comes in. It is designed to make SharpSocks easier to use, fix some long standing bugs and generally make the performance of SOCKS proxying better and faster.

.Net Core

As mentioned above, the SharpSocks Server component is now built as a .Net Core project. Why .Net Core? Well, when SharpSocks was originally built, it was a purely “C# Windows” only solution. This was primarily due to my background as a professional developer before my career in InfoSec. Creating a Windows only tool really does, in terms of InfoSec, limit your potential user base. Eventually I came to the conclusion that yes – it had to become cross platform. Some of the options included Go or Python, but in the end porting to these would have required a complete rewrite of the underlying code base, something I was really not sure was worth the effort considering that .Net Core is available.

By porting to .Net Core, it is now possible to run SharpSocks on either Windows, Linux or MacOS with limited changes. The process of porting involved creating a new .Net Core project and moving the source into it. The only change that had to be made was that the encryption code tried to limit exposure of the key in memory by using DPAPI; in .Net Core this does not appear to be supported as I suspect there is no direct analogue in Linux or MacOS.

The main advantage of running as .NET Core rather than Wine is performance; tunnelling your traffic through SharpSocks feels so much faster. This is entirely logical, as it runs on a small optimised platform runtime.

Other Changes

Other fixes and changes include an overhaul of the error handling, particularly when the server has stopped responding. A particularly nasty issue was found that occurred when the redirector returned a 404 and the server had been stopped.

There is also a new option on Server called socketTimeout (pass either -st or -socketTimeout and an integer value for second e.g. 240).

  • This controls how long a SOCKS connection to the server will be held open without any data having been sent over it. This is not something that you should normally have to tweak, however if you are having problems with the application being tunnelled timing out then this is a value that may help.

How to use (SharpSocks in Posh)

  1. Get a shell (PowerShell or C# implant) on the target host using your favourite execution method.
  2. Within the implant handler, select the implant.
  3. Type sharpsocks within the implant handler. Immediately, a line will be printed out with detail that you will need to start the server. Copy this and paste it into a terminal (NOT into the PoshC2 implant handler).
  4. Once the server has started, type ‘Y’ and enter into the implant handler window. The output should now say that the implant has started. You can confirm this by looking at the output from the server you started in the previous step. If it has started, you should see the port that the SOCKS Proxy is now listening on (most likely 43334).
  5. If you haven’t already done so, now is the time to configure proxychains, your browser or the SOCKS aware application to point to localhost:43334.
  6. With this you can start SOCKS Proxying away.

SharpSocks Deep Dive

As stated, it had been a while since the initial release of SharpSocks and it was time to do a little work on it. The following is a bit of a deep dive on how it works, some of the changes that have been made recently, and issues that we had to work through. If there is anything you would like to know more about, hit me up on twitter @rbmaslen or on the PoshC2 Slack channel (poshc2.slack.com – email us @ labs at nettitude dot com for an invite).

Long Polling

Having taken Silent Break Security’s excellent Dark Side Ops 2 course (https://silentbreaksecurity.com/training/dark-side-ops-2-adversary-simulation/ ) at DerbyCon last year, before smashing the 2018 CTF with SpicyWeasel, I was struck by the usefulness of HTTP Long Poll. I had come across the concept many years ago in another life as a developer but hadn’t really grasped the relevance to the Red Team toolkit until I took the course.

The premise, essentially, is that you are inverting the beacon. In traditional implants:

  • The main thread is on a timer (with an inbuilt jitter value).
  • When this interval elapses a call back is made to the C2 Server.

One of the main problems with running on beacon time is that once you have queued your task, there is plenty of time to be distracted before the results arrive in. Long Polling means that when a request is made to an HTTP Server, the connection will be held open until a result set is ready (or a much longer time out elapses server side).

How this works in the implant context is that when the request comes into the C2 Server from the implant, the connection (HTTP Request) is held open until tasks have been queued or if tasks are queued and ready to go, it returns immediately. This puts the wait upon the Server side and makes the implant/tasking feel very snappy much more like a command line.

It also means shorter beacon times when being actively used and longer ones when not in use, so the operator needs to spend less time adjusting the sleep time. It also probably makes it a little harder for tools looking for “regular” HTTP requests in order to identify beacons.

So how does that relate to SharpSocks? Well, I’m glad you asked; first it’s probably best to understand how SharpSocks works as a concept.

So how does it all work then?

Very good question, if you do know answers on a postcard please 🙂

Breaking it down, there are at a bare minimum two components, the first being the “Server” and the second being “Implant” (both as separate Visual Studio projects). Within the Visual Studio solutions there are also two test applications that you can use if you are debugging the libraries. The way that SharpSocks is normally deployed, particularly via the Implant, is either a PowerShell script that loads the library or a C# implant that loads the Assembly (.dll).

The Server at it’s core is an HTTPListener. When the server starts up, it starts listening for connections to the URI that has been passed.

An important point is that the Implant and the Server need to share a few secrets:

  1. One is an Encryption Key.
  2. The other is a Command Channel Session Id.

The Implant communicates to the Server via XML Messages in regular Web Requests (encrypted of course. The request needs to identify the connection or the Command Channel that messages are being sent about by a randomly generated Session Id.

The Command Channel has a special one that is shared between the “Server” and the “Implant’ at start-up. Messages about connections opening and closing are sent over the Command Channel (encrypted of course with the key); actual traffic and a status are sent with session id’s that identify the connection.

I need to admit that XML is not a great format. It was used for simplicity when SharpSocks was first built, and yes it will be replaced at some point in time, but it works for the moment. A point could also be made about the lack of multiplexing; at the moment each request will only have information about one Session Id (Command Channel can have multiple open/close messages). This is on the road map, as I would really like to be able to reduce the number of web requests.

The first time a Command Channel request is sent by the Implant another port on the localhost interface is opened up. This is the SOCKS port where you can point your browser, other SOCKS proxy aware app or proxychains (the port itself either defaults to 43334 or what you pass on the command line). Now the app that wants to proxy needs to first send a request to this port identifying the host and the port that it wants to open a connection to (an example of the structure here is for SOCKS4) before it can send any data. The details about the connection to open is then queued as a Command Channel task which will be picked up by the implants Command Channel web request. Once the implant receives this message back, the connection to the specified host is attempted and a message based on the status of this connection is returned to the Server.

Back to Long Polling

So thinking about Long Polling you can probably immediately see where this might be of benefit to the Command Channel, particularly if you have an application that is infrequently opening connections. Having a traditional beacon means that there will be a delay in opening the connection at the implant side if the proxying application didn’t make the request to open right before the beacon arrived.

For this reason the implant now uses Long Polling for the Command Channel. If there are no connections to Open or Close (or none arrive during the wait) the Server will hold the connection open for 40 seconds delay before returning back to the implant telling it there is no work to do (the Implant will then wait a very small amount of time before initiating the connection again). This Long Poll interval can be tweaked on the Server at runtime by typing:

LPoll= e.g. LPoll=5 or LPoll=60

Heading back to the implant side, when it receives the Open message it will then attempt to create a TCP Connection to the specified host:port. Now in the previous version, all of the work that it was to perform was started asynchronously within a Task (one was opened per connection). The code running in this task would asynchronously poll that connection to the target application and then send/receive data to and from the Server via web requests. The Server itself would also have a polling loop checking any data on the SOCKS connection.

This kind of worked in theory, but using some real world applications like RDP (and then trying to debug why connections were really slow) showed up that this was a less than optimal design. There were too many Tasks being created (far too many resources being used), it was next to impossible to get an idea of any connections state when debugging and it had really been coded using a too simplistic notion that traffic would follow a pattern of:

client->server
server->client
client->server
etc.

Changing in this release, instead of both the Server and the Implant having a Task per open connection, there is now only a single loop that polls each of connections regularly (very regularly) to check if the connection is still open and read any data that is available. Moving to a singular loop has shown performance gains rather than losses (so the lesson here is beware of unnecessary parallelism particularly in terms of complexity).

Any data that has been read from a polled connection is written into a queue and then an Event is triggered (specifically a ManualResetEvent notifying another thread that there is data to send back to the Server. This threads sole job is to wait until there is data to send via Web Request back to the Server (it is important to note this is fire and forget, NOT long polled). It’s best to think of this as a standard ProducerConsumer loop. In order to implement it here I am using ConcurrentQueue’s. These are a really cool class helping to avoid locks in concurrent code.

So how does the data come back from Server? The Implant also makes a long polling request per open connection to poll the Servers queue for any data that needs to be sent down the SOCKS connection.

It’s really important to understand how this works as it leads to one of the more frustrating limits I’ve found in .Net (I’ve been coding C# since 2007 and this is the first time I have seen it).

Summing up in terms of Web Requests back to the server we have at least:

  • 1 Long Polled Command Channel back to the Server.
  • 1 Long Polled Data request per open connection.
  • 1 Normal request when the Target application has sent data to the implant.

I’ve got all the code ready, should work really nice but NOPE it’s gone really slow again. What?!

Limiting limits

If you have done any coding using WebClient, C#’s wrapper for making Web Requests, then you might have also come across ServicePoint & ServicePointManager. These classes control the underlying connection, the connection pool and the TLS connection to the target site.

In order to do a System Test of everything I configured the test apps to point to each other (on Windows 10 using FireFox with its proxy configured to use the SOCKS proxy port) – I tried to load the BBC Website and the results were not great. First of all it’s insane how much gets loaded by most modern websites and how many connections to different sites there are.

I’ve probably ignored this in Burp by hiding what is not in scope… Both Test applications have the option of passing verbose for logging, yielding a load of information about the connections being opened, data being sent back & forth, and timings. Now i could see a delay in various places but having so many connections made it really difficult, so thinking only having one connection might make life easier, I resorted to Curl.

Sure enough, yes, in Curl I still kept getting an artificial delay, so there was no other option but to go back into Visual Studio and debug it. Did this yield any info? Not really. So, I could see the connection being made, everything was cool until data needed to be sent back and there was always a delay that appeared consistent with the Long Poll, but not always.

Is there a happy ending?

Well, yes. After an inordinate amount of testing, thinking about trying to use Kestrel instead of HTTPListener and much reading of documentation, I came across this utterly insane limit within the ServicePointManager. Now, each domain that you make a connection to will have a ServicePoint instance, meaning that there is a maximum of two (yes, 2!) concurrent connections to any site. This value can be modified, but it must be done before any connection is made to the host otherwise a ServicePoint object will have been created and the limit will be two.

The image above is from:

https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepointmanager.defaultconnectionlimit?view=netframework-4.8

So, we know that at least two connections are being Long Polled and any time data is read from the connection to the target application a third Web Request will be made. Either the Command Channel or Implants other connection will have to return before this can be sent. What can I say? Massively frustrating and I had never seen this before (or maybe I had in the past, forgotten it and am just getting old, who knows).

Conclusion

So, to wrap what have we learnt here… to be honest it just reinforces lessons that I have learnt continually through my career:

  • RTFM – there is incredible value in the MSDN.
  • Avoid unnecessary complexity and too much parallelism.

With this release I really feel that SharpSocks is getting a lot closer to the initial goals of being a very easy to use SOCKS proxy with solid performance. The upcoming features that are still in development are:

  • Reduce some of the web traffic mainly by multiplexing some messages.
  • Stop using XML and use a better message format.
  • Tighter integration with PoshC2.

Oh – I almost forgot: SOCKS5 (TCP only for the moment) and thus Burp are now supported. SOCKS away my friends!

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