There have been a few cool updates to PoshC2, our public Command & Control (C2) software, since we first released it. In this post, we’ll walk you through some of these new features so that you can try them out for yourself. We encourage you to give it a go and get involved.
New features
In a nutshell, the following new features are most noteworthy:
- New GUI – Enables collaboration when running one C2 Server.
- Daisy Chaining Module – C2 communications through one compromised host.
- Portability – Ability to deploy on client infrastructure.
- Persistence – Install persistence in up to four (soon to be five!) ways.
- Reporting – HTML report format for credentials, implants and completed tasks.
New GUI
The new graphical user interface allows multiple users to connect to the same central database while running a red team engagement. Install the PoshC2 server on a centralised host and then each user can mount a share which hosts the SQLite Database. This was a requirement that came out of using the tool in anger and is an absolute requirement for larger engagements.
With this, you now also have the ability to have autocomplete on the input field. When typing a new command in the taskbox it will show all the tasks from the help menu, including any previously typed commands from that engagement.
The new PoshC2 GUI
There are new context menus that improve the usability of the implants by simply allowing a user to right-click and run various actions, e.g. install-persistence, get-screenshot and more. This is useful for performing various tasks quickly.
PoshC2 context menu
Finally, there is improved module help, which was previously more tedious to access. When opening the GUI it will scrape the help from all modules listed in the Module folder so that you can search the module while mid-engagement, rather than having to open the module in an editor to search the help.
PoshC2 module help
Daisy chaining module
We created a new Daisy Chaining module that can be stood up on any valid implant to provide the ability for other internal hosts to connect through it like a proxy. The term daisy chain sprung to mind when visualising this type of implant and lateral movement.
PoshC2 daisy chaining
There are advantages and disadvantages for running secondary implants via the daisy chain server.
The benefits are:
- fewer hosts beaconing to the PoshC2 server directly, e.g. if you compromised a Domain Controller you wouldn’t expect to have it beaconing to the Internet, which could raise suspicion from the Blue Team.
- the DC might not have direct Internet access anyway, even if you supply the onsite proxy details.
On the other hand:
- if your initial implant gets taken offline or shutdown for any reason then all the other hosts will be lost too.
When performing lateral movement on a live Red Team engagement, it’s always best to try and increase your odds and have a backup plan. Try and establish a foothold that beacons to a completely separate host that is in no way connected to the initial attack, in case your initial foothold is caught by the Blue Team. Additionally, for high value assets, try to ensure it beacons via another host so that is doesn’t raise any suspicion in the proxy logs.
All lateral movement is still achieved using WMI which is far stealthier than PSEXEC as it doesn’t require a new service to be created. The following diagram shows a visual representation of daisy chaining via PoshC2.
Portability
While it’s not always essential to have a C2 that is portable, PoshC2 can be deployed almost anywhere that has a Windows base operating system, from Windows 7 onward. If posing as an insider threat, PoshC2 can be deployed locally and used as an internal attack framework for exploiting the client network. It’s worth noting that before doing this activity we’d advise on some due diligence and ensure the modules you are taking with you don’t get caught by Anti Virus. Modules like Invoke-Mimikatz and Get-Keystrokes often get caught.
This is different to when deploying modules in a more standard manner because you are not uploading them directly into memory in the PowerShell run-space. You instead have to place them on the client infrastructure, which would touch disk, and is at far greater risk of getting caught by Anti Virus. There are work arounds to prevent this; most AV vendors signature on simple strings which can be modified with no ill effect for the attacker. For example, we have had lots of success running Invoke-Mimikatz simply by removing the help text before deployment. Alternatively, you could remove almost all the modules and then load them using the download cradle built into PoshC2.
At any rate, PoshC2 serves as a capable internal attack framework when you need it to, which we’ve found to be useful on a number of engagements.
Persistence
We introduced a few other forms of user-land persistence to vary the Indicators of Compromise (IoC) during an engagement. The three locations are as follows:
- Registry run key
- Scheduled task
- Startup folder
Registry Run key auto runs when a user logs into their workstation and is stored in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run.
Scheduled tasks are run every four hours. Obviously you may end up with more than enough implants during the entire engagement but this task is stored completely separate to the registry run key and is a good alternative to use during your engagement.
The final method of persistence that has been added is to the user’s startup folder, in the form of a *.lnk file. This is run silently when a user logs into their workstation.
There is also a method of getting service-level persistence:
- This creates a new Windows service using the ‘sc’ utility which calls powershell as the binary path (binpath). This method is set to start automatically before a user even logs into the machine. This, by default will execute the implant using the
NT Authority\SYSTEMaccount. Be aware that in a secure environment, you may need to implement the service-level persistence using theWithProxyfunctionality.
Beyond the service-level persistence module that is currently in PoshC2, in the near future we are also going to integrate Matt Graeber’s WMI event persistence that runs as an elevated user:
Reporting
While this hasn’t changed significantly since the first iteration of PoshC2, it’s one of the most important elements of the tool. It will fundamentally assist in the SOC detection and response phase of your engagements, i.e. when assessing the response of the Blue Team. It is, of course, also a professional requirement to have full logs of offensive activity.
PoshC2 reporting
By default, every command and all output from each implant that is used within PoshC2 is logged to the internal SQLite database, complete with a time-stamp from the system you’re currently running the server from. It’s important to mention this because if you a targeting users from different time-zones then it’s probably best to change your local server to reflect their time zone or alternatively apply your own time difference at the end. Always ensure you have an up-to-date time source before starting every engagement, otherwise you’ll end up with time drift and results won’t marry up on either side.
One addition to the reporting element is the credential store. This will by default be produced when enforcing the ‘output-to-html’ function in PoshC2. One feature that will be implemented shortly is ensuring that passwords are obscured in the initial output using CSS, so you can provide this to a client after the engagement and they would have a full, obscured list of credentials they need to reset during their post engagement activities.
Conclusion
In conclusion, we’ve had a lot of fun working on PoshC2 and will continue to do so well into the future. We encourage you to use it, provide feedback and generally contribute to the project. You can always grab the latest version from GitHub: https://github.com/nettitude/PoshC2
