Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2019 > December
2019

Introduction

Having recently moved into the IR team – where I now have to actually do stuff as opposed to just talking about stuff in technical sales – I have found that the best way to get up to speed with detecting attacker behaviours is to run the tools they are likely to use in my lab so I can get familiar with how they work. Reading blogs like this and the others in Lee Kirkpatrick's excellent Profiling Attackers Series is great, but I find I learn much faster by doing things and interacting with systems myself.


Covenant

Covenant is an open source C2 framework (https://github.com/cobbr/Covenant) that can be viewed as a replacement for PowerShell Empire, since its retirement.

In this blog series, Lee Kirkpatrick has already covered some examples of how to get the payload delivered and installed on the target, so we’re going to dive straight in to how our Hunting Methodology can be used to detect the activity. We are going to hunt for activity using data generated by both NetWitness Network and NetWitness Endpoint.

For the purpose of this exercise, we have used the default http settings for the Listener profile in Covenant, and only changed the default beacon setting from 5 seconds to 120 seconds to represent a more realistic use of the tool. The settings can be easily changed (such as the user-agent, directory and files used for the callback etc) but quite often the defaults are used by attackers too! We have also used the Power Shell method for creating our Launcher.


NetWitness Network Analysis

Covenant uses an HTTP connection for its communication (which can optionally be configured to run over SSL with user provided certs). By using our regular methodology of starting with Outbound HTTP traffic (direction = ‘outbound’ && service = 80), we can review the Analysis meta keys for any interesting indicators:

 

 

Reviewing the Service Analysis keys (analysis.service) we can see some interesting values:

 

 

Check the RSA NetWitness Hunting Guide for more information on these values in Service Analysis

 

By drilling into these 6 values we reduce our dataset from over 4,000 sessions to 69 sessions – this means that these 69 sessions all share the same “interesting” characteristics that suggest that they are not normal user initiated web browsing.

 

 

With 69 sessions we can use Event Analysis to view those sessions in more detail, which reveals the bulk of traffic belongs to the same Source & Destination IP address pair:

 

 

This appears to be our Covenant C2 communications. Opening the session reconstruction, we can see more details. Some things that we can observe that could be used to enhance detection of this traffic would be the strange looking User-Agent string:

 

 

The User-Agent string is strange as appears to be old. It resolves to Chrome version 41 on Windows 7 – the victim in this case is a Windows 10 system, and the version of Chrome installed on the host is version 79. If you attempt to connect to the Listener with a different User-Agent it returns a 500 Error:

 

 

Don't poke the Bear (or Panda, Kitten, Tiger etc) - if you find these indicators in your environment, don't try to establish a connection back to the attacker's system as you will give them a tip-off that you are investigating them.

Also, the HTTP Request Header “cookies” appears in all sessions:

 

 

The HTTP Request Header “cookie” also appears in all sessions after the initial callback … so sessions with both “cookies” and “cookie” request headers appear unique to this traffic:

 

 

The following query (which could be used as an App rule) identifies the Covenant traffic in our dataset:

client = 'mozilla/5.0 (windows nt 6.1) applewebkit/537.36 (khtml, like gecko) chrome/41.0.2228.0 safari/537.36' && http.request = 'cookies' && http.request = 'cookie'

Another indicator we could use is the Request Header value SESSIONID=1552332971750, as this also appears to be a static string in the default HTTP profile for Covenant - as shown in this sample that has been submitted to hybrid-analysis.com https://www.hybrid-analysis.com/sample/aed68c3667e803b1c7af7e8e10cb2ebb9098f6d150cfa584e2c8736aaf863eec?environmentId=10… 

 

 

NetWitness Endpoint Analysis

When hunting with NetWitness Endpoint, I always start with my *Compromise keys – Behaviours of Compromise, Indicators of Compromise, and Enablers of Compromise, as well as reviewing the Category of endpoint events.

 

 

Here we can see 4 meta values related to running PowerShell – which we know is the method used for creating our Covenant Launcher.

Upon viewing these events in Event Analysis we can see the encoded PowerShell script being launched

 

 

Analysis shows that we have a very large encoded parameter being passed. It’s too large for us to decode and manage in the NetWitness GUI, so we can paste the command into CyberChef and decode it from there.

 

 

We can further decode the string to reveal the command:

 

 

The output here appears to be compressed, so we can add an Inflate operation to our recipe to reveal the contents:

 

 

Looks like we have some executable code. A quick search for recognisable strings yields a URL which matches our network traffic for the callback to the Covenant server, as well as a template for the html page that should match what is served by the Covenant Listener

 

 

Also the block of text can be Base64 decoded to reveal the Request Headers to be sent by the Grunt when communicating with the Listener:

 

 

This also matches what we observed in our network analysis for a Grunt check-in:

 

 

And the command being sent to the Grunt via the response from the Listener:

 

Decoding the &data= section of the above Post shows the encrypted data being returned to the Listener - known as the GruntEncryptedMessage:

 

 

 

Happy Hunting!

CT

In this blog post, I am going to cover a C&C framework called ReverseTCP Shell,. This was recently posted to GitHub by ZHacker:

 

With this framework, a single PowerShell script is used and PowerShell is the server component of the C2. This is also a little different from other C2's as it doesn't use a common protocol such as HTTP, this is why we thought it would be a good idea to cover, as it allows us to demonstrate the power of NetWitness with proprietary or unknown protocols.

 

The Attack

Upon execution of the ReverseTCP Shell PowerShell script, it will prompt for a couple of parameters, such as the host and port to listen for connections:

 

It will then supply options to generate a payload, I chose the Base64 option and opted to deploy the CMD Payload on my endpoint. At this point, the C2 also starts to listen for new connections:

 

After executing the payload on my endpoint, I recieve a successful connection back:

 

Now I have my successful connection, I can begin to execute reconaissance commands on the endpoint, or any commands of my choosing:

 

The C2 also allows me to take srceenshots of the infected endpoint, so let's do that as well:

 

NetWitness Packets Analysis

NetWitness Packets does a fantastic job at detecting protocols and has a large range of parsers to do so. In some cases, NetWitness Packets can not classify the traffic it is analysing, this could be because it is a proprietary protocol, or is just a protocol there is not a parser for, yet; in these instances, the data gets classified as OTHER

 

This traffic will still be analysed by the parsers in NetWitness, and should therefore be analysed by you as well. So to start the investigation, we would focus on traffic of type OTHER, using the following query, service=0 - from here, we can open other meta keys to see what information NetWitness parsed out. One that instantly stands out as a great place to start investigating is the windows cli admin commands metadata under the Service Analysis meta key:

 

Reconstructing the sessions, it is possible to see raw data being transferred back and forth, there is no structure to the data and therefore why NetWitness classified it as OTHER, but because NetWitness saw CLI commands being executed, it still created a piece of metadata to tell us about it:

NOTE: You may notice that the request and response in the above screenshot are reversed, this can happen for a number of reasons and an explanation as to why this occurs can be found in this KB article: 000012891 - When investigating sessions in RSA NetWitness, the source and destination IP addresses appear reversed.

 

The following query could be used to find suspect traffic such as this:

service = 0 && analysis.service = 'windows cli admin commands'

 

Further perusing the traffic for this C2, we can also see the screenshot taking place:

 

Which returns a decimal encoded PNG image:

 

We can take these decimal values from the network traffiic and run them through a recipe in CyberChef (https://gchq.github.io/CyberChef) to render the image, and see what the attacker saw:

 

NetWitness Endpoint Analysis

In NetWitness Endpoint, I always like to start my investigation by opening the IOC, BOC, and EOC meta keys. All of the metadata below should be fully investigated, but for this blog post, I will start with runs powershell decoding base64 string:

Pivoting into the Events view, and analysing all of the sessions, I come across the command I used to infect the endpoint, this event should stand out as odd due to the random capitalisation of the characters, which is an atempt to evade case sensitive detection machanisms, as well as the randomised Base64 encoded string, which is to hide the logic of the command:

 

Due to the obfuscation put in place by the creator, we cannot directly decode the Base64 in the UI, this is because the Base64 encoded string has been shuffled. For instances like this were large amounts of obfuscation are put in place, I like to let PowerShell decode it for me by replacing IEX (Invoke-Expression) with Write-Host - so rather than executing the decoded command, it outputs it to the terminal:

Always perform any malware analysis in a safe, locked down environment. The method of deobfuscation used above does not neccessarily mean you will not be infected when performing the same on other scripts.

After decoding the initial command, it appears there is more obfuscation put in place, so I do the same as before, replacing IEX with Write-Host to get the decoded command. This final deobfuscation is a PowerShell command to open a socket to a specified address and port - I now have my C2, and can use this information to pivot to the data in NetWitness Packets (if I had not found it before):

 

The above PowerShell was a subset of the first decoded command, the final piece of the PowerShell is a while loop that waits for data from the socket it opens, this is why the IEX alteration would not work here, it is just obfuscation by using multiple poorly named variables to make it hard to understand:

 

Flipping back over to the Investigation UI, and looking at other metadata under the BOC meta key, it is possible to see a range of values being created for the reconaissance commands that were executed over the C2:

 

As of 11.3, there is a new Analyze Process view (Endpoint: Investigating a Process), it allows us to visually understand the entire process event chain. Drilling into one of the events, and then using the Analyze Process function, it is possible to see all of the additional processes spawned by the malicious PowerShell process:

 

Conclusion

Analysing all traffic and protocols is important, it is true that some protocols will be (ab)used more than others, but excluding the analysis of traffic classified as OTHER, can leave malicious communications such as the one detailed in this blog post to go under the radar. Looking for items such as files transferred, cli commands, long connections, etc. can all help with dwindling down the data set in the OTHER bucket to potentially more interesting traffic.

Over the past year, I have posted multiple blogs whereby I perform APT (Advanced Persistent Threat) emulation and analyse the forensic footprint left behind after the attack using the NetWitness platform. In this post, I take a look at an adversary emulation framework from MITRE named CALDERA - Cyber Adversary Language and Decision Engine for Red Team Automation:

This framework allows you to automate the adversary based around the MITRE ATT&CK framework (https://attack.mitre.org/matrices/enterprise/), and takes out a lot of the preparation work required to setup the attack scenarios.

 

For the purposes of this post / demo, I used a service that exposes local servers behind NATs and firewalls to the public internet over secure tunnels. In this case, the service used is localhost.run (http://localhost.run/) - I've covered others in the past and all of these should be blocked for corporate environments. With this in mind I did not blur the URL in the screenshots, but I've since killed that connection so this address may now belong to someone else if you try to reach it, for security reasons I would suggest you don't.

 

This is not an attack framework like the other posts have covered, it is more of an emulation framework, however, this could be more suitable if you are just starting out in APT emulation and want to see what you can and can't detect. As like the other cases, in this post I will not go into detail on how to setup CALDERA as there is plenty of information regarding that already available.

 

Overview

CALDERA ships with an agent named Sandcat, also referred to as 54ndc47. This agent is written in GoLang for cross platform compatibility, and is the agent we will deploy on the endpoint(s) we want to execute our operations against. Navigating to the Sandcat plugin, we are presented with two options to deploy the agent.

  • Option one will generate commands on the fly for the specific operating system selected
  • Option two supplies a URL in which you can visit from the endpoint to download and execute Sandcat manually

 

For this blog post, I opted for the PowerShell command to deploy the agent. I ran this on my endpoint and you can see the connection was successful and it starts to beacon:

 

I chose one of the default adversaries, hunter, for my operation, the output of which can be seen below. A high level overview of this emulation is the search for sensitive files, which it collects, stages, and exfiltrates:

 

 

NetWitness Packets

Firstly, let's take a look into NetWitness Packets. Focusing on outbound traffic (direction='outbound') and the HTTP protocol (service=80), we can place a focal point on outbound HTTP communication. From here, we can view the characteristics of the HTTP traffic by opening up the Service Analysis meta key. Drilling into http suspicious 4 headers, http post no get, and http suspicious no cookie we are left with 20 events:

 

Next, we can start to view other metadata related to this traffic. Opening the Client Application meta key we can see a user agent of go-http-client/1.1 - this is because the agent is built on GoLang and it is not altered from the default. The server is Python/3.7 AIOHTTP/3.4.4, which is also worth noting. The filenames associated with this traffic are also interesting: instructions, results, and ping. These are very descriptive and are basically the agent receiving instructions, returning the results, or simply checking in:

 

This traffic could easily be picked up by adding the following logic to an application rule:

(client begins 'go-http-client') && (directory = '/sand/') && (filename = 'instructions','ping','results') && (server contains 'aiohttp')

            

 

Delving into the Event Analysis view, we can see Base64 encoded data in the body of the HTTP POST's. As of NetWitness 11 and upward, decoding Base64 can be done directly from within the UI by simply highlighting the text and selecting Decode Selected Text from the popup:

 

The Sandcat agent uses Base64 encoding for the whole instruction being sent to the endpoint, this instruction is in JSON format. The actual commands that will be executed are again Base64 encoded within the JSON record. To decode the commands within, I chose to run the additional Base64 through another tool called CyberChef (https://gchq.github.io/CyberChef/):

 

The traffic for Sandcat is very easy to detect in NetWitness Packets. It does not attempt to hide itself or blend in with normal traffic, this is most likely by design as this is not an attack framework, but an emulation framework.

 

NetWitness Endpoint

Drilling into boc = 'runs powershell' and boc = 'in root of users directory', we can see a file called, sandcat.exe, executing out of C:\Users\Public with arguments to connect to the CALDERA server, and we can see a large number of PowerShell commands being executed by it - these PowerShell commands are the commands executed by the sandcat agent to perform the operation laid out at the beginning of this post. The metadata writes executable to root of users directory, or evasive powershell used over network under the BOC meta key would've also led to sandcat.exe and all of its associated commands:

 

 

Custom Attack

The out of the box adversaries are great for getting to grips with CALDERA, but I decided to crank it up a notch and make my own. This operation involved some discovery of systems, dumping of credentials, and lateral movement as can be seen below. These were all out of the box operations, I just added them to make my own adversary:

 

Analysis

Delving into NetWitness Endpoint, we can see that there is a large quantity of metadata under the BOC meta key that tags all of the actions CALDERA performed:

 

CALDERA Ability ExecutedTechniqueNetWitness Metadata CreatedDescription

 

Find system network connections

T1057

enumerates network connectionsAdversaries may attempt to get information about running processes on a system. Information obtained could be used to gain an understanding of common software running on systems within the network.

Find user processes

 

T1049

queries users logged on local systemAdversaries may attempt to get a listing of network connections to or from the compromised system they are currently accessing or from remote systems by querying for information over the network.
Run PowerKatzT1003runs powershell with http argumentThe download of Mimikatz
Run PowerKatzT1003runs powershell downloading contentThe download of Mimikatz
Run PowerKatzT1003evasive powershell used over networkThe PowerShell command used to download Mimikatz
Run PowerKatzT1003powershell opens lsass processCredential dumping is the process of obtaining account login and password information, normally in the form of a hash or a clear text password, from the operating system and software. Credentials can then be used to perform Lateral Movement and access restricted information.
Net useT1077maps administrative shareAdversaries may use this technique in conjunction with administrator-level Valid Accounts to remotely access a networked system over server message block (SMB) to interact with systems using remote procedure calls (RPCs), transfer files, and run transferred binaries through remote Execution
Net useT1077lateral movement with credentials using net utilityThe lateral movement using net.exe and explicit credentials

 

To get a better view of the commands that took place, I like to open the Events view, from here I can see what was executed in an easier to read format:

 

Conclusion

Getting into APT emulation is not an easy task, CALDERA however, makes this a whole bunch easier. It is a great tool for testing your platforms abilities against the MITRE ATT&CK matrix and seeing what you can, and can't detect, as well as getting a better understanding as to how some of those techniques are actually performed; which will massively improve you as an analyst and improve your organisation defense posture. We only covered a subset of the available techniques, as the full content is too extensive to cover completely in a single post.

I was doing some hunting through our lab traffic today and came across some strange looking traffic, it turned out to be Rui Ataide playing around with a new DNS C2. It is named WEASEL and can be found here: GitHub - facebookincubator/WEASEL: DNS covert channel implant for Red Teams. From this, we decided to put together this quick blog post to go over how the traffic looks in NetWitness Packets, therefore, this is in a slightly different format to my usual posts in this topic. We may at some point update this to a full post if needed.

 

 

NetWitness Packets Analysis

As this tool uses DNS for its communication, we first need to place our focus on DNS traffic, we can do this with a simple query like so, service=53 - from here, I like to open the SLD (Second Level Domain) meta key and look for suspicious sounding SLD's, or SLD's that are quite noisy. From the screenshot below, doh stands out as a good candidate:

 

It is also a good idea to do the same with TLD to see if anything suspect stands out. We blurred out the domain we were using in this instance, but the .ml TLD should stand out as suspect as it is free to register and commonly used for malicious purposes:

 

Upon drilling into the suspect SLD (sld='doh'), we can then open the Hostname Alias Record meta key to see how many unique values are associated with that SLD. This type of DNS activity requires uniqueness in the requests it makes in order for the DNS queries not to be resolved by the cache, and this is why you would have a large number of unique alias.host values to a single SLD when performing this type of activity using the DNS protocol. This is depicted nicely by the below screenshot:

You would also typically see a large number of these DNS requests over a small period of time, however, this would be entirely dependent on the C2 and the beaconing interval set. For the above, the time range was over ~12 hours:

 

 

This traffic could easily be detected by using the following logic in an application rule:

(alias.host regex'^[0-9a-vx-z-]{2,52}w{0,6}\.[0-9a-f]{2}\.[0-9a-f]{4}\.') && (dns.querytype = 'aaaa record')

 

For other tools, the following regex should work too, it may however need some adaptation for each specific tool:

^[0-9a-vx-z-]{2,52}w{0,6}\.[0-9a-f]{2}\.[0-9a-f]{4}\.

 

With that being said, altering the behavior of C2 communications like WEASEL can easily be done, which would then mean this application rule / regex would not trigger, and thus why it is always important to review the behaviors of protocols and not rely solely on signatures.

 

Conclusion

DNS C2's are becoming a more prevalent way to exfiltrate information in and out of a network. It is a transmission medium that often gets forgotten about as most would tie malicious communications with protocols such as HTTP or SSL and tend to only block those. DNS in nature can be very noisy, more so in this case as there is a finite amount of information you can transfer in AAAA records, and by design WEASEL also opted for shorter query names to evade detection, both these in conjunction increase even further the amount of DNS traffic being generated. Additionally, DNS requests are also cached for a period of time, they therefore need to be unique and names can't easily be reused, in order to avoid them being resolved by a cache instead of making it back to the attackers infrastructure. This inherent noisy behavior of DNS C2 makes it slightly easier to detect when the right tools are in place.

UPDATE 31 Mar 2020: Amazon Detective has been made officially GA by AWS as of today!  See the notes at the end of this post for links to the official documentation with more details on usage and implementation.

 

Amazon Detective is an Amazon Web Services (AWS) threat hunting platform that offers a deep, cloud-native view of AWS resource data and history, optionally in the context of an AWS-generated alert (such as from Amazon GuardDuty).   Amazon Detective augments threat detection systems like RSA NetWitness Platform by providing details about the size and scope of AWS specific security threats, and to help reconstruct “security events” affecting cloud assets and infrastructure.

 

We are pleased to announce the release of a new RSA NetWitness Platform integration with Amazon Detective.  This integration will allow an analyst to pivot from a RSA NetWitness investigation directly into Amazon Detective to view the related AWS resource as needed.  In addition, any RSA NetWitness logs customers who are consuming AWS GuardDuty alerts can also pivot directly to a related finding in Amazon Detective.

 

 

 

 

Typical use case scenario for this integrationTypical use case scenario for this integration

 

 

This integration provides several benefits:

 

  • Reduced investigation time due to eliminating the manual pivot (RSA NetWitness takes you right to the entry)
  • Get the added cloud-native visibility of Amazon Detective to dive deeper into an investigation
  • Enable the analysts to use both tools for increased context around the incident, likely resulting in increased speed of investigations

 

How does the integration work?

Customers can enable this integration via the built-in custom context menu actions feature within RSA NetWitness.  These actions will show up when you right-click on an appropriate meta key's value (e.g. IP address, domain name, GuardDuty finding ID) within the Investigate view and Event Reconstruction view. 

 

Configuring a custom right-click action using the UI wizard

 

Configuring a custom right-click action using the UI wizard

 

Clicking one of these will open a new browser window directly into Amazon Detective and query the meta key value in the appropriate context.  From there the analyst can move around and investigate related data.

 

User pivoting on meta within the Events view

 

User pivoting on meta within the Events view

 

 

 

Landing page user is directed to by the browser

 

Landing page user is directed to by the browser

 

 

What kind of things can I pivot on?

There are a number of pivot options. Most searchable data points within Amazon Detective which have an equivalent meta key within RSA Netwitness Platform can be integrated.  Below are the types of entities we have identified as candidates to start with:

 

AWS Concept

RSA NetWitness Meta Key

Finding (id)

operation.id

Entity (IpAddress)

ip.src,ip.dst,alias.ip

Entity (AswAccount)  Accountid

reference.id1

Entity (AwsRole) Principalid

user.id

Entity (AwsUser) Principalid

user.id

Entity (UserAgent)

user.agent

Entity (Instanceid)

agent.id

  

Summary

Through tight UI integration, this enables RSA NetWitness analysts with a powerful addition to their threat hunting arsenal in Amazon Detective.  The integration is straightforward and easy to implement and customize and will save your analysts valuable investigation time.

 

Documentation

 

Good hunting!

  

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.serviceDescriptionReason
certificate long expirationCertificate expires more than two years since issued.Certificate validity is usually capped at two years. Longer-lived certificates may be suspicious.
certificate expiredCertificate was expired when presented.Expired certificates are invalid and won't be presented by most legitimate hosts.
certificate expired within last weekCertificate 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 dayCertificate 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 weekCertificate 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 monthCertificate was presented less than a month since issued.New certificates may be suspicious in combination with other characteristics of the session.
certificate anomalous issued dateCertificate issued date is malformed, nonsensical, or invalid.Invalid or malformed certificates are suspicious.
certificate anomalous expiration dateCertificate 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:

 

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:

 

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: Using RSA NetWitness to Detect 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.

Filter Blog

By date: By tag: