Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2020 > September

Zerologon (CVE-2020-1472) is a vulnerability with a perfect CVSS score of 10/10 being used in the wild by attackers, allowing them to gain admin access to a Windows Domain Controller.

 As more public exploits for this vulnerability are being published, including its support within mimikatz which is widely used, it’s expected to see even more attacks leveraging this vulnerability, and it's therefore crucial to be able to detect such attempts.


In this post we will see how this vulnerability can be exploited using mimikatz to gain administrative access to a Windows Domain Controller running on Windows Server 2019, and how the different stages of the attack can be identified by the RSA NetWitness Platform, leveraging Logs, Network and Endpoint data. This will include exploiting the Zerologon vulnerability, followed by the creation of golden tickets, and finally gaining admin access to the domain controller via a pass-the-hash attack/


We will assume that the attacker already has an initial foothold on one of the internal workstations, and now wants to move laterally to the domain controller.



Step 1


The attacker downloads “mimikatz” on the compromised system using the “bitsadmin” command.



RSA NetWitness Endpoint

The executed command is detected by RSA NetWitness Endpoint and tagged as remote file copy using BITS. The exact target parameters are also provided, allowing to see from where the file was downloaded (identifying the attacker’s server) as well as the location of the downloaded file. In addition, mimikatz being a known malicious file, we are able to tag the event accordingly.




RSA NetWitness Network

And the resulted network session is captured by RSA NetWitness Network, identifying the client application as Microsoft BITS as well as the downloaded file (mimikatz.exe). If needed, the session can be reconstructed to extract the file for further forensics.






Step 2


The attacker launches mimikatz, and tests whether the domain controller is vulnerable to the Zerologon vulnerability.


As the domain controller is vulnerable, the attacker executes the exploit.



RSA NetWitness Network

We know that the exploit starts with a “NetrServerReqChallenge” and spoofs the “NetrServerAuthenticate” with 8x ‘0’s (as seen in the previous screenshot). We also know that it takes an average of 256 of such attempts for the attack to be successful.

This consequently leads to the following:

  • We expect to see “NetrServerReqChallenge” and “NetrServerAuthenticate”
  • Due to the large number of attempts, we expect the size of the session to be larger than other similar connections
  • The session to contain lots of 0's


 In fact, by looking at the captured network session, we can see these indicators tagged by RSA NetWitness.


As seen in the above screenshot

  • The session is related to netlogon (as the vulnerability targets this service)
  • We can see both “NetrServerReqChallenge” and “NetrServrAuthenticate” within the session
  • The most common byte (MCB.REQ) is “0”
  • The size of the payload is around 200KB
  • As we also have the RSA NetWitness Endpoint agent installed on the workstation, we can link the captured network session to the process that generated this connection, in this case “mimikatz.exe”


Using this information, the use of this exploit could be identified with the follow Application Rule:

service=135 && filename='netlogon' && action begins 'NetrServerAuthenticate' && action='NetrServerReqChallenge' && mcb.req=0 && size>40000



RSA NetWitness Logs

A successful attack would lead to the domain controller’s password being changed. This can be identified within the Windows Logs based on the following criteria:

  • Event ID: 4742 (A computer account was changed)
  • Source User: Anonymous logon
  • Destination User: ends with “$” sign
  • Hostname: specify your domain controllers




The following Application Rule / Query could be used for this detection:

device.type='windows' &&'4742' && user.dst ends '$' && user.src='anonymous logon'






Step 3


Once the attacker successfully exploits the domain controller, he now has access to it with replication rights. He can now use the “dcsync” feature of mimikatz to mimic the behavior of a domain controller and request the replication of specific users to get their password hashes. This can be done to get the password hash of the Administrator account as seen in the below screenshot.




RSA NetWitness Network

User Replication is requested using the “GetNCChanges” function, which would result in the domain controller providing the account hashes. This behavior can be seen based on the captured network traffic.



This behavior should me monitored and alerted on when initiated from an IP or subnet not expected to perform domain replication.


The following is a rule that can identify this behavior, it should be fine-tuned to exclude IP addresses that are expected to have this behavior:


action = ‘drsgetncchanges’ && ip.src != <include list of approved IP addresses>



RSA NetWitness Logs

This would also generate Windows Logs with the event ID 4662, but by default this log doesn’t provide enough granularity to avoid having too many false positives and is therefore not recommended to be used on its own as a detection mechanism.






Step 4


The attacker then gets a golden ticket with a validity of 10 years for the Administrator account.


He is then able to use the ticket in a pass-the-hash attack.


He is now able to get shell access to the domain controller without the need for authentication and executes couple of commands to confirm he is connected to the Domain Controller (hostname, whoami ...).




RSA NetWitness Logs

The attacker gained shell access by using PsExec. This leads to the creation of a service named “psexesvc” on the domain controller that can be detected with Windows Logs and is tagged as a pass-the-hash attack by RSA NetWitness as seen below.



RSA NetWitness Network

Leveraging network data can uncover more details.

As seen in the below screenshot, we can identify:

  • The use of the “Administrator” account to login over SMB
  • The use of Windows admin shares
  • The transfer of an executable within one of the sessions (psexe)
  • The creation of a service (psexesvc)




RSA NetWitness Endpoint

The initial execution of “cmd.exe” by PsExec on the Domain Controller to gain the shell access can easily be identified by RSA NetWitness Endpoint.


Any other command executed by the attacker after he gets shell access would also be identified and logged by RSA NetWitness Endpoint, with the ability to track which commands have been executed, and by which processes they have been launched, providing a full picture of how and what the attacker is doing on the domain controller.





When dealing with such attacks and breaches, which often blend in within normal noise and behaviors, it becomes evident that the need for a rich data set based on a combination of Logs, Network and Endpoint is critical to both detect the breach as well as to identify the full scope of the breach from start to end, for each step done by the attacker.

Having visibility over East/West network traffic with rich metadata has also brought lots of value when compared to just relying on logs to detect and investigate more efficiently this attack. With the release of the RSA NetWitness Platform v11.5 it is now possible to setup policies to define for which network traffic to keep/drop the full payload in addition to the meta data, allowing to do east/west network capture in a more efficient way.

RSA NetWitness has been supporting Structured Threat Information eXpression (STIX™) as it has been the industry standard for Open Source Cyber Threat Intelligence for quite some time. 



In NetWitness v11.5 we take the power of Threat Intelligence coming from STIX to the next level. When in Investigate or Respond views, you will now see context of the Intel delivered by STIX right there next to the meta like this:


For this - NetWitness Platform’s has enhanced the existing integration with STIX to improve the threat detection capabilities with improved Threat Intel information to detect and respond to attacks in a timely manner. Now, when an analyst investigates threat intelligence information retrieved from a STIX data source, the context for each indicator is displayed. The context information includes viewing the adversary and the attack details directly from Context Hub, in both Investigate and Respond views.


Note that for the analyst to use this capability, an administrator needs to configure the STIX data sources to retrieve the threat intelligence data from the specified STIX source as below.



  1. Add & Configure STIX/TAXII as a 'Data Source' (note that you can add TAXII server/REST server/STIX file): 
  2. Create Feeds: Setup STIX feed from Custom Feeds section. Note that you can now see all the existing STIX Data Sources (as added in pervious step) to create feeds out of them. See Decoder: Create a STIX Custom Feed  for more details.
  3. Context Lookup Summary
  4. Context Lookup Details:

Here are the links to detailed documentation around STIX: 


Check it out and let us know what you think!


We strongly believe in the power of feedback! And thus please leave any feedback or suggestions on how to make this experience even better. To see what else may be in store for future releases, go to the RSA Ideas portal for the RSA NetWitness Platform to see enhancements that have been suggested, vote on them, and submit your own. 

As of RSA NetWitness 11.5, configuring what network traffic your Decoders collect and to what degree it should collect it has become much easier. Administrators can now define a collection policy containing rules for many network protocols and choose whether to collect only metadata, collect all data (metadata and packets), or drop all data.


NW 11.5 Selective Collection Policy Creation


This is made simpler by out-of-the-box (OOTB) policies that cover most typical situations. These can also be cloned and turned into a custom policy that fits your environment best. 


NW 11.5 Initial Selective Collection Policies


The policies are managed out of a new central location that has the ability to publish these policies to multiple network Decoders at once. This allows an administrator to configure one collection policy for DMZ traffic and distribute that to all the DMZ Decoders while simultaneously using a separate policy for egress traffic and distribute that to all the egress Decoders.


NW 11.5 Selective Collection Policy Status


An administrator can view which policies are published, the Decoders they have been applied to, when the last update was made and by whom. The policies can also be created in draft form (unpublished) and not distributed to Decoders until a maintenance window is available.


Initially this capability focuses on network collection, but long-term plan is to continue adding types of configurations and content to be administered using this centralized management approach. Please reference the RSA NetWitness Platform 11.5 documentation for further details at Decoder: (Optional) Configure Selective Network Data Collection 


As always, we welcome your feedback!


Please leave any feedback or suggestions on how to make this experience even better. To see what else may be in store for future releases, go to the RSA Ideas portal for the RSA NetWitness Platform to see enhancements that have been suggested, vote on them, and submit your own. 

RSA NetWitness 11.5 introduces the ability to interactively filter events using the metadata associated with all the events. This is seen as a new Filter button inside the Event screen that opens the Filter Events panel.


NW 11.5 Event Filter Button


This new capability functions in two modes.


NW 11.5 Event Filter Panel


The first presents a familiar search experience for analysts of all skill levels as many websites have a similar layout where filters (attributes or categories of the data) exist on the left side of the page and the matching results display on the right side. As an example in the below image, clicking the metadata (#1) in this integrated panel automatically builds the query (#2) and retrieves the resulting table (#3) of matching events.


NW 11.5 Event Filter Interactive Workflow


As analysts use this, it helps build the relationship between the metadata associated with the events and how to use those to structure a query.


NW 11.5 Full Screen Filter Events Panel


The second mode allows the panel to extend full screen giving more real-estate to show more metadata at once. This mode may seem very familiar to those who have used Navigate previously. As meta data values are clicked they are added as filters to the query bar and updates a new filter list based on the events filtered out. What it does not do is execute the query to retrieve the resulting table of events. This allows the analyst to hunt through the data and then when ready to see the results they can minimize (highlighted in above image) the Filter Events panel to reveal the results.


In both modes, the meta values associated to the meta keys can be organized by event count or event size and sorted by the count or value. This allows for analysts to sort descending by event count to find outliers, a small limited number of communications, for example. The meta keys can also be shown in smaller meta groups to help analysts focus in on the most specific values for certain use cases. Analysts can use the query profiles to execute a query with a predefined query, meta group, and column group allowing them to jump right into a specific subset of data. The right click actions that provide additional query and lookup options are also available. To get a further deep dive into the capability check out the Investigate documentation Investigate: Drill into Metadata in the Events View (Beta)  


As always, we welcome your feedback!


Please leave any feedback or suggestions on how to make this experience even better. To see what else may be in store for future releases, go to the RSA Ideas portal for the RSA NetWitness Platform to see enhancements that have been suggested, vote on them, and submit your own. 

A business what?  A Business Context Feed is a feed that provides context about systems or data that is present in NetWitness to aid the analyst in understanding more about the system or data they are examining.  The Business Context Feed should answer some basic questions that always come up during the analysis.

What is this system? - Web Server, Domain Controller, Proxy Server, etc...

What does it do? - Authentication, Database/Application Server, Customer Portal, etc...

Would it be considered a Critical Asset?

A classic scenario would be for an IP address.  If an analyst would like to know if the IP address of interest is a Domain Controller, they would need to obtain or identify all of the IP addresses of the Domain Controllers.  Then a query must be constructed to determine if there is a match (ip.all=,,,,... you get the idea).  If there is any content such as reports or alerts that are developed for this use case the list of IP addresses would need to be in all of those as well.  It can get complicated real quick once you start putting this list of IP's in content, especially when the addresses change periodically.  Creating a Business Context Feed will simplify this use case by maintaining a single feed that is centrally managed. Updating the feed can even be automated in most cases.  When the feed is applied to this use case the query gets simplified from (ip.all=,,,,... you get the idea) to a query using a custom metakey hnl.asset.role='domain controller'.  Now, it is not uncommon for an organization to create around a dozen custom metakeys in NetWitness for their own use to provide additional context for data that is collected in NetWitness.  But not everyone takes the time to create a taxonomy document to set the standard on how the custom content will be defined and populated to provide consistency for other content that will be developed around it.  Frankly, it is not advised to comingle custom meta values with the meta values that are created by NetWitness natively.  This can create confusion on what the values "are" versus what they "should be", and can adversely affect other content that uses these standard keys. There are reserved metakeys that custom values do not belong, these can be identified in the Unified Data Model (UDM) as "Reserved" in the "Meta Class" column or in the "Notes" column (use "ctrl+f" in the browser).  When creating custom content it is important to set standards on how the content is created, this includes naming conventions, spelling, formatting and values. This practice provides the necessary consistency for stable content development and performance.  Another common issue is the custom content becomes knowledge exclusive to the author and can affect the time it takes to bring new people up to speed. Another factor is time, as the undocumented knowledge becomes stale to the author and often cannot recall the logic behind the naming, purpose, or value. The taxonomy document takes the burden off of the content author and provides a reference for all parties involved in creating, updating and consuming the content.  Below is an example use case of the taxonomy to create custom metakeys and content to identify critical assets.


Creating Custom Metakeys - Things to Know

Name Length

You are limited to 16 characters (including the "." dot delimiter)  - use lowercase only for the name and values.


Allowed Characters

Only alpha numeric values are allowed, except for the "." delimiter.


Name Construction

Metakey names should follow the Unified Data Model (UDM) "3 Logical Parts" and should not conflict with any current RSA keys.

Metakey concept image

Value Format

You must decide what your metakey value it will store and define it in the appropriate custom index files if needed. The most commonly used formats are "Text" and "Integer". There are other formats but these are the most commonly used.


Multivalued Field

You will have to properly identify whether or not your metakey may contain multiple values in the same session.  This is done in the index file with a singleton="true" in the concentrator custom index files.  The reason for this is to have the ESA properly identify the field as a multivalued field (array) or a single valued field automatically.  


Example Use Case:  Creating Critical Asset Metakeys


The concept is the least specific part of the metakey name, typically used to group the metakeys, or in this case clearly identify the custom metakeys from the standard metakeys.  The concept for these asset metakeys will be an abbreviation of my "Homenet Lab", it is not uncommon to use an abbreviated company name here.  I will use "hnl" in this case.



The context is more specific and will typically define the "classification" of the key.  A context name of "asset" will be used here as these keys are for identifying the critical assets



The sub-context is the most specific, the specific sub-context values are shown below:


Sub Context Abbreviation


General Description of the Metakeys

The table below contains the metakey names fully assembled with the "concept.context.sub-context" values applied, showing a general description of the custom metakeys.

Metakey NameDescription
hnl.asset.critNumeric "Criticality" rating of the asset."Category" of the asset
hnl.asset.role"Role" of the asset"Hostname" of the asset"Date" the asset was added to the feed
hnl.asset.loc"Location" of the asset


Metakey Value Format

Define whether this metakey value will be text or an integer.

MetakeyValue FormatStore Multiple Values







Metakey Values


This metakey identifies the criticality of the system.  The table below lists the possible values and describes the values to use in the metakey.

Metakey Value


1Extremely Critical
2Highly Critical

Moderately Critical


This metakey identifies the category of the system.  The table below lists the possible values and describes the values to use in this metakey.  Note the values are always lowercase.

Metakey Value


authenticationSystems that provide authentication services, like domain controllers, LDAP servers, RADIUS, SecurID, TACACS, etc.
firewallSystems that provide firewall services.

Systems that perform scanning activities like a port/vulnerability scanner or pen test

networkNetwork Infrastructure



This metakey identifies the role of the system.  The table below lists the possible values grouped by category along with the descriptions of the values to use in this metakey.  Note the values are always lowercase.




authenticationMicrosoft Active Directorydomain controller
authenticationRADIUS Serverradius server
authenticationSecurID Serversecurid server
firewallFirewall operating in the ecommerce DMZecommerce dmz
firewallInternal firewall for secure hostingsecure hosting
firewallInternet Perimeter Firewallinternet perimeter
scannerVulnerability Scannervulnerability
scannerPenetration testingpentest
networkCore network router

core router

networkCore network switchcore switch

This metakey has the short hostname in lowercase

This metakey contains the numeric date the system was added to the feed in YYYYMMDD format.  The date is used to determine the age of the entry and to also know that prior to this date there is no contextual meta generated.



This metakey identifies the location of the system. The table below lists the possible values and describes the values to use in this metakey. Note the values are always lowercase.

Metakey Value


hqdc-01Headquarters Data Center 1
lvdc-02Leonardville Data Center 2

Moscow Data Center 3

raddc-04Radium Data Center 4


Sample Business Context Feed Using Taxonomy

User Friendly Version:

#indexhnl.asset.crithnl.asset.cathnl.asset.rolehnl.asset.hosthnl.asset.datehnl.asset.loc hostinghnlshfw-0220200708hqdc-01 controllerhnraddc-0120200708raddc-04 controllerhnlvdc-0220200708lvdc-02 controllerhnmscwdc-0320200708mscwdc-03 switchhnlcsw-0120200708hqdc-01


CSV File format for Feed Consumption:

#index,hnl.asset.crit,,hnl.asset.role,,,hnl.asset.loc,1,firewall,perimeter,hnlhqfw-01,20200708,hqdc-01,1,firewall,secure hosting,hnlshfw-02,20200708,hqdc-01,1,authentication,domain controller,hnraddc-01,20200708,raddc-04,1,authentication,domain controller,hnlvdc-02,20200708,lvdc-02,1,authentication,domain controller,hnmscwdc-03,20200708,mscwdc-03,1,network,core switch,hnlcsw-01,20200708,hqdc-01


Customizing Index

Now that the metakey names and values have been established they can be added to the necessary index custom files so that they are available to the analyst in Investigate.


Log/Network Decoders

There are two metakeys that are defined as integers, so we need to tell the Log or Network Decoder that these metakeys are to be formatted as integers.

The following custom index files need to be modified with the entries below:

index-logdecoder-custom.xml (Log Decoder)

<!-- *** Homenet Lab Custom Index 1.0 05/04/2020 *** -->
<!-- *** Homenet Lab Custom metakeys *** -->
<key description="HNL Asset Criticality" name="hnl.asset.crit" format="UInt8" level="IndexNone"/>
<key description="HNL Asset Date" name="" format="UInt32" level="IndexNone"/>

index-decoder-custom.xml (Network Decoder)

<!-- *** Homenet Lab Custom Index 1.0 05/04/2020 *** -->
<!-- *** Homenet Lab Custom metakeys *** -->
<key description="HNL Asset Criticality" name="hnl.asset.crit" singleton="true" format="UInt8" level="IndexNone"/>
<key description="HNL Asset Date" name="" singleton="true" format="UInt32" level="IndexNone"/>


All of the custom meta keys will need to be added to the Concentrator to be available in Investigate for the Analysts.

The following custom index file need to be modified with the entries below.

index-concentrator-custom.xml (Concentrator)

<!-- *** Homenet Lab Custom Index 1.0 05/04/2020 *** -->
<!-- *** Homenet custom index keys added to provide additional information from feeds *** -->

<key description="HNL Asset Criticality" name="hnl.asset.crit" singleton="true" format="UInt8" level="IndexValues" valueMax="50"/>
<key description="HNL Asset Category" name="" format="Text" level="IndexValues" valueMax="50"/>
<key description="HNL Asset Role" name="hnl.asset.role" format="Text" level="IndexValues" valueMax="50"/>
<key description="HNL Asset Hostname" name="" singleton="true" format="Text" level="IndexValues" valueMax="50"/>
<key description="HNL Asset Date Added" name="" singleton="true" format="UInt32" level="IndexValues" valueMax="100"/>
<key description="HNL Asset Location" name="hnl.asset.loc" singleton="true" format="Text" level="IndexValues" valueMax="50"/>


Now you have more information than just an IP address to look at thanks to the Taxonomy and a Business Context Feed.


As of RSA Netwitness Platform 11.5, analysts have a new landing page option to help them determine where to start upon login.  We call this new landing page Springboard.  In 11.5 it will become the new default starting page upon login (adjustable) and can be accessed from any screen simply by click the RSA logo on the top left. 


The Springboard is a specialized dashboard (independent of the existing "Dashboard" functionality) designed as a starting place where analysts can quickly see the variety of risks, threats, and most important events in their environment.  From the Springboard, analysts can drill into any of the leads presented in each panel and be taken directly to the appropriate product screen with the relevant filter pre-applied, saving time and streamlining the analysis process.  


As part of the 11.5 release, Springboard comes with five pre-configured (adjustable) panels that will be populated with the "Top 25" results in each category, depending on the components and data available:


Top Incidents - Sorted by descending priority.  Requires the use of the Respond module.

Top Alerts -  Sorted by descending severity, whether or not they are part of an Incident. Requires the use of the Respond module.

Top Risky Hosts -  Sorted by descending risk score.  Requires RSA NetWitness Endpoint.

Top Risky Users - Sorted by descending risk score.  Requires RSA UEBA.
Top Risky Files - Sorted by descending risk score. Requires RSA NetWitness Endpoint.


Springboard administrators can also create custom panels, up to a total of ten, of a 6th type for aggregating "Events" based on any existing saved query profile used in the Investigate module.  This only requires the core RSA NetWitness platform, with data being sourced from the underlying NetWitness Database (NWDB).  This enables organizations to add their own starting places for analysts that go beyond the defaults, and to customize the landing experience to adjust for deployed RSA NetWitness Platform components:


Example of custom Springboard Panel creation using Event data


For more details on management of the Springboard, please see: NW: Managing the Springboard 


And as always, if you have any feedback or ideas on how we can improve Springboard or anything else in the product, please submit your ideas via the RSA Ideas portal: RSA Ideas for the RSA NetWitness Platform  

RSA is pleased to announce the availability of the NetWitness Export Connector, which enables customers to export NetWitness Platform events and routes the data where you want, all in continuous, streaming fashion. Providing the flexibility to satisfy a variety of use cases. 


This plugin is installed on Logstash and integrates with NetWitness Platform Decoders and Log Decoders. This plugin aggregates meta data and raw logs from the Decoder or Log Decoder and converts it to Logstash JSON object, which can easily integrate with numerous consumers such as Kafka, AWS S3, TCP, Elastic and others.


Work Flow of NetWitness Export Connector 


  • The input plugin collects meta data and raw logs from the Log Decoder, and the meta data from the Decoder. The data is then forwarded to the Filter plugin.
  • The Filter plugin adds, removes, or modifies the received data and forwards it to the Output plugin.
  • The Output plugin sends the processed event data to the consumer destinations. You can use the standard Logstash output plugins to forward the data.


Check it out and let me know what you think!


Please leave any feedback or suggestions on how to make this experience even better. To see what else may be in store for future releases, go to the RSA Ideas portal for the RSA NetWitness Platform to see enhancements that have been suggested, vote on them, and submit your own. 


Download and Documentation

We are excited to announce the release of the new RSA OSINT Indicator feed, powered by ThreatConnect!  


What is it?

There are two new feeds that have been introduced to RSA Live, built on Open Source Intelligence (OSINT) that has been curated and scored by our partners at ThreatConnect:

  • RSA OSINT IP Threat Intel Feed, including Tor Exit Nodes
  • RSA OSINT Non-IP Threat Intel Feed, which includes indicators of types:
    • Email Address
    • URLs
    • Hostnames
    • File Hashes

These feeds are automatically aggregated, de-duplicated, aged and scored with ThreatConnect's ThreatAssess score. ThreatAssess is a metric combining both the severity and confidence of an indicator, giving analysts a simple indication of the potential impact when a matching indicator is observed.  Higher ThreatAssess scores mean higher potential impact.  The range is 0-1000, with RSA opting to focus on the highest fidelity indicators with scores 500 or greater (as of the 11.5 release - subject to change as needed)


Who gets it?

These feeds are included for any customer, with any combination of RSA NetWitness Logs, RSA NetWitness Packets, or RSA NetWitness Endpoint under active maintenance at no charge. The feed will work on any version of RSA NetWitness, but please see the How do I deploy it? section for notes on version-specific considerations.


How do I deploy it?

These feeds will show up in RSA Live as follows:


To deploy and/or subscribe to the feed, please take a look at the detailed instructions here: Live: Manage Live Resources 


11.4 and earlier customers will want to add a new ioc.score meta key to their Concentrator(s) in order to be able to query and take advantage of the ThreatAssess score of any matched indicator. Please see 000026912 - How to add custom meta keys in RSA NetWitness Platform  for details on how to do this. Please note that this meta key should be of type Uint16 - inside the index file, the definition should look similar to this:


11.5 and greater customers do not need to add this key, as it's already included by default.



How do I use it?

Once the feeds are deployed, any events or sessions with matching indicators will be enriched with two additional meta values, ioc and ioc.score.  These values are available for use in all search, investigation, and reporting use cases assuming those keys have been enabled.



eg. Events filter view

eg. Event reconstruction view


What happens to the "RSA FirstWatch" and Tor Exit Node feeds?

If you are running these new feeds, you do not need to run the existing RSA FirstWatch & Tor Exit Node feeds in parallel as they are highly redundant and tend to be less informative when matches occur.  At some point in the near future once we believe impact will be minimal, we will officially deprecate the RSA FirstWatch & Standalone Tor Exit Node feeds.


Do you have ideas?

If you have ideas on how to make these feeds better, ideas for content creation leveraging these feeds, or anything else in the RSA NetWitness portfolio, please submit and vote on ideas in the RSA Ideas portal: RSA Ideas for the RSA NetWitness Platform 

Before I jump into explaining what is the relation between RSA NetWitness as an evolved SIEM and Threat Defense platform and Gartner’s SOC Visibility triad, I’m going to start by talking about Gartner for a minute. I expect everyone knows who Gartner are. They are a worldwide IT leading research and advisory organization and one of the most trusted and reputable ones in addition to being active within the Cyber Security field for SOC Threat Detection and Response tools such as: SIEM, NTA, EDR, UEBA, SOAR..etc. The reason we are mentioning Gartner today is that they did a piece of great work last year that sought to simplify complex views of modern security toolset requirements into a single picture of what good looks like.


They called it the SOC visibility triad and it calls out the three pillars of security, being your traditional log-centric SIEM, network-orientated and endpoint security detection and response tools.

Combining all these 3 technologies together helps in filling gaps among them to provide full security visibility. That combined approach significantly reduces the chances of an (internal or external) bad actor  to evade your deployed systems for a prolonged period of time which ultimately enables you to effectively meet the required SOC Metrics in terms of MTTD/MTTR and cut down the dwell time of a bad actor. 


The reason we like it is that Gartner, arguably the most respected of today’s analysts, has essentially drawn the core of RSA NetWitness.


RSA NetWitness brings together the breadth of coverage of log management solutions with the detailed, intelligence and forensic  worlds of endpoint and network into a single, modular and powerful  security platform.                                                                


Cyber security has always been a battleground so there has always been evolution of the tools used to attack and the tools used to defend. More recently we’ve seen huge rises in the use of automation by attackers, massive ransomware campaigns, huge data breaches and some pretty big fines being handed out through regulation like GDPR. Of course, most recently, the Covid-19 pandemic has seen huge numbers of businesses suddenly alter the way of doing business and consequently their security posture by rapidly allowing remote access to their corporate resources from anywhere.


All these cyber security pressures combined with most businesses thirst for technology adoption and digitization created huge change. At the heart of the change are security teams trying to build or maintain adequate protections, trying to be business enablers and not blockers.


To succeed, security teams need to move from the conventional approach of multi-layered, disjointed security tooling that uses old detection methods like rules and signatures to something more valuable. Modern security tooling needs to be able to consume all data sources, not just logs, and use the latest analysis techniques like machine learning to find important security insights and reduce the alert noise created by traditional approaches. Full visibility is important and by that we don’t just mean having visibility across the whole estate. We also mean combining intelligence from those data sources to undercover threats the individual tools wouldn’t notice.


As you’d expect, Gartner name us as a leader in their MQ reporting for this very reason.



Using a mixed approach in detection using a large library of out-of-the-box rule-sets combined with the latest in machine learning, RSA NetWitness as a modular and a platform-anywhere solution can automatically classify alerts based on their risk score across all data sources fully aligned with MITRE ATT&CK framework and Gartner agreed that as a single platform RSA NetWitness shines.


 For the traditional log centric SIEM space, we have a comprehensive integration coverage (see this URL RSA NetWitness Platform Integrations Catalog ) , intuitive/interactive UI ( ),

toolset with advanced query and advanced correlation capabilities. Where we can consume log data from  350+ log sources and get all this data filtered, normalized and enriched at capture time. Then applying real-time correlation-based analytics and reporting to provide real time alerts and dashboards visibility into any spotted threat.  NetWitness also extends this with a fully unsupervised, multi-model, machine learning UEBA (User and Entity Behavioral Analytics) engine. This engine forms a picture of normal user and entity (endpoint, network) activity and finds anomalies automatically, for example, a malicious insider, credentials theft, brute-force, process injections ..etc (further details on UEBA use cases and indicators can be found here UEBA: NetWitness UEBA Indicators)


The network detection space is really where RSA NetWitness was born and is unbeaten. RSA NetWitness can perform a continuous full-packet capture while providing a real time OSI stack "layer 2" to "layer 7" network threat detection. Like with log data this data is normalized and enriched alongside all other data sources. Specifically, with packet data we can reconstruct entire network sessions and extract malicious payloads, digital artefacts and the likes for further analysis.


At the endpoint, RSA NetWitness provides further security intelligence data by tracking system and user space processes and further enhancing the UEBA engine. With our lightweight agent we can directly perform remediation measures on endpoints from simple process shutdowns or protocol blocks to full endpoint isolation to stop compromise at the source (How to Isolate a Host from the Network ). Also, as with network detection, we can pull interesting assets such as malicious programs, MFT, system/process dump files from the endpoint for deeper analysis.


All of this analysed security data gathered and generated can be enriched with our threat intelligence engine which provides yet more insight, confidence, risk scoring into known threats like compromised IP addresses, malicious code or actors. This all provides huge amounts of insight for use in threat remediation or incident response activities. These threat responses can be tracked or automated through the main analyst interface (Respond: Responding to Incidents ) , or, through our security orchestration and automation (SOAR) engine called NetWitness Orchestrator (Security Automation and Orchestration ) .


We describe RSA NetWitness as a reliable evolved SIEM and threat defense SOC platform because of this ability to produce high-fidelity alerts across all data sources, lower false positives through the depth of its insight and detect threats faster. It can also act as your storyteller, allowing you to go back in time and pick through an attack blow by blow. It goes beyond a single indicator-of-compromise type detection to a malicious log/network/endpoint/user based behavior and TTP (tactics, Techniques and Procedures) detection,  to getting you a step ahead of the threat and ultimately improve your overall digital immunity across your estate in the face of known and unknown threats on a proactive manner. 


Importantly, it gives you the best possible information to answer the burning questions during any attack:

When and how did it happen?

What systems were affected?

What’s the magnitude and impact of it?


Special Thanks to Russel Ridgley RSA's UKI CTO, who contributed and helped me in writing this article. Please feel free to leave a comment if you have any question or interest to understand more on the RSA NetWitness solution. Thank you!. 

Filter Blog

By date: By tag: