Daniel Spier

HTTP Plaintext Password Hunting and Parser Updates

Blog Post created by Daniel Spier Employee on Jul 30, 2020

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

 

Setup

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: https://community.rsa.com/docs/DOC-79198

 

Form_Data_lua

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: https://community.rsa.com/docs/DOC-80210

 

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: https://community.rsa.com/docs/DOC-81117

 

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.

 

Hunting

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: https://community.rsa.com/docs/DOC-44948

 

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.

 

Analysis

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.

 

Conclusion

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: https://community.rsa.com/docs/DOC-62341

 

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.

Outcomes