Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Lee Kirkpatrick
1 2 3 Previous Next

RSA NetWitness Platform

34 Posts authored by: Lee Kirkpatrick Employee

Table of Contents




Ransomware is something that’s haunted businesses for well over a decade, and now more than ever, detection for these attacks is something that should be prioritized by organizations. While reports have noted a slight decline in the number of ransomware attacks (Sophos 2020), they have now become highly targeted, more sophisticated, and deadly due to the value of the assets being encrypted.


How is Ransomware Deployed?

For ransomware to be as effective as possible, it must infect as many endpoints as possible, this means that ransomware is commonly deployed using techniques that allow for quick and easy distribution. Deployment methods could involve the following:


  • Microsoft SysInternals PsExec Utility
  • Group Policy Objects (GPOs)
  • System Center Configuration Manager (SCCM)


If the attacker has reached the stage where they are ready to distribute the ransomware, your detection of it will most likely occur once it starts encrypting your files, which is far too late. Prior to the deployment of the ransomware, the attacker must infiltrate the network, setup backdoors, harvest credentials, laterally move, and exfiltrate data – the attacker has to make a lot of noise to reach their end goal, and it is at these key points where defenders need to be detecting this attack. The dwell time from first signs of malicious activity to the deployment of ransomware can be as little as a few hours, so quick detection to prevent a successful attack is a must. The following figure shows an example flow of how a ransomware attack may play out:



Let's run through this and see how we can detect this with NetWitness.


Credential Harvesting

For an attacker to laterally move, they are going to need some credentials, these are typically obtained by dumping the memory of LSASS and using Mimikatz to extract the cleartext credentials from the dump. There are several methods an attacker can use to dump the memory of LSASS:


  • Microsoft Sysinternals ProcDump
  • Using the MiniDump function from comsvcs.dll
  • Custom applications (such as Dumpert)


Understanding these methods and how they manifest themselves in NetWitness is important for defenders, so they can quickly identify if these actions are occurring on their network.



ProcDump is a command line utility, and as such, will typically be executed via cmd.exe. The corresponding events for this would look similar to below, where cmd.exe launches the ProcDump binary with the command line arguments to dump LSASS memory and save it as a minidump:


We then see the ProcDump binary open lsass.exe in order to dump the memory:


This minidump would typically be exfiltrated from the network so the attacker can run Mimikatz against it to extract credentials. They do this activity offline as introducing Mimikatz into the network would most likely trigger antivirus and other detections. You should definitely monitor your AV logs for alerts of this type.


The activity above could be detected by adding the following application rule to your Endpoint Decoder(s):

procdump lsass dumpparam.src contains '-ma lsass' || param.dst contains '-ma lsass'
sysinternals tool usageparam.src contains '-accepteula' || param.dst contains '-accepteula'


Microsoft Sysinternal tools could also be detected by utilising the following query, file.vendor = 'sysinternals -':


As a defender, it would then be possible to identify malicious intent by analyzing the location and names of the binaries. For example, the screenshot below shows that the Sysinternal tool named, pd.exe, exists in the C:\PerfLogs\ directory, this should stand out as anomalous and be triaged:



This method has been around for quite some time but is seldom observed being utilized by attackers, however, it is a method to dump LSASS memory that should be monitored all the same. An example of how this may look is shown below, where we see a PowerShell command using rundll32.exe to utilize the MiniDump function to create minidump of LSASS:


We then see rundll32.exe open lsass.exe in order to dump the memory:


The activity above could be detected by adding the following application rule to your Endpoint Decoder(s):

comsvcs.dll lsass dumpparam.src contains 'comsvcs.dll MiniDump' || param.dst contains 'comsvcs.dll MiniDump'


Custom Applications

Custom applications can be made to dump the memory of LSASS using direct system calls and API unhooking. An example of a tool that does just that is, Dumpert. Tools such as this would commonly be executed by cmd.exe. From the below we can see that cmd.exe was used to run Outflank-Dumpert.exe, and subsequently Outflank-Dumpert.exe opens lsass.exe to dump the memory:


Activity from unsigned executables opening LSASS would be flagged by the meta value shown in the following figure. As a defender, all binaries flagged by this meta value should be investigated to confirm if they are legitimate or malicious:


If the LSASS minidump is transferred across the network via a cleartext protocol, and you have pushed the fingerprint_minidump Lua parser to your Packet Decoder(s), the following meta value would be created; which would be another great starting point for an investigation:


Lateral Movement

Once the attacker has credentials they can then begin to laterally move to endpoints in the network. There are a number of options an attacker has to move laterally, typically they are seen to use:


  • Remote Desktop Protocol (RDP)
  • Windows Management Instrumentation (WMI)
  • Server Message Block (SMB)


While all the above are used legitimately within an environment, it is important for defenders to understand how and where they are utilized to idenitfy anomalous usage.



RDP is a great way for attackers to laterally move, it provides an interactive graphical view of the endpoint they connect to and can easily blend in with normal day-to-day operations allowing it to go unnoticed by defenders. Typically, RDP logs are utilised when evidence of compromise is found. The attacker will be utilising one or more users and this information could then be utilised as a pivot point to identify lateral activity:

In order for the RDP event logs to be parsed as shown above, I added two dynamic log parser rules: Log Parser Customize: Log Parser Rules Tab 


The best log to monitor RDP activity is the Microsoft-Windows-TerminalServices-LocalSessionManager/Operational event log; an event ID of 21 will be a successful RDP connection. A great read to get a better handle on the event ID's related to RDP can be found here: Windows RDP-Related Event Logs: Identification, Tracking, and Investigation | Ponder The Bits.



Moving laterally to endpoints using WMI is a common technique adopted by attackers. Typically, usage of a tool named, WMIExec, is favoured. The following screenshot shows an example of how this tools usage looks in NetWitness Endpoint. From the below we can see the WMI provider service, WmiPrvSE.exe, executes cmd.exe and passes the parameters along with it:


Adding the following application rules to your Endpoint Decoder(s) would assist with detecting potentially malicious WMI usage:

wmiexecparam.dst contains '\\admin$\\__1'


The NetWitness Endpoint Decoder also comes with out of the box content to detect potentially malicious WMI usage:


Pivoting on these meta values would be a great way to detect possible attacker lateral movement, as a defender you would want to identify any atypical commands associated with the WMIC activity, an example of this is shown below, whereby the the attacker could use WMI to remotely execute commands on an endpoint using "process call create":


Remote WMI activity is also flagged in NetWitness Packets with the meta value, remote wmi activity. When process call create is utilised (CAR-2016-03-002: Create Remote Process via WMIC | MITRE Cyber Analytics Repository), the execmethod meta value will be populated under the action meta key. Identifying endpoints where this is taking place and typically does not, is another great starting point to identify potentially malicious WMI usage:



Lateral movement via SMB is typically performed with the net use command. It allows attackers to access a shared resource on a remote computer. Their favoured resources are typically the administrative shares, which commonly are C$, ADMIN$, D$. In order to identify if this type of activity is occurring in your environment keep an eye out for the following meta values:


A sample of the net use command to mount an administrative share is shown below:


As a defender you would want to pivot on these events and see what endpoints this activity is occurring on, from there you can perform timeline analysis on the endpoint to see what other activity took place around that time.




Once an attacker has breached a network they will need to maintain persistence. There are two primary ways that an attacker will do this:


  • Deploy a web shell to a public facing server
  • Deploy a Trojan to beacon back to a C2 server


A common method to detect C2's is via proactive hunting, which is something we have discussed in-depth on many occasions as part of the Profiling Attacker Series. We highly recommend reading through these posts to grasp C2 and web shell detection as they have been covered in-depth on a number of posts.


Another great resoure for identifying endpoints that are potentially infected with web shells or Trojans is the Microsoft-Windows-Windows Defender/Operational event log. Antivirus events are often overlooked but can be a great indicator to potential compromise as shown below, where Defender identified two web shells in the C:\PerfLogs\ directory:


Account Creation

Attackers may choose to create an account in order to push their ransomware or to laterally move. A common way for an attacker to create an account is with the net command. If the following meta value appears, it should be investigated to confirm if the user account creation was legitimate or not:

Pivoting on this meta value would give us some context as to what user was created and how. From the below we can see that lsass.exe executed net.exe to create an account named, helpdesk - this is indicative behaviour of the EternalBlue exploit:


If a user was adding via the command line it would look like the following. This is not to say that this is legitimate behaviour, but demonstrates the differences as to how a normal execution of net.exe would look:


For both of these events, the defender should perform anlaysis on the endpoint(s) in question and perform timeline analysis to look for further anomalous behaviour.


Some additonal useful application rules that could be deployed to detect anomalous behaviour by LSASS:

lsass writes exefilename.src = 'lsass.exe' && action = 'writetoexecutable'
lsass creates processfilename.src = 'lsass.exe' && action = 'createprocess'


From the account creation perspective, the Security event log would record a 4720 event ID along with information about the user that was created:


As a defender, you could pivot on = '4720' to analyse what user accounts were being created and where.


Ransomware Deployment

Ransomware can be deployed via a number of methods. The one we will cover here is deployment via PsExec. This is a common choice for attackers as it is a legitimate Microsoft tool that can be easily scripted to copy and execute files. Based on the way PsExec works, we can easily spot its activity based off of the following meta value:


Drilling into these events, we can see that PsExec.exe was used to connect to a remote endpoint. transfer a binary and execute it:


A useful application rule to further detect PsExec usage could be:

psexec usagefilename.dst = 'psexesvc.exe'


There are many clones os PsExec that work in a very similar to fashion, the following application rules should be added to help identify their usage within your envrionment:

remcom usagefilename.dst = 'remcomsvc.exe'
csexec usagefilename.dst = 'csexecsvc.exe'
paexec usagefilename.dst begins 'paexec'


From a Packet perspective, PsExec execution would be flagged under the Indicators of Compromise meta key. As a defender you would then need to determine if the PsExec activity is legitimateor not:


For a log perspective, the System event log records an event ID of 7045 (service creation) when PsExec is being used, as is shown below:


This is because PsExec and similar to tools utilise the service control manager (SCM) in order to function. For a better understanding of PsExec and how it works, please refer to the following URL:




What has been outlined above is merely an example of how a ransomware attack may unfold. Of course there are a myriad of tactics, techniques, and procedures (TTPs) an attacker will have in their arsenal that have not been outlined within this blog post, but this hopefully gives you a good starting point of how to use NetWitness to identify anomalous behaviours and prevent successful attacks. The further down you are in this process the higher the probabiity the attacker will succeed, if you are at the PsExec stage, it is already a bit too late. It should also be noted that the application rules listed in this blog may generate false positives, each envrionment is unique and the filtering as such should be performed on an individual basis.

Carrying on with the theme of Remote Access Tools (RATs), in this blog post will be covering Void-RAT. This tool is still in development and currently at alpha release so doesn't come with as many features as other RATs we've looked at, with that being said it still works quite nicely for controlling a remote endpoint. As always, check out the C2 Matrix for more details on its functionality.


The Attack

On our victim endpoint, we drop our compiled binary, client.exe, into the C:\PerfLogs\ directory and execute it:



After execution, it attempts to connect back to the C2 server, if successful it creates a slightly modified version of itself and stores it here: C:\Windows\Firewall\Firewall.exe - it then executes this binary which is the one that communicates back to the C2 server along with some information about the endpoint it is running on:


There are a number of options available to control the endpoint, but the most useful is the Remote CMD option. This allows us to execute commands remotely on the victim:



The Detection Using RSA Network

Void-RATs communication is in cleartext but uses a custom TCP protocol which is not directly understood by NetWitness. This means that the traffic gets tagged as OTHER, even though NetWitness does not understand the protocol, it will still analyse it. From the below screenshot, we can see that NetWitness has detected windows cli commands over some sessions using a suspect port:


Drilling into these sessions and reconstructing them, we can see the structure of the protocol used by Void-RAT, and the information that was sent to and from the victim:


Some more of the payload can be seen below. These commands are what NetWitness detected:


Void-RAT also reports back the public IP of the victim upon its initial check-in. It does this by making an HTTPS request to wtfismyip[.]com - this could also be used as a potential starting point for a hunt to find potentially compromised endpoints:

service = 443 && sld = 'wtfismyip'


These types of tools also require interaction from a remote operator, so at some point the attacker will perform actions that may supply additional indicators leading you to their presence. Here under the Indicators of Compromise meta key, we can see the meta value, hex encoded executable:



Drilling into this meta value and opening the events view to reconstruct the session, we can see that a hex encoded executable is being sent across the wire which uses the same proprietary protocol as Void-RAT, so even if we had not detected the RAT initially, we detected suspect behaviour, which led us to the RAT:



The Detection Using NetWitness Endpoint

Upon execution of Void-RAT, it sets up persistence for itself. It achieves this by creating a slightly modified version of itself here: C:\Windows\Firewall\Firewall.exe and modifies the \Current\Version\Run key to execute it upon boot. This behaviour was detected by NetWitness Endpoint and is shown as the two meta values in the following screenshot:



Drilling into these two meta values we can see these two events in more detail:



Changing our pivot in the Navigate view to focus on the new binary, filename.src = 'Firewall.exe', we can see that it is executing suspect commands (as shown under the Source Parameter meta key) and making network connections (as shown under the Context meta key):


Drilling into the network connections made by Firewall.exe, we can see the lookup performed to get the public IP of the victim using wtfismyip[.]com:


A simple application rule that could be created to look for this behaviour is shown below:

domain.dst = ''


We can also see the connection back to the C2, which would have given us a nice indicator to search and see if other endpoints are infected:



Similarly, as stated in the network detection, the tool is operated remotely and will at some point have to perform actions to achieve its end goal. The attacker transferred a hex encoded binary across the wire, but this cannot be executed by the system, so they used certutil (a LOLBin) to hex decode the file into an executable, which was detected under the Behaviours of Compromise meta key as shown below:




While many RATs seem to use custom TCP protocols to communicate, their behaviour is easily identifiable
with NetWitness. When hunting in network traffic make sure to spend some time on service = 0 - and
remember that a RAT has to do something in order to achieve its end goal, and those actions will be picked
up by NetWitness, so make sure to look for executables performing suspicious actions and
making network connections that you typically wouldn't expect for that endpoint. While this RAT does use a custom protocol, in a lot of cases, attackers exploit security controls in organizations that allow direct internet access on well-known common ports, like port 80/HTTP, 443/HTTPS, 22/SSH, etc. In these cases, NetWitness will also flag the unknown service on these ports. For more mature organizations, using NGFWs that do a certain level of protocol inspection before allowing traffic for well known services to flow through them, RATs like this would have some difficulty surviving, and therefore attackers are more prone to use tools that rely on standard protocols, which we have covered on some of the other posts.

Delving back into the C2 Matrix to look for some more inspiration for blog posts, we noticed there are a number of Remote Administration Tools (RATs) listed. So we decided to start taking a look at these RATs and see how we can detect their usage in NetWitness. This post will cover QuasarRAT which is an open-source, remote access tool that is developed in C#. It has a large variety of features for controlling the victim endpoint and has been used by a number of APT groups.


The Attack

QuasarRAT can be compiled in two modes, debug and release - for this blog post we compiled QuasarRAT in debug mode as it is the quickest and easiest way to get up and running. Once our agent had been compiled, we dropped it onto our victim endpoint in the C:\PerfLogs\ directory and executed:


Shortly after execution we get a successful connection back to QuasarRAT from our victim endpoint:


QuasarRAT has a large feature set, here we are using the Remote Shell feature to execute some commands:


There is also a file explorer that allows us to easily navigate the file system, as well as upload and download files:


It even has a Remote Desktop feature to view and control the endpoint:



The Detection Using NetWitness Network

QuasarRAT does not have an option for insecure communication and all traffic will be over SSL, it also uses a custom TCP protocol for its communication so if intercepted the protocol would be tagged as OTHER and you would have to look for indicators similar to those outlined in our CHAOS C2 post: Using RSA NetWitness to Detect Chaos C2.


Under the Service Analysis meta key, we get some interesting meta values generated regarding the certificate. QuasarRAT upon compilation generates a self-signed cert, this means the certificates age is low, as is identified by the certificate issued within last week meta value, and the self-signed meta value is, ssl certificate self-signed - you'll also notice that there is an ssl over non-standard port meta value, this is generated as the default port for QuasarRAT is 4782 (this is easily changed however and would more commonly be over 443 to bypass firewall restrictions). With that being said, these are some great pivot points to start a hunt in SSL traffic to look for suspect SSL communication:


Looking into the parsed data from the certificate, we can see that the SSL CA and SSL Subject identify this as a Quasar Server, which are the default values given to the certificate created by QuasarRAT: = 'quasar server ca' || ssl.subject = 'quasar server ca'


Another interesting meta value is located under the Versions meta key, where we can see that QuasarRAT uses an outdated version of TLS, tls 1.0 - this could be another starting point to look for this tool, or other applications using outdated protocols for that matter:


The SSL JA3 hash for this comes back as, fc54e0d16d9764783542f0146a98b300, which according to JA3 OSINT maps to, PowerShell 5.1;Invoke-WebRequest. While there is often overlap with JA3 hashes, it would still be a good place to start a hunt from:


On initial execution the RAT will also make an HTTP call to to obtain the public IP address of the endpoint. It would be worth hunting through the network traffic for requests to this domain and others that provide the same function:


The Detection Using NetWitness Endpoint

When we were setting up QuasarRAT, we modified the persistence settings to true, the following two meta values were generated based off of this. This is because QuasarRAT will copy itself to the \AppData\Roaming\ directory and use the \CurrentVersion\Run key to start it upon boot:


If you are using the new ATT&CK meta keys, we also see this persistence mechanism described there as well with the following meta values:


As stated in the network detection section, the RAT will make an HTTP connection to to get the public IP of the victim, we can also see that in the network endpoint data as shown below:


We can also drill into the meta value, console.remote, which is located under the Context meta key. This will show us commands executed by cmd.exe or powershell.exe as a result of inter-process communication through anonymous pipes, i.e. a reverse shell - here we can see client.exe executing suspect commands:


It is important to triage through all the commands executed in order to identify and follow the attackers intentions. An interesting command seen above is in relation to the esentutl.exe; this binary provides database utilities for the Extensible Storage Engine but can also be used to copy locked files for example. Drilling into this command, we can see it was used to copy the SAM hive (which is a locked file) to the C:\PerfLogs\ directory - it does this by using the volume shadow copy service (as noted by the /vss switch in the command below) to make a backup of the locked file which we are then able to copy:


This is an interesting LOLBin (Living off the Land Binary) as it would allow an attacker to copy any locked file from the system, this is activity that should be monitored and the following application rule logic would detect the usage of this command to copy files using the volume shadow copy service:

(filename.src = 'esentutl.exe' || filename.dst = 'esentutl.exe') && (param.src contains '/vss' || param.dst contains '/vss')

NOTE: Not all usage of esentutl.exe will necessarily be malicious, this could be a legitimate technique used by backup software for example. It is down to the defender to determine the legitimacy of the tool executing the command.




QuasarRAT has been around for some time and has been used in a number of targeted attacks against organizations and it is easy to see why. Remote access tools such as this pose a real risk to organizations and monitoring for their activity is paramount to ensuring the security of your network. It is also important as a defender that when these tools are found, that all command are triaged to gain a better understanding of the attackers intentions and end goal.

We are back again with another C2 framework called, Chaos: CHAOS is a PoC written in Go and comes with a healthy number of features for controlling the remote endpoints. It supports agents for Windows, Mac, and Linux, however, the feature availability does differ depending on the platform the agent is deployed on. This C2 only allows control of one agent, and all communication is over TCP sockets. More information surrounding this C2 can be found over at the C2 Matrix: C2Matrix - Google Sheets.


This C2 reminds a lot of one we previously covered called, HARS: Using RSA NetWitness to Detect HTTP Asynchronous Reverse Shell (HARS) - so check that post out as well if you haven't already.



The Attack

As always, we're keeping this super simple to place more of a focal point on the C2 traffic itself, rather than the delivery mechanism. So to deploy the agent, we simply copy the binary to the victim endpoint and execute it from the C:\PerfLogs\ directory:


After execution, we see our successful connection back to Chaos as is evident from the [+] Connected! message displayed:


Now we have our connection, we can use one of the available built-in features to set up persistence for Chaos to ensure it starts up again should the system reboot:


From here, we can start to execute commands to get information regarding the endpoint we are controlling:




The Detection Using NetWitness Network

Chaos has no direct support for HTTP and all communication between the C2 and the agent is over TCP sockets. As there is no structure to the traffic being generated, it is not possible to classify it under a specific service, so NetWitness tags this traffic as service = 0 - otherwise known as OTHER. The service OTHER is often overlooked as an area for hunting but should still be analysed by defenders to look for malicious traffic using proprietary protocols, or TCP sockets like Chaos. From the below, we can see that there are some meta values of interest for the Chaos C2 traffic that would stand out during the hunting process:

NOTE: The unknown service over http port meta value is interesting here, as attackers often use typical ports for web browsing to get around firewall policies that block everything but web access for endpoints.


Drilling into the possible base64 windows shell meta value, we can see the structure of the Chaos C2 traffic. The commands are sent as typed to the agent, but the output from the command is Base64 encoded and sent back to the C2, hence why NetWitness generated the possible base64 windows shell meta value:


This gives us the ability to easily observe the commands being executed, and to Base64 decode the output of the commands directly within the UI:


For this type of C2 there is no need to create additional detections for NetWitness Network, the detection is already there and just requires that defenders triage traffic of type OTHER where interesting meta values are generated, such as the ones shown here.



The Detection Using NetWitness Endpoint

As always, when these C2 frameworks are deployed, they have to execute and do things in order to achieve their end goal, and with NetWitness Endpoint it is easy to detect these actions. Below are the meta values generated from the small number of commands that were executed through the C2:


  • chaos > whoami - gets current username
  • chaos > tasklist - enumerates processes on local system
  • chaos > ipconfig - enumerates ip configuration
  • chaos > hostname - gets hostname
  • chaos > persistence_enable - runs registry tool, runs xcopy.exemodifies run key, modifies registry using command-line registry tool


Opening the Events view for the meta values of interest, we can get a better view of all the commands being executed:



The Detection Using NetWitness Logs

In order to better identify suspicious activities taking place on the endpoint, we have chosen to install Sysmon, and to include the detections available through its logging. More information surrounding Sysmon can be found at the following link: The collection of these logs is performed via the NetWitness Endpoint agent itself and more detail on how that was set up can be found here:


There are multiple starting points for using Sysmon to find malicious activities, but for now we are going to start with the following logic which would detect the usage of whoami being executed on a system, this is normaqlly evidence of attacker activity after successful exploitation or privilege escalation and is not overly common for most users to execute regularly:

(event.source = 'microsoft-windows-sysmon') && ( ends'whoami.exe') && ( = '1')

NOTE: The ='1' shown in the above query is for process creations.


Upon executing this query in NetWitness, we can see we get hits for the whoami command being executed from the C:\PerfLogs\ directory:


This is a suspicious directory for processes to be created from, so we can take a look at all processes being created out of this directory by slightly modifying our query to look for all process execution out of the C:\PerfLogs\ directory:

(event.source = 'microsoft-windows-sysmon') && (directory = 'c:\\perflogs\\') && ( = '1')


Here we can see a suspect executable running from the C:\PerfLogs\ directory named chaos.exe, and we can also see that there is a number of other suspicious commands being executed from this directory, as well:




We could also create an application rule that identifies the persistence that was created by looking for edits being made to the \CurrentVersion\Run key using the following logic:

(event.source = 'microsoft-windows-sysmon') && ( = '1') && (param contains 'reg  add hkcu\\software\\microsoft\\windows\\currentversion\\run')


NOTE: While we covered Sysmon as a free alternative to EDR, our recommendation would still be to use one, as Sysmon may require a considerable amount of configuration and tweaking, and will not provide as many capabilties or visibility as an EDR solution would. We covered it here just to offer an alternative for those that don’t use EDR.




Chaos C2 is an easy-to-use framework that gives the attacker great control over the victim endpoint, it does not provide much in terms of obfuscation and does not attempt to blend in with normal traffic, so this should make this an easy detection for defenders whether you have NetWitness Network, Endpoint or Logs. Just remember to not shy away from the traffic type OTHER when hunting through those packets!

A new C2 framework was recently added to the C2 Matrix called, Ninja. It was built on top of the leaked MuddyC3 framework used by an Iranian APT group called, MuddyWater. It can be run on Windows, Linux, macOS, and FreeBSD; the platform is built for speed, is highly malleable and feature rich. As usual, in this blog post will cover the detection of its usage using NetWitness Network and NetWitness Endpoint.


The Attack

Ninja creates a variety of payloads for you upon execution. In this instance, we just chose one of the PowerShell payloads and executed it on the victim endpoint:


A few seconds later we see our successful connection back to Ninja whereby a second stage payload is sent along, as well information about the victim endpoint:


We can see the information sent back from one of the initial HTTP POSTs by listing the agents:


Now we can change our focus to the agent, and start to execute commands against the endpoint:


The Detection Using NetWitness Network

Ninja C2 works over HTTP and currently has no direct support for SSL. This is in an attempt to blend in with the large quantities of HTTP traffic typically already present in an environment: the best place to hide a leaf is in the forest.


Ninja has a somewhat large amount of anomalies in regard to the HTTP requests it makes to and from the C2, a few of these have been highlighted below:

NOTE: While plenty of applications (ab)use the HTTP protocol, focusing on charateristics of more mechanical type behaviour can lead to us to sessions that are more worthy of investigation.


Another interesting element to Ninja is that for each agent a unique five character ID is generated. All requests from or to that agent are then in the form of, "AgentId-img.jpeg" - so from the below, we can tell that two agents are communicating with Ninja. You'll also notice that the requests it is making are for JPEG images, but none are actually returned. We can tell this as the File Type meta key is populated by a parser looking for the magic bytes of files, and it found no evidence of a JPEG in these sessions:



Another interesting artefact from Ninja is that it also returns encrypted commands in GET requests, and the associated encrypted response in POST requests; these can be seen under the Querystring meta key - the initial HTTP POST however, contains information about the system and is sent in the clear delimited by **:


Drilling into the Events view for the Ninja traffic, we can also see a defined beaconing pattern (we set this to two minutes upon setting up Ninja), as well as the fact that the beacons typically all have the same payload size:


Reconstructing the sessions from the beginning, we can see the initial communication with the Ninja C2, whereby it returns a second stage PowerShell payload:


This payload is somewhat large and is setting up the agent itself, the communication with the C2, encrypt and decrypt functions, as well as dynamically generating the AES key that should be used. Payloads such as this should be studied in-depth as they allow you to better understand the C2's function, and in this case, will allow us to decrypt the communication:


The next two pieces of information directly after the second stage payload are of importance, they contain information regarding the agent ID, details of the infected endpoint, as well as the encryption key that will be used; this is not a static key and is dynamically created for each agent:


Continuing the reconstruction of the sessions, we can see some Base64 encoded data, these are the AES encrypted commands and associated responses from them:


If you remember from earlier, we managed to identify the key that was used to encrypt this data. We also identified the second stage payload that was sent, this payload contained the PowerShell code for the agent which included the encryption and decryption functions for this data. We can simply use this to our advantage and create a simple decoder for this data:

#Ninja AES Key Returned From First HTTP POST to C2
#User passed data to decrypt

function CAM ($key,$IV){
try {$a = New-Object "System.Security.Cryptography.RijndaelManaged"
} catch {$a = New-Object "System.Security.Cryptography.AesCryptoServiceProvider"}
$a.Mode = [System.Security.Cryptography.CipherMode]::CBC
$a.Padding = [System.Security.Cryptography.PaddingMode]::Zeros
$a.BlockSize = 128
$a.KeySize = 256
if ($IV)
if ($IV.getType().Name -eq "String")
{$a.IV = [System.Convert]::FromBase64String($IV)}
{$a.IV = $IV}
if ($key)
if ($key.getType().Name -eq "String")
{$a.Key = [System.Convert]::FromBase64String($key)}
{$a.Key = $key}

$b = [System.Convert]::FromBase64String($enc)
$IV = $b[0..15]
$a = CAM $key $IV
$d = $a.CreateDecryptor()
$u = $d.TransformFinalBlock($b, 16, $b.Length - 16)


Executing the script and passing it the encrypted Base64 will decrypt the encrypted commands and associated responses allowing us to see what the attacker executed:


Based on Ninja being over HTTP by default, and the initial communication being in the clear, an application rule to pick up on this would look like the following:

(service = 80) && (action = 'post') && (query contains '**')


To detect further potential communication to and from Ninja C2 we could use the following application rule logic:

(service = 80) && (filename regex '^[a-z]{5}-img.jpeg') && (filetype != 'jpeg')


The Detection Using NetWitness Endpoint

Upon deploying Ninja, NetWitness Endpoint generates four Behaviours of Compromise, runs powershell, runs powershell decoding base64 string, and runs powershell with long arguments:


NetWitness Endpoint also generated meta values for the reconnaissance commands that were executed by the Ninja PowerShell agent:

  • C:\>whoami: gets current username
  • C:\>quser: queries users logged on local system
  • C:\>tasklist: enumerates proceses on local system


This is an important point to note, that even if you miss the initial execution, the malicious process will still have to do something in order to achieve its end goal, and as a defender, you only need to pick up on one of those activities to pull the thread back to the beginning.


Drilling into the Events view for the meta value, runs powershell decoding base64 string, we can see the Base64 encoded PowerShell command to initiate the connection to Ninja, we can also Base64 decode this within the UI to obtain other information such as the C2 IP:


Drilling into the Events view for the other meta values identified, we can see that a FILELESS_SCRIPT, spawned from the initial PowerShell command, is executing the reconnaissance command, tasklist:




New C2 frameworks are constantly being developed but all fall prey to the same detection mechanisms. It just comes down to you, as a defender, to triage the data the system presents to you to look for anomalies in processes doing things they shouldn't.

I have recently been posting a number of blogs regarding the usage of the RSA NeWitness Platform to detect attackers within your environment. As the list of the blogs grow, it is becoming increasingly difficult to navigate through them easily. In order to combat this, this blog post will contain references to all other blog posts in the Profiling Attackers Series, and will be updated when new posts are made.









Special thanks to Rui Ataide for his support and guidance for these posts.

I recently reviewed HTTP Asynchronous Reverse Shell (HARS) for The C2 Matrix, which should be posted soon! They also have a Google Docs spreadsheet here: C2Matrix - Google Sheets. I’ve been following them for awhile and have tried to map as may of the frameworks as possible from a defensive perspective. This blog post will therefore cover just that, how to use RSA NetWitness to detect HARS.


The Attack

After editing the configuration files, we can compile the executable to run on the victim endpoint. After executing the binary we get the default error message, which is configurable, but we left it with default settings:


The error message is a ruse and the connection is still made back to the C2 server where we see the successful connection from our victim endpoint:


It drops us by default into a prompt where we can begin to execute our commands, such as whoamiquser, etc:


Detection Using NetWitness Network

By default HARS uses SSL, so to see the underlying HTTP traffic, we used a MITM proxy to intercept the communication; it is highly advisable to introduce SSL interception into your own envrionment. Within this post, we will also cover the anomalies with the communication over SSL.



An interesting meta value generated for the HARS traffic is, http invalid cookie - this meta value looks for HTTP cookies that do not follow RFC 6265:


Drilling into the Events view for these sessions before reconstructing them, we can observe that there is a beacon type pattern to the connections with some jitter, and also a low variance in the payload for each request - this indicates that this is a more mechanical type check-in behaviour:


Reconstructing the events and looking at the cookie for the requests, we can see what looks like Base64 data:



Using the built-in Base64 decoding, we can see that this decodes to HELLO. While this is not indicative of malicious activity, this is still a malformed cookie and a rather strange value:


From here, we can continue to go through the traffic and decode the values supplied within the cookie header. The next few cookies contain the text QVNL, which returns ASK when Base64 decoded:


Eventually we come across a cookie with a Base64 encoded version of what looks like the ouput from a whoami command:


As well as one that contains the output from a quser command. Both these look rather suspicious and this is information that normally shouldn't be sent to a remote host, especially in this manner as a cookie value:


Looking through the request prior to the one that returns the output of quser, and sifting though the payload, there is a Base64 encoded quser command within it:


This C2 framework disguises its commands within legitimate looking pages in an attempt to evade detection by analysts, but is easily detected with NetWitness using a single meta value, http invalid cookie.

NOTE: It is important to remember that many applications abuse the HTTP protocol and do not follow RFC's, it is therefore possible for legitimate traffic to have inavlid cookies, it is down to the defender to determine whether the activity is malicious or not, but NetWitness points you to these anomalies and makes it easier to focus on traffic of interest.


This C2 is highly malleable and therefore the following application rule would only pick up on its default configuration, however, attackers tend to be lazy and leave many of the default settings for these tools. This would allow us to easily create an application rule to detect this behaviour:

cookie = 'QVNL','SEVMTE8='


In order for the application rule to work, you would need to register the cookie HTTP header. This involves using the customHeaders() function within the HTTP_lua_options file as described on the community:


One of our previous posts also covered registering the cookie HTTP header into a meta key and can be found on the community:




As previously stated, HARS uses SSL to communicate by default. When HARS initially connects back to the C2 from the victim endpoint, it attempts to blend in with typical traffic to www[.]bing[.]com. The below screenshot shows the malicious traffic (on the left), and the legitimate traffic to Bing (on the right). Playing spot the difference, we can see a few anomalies as highlighted below:


This allows us to create logic to detect possible HARS usage with the following application rule:

service = 443 &&'' &&'microsoft corporation' && ssl.subject='microsoft corporation'


And we can also create an application rule to look for anomalous Bing certificates, this would, however, be lower fidelity in order to detect a broader range of suspicious cases to aid in threat hunting:

service = 443 && = '' && not('' &&'microsoft corporation','baltimore' && ssl.subject='')


Detection Using NetWitness Endpoint

HARS uses PowerShell to execute the commands on the victim endpoint, but does not use any form of obfuscation. Therefore in NetWitness Endpoint, we can see multiple hits under the Behaviours of Compromise meta key for the reconaissance commands executed, quser, whoami, and tasklist:


Drilling into those meta values, we can see an executable named, hars.exe, running out of a suspect directory and executing reconaissance type commands:


Pivoting on the filename, hars.exe, (filename.src = 'hars.exe'), which really could be any other name, but would still be launching your commands, we can see all the events from this suspect executable, such as the commands it executed under the Source Parameter meta key:


After every command executed, HARS adds the following, echo flag_end. We can use this to our advantage to create an application rule to detect its behaviour:

category = 'console event' && param.src ends 'echo flag_end'


Another neat indicator comes under the Context meta key, here we can see four interesting meta values associated with, hars.exe - console.remote, network.ipv4, network.nonroutable, and network.outgoing - these meta values tell us that this executable is making an outbound network connection and running console commands:


Drilling into the Events view for the network meta values, we can see where the executable is connecting to:


And drilling into the console.remote meta value, we can see the commands that were executed:


So from a defenders perspective, it could be a good idea to use the filter, context = 'console.remote' - and look for suspicious executables:



Not all C2 frameworks use advanced methods of obfuscation or encryption, some rely on confusing analysts by trying to blend in with normal traffic by mimicking legitimate web sites. It is important as a defender to spot these anomalies and fully analyse the traffic, even if it at first glance appears to be normal, and remember, the attacker would probably think none of this really matters as the attack is over SSL and this data would not be visible to analysts, which is where having SSL interception is a great advantage for analysts, it really catches attackers out.

Lee Kirkpatrick

What's updog?

Posted by Lee Kirkpatrick Employee Mar 16, 2020

Updog is a replacement for Python's SimpleHTTPServer. It allows uploading and downloading via HTTP/S, can set adhoc SSL certificates and use HTTP basic auth. It was created by sc0tfree  and can be found on his GitHub page here. In this blog post we will use updog to exfiltrate information and show you the network indicators left behind from its usage.


The Attack

We are starting updog with all the default settings on the attacker machine, this means it will expose the directory we are currently running it from over HTTP on port 9090:


In order to quickly make updog publicly accessible over the internet, we will use a service called, Ngrok. This service exposes local servers behind NATs and firewalls to the public internet over secure tunnels - the free version of Ngrok creates a randomised URL and has a lifetime of 8 hours if you have not registered for a free account:


This now means that we can access our updog server over the internet using the randomly generated Ngrok URL, and upload a file from the victims machine:


The Detection using NetWitness Network

An item of interest for defenders should be the use of services such as Ngrok. They are commonly utilised in phishing campaigns as the generated URLs are randomised and short lived. With a recent update to the DynDNS parser from William Motley, we now tag many of these services in NetWitness under the Service Analysis meta key with the meta value, tunnel service:



Pivoting into this meta value, we can see there is some HTTP traffic to an Ngrok URL, an upload of a file called supersecret.txt, a suspicious sounding Server Application called werkzeug/1.0.0 python/3.8.1, and a Filename with a PNG image named, updog.png:



Reconstructing the sessions for this traffic, we can see the updog page as the attacker saw it, and we can also see the file that was uploaded by them:



NetWitness also gives us the ability to extract the file that was transferred to the updog server, so we can see exactly what was exfiltrated:


Detection Rules

The following table lists an application rule you can deploy to help with identifying these tools and behaviours:






Packet Decoder

Detects the usage of Updog

server begins 'werkzeug ' && filename = 'updog.png '





As a defender, it is important to monitor traffic to services such as Ngrok as they can pose a significant security risk to your organisation, there are also multiple alternatives to Ngrok and traffic to those should be monitored as well. In order for the new meta value, tunnel service to start tagging these services, make sure to update your DynDNS Lua parser.

A zero-day RCE (Remote Code Execution) exploit against ManageEngine Desktop Central was recently released by ϻг_ϻε (@steventseeley). The description of how this works in full and the code can be found on his website, We thought we would have a quick run of this through the lab to see what indicators it leaves behind.


The Attack

Here we simply run the script and pass two parameters, the target, and the command - which in this case is using cmd.exe to execute whoami and output the result to a file named si.txt:


We can then access the output via a browser and see that the command was executed as SYSTEM:


Here we execute ipconfig:


And grab the output:


The Detection in NetWitness Packets

The script sends a HTTP POST to the ManageEngine server as seen below. It targets the MDMLogUploaderServlet over its default port of 8383 to upload a file with controlled content for the deserialization vulnerability to work, in this instance the file is named The command to be executed can also be seen in the body of the POST:

The traffic by default for this exploit is over HTTPS, so you would need SSL interception to see what is shown here.


This is followed by a GET request to the file that was uploaded via the POST for the deserialization to take place, which is what executes the command passed in the first place:


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

(service = 80) && (action = 'post') && (filename = 'mdmloguploader') && (query begins 'udid=') || (service = 80) && (action = 'get') && (directory = '/cewolf/')


The Detection Using NetWitness Endpoint

To detect this RCE in NetWitness Endpoint, we have to look for Java doing something it normally shouldn't, as this is what ManageEngine uses. It is not uncommon for Java to execute cmd, so the analyst has to look into the commands to understand if it is normal behaviour or not - from the below we can see java.exe spawning cmd.exe and running reconaissance type commands, such as whoami and ipconfig - this should stand out as odd:


The following application rule logic could be used to pick up on this activity. Here we are looking for Java being the source of execution as well as looking for the string "tomcat" to narrow it down to Apache Tomcat web servers that work as the backend for the ManageEngine application, the final part is identifying fileless scripts being executed by it:

(filename.src ='java.exe') && (param.src contains'tomcat') && (filename.dst begins '[fileless','cmd.exe')

Other java based web servers will likely show a similar pattern of behavior when being exploited.




As an analyst it is important to stay up to date with the latest security news to understand if you organisation could potentially be at risk of compromise. Remote execution vulnerabilities such as the one outlined here can be an easy gateway into your network, and any devices reachable from the internet should be monitored for anomalous behaviour such as this. Applications should always be kept up to date and patches applied where available ASAP to avoid becoming a potential victim.

This post is going to cover a slightly older C2 framework from Silent Break Security called, Throwback C2. As per usual, we will cover the network and endpoint detections for this C2, but we will delve a little deeper into the threat hunting process for NetWitness as well.


The Attack

After installing Throwback and compiling the executable for infection, which in this case, we will just drop and execute manually. We will shortly see the successful connection back to the Throwback server:


Now we have our endpoint communicating back with our server, we can execute typical reconaissance type commands against it, such as whoami:


Or tasklist to get a list of running processes:


This C2 has a somewhat slow beacon that by default is set to ~10 minutes, so we have to wait that amount of time for our commands to be picked up and executed:



Detection Using NetWitness Network

To begin hunting, the analyst needs to prepare a hypothesis of what it is they believe is currently taking place in their network. This process would typically involve the analyst creating multiple hypotheses, and then using NetWitness to prove, or disprove them; for this post, our hypothesis is going to be that there is C2 traffic - these can be as specific or as broad as you like, and if you struggle to create them, the MITRE ATT&CK Matrix can help with inspiration.


Now that we have our hypothesis, we can start to hunt through the data. The below flow is an example of how we do exactly that with HTTP:

  1. Based on what we are looking for defines the direction. So in this case, we are looking for C2 communication, which means our direction will be outbound (direction = 'outbound')
  2. Secondly, you want to focus on a single protocol at a time. So for our hypothesis, we could start with SSL, if we have no findings, we can move on to another protocol such as HTTP. The idea is to navigate through them one by one to separate the data into smaller more manageable buckets without getting distracted (service = 80)
  3. Now we want to hone in on the characteristics of the protocol, and pull it apart. As we are looking for C2 communication, we would want to pull apart the protocol to look for more mechanical type behaviour - one meta key that helps with this is Service Analysis - the below figure shows some examples of meta values created based off HTTP


A great place to get more detail on using NetWitness for hunting can be found in the RSA NetWitness Hunting Guide: RSA NetWitness Hunting Guide PDF.


From the Investigation view, we can start with our initial query looking for outbound traffic over HTTP, and open the Service Analysis meta key. There are a fair number of meta values generated, and all of them are great places to start pivoting on, you can choose to pivot on an individual meta value, or multiple. We are going to start by pivoting on three, which are outlined below:

  • http six or less headers: Modern day browsers typically have seven or more headers. This could indicate a more mechanical type HTTP connection
  • http single response: Typical user browsing behaviour would result in multiple requests and responses in a single TCP connection. A single request and response can indicate more mechanical type behaviour
  • http post no get no referer: HTTP connections with no referer or GET requests can be indicative of machine like behaviour. Typically the user would have requested one or more pages prior to posting data to the server, and would have been referred from somewhere


After pivoting into the meta values above, we reduce the number of sessions to investigate to a more manageable volume:


Now we can start to open other meta keys and look for values of interest without being overwhelmed by the enormous amount of data. This could involve looking at meta keys such as Filename, Directory, File Type, Hostname Alias, TLDSLD, etc. Based off the meta values below, the domain de11-rs4[.]com stands out as interesting and something we should take a look at; as an analyst, you should investigate all domains you deem of interest:


Opening the Events view for these sessions, we can see a beacon pattern of ~10 minutes, the filename is the same everytime, and the payload size is consistent apart from the initial communication which could be a download of a second stage module to further entrench - this could also be legitimate traffic and software simply checking in for updates, sending some usage data, etc.:


Reconstructing the events, we can see the body of the POST contains what looks like Base64 encoded data, and in the response we see a 200 OK but with a 404 Not Found message and a hidden attribute which references cmd.exe and whoami:

The Base64 data in the POST is encrypted, so decoding it at this point would not reveal anything useful. We may, however, be able to obtain the key and encryption mechanism if we had the executable, keep reading on to see!


Similarly we see another session which is the same but the hidden attribute references tasklist.exe:

The following application rule logic would detect default Throwback C2 communication:
service = 80 && analysis.service = 'http six or less headers' && analysis.service = 'http post no get no referer' && filename = 'index.php' && directory = '/' && query begins 'pd='

This definitely stands out as C2 traffic and would warrant further investigation into the endpoint. This could involve directly analysing all network traffic for this machine, or switching over to NetWitness Endpoint to analyse what it is doing, or both.


NOTE: The network traffic as seen here would be post proxy, or traffic in a network with no explicit proxy settings (


Detection Using NetWitness Endpoint

As per usual, I start by opening the compromise keys. Under Behaviours of Compromise (BOC), there are multiple meta values of interest, but let's start with outbound from unsigned appdata directory:


Opening the Events view for this meta value, we can see that an executable named, dwmss.exe, is making a network connection to de11-rs4[.]com:


Coming back to the investigation view, we can run a query to see what other activity this executable is performing. To do this, we execute the following query, filename.src = 'dwmss.exe' - here we can see the executable is running reconaissance type commands:


From here we decide to download the executable directly from the machine itself and perform some analysis on it. In this case, we ran strings and analysed the output and saw there were a large number of references to API calls of interest:


There is also a string that references RC4, which is an encryption algorithm. This could be of potential interest to decrypt the Base64 text we saw in the network traffic:


RC4 requires a key, so while analysing the strings we should also look for potential candidates for said key. Not far from the RC4 string is something that looks like it could be what we are after:


Navigating back to the packets and copying some of the Base64 from one of the POST's, we can run it through the RC4 recipe on CyberChef with our proposed key; in the output we can see the data decoded successfully and contains information about the infected endpoint:


Now we have confirmed this is malware, we should go back and look at all the activity generated by this process. This could be any file that it has created, files dropped around the same time, folders it may be using, etc.



C2 frameworks are constantly being developed and improved upon, but as you can see from this C2 which is ~6 years old, their operation is fairly consistent with what we see today, and with the way NetWitness allows you to pull apart the characteristics of the protocol, they can easily be identified.

In this post we will cover CVE-2019-0604 (, albeit a somehwhat older vulnerability, it is one that is still being exploited. This post will also go a little further than just the initial exploitation of the Sharepoint server, and use EternalBlue to create a user on a remote endpoint to allow lateral movement with PAExec; again, this is an old, well-known vulnerability, but something still being used. We will then utilise Dumpert to dump the memory of LSASS ( and obtain credentials, and then employ atexec from Impacket ( to further laterally move.


The Attack

The initial foothold on the network is obtained is via the Sharepoint vulnerability (CVE-2019-0604). We will use the PoC code developed by Voulnet ( to drop a web shell:


In the above command we are targetting the vulnerable Picker.aspx page, and using cmd to echo a Base64 encoded web shell to a file in C:\ProgramData\ - we then use certutil to Base64 decode the file into a publicly accessible directory on the Sharepoint server and name it, bitreview.aspx.


To access the web shell we just dropped onto the Sharepoint server, we are going to use the administrative tool, AntSword ( Here we add the URL to the web shell we dropped, and supply the associated password:


Now we can open a terminal and begin to execute commands on the server to get a lay of the land and find other endpoints to laterally move to:


The AntSword tool has a nice explorer view which allows us to easily upload additional tools to the server. In this instance we upload a scanner to check if an endpoint is vulnerable to EternalBlue:


Now we can iterate through some of the endpoints we uncovered earlier to see if any of them are vulerable to EternalBlue:


Now that we have uncovered a vulnerable endpoint, we can use this to create a user that will allow us to laterally move to it. Using the PoC code created by Worawit (, we can exploit the endpoint and execute custom shellcode of our choosing. For this I compiled some shellcode to create a local administrative user called, helpdesk. I uploaded my shellcode and EternalBlue exploit executable and ran it against the vulnerable machine:


Now we have created a local administrative user on the endpoint, we can laterally move to it using those credentials. In this instance, we upload PAExec, and Dumpert, so we can laterally move to the endpoint and dump the memory of LSASS. The following command copies the and executes the Outflank-Dumpert.exe using PAExec and the helpdesk user we created via EternalBlue:


This tool will locally dump the memory of LSASS to C:\Windows\Temp - so we will mount one of the administrative shares on the endpoint, and confirm if our dump was successful:


Using AntSwords explorer, we can easily navigate to the file and download it locally:


We can then use Mimikatz on the attackers' local machine to dump the credentials which may help us laterally move to other endpoints:


We decide to upload the atexec tool from Impacket to execute commands on the remote endpoint to see if there are other machines we can laterally move to. Using some reconaissance commands, we find an RDP session using the username we pulled from the LSASS dump:


From here, we could continue to laterally move, dump credentials, and further own the network.


Detection using NetWitness Network

NetWitness doesn't always have to be used for threat hunting, it can also be used to search for things you know about, or have been currently researching. Taking the Sharepoint RCE as an example, we can easily search using NetWitness to see if any exploits have taken place. Given that this is a well documented CVE, we can start our searching by looking for requests to picker.aspx (filename = 'picker.aspx'), which is the vulnerable page - from the below we can see two GET requests, and a POST for Picker.aspx (inbound requests directly to this page are uncommon):

Next we can reconstruct the events to see if there is any useful information we can ascertain. Looking into the HTTP POST, we can see the URI matches what we would expect for this vulnerability, we also see that the POST parameter, ctl00$PlaceHolderDialogBodySection$ctl05$hiddenSpanData, contains the hex encoded and serialized .Net XML payload. The payload parameter also starts with two underscores which will ensure the payload reaches the XML deserialization function as is documented:


Seeing this would already warrant investigation on the Sharepoint server, but lets use some Python so we can take the hex encoded payload and deserialize it to see what was executed:


From this, we have the exact command that was run on the Sharepoint server that dropped a web shell. This also means we now know the name of the web shell and where it is located, making the next steps of investigation easier:

As analysts, it sometimes pays to do these things to find additional breadcrumbs to pull from, although be careful, as this can be time consuming and other methods can make it a lot easier, like MFT analysis that is described later on in the blog post.


This means we could search for this filename in NetWitness to see if we have any hits (filename = 'bitreview.aspx'):


As you can see from the above highlighted indicators, even without knowing the name of the web shell we would have still uncovered it as NetWitness created numerous meta values surrounding its usage. A fairly recent addition to the Lua parsers available on RSA Live is, fingerprint_minidump.lua - this parser creates the meta value, minidump, under the Filetype meta key, and also creates the meta value, lsass minidump, under the Indicators of Compromise meta key. This parser is a fantastic addition as it tags LSASS memory dumps traversing the network, which is uncommon behaviour.


Reconstructing the events, we can see the web shell traffic which looks strikingly similar to China Chopper. The User-Agent is also a great indicator for this traffic, which is the name of the tool used to connect to the web shell:


We can Base64 decode the commands from the HTTP POST's and get an insight into what was being executed. The below shows the initial POST which returns the current path, operating system, and username:


The following shows a directory listing of C:\ProgramData\ being executed, which is where the initial Base64 encoded bitreview.aspx web shell was dropped:


We should continue to Base64 decode all of these commands to gain a better understanding of what the attacker did, but for this blog post I will focus on the important pieces of the traffic. Pivoting into the Events view for the meta value, hex encoded executable, we can see the magic bytes for an executable that have been hex encoded:


Extracting all the hex starting from 4D5A (MZ header in hexadecimal) and decoding it with CyberChef, we can clearly see this is an executable. From here, we could save this file and perform further analysis on it:


Continuing on with Base64 decoding the commands we come across something interesting, it is the usage of a tool called eternalblue_exploit7.exe against an endpoint in the same network. This gives the defender additional information surrounding other endpoints of interest to the attacker and endpoint to focus on:

If you only have packet visibility, you should always decode every command. This will help you as a defender better understand the attackers actions and uncover additional breadcrumbs. But if you have NetWitness Endpoint, it may be easier to see the commands there, as we will see later.


Knowing EternalBlue uses SMB, we can pivot on all SMB traffic from the Sharepoint server to the targetted endpoint. Opening the Enablers of Compromise meta key we can see two meta values indicating the use of SMBv1; this is required for EternalBlue to work. There is also an meta value of not implemented under the Error meta key this is fairly uncommon and can help detect potential EternalBlue exploitation:


Reconstructing the events for the SMBv1 traffic, we come across a session that contains a large sequence of NULLs, this is the beginning of the EternalBlue exploit and these NULLs essentially move the SMB server state to a point where the vulnerability exists:


With most intrusions, there is typically some form of lateral movement that takes place using SMB. As a defender we should iterate through all possible lateral movement techniques, but for this example I want to see if PAExec has been used. To do this I use the following query (service = 139 && filename = 'svcctl' && filename contains 'paexe'). From the below, we can see that there is indeed some PAExec activity. By default, PAExec also includes the hostname of where the activity occured from, so from the below filenames, we can tell that this activity came from SP2016, the Sharepoint server. We can also see that a file was transferred, as is indicated by the paexec_move0.dat meta value - this is the Outflank-Dumpert.exe tool:


Back in the Investigation view, under the Indicators of Compromise meta key, we see a meta value of lsass minidump. Pivoting on this value, we see the dumpert.dmp file in the temp\ directory for the endpoint that was accessed over the ADMIN$ share - this is our LSASS minidump created using the Outflank-Dumpert.exe tool:


Navigating back to view all the SMB traffic, and focusing on named pipes (service = 139 && analysis.service = 'named pipe'), we can see a named pipe being used called atsvc. This named pipe gives access to the AT-Scheduler Service on an endpoint and can be used to scheduled tasks remotely. We can also see some .tmp files being created in the temp\ directory on this endpoint with what look like randomly generated names, and window cli admin commands associated with one of them:


Reconstructing the events for this traffic, we can see the scheduled tasks being created. In the below screenshot, we can see the XML and the associated parameters passed, in this instance using CMD to run netstat looking for RDP connections and output the results to %windir%\Temp\rWLePJvp.tmp:


This is lateral movement behaviour via Impackets tool, atexec. It writes the output of the command to a file so it can read it and display back to the attacker - further analysing the payload, we can see the output that was read from the file and gain insight into what the attacker was after, and subsequently endpoints to investigate:



Detection using NetWitness Endpoint

As always with NetWitness Endpoint, I like to start my hunting by opening the three compromise keys (IOC, BOC, and EOC). In this case, I only had meta values under the Behaviours of Compromise meta key. I have highlighted a few I deem more interesting with regards to this blog, but you should really investigate all of them:


Let's start with the runs certutil with decode arguments meta value. Opening this in the Events view, we can see the parameter that was executed, which is a Base64 encoded value being echo'ed to the C:\ProgramData\ directory, and then certutil being used to decode it and push it to a directory on the server:


From here, we could download the MFT of the endpoint:


Locate the file that was decoded, download it locally, and see what the contents are:


From the contents of the file, we can see that this is a web shell:


We also observed the attacker initially drop a file in the C:\ProgramData\ directory, so this is also a directory of interest and somewhere we should browse to within the MFT - here we uncover the attackers tools which we could download and analyse:


Navigating back to the Investigate view and opening the meta value http daemon runs command prompt in the Events view, we can see the HTTP daemon, w3wp.exe, executing reconaissance commands on the Sharepoint server:

This is a classic indicator for a web shell, whereby we have a HTTP daemon spawning CMD to execute commands.


Further analysis of the commands executed by the attacker shows EternalBlue executables being run against an endpoint, after this, the attacker uses PAExec with a user called helpdesk to connect to the endpoint - implying that the EternalBlue exploit created a user called helpdesk that allowed them to laterally move (NOTE: we will see how the user creation via this exploit looks a little later on):


Navigating back to Investigate, and this time opening the Events view for creates local user account, we see lsass.exe running net.exe to create a user account called, helpdesk; this is the EternalBlue exploit. LSASS should never create a user, this is a high fidelity indicator of malicious activity:


Another common attacker action is to dump credentials. Due to the popularity of Mimikatz, attackers are looking for other methods of dumping credentials, this typically involves creating a memory dump of the LSASS process. We can therefore use the following query (action = 'openosprocess' && filename.dst='lsass.exe'), and open the Filename Source meta key to look for something opening LSASS that stands out as anomalous. Here we can see a suspect executable opening LSASS named, Outflank-Dumpert.exe:


As defenders, we should continue to triage all of the meta values observed. But for this blog post, I feel we have demonstrated NetWitness' ability to detect these threats.


Detection Rules

The following table lists some application rules you can deploy to help with identifying these tools and behaviours:





Packet Decoder

Requests of interest to Picker.aspx

service = 80 && action = ‘post’ && filename = 'picker.aspx' && directory contains '_layout'


Packet Decoder

AntSword tool usage

client begins 'antsword'


Packet Decoder

Possible Impacket atexec usage

service = 139 && analysis.service = 'named pipe' && filename = 'atsvc' && filename ends 'tmp'


Packet Decoder

Dumpert LSASS dump

fiilename = 'dumpert.dmp'


Packet Decoder

Possible EternalBlue exploit

service = 139 && error = 'not implemented' && eoc = 'smb v1 response'


Packet Decoder

PAExec activity

service = 139 && filename = 'svcctl' && filename contains 'paexe'



Endpoint Log Hybrid

Opens OS process LSASS

action = 'openosprocess' && filename.dst='lsass.exe'


Endpoint Log Hybrid

LSASS creates user

filename.src = ‘lsass.exe’ && filename’dst = ‘net.exe’ && param.dst contains’ /add’




Threat actors are consistently evolving and developing new attack methods, but they are also using tried and tested methods as well - there is no need for them to use a new exploit when a well-known one works just fine on an unpatched system. Defenders should not only be keeping up to date with the new, but also retroactively searching their data sets for the old.

A couple of months ago, Mr-Un1k0d3r released a lateral movement tool that solely relies on DCE/RPC ( This tool does not create a service and drop a file like PsExec or similar tools would do, but instead uses the ChangeServiceConfigA function (and others) to edit an existing service and have it execute commands; making this a fileless lateral movement tool.


SCShell is not a tool designed to provide a remote semi-interactive shell. It is designed to allow the remote execution of commands on an endpoint utilising only DCE/RPC in an attempt to evade common detection mechanisms; while this tool is slightly stealthier than most in this category, it’s also a bit more limited in what an attacker can do with it.


When we first looked at this, we didn't have much in terms of detection, but with a prompt response from William Motley from our content team, he produced an update to the DCERPC parser that is the basis of this post.


The Attack

In the example screenshot below, I run the SCShell binary against an endpoint to launch calc.exe, while this is of no use to an attacker, it is just an example that we can use to visually confirm the success of the attack on the victim machine:



It could also be used to launch a Metasploit reverse shell, for example, as shown in the screenshot below. We will cover some of the interesting artifacts leftover from this execution in a seperate post. Obviously, this is not something an attacker would do, in their case something like launching an additional remote access trojan or tool would be more likely:


SCShell edits an existing service on the target endpoint, it does not create a new one. Therefore the service needs to already exist on the target. In the above example, I use defragsvc as it is a common service on Windows endpoints.


RSA NetWitness Network Analysis

There was a recent update to the DCERPC parser that is available via RSA NetWitness Live (thanks to Bill Motley), this parser now extracts the API calls made over DCE/RPC - which can be useful in detecting suspect activity over this protocol. If you have setup your subscriptions correctly for this parser (which you should have), it will be updated automatically, otherwise you will have to push it manually.


So, to start my investigation (as per usual) I take a look at my compromise meta keys and notice a meta value of, remote service control, under the Indicators of Compromise [ioc]

 meta key. This is an area that should be regularly explored to look for anomalous activity:


Pivoting on this meta value and opening up the action and filename meta keys, we can see the interaction with the svcctl interface that is being used to call API functions to query, change, and start an existing service:



  • StartServiceA - Starts a Service
  • QueryServiceConfigA - Retrieves the configuration parameters of the specified service.
  • OpenServiceAOpens an existing service
  • OpenSCManagerWEstablishes a connection to the service control manager on the specified computer and opens the specified service control manager database
  • ChangeServiceConfigAChanges the configuration parameters of a service


The traffic sent over DCE/RPC is encrypted, so reconstructing the sessions will not help here, but given that we have full visibility we can quickly pivot to endpoint data to get the answers we need. The following logic would allow you to identify this remote service modification behaviour taking place in your environment and subsequently the endpoints of interest for investigation:

service = 139 && filename = 'svcctl' && action = 'openservicea' && action = 'changeserviceconfiga' && action = 'startservicea'


RSA NetWitness Endpoint Analysis

A great way to perform threat hunting on a dataset is by performing frequency analysis, this allows us to bubble up outliers and locate suspect behaviour with respect to your environment - an anomaly in one environment, can be common in another. This could be done by looking for less common exectuables being spawned by services.exe in this instance - the following query would be a good place to start, device.type='nwendpoint' && filename.src='services.exe' && action='createprocess' - we would then open up the Filename Destination meta key and see a large number of results returned:



Typically, we tend to view the results from our queries in descending order, in this instance, we want to see the least common, so we switch the sorting to ascending to bubble up the anomalous executables. Now we can analyse the results and as shown in the screenshot below, we see a couple of interesting outliers, the calc.exe, and the cmd.exe:



Pivoting into the Events view for cmd.exe, we can see it using mshta to pull a .hta file, clearly this is not good:



This activity whereby services.exe spawns a command shell is out of the box content, and can be found under the Behaviors of Compromise [boc] meta key, so this would also be a great way to start an investigation as well:



Now that we have suspect binaries of interest, we have files and endpoints we could perform further analysis on to get our investigation fully underway, but for this post I will leave it here.



It is important to ensure that all your content in NetWitness is kept up to date - automating your subscriptions to Lua parsers for example, is a great start. It ensures that you have all the latest metadata being created from the protocols, and improves your ability as a defender to hunt and find malicious behaviours.


It is also important to remember that while sometimes there may not be a lot of activity from the initial execution of say a binary, at some point, it will have to perform some activity in order to achieve its end goal. Picking up on said activity will allow defenders to pull the thread back to the originating malicious event.

DNS over HTTPS (DoH) was introduced to increase privacy and help prevent against the manipulation of DNS data by utilising HTTPS to encrypt it. Mozilla and Google have been testing versions of DoH since June 2018, and have already begun to roll it out to end-users via their browsers, Firefox, Mozilla, and Chrome. With the adoption rates of DoH increasing, and the fact that C2 frameworks using DoH have been available since October 2018, DoH has become an area of interest for defenders; one C2 that stands out is goDoH by SensePost (


goDoH is a proof of concept Command and Control framework written in Golang that uses DNS-over-HTTPS as a transport medium. Currently supported providers include Google and Cloudflare, but it also contains the ability to use traditional DNS.


The Attack

With goDoH, the same binary is used for the C2 server, and the agent that will connect back to it. In the screenshot below, I am setting up the C2 on a Windows endpoint - I specify the domain I will be using, the provider to use for DoH, and that this is the C2:



On the victim endpoint I do the same, but instead specify that this is the agent:



After a short period of time, our successful connection is made, and we can begin to execute our reconnaissance commands:



RSA NetWitness Platform Network Analysis: SSL Traffic

Given its default implementation using SSL, there is not a vast amount of information we can extract, however, that does not mean that we cannot locate DoH in our networks. A great starting point is to look at who currently provides DoH - after some Googling I came across a list of DoH providers on the following GitHub page:



These providers could be converted into an application rule (or Feed) to tag them in your environment, or utilised in a query to retroactively view DoH usage in your environment. This would help defenders to initially pinpoint DoH usage: ends '','','','','','','','','','','','','','','','','','','','','','','','','','','','','','',''

NOTE: This is by no means a definitive list of DoH providers. You can use the above as a base, but should collate your own.


Running this query through my lab, I can see there is indeed some DoH activity for the Cloudflare provider:

As this traffic is encrypted, it is difficult to ascertain whether or not it is malicious, but there are a couple of factors that may help us. Firstly, we could reduce the meta values to a more manageable amount by filtering on long connection, which is under the Session Analysis meta key, this is because C2 communications over DoH would typically be long lived:



We could then run the JA3 hash values through a lookup tool to identify any outliers (in this instance I am left with one due to my lab not capturing a lot of data):


For details on how to enable JA3 hashes in the RSA NetWitness Platform, take a look at one of our previous posts: Using the RSA NetWitness Platform to Detect Command and Control: PoshC2 v5.0 

Running the JA3 hash (706ea0b1920182287146b195ad4279a6) through OSINT (, we get results back for this being Go-http-client/1.1, this is because the goDoH application is written in Golang - this stands out as an outlier and the source of this traffic would be a machine to perform further analysis on:




RSA NetWitness Platform Network Analysis: SSL Intercepted Traffic

Detecting DoH when SSL interception is in place becomes far easier. DoH requests for Cloudflare, for example

, supply a Content-Type header that allows us to easily identify it (besides the value):


Also determining whether the DoH connections are malicious becomes far easier when SSL interception is in place, this is because it allows defenders to analyse the payload that would typically be encrypted. The following screenshot shows the decrypted DoH session between the client and Cloudflare - here we are able to see the DNS request and response in the clear, which divulges the C2 domain being used, We can also see that the JA3 hash we previously reported was correct, as the User-Agent is Go-http-client/1.1:



The session for this DoH C2 traffic is quite large, so I am unable to show it all - this is due to the limited amount of information that can be transmitted via each DNS query. An example of data being transmitted via an A record can be seen below - the data is encrypted so won't make sense by merely viewing it:



Within this session there are hundreds of requests for the domain with a very high variability in the FQDN seen in the name parameter of the query; this is indicative behaviour of C2 communication over DNS. Below I have merged five of the requests together in order to help demonstrate this variability:



Given the use of TCP for HTTPS vs the common use of UDP for DNS, the traffic shows as a single session in the RSA NetWitness Platform due to TCP session/port reuse, normally this type of activity would present itself over a larger number of RSA NetWitness Platform sessions when using native DNS.


RSA NetWitness Endpoint Analysis

Looking at my compromise keys, I decide to start my triage by pivoting into the Events view for the meta value, runs powershell with http argument as shown below.



From the following screenshot, we can see an executable named, googupdater.exe, running out of the users AppData directory is executing a PowerShell command to get the public IP of the endpoint. We also get to see the parameter that was passed to the googupdater.exe binary that reveals the domain being contacted:


NOTE: googupdater.exe is the goDoH binary and was renamed for dramatic effect.

We could have also pivoted on the outbound from unsigned appdata directory meta value which would have led us to this suspect binary, as well. While from an Endpoint perspective this is just another compiled tool communicating over HTTPS, the fact that it will need to spawn external processes to execute activity would lead us to an odd parent process:



Given this scenario in terms of Endpoint, this would lead us back to common hunting techniques, but in the interest of brevity, I won't dig deeper for this tool. The key items would be an uncommon parent process for some unusual activity, and the outbound connections from an unsigned tool. While both can at times be noisy, in conjunction with other drills, they can be narrowed down to cases of interest.



This post further substantiates the requirement for SSL interception as it vastly improves the defenders capability to investigate and triage potentially malicious communications. While it is still possible to identify suspect DoH traffic without SSL interception, it can be incredibly difficult to ascertain its intentions. DNS is also a treasure trove for defenders, and the introduction and use of DoH could vastly deplete the ability for them to protect the network effectively.

A couple of days ago on Github, Hackndo released a tool ( that is capable of dumping the memory of LSASS using LOLBins (Living of the Land Binaries) - typically we would see attackers utilising SysInternals ProcDump utility to do this. Lsassy uses the MiniDump function from the comsvcs.dll in order to dump the memory of the LSASS process; this action can only be performed as SYSTEM, so it therefore creates a scheduled task as SYSTEM, runs it and deletes it.


We decided to take this tool for a spin in our lab and see how we would detect this with NetWitness.


The Attack

To further entrench themselves and find assets of interest, an attacker will need to move laterally to other endpoints in the network. Reaching this goal often involves pivoting through multiple systems, as well as dumping LSASS to extract credentials. In the screenshot below, we use the lsassy tool to dump credentials from a remote host that we currently have access to:


The output of this command shows us the credentials for an account we are already aware of, but also shows us credentials for an account we previously did not, tomcat-svc.


NetWitness Network Analysis

I like to start my investigation every morning by taking a look at the Indicators of Compromise meta key, this way I can identify any new meta values of interest. Highlighted below is one that I rarely see (of course in some environments this can be a common activity, but anomalies of what endpoints this takes place on can be identified):


Reconstructing the session, we can see the remote scheduled task that was created and analyse what it is doing. From the below screenshot, we can see the task created will use CMD to launch a command to locate LSASS, and subsequently dump it to \Windows\Temp\tmp.dmp using the MiniDump function within the comsvcs.dll:


cmd.exe /C for /f "tokens=1,2 delims= " ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do C:\Windows\System32\rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump ^%B \Windows\Temp\tmp.dmp full

This task also leaves other artifacts of interest behind. From the screenshot below, we can see the tmp.dmp LSASS dump being created and read:


This makes the default usage of lsassy easy to detect with simple application rule logic such as the below. Of course the names and location of the dump can be altered, but attackers typically tend to leave the defaults for these types of tools:

service = 139 && directory = 'windows\\temp\\' && filename = 'tmp.dmp'


NetWitness Endpoint Analysis

Similarly with Endpoint, I like to start my investigations by opening up the Compromise meta keys - IOC, BOC, and EOC. From here I can view any meta values that stand out, or iteratively triage through them. One of the meta values of interest from the below is, enumerates processes on local system:

Pivoting into the Events view for this meta value, we can see cmd.exe launching tasklist to look for lsass.exe - to get proper access, the command is also executing with SYSTEM level privileges - this is something you should monitor regularly:


After seeing this command, it would be a good idea to look at all activity targeted toward LSASS for this endpoint. To do that, I can use the query filename.dst = 'lsass.exe' and start to investigate by opening up meta keys like the ones below. Something that stands out as interesting is the usage of rundll32.exe to load a function called minidump from the comsvcs.dll:

Pivoting into the Events view, we can see the full command a lot easier. Here we can see that rundll32.exe is loading the MiniDump function from comsvcs.dll and passing some parameters, such as the process ID for dumping (which was found by the initial process enumeration), location and name for the dump, and the keyword full:


This activity could be picked up by using the following logic in an application rule. This will be released via RSA Live soon, but you can go ahead and implement/check your environment now:

device.type = 'nwendpoint' && category = 'process event' && (filename.all = 'rundll32.exe') && ((param.src contains 'comsvcs.dll' && param.src contains 'minidump') || (param.dst contains 'comsvcs.dll' && param.dst contains 'minidump')



It is important to consistently monitor network and endpoint behaviour for abnormal actions taking place, and not solely rely on out of the box detections. New attack methods/tools are consistently being devleoped, but the actions these tools take always leave footprints behind, it is down to the defender(s) to spot the anomalies and triage accordingly. With that being said, RSA are consistently updating detections for attacks such as the one laid out in this post - we have been working with the content team to have this tool usage detected with out of the box content.

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 ( 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:



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.

Filter Blog

By date: By tag: