The general public deserves less hyperbole and more straight talk
I must admit that I’ve grown increasingly weary over the constant harangue in the popular press about the ever-increasing volume and severity of “cyber attacks” worldwide. The apocalyptic language, the fear mongering, and the dearth of clear and simple explanatory language obscures an already complex topic. The general public deserves less hyperbole and more straight talk.
Don’t get me wrong. I’m not downplaying the threats we are facing. Advanced persistent threat actors are homesteading on sensitive federal agency and corporate networks. Cyber threats to industrial control systems (ICS) threaten to hold critical facilities and economic sectors at risk. Denial-of-service attacks, financial compromises, and intellectual property theft disrupt our economy and sow distrust in our banking and commercial sectors.
As analysts, we must better frame this public discussion. We can start by doing what we do best – defining and explaining the nature of the problem we confront. Commentators often lump together a wide range of malicious network activity as “attacks,” disregarding the fact that we can distinguish activity by type, intent, and degree. These differentiations matter; they speak to the nature and intent of the threat actors, which ultimately is what we should be most concerned about.
Espionage & Attack
Traditionally, we differentiate between espionage and attack, and we should do the same with network activity. When the Justice Department indicts a Robert Hanssen, or arrests a group of Russian “illegals” living in the United States, we do not characterize their espionage as “attacks.” Nor should we label the reported intrusions into the White House and State Department networks as “attacks,” lest we conjure up images of combat and destruction that are inappropriate to the event. Perhaps labeling every cyber incident as an “attack” advances some political or corporate purposes. As analysts with a professional commitment to critical thinking, we must play stronger roles in structuring this conversation in ways that advance our collective understanding.
Real network attack modifies the function of a network or a physical system that the network controls. We now witness first-generation network attack capabilities taking the field: industrial control system attacks in Iran (2010) andGermany (2014); and corporate network attacks in Saudi Arabia and Qatar(2012), South Korea (2013) and the United States (2014). Federal agencies and security firms continue to identify industrial control attack tools (some of which had gone unrecognized for years) that may reside on any number of sensitive control systems worldwide. Global proliferation of increasingly destructive network attack capabilities warrants serious attention and should be properly differentiated from espionage.
A Chinese hacker stealing intellectual property from a US defense contractor is qualitatively different from a BlackEnergy implant in a natural gas pipeline control system. Both are malicious activities, but differ substantially in intent and degree of potential impact.
Sometimes clear differentiation eludes us. Espionage and attack often employ similar means of ingress, exploitation, and persistent presence. Some operations—such as the Sony Pictures Entertainment hack—combined elements of both. These challenges should compel us to explore new ways to clearly identify and characterize cyber threats.
A way forward
As analysts with a dedication to tradecraft, we must seek out approaches that better differentiate malicious activity by type and intent. We must move the conversation past malware and digital forensics, which surely play a vital role in cyber intelligence but often offer limited explanatory power for key audiences. Most importantly, we must develop tradecraft that anticipates future threat environments, rather than simply describe and characterize present (or past) ones.
We should resist taking the bait that the popular press offers: to lump together all threat activities under one moniker of “attack.” Failing to offer at least some degree of activity differentiation only contributes to the malaise that strangles our general discussion on the nature of cyber threat.
Do not dismiss the general public as incapable of understanding the technical nuances of cyber threat activity. Our audiences are savvier than we give them credit for; to condescend to them or even write them off altogether is simply high-tech hubris. Even more important, popular understanding matters. An informed public discourse—the cornerstone of any democratic society—forms the basis for developing sound public policy. In our role as analysts, we owe this process the best of our tradecraft, our intellectual rigor, and simple clarity.
Michael McMahon is Director, Cyber Strategy and Analysis at Innovative Analytics & Training, LLC, a Washington, DC-based research consultancy and professional services firm. Mike is a 25-year veteran of the US intelligence community, serving most recently on the National Intelligence Council. He holds Master’s degrees from George Washington University and the National War College, and also serves as an adjunct lecturer in the Liberal Studies program at Georgetown University.
Mike brings his background in political science and international relations theory to the emerging discourse on role of cyber capabilities as an instrument of statecraft. He’ll be glad to get in your face on the problems of deterrence and the security dilemma in cyberspace, or how social contract theory can help us anticipate developments in global network governance, but don’t ask him how to fix your hard drive.
Many of today’s industrial control systems (ICS) are considered to be antiquated, making them vulnerable to a cyberattack, especially if they are interconnected with traditional information and communications technology (ICT). Think about electricity, water and energy production as typical places where ICS are in place.
The problem is that these ICS systems have been isolated—separate and apart from IT. But, in today’s converged system environment, ICS are becoming part of the greater enterprise. This makes ICS and IT vulnerable to the same threat agents and attack vectors.
Risk management and governance are critical, no matter if someone is responsible for defending the infrastructure of a manufacturing plant or the corporate network.
In fact, the current state of ICS cybersecurity is described as “turbulent,” according to ISACA’s new, comprehensive white paper about ICS and related risks, titled: “Industrial Control Systems: A Primer for the Rest of Us.”
The guide looks at the current environment of ICS, and discusses the differences and similarities between ICS and IT. The guide points out that while ICS people are operational in nature, IT professionals have a focus that is system or task- specific. An understanding of these cultural differences provides a context where it is possible to explore similarities and distinctions.
The guide suggests there are many advantages to creating and sustaining cross-functional teams of ICS and IT cybersecurity professionals, including:
Opportunity to for cybersecurity professionals to share their unique perspectives
An agreed understanding of risk management and governance
Establishment of a dialogue about shared assets and associated risks
The good news is that much positive work has already been done to create standards, offer training, hold conferences and create relevant certifications.
In recent weeks, Unit 42 has been analyzing delivery documents used in spear-phishing attacks that drop a custom downloader used in cyber espionage attacks. This specific downloader, Cmstar, is associated with the Lurid downloader also known as ‘Enfal’. Cmstar was named for the log message ‘CM**’ used by the downloader.
Unit 42 is aware of threat actors using two toolkits – MNKit and the Tran Duy Linh toolkit – to produce malicious documents that exploit CVE-2012-0158 in order to implant Cmstar. The Cmstar downloader itself has several unique and interesting features, as well as substantial infrastructure overlap with other tools worth discussing.
Manual Building of Import Address Table
The Cmstar downloader starts by manually building its import address table (IAT), much like shellcode would; however, it uses a rather unique technique. Instead of finding API function names based on their hashed values, this malware enumerates libraries’ export address table (EAT) and searches for the name of the API function the payload needs to load by using a character to offset array. The payload pairs several comma-separated lists of characters with comma-separated lists of numbers. Each list of characters consists of the set found within the API function name the payload seeks to add to its IAT, while the corresponding list of numbers specifies the offset in the function name where those characters should be placed. For example, if the payload has “D,e,A” paired with “0,5,19”, this results in the following mapping:
“D” at offset 0 in API function name
“e” at offset 5 in API function name
“A” at offset 19 in API function name
The payload loads a specific Windows library’s EAT by calling the ImageDirectoryEntryToData API function using the IMAGE_DIRECTORY_ENTRY_EXPORT flag. It then enumerates the library’s EAT to find exported function names by checking each function name for the character and the specific offset. Once found, the payload adds the address for the specific API function to its IAT. For instance, the payload checks the EAT of “wininet.dll” using the comparisons mentioned above to find the address to the “DeleteUrlCacheEntryA” API function. One specific Cmstar payload that we analyzed used the character/offsets seen in Figure 1 to locate the API functions within three different Windows libraries to build its IAT.
Library
Characters
Offsets
Function Name
wininet.dll
D,e,A
0,5,19
DeleteUrlCacheEntryA
e,O,A
3,8,12
InternetOpenA
e,C,A
3,8,15
InternetConnectA
p,O,A
3,4,15
HttpOpenRequestA
p,S,A
3,4,15
HttpSendRequestA
p,E,A
3,4,14
HttpEndRequestA
p,Q,A
3,4,13
HttpQueryInfoA
e,R,e
3,8,15
InternetReadFile
e,C,e
3,8,18
InternetCloseHandle
advapi32.dll
S,V,A
3,6,13
RegSetValueExA
C,s,y
3,6,10
RegCloseKey
O,K,A
3,7,12
RegOpenKeyExA
D,K,A
3,9,12
RegDeleteKeyA
D,V,A
3,9,14
RegDeleteValueA
U,r,A
3,6,11
GetUserNameA
v,t,S
3,6,12
ConvertSidToStringSidA
k,A,A
3,6,17
LookupAccountNameA
kernel32.dll
W,E,c
0,3,6
WinExec
C,M,A
0,10,17
CreateFileMappingA
U,V,e
0,5,14
UnmapViewOfFile
M,O,e
0,7,12
MapViewOfFile
Figure 1. Character and Offset Pairs Found in Cmstar Payload and the Resulting API Function Names
Cmstar Behavior
After manually creating the IAT, Cmstar decrypts its configuration, several encrypted strings, and a piece of shellcode. The embedded configuration contains nothing more than a URL that Cmstar uses as its command and control (C2) location. The encrypted strings within the Trojan include fields used within the HTTP requests that Cmstar will create to communicate with its C2 server, as well as additional strings used to interact with the registry. The Cmstar sample associated with the MNKIT delivery document creates the following registry key to automatically execute at system startup:
Unit 42 found an additional encrypted registry key that would allow Cmstar to automatically start up after reboots. However, the code does not decrypt, reference, or use the following registry key in any way, which suggests that the malware author left this artifact in the code after swapping to the run key listed above:
HKCU\Software\Microsoft\CTF\LangBarAddIn
Cmstar also decrypts a 752-byte piece of shellcode that carries out communications with the C2 server, specifically by sending HTTP POST requests to the following URL:
It should be noted that the C2 URL contains the string ‘cgl-bin’, which visually resembles the common cgi-bin folder used by many webservers to run server-side scripts. Unit 42 used the Palo Alto Networks AutoFocus threat intelligence service to locate additional samples using the ‘cgl-bin’ string within URLs of HTTP requests and found several samples of the Cmwhite tool associated with the LURID/Enfal downloader1, as seen in Figure 2.
Figure 2. Cmwhite Tools Using “cgl-bin” within HTTP Requests
Cmstar’s HTTP POST requests sent to ‘happy.launchtrue[.]com’ contain data that the Trojan gathers from the infected machine that has the following structure:
<Windows Version number>@@<CPU Architecture (2 for x64, 1 for x86)>??<boolean for elevated privileges>]]**<boolean if antivirus processes are found>!!<static version string>==
In one example, Unit 42 observed the following data within an analysis environment, which was then encrypted using a single-byte XOR algorithm and a key of 0x45 before being sent to the C2 server:
510@@1??1]]**0!!150316o==
Helpfully, the malware author writes log messages to the ‘DF64159.TMP’ file, used for debugging purposes throughout the execution of the Cmstar downloader. The log messages are abbreviated strings that describe specific activities during the execution of the code. For instance, the downloader uses the CreateMutex to create a mutex named ‘{53A4988C-F91F-4054-9076-220AC5EC03F3}’ to determine if another instance of the code is running. If the downloader determines another instance of itself is running, the code writes the string ‘CM**’ – which happens to be the basis for the name of the Trojan – to the log file. Unit 42 created a Yara signature to detect Cmstar samples based on these debugging strings, which is available in the appendix.
Hashing Process Names
As mentioned in the behavioral analysis section, the Cmstar downloader gathers system-specific information to send to the C2 server. One such piece of information is the existence of specific running processes. Many malware families and tools check for the existence of antivirus, but the Cmstar tool does so in a clever way. Rather than including a list of strings of associated processes, Cmstar enumerates the running processes and subjects these process names to a hashing algorithm. The results of this algorithm are then compared against three static values: 0x1E00AFA, 0xBEE091E8 and 0xD46FCDFA. Unit 42 reverse engineered the algorithm and created the function seen below to generate hashes in order to determine the processes Cmstar is trying to find:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
def hashStr(st):
hash=0
count=0
whilecount<len(st):
h1=(hash<<0x13)&0xFFFFFFFF
h2=(hash>>0x0d)&0xFFFFFFFF
h3=(h1|h2)&0xFFFFFFFF
hash=(h3+(ord(st[count])^0x4a))&0xFFFFFFFF
count+=1
returnhash
Unit 42 found that the string ‘avp’ subjected to the algorithm above results in the value 0x1E00AFA, which suggests the Cmstar sample specifically looks for Kaspersky’s Anti-virus product (avp.exe) running on the compromised system. If the Trojan finds processes whose hash matches the three values mentioned earlier, it sets a boolean value (the character ‘1’) within the data sent to the C2 server and continues carrying out its functionality. Rather than altering its activities, Cmstar only notifies the C2 server if a system is running one of these processes, suggesting that the threat actors might employ this technique as a filtering mechanism to ignore analysis systems and researchers.
Threat Infrastructure
In order to determine the intrusion set involved with the Cmstar, Unit 42 enumerated infrastructure used by the downloader for its C2 servers. The related infrastructure chart in Figure 3 shows a rather large cluster of related entities with one small set of entities that do not share any related entities with the larger cluster.
Figure 3. Infrastructure and Entites Related to Cmstar
As seen in the chart above, the C2 domain ‘happy.launchtrue[.]com’ was originally registered using the email address ‘WANGMINGHUA6@GMAIL[.]COM’. When Unit 42 used the Palo Alto Networks AutoFocus threat intelligence service to locate additional Cmstar samples, we found several with C2 domains that also had the same original registrant:
links.dogsforhelp[.]com
three.earewq[.]com
question.eboregi[.]com
here.pechooin[.]com
sarey.phdreport[.]com
bakler.featurvoice[.]com
The only known Cmstar C2 domain not initially registered by the email address was help.ubxpi0s[.]com. Further analysis revealed that additional domains related to Cmstar C2 domains were also originally registered using the email address ‘WANGMINGHUA6@GMAIL[.]COM’ and updated to the current information within a few days. In addition, this was the original registrant for C2 domain used in our Google Code blog2, indicating this registrant email is likely a re-seller, and/or someone who initially sets up infrastructure for particular APT threat actors.
forever.cowforhelp[.]com
question.shiesiido[.]com
endline.biortherm[.]com
right.marubir[.]com
baby.brabbq[.]com
lind.kruptcy[.]com
The rest of the domains related to the Cmstar infrastructure did not use the original registrant noted above, but instead kept the same information initially used to register them. The difference in domain registration patterns could indicate threat actor preference, or could indicate there are at least two groups using this malware whose infrastructure at times overlaps.
under.suttgte[.]com
help.ubxpi0s[.]com
finally.basiccompare[.]com
crystal.diskfunc[.]com
queenfansclub[.]com
novnitie[.]com
flash-vip[.]com
replyfunt[.]com
natcongress[.]com
keep.regebky[.]com
love.regebky[.]com
Interestingly, the updated registrant information (or original, in the cases where it wasn’t changed) for all of the C2 domains in this blog has also been used to register scam sites, most purporting to sell knock-off designer products like shoes, software, or cell phones. The contact emails and contact names can vary, but the address is re-used. Blue Coat noted this pattern as well in a blog published late last year, which also noted the ‘WANGMINGHUA6@GMAIL[.]COM’ registrant email.3 It is not known whether the threat actors conducting the malicious activity are also behind the scam sites.
Conclusion
The Cmstar tool has several interesting features, including a previously unseen method of manually creating its import address table using an API function name character to offset mapping techniques, and a hashing algorithm used to find antivirus processes on an infected system. Both of these features are noteworthy and may provide the ability to correlate future tools to the same group and/or malware authors.
The URL used by Cmstar to communicate with its C2 server, as well as significant infrastructure overlap, show a direct relationship between the Cmstar downloader, Lurid/Enfal and Cmwhite tools. In a majority of the cases, threat actors using the Cmstar downloader initially register the C2 domains using the email address ‘WANGMINGHUA6@GMAIL[.]COM’ and later change the registration information to include a different email address. Unit 42 cannot positively confirm that the threat actors control the ‘WANGMINGHUA6@GMAIL[.]COM’ email address, or if the email address belongs to a reseller that the threat actors buy domains from to create their infrastructure; however, we do believe this is an interesting TTP worth tracking in future infrastructure enumeration.
Filename: Какая реформа армии нужна Украине.doc (What is needed reform of the army Ukraine.doc)
MD5: 76ffb9c2d8d0ae46e8ea792ffacc8018
SHA256: c26c67eac20614038aaadfda19b604862926433333893d65332928b5e36796aa
Type: MIME entity text
Toolkit: MNKit
Author: User123
Last Saved By: User123
Created: 2012-05-01T14:08:00Z
Modified: 2012-05-01T14:12:00Z
Filename: запуск ракеты-носителя Союз.doc (launch of the carrier rocket Soyuz.doc)
MD5: 6fdeadacfe1dafd2293ce5c4e178b668
SHA256: e39b0e777ef0135c1f737b67988df70c2e6303c3d2b01d3cdea3efc1d03d9ad9
Type: Microsoft Office Word 97-2003 Document
Toolkit: Tran Duy Linh
Created: 2012:11:23 04:35:00
Modified: 2012:11:23 04:39:00
Company: DLC Corporation
Filename: РФ_КНР_сельское_хозяйство.doc (RF China Agriculture and Economy.doc)
MD5: 9da10a36daf845367e0fc2f3e7e54336
SHA256: a0aeb172a72442d2c2c02e1d32b48accb9975c4da7742df24d9350a8ccd401f2
Type: Microsoft Office Word 97-2003 Document
Toolkit: Tran Duy Linh
Created: 2012:11:23 04:35:00
Modified: 2012:11:23 04:39:00
Company: DLC Corporation
Filename: Ерөнхий сайд асан Н.Алтанхуягийг шалгаж эхэлжээ.doc (Former Prime Minister started to check with their lethargy.doc)
MD5: f7d47e1de4f5f4ad530bca0fc080ea53
SHA256: 4883286b8229a2c43db17eb1e1c5bd79d1933e840cdfedff80d5b99a84c9e39f
Type: Microsoft Office Word 97-2003 Document
Toolkit: Tran Duy Linh
Created: 2012:11:23 04:35:00
Modified: 2012:11:23 04:39:00
Company: DLC Corporation
Filename: запуск ракеты-носителя Союз.doc (launch of the carrier rocket Soyuz.doc)
MD5: 6fdeadacfe1dafd2293ce5c4e178b668
SHA256: e39b0e777ef0135c1f737b67988df70c2e6303c3d2b01d3cdea3efc1d03d9ad9
Type: Microsoft Office Word 97-2003 Document
Toolkit: Tran Duy Linh
Created: 2012:11:23 04:35:00
Modified: 2012:11:23 04:39:00
Company: DLC Corporation
Over the last few years, we’ve increasingly seen a number of products claiming to be “next-generation.” This message is now so frequently used, it’s difficult to really understand whether the message has gotten lost in the technology or vice versa. What makes something “next-generation”?
To quote from my favorite college-unapproved secondary source, Wikipedia, which takes their definition for Next-Generation Firewalls from this article written by Eric Geier of eSecurity Planet:
From this definition, next-generation products appear to be those that are natively built within the same platform or device, can identify applications regardless of port or protocol,operate in Layer 7, and can integrate with other software that maps IP addresses to actual users on the network.
But this brings me to my next question: What’s the difference between traditional IPS and “next-generation” IPS, or NGIPS for short?
The description above would indicate that NGIPS is part of a next-generation security platform, sharing context-aware features with the firewall, such as application and user awareness, improved threat prevention performance, and log correlation. In short, they’re much better than traditional IPS at understanding malicious traffic.
NSS Labs has designed a test for NGIPS products, which Palo Alto Networks participated in recently. In their methodology overview, NSS sets forth this requirement for NGIPS devices:
“…next generation intrusion prevention systems (NGIPS) must provide organizations the ability to identify both the applications and the users on their internal networks.”
The importance of application and user awareness is paramount, as these are what basically turn an IPS into an NGIPS.
First off, it helps to enforce application- and user-specific policies. For example, JDoe should have access to this application but only in these specific ways — anything outside this is prohibited. An NGIPS can help you do this.
Secondly, application and user awareness make heuristics much more useful. These features make your IPS smarter so that it knows what “normal” traffic looks like for each application, and alerts you to anything that falls outside that pattern.
Any vendor who boasts an NGIPS product must be able to employ these features realistically for the customer. This means providing NGIPS capabilities while maintaining performance that reasonably fits the customer’s throughput needs, and doesn’t sacrifice 80 to 90 percent of throughput when these “next-generation” features are turned on. You can’t claim to be serious about security and promote these features if customers can’t really use them in a meaningful way.
Although the platform component is a key improvement in intrusion prevention, as it effectively consolidates multiple security features and makes them easier to deploy and manage, not every customer in the market for IPS necessarily needs all of these bells and whistles.
Internal IPS deployments are sometimes stand-alone, segmenting the network or protecting data centers. These stand-alone deployments are where “next-generation” features like application and user awareness are most needed.
In today’s world of devious attackers and sophisticated threats, hiding in plain sight – within the very applications that enable businesses to become more productive – is a tactic cyber criminals are using to successfully infiltrate organizations. Only a smart IPS, one that’s truly “next-generation,” is equipped to prevent these threats and level up enterprise security.
Information is powerful. In today’s fast-moving world, timely information is critical to keeping cybersecurity plans and programs current.
But, having the time and diligence to filter massive amounts of information to a digestible, actionable form is nearly impossible. Besides myriad global regulations and other developments, all manner of cybersecurity breaches are frequently in the news. In fact, the growing rate of breaches around the world has organizations preparing for when they will be attacked, rather than wondering if they will be.
To provide a concise source for the industry trends and latest developments cybersecurity experts need to know about most, ISACA has launched a new free newsletter. The Nexus, which is part of ISACA’s Cybersecurity Nexus (CSX) program, features original CSX thought leadership and knowledge, news and updates related to cybersecurity, and a collection of cybersecurity articles from around the web .
Recent articles in The Nexus include:
Cybersecurity table stakes for companies: The bare minimum needed to survive by Doug Steelman.
5 Costly consequences of SMB cybercrime from CIO Magazine.
Simple steps go a long way in cybersecurity by Rolf von Roessing, CISA, CISM, CGEIT
Visit The Nexus subscription page of the ISACA web site to subscribe to this valuable monthly e-newsletter.
Robert E Stroud, CGEIT, CRISC
ISACA International President
