Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2018 > January
2018
Ahmed Sonbol

A New Hancitor Campaign

Posted by Ahmed Sonbol Employee Jan 25, 2018

This week RSA FirstWatch observed a new malspam campaign delivering Hancitor malware.  Hancitor is a downloader that was used by adversaries to deliver various malware families such as Pony and Zeus Panda Banker.  Contrary to previous malspam campaigns that used VBA macros to deliver Hancitor, this one is exploiting CVE-2017-11882 in malicious RTF documents.

 

Invoice_304550.doc and fax_645751.doc are two examples of the RTF documents used in this campaign.  Opening them with an un-patched instance of Microsoft Word leaves a user with a blank page. However, a lot of activity is happening in the background.

 

 

First, a suspicious retrieves "1", a script containing our Hancitor payload as a Base64 encoded blob along with the necessary commands to decode and start it as a new process.  

 

 

Looking at the HTTP GET, many of headers in the request are curiously absent.  

  

 

NetWitness Packets flags suspicious meta data (e.g., the file.analysis and service.analysis tags shown below).

 


  

Next, there is a request to a service to idenitfy the IP address of the victim machine:

  

  

Then, it checks-in with a C2 domain (undronride[.]ru) sending the host information via an HTTP POST request.  The directory and filename used in the request reflect the telltale 'ls5/forum.php' characteristics of Hancitor.

 

 

It is worth noting that the C2 domain, undronride[.]ru, was registered just seven days ago and lacks a surprising amount of registration information.

 

 

A second C2 callback to the CNOBIN-registered littarhapone[.]com was also generated by the malware. 

 

 

The following screenshot shows the meta populated by NetWitness Packets for these C2 check-in sessions:

 

 

In both cases, there were no binaries downloaded after the check-in. However, this SANS blog post discusses some of the additional payloads delivered by this Hancitor campaign.

 

 

All the IOC from those HTTP sessions were added to RSA FirstWatch Command and Control Domains on Live with the following meta:

  • threat.source = ‘rsa-firstwatch’
  • threat.category = ‘malspam’
  • threat.description = ‘delivery-domain’

 

Delivery documents (SHA256):

  • b489ca02dcea8dc7d5420908ad5d58f99a6fef160721dcecfd512095f2163f7a
  • 6dcbf652b96a7aea16d0c2e72186173d9345f722c9592e62820bcfe477b2b297
     

After spending some time writing application rules for detecting Powershell, lateral movement and indicators of compromise for endpoint events I figured there would be a good post about how escaping slashes (\) works in the application world.

 

It took me a while to wrap my head around it, so this hopefully saves you some time.

 

This is what an event might look like as meta in NetWitness:

 

 

Notice the slashes in the directory field in the event itself

single slash (\)

 

if you were to drill on that directory meta or copy it out as text it would look like this

HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Active Setup\\Installed Components\\{8A69D345-D564-463c-AFF1-A69D9E530F96} @StubPath

 

notice the single slash (\) is now escaped with another slash (\\)

 

What would you write your application rule to trigger on if your logic was looking for this event (Autorun Active Setup)?

 

nwe.callback_id exists && category = 'autorun' && autorun.type = 'explorer' && directory  contains 'software\\microsoft\\active setup\\installed components'

Notice the apprule in the UI editor works on the escaped slashes (\\)

Another way to check this is to drill on the meta that you want to work with in your application rule and see how that shows up in your breadcrumbs

 

You can see that the breadcrumb shows the escaped string.. this is what we will use in our rule.

 

One more complication... what if you wanted to write your rule in NotePad++ and import them into the decoder?  What would your rule look like there?

 

name=p2_mo_autorun_active_setup rule="nwe.callback_id exists && category = 'autorun' && autorun.type = 'explorer' && directory  contains 'software\\\\microsoft\\\\active setup\\\\installed components'" alert=ioc type=application

 

four slashes (\\\\) ?  when importing from nwr files the slashes need to be escaped again.

So one(\) slash in meta, needs two slashes (\\) in the application rule syntax, which when imported from nwr files needs four slashes (\\\\).

 

Another example is matching a system making a call to a remote service using sc.exe.  How would we match this type of command?

sc \\win7 create remotecmdasservice binpath= "cmd /k start" type= own start= auto 

 

name=p1_creates_remote_service rule="nwe.callback_id exists && category = 'process event' && action = 'createprocess' && filename.dst = 'sc.exe' && param contains '\\\\\\\\' && param contains ' create ' && param contains ' binpath='" alert=ioc type=application

eight (\\\\\\\\) slashes to match two (\\) as meta indicating a remote system when imported via nwr text file.

 

Happy hunting!

During the week following the Orthodox New Year (January 14, 2018), the Necurs botnet re-emerged on the scene with a malspam campaign spreading an old friend, the Dridex banking trojan. 

 

This activity was first identified by a Forcepoint Labs report, which found the campaign using compromised FTP sites rather than HTTP links (as historically observed) for the download of malicious documents.  According to Forcepoint, the malicious emails were sent "primarily to .COM top level domains (TLDs) with the second, third and fourth top affected TLDs suggesting that major regional targets were France, the UK, and Australia respectively".

  

A recent post by Broadanalysis.com also details observations from this renewed Dridex campaign activity. The screenshot below is an sample email with an embedded FTP link for the download of a malicious MS Word document.

 

 

This FTP link leads to the direct download of our malicious Word document.

 

 

This malicious MS Word document contains some less than savory VBA code as flagged by RSA's pre-release Whatsthisfile capability.  This appears consistent with maldocs observed from 21-22 January campaigns that appear to be using macros for exploit and payload delivery (whereas early campaigns as reported by both Forcepoint and Broadanalysis observed DDE exploit CVE-2017-11826 to begin infection chain).

 

 

This VBA code in our malicious document auto-launches and via some heavily obfuscated powershell retrieves the Dridex payload, 'oojsd355'.

 

 

NetWitness Packets flags this download activity through a number of suspicious tags in the service.analysis, session.analysis, and file.analysis fields.

 

 

Post infection, we observed the typical encrypted Dridex Command and Control (C2) callbacks (sample below).

 

 

NetWitness Packets also detects this activity and flags these self-signed certificates in use over both standard and non-standard SSL ports. 

 

 

Thanks to Ahmed Sonbol for his assistance in this research, and all related IOCs can be found below.

 

Delivery documents (SHA256):

  • 7dd1f097ea8f60a291f3840c34d20ca97f0efd68f6ff38a25f8648fdd8c52670
  • 806355b21bcc61294bba6e70b737388188e6af0b2e0b0703b49034a9bd660762
  • 352bcc2deec893c79e42dc3d9fa5136c1397484651a9f8af509f01eabba21301
Delivery domain:
  • techknowlogix[.]net
Delivery URL:
  • hXXp://techknowlogix[.]net/ooJsd355
Dropped binary (SHA256):
  • 3b68424fc2aa42762427789163dc1643b11760ccc3ad27dac0043b2450856b3f
C2 communication:
  • 80.188.120.11 : 4343 (C2)
  • 107.191.101.4 : 443 (SYN only)

 

Vulnerabilities give headaches to security teams. RSA aims to improve the user experience and minimize the time of response to these types of attacks. When publishing the Meltdown / Spectre vulnerability, Microsoft released updates to be installed on all Windows operating systems.

 

However, we have created an Instant Indicator of Compromise (IIOC) to perform validation if the update was installed on each endpoint regardless of the version of the operating system.

 

When the IIOC does not detect this update on the endpoint, it will trigger:

 

 

IIOC configuration:

 

 

For your convenience, you can download this IIOC below. 

Upgrade to RSA NetWitness Version 11 With RSA Professional Services:

There are numerous reasons why organizations are upgrading to RSA NetWitness Suite Version 11.  The majority are interested in the highly intuitive & redesigned user interface, the new product capabilities, the launch of “Respond” and many other usability & serviceability enhancements that come with version 11.  Regardless of what your reason is for upgrading, our RSA NetWitness Professional Services team will ensure you get through your upgrade thoughtfully and successfully while minimizing the amount of time you need to take away from your daily responsibilities.

  

One of the biggest challenges we face in the security industry today is a lack of resources.  If your organization doesn’t have the skillset needed to perform the upgrade independently or if your employees can’t take the time out of their daily obligations to perform the upgrade, I strongly encourage you to engage with RSA Professional Services as your trusted adviser to perform the upgrade for you. 

  

At RSA, we have a global Professional Services team that is certified on the RSA NetWitness product and fully trained on the upgrade to RSA NetWitness v11.  Our battle tested team will ensure you have a successful upgrade and will minimize the amount of time it takes to complete the upgrade to RSA NetWitness 11.

 

Our Professional Services team has several flexible offerings that can be leveraged for upgrading your environment.  From smaller environments to very large and complex global enterprise deployments, we have offerings that will meet your business requirements as well as your preferred procurement method.

  

Key Benefits of working with RSA PS include: 

  • We bring the most real-world field experience: Founded in 1982, RSA has worked with more organizations in more countries for more years than anyone else, and have logged over 100,000 engagements.
  • Our battle-tested teams have tackled the most sophisticated and complex cybersecurity and compliance challenges.
  • We come with the highest level of expertise: Our professionals are trained and certified in the most advanced technologies and methodologies, and are thought-leaders through leading research, conferences, publications, education and training programs.
  • We’ll ensure your upgrade is thoughtfully planned out and executed jointly with our team of experts
  • We’ll help you maximize your ROI by receiving detailed Knowledge Transfer through a series of workshops during the engagement about the new version, how to use the latest features & functionality as well ashow to extract the most value out of the product.
  • We’ll give you the peace of mind knowing you are in the hands of experts who have helped many other organizations like yours successfully navigate the exact same upgrade process and have insights into common risks seen in other environments
  • We’ll give your employees the ability to focus their attention on their day to day duties rather than putting those entirely to the side to perform an upgrade
     

Please contact your local Account Representative for more information about RSA's upgrade services.  We offer a combination of both fixed scope upgrade services as well as upgrade services that can be custom scoped for your specific implementation and business requirements.  If you are unsure who your Account Representative is please contact me directly and I’ll personally help you get in touch with the right person.  You can contact me at Jacob.dorval@rsa.com

 

Upgrading to RSA NetWitness Version 11 Without Professional Services:

For those customers who wish to complete the NW11 upgrade journey without PS Support, you’re still in great hands.  The engineering teams at RSA delivered an incredibly high quality product and documented the entire upgrade process very well.  Please be sure to read and follow the product documentation step by step to ensure you have a successful upgrade.

 

This link is the main RSA NetWitness v11.0 page where you can find the documentation, release notes, upgrade guides, etc.  Beware, there are several unsupported configurations in RSA NetWitness Version 11.  Be sure to familiarize yourself with these configurations prior to executing your upgrade.  This is all well documented in the v11.0 Release Notes.  

 

If you do run into trouble during the upgrade our RSA NetWitness Customer Support team is always standing by to assist.  Simply open up a support case via RSA Linkclicking on “My RSA” up at the top and then clicking on “Create New Case.” 

 

About RSA Global Services:

If you haven’t talked with your Account Representative lately about RSA’s Global Services offerings I would highly recommend doing so.  There are numerous offerings that can help you through your transition.  We offer services for our RSA NetWitness customers from the following teams in Global Services: RSA University, RSA Professional Services, RSA Customer Support and the RSA Risk and Cybersecurity Practice which includes RSA Incident Response and RSA Advanced Cyber Defense.  You'll find that we have many of the services your business needs to be successful and mature your security operations.  

 

To give you a sneak peek, below you will find a high level, 1 slide overview of each practice which shows some of the offerings we provide.  If you’d like to obtain more information or have a conversation about any of these service offerings please feel free to contact your local Account Representative or contact myself directly.  

 

RSA Cybersecurity Experience & Global Services Overview:

 

RSA Professional Services:

 

RSA Advanced Cyber Defense:

 

RSA Incident Response:

 

RSA University:

 

RSA NetWitness Customer Support:

 

Thanks everyone. I hope you are as excited to move to RSA NetWitness v11 as we are.  

 

Thank you,

Jake

 

Jake Dorval | Global Services Product Lead (SPL) – RSA NetWitness® Suite | Global Services| Reston, VA

Mobile: +1 410-960-6988 | jacob.dorval@rsa.com | GMT (-4) Time Zone

RSA® NetWitness® Suite Community: https://community.rsa.com/community/products/netwitness

If you have some custom alert templates that you've been using in NetWitness 10.6.x, you may find that certain expressions no longer work in 11.x, specifically the "@value_of" function we use to iterate through variables that are stored as arrays.

 

For reference, the out-of-the-box string arrays in the Event Stream Analysis are:

 

The statements we use in10.6.x to include these string arrays in our alerts looked like this:

 

CEF:0|RSA|NetWitness ESA|11.0|${statement}|${moduleName}|${severity}|rt=${time?datetime} id=${id} source=${eventSourceId} <#list events as x> sessionid=${x.sessionid!" "} service=${x.service!" "} hostname=<#if x.alias_host?has_content><@value_of x.alias_host /></#if> </#list>

 

To achieve the same functionality in 11.x for string arrays such as alias_host, we need to use a different expression in order to tell the freemarker template to iterate through each value in the array.  We also need the new expression to be able to handle null values, for example if there is no alias_host meta within the alert.

 

<#if x.alias_host?has_content><#list (x.alias_host) as alias_host> hostname=${alias_host!" "} </#list></#if>

 

It is important to take note of the spaces included within this expression, as these ensure each value of "alias.host=www.example.com" is delimited from subsequent "alias.host=" values.  Otherwise, we would end up with this:

 

The template as a whole would look like this:

 

 

CEF:0|RSA|NetWitness ESA|11.0|${statement}|${moduleName}|${severity}|rt=${time?datetime} id=${id} source=${eventSourceId} <#list events as x> sessionid=${x.sessionid!" "} service=${x.service!" "} <#if x.alias_host?has_content><#list (x.alias_host) as alias_host> hostname=${alias_host!" "} </#list></#if> </#list>

 

 

And we can add additional expressions within the template as necessary:

 

CEF:0|RSA|NetWitness ESA|11.0|${statement}|${moduleName}|${severity}|rt=${time?datetime} id=${id} source=${eventSourceId} <#list events as x> sessionid=${x.sessionid!" "} service=${x.service!" "} <#if x.alias_host?has_content><#list (x.alias_host) as alias_host> hostname=${alias_host!" "} </#list></#if> <#if x.action?has_content><#list (x.action) as action> action=${action!" "} </#list></#if> </#list>

Discovered this list of windows Event ID's and their criticality from Microsoft.

Appendix L - Events to Monitor | Microsoft Docs 

With a little Notepad++ magic the table provided was converted to a feed that can be used to mark events by Event ID and add the criticality of that event id to the meta.  

This information can be used in reporting, alerting or ESA calculations to determine if the event and the associated event criticality should be alerted or investigated.

The Table has a Current and Legacy column which were flattened to just one column to match on so that regardless of which Event ID is logged the criticality will be written.

 

#reference.id,legacy_id,criticality,description,,,
4618,n/a,high,a monitored security event pattern has occurred.,,,
4649,n/a,high,a replay attack was detected. may be a harmless false positive due to misconfiguration error.,,,
4719,612,high,system audit policy was changed.,,,
612,n/a,high,system audit policy was changed.,,,
4765,n/a,high,sid history was added to an account.,,,
...

 

 

<?xml version="1.0" encoding="utf-8"?>
<FDF xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="feed-definitions.xsd">
<FlatFileFeed comment="#" separator="," path="feed-msevents-criticality.csv" name="unified">
<MetaCallback name="InspectMeta" valuetype="Text" ignorecase="true">
<Meta name="reference.id"/>
</MetaCallback>
<LanguageKeys>
<LanguageKey name="severity" valuetype="Text"/>
</LanguageKeys>
<Fields>
<Field index="1" type="index" key="InspectMeta"/>
<Field index="3" type="value" key="severity"/>
</Fields>
</FlatFileFeed>
</FDF>

 

Using the data in a Dashboard can illustrate the groupings of high, medium and low severity events.

 

Malspam was observed on January 12th 2018 delivering Ursnif (AKA Gozi). Ursnif is a Banking Trojan that was discovered in 2007. Originally it was targeting banking wire systems in English speaking countries. In the past decade, its list of target countries expanded and its capabilities evolved. In addition to stealing banking credentials, Ursnif can now collect user credentials for local webmail, cloud storage, cryptocurrency exchange platforms and e-commerce sites [1]. 

 

In October 2017, security researchers took notice of a new Ursnif spam campaign [2]. The actors behind this campaign developed their macros to run when the document is closed. Sandbox technologies might miss this behavior and it could prove to be a simple yet effective evasion technique.

 

Let's take this delivery document as an example. Submitting it to RSA pre-release What's This File service shows the embedded VBA code including its AutoClose function:

 

 

 

 

On NetWitness Packets, first there is a DNS request to what looks like a DGA delivery domain. Notice the large number of answers in the DNS response:

 

 

Next, an HTTP GET request to retrieve a script from the domain:

 

 

 

Here is a better look at the downloaded script:

 

 

The script reaches out to the same domain in order to download an executable. Notice the usage of PFX file extension and the absence of many headers in the HTTP GET request:

 

 

 

 

VirusTotal scan results indicate that the binary is an Ursnif variant.

 

Once the download is complete and the malware is executed, it checks in with the same domain:

 

 

 

Here is a recap of the network activity:

 

 

More information about the recent Ursnif variants can be found in this Malware Breakdown blog post.

 

Delivery document (SHA256):

  • a0a946868e2a067fc2144f19faa161b586c85fe57413633525e8e8bd5e2f48d6

 

Ursnif binary (SHA256):

  • eee6bd38c0e6498fadc466d5a1b635271b63c4235a3b271a9e15d5896c5a045a

 

All the IOC from those HTTP sessions were added to RSA FirstWatch Command and Control Domains on Live with the following meta:

  • threat.source = ‘rsa-firstwatch’
  • threat.category = ‘malspam’
  • threat.description = ‘delivery-domain’

 

References:

  1. https://threatpost.com/ursnif-banking-trojan-spreading-in-japan/128643/ 
  2. https://blog.trendmicro.com/trendlabs-security-intelligence/new-malicious-macro-evasion-tactics-exposed-ursnif-spam-mail… 

During the last several weeks of 2017 and now well into early 2018, RSA FirstWatch has observed a malspam campaign delivering njRAT, a robust and publicly available remote administration tool (RAT) with capabilities for remote desktop, file manager, remote camera, remote keylogger, DOS attack, and run file (from link, disk, or script).

  

One such event occurred on January 10, 2018, with likely targeted malspam delivery of a malicious MS Word document, 'Pro Forma Invoice.doc'.

 

 

As we can see by RSA's pre-release Whatsthisfile.net capability, some highly suspicious VBA code is embedded in the delivery document.

 

 

This VBA code effectively calls powershell to retrieve a njRAT payload from an open directory on eagleepcisocks[.]com, hosted on 162.144.63[.]238.

  

 

It's worth noting that a very similar powershell drop method has been recently been observed for Agent Tesla deliveries as reported by malwarebreakdown.com.

 

Network activity for the njRAT payload delivery is below.

 

 

 

 

You can also see the whole thing happen live on app.any.run here.  

  

Post-infection, we immediately begin to see indications of active Command and Control (C2) out to 212.83.167[.]116, which appears to be a somewhat unsavory machine.

 

 

This activity is detected by NetWitness Packets and flagged with the following meta data.

 

 

Thanks to Ahmed Sonbol, @Zerophage1337@James_inthe_box for their assistance with this research.

 

 

Interesting question from an internal resource about how to parse CSV files that contain information pulled from Cisco Umbrella S3 Buckets to a local filestore and how to get them into RSA NetWitness Logs.  As a learning process I have documented the steps that were used to get this working, hopefully you find it useful. 

Thanks to Dave Glover for the help with the parser framework and Nir Oz for the original question.

 

At high level we will assume that the logs are pulled down by an external script to a location that either has the SFTP agent installed or can be placed in the correct directory on the log collector for the parsing pipeline to take over in NetWitness.

 

Review the typespec framework as we will create a new one for the file collection method.

https://community.rsa.com/docs/DOC-54570

 

Create the typespec file for file collection

 

<?xml version="1.0" encoding="UTF-8"?>
<typespec>
 
   <name>cisco_umbrella</name>
   <type>file</type>
   <prettyName>cisco_umbrella</prettyName>
   <version>1.0</version>
   <author>eric_partington</author>
   <description>FileCollection specification for eventsource type "Cisco Umbrella" using file handler type "cisco_umbrella"</description>
 
        <device>
                <name>cisco_umbrella</name>
                <parser>cisco_umbrella</parser>
        </device>
 
        <configuration>
        </configuration>
 
        <collection>
                <file>
                <parserId>file.cisco_umbrella</parserId>
                <processorType>generic</processorType>
                <dataStartLine>1</dataStartLine>
                        <fieldDelim>,</fieldDelim>
                        <idField></idField>
                        <lineDelim>\n</lineDelim>
                        <transformPrefixTag>cisco_umbrella_logs</transformPrefixTag>
                        <transformReplaceFieldDelim>0</transformReplaceFieldDelim>
                        <transformPrefixFilename>0</transformPrefixFilename>
                        <transformMultipleDelimiterAsOne>0</transformMultipleDelimiterAsOne>
                        <transformReplacementFieldDelim></transformReplacementFieldDelim>
                </file>
        </collection>
</typespec>

 

Upload the typespec file to the log collector

/etc/netwitness/ng/logcollection/content/collection/file

set the name as cisco_umbrella.xml

make sure permissions are set right (same as the other files in the directory)

 

Restart the log collector service

 

Create Event Source

In the log collector UI Set up collection

Log collector > Config > Event Sources > File > New Event Category

call it cisco_umbrella

Create a new source

File Directory is cisco_umbrella (this is the directory inside the uploads directory where files will be placed for this collection)

Address - this set the device.ip of this collection so set it to the IP of the cloud system potentially so you have a good record in device.ip of where logs 'came from' originally

 

Review filesystem for uploads directory created for this collection

/var/netwitness/logcollector/upload/

 

Start file collection mechanism on log collector

 

Upload test file

review that the collection mechanism works

place the csv in this directory for collection to take place

/var/netwitness/logcollector/upload/cisco_umbrella/cisco_umbrella

 

Review Logs

Jan  8 20:53:49 nw11ldecoder NwLogCollector[62493]: [FileCollection] [info] [file:WrkGrp[1]:64008] [getWork:651] [cisco_umbrella.cisco_umbrella] [idle] Work Unit Given to Work Manager: /var/netwitness/logcollector/upload/cisco_umbrella/cisco_umbrella/work/2017-12-13-00-10-dcd8.csv

Jan  8 20:53:49 nw11ldecoder NwLogCollector[62493]: [FileCollection] [info] [file:WrkUnit[2]:64010] [postWork:1073] [cisco_umbrella.cisco_umbrella] [processing] [generic:2017-12-13-00-10-dcd8.csv] [processing success] File processed successfully: /var/netwitness/logcollector/upload/cisco_umbrella/cisco_umbrella/work/2017-12-13-00-10-dcd8.csv

Jan  8 20:53:49 nw11ldecoder NwLogCollector[62493]: [FileCollection] [info] [file:WrkUnit[2]:64010] [postWork:1104] [cisco_umbrella.cisco_umbrella] [processing] [generic:2017-12-13-00-10-dcd8.csv] [processing success] File deleted: /var/netwitness/logcollector/upload/cisco_umbrella/cisco_umbrella/work/2017-12-13-00-10-dcd8.csv

 

View investigator

 

Default Parsing with no parser

 

New features added in NW11.0 are now included in the log decoders which are the lua parsers below...these help in the best effort parsing of messages to try to locate useful information from logs and parse them out.

 

 

With no parser created pulls out some information from these logs by default (new feature in NW11.0)

ip.addr, alias.host, filename, sld and tld.

 

 

Create Log Parser

Category for the logs will be Web Logs

Define the header with the LPT1.0 tool (or notepad++)

this is the raw log data as the decoder sees it

%cisco_umbrella-4: "2017-12-13 00:08:01","DC

 

Define the additional fields to parse out according to the columns in the CSV and the need for the data.

 

<?xml version="1.0" encoding="UTF-8"?>
<DEVICEMESSAGES
                 name="cisco_umbrella"
                 displayname="Cisco Umbrella:custom"
                 group="Web Logs"
                 type="7104">
<VERSION
                 xml="1"
                 revision="1"
                 device="2.0"/>
<TAGVALMAP/>
<HEADER
                 id1="HDR1"
                 id2="HDR1"
                 content="%cisco_umbrella_&lt;messageid&gt;-4:&lt;!payload&gt;"/>

<MESSAGE
                 id1="logs"
                 id2="logs"         
     eventcategory="1612000000"                content="&quot;&lt;event_time_string&gt;&quot;,&quot;&lt;rulename&gt;&quot;,&quot;&lt;saddr&gt;&quot;,&quot;&lt;stransaddr&gt;&quot;,&quot;&lt;daddr&gt;&quot;,&quot;&lt;content_type&gt;&quot;,&quot;&lt;action&gt;&quot;,&quot;&lt;url&gt;&quot;,&quot;&lt;web_referer&gt;&quot;,&quot;&lt;user_agent&gt;&quot;,&quot;&lt;resultcode&gt;&quot;,&quot;&lt;fld1&gt;&quot;,&quot;&lt;fld2&gt;&quot;,&quot;&lt;fld3&gt;&quot;,&quot;&lt;uid&gt;&quot;,&quot;&lt;fld4&gt;&quot;,&quot;&lt;fld5&gt;&quot;,&quot;&lt;fld6&gt;&quot;,&quot;&lt;fld7&gt;&quot;,&quot;&lt;fld8&gt;&quot;,&quot;&lt;fld9&gt;&quot;,&quot;&lt;group&gt;&quot;"/>
</DEVICEMESSAGES>

 

Verified in the LPT1.0 tool

 

save the file as cisco_umbrellamsg.xml

create the cisco_umbrella.ini for his device as well

 

DatabaseName=cisco_umbrella
DisplayName=cisco_umbrella
DeviceGroup=Web Logs
DeviceType=7104

 

save it in this directory structure for easy upload to the log decoder

/etc/devices/cisco_umbrella/

place the xml and ini in this directory

 

zip archive the structure and rename the etc.zip as cisco_umbrella.envision

 

Upload the parser

Log Decoder > Config > Parsers

upload

check the filesystem to make sure the permissions are set right on the folder and files (same as the other files in the directory structure

/etc/netwitness/ng/envision/etc/devices/cisco_umbrella/

 

Reload the Parsers

Log Decoder > Explore menu

Decoder > Parsers - right click - select properties

reload - submit

Review the logs to ensure the parser was loaded with no errors

Cat /var/log/messages | grep –i cisco_umbrella

Should show up in the log decoder parsers list when enabled correctly

 

Upload new file to test collection and new parsing

place in same folder location as before

 

Review Parsing

 

parsing looks good!

review the data that was parsed and what is visible on the decoder/concentrator ( keys like referer and url may not be indexed by default depending on what other customizations have been done those may need to be added to table-map.-custom.xml and index-concentrator-custom.xml)

Malspam activity was observed on January 7th 2018 delivering a new variant of BITTER Remote Access Tool (RAT), which has been previously reported by Forcepoint in nation-state campaigns against Pakistani targets.  In this blog post, FirstWatch discusses observed malicious activity from the perspective of the RSA NetWitness suite.

 

The delivery document (NamesOfMaldiviansReturning-1.doc) tries to exploit CVE-2017-11882 in order to deliver the BITTER RAT to a victim machine.  CVE-2017-11882 is a vulnerability in Microsoft Office suite that was disclosed in November 2017 and has an available patch for affected products.  You can read more about this vulnerability in a past  FirstWatch threat advisory.

 

Upon opening the malicious document with an un-patched Microsoft Word application, a HTTP GET request was observed downloading an executable file from delivery domains, hartraders[.]com, which is hosted on a Namecheap server at 104.219.248[.]10.

 

 

 

VirusTotal scan results and a Hybrid-Analysis report of the payload, 'wp-sig.exe', are available, but also observe below the suspicious scoring of this file as evaluated during execution by NetWitness Endpoint (NWE).  

 

  

Upon execution, the malware also spawns a second process, 'ctfmers.exe', which is responsible for checking in with a C2 server.  This process is also flagged as potentially malicious by NWE.

 

 

 

  

Similar network behavior was previously observed in a November 2017 BITTER campaign with the execution of another delivery document (yyyyyyy.doc).  While, the malspam document from this earlier campaign was crafted to exploit the older CVE-2012-0158, the maldoc attempted to download its payload from zmwardrobe[.]com, which is actually hosted on the same Namecheap server as the current campaign, 104.219.248[.]10.

  

 

The payload from the November 2017 campaign was an earlier BITTER variant, 'ctf.exe' as shown below.

  

 

Post infection, we also observed similar C2 callbacks from this earlier BITTER variant.

 

 

That's not the only C2 similarity across historical BITTER campaigns though, the new variant's C2 communication also shares characteristics with much older variants.  For example, the following screenshot shows the C2 check-in for a binary first submitted to VirusTotal in January 2016:

 

 

More information about older BITTER variants can be found in this blog post from RSA FirstWatch.

 

Delivery documents (SHA256):

  • 9292764ce4a84b29f2ca4598def80239dfd079451c113a45f2569d9ea220fac3
  • d128bdcedecee0fbc8ec440a3edd3fe624cfd9a6c0ed298fe7c26f0c86f21618

 

BITTER binaries (SHA256):

  • ffe1528eea078bde8336ab96a574a5401ff2c0403bbefda96a34e5cce4ae6385
  • 131c53a3612c933e747897573a5f79db9f61895b404f69efea8c1c87262da4fe

 

All the IOC from those HTTP sessions were added to RSA FirstWatch APT Threat Domains on Live with the following meta:

  • threat.source = ‘rsa-firstwatch’
  • threat.category = ‘apt’
  • threat.description = ‘bitter'

 

Thanks go to Kent Backman and Kevin Stear for contributing to this threat advisory.

 

References:

  1. BITTER: A Targeted Attack Against Pakistan | Forcepoint 

 

Malspam activity was observed on January 8th 2018 delivering FormBook malware. FormBook is a data stealer and form grabber available on various hacking forums since early 2016. Its capabilities include clipboard monitoring, keyboard logging, taking screenshots, grabbing form data and collecting passwords from browsers and email clients. More information about the malware can be found in this blog post by FireEye security researchers.

 

The delivery document Tax Reform.doc uses macros to help delivering the payload to a victim machine.

 

 

The following screenshots show the results of scanning the document using RSA pre-release What's This File service including signs of an auto launch script.

 

 

 

Upon enabling the macro, the code runs and a binary is downloaded to the victim machine. Notice the absence of typical fields in the HTTP GET request and the usage of a unique User-Agent string.

 

 

 

 

 

VirusTotal scan results can be found here. Analysis report from hybrid-analysis.com suggests it is a FormBook variant.

 

Upon execution of the binary, it checks in with a list of C2 servers. 

 

 

 

 

After checking in, the malware posts data to the server in an encoded/encrypted format.

 

 

 

Delivery document Tax Reform.doc (SHA256):

  • 9441d7811e869d50e7c340c622a57c14004682573ff6d5d43fca4d0be6aca102

 

FormBook binary bin.exe (SHA256):

  • 391971ca3923a45997633275249dcd5bedf2b11f165646671e4359afa3fec4b4

 

Highlighting some of the new features available in NW11 (NetWitness 11.0).

HTTP Lua Parser Options 

 

Http_lua options file was introduced a while ago to provide a means to customize some of the lua parser functions using an options file to set the required status.  This functionality has been used to enable some advanced features on the http_lua parser in NW11.0+

 

Some of the new features to be aware of:

  • registerURL
  • splitQuery
  • useOrigIP
  • refererPath
  • userAgent
  • respReason
  • decompress
  • advanced

The most interesting are the decompress and refererPath options.  Some are set on/true by default, others are not. 

 

Notes:

You should not subscribe to the Options files as updates from RSA will wipe out your changes in that file.

You should deploy only from RSA Live (not subscribe and deploy)

 

Check periodically for new updates to the Options Files and deploy new ones when ready and have reviewed any changes

NW11 > Configure > RSA Live > Search for options files > Click Description > Download > Open *.zip > review content

This was an idea originally spawned by Sean Ennis so I have to give kudos to him for coming up with the original data set and link to the source data ...

 

NetWitness with the TLS parser (or any other parser that might write values into the crypto metakey) writes the crypto/cipher suites that are detected into this metakey, which makes it really easy to match up against a list of known good or bad suites to provide alerting or reporting on what is seen in the events.

 

So where to find a good, trusted source for weak cipher suites?

 

How's My SSL? 

 

This site is a great reference to check your own browser cipher suites and provide a report card on what is presented and if legacy or weak suites are presented (potential downgrade attacks).

 

If you hop over to the GitHub page for this site you can locate this file which lists the weak cipher suites that can be used in a feed to match against what is see on the wire and provide additional alerting or reporting on what is detected.

 

howsmyssl/insecure_suites.go at master · jmhodges/howsmyssl · GitHub 

 

With a little work in Notepad++ you can get a file as included in this post and create a matching xml file for feed deployment.  Then deploy to your decoders (packet and log) and now you have the ability to create matching meta (in this case the xml points to

analysis.service = 'insecure_cipher_suites'

 

and more detailed reason of why in threat.desc

threat.desc='sweet32ciphersuites:uses 3des which is vulnerable to the swe...'

 

in this case matching this suite

tls_rsa_with_3des_ede_cbc_sha

 

The additional meta as well as direction or specific applications or workstation subnets can form the basis of additional alerts/meta or rules that can end up in IM/Respond for Triaging.  Can also be an Ops report to provide locations where weak suites are being used (maybe a legacy internal app is requesting them or legacy browsers on unmanaged devices)

 

which can also be used in  addition to the other serivce analysis keys to look for addities in the properties of TLS traffic that might give you further reason to look at the source or destination of the traffic.

 

Filter Blog

By date: By tag: