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

Malspam activity was noted this week delivering Hawkeye to infected machines. Hawkeye is a commodity keylogger that can be used to steal a victim sensitive information. This threat advisory will discuss its delivery mechanism and will show how the traffic looks in NetWitness Logs and Packets.


This delivery document has an embedded malicious macro that launches a powershell script. Submitting the document to What's This File service shows a high threat score:



The powershell script is used to download an executable from a delivery domain. An infection scenario that's shared among different malspam campaigns. Here is the process tree:



Here's the download session in NetWitness Logs and Packets:



Using the "View Files" option to get the checksum of the downloaded file:



This report from suggests it is a Hawkeye variant. The hunting pack registered the following meta for this download session indicating highly suspicious traffic:



The fact that the executable is recently compiled can also be noticed when submitting the file to What's This File service:



It is worth mentioning that this domain directlink[.]cz has been used to deliver different kinds of malware. Here is the activity in NetWitness Logs and Packets for this week:



While the directory remained the same, filenames varied from one download session to another:




Here is a list of some of the delivered payloads (SHA256):




This delivery domain was added to RSA FirstWatch Command and Control Domains on Live with the following meta values:

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

Further reading:

1. How I Cracked a Keylogger and Ended Up in Someone's Inbox 

2. Piercing the HawkEye: How Nigerian Cybercriminals Used a Simple Keylogger to Prey on SMBs - Security News - Trend Micro… 

3. The “HawkEye” attack: how cybercrooks target small businesses for big money – Naked Security 

Malspam activity was noted on June 26th 2017, delivering Emotet banking trojan. It leverages malicious Word documents with embedded macros.


Scan results of a delivery document can be found here. An attacker can easily lure the victim to run the embedded macro:



Submitting the delivery document to What's This File service shows its maliciousness:



Upon running the macro launches a powershell script to download and run the malware. Here is the process tree:



Here is the GET request in NetWitness Logs and Packets, as well as the file checksum using the "View Files" option of the download session:




The Hunting pack registered the following meta values for the download sessions indicating highly suspicious traffic:



Analysis results on VirusTotal suggest the final payload is an Emotet variant, a banking trojan that has been around since 2014.


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

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


Further reading:

  1. more invoice malspam with links to download word doc deliver malware – My Online Security 
  2. New Variant of Geodo/Emotet Banking Malware Targets UK | Forcepoint 

After few days of inactivity, this malspam campaign is back and yesterday it was delivering Locky ransomware. The campaign is known for using PDF attachments with embedded malicious Word documents. 


Here is the traffic for a download session in NetWitness Logs and Packets:



Note that an obfuscated file is first downloaded to an infected machine:



Once the download is complete, it is de-obfuscated and the final payload is saved to the same directory:



The checksum of the final payload is shown below:



Analysis results on VirusTotal suggest it is a Locky ransomware variant. mentions that this Locky variant would run only on a Windows XP machine.


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





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

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

Malspam campaign activity was noted yesterday, June 22nd, 2017, and was delivering Lokibot.  Malicious attachment "Quotation.doc" (probably generated by AKbuilder) was noted in sample attachments, which attempts to exploit CVE-2012-0158 and then download its payload from nioustech[.]com, hosted on 143[.]95[.]230[.]12.


lokibot delivery


lokibot delivery


Lokibot is a commodity info-stealer that creates a registry entry and then attempts to steal credentials (e.g., ssh, ftp, email, browser, etc) and even log keystrokes.  In the case that infection occurs, exfil has been observed out to [RANDOM URL]/fre.php.  


'What's This File' (WTF) analysis of our lokibot payload reveals some oddities from static analysis, including a number of blank file property fields (as shown below) and indication that this is a recently compiled file.                       


WTF lokibot


As far as NetWitness packet detection, Lokibot  exhibits several generically inherently malicious file characteristics, which are flagged in the NetWitness 10.6.3 screenshot below.


lokibot nw detection


Readers may want to also reference recent FirstWatch work on Dyzap, which is commonly observed in the same or related campaigns.  




For the past few weeks, there has been an increase in malspam delivering Zyklon malware. Zyklon is available for sale on the Darknet and is capable of launching various types of DDoS attacks, data theft and fraud [1] [2]. In this threat advisory, we will shed some light on its delivery mechanism.


Let’s take this delivery document from June 21, 2017 [3] seen in the wild as Sean-Resume.doc. An attacker can easily trick a victim into running the embedded malicious macro.



Upon running the macro launches a powershell script to download and run the malware. Here is the process tree:



Here is the download session from NetWitness Packets and Logs:



The checksum of the downloaded executable can be obtained using the “View Files” option:



Analysis results on VirusTotal suggest it is a Zyklon variant [4].


The malicious network behavior is easily detected using NetWitness Packets and Logs. Here are some of the meta values registered by the Hunting pack for the download sessions since mid-May [5]:



It is worth mentioning that over the same period of time, the filename in those download sessions has been constantly changing:



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

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




The scripts are designed to upload parsers from linux(.sh) or windows(.bat) by means of NwConsole.

I hope these will help you.


*Please use at your own risk*

Cerber Ransomware has again taken the cyber world by storm by taking over 87% share in terms of cyber-attacks in 1st Quarter of 2017, and it remains the most profitable ransomware in the market for close to a year now.  Now a little over a year after its first variants were found in the wild, Cerber developers have released their 6th edition codebase, which boasts a slew of new of improvements.  


Specifically Cerber has added new encryption patterns, and anti-VM and anti-sandboxing features, which have raised the bar for researchers (and also automated systems) to detonate and identify the new ransomware.  These new features combined with varied distribution channels show that the Cerber crew is taking ransomware development to the next level, making it by far the most dangerous ransomware on the market today.


Here is some of the previous research from RSA about Cerber Ransomware and its Evolution:


The following chart shows features of different Cerber versions:



Cerber v1, v2 and v3

Cerber v4

Cerber v5

Cerber SFX

Cerber v6

File Type




SFX (Loader) VBS, DLL


Exceptions (Cerber doesn’t execute if it detects certain components in the system)

Language in v1 and v3*

Language and antivirus (AV) for v2*



AV, VM, Sandbox (Loader*), and Language*


Anti-AV Routine





EXE files of AV, Firewall and Antispyware products set to be blocked by Windows firewall rules*





VM and Sandbox (Loader*)

VM and Sandbox (Loader*)

Backup Deletion

Yes (vsadmin, WMIC, BCDEdit)*

Yes (WMIC)*

Yes (WMIC)*


Removed in v5.02

 Varies (some samples have backup deletion capabilities)

Varies (some samples have backup deletion capabilities)

Exclusion List 
(directories and file types Cerber doesn’t encrypt)

Folder and file*

Folder and file*

Folder and file*; and AV, Antispyware, and Firewall directories

Folder and file*; and AV, Antispyware, and Firewall directories

Folder and file*

*Cerber RaaS Configurable


Exploit kits and Malspam emails are the two major delivery vectors for Cerber today. In the case of exploit kits, a compromised site or malvertising often redirects victims to a malicious landing page that downloads and executes a payload.  With regard to malspam, a victim is typically tricked (and clicks on a link) to download and run js, ps1 or sfx files, which eventually inject and execute the ransomware payload. 

Following diagram shows delivery of Cerber in brief:



Until May 2017, Cerber was heavily using RigEK over malspam campaigns to deliver Cerber infections; yet, after combined efforts of researchers and domain registrar, GoDaddy, a massive amount of Rig-related shadow domains were taken down during Operation Shadowfall. Post Shadowfall, the group’s distribution vector changed over to more malspam-centric campaigns for delivering the Cerber payload. The delivery of Cerber via the ‘Blank Slate’ campaign in 2nd quarter of 2017is evidence to this fact, and a diagram of the infection vector is below.



‘Blank Slate’ delivery is through spam emails with subjects like “Unusual Sign-In Activity”, “Chrome Update”, “Delivery Invoice” etc.  Unwitting victims are tricked into clicking on a link provided or button to download a zip file, which on extraction injects a .js, .doc, or .ps1 script to download and install the Cerber payload.






RTF file with Macros are also used to trigger ransomware delivery, and a great explanation of both RTF and the recent MS 2017-10 zero day can by RSA’s own Kevin Douglas can be found here




New variants of Cerber also show some different but unique patterns in post exploitation traffic. UDP beaconing ports are changed along with some new payment site alias hosts. After April 2017, Cerber payment sites, patterns and UDP port (which is now 6893, previously 6892) changed.

RSA Netwitness Live Content for detection can detect newest variants of Cerber beaconing.  An updated Event Stream Analysis (ESA) rule looks for a spray of outbound suspected command and control (C2) traffic via UDP to port 6892, 6893 from a single source IP to multiple destinations IPs (within the same netblock).




NetWitness Packet also has an application rule that detects Cerber pay-site patterns, correlating on the ransomware’s embedded configuration files for the set up of bitcoin wallets for each victim. This rule matches when the '' (packet) or 'fqdn' (web logs) begins with one of the identified pay-sites.

Meta Keys:

  • Risk Warning = cerber ransomware
  • Indicators of Compromise = cerber ransomware




All the IOCs are added to the following feeds on Live:

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



Thanks goes to Kevin Stear for contributing to this threat advisory.





Blank Slate campaign was noted as active and delivering Cerber ransomware yesterday, June 15th, 2017.  Malicious attachments "PO.doc" and "build.doc" noted in the malspam delivery.


This campaign has been previously noted with multiple delivery vectors.  This was again seen in yesterday's campaign, where one of the two delivery methods failed to retrieve the payload from www[.]host[.]com, which is still being served from 104[.]27[.]137[.]194.

cerber infection fail 404

cerber infection fail 404


In this instance, the second delivery method succeeded in retrieving a payload from oooweqwnenwqew[.]net, which is still currently being served from 193[.]34[.]93[.]145.

cerber infection

cerber infection


Payload is Cerber "2150342-107-0_1.panse.exe", which executes and then checks in to establish payment methods via a p27dokhpz2n7nvgr[.]12nwsw[.]top, a Tor2Web proxy hosted on 184[.]170[.]243[.]164

cerber check in

cerber check in


Post infection, noted Cerber UDP spray outbound to,, on port 6893.

cerber UDP spray to port 6893


Current NetWitness detection flags both payment domain (key.dga.tld pattern) as 'cerber ransomware' and the UDP spray as 'cerber beaconing' in the <Indicators of Compromise> meta field.  Additionally, <File Analysis> flags for 'js eval no docwrite' and 'exe filetype but not exe extension' should be noted as indicators of possibly malicious files.


NW cerber beaconing detection

Dridex is a banking Trojan that steals a victim’s credentials in order to commit fraudulent financial transactions. In May, RSA FirstWatch published a threat advisory discussing a Dridex variant that spread through well-crafted Word documents targeting exploit CVE-2017-0199 [1].


In this blog we will take a look at another Dridex delivery mechanism, Word documents with macros. We will discuss how to leverage the Hunting pack to detect its network behavior using RSA NetWitness Packets and Logs. In addition, the threat advisory will shed some light on the suspicious host behavior detected by RSA NetWitness Endpoint.


Let’s take this delivery document as an example [2], the attacker tries to trick the victim into running the malicious macro:



When the macro runs, it launches a powershell script to download the malware from its delivery domain and saves it to the user %TEMP% directory. Once the download is complete, a new process is created which injects code into a system process then deletes itself. Here is the process tree after running the delivery document:



Similar information can be found by running the same delivery document on another machine with a NetWitness Endpoint agent installed on it:


Here is a screenshot of a download session in NetWitness Packets and Logs:



Using the “View Files” option for this session shows the checksum and size of the downloaded executable:



NetWitness Endpoint gives us even more information about the PE file including its static characteristics, its location on the infected machine before it was deleted.



Looking up the file hash on VirusTotal suggests it is a Dridex variant [3].


Finally, NetWitness Endpoint shows the injected code into spoolsv.exe:


The malicious host behavior is captured by the machine IIOC’s. Some of them are displayed below:



Detection using Hunting pack:


The Hunting pack is designed to allow you to quickly hunt for indicators of compromise or anomalous network activity by dissecting packet traffic within the NetWitness Suite and populating specific meta keys with natural language values for investigation. For more information on the hunting pack including how to deploy it in your environment, please refer to RSA documentation [4].


Given the network artifacts we know so far, let’s run a query to narrow down the results in NetWitness Packets and Logs:

analysis.session = 'first carve' && analysis.session = 'first carve not dns' && service = 80 && action = 'get' && filename = 'styles.bin' && client !exists


The first two conditions in the query analysis.session = 'first carve' && analysis.session = 'first carve not dns’ help in focusing the investigation on non-DNS, outbound sessions that have two streams and payload greater than zero. Please keep in mind that the packet decoder in this case is used to monitor the network traffic of a relatively small environment in RSA FirstWatch lab, results in a real environment might vary and the query might need further tweaking.



The Hunting pack tags the download sessions with more meta values indicating a highly suspicious network behavior. Let’s try to understand what some of those values mean:

  • http two headers: In a typical user browsing session, the fields in HTTP headers are populated by the browser. Thus having only two fields in the header is not normal. Among the missing fields is the User-Agent string itself indicated here by the meta value http no user-agent
  • http direct to ip request: It is uncommon for a regular user to use an IP address instead of a domain name while browsing.
  • watchlist file extension: Extensions that are commonly used with malware were detected in the session. In this case the filename extension .bin
  • watchlist file fingerprint: File formats that are commonly used in malware. In this case a PE file fingerprint.
  • exe file type but no exe extension: Sessions where EXE files are downloaded warrant further investigation to check if the activity is legitimate or not. In this case, not only an executable is being downloaded but also has a misleading extension.

For an explanation of the rest of the meta values generated in those sessions, please refer to RSA documentation [4].


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

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

If you are interested in more Hunting pack use cases, please check this community post on RedLeaves malware and this one on delivery documents.


Thanks to Christopher Ahearn for helping with this threat advisory.



  1. Bank on it with the Dridex Trojan 
  2. Antivirus scan for f13b2b7b53bc7c1ca3ca4fa5181f2283edc6820710d8412952447b58e3c3d257 at2017-06-05 01:30:25 UTC - VirusTot… 
  3. Antivirus scan for 2b4cf6aec98d90cca1d7f8607ee16001fa928b8cc5af5624625a284619391d29 at2017-06-07 16:20:26 UTC - VirusTot… 
  4. RSA NetWitness Hunting Guide 

Many cyber threats have already been identified, and RSA NetWitness has been actively delivering content related to these identified threats. The content required to hunt these threats are in the form of different resource types such as feeds, parsers, application rules and so on.

The RSA NetWitness Known Threats Pack enables analysts to deploy all the content required to identify and hunt known threats efficiently. The Known Threats pack contains a set of content specific to known identified threats such as malware, crimeware, RAT campaigns, and so on.  When the pack is deployed, all the content with dependencies is automatically deployed. Analysts can then efficiently hunt previously known threats and keep track of known malicious IPs, domains and potentially compromised systems on the network.



You can deploy all of the items in the Known Threat Pack through Live. To deploy:

From the Security Analytics menu, click Live > Search.

In the Resource Type field, select Bundle.


Select the Known Threat Pack.

   You can view the details page if you wish:




Select Deploy, then follow the steps in the wizard.

The Deployment Wizard lists the resources that are in the bundle.


Select the service or services on which to deploy the bundle.


Review your selections.


Click Deploy. Progress is shown in the dialog box, until completion.


Click Close to exit the wizard.



Threat Hunting and Investigation:

With all required content deployed to hunt known threats, analysts can now start looking for alerts, anomalous network activity and meta generated using various LUA parsers and rules.  Keys to look for to start hunting and drilling down on to validate the alerts are Indicator of Compromise, Behaviors of Compromise, Enablers of Compromise, Session Analysis, Service Analysis, File Analysis and investigation meta. In depth protocol analysis which involves looking at headers user agents, host-names aliases and request codes will help further validating the alerts. More about this: Hunting guide -



Investigation meta is used to provide a means to classify all logs and sessions in support of investigations and remediation. This is useful for front line analysts, because it minimizes the time dedicated to mining logs or sessions in support of their findings. More about this:





As new threats are identified, content related to those threats will be added to the Known Threats Pack. Monitoring changes periodically and deploying new content via Known Threat Pack will be help identifying and hunting latest threats in the cyber world.


Thanks to Michael Sconzo, Angela Stranahan, Raymond Carney, Erik Heuser, Theresa Berardinelli, Scott Marcus and Jim Ward for their contribution.




Known Threats Pack Documentation:       

Hunting Guide:

Investigation feed Documentation:           

What is a botnet?

The term botnet is derived from the words robot and network.  A bot, sometimes referred to as a zombie, is an individual device connected to an Internet Protocol (IP) network, typically the internet.  Historically, this meant desktop computers, laptops, printers, home router, etc. were vulnerable to becoming a bot.

Today however, as the Internet of Things (IoT) evolves our household devices are increasingly more often connected to the Internet.  This means that the candidate list of potential botnet devices has greatly expanded.  Included now are web cams, baby monitoring controls, and even toasters.  After a device becomes infected with botnet malware, it can be leveraged via its network connectivity to conduct a slew of unauthorized and malicious activities. 


Botnet herders are actors who control bots remotely.  They setup and deploy command and control (C&C) servers, and these serve as the interface to the bots. Coded within the botnet malware are C&C check-in IP addresses, schedules, and instructions.  Their purpose is to establish communications channels from the herders to the bots.  For example, IRC channels are frequently employed for this purpose.  After communications are setup, the compromised hosts are often times further organized and issued updated instructions.  They have now become an organized group of hosts under centralized control.  Figure 1 shows the elements of a botnet.



Figure 1



According to the Internet Society-

Botnets are a complex and continuously evolving challenge to user confidence and security on the Internet. Combating botnets requires cross-border and multidisciplinary collaboration, innovative technical approaches, and the widespread deployment of mitigation measures that respect the fundamental principles of the Internet1.


There are two types of botnets, involuntary and voluntary. A botnet that consists of willing participants is a voluntary botnet.  In this model, frequently used by hacktivists, users willingly allow their computers to become a bot. They permit a third party to not only gain remote access and full control, but also allow it to be used for any means.  Typically this involves illicit activities.


In contrast is the involuntary model.  It will be the focus of this blog post as well as any follow up posts. In it, consent is not given to use a computer's resources.  It consists of users who are unaware that their computers have been compromised. To accomplish this a threat actor must deliver malware to victims.  Exploit kits, trojans or phishing scams are commonly employed to complete this step.  If successful, the computer becomes infected which opens the door for the payload delivery, a bot executable.  If this step succeeds then a new bot has been enlisted.



Current State

Rustoc, Conficker, and Zeus are some of the best known botnets.  They infected thousands of computers worldwide from 2006-2011.  Others came before them.  Botnets have long been a going concern for internet security.  They’re frequently used for spam-marketing, phishing, password stealing, and hijacking financial data.


Most recently, botnets made headline news when major DDoS (distributed denial of service) attacks were aimed at two notable websites, krebsonsecurity.com2 in retaliation for his continuing work and to demonstrate the at-scale efficacy and impact of a the Mirai botnet.  The Dyn attack disrupted internet traffic on the U.S. East Coast for an entire business day3.  Botnets facilitated both of these attacks.  They were instructed to flood their targets with massive amounts of TCP and UDP requests, the goal being to knock them out of service.  They succeeded.


Botnets are not however invincible, and there have been numerous takedowns throughout the years.  Most recently in April 2017, the Kelihos botnet was shut down after a lengthy law enforcement process4.  Kelihos was associated with cybercriminal activities that included spam e-mail and ransomware.  In spite of such takedown efforts, hackers continue adding features and functionality to botnets.  They're motivated by financial gain and this drives them to innovate in order to stay one step ahead of law enforcement as well as detection and remediation technologies.


For example, a decentralized or peer to peer command structure is being used more frequently5.  In it each bot serves as both a C&C client and server.  This multiplies and provides redundant communication channels.  Plus, it eliminates a single point of failure.  As previously discussed, tapping into the Internet of Things (IoT) has presented an array of possible new recruits.  Many security researchers are currently monitoring port scans and brute force password attacks on many home networks that are attempting to convert benign devices into zombies6



Botnet Tracking

There exists a number of online resources designed to track and report on botnet activities. Table 1 presents a few of them, but many others exist.  Each one offers information in a slightly different format.  From them, you can learn at a glance which botnets are active, their location, statistics, and other pertinent information.             


Table 1




This article is the first in a series about botnets.  Future articles will cover individual aspects of botnets, current campaigns they support, and related malware. 



Thanks to Kevin Stear and Ray Carney for their contributions to this blog post.











We all are so familiar with the 4625 as a failed logon, but did you know that the 4625 has more details relating to why the login failed?  I kept these notes regarding this event to write reports for a customer.  These notes show the metakeys of interest and also break down the event status and sub status codes.


Parser Version Notes

Recently there were some parser modification to the windows event parsers that changed the metakeys that the status code and sub status code were kept.  This table below was compiled from what I have seen in the field.  


Parser NameUpdateStatus Code MetakeySub Status Code Metakey




102 and earlierdispositionresult.code




some versions between 102-106result.codefld (throw away)




106 (5/24/17) and laterresult.code


(currently not in default Concentrator index)


Metakeys of Interest

Metakey NameDescription
device.ipDevice IP - System that reported this event
reference.idWindows EventID
domainWindows domain name or local computername for local computer logon

User account that is failing to login.  This can also be a computer account, which ends with a "$".


Windows Logon Types:

2 - Interactive Console Logon

3 - Network Logon - Background logon, usually for network drives and other shared resources.

4 - Batch - Job scheduling systems or other applications.

5 - Service - Applications that run as a service with user credentials.

7 - Unlock - Console Unlock of password protected screen using local keyboard.

8 - Network Clear Text - Credentials are sent in the clear, IIS basic authentication mode for example.

9 - RunAs - When you right click and use "Run As" on an application.

10 - Remote - Using RDP session to remotely logon.


Logon Types 2,3,10 are the most common


Source IP of system that attempted to logon

Hostname of the system that attempted to logon

Computer that this event 4625 occurred on - someone failed to logon to this system.


Status Code - See the table above regarding this metakey


Status Code or Sub Status Code - See the table above regarding this metakey


Sub Status Code - See the table above regarding this metakey

NOTE:  The following metakeys are not in the default index and will need to be added to the custom table map and custom concentrator/broker indexes.




Status\Sub-Status Code Description


Status/Sub Status CodeDescription
0XC000005EThere are currently no logon servers available to service the logon request.
0xC0000064User logon with misspelled or bad user account (Uknown User)
0xC000006AUser logon with misspelled or bad password
0XC000006DThis is either due to a bad username or authentication information
0XC000006EUnknown user name or bad password.
0xC000006FUser logon outside authorized hours
0xC0000070User logon from unauthorized workstation
0xC0000071User logon with expired password
0xC0000072User logon to account disabled by administrator
0XC00000DCIndicates the Sam Server was in the wrong state to perform the desired operation.
0XC0000133Clocks between DC and other computer too far out of sync
0XC000015BThe user has not been granted the requested logon type (aka logon right) at this machine
0XC000018CThe logon request failed because the trust relationship between the primary domain and the trusted domain failed.
0XC0000192An attempt was made to logon, but the Netlogon service was not started.
0xC0000193User logon with expired account
0XC0000224User is required to change password at next logon
0XC0000225Evidently a bug in Windows and not a risk
0xC0000234User logon with account locked
0XC00002EEFailure Reason: An Error occurred during Logon
0XC0000413Logon Failure: The machine you are logging onto is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine.
0x0Status OK.

Sample Queries

The sample queries below cover both sets of metakeys generated by the older and newer updated parsers.


User Does Not Exist - Status Code 0xc000006D Sub Status Code 0xC0000064

medium = 32 && device.class = 'windows hosts' && = '4625' && ((result.code = '0xc000006d' && context = '0xC0000064') || (disposition = '0xc000006d' && result.code = '0xC0000064')) && (not(user.dst ends '$'))


User Bad Password-Status Code 0xc000006D Sub Status Code 0xC000006A

medium = 32 && device.class = 'windows hosts' && = '4625' && (((not(disposition exists)) && result.code = '0xc000006d' && context = '0xC000006A') || (disposition = '0xc000006d' && result.code = '0xC000006A')) && (not(user.dst ends '$'))


Disabled User Accounts - Status Code 0xc000006E Sub Status Code 0xc0000072

medium = 32 && device.class = 'windows hosts' && = '4625' && (((not(disposition exists)) && result.code = '0xc000006e' && context = '0xC0000072') || (disposition = '0xc000006e' && result.code = '0xC0000072')) && (not(user.dst ends '$'))


Logon with Expired Password - Status Code 0xc000006E Sub Status Code 0xc0000071

medium = 32 && device.class = 'windows hosts' && = '4625' && (((not(disposition exists)) && result.code = '0xc000006e' && context = '0xC0000071') || (disposition = '0xc000006e' && result.code = '0xC0000071')) && (not(user.dst ends '$'))


User Must Change Password at Next Logon

medium = 32 && device.class = 'windows hosts' && = '4625' && ((disposition = '0xc0000224' && result.code = '0x0') || ((not(disposition exists)) && result.code = '0xc0000224' && context = '0x0')) && (not(user.dst ends '$'))


User Was Not Granted Rights to Logon - Status Code 0xc000015B Sub Status Code 0x0

medium = 32 && device.class = 'windows hosts' && = '4625' && (((not(disposition exists)) && result.code = '0xc000015b' && context = '0x0') || (disposition = '0xc000015b' && result.code = '0x0')) && (not(user.dst ends '$'))


Attachments - Custom column view for the "Events" view in Investigation.

Investigation-->Events, it's the drop down right next to "Profile".  Choose "Manage Column Groups" and import the .jsn file.


Report-User Failed Logon Attempts (4625) - Windows 4625 Report based on the sample rules in this post. Just import into the Report Engine.

If you have been using RSA Netwitness Packets for any length of time, you might have noticed that many large sessions are maxed out at approximately 32mb.  Furthermore, there maybe multiple 32mb sessions between the two hosts. 



Beginning in 10.5, a new meta key was added called 'session.split' to track follow-on sessions that are related.  While the decoder settings may draw the line at 32mb (the default setting and I don't recommend changing) for a session, network traffic is not bound by such restraints.  Network traffic can be as large as it has to be.  All of this traffic is still captured, but there wasn't anything really tying all the sessions together.  However, with session.split, we can see that there is more network data to be found.  In the 'List View' screenshot above, you can see the numbers on the far right of the session.  You can right click on that number and find the session fragments in a new tab.


If that view doesn't work for you, you can build your own custom view like the one below.



Recently, I was having a discussion with some colleagues about how to find uploads greater than 1 GB in size that are going outbound.  This was to identify some potential exfiltration use cases.  One thing that came to mind was using meta in 'session.split'.  In a few short minutes, I had an application rule built by using some of the content from the Hunting Pack content (RSA Announces the Availability of the Hunting Pack in Live  ).  Let's break it down.


First, we know that it would be outbound network traffic.  Therefore, we could start our application rule with:


('medium = 1 && direction = 'outbound')


If you don't have directionality setup in your decoders, you could substitute "direction = 'outbound'" with "org.dst exists".


Next, we look at the new meta key from the hunting pack called 'analysis.session' (aka Session Characteristics).  This purpose of this meta key is to tell the analyst things that were observed about the network session.  In our case, we are looking for 'ratio high transmitted'.


The meta 'ratio high transmitted' is a reference to a calculation of the transmitted bytes (requestpayload) vs the received bytes (responsepayload) in a network session.  It provides a ratio score of 0 - 100 showing which side sent more data.  A score of 0 means more bytes were received than transmitted.  A score of 100 means more bytes were transmitted than received.  Since we are looking for uploads, that would typically have more data being transmitted than received in a network session.  Therefore, we can add this meta to our app rule.


('medium = 1 && direction = 'outbound' && analysis.session = 'ratio high transmitted')


However, we aren't done yet.  How do we tell if it is around or over 1 GB?  This is where session.split comes in.  Since the sessions were being maxed at 32mb per the default decoder configuration, we can do some math to find out how many sessions it would take to get to approximately 1 GB.


1024 mb / 32 mb = 32 sessions.


Since there could be retransmitted data or some other anomalies in the traffic, lets give ourselves an approximate session count of 30.  This means that if session.split reached 30 splits (really 31 since it starts from 0), then we have a large session and may want to have a closer look.


Therefore, our application rule looks like:


('medium = 1 && direction = 'outbound' && analysis.session = 'ratio high transmitted' && session.split >=30)



I called mine "large_outbound_transmit' but you can call it whatever you like.  This will tag any of those follow-on sessions that matched the criteria we set in the app rule starting at session.split 30.  To find all the session fragments, go back into the Investigation Events, select the List view.  Right-click on the session.split number (not the little icon to the left of it) and select 'Refocus or Refocus New Tab'.




What's nice about this rule is that it works whether the content is encrypted or unencrypted.  It is simply working against meta we've already collected.  Now, I can tell if I have large network sessions leaving my network.  If you regularly have large sessions, perhaps creating a filtering application rule or feed may help reduce some of that noise.


More information about session.split and understanding its configuration can be found here: Investigation: Combine Events from Split Sessions 


I hope you found this post helpful, and as always, happy hunting.



Filter Blog

By date: By tag: