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

Servers are attacked every day and sometimes, those attacks are successful.  There is a lot of attention to Windows executables that come down on the wire, but I also wanted to know when my systems were downloading ELF files, typically used by Linux systems.  With some recent exploits that target Linux web servers and the delivery of crypto-mining software, I wrote a parser that attempts to identify Linux ELF files and places that meta in the 'filetype' meta key.

 

 

 

This isn't limited to crypto-mining ELF files and has detected many others in testing.  The parser is attached below.

 

I hope you find this parser useful, and as always, happy hunting.

 

Chris

Whenever I am on an engagement that involves the analysis of network traffic, my preferred tool of choice is the RSA NetWitness Network (Packets) solution.  This provides full packet capture and allows for analysts to "go back to the video tape" to see what happened on the wire.  When the decoder examines the traffic, it tries to identify the service type associated with it.  HTTP, DNS, SSL and many others are some examples.  However, there are times when there is no defined service.  This results in 'service = 0'.  

 

When time allows, I like to go in there, but as you may notice, there can be quite a lot of data to go through.  Therefore, I like to focus on small slices of time and attributes about those sessions that makes sense.  For example, I might choose the following query over the last 3 hours.

 

   service = 0 && ip.proto = 6 && direction = 'outbound' && tcpflags = 'syn' && tcpflags = 'ack' && tcpflags = 'psh'

 

This query will get to the sessions where:

   service = 0 [OTHER traffic not associated with a service type]

   ip.proto = 6 [TCP traffic]

   direction = 'outbound' [traffic that starts internally and destined for public IP space]

   tcpflags = [Focus on SYN, ACK, and PSH because those TCP flags would have to be present for the starting of a session and the sending of data]

 

Next, I look at associated TCP ports (tcp.srcport and tcp.dstport) as well as some IP's and org.dst meta.  What we recently found was a pipe delimited medical record in clear text.  After some additional research, we came across this fantastic blog post from Tripwire discussing Health Level 7 (HL7).  In it, the author, Dallas Haselhorst, even showed the pipe delimited format that the HL7 protocol uses to transfer this data.  It was this format that was observed on the wire.

 

While the idea of medical records being transmitted on the wire in clear text was alarming at first, it was determined that this was in fact, a standard practice.  If used to cross the Internet, VPN tunnels would be used.

 

To get a sense of how much traffic I could see, I created a parser to identify this as 'service = 6046'.  I chose '6046' because that was the first port I observed, however in truth, we eventually saw it on numerous tcp.dstport's.  This parser is just going to identify this as HL7 and will not parse out the information contained in the fields.  Some of that data will likely contain Personal Health Information and it is not something I wanted as meta.  But, knowing it is on the wire in the clear was important to me and my client.  

 

If you work in an organization that handles this kind of data, this parser might help identify and validate where it's going.  

 

Good luck, and happy hunting.  Also..special thanks to one of my new team-mates, Jeremy Warren, who helped find this traffic.

 

Chris

If you haven’t seen the new RSA NetWitness Platform, you are missing out. Over the past 12 months, we have released new innovative capabilities, redesigned the user experience and invested in our core functionality to ultimately increase the speed of detection and response to threats.  We believe that we not only have to enable organizations to detect incidents earlier – before there is business impact, but that we must focus on the precious time of the human analysts – no matter what their skill level is.

 

That is why the RSA NetWitness Platform evolved SIEM provides security monitoring, detection and investigation tools under a single unified platform – across logs, network and endpoint data, with our new orchestration and automation capabilities to aggregate, standardize and normalize alerts from your entire stack of security technologies. And, we are excited to announce we are now offering user and entity behavior analytics as part of the RSA NetWitness Platform. In addition, because we believe it is absolutely critical to have end to end visibility, we are offering free endpoint insights to RSA NetWitness Platform customers.

 

I’ve only shared 4 of the 11 reasons so far (UEBA, Free Endpoint Insights, Orchestration & Automation and a redesigned and intuitive UI) – but there is so much more! Read more about the significant functionality the RSA NetWitness Platform 11.x provides to enable rapid detection and response.

Here's the steps you'll need to follow to initiate a fork of the RSA NetWitness Log Parsers Repository

 

  • Create a fork (your copy of the full repo) from the link on top right corner of page https://github.com/netwitness/nwlogparsers
  • Create a new branch in your repo for your work and add your new parser work under community folder
  • Each new parser should be kept in a new folder with its name
    • only add the parser.xml file (not zip or .envision file)
  • Create a new folder for your parser by clicking new file button, when the box shows up add the folder name then a slash and then the file name (this creates a folder for your file which isn’t obvious from the UI)
  • Copy and paste the text of your parser into the editor
  • Only include the .xml and .ini file and nothing else (no .envision or .zip)
  • Add data to the Commit description at the bottom and click commit new file
  • Raise a pull request to merge your changes to the RSA NetWitness repo
    • Open your repo page on github.com
    • Click create pull request
    • Name the pull request
    • Request will go to the RSA content team for review and merging into the parser(s)

How to Update your forked log-parsers repository to get latest version

  • Log into your github account
  • Locate the forked nw-logparsers repository in your account

  • Click on compare (right side)

You will get a notification like this if it’s the first time for comparing

There isn't anything to compare.
someone:master is up to date with all commits from me:master. Try switching the base for your comparison.

Click on switching the base

Or you will see this if you have compared before:

 

*** important  ***

Github defaults to sync your changes to the upstream fork, in this case we want the opposite.

Chagne the base fork (left option) to be your fork (not the netwitness/nw-logparsers)

Now you will see a different comparing changes screen and a note about comparing the same two things:

 

Click the compare across forks:

Click the head fork and change to the netwitness/ fork:

Now you see the commits since the repository was forked:

Click on Create pull request:

Give it a title and if required a description

 

On the next page click Create pull request

Click confirm merge:

Your copy of the RSA Netwitness nw-logparsers repo is now updated

You can review the latest code and also submit new parsers or updates to your already submitted parsers using the above process.

 

The resource I used which helped me along with this was the following very helpful GitHub link:

https://github.com/KirstieJane/STEMMRoleModels/wiki/Syncing-your-fork-to-the-original-repository-via-the-browser

The Google Cloud Platform provides Infrastructure as a Service, Platform as a Service and Server less computing environments.

 

The Google Cloud Platform services deliver audit logging to help answer the question of "who did what, where and when?" Google Cloud Audit Logs are captured by Google StackDriver, which provides powerful monitoring, logging, and diagnostics; equipping users with insight into the health, performance, and availability of cloud-powered applications. These insights enable users to find and fix issues faster and is natively integrated with Google Cloud Platform. For more information please visit the following links:

GCP: https://cloud.google.com/

Stackdriver: https://cloud.google.com/stackdriver/

Cloud Audit Logs: https://cloud.google.com/logging/docs/audit/

 

The logs from StackDriver can be imported into the RSA NetWitness Platform using the RSA NetWitness Google Cloud plugin. This plugin pulls logs from StackDriver via a Google Cloud Pub/Sub subscription.

 

Below is a basic flow diagram that outlines how the logs flow into the RSA NetWitness Platform:

 

 

Here are a few example use-cases that can provide insights into the capabilities of the Google Cloud Platform, using the Google Cloud Audit Logs:

 

  1. Resource creation, update or deletion.
  2. Addition of a user to a new IAM role.
  3. Access to sensitive Data and Resources.

 

To take advantage of this new capability within RSA NetWitness, please visit the link below and search for the terms below in RSA Live.

 

 

Configuration Guide:  Google Cloud Platform Event Source Configuration Guide

Collector Package on RSA Live: "Google Cloud Log Collector Configuration"

Parser on RSA Live: CEF

One of the useful features that was released with RSA NetWitness 11.1 was the NetWitness API which provides access to the Incidents and Alerts from the Respond Engine.

 

Documentation is located at the link below which is very useful from a schema perspective.

 

NetWitness Suite API User Guide for Version 11.1 

 

Using that Guide and a helpful internal training video, I found a very useful Google Chrome plugin to help test integrations with the API.

 

Restlet Client - REST API Testing - Chrome Web Store 

 

Using this plugin you can simulate RSA NetWitness Orchestrator web calls or anything that is calling the API to validate what to expect and test.

 

The first thing to do is follow general security best practice and create a role and user in RSA NetWitness to reduce the required permissions to just what is required.  Currently I am still testing to see if i can reduce the roles further but the current permissions are much less than the default 'admin' account.

 

Create a new Role (I called it Orchestration)

  • Admin > Security > Roles
  • Add the following rights
  • Alerting - access alerting module view alerts, view rules
  • Incidents - Access incident module, delete alerts and incidents, manage alert handling rules, view and manage incidents
  • Integration server - integration-server.api.access (this is the required criteria according to the api doc)
  • Respond Server - respond-server.alert.delete,respond-server.alert.manage,respond-server.alert.read,respond-server.incident.delete,respond-server.incident.manage,respond-server.incident.read,respond-server.journal.manage,respond-server.journal.read,respond-server.notifications.manage,respond-server.notifications.read, respond-server.process.manage,respond-server.remediation.manage, respond-server.remediation.read,respond-server.security.manage, respond-server.security.read

 

create a new User (I called it Orchestrator)

  • Add it to the Role: Orchestration

 

Now there is an account to use for testing with the API and integrating with RSA NetWitnessOrchestrator.

 

Using Restlet-client import the three 'requests' from the github link below:

GitHub - epartington/rsa_nw_netwitnessapi 

 

This will get you a nw-getauth, nw-get-incident, nw-get-alert

 

Use nw-getauth to request a security token from the RSA NetWitness API (update for your RSA NetWitness interface)

 

 

Hit send and you should get back a 200 OK result with the security tokens to use in the next submissions.

 

Now you have the accessToken value to use to authenticate your next commands (copy the accessToken value)

Use the nw-get-incident request to get the details for a specific incident (INC-XXX)

 

Insert the value for the accessToken into the RSA NetWitness-Token field and hit send.

 

If everything works well you should get back another 200 OK with the json dump of the values on that specific incident

 

 

You can click download to grab a json export of this incident to use to work offline, investigate, upload to a demo RSA NetWitness Orchestrator system ... A sample one is included in the github link.

 

To grab the alert details from this incident use the 3rd 'request' nw-get-alert

 

Again you should get a 200 OK with the details of the Alerts for the incident requested

 

 

 

Again you can download the json file to get the full details of the alert to know what you can work with in RSA NetWitness Orchestrator/Crystal Reports.

 

This is the equivalent output from the Respond Incident window (alerts are the same missing items), the area in the red box don't appear to be available in the API.  An internal Jira has been opened on this to enhance or resolve this (I can't figure out if this is a bug or feature request).

 

Version 11.0 NetWitness Logs and Network documentation is now available in French, Japanese, German, and Spanish.

 

RSA NetWitness Logs & Packets 11.0 (French) 

RSA NetWitness Logs & Packets 11.0 (Japanese)

RSA NetWitness Logs & Packets 11.0 (German) 

RSA NetWitness Logs & Packets 11.0 (Spanish) 

Filter Blog

By date: By tag: