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).

CVE-2019-13021, 22, 23: JETSELECT Network Segregation Application

Nettitude are disclosing three vulnerabilities discovered as part of a security assessment on board a superyacht. These vulnerabilities have now had patches published by the vendor, and an appropriate time period has elapsed to allow for a patching window aboard the vessels.

JETSELECT

The JETSELECT application is supplied by JetStream, a technology company specialising in the provision of various IT services to the yacht industry. Further details on the product can be found here:

http://www.jetstream.mc/our-products/jetselect/

The JETSELECT instance tested by Nettitude was hosted on Oracle Glassfish middleware, which was vulnerable to Local File Inclusion. This vulnerability allowed Nettitude to analyse the underlying source code of JETSELECT, revealing several other vulnerabilities. The Oracle Glassfish middleware was the mechanism that allowed for the discovery of the following vulnerabilities from an unauthenticated attacker perspective.

CVE-2019-13021

During installation of the JETSELECT application, an installation script is run.  It writes a copy of the master password to a .bak file stored on the filesystem.

As can be seen in the screenshot below, the CONFSFC variable is assigned to /JetSelect/SFC/resources/sfc-general.properties.

This installation script was located in /home/bondit/jsl/3passchange.sh

At the conclusion of the script, an in-place sed command replaces all previously stored password hashes with the new passwords in the sfc-general.properties file. Additionally, the previous installation password hashes are stored in a file named sfc-general.properties.bak. The full path to this file is /JetSelect/SFC/resources/sfc-general.properties.

It is possible for any low privileged user on the system to view this directory, rendering any protections that may be provided by the MySQL database or salting to be ineffective.

Whilst this does give direct access to the password hashes, Nettitude were unable to discover the plaintext password until the discovery of CVE-2019-13022, shown below.

CVE-2019-13022

Nettitude continued to probe the application, eventually gaining access to the JAR class ENCtool.jar referred to in the installation script, which is responsible for encrypting and decrypting data.

After obtaining a copy of that file, Nettitude decompiled the application and gained access to the source code. Examination of the source code revealed that the algorithm responsible for generating secure password hashes was simply a XOR function followed by Base64 encoding the output, as shown below.

Leveraging this information, it was possible to quickly develop a tool to gain access to the original plaintext input.

Using the code above, it is possible to pass a base64 encoded string obtained from the sfc-general.properties file:

python crack.py "TVxOTkpST1k="

'Encrypted' Password: TVxOTkpST1k=

'Decrypted' Password: password

This password can be used to log into the web interface of the application as an Administrator, allowing the amendment of all network segregation rules provided by the application. Additional passwords (for example, MySQL login details) can be found by examining the other files referenced in the 3passchange.sh script mentioned previously.

Examination of an additional installation script within the BondIT home directory named runSQL.sh also revealed MySQL credentials for the root account. After obtaining access to the MySQL database as root, it was simple to obtain usernames and password hashes for all other users in the JetSelect application using the following query:

SELECT * from JSL_USER

As these passwords are ‘encrypted’ using the same manner as previously described, it is possible to gain access to all accounts in the application.

CVE-2019-13023

Nettitude also discovered that the web interface of the application stored and attempted to obscure sensitive information such as RADIUS secrets and SNMP strings. These values were stored in cleartext in a property called password within the HTML of the web page. As such, it was trivial to obtain the cleartext values of these settings, even as a lower privileged user – for example, the ETO role who is not an Administrative user and who should not have access to this information.

Nettitude did not complete a full assessment of the software as that was not the objective of the engagement; it is possible that other fields within the application suffer from the same issue.

Conclusion

This scenario also serves to highlight the risks that the Marine & Offshore sector can experience in relation to securing both the information technology (IT) and the operational technology (OT) of a vessel. Many vessels are equipped with 24/7 internet connectivity, in effect making the IT not much different to that of a conventional business.

It is critical that vessel operators adopt a cyber security strategy for both their onshore and offshore operations. This should incorporate, as a minimum, a solid patching strategy (supported by a development environment hosted onshore), vulnerability assessment and rolling penetration testing.

Additionally, this case study provides a perfect example of where the OWASP ASVS testing framework can improve assurance levels, as well as ensure that security is included in the development life-cycle of applications and services. If this application was simply tested from a black box web application perspective, two of the vulnerabilities would have gone unnoticed. By combining grey box web application penetration testing with architecture reviews, build reviews, code reviews etc, it is possible to drastically improve the security of an application as a whole.

For more information on the OWASP ASVS framework, please visit:

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

Disclosure Timeline

  • 15 May 2019 – Initial communications established with vendor.
  • 24 May 2019 – Technical details provided to allocated point of contact.
  • 28 May 2019 – Follow up email sent to ensure vendor received technical details.
  • 4 June 2019 – Vendor acknowledged receipt of technical details.
  • 18 July 2019 – Nettitude requests update.
  • 21 July 2019 – Vendor replies they have a patch nearly ready, that will be released in the coming weeks.
  • 24 July 2019 – Nettitude delay disclosure to allow further time for customers to patch their software.
  • 12 December 2019 – Nettitude give vendor of notice to publicly disclose.
  • 13 December 2019 – Vendor acknowledges.
  • 22 April 2020 – Nettitude publicly disclose vulnerabilities.

Credits

Thanks to Rob Bone (R2B2) @m0rv4i for his quick PoC to ‘decrypt’ the passwords stored in the application.

CVE-2019-12750: Symantec Endpoint Protection Local Privilege Escalation – Part 2

In this post we will walk you through a more sophisticated method of exploiting CVE-2019-12750.  This is a local privilege escalation vulnerability that affects Symantec Endpoint Protection.  The method of exploitation described in this post works, at the time of writing, on all versions of Windows. Read more

CVE-2019-12750: Symantec Endpoint Protection Local Privilege Escalation – Part 1

A malicious application can take advantage of a vulnerability in Symantec Endpoint Protection to leak privileged information and/or execute code with higher privileges, thus taking full control over the affected host. Read more