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

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.




RSA FirstWatch would like to thank the Target Cyber Threat Intelligence & Detection Team for sharing technical insight into the topic of this post.


Well into the holiday season, people are making their shopping lists, recovering from Black Friday and Cyber Monday, and perhaps contemplating the many things for which they are grateful.  Criminals, too, are making their lists, and posturing for the big shopping days ahead. 


Threat researchers are still at work of course, so it was inevitable that FirstWatch contemplated which things credit card stealing criminals--AKA “carders” appreciate.  This is what we came up with.


What carders are thankful for this year

1. Malicious code and techniques shared by other criminal developers
2. Merchants that still use swipe-only Point of Sale (POS) systems
3. Merchants with POS systems that lack Point-to-Point (P2P) encryption of payment card data
4. Merchants that employ antivirus easily bypassed by unsophisticated malware


With a combination of one or more of these carder’s favorite things, intruders have stolen payment card data associated with millions of consumers (like us), resulting in tens of billions of dollars of losses annually.[i]


We would like to illustrate a carder’s favorite thing number four with a sample of malware uploaded to the VirusTotal website on Tuesday morning, 21 November 2017, detected by zero out of 65 different antivirus vendors (Figure 1).


Figure 1 Zero detection POS RAM-scraping malware uploaded to VT


Certainly this won’t be the last POS malware not detected (statically and initially, at least) by any antivirus, nor is it the first. Consider the analysis of the zero detection Getmypass POS malware by Nick Hoffman during the holiday season three years ago[ii]


“While this isn’t the most advanced POS RAM scraper there is, it’s still capable of bypassing all 55 AV’s used to scan it.”

Three years later, there are now ten more antivirus vendors represented on VirusTotal, whose static scans are still bypassed by this recent iteration of payment card information stealing malware.


By their very nature, merchant POS intrusions are rather targeted, and if the minimal barrier to installation of their payment card collector/exfiltrator is an antivirus, merchant intruders so far continue to effectively bypass that minimal barrier.


FirstWatch would like to use this post to expose this particular campaign that unfortunately has been active since at least February of this year, with indications that thousands of credit card numbers from targeted merchants are being exfiltrated to the perpetrators at this very moment.  With any luck, we hope to make this perpetrator’s holiday season perhaps a little less enjoyable than yours. Will use some of the tools at our ready disposal, namely NetWitness and What’s This File, to peer into its behavior.


This malware is a variant of FrameworkPOS, and shares some code with other POS malware families variously known as TRINITY, BlackPOS, and BrickPOS, so we have decided to call it GratefulPOS, because, well, tis the season.


A set it and forget it stealer, not a controller

This is a tool designed to scrape and exfiltrate payment card information from one or more processes in use by a Windows-based Point of Sale system, from probably a wide variety of POS vendors.  Compiled for x64 architectures, we can assume that this malware is designed to run on POS systems running Windows 7 or later. It has no command and controller capability itself; the perpetrator uses other means of privileged access to install and execute the malware on the target POS systems.


GratefulPOS has the following functions

1. Access arbitrary processes on the target POS system

2. Scrape track 1 and 2 payment card data from the process(es)

3. Exfiltrate the payment card data via lengthy encoded and obfuscated DNS queries to a hardcoded domain registered and controlled by the perpetrators, similar to that described by Paul Rascagneres in his analysis of FrameworkPOS in 2014[iii], and more recently by Luis Mendieta of Anomoli in analysis of a precursor to this sample[iv].


GratefulPOS WTF Score

A high threat score of 80 is computed when GratefulPOS is submitted to RSA What’s This File (, Figure2)


Figure 2 GratefulPOS scores a high 80 on WTF


NetWitness Endpoint and GratefulPOS

The GratefulPOS sample was executed on a renamed but otherwise stock Windows x64 VM running NetWitness Endpoint, and analyzed through the NWE UI. 


The malware installs itself as persistent Windows service, with a legitimate sounding name “TrueType Fonts Management Service” (Figure 3).


Figure 3 GratefulPOS Windows service


Combined risk and Instant Indicators of Compromise (IIOC) score rose significantly from 23 (Figure 4) to 159 (Figure 5) after the malware installation.


Figure 4 NetWitness Endpoint before GratefulPOS execution


Figure 5 NetWitness Endpoint score after GratefulPOS execution and installation


NWE reveals the process memory scraping activity typical of RAM-scraping POS malware, by tracking GratefulPOS’s access to consecutive processes on the system in the Tracking panel (Figure 6).



Figure 6 GratefulPOS process memory scraping observed in NWE tracking panel


More credit card numbers, more DNS traffic

GratefulPOS has a simple and efficient method of exfiltrating scraped payment card data to the perpetrator by means of DNS queries to a malicious controlled domain and DNS name server daemon.  This method can typically bypass firewall and other enclaving set up on a merchant’s POS network infrastructure because the compromised POS system does not need to communicate directly to the Internet.  It can just as easily communicate to an internal DNS server on the merchant’s network, which would presumably pass on the payment card data encoded in the DNS queries, to the perpetrator.


We observed the initial DNS “check-in” beacon communication on our test system in NetWitness Packets, that sent information about the compromised system to the perpetrator.



44105+ A? (166)



44105 1/0/0 A (182)


Beacon communication was to a public DNS server (lower part of Figure 7), however, it could have been to an internal DNS server, further hiding its origins on a large enterprise network by the time it leaves the perimeter.


Figure 7 GratefulPOS malware initial DNS beacon communication to public DNS server


To add insult to injury, the domain was not selected at random.  It was designed to mimic legitimate DNS queries typically encountered in volume on large enterprise networks, associated with the large Content Delivery Network (CDN) service Akamai.  We have reached out to Akamai with this information.


We used NetWitness Packets to observe GratefulPOS perform a web check-in to the malicious name server on port 80.  The web server responded with a page that displayed the compromised system’s public IP address (Figure 8).


Figure 8 NetWitness 11 display of GratefulPOS malware web check-in with public IP response in body


It appears that the malware developer created their own IP information service, perhaps to help them organically track the source and public network infrastructure of their targeted POS systems, rather than using one of the many free services available such as, or


We also generated a few hundred fake credit card numbers and formatted them as would be encountered on a real POS system, and observed via NetWitness as the payment card information flew out the door via encoded DNS to the still clearly active exfiltration node (Figure 9).


Figure 9 GratefulPOS exfiltrates credit card numbers as observed with NetWitness


Compared to the sample analyzed by Mr. Mendieta of Anomali in 2015, we observed only minor code changes.  Instead of the particular campaign specified by “grp” strings, we see “v1702” is the campaign identifier, as displayed in an exfiltration packet (Figure 10).


Figure 10 Encoded Track 1 data with campaign identifier "v1702" as observed in NetWitness 11 event analysis


Implications and Conclusions

As Paul Rascagneres suggested, this DNS exfiltration method employed by the POS malware is clever.  It effectively negates a common POS system control employed by payment card merchants, which is blocking direct access to the Internet from the POS systems.  If the POS systems point to internal DNS servers, this malware should have no problem exfiltrating credit card data en masse without direct connect to the Internet.


Keen visibility of enterprise endpoints and network traffic allows an analyst to detect business and customer-critical threats not otherwise detected by antivirus. Hardware-enabled Point-to-Point encryption of payment card data would prevent RAM scrapers like FrameworkPOS and GratefulPOS from working at all. In absence of that, one strategy as mentioned by Mr. Rascagneres from GData includes DNS domain whitelisting of only necessary domains needed for POS function.


Indicators of Compromise

The exfiltration domain and current exfiltration DNS server IP address have been added to the RSA FirstWatch C2 Domains and IPs feeds.


Table 1 GratefulPOS Indicators of Compromise

GratefulPOS MD5


GratefulPOS exfiltration domain 

Current Exfiltration DNS server








Last month, security researchers at Embedi disclosed a new vulnerability in Microsoft Office suite. CVE-2017-11882 resides in the Microsoft Equation editor; a tool that lets users insert and edit mathematical equations inside office documents [1]. If exploited, the vulnerability allows the attacker to run arbitrary code in the context of the current user. Microsoft issued a patch to address the vulnerability in the affected products [2][3]. It didn't take a lot of time to start seeing malspam campaigns trying to leverage CVE-2017-11882 to deliver their final payload as discussed in this blog post by Fortinet.


One of those delivery documents is PI-5460-DPC.doc. In this threat advisory we will go over the host and network behavior using NetWitness Packets and NetWitness Endpoint.


Upon opening the document in a vulnerable Microsoft Word, the vulnerability is exploited and an instance of the vulnerable Equation tool (eqnedt32.exe) is created by svchost.exe:



That is followed by a GET request to retrieve a javascript script:



eqnedt32.exe calls mshta.exe to execute the downloaded script:



When mshta.exe runs, it calls cmd.exe to write a script (A6p.vbs) to the infected machine. wscript.exe runs the newly created script which has the instructions to download the final payload:





The downloaded binary is executed and it starts to communicate with its command and control server:






The post infection traffic is characteristic of dyzap malware (also known as Lokibot). RSA FirstWatch blogged twice about its activity here and here.


Here is a recap of the network activity:



And here is a recap of the host activity:



Thanks to Kent Backman and Justin Lamarre for contributing to this threat advisory.


PI-5460-DPC.doc (SHA256):

  • 3917474eb4b2dd52aad96b76228304b692031180a55f59346808e797ea332305


fafa.exe (SHA256):

  • 1c71868cf97ee2f713d1a445f650d7a829c80e49c529be5bffb3091a3059ff23





RSA Incident Response White Paper: Inside the Response of a Unique CARBANAK Intrusion 


RSA Incident Response and Discovery Practice (RSA IR) analysts spend a significant amount of time engaged in the research, hunting, and effective response of advanced and persistent actors.  A customer engagement early-to-mid-2017 is an excellent example of a unique case in which RSA IR successfully responded to an intrusion perpetrated by the threat actor group CARBANAK, also known as FIN7.  The CARBANAK actions illustrated in this post and associated paper were observed with other RSA clients as recently as November 2017, with the methods and intelligence supplied by these publications having been used successfully to detect and track attacker activities.


Several intrusions associated with the CARBANAK actors have been reported within the last year, describing compromises of organizations within banking, financial, hospitality, and restaurant verticals.  However, they all describe a relatively equivalent progression, with only slight deviation in specific attacker actions.  The intelligence surrounding recent CARBANAK incidents indicate that phishing attacks have been the group’s primary method of initial compromise.  After gaining access to a user system, the attackers move laterally throughout the environment, conduct internal reconnaissance, establish staging points and internal network paths, harvest credentials, and move towards their intended target. However, this intrusion began with a significantly higher level of privilege due to the exploitation of the Apache Struts vulnerability CVE-2017-5638 allowing the attackers to quickly gain administrative access within the client’s Linux environment.  This intrusion presented substantial challenges due to:

  • The initial intrusion vector
  • Unique attacker toolset
  • The attacker dwell time
  • The large, heterogeneous environment
  • The speed with which the attackers gained administrative access
  • The forensic mindfulness of the CARBANAK attackers

The attackers’ toolset was a mix of custom tools, freely available code, and open source software utilities.  RSA IR researched all 32 of the malicious files in the CARBANAK toolset using various publicly available and open-source resources.  Six of the tools used in this intrusion were found to have been uploaded to a publicly available anti-virus aggregation site. Of these six, five have little-to-no detection or indication of malice from antivirus vendors.  This observation explains why the client’s signature-based host protection mechanisms were unable to identify or prevent the use of these tools.  

Figure 1: Findings from Public and Open Source Research of Toolset Reference

While the attackers used more than 30 unique samples of malware and tools, they also demonstrated a normalization across Windows and Linux with respect to their toolset.  The toolsets they deployed can be broken down into five basic functionalities:

  • Ingress/Egress/Remote Access
  • Lateral Movement
  • Log Cleanup
  • Credential Harvesting
  • Internal Reconnaissance

The ingress, lateral movement, and internal reconnaissance mechanisms used by the attackers during this investigation were not that sophisticated in and of themselves.  However, when viewed in aggregate, and from an operational view, RSA observed the actors normalized their choice in toolset across the Linux and Windows environments.  The attackers in this engagement primarily used modified versions of legitimate administrative tools, commonly used penetration testing utilities, and common network file acquisition tools.  Though specialty malware was observed during this intrusion, the attackers used basic XOR encoding just above Layer 4 to facilitate communication, communicated via SSH tunnel directly over TCP/443, or just transmitted and received data in clear text across the network.  Of the observed actions during this intrusion, none of the attacker tools, techniques, or procedures were particularly advanced.  However, they were still able to bypass a significant security stack, obtain initial access and lateral access effectively, deploy malware and toolsets with impunity, and traverse over 150 systems in the span of six weeks.  While, at first glance, this attack was not sophisticated in its toolset, it was sophisticated in its operationalization and agility of attackers’ actions.  The correlations between the Linux environment tools and the Windows environment tools are shown below:

Cross-Platform Toolsets and Purpose





Tinyp (PSEXEC Variant)

Lateral Movement

Auditunnel (Linux Version)

Auditunnel (Windows Version)

Ingress Tunneling

PScan (Linux Version)

PScan (Windows Version)

Internal Recon

WGet (Linux Version)

WGet (Windows Version)

Toolset Download



File Transfer

RSA IR released a white paper containing an in-depth review of this engagement, including observed attacker operational patterns, TTPs, and the techniques used during this engagement to successfully track and respond to the threat.  The observations illustrated in this paper identify that not only do CARBANAK actors have the capability to successfully compromise various operating system environments, they have standardized and operationalized this capability.  This attribute indicates strategic operational thought and effort being invested in this group’s compromises, suggesting that the CARBANAK actors are working towards becoming a more organized, structured, resourceful, and mature threat group.

During an intrusion, time is the single most critical resource to an organization’s security team and is the most significant indicator of determining if the security team will be successful in containing, eradicating, and remediating the extant threat.  There are two specific sets of time related to an intrusion that may determine the difference between success and failure: the time that the attackers are in the environment prior to detection (dwell time), and the time it takes security teams to identify, investigate, understand, and contain the attacker’s actions (response time).  In this specific incident, the attacker’s dwell time at intrusion declaration was 35 days, which is a significant amount of time given the level of access immediately available upon compromise.  However, by utilizing the methodology and visibility described in this paper, RSA IR was able to complete containment, eradication, and remediation in only nine days.  We also discuss the methodology used by RSA IR to successfully detect, investigate, understand, and contain the attackers before the actors could achieve their intended goal.

The CARBANAK actors not only showed the capability to successfully compromise both Linux and Windows systems, they chose a toolset that was either directly cross-platform or extremely similar in both function and command line usage.  This indicates a level of tactical organization and operationalization not previously observed by this actor group.  Additionally, they were significantly cognizant and aware of actions taken by the security team, switching to new methods of ingress after initial compromise, detected remediation actions, and environmental migration.  They were methodical in their choice of staging systems, basing the system utilized on:

  • a critical function of lateral access
  • or responder detection and investigation

They chose key systems based on their needs rather than systems the organization would consider ‘key’ assets. They ensured the toolsets they would interact with most often contained very similar functions and commands across environments in order to limit mistakes made at the keyboard.  They included a method, whether manually or automatically, to remove any record of their activities.  They operated with purpose, patience, planning, and most significantly, persistence.

This intrusion was successfully discovered, investigated, contained, eradicated, and remediated only due to the following reasons:

  1. The organization invested in the necessary visibility at a host and network level to allow analysts to rapidly and effectively hunt for and investigate these types of threats.
  2. The organization had invested and empowered their personnel to creatively and proactively hunt for, understand, investigate, and learn from threats within their environment.
  3. The organization had maintained a relationship with a proven and trusted advisory practice and had worked to recreate and implement a solid and proven Threat Hunting and Incident Response methodology within their own organization.
  4. The organization had a solid top-down understanding of what role Threat Hunting and Incident Response held during daily operations and security incidents, and provided the necessary support and enablement to subordinate units and analysts.

While a first look at the tools used in this engagement may appear simplistic, upon review of the entire intrusion, it becomes quickly apparent that each of them was purpose-chosen with an overall operationalized capability in mind.  CARBANAK has shown themselves to be a coordinated and extremely persistent group of actors that are consistently moving towards more agile methods of intrusion and standardization of processes across heterogeneous environments.  They have proven their capability to use that persistence and agility to defeat or bypass organizational security controls.  Even with the least advanced of their capabilities, they can be a difficult adversary to track within an environment due to their speed, efficiency, adaptability, and care in leaving little trace of any activity.  However, this difficulty compounds exponentially for organizations without the necessary visibility, practices, methodologies, or trusted partner relationships necessary to effectively detect and respond to these types of threats.  This white paper shows that with the necessary visibility, planning, methodology, and analyst enablement, organizations can be successful against these types of threats.


Learn more about the Carbanak/Fin7 syndicate based on unique Carbanak intrusions, and the mindset and methods used to combat them in these recent RSA Research publications.

RSA NetWitness® Suite Certified for U.S. Department of Defense Information Network UC APL


The RSA NetWitness Suite is an evolved SIEM that meets all joint interoperability requirements in accordance with the unified capabilities requirements.  To receive this certification, products undergo rigorous testing to determine compliance with the DoD security functional requirements and security best practices. Due to the DoD’s extensive testing criteria, international agencies, governments and corporations with strict requirements often look to the DoDIN APL when considering SIEM solutions for their short list.  


This certification is a relevant differentiator for the government sector and other sectors who seek validation of vendor capabilities.


Currently, the RSA NetWitness Suite is the ONLY evolved SIEM providing visibility and threat detection across logs and network data in a single unified platform currently on the list. The DoDIN APL approval of the RSA NetWitness Logs and Packets Rel. 10.6.3 TN 1628501 as an Intrusion Detection and Protection System (IPS/IDS) document is posted on the DoDIN APL site


The DoDIN press release has more details.

Every year Symantec and McAfee and others provide research on the top shady domains on the internet based on TLD's.  With the increase in vanity TLD's the options increase to registering domains quickly with potentially little oversight and security.


How can we use this knowledge in NetWitness to detect when traffic may be accessed or looked up to these potentially shady domains?


White papers:


Larger list of extracted domains and use-case


The description of the yml seems like a good place to start


description: Detects download of certain file types from hosts in suspicious TLDs 


we will focus on the first part of detecting the TLD communication, the second part would be a simple application rule to wrap that data up.


With some notepad++ magic we get a list of domains and other information:




Now we create a feed xml file to make mapping this information easy


<?xml version="1.0" encoding="utf-8"?>
<FDF xmlns:xsi="" xsi:noNamespaceSchemaLocation="feed-definitions.xsd">

<FlatFileFeed comment="#" separator="," path="feed-sigma-proxydownloadsusptldsblacklist.csv" name="unified">

<MetaCallback name="InspectMeta" valuetype="Text" ignorecase="true">
<Meta name="tld"/>

<LanguageKey name="analysis.session" valuetype="Text"/>
<LanguageKey name="threat.category" valuetype="Text"/>

<Field index="1" type="index" key="InspectMeta"/>
<Field index="2" type="value" key="analysis.session"/>
<Field index="3" type="value" key="threat.category"/>


Now create the feed and push to decoders

We will look for matches in our feed from the TLD metakey and write into analysis.session and threat.category

Those events can now be wrapped into an apprule if looking for specific downloads from those TLD's or can be leveraged in ESA rules.



name="suspicious_download_shady_domain" rule="analysis.session='suspect_tld' && extension='exe','vbs','bat','rar','ps1','doc','docm','xls','xlsm','pptm','rtf','hta','dll','ws','wsf','sct','zip' " type=application alert=eoc

By Kevin Stear, Justin Lamarre, Ahmed Sonbol and Kent Backman




On November 14th 2017, the US-CERT released two Technical Alerts (TA17-318A and TA17-318B) on North Korean government cyber activity, aka HIDDEN COBRA, behind broad targeting of multiple sectors in Asia and the West.  Both Symantec and Novetta have also previously documented prior campaigns by this nation-state actor, with follow-on analysis by Bluecoat and others.


FirstWatch assesses that HIDDEN COBRA high-level objectives include acquisition of hard currency, access into high value networks for later stage strategic effects, and collection of sensitive information (i.e., espionage).  HIDDEN COBRA leverages compromised third party systems as operational relay and exploitation nodes, and delivers malware via drive-by download, spear phishing, watering hole and supply-chain attack methods.



Current campaigns by this Advanced Persistent Threat (APT) group have focused on delivery of the VOLGMER Backdoor, FALLCHILL Remote Access Trojan (a relative of DESTOVER), and most recently Android malware.  As these malware are discussed in detail in previous US-CERT and Industry reporting, this blog will instead focus on detection of HIDDEN COBRA malcode in the NetWitness Suite.


It is important to note here that this HIDDEN COBRA malware does demonstrate a somewhat impressive level of technical sophistication.  In addition to the use of DLLs for process injection, the malware has significant VM evasion and sleep/delay capabilities (Figure 1).


Figure 1. VOLGMER's long and random sleep routine


Despite some of this complexity the VOLGMER executable has a number of blank file property fields, which are often good indicators of maliciousness (Figure 2).


Figure 2. Unusual empty file property fields in VOLGMER backdoor dropper


NetWitness Detection of HIDDEN COBRA

Perhaps the most easily recognizable sign of HIDDEN COBRA activity in network is the fake TLS handshake used for Command and Control (C2) in several strains of the APT group’s malware.  This activity is detected in NetWitness Packets as an alert on “unknown service over SSL port” as demonstrated by traffic from a machine infected with FALLCHILL (Figure 3).


Figure 3. Non-SSL C2 traffic of FALLCHILL malware flagged by NetWitness


NetWitness Endpoint also detects FALLCHILL by noting the malware’s unsigned process and network activity (Figure 4), which correlates to the traffic observed in NetWitness Packets in Figure 1.


Figure 4. HIDDEN COBRA FALLCHILL malware as observed in NetWitness Endpoint


For activity associated with the VOLGMER Backdoor, the NetWitness Suite also provides several means of detection.  The most consistent artifact in samples identified thus far is the “Mozillar” browser compatibility identifier name (it should be Mozilla) within user agent (UA) strings seen in the initial C2 check-in/beacon (Figure 5).  


Figure 5. Telltale "Mozillar" User Agent identifier in VOLGMER beacon


VOLGMER also employs a number of seemingly random UA strings for this C2 function.  While it is unclear the purpose of these variances, we observed six completely different UA strings and varying HTTP headers over a few seconds from a single infected machine (Figure 6). 


Figure 6. VOLGMER's jumbled HTTP connections upon initial C2 check-in 


Examination of the codebase indicates that nine different UA strings may be used for the C2 check-in (Figure 7).


Figure 7. Various User Agent strings employed for VOLGMER C2 beacon as seen in malware code


Advanced features in the NetWitness Packet’s HTTP_Lua parser provide additional indications for this VOLGMER activity with meta tagging in the service.analysis field for “not good Mozilla” and “http 1.0 unsupported connection header”.  These tags should be signs to the security analyst that something is not right and worthy of immediate investigation (Figure 8).


Figure 8. Suspicious HTTP artifacts flagged by the HTTP_Lua parser in NetWitness


NetWitness Endpoint also provides indications of VOLGMER infections by flagging the process responsible for the malware’s C2 behavior that uses contrived host headers with random domains (Figure 9).  This is well described in the Volgmer analysis report (MAR) from the US-CERT.



Figure 9. VOLGMER C2 check-in with unusual crafted HTTP artifacts and domains



HIDDEN COBRA has historically been often dismissed as a top tier threat group; however recent activity demonstrates the APT group’s ability to compromise a broad assortment of direct and indirect targets using above-average (and improving) malware development and deployment capabilities.  


While it is likely that HIDDEN COBRA will continue to harvest new infrastructure for use in ongoing campaigns, all existing Indicators of Compromise (IOCs) from US-CERT reporting as well as IOCs related to the group’s Android malware targeting Samsung users (reporting by McAfee and Palo Alto Unit 42) have been incorporated into RSA FirstWatch’s Third Party domain and IP address feeds since November 15th.


IOCs are increasingly perishable (especially from advanced actors) and limited in their effectiveness, and analysts should also leverage NetWitness and the techniques described in this post to identify any HIDDEN COBRA-initiated malware and related infrastructure that has yet to be identified.


HIDDEN COBRA meta values:

threat.source = ''

threat.category = ‘hiddencobra’

threat.description = ‘volgmer’ or threat.description = ‘fallchill’


Filter Blog

By date: By tag: