Command and Control platforms are constantly evolving. In one of my previous blog posts, I detailed how to detect PoshC2 v3.8:
Since then, Nettitude have revamped PoshC2 and released v5.0. This blog post takes a look at the new and improved version, and goes into some detection mechanisms, but this time, solely over SSL.
Review
Reviewing the configuration for PoshC2, it appears it still generates a certificate with the same default information as its predecessor. This is not to say that it is not easy to change as you could simply edit the Python file that generates this certificate, or that it will not alter in the future, but it's worth noting:
Delving into NetWitness Packets, we can see this information is extracted and gets populated under the meta keys shown below:
This would make detecting the default certificates of PoshC2 with application rules a simple task. We would need only to look for one of the metadata values above being created due to them being very unique:
alias.host = 'p18055077' || ssl.ca = 'pajfds' || ssl.subject = 'pajfds'
The certificate is also self-signed and generated when the PoshC2 sever is started, so we also see some interesting metadata values populated under the analysis.service meta key:
The certificate issued within last day is a relatively new metadata value and something to look out for within your environment. There are also other relatively new metadata values that will be populated based upon the analysis NetWitness performs against the certificate, these are shown below:
| analysis.service | Description | Reason |
| certificate long expiration | Certificate expires more than two years since issued. | Certificate validity is usually capped at two years. Longer-lived certificates may be suspicious. |
| certificate expired | Certificate was expired when presented. | Expired certificates are invalid and won't be presented by most legitimate hosts. |
| certificate expired within last week | Certificate was expired by less than a week when presented. | Expired certificates are not expected to be presented by most legitimate hosts. |
| certificate issued within last day | Certificate was presented less than a day since issued. | New certificates may be suspicious in combination with other characteristics of the session. |
| certificate issued within last week | Certificate was presented less than a week since issued. | New certificates may be suspicious in combination with other characteristics of the session. |
| certificate issued within last month | Certificate was presented less than a month since issued. | New certificates may be suspicious in combination with other characteristics of the session. |
| certificate anomalous issued date | Certificate issued date is malformed, nonsensical, or invalid. | Invalid or malformed certificates are suspicious. |
| certificate anomalous expiration date | Certificate expiration date is malformed, nonsensical, or invalid. | Invalid or malformed certificates are suspicious. |
Looking further into the configuration there are a few other interesting default settings. The User Agent string is hard coded, but of course you would need SSL inspection to see this, or for the beacons to be over HTTP - with that being said, it is a very common User Agent string and not a great indicator anyway. The default sleep, or beacon, is set 5 seconds, and the jitter to 0.20 seconds - this would make the beacons stand out in NetWitness Packets:
Looking into the Navigate view, and pivoting on the suspiciously named certificate, ssl.ca = 'pajfds' - it is possible to see a beacon type pattern for this traffic:
Delving into the Event Analysis view for this, we can obtain a better view of the cadence of communication. From here you can see the very obvious beacon pattern coupled with a payload size that does not vary greatly. Two great indications of automated check-in type behaviour:
With 11.3.1.0, there is a new feature available that provides the ability to generate JA3 hashes for SSL traffic. They are not enabled by default, but the following configuration guide details how to enable them:
Decoder Configuration Guide for RSA NetWitness® Platform 11.3
For more details on what JA3 hashes are, and how they can be useful, there is a great explanation of them from the creators available on Github:
https://community.rsa.com/external-link.jspa?url=https%3A%2F%2Fgithub.com%2Fsalesforce%2Fja3
In this instance, a PowerShell payload was dropped onto the endpoint, and therefore it is PowerShell making the web requests. The way PowerShell sets up its TLS sessions has a unique(ish) JA3 fingerprint:
Perusing the available open source JA3 hash lists, we can see that we indeed have a match for this hash and it is PowerShell (Miscellaneous/ja3_hashes.csv at master · marcusbakker/Miscellaneous · GitHub ). While this is not a atomic indicator for PoshC2, it is a great way to detect PowerShell making web requests, and a great starting point for your threat hunting that could lead you to find C&C servers, such as PoshC2 where a PowerShell payload was used:
The following screenshot shows the PowerShell payload created by PoshC2 and the one I used to infect the endpoint:
These JA3 hashes could be pulled in as a Feed, so the associated hash values get generated under a meta key of your choosing, or you could also create a right-click context menu action (attached to this post):
While not much as changed in terms of endpoint indicators and analysis, in this post we opted to cover the encrypted (by default) traffic generated by this framework a bit in more detail, while also highlighting some of the new certificate analysis characteristics on the product. Endpoint analysis of this framework can be found in the previous post regarding Posh C2: https://community.rsa.com/community/products/netwitness/blog/2019/03/04/command-and-control-poshc2
Conclusion
With the new release of PoshC2 v5.0, it appears that not much has changed in the grand scheme of things. With that being said, it is a good idea to regularly revisit known attack frameworks as they are constantly adapting and evolving to evade known detection mechanisms. It is also important to keep up to date with the latest features of NetWitness to ensure you have every chance to detect the bad traffic in your network.
1 Comment
