Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2016 > August
2016
Eric Partington

SSL and NetWitness

Posted by Eric Partington Employee Aug 29, 2016

Encrypted traffic, we all can see that the percentage of encrypted traffic is increasing month by month making it harder to detect and investigate malicious traffic.  With services like Let's Encrypt the bar is lowering to how much effort it takes to get a valid certificate for whatever purpose.

I was following the twitters and noticed this interesting post which got me thinking about what we can see with regards to ssl certificate information.

Hunting Threat Actors with TLS Certificates

The RSA Live TLS_Lua parser gets you some interesting information about the CA, Subject, and Serial as well as a number of interesting meta artifacts.  There are a few changes that you need to make to the default indexes to be able to perform more than exists or !exists queries on those fields which might be useful to allow pivoting on specific certificate CA or other items.

Default values as of 10.6.1 for index-concentrator.xml

<key description="SSL CA" level="IndexKeys" name="ssl.ca" format="Text" />
<key description="SSL Subject" level="IndexKeys" name="ssl.subject" format="Text" />

 

Changes to default index-concentrator-custom.xml

To make ssl.ca and ssl.subject queryable by more than exists or !exists and adding one more key ssl.serial

Before making changes, test, test again and then test.

 

    <key description="SSL CA" level="IndexValues" name="ssl.ca" format="Text" valueMax="100000" defaultAction="Closed"/>
    <key description="SSL Subject" level="IndexValues" name="ssl.subject" format="Text" valueMax="100000" defaultAction="Closed"/>
    <key description="SSL Serial" level="IndexKeys" name="ssl.serial" format="Text" valueMax="10000" defaultAction="Closed"/>

 

Now you have the ability to search and pivot on CA and Subjects in your environment for unusual CA authorities. 

  • What are your top 10 CA ?
  • What are your bottom 10 CA ? anything unusual there ?
  • self signed internal certificates ?
  • indications of CAs from IOT devices? 
  • Are there alerts or risk.* for self signed certs or cert chain missing ?

I have included a profile group for crypto traffic as well as a meta group for similar traffic.  The profile looks for crypto exists to locate traffic where crypto is detected and that meta is written.

 

Testing with a bunch of test pcaps got me this nice mix of CA's but I'd be curious to see what larger environments with more diverse traffic would see.

SSL CA

 

Here is my meta group to pull together some interesting metakeys for crypto traffic

metakeys crypto

 

If you have access to RSA NW and the RSA Live section you can click on TLS_Lua and locate details to see in depth what is written and when.

 

There is also the ability to create custom lookup actions called Context Menu items that allow you to right click on a meta value and look up that value at an external url (as parameter {0}).  So I have also included below the code to enable right click lookups on the ssl.ca and ssl.subject and query google for that information.  Never know what will pop up that is useful but saves time trying to select, ctrl+c and paste into google.

 

{
    "displayName": "Google SSL CA",
    "cssClasses": [
        "ssl.ca",
        "ssl-ca",
        "ssl.subject",
        "ssl-subject"
    ],
    "description": "",
    "type": "UAP.common.contextmenu.actions.URLContextAction",
    "version": "1",
    "modules": [
        "investigation"
    ],
    "local": "false",
    "groupName": "externalLookupGroup",
    "urlFormat": "http://www.google.com/search?q={0}",
    "disabled": "",
    "id": "GoogleSSLCA",
    "moduleClasses": [
        "UAP.investigation.navigate.view.NavigationPanel",
        "UAP.investigation.events.view.EventGrid"
    ],
    "openInNewTab": "true",
    "order": ""
}

context-sslca-google

 

Happy hunting, comment or DM if you find anything interesting in your networks that you can share.

There's been a lot of buzz lately about the Pegasus iOS malware and associated exploits. One of the many ways we help customers track and understand these types of threats is by addition IOCs to our various Feeds. This specific instance caused the addition of over 300 domains to our Third Party IOC Domains feed. One of the advantages of using this feed is not only do we track down additional indicators to insure you have the greatest amount of coverage, but this feed is automatically curated. That means indicators are aged out after 90 days so you don't have to worry about stale indicators.

Robert Dredger

Enable SNMP via CLI

Posted by Robert Dredger Employee Aug 26, 2016

      RSA NetWitness allows for the configuration of SNMP via the Web User Interface (UI).  When configuring multiple hosts however, it can be more efficient to utilize the Command Line Interface (CLI).  This document gives a brief walk-through for enabling SNMP on RSA NetWitness Hosts and updating the onboard Firewall with the appropriate Rules. To configure SNMP via the WebUI, checkout Set SNMP - RSA Security Analytics Documentation 

 

Task:  Enabling SNMP on RSA NetWitness Appliances

 

Process:  First we must ensure the onboard Firewall within CentOS is properly configured to allow SNMP traffic, UDP Port 161. Login to the CLI with elevated privileges. 

       

       1.)  Ensure that SNMP is not currently running with the following command:

                 #service snmpd status   

        2.)  The response should be:  

                  #snmpd is stopped

 

      Next, review the current IP Tables of CentOS to determine if UDP Port 161 is listed.

         3.)  Utilize the following command to list the rules in all chains:

                    #sudo iptables -L

         4.)  Out of the box configuration does not include a rule for UDP.  Enter the following command to create a rule allowing traffic on UDP Port 161:

                     #sudo iptables -I INPUT -p udp -m udp --dport 161 -j ACCEPT

                     #sudo service iptables save

          5.)  The Firewall Rules have now been updated to include UDP 161.  Enter the following command to start the SNMP service:

                     #service snmpd start

 

           6.)  To ensure that the SNMP daemon starts automatically after restart, utilize the following command

                     #chkconfig snmpd on 

 

 

Conclusion:   At this point, the RSA NetWitness appliances you have configured should be discoverable through SNMP.  Further configuration of the /etc/snmpd/snmpd.conf file will allow you to name your device, add a POC, identify a community string, and a host of other options.  

 

Additionally:  The possibility exists to utilize Puppet to configure these changes across your deployment.  I'll be adding a follow-up document that illustrates how to utilize this method.  As always, feedback and suggestions from the community are welcome.  Please drop your two-cents as there is always room for improvement!

 

Credit:  Thank you KEVIN DIENST for the reminder about #chkconfig snmpd on , Good looking out!

Thanks,
RSA Bob

I've developed a application rule to detect phishing attempt using fake LinkedIn site.

Don't hesitate to leave any suggestion or comment to enhance this app rule

 

[Scenario]

Attacker lure a user to click a fake LinkedIn link.

the fake web site looks like a legitimate linkedin login page

the user put his/her linkedin' ID/Password

Attacker get user's id and credential, redirect to original linkedin web site.

 

How to detect this attempt using SA application rule

I've used an app rule and SEARCH parser.

 

<App Rule>

Rule name: LinkedIn phishing

Rule: extension='php' && match = 'LinkedIn','Linkedin','linkedin'

 

Dependancy: SEARCH parser

 

<search.ini>

[LinkedIn]

Services=80

Keywords=LinkedIn;Linkedin;linkedin

 

Attachment:

fake linkedin log-in page: fake_linkedin.jpg

pcap sample: linkedinphishing.pcap###

With the release of Security Analytics 10.6.1, we are more formally introducing the new RSA Live Connect community based threat intelligence sharing service.  This service is a cloud based threat intelligence service that gathers, correlates, analyzes, and process threat intelligence across the RSA Security Analytics community.  During this initial release of RSA Live Connect, the "Analyst Behaviors" service option provides an opportunity to voluntarily contribute threat intelligence information anonymously and securely to the Live Connect cloud service.  This threat investigation information will be used by RSA to improve the RSA Live threat intelligence services.   

 

 

Enabling the RSA Live Connect service in Security Analytics:

 

As mentioned, participation in the RSA Live Connect service is completely voluntary.  Upon initial install or upgrade of Security Analytics 10.6.1, an application administrator will proactively be presented with a popup window with detailed information about the service and the opportunity to confirm acceptance into the service or opt out through the Live Services configuration interface.  Also, authentication to Live Connect is down with existing RSA Live credentials.  If you don't have an RSA Live account, details for enrolling and configuring can be found at RSA Security Analytics Live account.  

 

Service popup:

 

 

 

Authentication via RSA Live Credentials:

 

 

 

 

Live Services Configuration:

 

 

 

The Live Connect service is being introduced as an open beta for all RSA Security Analytics customers with internet access and an RSA Live credential.  Participation in the beta is anonymous and optional.  For more detailed information about configuration and service details, see the RSA Security Analytics Live Connect documentation.

 

NOTE:  The RSA Live Connect service also provides a 'Threat Insights' option that is independent of the 'Analyst Behaviors' option.  Details for this option can be found in the blog post 'Leveraging RSA's New Live Connect Community Based Threat Intelligence Service'.  In addition, for a more detailed description see the RSA Security Analytics Live Connect documentation.

Ever feel like an analyst alone on an island attempting to hunt down the latest attack or risk in your network?  Or, when trying to investigate an incident or potential attack, do you ever find yourself digging through mountains of data and information while still not feeling like you have enough context or perspective on the data to make informed decisions?

 

With the release of Security Analytics 10.6.1, we are more formally introducing the new RSA Live Connect community based threat intelligence sharing service.  This service is a cloud based threat intelligence service that gathers, correlates, analyzes, and process threat intelligence across the RSA Security Analytics community.  In turn, this intelligence can be leveraged by SA customers during the threat investigation workflow.  During this initial release RSA Live Connect, the "Threat Insights" service option will provide a threat intelligence risk assessment, anonymous community statistics, and an opportunity to 'give back' to the community by providing risk assessment feedback for a given IP address that Live Connect is tracking.

 

 

 

Enabling the RSA Live Connect service in Security Analytics:

 

Participation in the RSA Live Connect service is completely voluntary.  Upon initial install or upgrade of Security Analytics 10.6.1, an application administrator will proactively be presented with a popup window with detailed information about the service and the opportunity to confirm acceptance into the service or opt out through the Live Services configuration interface.  Also, authentication to Live Connect is down with existing RSA Live credentials.  If you don't have an RSA Live account, details for enrolling and configuring can be found at RSA Security Analytics Live account.  

 

Service popup:

 

 

Authentication via RSA Live Credentials:

 

 

 

Live Services Configuration:

 

 

Leveraging the RSA Live Connect service during SA Investigations workflow:

Once you have enabled and configured the Live Connect service, an analyst will have the ability to leverage the Live Connect IP based threat intelligence during the Security Analytics Investigation workflow via the Context Hub.  If there is community based threat intelligence available for a given IP, the IP will be highlighted and a user can right mouse click to the Context Hub with a detailed view of the Live Connect assessment and statistics for the respective IP address.

 

 

In addition, upon completing an investigation on the given IP address, in turn, the analyst can provide feedback to RSA Live Connect to confirm that the IP is seen as 'Safe' or 'Risky'.  Again, this feedback is voluntary and anonymous.  However, feedback by the analysts provides tremendous value and insight to the RSA Live Connect service when assessing the risk level and providing insight to the broader RSA SA community.

 

 

The Live Connect service is being introduced as an open beta for all RSA Security Analytics customers with internet access and an RSA Live credential.  Again, participation in the beta is anonymous and completely optional.  For more detailed information about configuration and service details, see the RSA Security Analytics Live Connect documentation.

 

NOTE:  The RSA Live Connect service also independently provides an 'Analyst Behaviors' option for sharing threat investigation information that is independent of the 'Threat Insights option.   Details for this option can be found in the subsequent blog post 'Giving Back to the Community Through RSA Live Connect's 'Analyst Behaviors'.  In addition, for a more detailed description see the RSA Security Analytics Live Connect documentation.

With the rapid growth in the number threat intelligence providers and services, the need and focus for threat intelligence format standards and protocols became inevitable.  With the emergence of STIX, Structured Threat Information eXpression, threat intelligence providers, application vendors, and users could begin to share and leverage threat intelligence by speaking a common language.  (For additional information about STIX, see Structured Threat Information eXpression). 

 

With the release of Security Analytics 10.6.1, RSA will begin providing some initial basic support for the STIX threat intelligence file format.  Initial support for the STIX format will be focused on threat indicators through STIX 'Observables' and 'Indicators'.  Specifically, a user will be able to import threat indicators such as IP addresses, file hashes, and URLs.  Similar to the existing ability in Security Analytics to import custom CSV based threat intelligence feeds, a user will be able to map the intelligence imported from a STIX feed to the creation of meta data during packet and/or log capture time by the SA decoders.  Once meta data is created, a user can leverage the information during threat detection and/or during the threat investigation workflows.   

 

 

Custom Feed Importing:

As mentioned, importing a STIX feed is similar to importing a Live Custom Feed (See Live Custom Feed Configuration).  After specifying the STIX feed type, a user can choose to do a one-time 'Adhoc' import from disk or a 'Recurring' feed from a specified URL location.

 

 

Specify STIX and 'Adhoc' or 'Recurring'.

 

 

Mapping to Meta Data:

Upon specifying the feed, the user can map the information to metadata.

 

 

Leveraging During Investigation:

 

After importing and/or configuration is complete, SA will begin to create meta during data capture time. Upon metadata creation, users can leverage the STIX based threat intelligence during subsequent investigations.

 

 

 

For additional details about Security Analytics STIX support, see Security Analytics STIX.

The Netwitness Suite provides out-of-the-box a number of tools to analyze your data. But there is a capability hidden under the hood which if implemented correctly may be precious to identify additional suspicious patterns: the development of a baseline to perform a trend analysis.

 

This approach can help whenever a significant change in the rate  of a given value could imply a security issue. Of course not all the threats can be identified in this way!

 

To perform any statistical analysis, numbers are an obvious requirement and these have to be derived from the collected events first. The attached (unofficial) model, inspired by the new 10.6 Event source Automatic Monitoring functionality, offers a solid way to count the number of occurrences without requiring to buffer all the events in memory for a long timeframe. 

 

For each value of a given meta key, the number of occurrences are counted every minute and then aggregated every five minutes, hour and day to minimize the impact on ESA performance. Then, for each hour (and for each day), a baseline is created.

 

 

In case there is a significant deviation in the rate of any meta value, an alert is generated.

The duration of the learning phase, the entity of the deviation and the duration of the baseline are all configurable parameters. 

 

As an implementation best practice, do not use meta keys with too many unique values (e.g. ip.src) since would generate too many false positives. Start focusing on those with a few but significant unique values, like as:

  • Browsers - uncommon client may be associated with malicious codes
  • Country source/destination - can help identifying attacks or potential data exfiltration
  • TLDs - uncommon TLDs can be an indicator of something strange happening

 

All the details regarding the model, how it works, how to implement it and all the technical details can be found in the attached presentation together with the full EPL code.

 

For a different but complementary approach, I'd suggest reading this excellent post by Nikolay Klender: https://community.rsa.com/thread/187264 

 

Please note this is not RSA official/supported content so use it at your own risk!

Help us understand how you monitor and respond to incidents related to your Assets and Identities.

Click here to take the short survey.

The RSA Content team is pleased to announce the addition of the following new features along with new and updated content to the RSA Live Content Library. 

 

Live Content Search Tags

A new set of Advanced Security Operations Center (ASOC) tags have been introduced in Live to provide an easier way to search for relevant content. These tags are used to organize Live content and to deliver an accurate path to information security incident response. The tags are found in the Tags field in the Live Search Criteria view. The objective of a tag is to catalog existing content for deployment according to an incident response approach. RSA LINK.

 

Traffic Flow- Directionality

Decoders can now derive the directionality of traffic using the source and destination hosts referenced within a session. This information 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). RSA LINK.

 

Ransomware Indicators in Feeds

Ransomware continues to be a significant threat to our customers, so this is a very timely addition.  Abuse.ch has added a ransomware tracker which tracks the following families of ransomware:

TeslaCrypt

CryptoWall

TorrentLocker

PadCrypt

Locky

CTB-Locker

FAKBEN

PayCrypt

 

We’ve added these indicators to the following feeds in LIVE:

 

1.    Third Party IOC Domains

2.    Third Party IOC IPs

 

Here is the link to the Blog Post.

 

10.6.1 Related Updates

 

Enhanced Log Parsing functionality

An enhancement has been made to the transfer of logs from the Log Collector to the Log Decoder which can minimize the chances of incorrect parsing. As part of the Log Collector configuration of certain types of event sources, such as File or ODBC, the Administrator can now specify the event source type, such as Apache or Oracle. The Log Collector now passes this information to the Log Decoder so that the Log Decoder can directly use the specified parser. No configuration changes are necessary, but new Log Collector content will need to be applied from Live in order to benefit from this enhancement.

 

Enhanced Content Deprecation

All the content on Live has been reviewed to see if there is any that is outdated and can be discontinued. Individual services can be scanned for discontinued content.  The discontinued resources are displayed in red on the UI. Refer to the Live Services Management guide for more details.

 

Here is a list of all Discontinued Content on Live. RSA LINK. 

 

Out of the Box Content Updates

 

RSA Security Analytics Content team has updated the following parsers and analytical content based on feedback from our customers and partners:

 

For a full breakdown please go to RSA LINK.

 

Analytical Content

Application Rules

1 New Rules has been added.

1 Rule has been updated.

 

Feeds

4 Feeds have been updated.

 

Security Analytics Rules

4 New Rules have been added.

2 Rules have been updated.

 

Security Analytics Reports

1 New Report has been added.

 

Parser Content

Packet Parsers

3 New Parsers have been added.

15 Parsers have been updated.

 

Log Parsers

45 parsers have been updated

 

Additional Information

The entire content library can be viewed here:

https://sadocs.emc.com/0_en-us/300_RSA_ContentAndResources

 

Content requests can be made here:

https://sadocs.emc.com/0_en-us/300_RSA_ContentAndResources/RSA_Content_Resources/40_Request_Portals

 

Regards,

The ASOC Content Team ( ASOC.Content@rsa.com )

Ever wondered if there was an easier method to compare or export all the application, correlation and network rules from your log and packet decoders to see if they were all deployed the same or to keep as an archive ?

 

Using the magical REST interface, that can be achieved with a python script which is included here.  The script takes as input a csv of the devices to read from that include the ip or hostname, the username and password as well as a device type and friendly name to use in the output.  Script is designed to be run from the SA server and will reach out to the decoders and log decoders defined in the csv as long as firewall ports in your environment allow access.

 

you can pipe the output to a file to capture the results and archive or split into individual csv files for comparison or archival or just use the md5 of each of the outputs to compare and see if they are the same.

 

I have a number of folders on my SA server for different scripts this one lives in rsa-rule-dump

 

depending if the python environment variable is set for you

[UPDATE 2016-08-12]

Added and moved output around to get the hash, line count and any warnings about rules that are order dependent to each section.

 

 

python rsa-rules-dump.py devices-rsa.csv

 

 [94m################################################################## [0m
 [94m# Checking for 200 http status codes - which are good [0m
 [94m# application rules http status code = 200 [0m
 [94m# network rules http status code = 200 [0m
 [94m# correlation rules http status code = 200 [0m
 [94m################################################################## [0m
 [95m# http://ldecoder1:50102 decoder
 [0m
#HASH-RULE-APPLICATION,http://ldecoder1:50102,3bb54113e830814a2c979b49ffe71f41
#CONTENT-RULE-APPLICATION
name=encryption:success rule="ec.theme='encryption' && ec.outcome='Success'" alert=alert.id order=1 type=application uuid=01d6dcde-c6c1-4e9f-a7e5-009c06f2a19a pushFrom="ldecoder1.cancirc.ca Log Decoder"
name=nw05415 rule="reference.id='7045' && service.name begins 'wce','psexe','pwdump','cachedump','gsecdump'" alert=alert.id order=2 type=application uuid=5ac784a4-7af4-4f43-afba-bbd46a7de516
name=nw30060 rule="reference.id='528','540','4624' && logon.type='3' && process='NtLmSsp' && user.dst!='ANONYMOUS LOGON' && NOT(user.dst ends '$')" alert=alert.id order=3 type=application uuid=96dd09e0-3413-4c74-9bda-f4532f1ecf39
name=threatstream rule=alert\='threatstream' alert=threat.source order=4 type=application pushFrom="ldecoder1.cancirc.ca Log Decoder"
name=nw110150 rule="alias.host ends '.box.com', '.boxcloud.com', '.box.net', '.dropbox.com', '.dropboxstatic.c
om', 'github.com', '.icloud.com'" alert=alert.id order=5 type=application uuid=f26f78fc-f172-4352-94ef-37e9995de746 pushFrom="ldecoder1.cancirc.ca Log Decod

 

 

# HASH-RULE-APPLICATION,http://pdecoder:50104,cfed6704667382464b1ba6f21cd0579b
# COUNT-RULE-APPLICATION,http://pdecoder:50104,496
 [91m# !!WARNING: Check that dependent alerts are above these rules: ['nw110055', 'nw20055']
name=nw110055 rule="alert.id = 'nw12525' && size > 5242880 && streams =2 && ip.src = 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 && ip.dst != 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16" alert=alert.id order=32 type=application
name=nw20055 rule="alert.id = 'nw02550','nw02520', 'nw02560','nw02555' && filetype begins 'fp_'" alert=alert.id order=49 type=application uuid=4f98a661-4b7c-4126-8149-acfda64ac677

Filter Blog

By date: By tag: