Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Ahmed Sonbol
1 2 3 Previous Next

RSA NetWitness Platform

43 Posts authored by: Ahmed Sonbol Employee

Dridex is a banking Trojan that steals a victim’s credentials in order to commit fraudulent financial transactions. In May, RSA FirstWatch published a threat advisory discussing a Dridex variant that spread through well-crafted Word documents targeting exploit CVE-2017-0199 [1].

 

In this blog we will take a look at another Dridex delivery mechanism, Word documents with macros. We will discuss how to leverage the Hunting pack to detect its network behavior using RSA NetWitness Packets and Logs. In addition, the threat advisory will shed some light on the suspicious host behavior detected by RSA NetWitness Endpoint.

 

Let’s take this delivery document as an example [2], the attacker tries to trick the victim into running the malicious macro:

 

 

When the macro runs, it launches a powershell script to download the malware from its delivery domain and saves it to the user %TEMP% directory. Once the download is complete, a new process is created which injects code into a system process then deletes itself. Here is the process tree after running the delivery document:

 

 

Similar information can be found by running the same delivery document on another machine with a NetWitness Endpoint agent installed on it:

 

Here is a screenshot of a download session in NetWitness Packets and Logs:

 

 

Using the “View Files” option for this session shows the checksum and size of the downloaded executable:

 

 

NetWitness Endpoint gives us even more information about the PE file including its static characteristics, its location on the infected machine before it was deleted.

 

 

Looking up the file hash on VirusTotal suggests it is a Dridex variant [3].

 

Finally, NetWitness Endpoint shows the injected code into spoolsv.exe:


 

The malicious host behavior is captured by the machine IIOC’s. Some of them are displayed below:

 

 

Detection using Hunting pack:

 

The Hunting pack is designed to allow you to quickly hunt for indicators of compromise or anomalous network activity by dissecting packet traffic within the NetWitness Suite and populating specific meta keys with natural language values for investigation. For more information on the hunting pack including how to deploy it in your environment, please refer to RSA documentation [4].

 

Given the network artifacts we know so far, let’s run a query to narrow down the results in NetWitness Packets and Logs:

analysis.session = 'first carve' && analysis.session = 'first carve not dns' && service = 80 && action = 'get' && filename = 'styles.bin' && client !exists

 

The first two conditions in the query analysis.session = 'first carve' && analysis.session = 'first carve not dns’ help in focusing the investigation on non-DNS, outbound sessions that have two streams and payload greater than zero. Please keep in mind that the packet decoder in this case is used to monitor the network traffic of a relatively small environment in RSA FirstWatch lab, results in a real environment might vary and the query might need further tweaking.

 

 

The Hunting pack tags the download sessions with more meta values indicating a highly suspicious network behavior. Let’s try to understand what some of those values mean:

  • http two headers: In a typical user browsing session, the fields in HTTP headers are populated by the browser. Thus having only two fields in the header is not normal. Among the missing fields is the User-Agent string itself indicated here by the meta value http no user-agent
  • http direct to ip request: It is uncommon for a regular user to use an IP address instead of a domain name while browsing.
  • watchlist file extension: Extensions that are commonly used with malware were detected in the session. In this case the filename extension .bin
  • watchlist file fingerprint: File formats that are commonly used in malware. In this case a PE file fingerprint.
  • exe file type but no exe extension: Sessions where EXE files are downloaded warrant further investigation to check if the activity is legitimate or not. In this case, not only an executable is being downloaded but also has a misleading extension.

For an explanation of the rest of the meta values generated in those sessions, please refer to RSA documentation [4].

 

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

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

If you are interested in more Hunting pack use cases, please check this community post on RedLeaves malware and this one on delivery documents.

 

Thanks to Christopher Ahearn for helping with this threat advisory.

 

References:

  1. Bank on it with the Dridex Trojan 
  2. Antivirus scan for f13b2b7b53bc7c1ca3ca4fa5181f2283edc6820710d8412952447b58e3c3d257 at2017-06-05 01:30:25 UTC - VirusTot… 
  3. Antivirus scan for 2b4cf6aec98d90cca1d7f8607ee16001fa928b8cc5af5624625a284619391d29 at2017-06-07 16:20:26 UTC - VirusTot… 
  4. RSA NetWitness Hunting Guide 

For the past few weeks a new malspam campaign has been observed delivering different kinds of malware via email messages. The malspam uses PDF attachments with embedded Word documents [1]. The Word documents themselves include malicious macros. Adobe Reader and Microsoft Word have built-in mechanisms to automatically prevent the attachments from dropping their payload. However, an attacker can easily lure a victim into bypassing those mechanisms. Once the malicious macro runs, it connects to a delivery domain in order to download the final payload. Examples of delivered malware include Locky ransomware [2], Jaff ransomware [3] and Dridex banking Trojan [4][5].

 

This threat advisory sheds some light on the delivery documents. It also discusses how to leverage the Hunting pack to detect their network behavior using NetWitness Logs and Packets.

 

Let’s take this delivery document as an example [6]. The usage of embedded Word documents in PDF attachments requires more user interaction providing the attacker an extra layer of sandbox evasion.

 

Upon opening the PDF attachment, Adobe Reader alerts the user that it may have content that can harm her computer:

 

 

If the user chooses to open the PDF attachment, a document will be extracted and launched in Microsoft Word if it is installed on the computer. Microsoft Word displays a warning that the document is opened in protected view:

 

 

If the user follows the instructions to enable content for this document, the embedded malicious code will execute and tries to connect to a delivery domain:

 

 

The infected machine receives an obfuscated payload in response:

 

 

The final step is to de-obfuscate the payload and to start the malware in a new process, in this case a Jaff ransomware variant [7]. This is the process tree from hybrid-analysis.com:

 

 

Detection using Hunting pack

 

The Hunting pack is designed to allow you to quickly hunt for indicators of compromise or anomalous network activity by dissecting packet traffic within the NetWitness Suite and populating specific meta keys with natural language values for investigation. For more information on the hunting pack including how to deploy it in your environment, please refer to RSA documentation [8].

 

The screenshot below shows that the network behavior is shared among multiple delivery documents:

 

 

Below are some of the meta values registered by the Hunting pack for those sessions:

 

 

Here is a description of some of those meta values:

Meta ValueDescription
http not good mozilla

A User-Agent without the Mozilla identifier

http no referer

HTTP sessions with no referrer

http mid length user-agent

User-agent header length between 56 and 74 characters

http get no post

Sessions with only HTTP GET Methods

http six or less headers

Six or less HTTP headers in a session

tld not net com org

Less Common Top Level Domains

not top 20 dstorg.dst is not one of the most common 20 destinations

 

Let’s compare the network behavior we have seen so far to a normal browsing activity to try to understand why the Hunting pack is tagging those sessions with the meta values described above. The screenshot below shows an HTTP GET request to CNN website using a Mozilla Firefox browser on an Ubuntu machine:

 

 

Some differences to note here are:

  • Unlike the fake user-agent string used by the malicious macro, the one above is typical of human-operated web browsers [9]. Malware authors can simply forge this field but anomalies can be easily spotted and might indicate malicious behavior.
  • The existence of more HTTP headers in this request, malware authors usually tend to ignore those headers in their code when they call the functions to connect to their delivery or C2 domains.
  • A referrer field that indicate the origin of the request. Although not present in every HTTP request but anomalies especially in a large number of sessions might indicate a mechanical behavior.
  • The Top-level domain is one of .com, .net or .org. Of course that doesn’t guarantee that the domain is a legitimate one but attackers tend to use other TLD in their operations and in particular the generic top-level domain [10]. It is important to understand what are the normal and most frequently visited TLD based on your environment, your business and geographic location.

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

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

 

If you are interested in another Hunting pack use case, check this community post on RedLeaves malware.

 

References:

  1. Malicious Documents: The Matryoshka Edition | Didier Stevens 
  2. Malware-Traffic-Analysis.net - 2017-04-21 - Dridex-style malspam pushes Locky ransomware instead 
  3. Malware-Traffic-Analysis.net - 2017-05-11 - Jumping on the Jaff ransomware bandwagon 
  4. Malware-Traffic-Analysis.net - 2017-04-19 - Dridex malspam with PDF attachments containing embedded Word docs 
  5. Bank on it with the Dridex Trojan 
  6. Antivirus scan for ff66670b0ab937f33842c0977c2396d25933a8da7e4fa1931e0a9055dfeac9e5 at2017-05-16 03:08:01 UTC - VirusTot… 
  7. Antivirus scan for 03363f9f6938f430a58f3f417829aa3e98875703eb4c2ae12feccc07fff6ba47 at2017-05-17 16:27:35 UTC - VirusTot… 
  8. RSA NetWitness Hunting Guide 
  9. User agent - Wikipedia 
  10. List of Internet top-level domains - Wikipedia 

On April 27, 2017 The United States Computer Emergency Readiness Team (US-CERT) released an alert TA17-117A [1] with information on an emerging sophisticated campaign. The campaign has been active since at least May 2016 and targets organization in several sectors, including Information Technology, Energy, Healthcare and Public Health, Communications and Critical Manufacturing. The threat actors have deployed multiple malware families and variants in their campaign including PlugX and RedLeaves.

 

This threat advisory discusses the host and network behavior of RedLeaves malware. In addition, it shows how to leverage the Hunting pack to detect RedLeaves network activity using RSA NetWitness Logs and Packets.

 

A typical infection scenario starts with a dropper dropping a legitimate application (EXE), a malicious DLL, and an encoded DATA file in the user %TMP% folder [2].

 

The screenshot below shows the files dropped by a RedLeaves sample on a victim machine [3]:

 

 

 

FilenameSHA256
obedience.exe aba4df64717462c61801d737c9fa20a7fada61539eaef50954331d31f7306d27
StarBurn.dll adb72a24429441f743bd2b1a9c0116ae9a1e7b217e047849d70ca1e9054dbdb6
handkerchief.dat 773b176b3a68c3d21fae907af8fba7908b55726bd591c5335c8c0bc9de179b76

 

It then starts the application. Taking advantage of DLL preloading, the EXE file loads the malicious DLL, which reads, decodes, and then executes the DATA file. It then creates a new process and injects itself into it. Below is a snapshot of the process tree after running the same sample on hybrid-analysis.com [4]:

 

 

To ensure that one instance of the malware is running on an infected system, the malware creates a mutant. In this case, it is vv11287GD. To gain persistency on the system, the malware creates a link in the Startup folder pointing to the legitimate application dropped in the %TEMP% folder.

 

The malware starts beaconing to its C2 server using raw TCP over port 443 as follows:

 

 

As explained in the alert issued by US-CERT, the payload follows two 12-bytes fixed length headers. The first header comes in its own packet, the second header and the payload in a separate packet in the same TCP stream. The first four bytes of the second header (0x3275636b) represent the length of the encrypted and compressed payload (XOR encoded with the first four bytes of the RC4 key), the second four bytes of the second header (0x3175636b) represent the length of the decrypted and decompressed payload (XOR encoded with the first four bytes of the RC4 key).

 

Analyzing the strings in the address space of the injected process; in this case iexplore.exe; suggests that the RC4 key is Lucky123 with null byte appended:

 

 

Here is the decrypted payload:

 

 

The malware also sends the same payload along with the second header to the server as an HTTP POST request over port 443:

 

 

A list of commands supported by RedLeaves can be found in the report released by the NCC Group Cyber Defence Operations team [5].

 

Detection using Hunting Pack

 

The Hunting pack is designed to allow you to quickly hunt for indicators of compromise or anomalous network activity by dissecting packet traffic within the NetWitness Suite and populating specific meta keys with natural language values for investigation. For more information on the hunting pack including how to deploy it in your environment, please refer to RSA documentation [6].

 

The screenshot below shows some of the meta keys registered by the hunting pack for the initial RedLeaves beaconing session. That is the one using a raw TCP connection over port 443:

 

 

The session was tagged with different meta values indicating suspicious traffic over SSL port. Here is a description of some of those values:

Meta ValueDescription
session size 0-5k

A total session size, request + response payload, between 0KB and 5KB

ratio high transmitted

Between 75% and 100% of the session payload transmitted outbound

potential beacon

Session assumed to be programmatic, nefarious communications

not top 20 dst

org.dst is not one of the most common 20 destinations

first carve

outbound traffic with two streams and payload > 0

first carve not dns   outbound traffic with two streams and payload > 0 and not service type 53

 

The screenshot below shows some of the meta keys registered by the hunting pack for the following RedLeaves beaconing sessions. Those are the ones that use HTTP POST requests over port 443:

 

 

The sessions were tagged with different meta values indicating suspicious HTTP traffic over SSL port. Here is a description of some of those values:

Meta ValueDescription
watchlist file extension

Any executable extension commonly used with malware like .exe, .php, .zip, etc

http with binary

HTTP with binary data in the body

http suspicious 4 headers

Sessions with only HTTP POST and four HTTP headers

host-header contains port

Host header directly declares a port such as 'www.example.com:80'

http post no get low header count not flash

An HTTP POST request with less than 6 Headers and the user-agent is not ‘shockwave flash’

http post no get no referrer directtoip

HTTP session with at least one POST request to an IP address, no GET requests, and no referer

 

While the network behavior explained earlier is not unique to RedLeaves malware, the hunting pack can help an analyst in identifying suspicious traffic in the environment without relying on any network signatures.

 

References:

  1. https://www.us-cert.gov/ncas/alerts/TA17-117A
  2. http://blog.jpcert.or.jp/2017/04/redleaves---malware-based-on-open-source-rat.html
  3. https://www.virustotal.com/en/file/5262cb9791df50fafcb2fbd5f93226050b51efe400c2924eecba97b7ce437481/analysis/
  4. https://www.hybrid-analysis.com/sample/5262cb9791df50fafcb2fbd5f93226050b51efe400c2924eecba97b7ce437481?environmentId=100
  5. https://github.com/nccgroup/Cyber-Defence/blob/master/Technical%20Notes/Red%20Leaves/Source/Red%20Leaves%20technical%20note%20v1.0.md
  6. https://community.rsa.com/docs/DOC-62341

Lotus Blossom is an adversary group that targets military and government organizations in Southeast Asia [1]. Emissary is one of the malware tools used by the group. The oldest Emissary sample was found in 2009 and the malware family has evolved over time [2]. It is usually delivered through well-crafted documents that exploit unpatched vulnerabilities in Microsoft Office.

 

This threat advisory discusses the host behavior of one of Emissary variants and how to detect its beaconing activity using RSA NetWitness Logs and Packets.

 

A dropper loads this Emissary variant from its resources section and writes it to the disk but it doesn’t stop there. It keeps inflating the newly created file by adding junk data to it. The size of the newly created file exceeds 500 MB. In the same directory, it drops a copy of itself and an obfuscated configuration file. Analysis indicates that the configuration file has a unique victim ID and a list of C2 servers.

 

 

The dropper proceeds to inject Emissary into the address space of a new Internet Explorer process:

 

 

Emissary keeps a log of its activity in clear text:

 

 

Emissary collects system information and starts communicating with its primary C2 server as follows:

 

 

In the screenshot above, the Cookie field has both the victim machine unique ID as well as its IP address.

 

An update to the HTTP Lua parser is now available on Live to detect Emissary network activity:

 

 

When it detects Emissary traffic, it registers meta to the “Indicators of Compromise” key:

 

 

Emissary sample can be found on VirusTotal here, and a delivery document can be found here.

 

All the IOC from those HTTP sessions were added to the following RSA FirstWatch Live feeds:

  • RSA FirstWatch APT Threat Domains
  • RSA FirstWatch APT Threat IPs

If threat.desc meta key is enabled then you can use the following query:

            threat.desc = ‘apt-emissary-c2’

 

Thanks go to Bill Motley for contributing to this threat advisory.

 

References:

  1. http://researchcenter.paloaltonetworks.com/2015/06/operation-lotus-blossom/ 
  2. http://researchcenter.paloaltonetworks.com/2016/02/emissary-trojan-changelog-did-operation-lotus-blossom-cause-it-to-evo… 

Ursnif, also known as Gozi and ISFB, is a banking Trojan that primarily targets English-speaking countries. It was first discovered in 2007 and in 2010 its source code was unintentionally leaked [1]; which provided the basis for much of the legacy Ursnif variant diagnosis and detection. Dreambot is a newer variant (ca 2016) of Ursnif that incorporates capabilities such as Tor communications and peer-to-peer functionality [2].

 

Dreambot malware has been observed to spread via many of the conventional crimeware avenues to include exploit kits, e-mail attachments and links [2] [3]. To evade automated malware analysis, Dreambot uses password protected macro attachments and also delays for 250 seconds prior to downloading the malware [4].

 

This threat advisory discusses how to detect Dreambot beaconing activity using RSA NetWitness Logs & Packets.

 

A system infected with Dreambot reaches out to its command and control server as follows:

 

 

The behavior is consistent across many Dreambot samples:

 

 

Then a Tor client is retrieved:

 

 

 

The check-in is different for other Dreambot variants:

 

 

 

Assuming that the appropriate meta keys are enabled, the following queries can be used to detect Dreambot network activity:

  • Detect the check-in activity you can use:

    action = 'get' && filename = '.avi' && extension = 'avi' && directory contains '/images/' && direction = 'outbound'

    action = 'post' && directory begins '/images/' && query begins 'filename=' && extension = 'bin' && direction='outbound'

  • Detect the Tor client retrieval you can use:

    action = 'get' && filename = 'test32.dll',' t32.dll', ' t64.dll' && extension = 'dll' && directory contains '/tor/' && direction = 'outbound'

 

Dreambot samples can be found on VirusTotal here and here, and on Payload Security here and here.

 

All the IOCs from those sessions were added to the following feeds on Live:

  • RSA FirstWatch Command and Control Domains
  • RSA FirstWatch Command and Control IPs

To find those IOCs using RSA NetWitness, please refer to this post.

 

In addition, the following Application Rule is now available on Live:


 

 

Below is a screenshot of the Application Rule detecting Dreambot traffic:

 

 

 

Thanks go to Rajas Save for contributing to this threat advisory.

 

References:

  1. https://securityintelligence.com/gozi-goes-to-bulgaria-is-cybercrime-heading-to-less-chartered-territory/#.VdQEtfnddi8
  2. https://www.proofpoint.com/us/threat-insight/post/ursnif-variant-dreambot-adds-tor-functionality
  3. RIG EK at 92.53.127.21 Drops Dreambot – MALWARE BREAKDOWN 
  4. New Password Protected Macro Malware evades Sandbox and Infects the victims with Ursnif Malware !! - Cysinfo 

Ismdoor is a remote access Trojan used by the Greenbug cyberespionage group against different organizations in the Middle East. In addition to collecting data from an infected system, it has the ability to download and install binaries. In this blog post, we will shed some light on its network activity and show how to detect it using RSA NetWitness.

 

After infecting a system, the malware reaches out to its C2 server as follows:

 

 

Some Ismdoor binaries use a different filename to check the connection with the server:

 

 

If the response from the server is ‘Ok’, the malware knows that it can start receiving commands from the server so it sends another POST request:

 

 

In this case Ismdoor will execute the systeminfo command on the infected system to collect its information. It saves the command output to a temp file ‘test.txt’ in C:\Users\<user>\AppData\Local\Microsoft\Windows\TmpFiles. The content of the text file is obfuscated, saved to another temp file in the same directory. The obfuscated data is submitted to the server and both files are deleted.

 

 

The URL is not the same across Ismdoor variants:

 

 

Based on those network artifacts and assuming that the appropriate meta keys are enabled, two different queries can be used to detect Ismdoor network activity:

 

  • First to detect the check-in you can use:

    service = 80 && action = 'post' && referer !exists && directory = '//home/' && client = 'winhttpclient'

  • Second to detect the C2 activity you can use:

    service = 80 && action = 'post' && referer !exists && query begins 'commandid=cmdresult='

 

For more information on Greenbug, please check Symantec blog here. Scan results for Ismdoor variants can be found here and here.

 

All the IOC from those HTTP sessions were added to the following RSA FirstWatch Live feeds:

  • RSA FirstWatch APT Threat Domains
  • RSA FirstWatch APT Threat IPs

If threat.desc meta key is enabled then you can use the following query:
   threat.desc = ‘apt-Ismdoor-c2’

ISR is a password stealer that has been spreading through phishing attacks. The malware targets different browsers and programs in order to steal the victim passwords. In this blog post we will discuss how to detect ISR traffic using RSA NetWitness.

 

ISR uploads the stolen data to compromised websites as shown in the screenshot below

 

 

The unique user-agent string used in this HTTP GET request is common among ISR variants:

 

 

Assuming the appropriate meta keys are enabled, the following query can be used to detect ISR network activity:

            service = 80 && client = ‘HardCore Software For : Public’

 

More information about ISR can be found on Intel Security blog. Scan results for an ISR binary can be found here.

 

All the IOCs from those sessions were added to the following feeds on Live:

  • RSA FirstWatch Command and Control Domains
  • RSA FirstWatch Command and Control IPs

To find those IOCs using RSA NetWitness, please refer to this post.

Every week RSA FirstWatch collects hundereds of indicators of compromise from running different kinds of malware samples. They are used to update the following feeds on Live:

  • RSA FirstWatch Command and Control Domains
  • RSA FirstWatch Command and Control IPs

 

Those binaries are often referred to as commodity malware. They are not tied to an actor or a targeted campaign. Thus our team doesn’t use any specific meta values to tag them. In this blog post we will discuss how to find those IOCs using RSA NetWitness.


Let’s take Sality for example, a malware family that has been around for a very long time. Below is a screenshot that shows a Sality sample beaconing to its Command and Control server:

 

Recently we blogged about Dyzap malware and how to detect it using RSA NetWitness. This is how Dyzap beaconing activity looks:

 

 

In both cases the IOCs were added to the same FirstWatch feed(s) on Live. You can use the following meta keys and values in your app rules and reports:

  • threat.source = 'rsa-firstwatch'
  • threat.category = 'botnet'
  • threat.desc = 'c2-domain' or threat.desc = 'c2-ip'

Dyzap is an information stealer that has been around for a while. The malware has the ability to steal usernames and passwords of e-mail, banking and social media accounts. A new variant has been recently spreading through phishing messages. In this blog post we will discuss how to detect it using RSA NetWitness.

 

Once the malware infects a victim machine, it starts sending data to its server via an HTTP POST request:


 

Similar network activity originates from different machines infected with Dyzap:


 

The same user-agent string is used across all the sessions. On RSA NetWitness you can develop an app rule to detect Dyzap traffic:

            service = 80 && client = 'mozilla/4.08 (charon; inferno)'

 

While malware authors can change a user-agent string from one variant to another, Dyzap network activity is suspicious enough for an analyst to take a closer look.  All the sessions above have binary payloads, have no referrers and consist only of HTTP POST methods. Such anomalies can be easily detected with the RSA IR hunting pack. For more information on the hunting pack, please refer to this document.

 

An example of a document that drops this Dyzap variant can be found here. Analysis results of one of those binaries can be found here.

 

Microsoft has more information on its threat encyclopedia website.

 

All the IOCs from those sessions were added to the following feeds on Live:

  • RSA FirstWatch Command and Control Domains
  • RSA FirstWatch Command and Control IPs

This week security researchers at Palo Alto Networks revealed a new targeted attack by the APT group Wekby against a US-based organization. Unit42 named the malware used by the group as pisloader based on its metadata. Most notably pisloader uses DNS requests to communicate with its command and control server. In this blog post we will discuss how to use RSA Security Analytics reports to help an analyst in finding odd DNS requests.

 

First, you need to start by creating a rule in SA. In this use case, we are interested in DNS requests for a TXT record:

 

DNS-TXT-rule.png

 

 

The rule builder can be used to filter the result set or add more meta values to it if necessary. Next, you need to add the rule to a report and schedule it to run on a regular basis.

 

DNS-TXT-report2.png

 

I chose to schedule a daily report that looks for DNS requests for a TXT record in the past 24 hours:

 

DNS-TXT-report3.png

 

When RSA FirstWatch ran pisloader malware samples in its sandbox, the binaries started to beacon to their C2 servers. This is how the DNS requests look in the newly created report:

 

DNS-TXT-report.png

 

 

An analyst can go through the result set of the newly created report to rule out any false positives and dig deeper into more suspicious ones.

Tendrit is a backdoor malware family that has been used in targeted attacks since 2011. The malware is known to spread through phishing campaigns that use holiday themes to lure the victims into running their payload. In this blog post we will discuss how to detect its beaconing activity using RSA Security Analytics.

 

Once it infects a victim machine, this Tendrit variant start to collect data about the victim machine like its hostname, username, MAC address and OS version. The collected data is encoded and sent to the C2 server via a GET request as shown in the screenshot below:

 

tendrit-session.png

 

The network behavior is the same across Tendrit samples:

 

tendrit-investigator.png

 

Assuming the appropriate meta keys are enabled, the following query can be used to detect Tendrit network activity:

          service = 80 && action = 'get' && filename = 'css.ashx' && query begins 'nly='

 

Scan results for a Tendrit variant can be viewed here.

Locky is a new ransomware family that is getting a lot of interest among security researchers because it is being delivered by the same actors behind the notorious Dridex banking trojan. Locky spreads through spam campaigns with attached office documents that use embedded macros to download Locky binaries to their victims. You can read more about Locky on Proofpoint blog.

 

In this blog post, we will see how its network activity looks in RSA Security Analytics. After the user enables the macro, an executable is downloaded to the machine as follows:

 

locky-session1.png

 

locky-investigator1.png

 

Downloading executables is definitely not exclusive to Locky or any ransomware family but it is suspicious enough to warrant further investigation. Once the transfer is complete, Locky runs and starts to communicate with its C2 server as follows:

 

locky-session2.png

 

locky-investigator2.png

 

Assuming the appropriate meta keys are enabled, the following query can be used to detect Locky network traffic:

               service = 80 && action = 'post' && filename = 'main.php' && client !exists

 

Scan results for a Locky variant can be found here.

 

All the IOCs from those HTTP sessions were added to the following RSA FirstWatch Live feeds:

  • RSA FirstWatch Command and Control IPs
  • RSA FirstWatch Command and Control Domains

HttpBrowser is a Remote Access Trojan associated with cyberespionage campaigns. This blog will discuss how to detect its beaconing activity using RSA Security Analytics.

 

HttpBrowser sends information about the infected system to its C2 server via POST requests:

 

httpbrowser-session2.png

 

 

The querystring is the decimal representation of the value returned by the GetTickCount system call. It is the number of milliseconds that have elapsed since the system was started. In the request body itself, more information is included:

  • computer: Machine hostname [username]
  • lanip: IP address of the infected machine
  • uid: An encoded value that has the Machine GUID and its volume serial number
  • os: Windows Major version, Windows Minor version, System architecture

 

Malware researchers called this family HttpBrowser based on the unique User-Agent string used by its variants. However, recent HttpBrowser binaries dropped that UA string altogether and started using a common one in order to bypass signatures and blend in with other network traffic.

 

httpbrowser-session1.png

 

Except for the UA string, everything else stays the same. That’s how the traffic looks in Security Analytics Investigator:

 

httpbrowser-investigator.png

 

 

Assuming the appropriate meta keys are enabled, the following query can be used to detect HttpBrowser network activity:
               action = 'post' && directory = '/' && filename = 'result' && query exists

 

Scan results for an HttpBrowser variant can be viewed here.

 

All the IOC from those HTTP sessions were added to the following RSA FirstWatch Live feeds:

  • RSA FirstWatch APT Threat Domains
  • RSA FirstWatch APT Threat IPs

If threat.desc meta key is enabled then you can use the following app rule:

               threat.desc = 'apt-httpbrowser-c2'


Filter Blog

By date: By tag: