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

We heard you loud and clear - with the upcoming long Memorial Day weekend fast approaching, school classes ending in the Midwest for the summer, and a host of work-related commitments, you wanted more time to submit Call for Speakers (C4S) Abstracts.


We are pleased to tell you that the deadline for C4S submissions has been extended and is now EOD on June 9, 2017.


This is a hard deadline, however, and will not be extended again so we can meet all the time-sensitive event activities leading up to RSA Charge 2017.


All of the information to help you submit your proposal can be found on the RSA Charge 2017 microsite, including Charge registration information – though RSA Charge ‘Speakers’ receive a complimentary pass to the Charge event – another solid reason to submit!


First, check out the webinar replay of 'What You Should Know Before Submitting Your Proposal' and then use the Offline Submission Form (for practice) before submitting your proposal using the Online Submission Form. There are also FAQs to help you too. 


The Tracks for RSA Charge 2017 include:


(Governance, Risk & Compliance)

Inspiring Everyone to Own Risk

Managing Technology Risk in Your Business

Taking Command of Your Risk Management Journey

Transforming Compliance

RSA Archer Suite Technical

RSA Archer Suite Advanced Technical


(Security Operations, Identity, Anti-Fraud)

Detecting and Responding to the Threats That Matter

Identity Assurance

Reducing Fraud, while Not Reducing Customers

Secrets of the SOC


Complete Session details are also available.


With the extended deadline through June 9, we hope you will consider sharing your first-hand knowledge, advice, ideas, experiences, case studies, and war stories with your peers at Charge 2017. For the many who have already submitted proposal abstracts, ‘thank you’ and we look forward to seeing you in Dallas, Oct. 17-19.

Visibility: RSA Archer Staging

Blackmoon (also known as KRBanker) is a banking trojan that was first detected in 2014.  Its purpose is to steal financial account login credentials using a man in the browser attack.  The perpetrators then impersonate legitimate users to conduct fraudulent transactions with banks or a variety of wealth management, investment, retirement, etc. services(1). In this way, Blackmoon victimizes both consumers and businesses when the campaign is successful.   South Korea is currently a primary target.


The latest version of Blackmoon uses a new multi-phase framework to evade current detection and facilitate more effective program modifications in its victims. 


Referred to as the Blackmoon Downloader Framework(1), it consists of three stages or modules which are designed to work in unison.


Stage 1-Dropper

Blackmoon propagates via a dropper commonly delivered via adware, phishing, or in some cases exploit kits.  Upon execution the dropper code spawns multiple processes, of which each is necessary to ensure a successful infection.  During the first stage, a browser vulnerability is exploited to request/receive bytecode to initiate stage 2.


Stage 2-Downloader

The second stage runs bytecode.  Its purpose is to expand the malware's functionality and resolve any functions it needs.  It then decodes an onboard blob of data with a single byte XOR. This contains the URL for the next download, from which the malware retrieves an EXE file typically masked as a JPG file to avoid detection. 


Stage 3-EXE

The framework’s final stage uses a Base64 string encoding technique to mask operations.  This obfuscation hides decoding of the Command and Control (C2) IP addresses used for bot check-in, downloading of the EXE payload, and its execution.  This stage results in a victim’s browser being redirected to a compromised website, similar to the one shown in figure 1.  After a user attempts to authenticate, their login credentials are harvested and redirected to the threat actors.


Figure 1 Source-


NetWitness Detection

RSA Netwitness Endpoint can detect Blackmoon.  Endpoint dives deeper into network endpoints to better analyze and identify zero-day, new, hidden, and even those “file-less”, non-malware attacks that other endpoint security solutions miss entirely.




Thanks to Kevin Stear, Bill Motley, and Christopher Ahearn for their contributions to this threat advisory.



These IOCs will be added to the Third Party Feed












Additional Reading-


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



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.



  1. Malicious Documents: The Matryoshka Edition | Didier Stevens 
  2. - 2017-04-21 - Dridex-style malspam pushes Locky ransomware instead 
  3. - 2017-05-11 - Jumping on the Jaff ransomware bandwagon 
  4. - 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 

It’s down to the final weeks for Call for Speakers (C4S) proposal submissions for the RSA Charge 2017 event.


If you are still on the fence, time is running out but there are some helpful aids to get you started. First, check out the webinar replay of ‘What You Should Know Before Submitting Your Proposal’ and then use the Offline Submission Form (for practice) before submitting your proposal using theOnline Submission Form.  There’s also FAQs to help you before submitting your proposal.


The Tracks include: 

Security Operations, Identity, Anti-Fraud

Detecting and Responding to the Threats That Matter

Identity Assurance

Reducing Fraud, while Not Reducing Customers

Secrets of the SOC


You may also check out the completeRSA Charge 2017 Session details


All of the information to help you submit your proposal can be found on the RSA Charge 2017 microsite, including Charge registration information – though RSA Charge ‘Speakers’ receive a complimentary pass to the Charge event – another solid reason to submit! 


Even if you are not considering submitting a presentation proposal, we encourage you to attend this premier event; save $300 with the Early Bird Discount through June 30.


See you in Dallas!

Overview of WannaCry/Wanna Decryptor

As you know, starting late Thursday and hitting mainstream over Mother’s Day there is a current outbreak of a ransomware threat known as “WannaCry” or “Wanna Decryptor”. Ransomware attacks like “WannaCry” are meant to be very visible in order to pressure the victim to pay the ransom. The scale of this attack, together with this specific ransomware family, is unique in that it has worm-like capabilities leveraging an exploit against vulnerable Microsoft Windows® operating systems. This exploit was recently made publicly available and appears to be associated with the “Shadowbrokers” release of nation state hacking tools. As of 5/15/2017 at 1pm ET, the associated income achieved is less than $50k the best we can estimate, less than 150 individuals or businesses impacted that were willing to pay.


While details are still emerging, RSA believes it follows a typical attack pattern where a malicious link is delivered through email as part of a phishing scam, whereby the malware installs itself. The malware can spread rapidly when an already infected computer is able to locate additional open and vulnerable computers with outbound internet connections. This malware can travel quickly through an internal network as a result of a core Windows networking function exploit. Microsoft issued a patch for this vulnerability under advisory (MS17-010).


The vulnerability exploited in this attack was made public in September, 2016. Microsoft released a patch in March, 2017. If an organization looks at their enterprise risk management with proper cyber hygiene, they may not have been vulnerable to this attack.


While mitigating attacks like this, which include host blocking, a robust backup strategy and comprehensive patch management, IT leaders should also be mindful that because of Microsoft’s patch support policy, any organization still running Windows XP, Windows 8 or Windows Server 2003 remain at high risk. Microsoft has issued specific guidance for this attack, which can be found here. This is not a new phenomenon and like in most major attacks, resistance is achieved with disciplined patching hygiene.


This latest wave of ransomware continues a trend with this popular attack method. Attackers are shifting away from stealing information for profit, rather taking advantage of the fact that data is critical to its victims for daily business operations.


Was RSA or Dell Technologies Impacted?

While we continue to monitor and validate, at this time there appears to be no impact to the internal networks of any of the major Dell Technologies networks.


Are RSA Products Impacted?

Individual alerts have been sent to clients using specific products. Because many clients leverage Microsoft OS and products as underlying components of RSA Products, there is a risk they could be impacted. That said, the actual product applications that RSA distributes are not impacted.


How RSA Can Help You?

You may be asking how RSA can help. First, recognize that ransomware threats, by design, are noisy and are obvious to the infected victim … this is part of the criminal’s objective and business model. RSA NetWitness® Suite is designed to help identify and provide visibility into a ransomware attack – but as part of this attack method, the victim organization’s data is being encrypted by the malware. This is the same for any advanced threat detection and response technology platform.


From a risk perspective, RSA Archer is designed to help automate risk management, prioritizing activities to reduce risk (i.e. Vulnerability Risk Management) to mission-critical systems, and consistently and effectively manage an actual incident.


From an investigation and readiness standpoint, RSA can provide strong visibility and expertise, helping users to reconstruct, analyze, and understand the attack for current and future identification of ransomware behavioral indicators and operational performance optimization. Analysts within Security Operations Centers (SOC) can see suspicious activities such as lateral movement of infected systems, and/or attempts to infect workstations and other network and critical business assets to more readily determine the overall operational, business continuity, governance, regulatory and compliance impact of the attack to their business. Lastly, RSA can help security programs and IT operational functions see the last known good state of the workstation to understand when the incident first began in order to measure “dwell time”, determine SOC visibility and detection, gaps and remediation requirements as well as the ability to restore from known good backup. This can help limit data loss and reduce the prospect of paying ransom to the attackers.


In a large-scale attack like this, expertise and experience in readiness, response, resilience and business risk management is imperative. RSA can help organizations in their response and readiness efforts and programs. These attacks can be contained and preemptive efforts can be taken to block similar attacks from occurring in the future, minimizing the impact and scale of ransomware campaigns.


For a deeper dive on using RSA Netwitness to improve you visibility and make decisive steps to reduce the impact on your environment, see WannaCry from the RSA NetWitness Suite's Perspective and Blocking WannaCry with Netwitness Endpoint.


Other RSA and Third Party References

Here are some additional resources if you’d like to learn more about the attack.


What's to Come?

New attacks are often followed by attack variants that use a similar infection vector with minor changes to bypass common defenses such as port and allowed path blocking. As such, four broad predictions:

  • Many organizations will not patch core systems, rather put in protective defensives such as AV, blocking ports and IP addresses, and other supplemental actions. Thus, future morphs of WannaCry will continue to impact customers.
  • After some minor reductions in volume of attacks we will see continued:
    • Increase in leveraging attack tool leaks to fuel new attacks. Increase in attacks that focus on incidents that demand immediate monetary payment. (i.e. DDOS, Ransomware, identity change, etc.)
    • Exploit of older vulnerabilities will continue to make headlines.
  • Industry and government regulatory bodies always respond to major cybersecurity events, thus you can assume there will be a continued tighten requirements around vulnerability management and patch hygiene.
  • Risk management will become more fundamental in the scheme of prioritizing resource allocation and spend. More alignment between business needs and underlying security activities are on the horizon … this is still a year of planning and early walks for most organizations.


In Summary

While newsworthy and certainly impacting organizations, the underlying issue for WannaCry is patch hygiene. Understanding the IT investments needed to be able to upgrade applications tied to OS changes (i.e. config, patches, etc.) must be a focus for organizations to better improve vulnerability to patch to deployment. Understanding major newsworthy hacking event, can reveal defensive commonalities that can have broad, risk reducing impacts to the organization short and long term.


These include:

  • Aligning business risk tolerance to a risk and cybersecurity plan
  • Prioritizing actions to reduce risk (less whack-a--mole)
  • Focus on the fundamentals that positively impact all threats:
    • Educating people
    • Business-driven risk reduction tied to an action-oriented plan
    • Continually test your environment for weaknesses
    • Strengthened identity and access assurance program
    • Assume all defenses will fail and that your understand of your environment isn't optimal.  Make sure you have expert visibility at the perimeter, inside the network, in the cloud and on attached mobile devices.  You must be able to monitor logs, packet traffic and what's actually happening on the endpoint. More importantly, you must have the expert capacity (people) to seek, monitor and respond to threats.
    • Automate your processes wherever possible. Very few organizations can invest at a level that provides enough people to adequately address the workload manually. The more organizations seek to enhance the efficiency and efficacy of their security teams, the greater the probability of success.


RSA’s Business-Driven Security solutions uniquely link business context with security incidents to help organizations manage risk and protect what matters most. The RSA Risk and Cybersecurity Practice, our expert professional services team, help organizations identify, assess, and close the gaps; and take command of their evolving security posture. Feel free to contact RSA for further detail or assistance.


Additional Resources

On Friday, May 12th 2017, one of the largest ransomware attacks in history was launched using WannaCry infecting more than 230,000 computers in 150 countries in a matter of days.  Attackers are demanding ransom payments using Bitcoin, with amounts increasing as time goes on. The attack has been described by international organizations like Europol as unprecedented in scale.


When executed, the malware first checks for a specifically generated kill switch domain . If it is not found, then the ransomware will begin to encrypt data on the computer.  WannaCry has a second stage that attempts to exploit the SMB vulnerability MS17-010 to spread out to random computers on the Internet, and laterally to computers within an organization.


RSA Netwitness Endpoint can not only help detect this activity (WannaCry from the RSA NetWitness Suite's Perspective ), but also proactively block it to stop the spread and reduce further damage from infection.



Customers should take caution when blocking files with Netwitness Endpoint.  Netwitness Endpoint will not block files signed by Microsoft or the RSA Netwitness Endpoint (ECAT) driver.  However any other SHA256 hashes entered via blacklisting in the GUI with the blocking option enabled or directly into the NWE database will be blocked.  Netwitness Endpoint has safeguards in place, including prevention of blocking if a module is present on more than "x" number of systems.  This is configurable.  Also blocking must be enabled at the group level and globally.  Machines by default will inherent this setting from their group, but can also be enabled or disabled at the individual machine.


Blocking Global Parameters

The attached SQL query can be run to block 241 different variants of WannaCry.  Additional SHA256 hashes can be added to the block list by following the same format in the SQL query.  It needs to be run in SQL Server Management Studio against the NWE database (By default this is named ECAT$PRIMARY).


SSMS Query


After this is completed make sure to select Tools->Force Blocking Status Update to push the changes to the NWE agents.  



You can verify this is successful by checking the "BlockingHashes" table on the NWE database as well as the agents in c:\Program Data\ecatservice


Confirm Hash DB Update

In this post, I will quickly go through some aspects of the WannaCry ransomware from the perspective of RSA NetWitness Endpoint and Packets. This would allow to help detect, investigate and analyze such compromises.



If we first look at the modules dropped by the malware, we can see 5 main modules.

4 of the modules are labeled as "Malicious" based on the reputation database.

We can also see that all of them have a relatively high IIOC score.


If we look at the below triggered IIOCs which caused those scores, we can see some behaviors typical of ransomware:

- "Deletes shadow volume copies" (to stop the recovery of encrypted files)

- "Rapidly reads multiple documents" (triggered during the encryption of the documents)

- "Modifies run key"(to run at startup)

- "Beacon" (due to communication with C2)



If we now analyse the @WannaDecryptor@.exe file (right click, Analyse Module), we can see some artifacts that can help us understand the behavior, such as:

- References to the generation of encryption keys ("CryptGenKey")

- Hard-coded commands, such as the deletion of the shadow volume copies using vssadmin


- Or even the list of file extensions the WannaCry ransomware looks for to encrypt



Now, to look how the WannaCry ransomware infects the machine, we can look at the tracking module, having visibility over the command line arguments as well, and check the behavior in chronological order:

- (1) It first drops the payloads

- (2) It then sets the directory as hidden (as reflected in the triggered IIOCs seen earlier) using "attrib.exe"

- (3) It grants full access to all users using "icacls.exe"

- It writes and executes a batch file and a vbs script

- (4) Documents start to get encrypted


If we continue looking at the behavior tracking, we can see that the malware starts copying the @WanaDecryptor@.exe file to multiple locations on disk:



Finally, once the encryption is completed, it does the following:

- (1) It executes the @WanaDecryptor@.exe file which displays the warning message and countdown to the user

- (2) It drops the files needed to run tor.exe, which is used to communicate with the C2

- (3) It modifies the run registry key

- (4) It deletes the shadow volume copies




If we now have a look from RSA NetWitness Packets' perspective, we can easily and quickly identify the following based on the default parsers and RSA Live Feeds:

- Tunneling using tor (in "Risk: Suspicious")

- Identify access to the tor network, C2 and Crimeware (in "Threat Category")

- The use of SMB and Netbios which is used by the malware to propagate itself

- Access to suspicious looking domain names



It would also be possible to reconstruct those sessions if needed.

Join more than 2,000 security, risk and compliance professionals at the premier Business-Driven Security event, RSA Charge 2017. This year’s event will be held Oct. 17-19 in Dallas at the Hilton Anatole Hotel.


This is your opportunity to network with RSA customers, partners, and industry experts while discovering how to implement a Business-Driven Security strategy in an increasingly uncertain high-risk world.


To whet your appetite, check out Top 10 Reasons to Attend RSA Charge 2017 and Agenda at a Glance


RSA University will also once again be offering condensed product-specific training courses beginning Monday, October 16 and on Tuesday, October 17, with information available soon on the RSA Charge microsite.  Visit the microsite often to stay informed and maximize your experience at RSA Charge 2017.


Don’t miss this event - inspiring Keynotes, hands-on labs, strategic security sessions, technical deep-dives, and so much more; register today and save $300 with the Early Bird Discount through June 30.


See you in Dallas!

Kevin Stear

RIG Decimal IP Campaign

Posted by Kevin Stear Employee May 11, 2017

In a world where the Internet makes sense to casual users “IP addresses (IPv4) follow the dot-decimal notation, which is four numbers, each ranging from 0 to 255, separated by dots. But then, to make things a little more complicated, we have exceptions, such as the non-dotted IP literals, in decimal (http://2130706433/) or octal form (http://017700000001/).”[1]


Most current browsers automatically convert non-dotted IP literals to 'normal' dot-decimal format, but can most snort instances? This is likely an issue for some traditional IP-based detection measures, which is probably why current RIG-related activity rightfully dubbed the Decimal-IP campaign has adopted just such a technique.  During April and May, RSA FirstWatch noted the presence of decimal-IP redirectors in use with the RIG Exploit Kit (EK).




The Decimal-IP campaign is currently believed to be one of two active campaigns leveraging RIG, and has been recently observed delivering smokeloader, and you can find sample <here>. (Seamless is the other active RIG campaign, which was delivering Ramnit ransomware in April.)  Here's a good write-up by zerophage.


Brad Duncan (thanks for the images) also has a good technical walkthrough of the Decimal IP campaign delivering smokeloader via a fake adobe flash player install.  Below are a couple of related screenshots of traffic from the fake adobe site and then the file <open> dialogue for the smokeloader payload.





In addition to the smokeloader payload, during a recent changeover in the campaign’s operations, FirstWatch observed Decimal-IP redirects to seemingly Litecoin-related sites for ‘segwit.php’. This is interesting… especially given the recent events surrounding Segregated Witness or SegWit and its potential to bring transaction malleability and block scaling on Litecoin and Bitcoin. This is an area of ongoing research.




With regard to detection of decimal-IP usage, the NetWitness ‘HTTP_lua’ parser has been updated to tag “http host header is an integer” in the analysis.service field. This content is currently available in RSA Live.




With specific regard to detection of ‘RIG Decimal IP Campaign’ activity, a new ESA rule is also available in RSA Live.





Special thanks to @nao_sec (twitter) for continued efforts that provide referrers for our ongoing research against RIG exploit kit.




The Dridex Trojan is a strain of banking malware that began spreading in 20141. Its transport mechanism continues to be spam email, commonly referred to as malspam. It steals a victim's banking credentials in order to commit fraudulent financial transactions. Historically, Dridex relied on Microsoft Office macros to successfully infect a victim. A new campaign, however, reveals that it's now leveraging a Microsoft Word zero-day vulnerability (CVE-2017-0199) instead.

For the exploit to land, a user must open an attached Microsoft Word RTF (Rich Text Format) document. Contained within it is an embedded OLE2link object which executes winword.exe. That process sends a HTTP request to a remote server which retrieves a malicious .hta file, the payload2.

To enable detection of malicious RTF documents, users need to verify that their NetWitness installation has been configured with the:

-‘fingerprint_rtf_lua parser’ from RSA Live.


Once you have subscribed to and enabled this content in your environment, NetWitness will identify suspicious strings in the RTF header. Shown below is the parser flagging RTF traffic.

Thanks to Kevin Stear, Bill Motley, Angela Stranahan, and Christopher Ahearn for contributing to this threat advisory.






Additional reading:

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]:




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 [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 ''

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.




PunyCode is a special encoding used to convert Unicode characters to ASCII, which is a smaller, restricted character set and used to encode internationalized domain names (IDN) [1]. PunyCode is a way to represent Unicode within the limited character subset of ASCII used for Internet host names. For example, "München" (German name for the city of Munich) would be encoded as "Mnchen-3ya". Using PunyCode, host names containing Unicode characters are transcoded to a subset of ASCII consisting of letters, digits, and hyphen (the Letter-Digit-Hyphen (LDH) subset, as it is called)[2].


There exist non-Latin character sets which contain code points (characters) that, when displayed, look like Latin code points:

ASCII 0x61 -> a

Unicode U0430 -> a (0x0430 if UTF16, but 0xd0b0 if UTF8)

A name consisting of characters that look like Latin characters is a different name than if it consisted of Latin characters.

xn--80ak6aa92e -> 0xd0b0d180d180d38fd0b5

0xd0b0 (UTF8 U430) -> "a" (Cyrillic small letter "a")

0xd180 (UTF8 U440) -> "p" (Cyrillic small letter "er")

0xd180 (UTF8 U440) -> "p" (Cyrillic small letter "er")

0xd38f (UTF8 U4CF) -> "ӏ" (Cyrillic small letter "palochka")  ...and so on...


Byte sequences like 0xd0b0, 0xd180, et al can't be used in things like domain names, etc.  The RFC 3492 document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. PunyCode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDN.


This threat advisory discusses how to detect IDN homograph Phishing attacks using RSA NetWitness Logs & Packets.


PunyCode Detection using IDN_homograph Parser

IDN_homograph lua parser detects punyCode-encoded internationalized domain names which use non-Latin Unicode code points whose glyphs resemble those of Latin Unicode code points and registers the decoded homograph as analysis.service meta.

  • service - host as which the homograph is masquerading
  • ioc - indicators of compromise - homograph detected


IDN_homograph lua parser is now available on RSA Live:





Host aliases encoded with PunyCode:



Meta registered in RSA NetWitness Investigation:

  • host:
  • ioc: homograph detected
  • service:


Below is screenshot of IDN_homograph parser detecting IDN homograph attacks:



Detection of homographs used in Phishing Emails


If an email contains: <a href=""></a>

Then Phishing_lua parser will register:  risk.warning - href host doesn't match displayed host as well as the same IDN meta from IDN_homograph as above.

If an email contains: <a href=""></a>

Then there is no mismatch, but the host will still be registered from Phishing_lua parser, and the same IDN detection will be

done by IDN_homograph parser.




Event Stream Analysis for Detecting PunyCode Phishing Attempts


Event Stream Analysis (ESA) rule identifies mail sessions that have a PunyCode hostname and also have a mismatch between the hostname in a link (href) and the text in the same link containing an IDN homograph.  This suspected phishing attempt is then followed by HTTP(S) traffic with the same hostname in the certificate or in the host.



ESA rule will alert based on presence on PunyCode in emails, which is detected using ioc’s and analysis_service meta generated from IDN_homograph and mail protocol parsers. It also does looks for sessions on which uses same alias host over HTTP(S).



Event Stream Analysis Rule for PunyCode Phishing Attempt is now available on RSA Live:





Thanks goes to Sean LimWilliam Motley and Angela Stranahan for contributing to this threat advisory.



  1. IDN converter:

Filter Blog

By date: By tag: