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

Microsoft Azure Network Security Group Flow Logs are a feature of Azure Network Watcher that provide information about ingress and egress IP traffic through a configured Network Security Group. The NetWitness plugin built for Azure NSG can authenticate and pull flow logs from Azure storage in real time.


“While Virtual Network (VNET) is the cornerstone of Azure networking model and provides isolation and protection. Network Security Group (NSG) is the main tool you need to use to enforce and control network traffic rules at the networking level. Customers can control access by permitting or denying communication between the workloads within a virtual network, from systems on customer’s networks via cross-premises connectivity, or direct Internet communication. In the diagram below, both VNETs and NSGs reside in a specific layer in the Azure overall security stack, where NSGs, UDR, and network virtual appliances can be used to create security boundaries to protect the application deployments in the protected network.”


What is a Network Security Group (NSG)?





How does it work?

These flow logs are written in JSON format and show outbound and inbound flows on a per rule basis.


It provides the following information: 

  • MAC Address of the NIC, flow applies to
  • 5-tuple information about the flow (Source IP, Destination IP, Source Port, Destination Port, Protocol),
  • And if the traffic was allowed or denied.


Flow logs are stored only within a storage account and follow the logging path as shown below:



Logs have a retention policy that can be set from 1 day to 365 days. If a retention policy is not set, the logs are maintained foreverRSA Netwitness uses Shared Access Signature (SAS Token) to authenticate and pull flow logs from Azure storage in real time.

Use Cases:

With the visibility into Network Flow traffic in the Azure framework, multiple use-cases can be built. For example: 


  1. See the overall stats of Allowed vs Denied Traffic in your network, and based on what’s normal, setup alerts if its above or below a certain threshold.
  2. Summary of Protocol usage in the environment, set alerts for abnormal protocol usage. 
  3. Top Destination Address Reached out to from your environment.
  4. Set Alerts against blacklisted IP Addresses
  5. Setup rules based on IP range to determine Inbound vs Outbound vs Lateral traffic and then build a dashboard to see the pattern.


Downloads and Documentation:


Configuration Guide: Microsoft Azure NSG Event Source Configuration Guide 


Collector Package on RSA Live: "MS Azure NSG Flow Logs"


Parser on RSA Live: CEF (device.type="msazurensg")


The threat landscape continues to be aggressive, with the advantage on the side of threat actors. Attackers use ever evolving tools and techniques that evade signature based intrusion detection technology. We are no longer dealing with simple script kiddies that can be thwarted by a traditional, preventative control based approach. The deep inspection of network traffic and endpoint behaviors for signs of intrusion –yes, based on signatures for known attacks, but also based on more than just rules and policies to detect unknown threats is needed in today’s landscape to tip the advantage to the good guys. 

IPS/IDS has always promised to stop or detect intrusion at the front door by using a signature based approach, which blocks based on known indicators – but we all realize that no matter how high of a wall the security team builds, some attacks will still get over (or through it).  Today, preventing intrusions mean stopping the attackers from taking (or destroying) your data – and you can’t rely only on rules, like traditional IDS.  Whether that is through malware analytics, user behavior analytics, advanced correlation or endpoint analytics – true intrusion detection must be enabled by visibility across the network and down to the endpoint. One size does not fit all here.

Detecting intrusions has to begin with understanding network traffic, and using it to detect anomalies that may signal an intrusion. This is exactly what RSA NetWitness Suite does – it quickly detects any intrusion or attack as they are happening by performing multiple types of analysis on enriched network metadata – not based on rules, like a traditional IDS.  With out-of-the-box threat content to better detect known and unknown threats such as malicious webshells, DNS tunneling, custom protocols, lateral movements, and data exfiltration, analysts can easily deploy the same detection rules used by the experienced RSA Incident Response Team. Real-time enrichment with threat intelligence - from industry experts, third party providers and crowd sourced from our customer base – as well as business context provides for better prioritization of alerting and helps analysts during forensics and hunting. In addition, we can utilize this intelligent metadata to detect any anomalies across your network, suspicious activity of machines and users, as well as abnormal activities across your applications – no matter where they reside: on premise, virtual machines or 3rd party cloud and within both north-south and east-west communications. 

Let’s take a look at an example – detecting intrusions based on Webshells – and how RSA NetWitness Suite can give early indicators of an intrusion.

A Typical Attack Scenario

A common method of attack leverages vulnerabilities in a website (e.g. SQL Injection, Remote File Inclusion) to remotely generate or install a file that will act as a WebShell. Once the WebShell is successfully installed, the remote attacker may then craft an HTTP POST request directly to the WebShell with embedded commands that will be executed as if the attacker had local (shell) access to the web server.


Attackers who successfully use WebShells take advantage of the fact that many organizations do not have complete visibility into HTTP sessions. Traditional tools rely on signatures and are easily left blind by intentional obfuscation of payloads and commands. In order to effectively respond to WebShell attacks, defenders must maximize visibility into each stage of the attack lifecycle. The following chart contrasts the visibility by attack stage into an attacker’s tools, tactics, and procedures (TTPs) provided by traditional tools with RSA NetWitness solution:


Detecting possible WebShell activity involves understanding what an HTTP session with an embedded command typically looks like. There are a few notable features often seen with this attack:

  • Request sent directly to a web server with the HTTP POST method to send data without populating commands in the URL string: This method ensures typical web access logs do not include the command (vs. HTTP GET which would include the commands within the URL)
  • No HTTP GET will have been seen before the POST (Normal human-based web traffic would have seen a GET before a POST is issued)
  • (Usually) No Referrer header since the request is sent directly to the server and is not a result of click-through browsing
  • Posted data includes obfuscated shell commands to be executed by the WebShell


By reconstructing the entire HTTP session upon capture and immediately generating and extracting rich metadata, RSA NetWitness Suite makes it simple to alert on the features indicative of a WebShell attack, or a very early sign of an intrusion.


RSA NetWitness Suite is a critical component to any security organization’s capability to detect and intrusions that bypass security controls and other monitoring capabilities. The Suite utilizes multiple types of analytics – not just static rules – to find the broadest set of both known and unknown threats.

To read more about how RSA NetWitness Suite can detect early in the lifecycle of an intrusion attempt, check out the Remote Access: Webshells solution brief.

The Salesforce event monitoring product gathers information about an organization's Salesforce operational events.  This information can be used to analyze usage trends and user behavior. Event monitoring allows querying fields on the EventLogFile object (such as Event Type and LogDate). The Event Type determines the schema of this field. For more information, see EventLogFile Supported Event Types on the Salesforce Developers Website. 


RSA NetWitness uses OAuth Username-password flow to authenticate between a Connected App and the Salesforce API. Creating a read-only custom profile restricts the users to have read-only access to Salesforce API logs.


RSA provides steps to configure the Salesforce event source using either the Classic View or the Lightning Experience View.





This plugin supports all the 45 different Event Types provided by Salesforce, for Login, LoginAS, Logout etc. All the types are explained here:


Also, the raw events in Salesforce only exposes User Ids and not the actual user names. Salesforce maintains a separate mapping of UserID to username. This integration polls the UserID to user mapping on a configurable time interval so that it can  provide the actual user names for every userID given in the events. 


Configuration GuideSalesforce Event Source Configuration Guide 

Collector Package on RSA Live: "Salesforce Log Collector Configuration"

Parser on RSA Live: CEF (Parsed as device.type=salesforce)

Malspam activity was observed on February 11th delivering a Keybase variant. The keylogger was first reported by security researchers at Palo Alto Networks in 2015. FirstWatch previously blogged about how to detect it using RSA NetWitness.


The delivery document is crafted to exploit CVE-2017-8759 in Microsoft Office. CVE-2017-8759 is a SOAP WSDL parser code injection vulnerability. FirstWatch dug deeper into that vulnerability in a previous threat advisory.


Upon opening the RTF document with an un-patched Microsoft Word, the user is presented with an empty page:



In the background there is an HTTP request over SSL to a[.]pomfe[.]co :





Next comes the request to retrieve an HTA script from bahyt-krim[.]ru :




Then an executable ziraat_bobby.exe; a Keybase variant; is downloaded from the same domain:





Once the download is complete, the binary executes and it starts to exfiltrate data in the query strings of successive HTTP GET requests to ziraat-helpdesk[.]com:





Post infection HTTP sessions were tagged with keybase malware in NetWitness Packets:



Here is the analysis report from


It is worth mentioning that the delivery domain bahyt-krim[.]ru has been active over the past couple of days:



Delivery document (SHA256):

  • 4487cb74d5524d57eb0859bdda34fd9ba7f426fd0867e8826ac2e8c787052848


ziraat_bobby.exe (SHA256):

  • df48d1ef1d11b4b5bbc92f52de489935ffb9e36ff226b9ac0a7f5c899b9f1db1


Malspam activity was observed on February 13th delivering a variant of ISR password stealer. ISR was reportedly used in spear phishing attacks against food and machine industries. In this blog post we will discuss the network activity using RSA NetWitness Packets.


The delivery document Payment receipt.doc is crafted to exploit CVE-2017-11882. You can learn more about the vulnerability in this FirstWatch threat advisory.



Opening the malicious document with an un-patched Microsoft Word application led to the following network activity:





Once 99v.exe executes on the victim machine, it starts to communicate with what looks to be a compromised Wordpress website transeagleperu[.]com:



Since the User-Agent string used in this session is common to ISR variants, it was tagged with the value known bad ua credentialleak under Indicators of Compromise meta key:



It is worth mentioning that the delivery domain menorasarainc[.]info has been active over the past week:



Payment receipt.doc (SHA256):

  • 383521ecc7aa09050e82498e10c756c866b0ce47702d77c6a5a4a7da98517146


99v.exe (SHA256):

  • 29eb49ad843aa992abff873d9b611a62248b2b8b4fbfa900bb7712f6aa6cda65


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

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


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


Malspam was observed on February 7th 2017 delivering GandCrab ransomware. GandCrab is a new ransomware family that was first reported in late January. This is the first time to see it being distributed via a malspam campaign [1].


This screenshot from shows an example of e-mails used in the campaign [2]. They come with PDF attachments and a little bit of social engineering. If the user opens the attachment, it downloads a Word document ; opening the Word document in turn downloads the ransomware payload.



A similar infection chain has been used lately to deliver the Dridex banking trojan. RSA FirstWatch previously blogged on the resurgence of Dridex.


Scan-image001_070218.jpg is an example of one of those downloaded Word documents:



Submitting it to RSA pre-release What's This File service gives more information about its maliciousness:




The embedded code suggests that the actors are only targeting Windows 64 bits machines.


Upon opening the document with Microsoft Word on a 64 bits machine, an HTTP GET request is issued to sorinnohoun[.]com to retrieve a script:





It is a well-documented and publicly available script. It can reflectively load a DLL/EXE into a powershell process or it can reflectively load a DLL into a remote process. In this case, sct5 is being used to load the GandCrab ransomware into the powershell process:




Next, the malware connects to its C2 domain nomoreransom[.]coin to get the victim machine IP address:




This is followed by POST requests to the same domain with encoded/encrypted data:





On the host side, you can start seeing the files being encrypted. The ransomware adds gdcb extension to an encrypted file:



It drops a note in each directory with the instructions on how to pay the ransom and recover the files:




As of this writing, the actors are asking for 2.6 Dash coins to buy GandCrab decryptor in order to recover the files on this particular victim machine. If not paid in time, the ransom they are asking for simply doubles. 



Here is a recap of the network activity:



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

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


Feb-9523713.pdf (SHA256):

  • 3aabca6aa74d4499e07d8828be981e65d421603895dd8450a15b49f1113517ff


Scan-image001_070218.jpg (SHA256):

  • 8f9e12851b92fcc74f9c9ab6181aa3fd49eabcf789608f9986cb136141033213


sct (SHA256):

  • 6960a00da0069a5b1aa7e213962a65abe3b148ddb7ac508cda0f8f8492ef7eaf



  1.  GandCrab Ransomware: Now Coming From Malspam - SANS Internet Storm Center 

Here's an interesting problem that came from a partner of ours this week.  How do you map forcepoint_security CEF logs to the matching category name provided as a feed?  The further complication was that the event.type metakey contained a numerical reference that might overlap with other device types so it was important to match on both the device.type and the event.type columns before writing meta.


First thought was to use a feed, multi column feeds can be created with multiple callbacks however the UI currently throws an error when attempting to upload the XML which means you need to follow this KB reference and push out the feed manually on each decoder from the CLI (not a scalable solution for the partner).

000035599 - Creating custom feeds with multiple indexed meta keys for RSA Security Analytics 10.6.x 


A request is being opened shortly to address this issue so that in the future hopefully this can be accomplished in the UI for these situations.


Until then ...


This was a CEF message format so there is no specific parser that exists for forcepoint_security events which we could have used to add a VALUEMAP property to  to include the string of matches for the category to information.  However the CEF-custom.xml parser didn't let us define a new VALUEMAP that would have looked like this:

content="&lt;event_type&gt;&lt;msghold&gt;" />


So that was off the table which left Lua as the option to use multiple callbacks before writing the matched data.


The Lua parser is included in the attachment and has the table of event.type to category matches in a table that is used after matching the device.type and event.type before writing the category out to the metakey called category.


When installed on the log decoder(s) via the parsers tab it will show up in this section of the config window:


and when the parsers reload after uploading you will see these types of events matched for the event.type

On February 1st 2018, malspam delivered a malicious RTF document that tries to exploit Microsoft Office/WordPad via a Buffer Overflow Vulnerability in the ListView / TreeView ActiveX controls in the MSCOMCTL.OCX library, CVE-2012-0158. The malicious code can be triggered by a specially crafted DOC or RTF file for un-patched MS Office products.




VirusTotal Analysis of delivery document paymentorder.doc confirms presence of RTF exploit.



After opening the document in a vulnerable Microsoft Word application, a connection is established to “pgamix[.]com” to download a malicious executable payload, using shell code present in RTF file,  which kicks off the following network events.



VirusTotal Analysis of final payload “babawire.jar” confirms that it’s Adwind, a Java based Remote Access Trojan (RAT). Adwind RAT is a multifunctional malware program and it is distributed through a single malware-as-a-service platform.


This file is a compressed stream containing 168 files. It imports multiple java packages required for execution of the Trojan.




Current RSA NetWitness detection populates following meta for the download sessions:



Although we didn't achieve a full detonation in our own sandbox, post-infection traffic from populates following meta for the download sessions with Current RSA NetWitness detection:




More detailed information about CVE-2012-0158 can be found here:

Triaging Malicious Microsoft Office documents CVE-2012-0158 


Thanks go to Kevin Stear and Ahmed Sonbol for contributing to this threat advisory.





Filter Blog

By date: By tag: