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

This article applies to hunting with Netwitness for Networks (packet-based). Before proceeding, it is important that you are aware of any GDPR or other applicable data collection regulations which will not be covered here.


Hunting for plaintext credentials is an important and easy method of finding policy violations or other enablers of compromise. Increasing numbers of the workforce in remote or work-from-home situations means that employees will be transferring data over infrastructure not controlled by your organization. This may include home WiFi, mobile hotspots, or coffee shop free WiFi.


Frequently, this hunting method will reveal misconfigured web servers, poor authentication handling, or applications using baked-in URLs and credentials. While Netwitness does a good job parsing this by default, there are additional steps that can be taken to increase detection and parsing.


Key Takeaways

  • Ensure the Form_Data_lua parser is enabled and updated
  • Also hunt for sessions where passwords are not parsed



Most environments will have either the HTTP or HTTP_lua parser currently enabled considering that it is one of the core network parsers. You can check this under your Decoder > Config tab in the Parsers Configuration pane. More details about system parsers and Lua equivalents can be found here:



This parser looks at the body of HTTP content whereas the HTTP/HTTP_lua parsers primarily extract credentials from the headers. Before enabling Form_Data_lua, it is important to understand that this can come with increased resource usage due to the amount of additional data being searched.  You can find statistic monitoring instructions here, although this itself can come with a performance impact as well:


For the purpose of this hunting method, you can disable the “query” meta key if there are resource concerns. In either case, be sure to monitor keys for index overflow. You can adjust the per-key valueMax if needed per the Core Database Tuning Guide:


Also, if you are not subscribed to and deploying the Form_Data_lua parser, be sure to deploy the latest copy from Live. Along with optimizations, recent changes expand the variables that the parser is searching for, as well as introduce parsing of JSON-based authentication.



Once the parsers are enabled, you can go to Investigate > Navigate and begin a new query. For ease of record keeping, I like to structure my hunt in these categories:

  • Inbound
    • Password exists
    • Password does not exist
  • Lateral
    • Password exists
    • Password does not exist
  • Outbound
    • Password exists
    • Password does not exist


The assumption here is that you’re using the Traffic_Flow_lua parser with updated network definitions to easily identify directionality. If not, you can use other keys such as ip.src and ip.dst. More info on the Traffic_Flow_lua parser here:


Querying where passwords exist is straightforward:

password exists && direction = “inbound” && service = 80
password exists && direction = “lateral” && service = 80
password exists && direction = “outbound” && service = 80


Querying where passwords do not exist requires a bit of creativity and assumptions. In many cases, authentication over HTTP will involve URLs similar to http[:]//host[.]com/admin/formLogin. This path is recorded in the directory and filename meta keys, where “/admin/” would be the directory and “formlogin” would be the filename.


I’ll often start with the below query (the exclamation point is used to negate “exists”):

password !exists && direction = “outbound” && service = 80 && filename contains “login”,”logon”,”auth”


You can follow this pattern for other directions, filenames, and directory names as you see fit. The comma-separated strings in the filename query act as a logical OR. It would be equivalent to the following. Pay attention to the parentheses:

password !exists && direction = “outbound” && service = 80 && (filename contains “login” || filename contains ”logon” || filename contains ”auth”)


Many authentication sessions will occur using the “POST” HTTP method. If you’d like, you can also append ‘action = “post”’ to the above query.



After your query completes, you’ll be left with a dataset to review. (Hopefully) Not all of them will contain credentials, but this is where the human analysis begins. Choose a place to start, then open the Event Analysis view (now known simply as Event view in newer versions). My example here will be heavily censored for the purpose of this blog post.

Choose the “Decode Selected Text” option to make viewing this easier.

Now that you’ve found sessions of interest, you can begin appropriate follow-up action. Examples may include advising the website developer to enable HTTPS or discussing app configuration with your mobile appliance team.



This hunting method will aid in analyzing security posture from outbound, inbound, and lateral angles. It also serves as an easy gateway for analysts to quickly make a positive security impact as well as become familiar with the intricacies of HTTP communication.


Netwitness parsers must balance performance considerations alongside detection fidelity. While they currently have good coverage, it’s beneficial to know how to search data that is structured in a way that is malformed or formatted such that it is impractical for Netwitness to parse.


For more hunting ideas, see the Netwitness Hunting Guide:


If you have any comments, feel free to leave them below. If you’re finding recurring patterns in your environment that are not parsed, you can let us know and we’ll assess the feasibility of adding the detection to the parser.

A question has come up a few times on how someone could exclude certain machines from triggering NetWitness Endpoint Agent alerts easily.


This particular use case were their "Gold Images" which are used for deploying machines.  As part of a bigger vision for other server roles & rules, a custom meta key was created called Server.Role to hold the various roles they have defined for servers in their environment.


A Custom Feed was created to associate "Gold Image" as a meta value for that Meta Key by matching against, or host.src. This example is just an Adhoc feed, but a recurring feed from a CMDB or other tools could be leveraged to keep this list dynamic.

note: My example has not gold just to contrast the roles.


Now that the meta values are created, we can use these as whitelisting statements for the App rules.

From Admin>Services, select the Endpoint Log Decoder, click View>Config then select the App Rules tab.


Filter by nwendpoint to find the endpoint rules.

Edit the rule you'd like and add a server.role != 'gold image' && in front of the rule as shown in the example below:

Click OK then Apply the rules

Repeat for any other rules you would need whitelisted.


This is just a simple example, but you can use this approach for many other scenarios.

Filter Blog

By date: By tag: