Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Authors Angela Stranahan

What is the syntax and supported functions of regular expressions within ESA?


The regular expression syntax supported in ESA is through the java.util.regex API and is most similar to that found in Perl.  There are regular expression tools, such as Regex Buddy, that allow validation of the syntax according to the flavor of regular expression you are writing – including Java.  To see the supported functions within java.util.regex, see the online tutorial or description in the Pattern class documentation.  The language supports more complex concepts such as lookahead and lookbehind. 


An expression for NeutrinoEK shown below would be supported since the API implements concepts such as capture groups, boundary matching, quantifiers, character classes and lookaheads.


^http:\/\/(?!www|jobs?)[a-z0-9\-]{4,32}\.[a-z0-9\-]{4,32}\.[^\x2f]+\/(?!news|people|includes?|company)[a-z]{3,12}\/(?:[a-z]{3,12}\-){1,5}[0-9]{8}(?:\.swf)?$ Juan Figuera, 2016-06-21, NeutrinoEK Landing pattern 2. Thanks Keith Faber for extra samples. Validated by Michelle Ticer.




Are there expressions to detect DGA?


Within the current shipping product, the TLD Lua parser will populate within the meta key risk.suspicious the value ‘hostname consecutive consonants’.  This is employing a regular expression that looks within the meta ‘’ for either a) 5 or more consecutive consonants or b) two groups of 4 consecutive consonants.  This pattern is commonly found output from a DGA.    Deploy the TLD Lua parser from Live and write an ESA rule against the meta value as follows:



select * from Event


risk_suspicious = ‘hostname consecutive consonants’



Alternatively, if you did not want to use the Lua parser you could match the regular expression directly in ESA for either 5 or more consecutive consonants or two groups of 4 consecutive consonants.  An example:



select * from Event


alias_host regexp ' [BbCcDdFfGgHhJjKkLlMmNnPpQqRrSsTtVvWwXxYyZz]{5,}'


alias_host regexp '[BbCcDdFfGgHhJjKkLlMmNnPpQqRrSsTtVvWwXxYyZz]{4}.+[BbCcDdFfGgHhJjKkLlMmNnPpQqRrSsTtVvWwXxYyZz]{4}'



There is a post in the community on RSA Link that shows a plugin to ESA to calculate entropy in order to detect DGAs.  This can also be accomplished in a Lua parser.


The RSA Live Content team has released the Traffic Flow LUA and associated options parsers.  The traffic flow parser brings directionality information and netblock identification into the product, which exist as part of the IR content pack.  Directionality (direction meta) provides the context of whether a session was initiated from an internal host to an external host (outbound), from an external host to an internal host (inbound), or was between two internal hosts (lateral). The netblock name (netname meta) provides the context of where on your network a host resides.  By default, netblocks are defined for private, broadcast, loopback, link-local, multicast, and reserved traffic.  The screenshot below shows the Investigation view of these two pieces of meta being populated.



You download the parser from Live to deploy to a packet decoder, in the same manner as you download and deploy all of the RSA parsers. In addition to the parser, there is an options file. You only need the options file if the default settings are not sufficient for your use case. 




At this time, only manual deployment to a Log Decoder is supported.  You can find detailed information about the current implementation in SA docs, at Traffic Flow Lua Parser


What to expect going forward?

Our goal going forward is to make the parser easier to deploy and configure.  It is expected in upcoming releases:

  • Ease of customization and deployment across multiple devices
  • Support for Log Decoders via Live

Lateral movement is a part of the kill chain. After an attack has taken place, which allows entry into a company’s internal environment, lateral movement is the process of elevating credentials and gaining access to additional internal systems. This document describes a package of content that contains a set of rules to monitor Windows systems for lateral movement.


A vulnerability in the Internet Key Exchange (IKE) version 1 (v1) and IKE version 2 (v2) code of Cisco ASA Software could allow an unauthenticated, remote attacker to cause a reload of the affected system or to remotely execute code.


This is registered as CVE-2016-1287.  See the Cisco Security Advisory for additional information


Live Content

There are two pieces of content in Live, which identify events within SA that potentially warrant further investigation.

  1. LUA Parser (packets):  ISAKMP
  2. Application Rule (logs):  Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow



For packet-based customers, this LUA parser identifies ISAKMP.    For IKE type 132 (fragment) payloads, an alert is registered if the length field is less than 8, which indicates an attempt to exploit Cisco ASA Buffer Overflow CVE-2016-1287.  ISAKMP sessions on ports other than UDP 500 or 4500 will not be parsed.


Parser Details:



          * FeedParser

          * NETWORK


          * alertids_warning




     * - mapped to risk meta

     * service - '500'



          * isakmp buffer overflow


Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Application Rule

Customers who deploy either Cisco IPS or SourceFire Defense Center may benefit from this log-based Application Rule written to detect indicators to CVE-2016-1287: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow.


SourceFire signature IDs utilized to detect this vulnerability are '1:36903' and '1:37674' while Cisco IPS signature IDs are 7169-0 and 7169-1.


Rule Logic:

Rule Name: nw125025

Condition:  device.type='snort','ciscoidsxml' &&'"SERVER-OTHER Cisco ASA IKEv1 invalid fragment length heap buffer overflow attempt"', '"SERVER-OTHER Cisco ASA IKEv2 invalid fragment length heap buffer overflow attempt"', 'Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow'

Alert On:




Rule Details:


          risk.warning - Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow







Customer  Content

Since a result of the vulnerability is a large increase in ISAKMP sessions utilizing UDP port 500 or 4500, a Correlation Rule or ESA rule could be created to detect traffic over a threshold typical within the customer environment.


The rule should be tailored to the customer environment:

  1. Condition ‘device.type='ciscoasa' && ip.dstport=500’ is added to detect logs with Cisco ASA enabled.  Remove if not needed or update to allow for ip.dstport 4500 if applies to environment
  2. Default threshold is a single ip.src generating traffic to greater than 200 unique ip.dst.   Customize the threshold for the customer environment


Sample Basic Correlation Rule


Rule Name:  Cisco ASA Buffer Overflow Vulnerability

Condition:  medium=32 && device.type='ciscoasa' && ip.dstport=500

Threshold:  u_count(ip.dst)>200

Instance Key:  ip.src

Time Window:  5 minutes




Sample ESA Rule

Create an Advanced ESA rule and copy and paste the following.  Be sure to customize for the environment as described above.


The @Hint to reclaim groups should match in seconds the total time set for the window.






medium=32 AND device_type='ciscoasa' AND ip_dstport=500

).std:groupwin(ip_src).win:time_length_batch(5 minutes, 200).std:unique(ip_dst)

GROUP BY ip_src

HAVING COUNT(*) = 200;

Filter Blog

By date: By tag: