Every day, in every corner of the world, at every minute, small- and medium-sized enterprises (SMEs) are opening up stores, serving clients, delighting customers (or not). And while the classic SME picture may be the storefront, SME reality means constant commerce, updating web presences to buy, sell and service everything; work that begins before dawn and ends long after night has fallen.
While precise measurements are difficult due to differing definitions of SMEs, research by the World Bank has indicated that these vital enterprises employ more than half of all private sector workers globally, and can comprise more than 90% of all the world’s existing businesses. In the United States alone, the U.S. Small Business Administration has estimated that the number of SMEs currently operating in America exceeds 28 million firms.
These entrepreneurs and service sector employees share common characteristics—incredible dedication, a belief that what they do is valued by their communities, and the hope that their hard work will adequately provide for their families, and their families’ futures.
Regrettably, however, many SMEs have something else in common—minimal or nonexistent protection from cyber threats and attacks.
Effective cybersecurity is paramount to the success of any business, regardless of size, as it pursues growth and prosperity within a global and increasingly digital marketplace. According to global estimates released by security company Symantec, spear-phishing attacks against SMEs have more than doubled in only a few brief years, rising from 18% in 2011 to 43% in 2015.
For some SMEs, though, this digital economy brings with it some difficult choices. A number of SMEs around the world find themselves in the unwelcome situation of being forced to choose between incorporating adequate cybersecurity into the digital and wireless aspects of their business, or not doing so. All too often, due to business or personal factors, SMEs choose the latter.
This may not be possible in the future. As our digital economy evolves, a lack of cybersecurity for an SME poses increasing risk. Cyber insurance, available and in use by larger-scale organizations, should be more of an option for, and optimized by, SMEs. More direct impacts, such as breaches of an SME’s digital infrastructure leading to the release of financial or personal information, or attacks that create a back door into another company, will have consequences. Minimally, this hurts reputations and relationships, as customers and vendors think twice before patronizing the SME again. On the other side of the spectrum, the business does not recover, and is shuttered. None of this bodes well for SMEs that lack effective and robust cybersecurity.
There are efforts underway to address this. New Jersey’s recently appointed CTO, David Weinstein, is creating a resource for New Jersey’s SMEs to keep abreast of developments in both cybersecurity and the threat landscape, an effort that complements the ongoing cybersecurity education efforts of the U.S. Small Business Administration. We see an increasing number of Information Sharing and Analysis Centers (ISACs) in the United States making similar resources available to SMEs within their respective industries. In the European Union, ENISA is leading efforts to ensure that the knowledge gleaned from ISACs finds its way to the SME community as well. All of these efforts are commendable, for they provide SMEs with valuable tools to aid them in ensuring the cybersecurity of their digital businesses.
Yet, these efforts have not and will not reach every SME. Leaving one business or agency behind in the quest for greater cybersecurity for their digital enterprise efforts is unacceptable. The aforementioned efforts, already underway, must be built upon. Chambers of Commerce at the local, regional and national levels must begin to offer resources to secure the digital business of SMEs. More ISACs need to become involved. Governments, at all levels, need to find additional ways to create and support efforts that will aid in securing the digital futures of SMEs.
ISACA’s global community must do its part, as well. We know some ISACA chapters have begun outreach to local SMEs. This is excellent and to be commended—but efforts must grow. We urge all ISACA chapters reach out to local, regional and national SME-focused organizations, and to partner in efforts to increase and enhance cybersecurity within this crucial sector of the digital economy.
Likewise, we urge our colleagues within the NGO community to engage in similar efforts; and we pledge to help you with subject-matter expertise, tools and experience. Several NGOs have already taken steps to aid the SME community, all admirable efforts. Taken in sum, the NGO cybersecurity community has presences in nearly every nation in the world; our non-profit sector has an opportunity to effect global, positive change within the SME sector, as well as within the wider international digital marketplace.
It is incumbent, upon all of us within ISACA and with the wider NGO community, to share our expertise with the SME community. Enterprises of all sizes can and will benefit markedly from this interaction, and will be further empowered to realize the positive potential of technology, and reap the benefits of security in our evolving global digital economy.
Matthew S. Loeb, CGEIT, FASAE, CAE, Chief Executive Officer of ISACA
Threat actors tend to reuse certain tools, a trend we observed during recent Unit 42 research published on MNKit. In this post, we will discuss a fresh toolkit, which on the surface, appeared similar to MNKit, but functionally was found to be quite different.
This toolkit, which we named “HOMEKit”, is similar to MNKit in that it is also designed to generate weaponized Microsoft Word documents containing an exploit for CVE-2012-0158, but it uses OLE instead of MHTML files. In addition, we have been able to track the use of HOMEKit by its operators since 2013 across a variety of campaigns, using several different variants of the toolkit. For this post, we will be focusing on the most recent example of the HOMEKit toolkit, in addition to an interesting overlap we discovered with the well-known attack campaign DarkHotel. In a follow-up post, we will discuss the other campaigns associated with HOMEKit, along with other variants of HOMEKit that we discovered.
In addition to analysis of HOMEKit, we will also examine a new payload we discovered embedded in one of the malicious documents created by HOMEKit, which we have named “Cookle.” It is a fairly simple downloader tool, but until now has not been publicly discussed. Cookle deploys some interesting tactics to obfuscate its activity.
Telemetry
In late June 2016, we collected an e-mail file (Figure 1) that appeared to carry a phishing attack with a malicious file attached. The sender address was spoofed, using the identity of a coordination associate for the United Nations Environment Programme (UNEP). The content of the email seemed legitimate, using the subject line of “Pyongyang International Phonebook and Mailing lists – JUNE,” attempting to appear as a global directory for residents of the Democratic People’s Republic of Korea under UNEP. To further increase the legitimacy of the phishing attack, the threat actor copied the coordination associate’s signature block as well.
The email contained two file attachments, a Microsoft Word document and a Microsoft Excel document. The Excel document proved to be benign, but the Word document exploited the CVE-2012-0158 vulnerability. If the victim were to open the Word document, it would silently install the Cookle Trojan, while opening a decoy document in Word (Figure 2), displaying the expected content to the victim.
Figure 2 Decoy document containing message intended for residents of Pyongyang
The benign Excel document and the Word document used as decoys both appeared to be legitimate, internal documents; the Word document containing the email addresses of all DPRK UNEP residents, along with mailing lists to use for specific topics. The Excel document contained additional contacts for other related agencies, in addition to emergency contact information for the DPRK UNEP residents. Examination of the metadata of the two files revealed the Excel document was last modified by the spoofed sender’s identity on June 22, 2016, while the decoy Word document showed the original author as the Coordination Officer in 2012, with a creation timestamp of July 19, 2012. The “last modified” field of the decoy document though revealed its true nature, showing that it was last modified on April 5, 2016, by “Windows User” indicating the decoy document was likely to be last modified by the threat actor.
By using the specific documents observed in this attack, the threat actor demonstrated that he or she may have already gained unauthorized access to some extent. Also, the contents of these internal documents show that the threat actor currently has access to data that could be further leveraged to craft additional phishing attacks at related targets.
HOMEKit
The HOMEKit toolkit creates Microsoft Word documents (OLE) that exploit the CVE-2012-0158 vulnerability. All malicious documents created by the HOMEKit toolkit have the same metadata within the SummaryInformation and DocumentSummaryInformation streams of the OLE document, as seen in Figure 3.
HOMEKit creates documents designed to exploit a vulnerability within the TreeView ActiveX control, specifically the CLSID of 9368265E-85FE-11d1-8BE3-0000F8754DA1. Upon successful exploitation, the malicious document will execute shellcode to open a decoy document (~.doc) while it installs and executes a payload on the system (~.dat).
The shellcode executed by this variant of HOMEKit begins with a decryption stub that is responsible for decrypting the functional shellcode. The decryption stub uses a combination of right bit shifting (ROR 3) and an XOR operation (key of 0xAF) on each byte of ciphertext.
The functional shellcode exposed by the decryption stub starts by enumerating open file handles looking for files that have a file size greater than zero. It then reads the last 20 bytes of each file looking for the value “0xDEADFOOD” at the very end of the file to find the delivery document. Once it finds the appropriate file, it parses the last 20 bytes of the file to locate the payload and decoy document using the following structure:
To decrypt the payload and decoy, the shellcode uses an algorithm that starts from the end of the ciphertext, using the lowest byte of the initial value of “0xDEADFOOD” to XOR the first byte and then rotating the key value by 1 for each subsequent operation. The shellcode will save the payload to %TEMP%\~.dat and the decoy to %TEMP%\~.doc after the decryption routines are finished. Once the payload and decoy are saved to the system, the shellcode creates a process with %TEMP%\~.dat to execute the payload and creates a process with the following command line to open the decoy document:
When creating the processes to run the payload and open the decoy, the shellcode calls GetCurrentProcess to get a handle to the current Word process, then OpenProcessToken to access the Word process’s token. Finally, it uses this token to call CreateProcessAsUserA to run the payload and the decoy with the same context as the current Word process.
Cookle Trojan
At a high level, the payload delivered in this attack is a downloader Trojan that we are tracking as “Cookle” based on a header value in HTTP requests made by the malware.
After initial execution, the Trojan creates the mutex “LDE_160425” and copies itself from %TEMP%\~.dat to %APPDATA%\Microsoft\WindowsUpdate\~.exe. For persistence, the Trojan creates the following registry key with a path to the newly copied Trojan:
A majority of the pertinent strings embedded within the Trojan are encoded, which the Trojan decodes using a modified base64 decoding function that swaps the uppercase letters in the base64 alphabet with lowercase letters, and vice versa. It uses this custom base64 decoder to decode the following strings:
The Trojan contains two command and control (C2) domains within the encoded strings listed above, dyn.kaleebso[.]com and dyn.pwnz[.]org. The Trojan sets a sleep timer of 20 minutes to wait before generating and sending network beacons to the C2 servers. The initial beacon seen in Figure 4 contains a misspelled “Cookie” field that includes the same value the Trojan uses as a mutex.
Figure 4 C2 Beacon sent from Cookle Trojan
If the Trojan receives a response to this beacon from the C2 server, it runs several system commands, specifically systeminfo, tasklist, netstat /ano, and ipconfig /all. It will then take the output from those system commands and save the output to a text file in the %TEMP% folder with a filename of “<year><month><day><hour><minute><second>.tmp”. The Trojan will then send the contents of this file to the C2 server as cleartext within a HTTP POST request that will resemble the following:
Figure 5 HTTP POST request issued by Cookle that sends system information to C2 server
The C2 server will respond to this request with a command that the Trojan will parse. The Trojan’s command handler has three available commands:
Figure 6 Commands within Cookle’s Command Handler
The functionality available within the Trojan is limited, however, it allows the actor to perform system reconnaissance before delivering a secondary payload. The secondary payload is delivered via the ‘d’ command, wherein the Trojan will decrypt an executable using the XOR operation on each byte in the C2’s response with 0xA7. During the analysis period, the C2 servers did not respond with a secondary payload.
Overlap with DarkHotel
Collection of additional HOMEKit delivery documents revealed use of this toolkit by its operators since at least 2013 and most recently, late June 2016. Each of these malicious documents created by the HOMEKit toolkit installed different payloads including PlugX, Sutr, and HIMAN/Mirage, among others. As mentioned earlier, we will be publishing a follow up to this post that contains details of these prior attacks.
As part of the collected sample set, we found two documents that have a very similar structure as the delivery document used in the attack delivering the Cookle payload but with very slight variations in the exploit code. The most curious aspect of these two documents was the payload embedded in them.
Both of the additional HOMEKit samples have the same functional shellcode and install a downloader associated with the Tapaoux Trojan, a tool related to the DarkHotel threat group. We compared the shellcode embedded in the HOMEKit delivery documents with previous samples associated with DarkHotel and found striking similarities (Figure 7).
Figure 7 Comparison of notable static attributes within HOMEKit documents installing Cookle and DarkHotel
The major difference between the HOMEKit documents dropping Cookle and DarkHotel begins with the stub decrypter, as seen in Figure 7. The stub decrypter decrypts a second piece of shellcode that carries out the main functionality as mentioned previously in this post. The decryption routines themselves differ, as seen in the green highlighted instructions in Figure 8. The size of the decrypted shellcode differs between the two samples as well, as seen in the yellow highlighted “mov cx” instructions in Figure 8.
Figure 8 Comparison of stub decrypters found in the shellcode within Cookle and DarkHotel samples
Even though the size of the shellcode differs between the Cookle and DarkHotel samples, the shellcode itself is extremely similar. A simple binary difference between the two functional shellcodes result in over a 90 percent similarity. Static analysis determined that the two shellcodes resolve the same API functions and store them on the stack in the same order. Also, many identical code blocks exist between the two shellcodes that results in significant code overlap. The similarities in shellcode suggest that the author of the HOMEKit toolkit variant used to deliver the Cookle Trojan had access to the same shellcode as the HOMEKit toolkit used to install DarkHotel.
The difference between the functional shellcode that installs Cookle and DarkHotel lies in the way a process is created to execute the payload and to open the decoy document. While the difference between the two is very minor, it is worth discussing as it suggests the author of the Cookle shellcode intentionally modified the DarkHotel shellcode, possibly as an anti-analysis technique. Figure 9 shows a side-by-side comparison of the process creation functionality within the DarkHotel and Cookle shellcodes, which highlights the differences between the two (red and blue highlighted instructions and two new gray code blocks).
Figure 9 Side-by-side comparison of the shellcode dropping DarkHotel and Cookle, specifically code used to create a process
The comparison in Figure 9 shows the differences between the two functions using highlighted instructions and additional boxes, but it does not explain what the changes mean from a functionality standpoint. We will explain how the two functions go about creating a process and how they differ.
The DarkHotel shellcode first uses the GetCurrentProcess function to get a handle to the Word process, then uses OpenProcessToken and finally CreateProcessAsUserA to open the decoy and execute the payload just like the Cookle shellcode. However, the DarkHotel shellcode calls the API functions in a very straightforward manner, specifically using CALL instructions (highlighted red in Figure 9).
In contrast, the Cookle shellcode uses CALL instructions to call the GetCurrentProcess and OpenProcessToken functions, but jumps to the CreateProcessAsUserA function using a JMP instruction. To allow the use of JMP in place of a CALL, the shellcode must provide a way to return to the function that called it, as the JMP instruction does not automatically handle this like the CALL instruction. Instead, it references a specific location (top four blue highlighted instructions) and starts looking for the value “0xC3” (first gray box in Figure 9), which is the value for the instruction “RETN”. Once found, the shellcode will push to the stack so the JMP instruction can be used to call the CreateProcessAsUserA function and return to the original calling function.
The similarities between the delivery documents dropping Cookle and DarkHotel payloads suggest that both were generated by the HOMEKit toolkit, albeit using slightly different versions. The slight differences between the stub decrypters and the functional shellcode within the malicious documents hints that the actor may have used the same codebase to create a modified version of HOMEKit for use in the Cookle attack.
Conclusion
As we have highlighted several times in the past, the reuse of tools is quite common amongst various threat actor groups. Our next post will further map out the various campaigns associated with HOMEKit, along with the multiple variants discovered in the span of several years. The DarkHotel payload however, is a curious outlier in the grouping of payloads we were able to identify. It is possible that the DarkHotel threat actors were able to obtain a copy of the HOMEKit codebase somehow, or even possible that the Tapaoux Trojan was obtained by operators with access to HOMEKit. It is also possible that HOMEKit is a toolkit available to multiple threat actors, via a connected intermediary. Unfortunately, at this time, a lack of data does not allow us to come to a definitive answer. Regardless, it is yet another example of tool sharing and overlap, this time with surprising results.
Palo Alto Networks customers are protected and can learn more via the following resources:
All samples of this HOMEKit variant and Cookle are detected as malicious by WildFire
All domains described in this post are classified as malicious
CISOs exploring career advancement opportunities have a new consideration, according to Gartner VP and Distinguished Analyst Paul Proctor. At a Gartner Security & Risk Management Summit presentation in June, Proctor talked about the evolution of a new enterprise role, which is a logical next step for some CISOs: Digital Risk Officer (DRO).
While few organizations have formally created the role, Gartner predicts that by 2020, 30 percent of large enterprises will have a DRO in place. Why? Because the increasing integration of digital technologies into business operations and products—the Internet of Things (IoT)—requires someone who can assess technology risk throughout the digital enterprise and provide executives with decisions that impact business processes. An example is assessing the physical system that gathers personally identifiable information from wearable technology. The DRO would look at how the data is used in marketing and sales operations, identify privacy issues, and look at the legality of monetizing the data as a source of revenue.
Proctor reports while CISOs may not have the title, many have gradually taken on some of the tasks associated with a DRO, such as:
Reviewing contract clauses for technology risk and security requirements
Developing policies to address the growing use of technology not controlled by IT
Addressing the privacy and security of data gathered by IoT devices
For CISOs interested in making the transition, here are the skills needed, according to several experts:
Fully comprehend how the business is run, recognize desired strategic outcomes and speak the language of executives in order to fully articulate digital risk factors in operational and financial terms.
Understand IT, IoT and operational technology (OT), and the overlap of technology and the physical world.
Have the ability to work in a bimodal organization, supporting Mode 2 projects.
Understand global privacy and e-commerce regulations.
Have a people-centric style to work across the organization in collaboration with businesses, legal, compliance, operations, and digital marketing and sales.
Essentially, the DRO’s role is to bridge the cultural divide between business and technology, says Nick Sanna, president of the Digital Risk Management (DRM) Institute. To do that requires building the organizational processes and best practices necessary to measure and manage digital business risk—including mapping important business processes, assessing exposure to threats and prioritizing risk mitigation initiatives. Sanna admits that building a DRM program will be a complex challenge for DROs, but also a great personal stretch opportunity.
