It is associated with the cyberespionage group BlackTech, which mainly targets technology companies and government agencies in East Asia (specifically Taiwan, and in some instances, Japan and Hong Kong) and is responsible for some infamous campaigns such as PLEAD and Shrouded Crossbow.


In previous campaigns, we’ve seen Waterbear primarily being used for lateral movement, decrypting and triggering payloads with its loader component.


In most cases, the payloads are backdoors that are able to receive and load additional modules.


However, in one of its recent campaigns, we’ve discovered a piece of Waterbear payload with a brand-new purpose: hiding its network behaviors from a specific security product by API hooking techniques.


In our analysis, we have discovered that the security vendor is APAC-based, which is consistent with BlackTech’s targeted countries.


Knowing which specific APIs to hook might mean that the attackers are familiar with how certain security products gather information on their clients' endpoints and networks.


And since the API hooking shellcode adopts a generic approach, a similar code snippet might be used to target other products in the future and make Waterbear harder to detect.


A closer look at Waterbear Waterbear employs a modular approach to its malware.


It utilizes a DLL loader to decrypt and execute an RC4-encrypted payload.


Typically, the payload is the first-stage backdoor which receives and loads other executables from external attackers.


These first-stage backdoors can be divided into two types: First, to connect to a command-and-control (C&C) server, and second, to listen in on a specific port.


Sometimes, the hardcoded file paths of the encrypted payloads are not under Windows native directories (e.g., under security products or third-party libraries' directories), which may indicate that the attackers might have prior knowledge of their targets' environments.


It is also possible that the attackers use Waterbear as a secondary payload to help maintain presence after gaining some levels of access to the targets’ systems.


The evidence is that Waterbear frequently uses internal IPs as its own C&C servers (for instance, b9f3a3b9452a396c3ba0ce4a644dd2b7f494905e820e7b1c6dca2fdcce069361 uses an internal IP address of 10[.]0[.]0[.]211 as its C&C server).


The typical Waterbear infection chain  Figure 1.


A typical Waterbear infection chain


A Waterbear infection starts from a malicious DLL loader, as shown in Figure 1.


We have seen two  techniques of DLL loader triggering.


One is modifying a legitimate server application to import and load the malicious DLL loader, while the second technique is performing phantom DLL hijacking and DLL side loading.


Some Windows services try to load external DLLs with hardcoded DLL names or paths during boot-up.


However, if the DLL is a legacy DLL (i.e., one that is no longer supported by Windows) or a third-party DLL (i.e., one that is not part of the original Windows system DLLs), attackers can give their malicious DLL a hardcoded DLL name and place it under one of the searched directories during the DLL loading process.


After the malicious DLL is loaded, it will gain the same permission level as the service that loads it.


During our recent Waterbear investigation, we discovered that the DLL loader loaded two payloads.


The payloads performed functionalities we have never seen in other Waterbear campaigns.


The first payload injects code into a specific security product to hide the campaign’s backdoor.


The second payload is a typical Waterbear first-stage backdoor, which we will attempt to dissect first based on a specific case we observed during our analysis.


Waterbear’s first-stage backdoor


We saw a Waterbear loader named "ociw32.dll" inside one of the folders in the %PATH% environmental variable.


This DLL name is hardcoded inside "mtxoci.dll" which is loaded by the MSDTC service during boot-up.


“mtxoci.dll” first tries to query the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MTxOCI" to see if the value "OracleOciLib" exists.


If so, it retrieves the data inside it and loads the corresponding library.


If the value doesn't exist, “mtxoci.dll” tries to load "ociw32.dll" instead.


During our investigation, we noticed that the value "OracleOciLib" was deleted from the victim's machine, as shown in Figure 2.


Hence, the malicious loader "ociw32.dll" was loaded and successfully executed on the host.


Figure 2.


The deleted value "OracleOciLib" on the victim's host


Note: The image on the left  shows how  the DLL on a normal machine normally looks.


The image on the right showcases how the DLL on a victim's machine appears.


Because there is no "OracleOciLib" value, it loads the hardcoded DLL "ociw32.dll" instead, which triggers the malicious Waterbear DLL loader.


After the Waterbear DLL loader is executed, it searches for a hardcoded path and tries to decrypt the corresponding payload, which is a piece of encrypted shellcode.


The decryption algorithm is RC4, which takes the hardcoded path to form the decryption key.


If the decrypted payload is valid, it picks a specific existing Windows Service — LanmanServer, which is run by svchost.exe — and injects the decrypted shellcode into the legitimate service.


In most cases, the payload is a first-stage backdoor, and its main purpose is to retrieve second-stage payloads — either by connecting to a C&C server or opening a port to wait for external connections and load incoming executables.


Configuration of the first-stage backdoor Waterbear’s first-stage backdoor configuration contains the information required for the proper execution of and communication with external entities.


Offset 0x00, Size 0x10: Encryption / decryption key for the functions Offset 0x10, Size 0x04: 0x0BB8 (reserved) Offset 0x14, Size 0x10: Version (e.g., 0.13, 0.14, 0.16, and so on) Offset 0x24, Size 0x10: Mutex or reserved bytes Offset 0x34, Size 0x78: C&C server address which is XOR-encrypted by key 0xFF.


If the backdoor is intended to listen in on a specific port, this section will be filled with 0x00.


Offset 0xAC, Size 0x02: Port Offset 0xAE, Size 0x5A: Reserved bytes Table:


The function address table of the payload.


The block is initially filled with 0x00 and will be propagated during runtime.


Table: The sizes of functions Table:


The API address table.


The block is initially filled with 0x00 and will be filled with loaded API addresses during runtime.


Table: The API hashes for dynamic API loading


A list of DLL names and the number of APIs to be loaded   Figure 3.


The first-stage backdoor’s configuration structure Anti-memory scanning of shellcode payload


In order to avoid in-memory scanning during runtime, the payload encrypts all of the function blocks before executing the actual malicious routine.


Afterwards, whenever it needs to use a function, it will decrypt the function, execute it, and encrypt the function back again, as can be seen in Figure 4.


If a function will not be used on the rest of the execution, it will be scrambled by another mess-up function, as illustrated in Figure 6.


The mess-up function muddles up the bytes with random values and makes the input blocks unrecoverable.


The purpose of this is to further avoid being detected by a certain cybersecurity solution.


Figure 4.


The decryption-execution-encryption flow in the shellcode execution routine  Figure 5.


The function for the function block encryption and decryption  Figure 6.


The payload’s mess-up function Same Waterbear, different story


During our investigation, we found a peculiar incident that stands out from most of the Waterbear infections we’ve previously seen.


This time, the DLL loader loaded two payloads – the first payload performed functionalities we have not seen before: It injected codes into a specific security product to do API hooking in order to hide the backdoor from the product.


Meanwhile, the second payload is a typical Waterbear first-stage backdoor.


Figure 7.


An unusual Waterbear infection chain


Both payloads were encrypted and stored on the victim’s disk and were injected into the same service, which was, in this case, LanmanServer.


We have observed that the loader tried to read the payloads from the files, decrypted them, and performed thread injections with the following conditions:  If the first payload could not be found on the disk, the loader would be terminated without loading the second one.


If the first payload was successfully decrypted and injected into the service, the second piece would also be loaded and injected regardless of what happened to the first thread.


In the first injected thread, if the necessary executable from the security product was not found, the thread would be terminated without performing other malicious routines.


Note that only the thread would be terminated, but the service would still be running.


Regardless if the API hooking was performed or otherwise, the second backdoor would still be executed after having been successfully loaded.


API hooking to evade detection


In order to hide the behaviors of the first-stage backdoor (which is the second payload), the first payload uses API hooking techniques to avoid being detected by a specific security product and to make an interference in the result of the function execution.


It hooks two different APIs, namely "ZwOpenProcess" and "GetExtendedTcpTable", to hide its specific processes.


The payload only modifies the functions in the memory of the security product process, hence the original system DLL files remain unchanged.


The payload is composed of a two-stage shellcode.


The first-stage shellcode finds a specific security product's process with a hardcoded name and injects the second-stage shellcode into  that process.


The second-stage shellcode then performs API hooking inside the targeted process.


Hiding process identifiers (PIDs) The process identifiers or PIDs to be hidden are stored in the shared memory "Global\<computer_name>."


If the shared memory doesn't exist, it takes the PID embedded by the first-stage shellcode.


In this case, the intention of the malicious code is to hide Waterbear’s  backdoor activities from the security product.


Therefore, the first-stage shellcode takes the PID of the Windows Service — which the first-stage shellcode and the succeeding backdoor both inject into — hides the target process, and embeds that PID into the second-stage shellcode.


Figure 8.


Code that injects current PID into the second-stage shellcode Hooking "ZwOpenProcess" in ntdll.dll


The purpose of hooking “ZwOpenProcess” is to protect the specific process from being accessed by the security product.


Whenever “ZwOpenProcess” is called, the injected code will first check if the opened process hits any PIDs in the protected process ID list.


If yes, it modifies the process ID, which should open on another Windows Service PID.


First, it builds the hooked function and writes the function at the end of “ntdll.dll”.


This function includes two parts, as shown in Figure 9:  The PID checking procedure.


It recursively checks if the PID to be opened by “ZwOpenProcess” is in the list of the protected process IDs.


If yes, it replaces the PID to be opened with another Windows Service PID that has been written by the Waterbear loader in the beginning.


After the PID checking procedure, it executes the original “ZwOpenProcess” and returns the result.


Figure 9.


The function hook of “ZwOpenProcess” to check and modify the output of the function Secondly, it writes "push <ADDRESS> ret" at the beginning of the original “ZwOpenProcess” address.


Hence, when “ZwOpenProcess” is called, the modified version of “ZwOpenProcess” will be executed.


Figure 10.


“ZwOpenProcess” after modification


The API hooking on “ZwOpenProcess” will only be triggered if "%temp%\KERNELBASE.dll" exists on the host.


It is possible that this check is designed according to the nature of the security product it targets.


"GetExtendedTcpTable" and "GetRTTAndHopCount" hooks in iphlpapi.dll


The second part of API hooking hooks on “GetExtendedTcpTable.” “GetExtendedTcpTable” is used for retrieving a table that contains a list of TCP endpoints available to the application, and it is frequently used in some network-related commands, such as netstat.


The purpose of the hook is to remove TCP endpoint records of certain PIDs.


In order to achieve that, it modifies two functions: “GetExtendedTcpTable” and “GetRTTAndHopCount.”


The second function, “GetRTTAndHopCount,” acts as the place to put the injected hooking code.


“GetExtendedTcpTable” only writes a jump to “GetRTTAndHopCount” in the beginning of the function.


Only the first 5 bytes of the code of the API "GetExtendedTcpTable" are changed, as shown in Figure 11.  Figure 11.


Only 5 bytes changed in the “GetExtendedTcpTable”


The rest of the routine is all placed in “GetRTTAndHopCount.”


In the first part of the code, it pushes [“GetRTTAndHopCount”+0x3E] as the return address and then executes the first four instructions of the original “GetExtendedTcpTable” function (which has already been replaced by the jump instruction in Figure 11).


After that, it jumps to “GetExtendedTcpTable” to execute the function normally and to catch its return values.


The code is shown in Figure 12.


Figure 12.


The first part of injected code in “GetRTTAndHopCount,” which executes “GetExtendedTcpTable” and returns back to the next instruction


After “GetExtendedTcpTable” is executed and the process returns back to the second part of the code, it iteratively checks every record in the returned Tcp table.


If any record contains the PID Waterbear wants to hide, it will remove the corresponding record, modify the record number inside the table, and continue to check the succeeding records.


In the end, it returns the modified table.


Fig. 13.


The injected code’s second part in “GetRTTAndHopCount” that checks and removes returned records of certain PIDs


Rather than directly disabling these two functions, this method of using API hooking makes noticing malicious behaviors more difficult, especially since both functions still work and return results normally.


Although in this case, the affected process is specified in the first-stage shellcode, the API hooking logic is quite generic that the same piece of shellcode can be used to hook other vendors' products.


Conclusion


This is the first time we’ve seen Waterbear attempting to hide its backdoor activities.


By the hardcoded product name, we infer that the attackers are knowledgeable of the victims' environment and which security product(s) they use.


The attackers might also be familiar with how security products gather information on their clients’ endpoints and networks, so that they know which APIs to hook.


Since the API hooking shellcode adopts a generic approach, the similar code snippet might be used to target other products in the future and make the activities of Waterbear harder to detect.  Tactic  Technique ID Description  Execution Execution


through


Module Load


T1129   Dynamically loads the DLLs through the shellcode Execution through API T1106


Dynamically loads the APIs through the shellcode Persistence


Hooking T1179   Hooks security product’s commonly used APIs Privilege Escalation   Process Injection T1055 Injects the decrypts payload into svchost.exe process Hooking T1179   Hooks security products’ commonly used APIs Defense Evasion Binary Padding T1009 Adds junk data to evade anti-virus scan Disabling Security Tools T1089 Targets a specific security product’s process for injection purposes Deobfuscate/Decode Files or Information T1140 Uses TROJ_WATERBEAR to decrypt encrypted payload Execution Guardrails T1480 Targets specific software in the victim’s environment DLL


Side-Loading T1073   Uses modified legitimate DLL to load the malicious DLL Process Injection T1055 Injects the decrypted payload into svchost.exe process Exfiltration Exfiltration Over Command and Control Channel T1041


Possibly sends collected data to attackers via C&C channel   Indicators of Compromise (IoCs)  SHA256  Detection Name  649675baef92381ffcdfa42e8959015e83c1ab1c7bbfd64635ce5f6f65efd651 BKDR_WATERBEAR.ZTGF 3909e837f3a96736947e387a84bb57e57974db9b77fb1d8fa5d808a89f9a401b TROJ_WATERBEAR.ZTGD fcfdd079b5861c0192e559c80e8f393b16ba419186066a21aab0294327ea9e58 TROJ_WATERBEAR.ZTGJ 3f26a971e393d7f6ce7bf4416abdbfa1def843a0cf74d8b7bb841ca90f5c9ed9 TROJ_WATERBEAR.ZTGH abb91dfd95d11a232375d6b5cdf94b0f7afb9683fb7af3e50bcecdb2bd6cb035 TROJ_WATERBEAR.ZTGH bda6812c3bbba3c885584d234be353b0a2d1b1cbd29161deab0ef8814ac1e8e1 TROJ_WATERBEAR.ZTGI 53402b662679f0bfd08de3abb064930af40ff6c9ec95469ce8489f65796e36c3 TROJ_WATERBEAR.ZTGH f9f6bc637f59ef843bc939cb6be5000da5b9277b972904bf84586ea0a17a6000 TROJ_WATERBEAR.ZTGI 3442c076c8824d5da065616063a6520ee1d9385d327779b5465292ac978dec26 BKDR_WATERBEAR.ZTGD 7858171120792e5c98cfa75ccde7cba49e62a2aeb32ed62322aae0a80a50f1ea


TROJ64_WATERBEAR.ZTGI acb2abc7fb44c2fdea0b65706d1e8b4c0bfb20e4bd4dcee5b95b346a60c6bd31 BKDR_WATERBEARENC.ZTGF b9f3a3b9452a396c3ba0ce4a644dd2b7f494905e820e7b1c6dca2fdcce069361 BKDR64_WATERBEAR.ZTGD 7c0d2782a33debb65b488893705e71a001ea06c4eb4fe88571639ed71ac85cdd BKDR_WATERBEARENC.ZTGH c7c7b2270767aaa2d66018894a7425ba6192730b4fe2130d290cd46af5cc0b7b BKDR_WATERBEARENC.ZTGI 7532fe7a16ba1db4d5e8d47de04b292d94882920cb672e89a48d07e77ddd0138 BKDR_WATERBEARENC.ZTGI dea5c564c9d961ccf2ed535139fbfca4f1727373504f2972ac92acfaf21da831 BKDR_WATERBEARENC.ZTGI 05d0ab2fbeb7e0ba7547afb013d307d32588704daac9c12002a690e5c1cde3a4 BKDR64_WATERBEARENC.ZTGJ 39668008deb49a9b9a033fd01e0ea7c5243ad958afd82f79c1665fb73c7cfadf BKDR_WATERBEARENC.ZTGD              Tags  Malware | APT & Targeted Attacks | Endpoints | Research | Network


Updated May 17, 2021, 3:25 a.m. Eastern Time:


This article has been updated to add references to the DarkSide victim data.


On May 7, a ransomware attack forced Colonial Pipeline, a company responsible for nearly half the fuel supply for the US East Coast, to proactively shut down operations.


Stores of gasoline, diesel, home heating oil, jet fuel, and military supplies had been so heavily affected that the Federal Motor Carrier Safety Administration (FMCSA) declared a state of emergency in 18 states to help with the shortages.


It has been five days since the shutdown prompted by the attack, but Colonial Pipeline is still unable to resume full operations.


Outages have already started affecting motorists.


In metro Atlanta, 30% of gas stations are without gasoline, and other cities are reporting similar numbers.


To keep supplies intact for essential services, the US government has issued advisories against hoarding.


The FBI has confirmed that DarkSide, a cybercriminal group believed to have originated in Eastern Europe, is behind the attack.


The ransomware used by the group is a relatively new family that was first spotted in August 2020, but the group draws on experience from previous financially successful cybercrime enterprises.


Apart from locking Colonial Pipeline’s computer systems, DarkSide also stole over 100 GB of corporate data.


This data theft is all the more relevant in light of the fact that the group has a history of doubly extorting its victims — not only asking for money to unlock the affected computers and demanding payment for the captured data, but also threatening to leak the stolen data if the victims do not pay. As we will cover later, DarkSide shows a level of innovation that sets it apart from its competition, being one of the first to offer what we call “quadruple extortion services.”


The group announced on May 12 that it had three more victims: a construction company based in Scotland, a renewable energy product reseller in Brazil, and a technology services reseller in the US.


The DarkSide actors claimed to have stolen a total of 1.9 GB of data from these companies, including sensitive information such as client data, financial data, employee passports, and contracts.


Since Darkside is a ransomware-as-a-service (RaaS), it is possible that three different affiliate groups are behind these three attacks.


Even the DarkSide actors themselves admit that they just buy access to company networks — they have no idea how access was acquired.


Trend Micro Research found dozens of DarkSide ransomware samples in the wild and investigated how the ransomware group operates and what organizations it typically targets.


The DarkSide ransomware DarkSide offers its RaaS to affiliates for a percentage of the profits.


The group presents a prime example of modern ransomware, operating with a more advanced business model.


Modern ransomware identifies high-value targets and involves more precise monetization of compromised assets (with double extortion as an example).


Modern ransomware attacks are also typically done by several groups who collaborate and split profits.


These attacks may look more like advanced persistent threat (APT) attacks than traditional ransomware events.


Here is a short timeline of DarkSide activity compiled from publicly available reports:


August 2020: DarkSide introduces its ransomware.


October 2020: DarkSide donates US$20,000 stolen from victims to charity.


November 2020:


DarkSide establishes its RaaS model.


The group invites other criminals to use its service.


A DarkSide data leak site is later discovered.


DarkSide launches its content delivery network (CDN) for storing and delivering compromised data.


December 2020:


A DarkSide actor invites media outlets and data recovery organizations to follow the group’s press center on the public leak site.


March 2021:


DarkSide releases version 2.0 of its ransomware with several updates.


May 2021:


DarkSide launches the Colonial Pipeline attack.


After the attack, Darkside announces it is apolitical and will start vetting its targets (possibly to avoid raising attention to future attacks).  Initial access


In our analysis of DarkSide samples, we saw that phishing, remote desktop protocol (RDP) abuse, and exploiting known vulnerabilities are the tactics used by the group to gain initial access.


The group also uses common, legitimate tools throughout the attack process to remain undetected and obfuscate its attack.


Throughout the reconnaissance and gaining-entry phases, we saw these legitimate tools used for specific purposes:   PowerShell: for reconnaissance and persistence  Metasploit Framework: for reconnaissance Mimikatz: for reconnaissance BloodHound: for reconnaissance Cobalt Strike: for installation  For modern ransomware like DarkSide, gaining initial access no longer immediately leads to ransomware being dropped.


There are now several steps in between that are manually executed by an attacker.


Lateral movement and privilege escalation Lateral movement is a key discovery phase in the modern ransomware process.


In general, the goal is to identify all critical data within the victim organization, including the target files and locations for the upcoming exfiltration and encryption steps.


In the case of DarkSide, we confirmed reports that the goal of lateral movement is to gain Domain Controller (DC) or Active Directory access, which will be used to steal credentials, escalate privileges, and acquire other valuable assets for data exfiltration.


The group then continues its lateral movement through the system, eventually using the DC network share to deploy the ransomware to connected machines.


Some of the known lateral movement methods deployed by DarkSide use PSExec and RDP.


But as we previously noted, a modern ransomware group behaves with methods more commonly associated with APT groups — it adapts its tooling and methods to the victim’s network defenses.


Exfiltration  As is common practice with double extortion ransomware, critical files are exfiltrated prior to the ransomware being launched.


This is the riskiest step so far in the ransomware execution process, as data exfiltration is more likely to be noticed by the victim organization’s security team.


It is the last step before the ransomware is dropped, and the attack often speeds up at this point to complete the process before it is stopped.


For exfiltration, we saw the following tools being used:   7-Zip: a utility used for archiving files in preparation for exfiltration  Rclone and Mega client: tools used for exfiltrating files to cloud storage PuTTy: an alternative application used for network file transfer  DarkSide uses several Tor-based leak sites to host stolen data.


The file-sharing services used by the group for data exfiltration include Mega and PrivatLab.


Execution and impact  The execution of the actual ransomware occurs next.


The DarkSide ransomware shares many similarities with REvil in this step of the process, including the structure of ransom notes and the use of PowerShell to execute a command that deletes shadow copies from the network.


It also uses the same code to check that the victim is not located in a Commonwealth of Independent States (CIS) country.


In addition to PowerShell, which is used to install and operate the malware itself, the group reportedly uses Certutil and Bitsadmin to download the ransomware.


It uses two encryption methods, depending on whether the target operating system is Windows or Linux: A ChaCha20 stream cipher with RSA-4096 is used on Linux, and Salsa20 with RSA-1024 is used on Windows.


The following figure shows a sample ransom note from DarkSide.


Figure 1.


A Darkside ransom note


It is interesting to note that DarkSide’s ransom note is similar to that of Babuk, which might indicate that these two families share a link.


DarkSide ransomware targets


Based on the group’s Tor leak sites, DarkSide determines whether to pursue targeting a potential victim organization by primarily looking at that organization’s financial records.


It also uses this information to determine the amount of ransom to demand, with a typical ransom demand amounting to anywhere between US$200,000 and US$2 million.


Reports say that, based on the leak sites, there are at least 90 victims affected by DarkSide.


In total, more than 2 TB of stolen data is currently being hosted on DarkSide sites, and 100% of victims’ stolen files are leaked.


The actors behind Darkside have stated that they avoid targeting companies in certain industries, including healthcare, education, the public sector, and the nonprofit sector.


Organizations in manufacturing, finance, and critical infrastructure have been identified in Trend Micro data as targets.


Based on Trend Micro data, the US is by far DarkSide’s most targeted country, at more than 500 detections, followed by France, Belgium, and Canada.


As previously mentioned, DarkSide avoids victimizing companies in CIS countries.


Part of the ransomware execution code checks for the geolocation of potential victims to avoid companies in these countries, although the group would likely be aware of the location of a target organization long before the ransomware is executed.


That the group admittedly spares companies in CIS countries could be a clue to where DarkSide actors are residing.


It is possible that they do this to avoid law enforcement action from these countries, since the governments of some of these countries do not persecute criminal acts such as DarkSide’s if they are done on foreign targets.


After the Colonial Pipeline attack, DarkSide released a statement on one of its leak sites clarifying that the group did not wish to create problems for society and that its goal was simply to make money.


There is no way to verify this statement, but we know that the group is still quite active.


As previously mentioned, DarkSide actors announced that they had stolen data from three more victims since the Colonial Pipeline attack.


MITRE ATT&CK tactics and techniques


The following are the MITRE ATT&CK tactics and techniques associated with DarkSide.


Conclusion


Ransomware is an old but persistently evolving threat.


As demonstrated by the recent activities of DarkSide, modern ransomware has changed in many aspects: bigger targets, more advanced extortion techniques, and farther-reaching consequences beyond the victims themselves.


Ransomware actors are no longer content with simply locking companies out of their computers and asking for ransom.


Now they are digging deeper into their victims’ networks and looking for new ways to monetize their activities.


For example, a compromised cloud server can go through a complete attack life cycle, from the initial compromise to data exfiltration to resale or use for further monetization.


Compromised enterprise assets are a lucrative commodity on underground markets; cybercriminals are well aware of how to make money from attacking company servers.


In the Colonial Pipeline attack, DarkSide used double extortion.


But some ransomware actors have gone even further.


Jon Clay, Director of Global Threat Communications at Trend Micro, outlines the phases of ransomware:


Phase 1: Just ransomware.


Encrypt the files, drop the ransom note, and wait for the payment.


Phase 2: Double extortion.


Phase 1 + data exfiltration and threatening data release.


Maze was one of the first documented cases of this.


Phase 3: Triple extortion.


Phase 1 + Phase 2 + threatening DDoS.


SunCrypt, RagnarLocker, and Avaddon were among the first groups documented doing this.


Phase 4: Quadruple extortion.


Phase 1 (+ possibly Phase 2 or Phase 3) + directly emailing the victim’s customer base or having contracted call centers contact customers.


In fact, as detailed in security reports, DarkSide offers both the DDoS and call center options.


The group is making quadruple extortion available to its affiliates and showing a clear sign of innovation.


In cybercrime, there are no copyright or patent laws for tools and techniques.


Innovation is as much about quickly and completely copying others’ best practices as it is about coming up with new approaches.


Ransomware will only continue to evolve.


Organizations therefore need to take the time to put in place an incident response plan focused on the new model of ransomware attacks.


Unfortunately, some organizations may be putting cybersecurity on the back burner.


For example, some security experts noted that Colonial Pipeline was using a previously exploited vulnerable version of Microsoft Exchange, among other cybersecurity lapses.


A successful attack on a company providing critical services will have rippling effects that will harm multiple sectors of society, which is why protecting these services should be a top priority.


In a US Senate hearing on cybersecurity threats, Senator Rob Portman of Ohio described the strike on Colonial Pipeline as “potentially the most substantial and damaging attack on US critical infrastructure ever.”


This attack is a call to action for all organizations to harden their networks against attacks and improve their network visibility.


Trend Micro has a multilayered cybersecurity platform that can help improve your organization’s detection and response against the latest ransomware attacks and improve your organization’s visibility.


Visit the Trend Micro Vision One™ website for more information.


Detailed solutions can be found in our knowledge base article on DarkSide ransomware.


Tags  APT & Targeted Attacks | Ransomware | Research | Articles, News, Reports


We have been collectively saying in our industry for the last 15-20 years that a layered approach to your security stack is a “best practice,” but as with all best practices, these are ideals rather than reality for so many charged with protecting their organizations.


The vast majority of CISOs are saddled with legacy operating systems and applications, along with a lack of funding.


For many of those in the more mature sectors who struggle less with resources, such as financial and government, this ideal state has been achieved by buying a large number of feature products for each layer.


Then, add more and more people to each layer with the hope that they can effectively coordinate their layers to protect, detect, respond and recover from attacks.


Today’s Challenge


While this strategy has provided a small level of success, it’s not sustainable and definitely not an option for the remaining 90% of companies with resource challenges.


Further complicating the issue is the growing scope and scale of attacks today that are successfully targeting the seams between these layers.


There are many reasons why we are in this overloaded place, drowning in alerts and logs.


But, there is one cause that we can point to that has become especially problematic to the design and operations of security programs – the focus on the “kill chain.”


This focus can be effective to simplify and explain the progression of an attack through the different layers.


However, it doesn’t adequately address the reality of the non-linear nature of attacks.


It also misses the incredible importance of identifying tactics, techniques, and tools used by global threat actor groups today.


(Que the MITRE ATT&CK plug)


Until now.


ATT&CK “…is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations.”


ATT&CK enables network defenders and cyber threat intelligence analysts to collaborate through an open community to continuously identify tactics, techniques and tools used by 90+ global threat actor groups to improve their protection and detection.


Today’s Protection


Other innovative trends that work hand in hand with ATT&CK is the move to XDR from EDR.


In the same way that the kill chain has become an outdated concept, so has the notion that EDR is sufficient to speed up detection and response by solely using the endpoint.


ATT&CK gives you the full picture of the threat, and XDR coordinates protection against the full picture of that threat.


While the endpoint is still critical, there are vast numbers of malicious artifacts that are siloed or missed at the network, cloud, and gateway.


XDR fills in those gaps.


Do you think the evolution of EDR to XDR will meet many of challenges we are seeing today?


Tweet us your thoughts at @TrendMicro.


Tags  Cloud | APT & Targeted Attacks | Expert Perspective | Articles, News, Reports | Cyber Threats


Determining who is behind a malware campaign can be a challenging endeavor.


Threat actors generally don’t leave easily identifiable signatures in software designed to disrupt or otherwise harm an adversary.


However, by comparing key pieces of information with known sources, it is possible to determine when a campaign was likely perpetrated by a certain group.


This is even more true when the group has existed for many years and has many pieces of evidence to compare.


Recently, we uncovered the Operation Earth Kitsune campaign and published a detailed analysis of its tactics, techniques, and procedures (TTPs).


While analyzing the technical details of this malware, which includes two new espionage backdoors, we noticed striking similarities to other malware attributed to the threat actor known as APT37, also known as Reaper or Group 123.


We hope our thorough analysis of Operation Earth Kitsune will help others with data points for attribution in the future.


By some accounts, this group has been active since 2012, so there are many examples attributed to them to compare.


It is important to note that previous analysis of suspected APT37 activities from different security vendors date from 2016, and the captured samples for the Operation Earth Kitsune have been developed recently.


Because of this, finding code similarity is unlikely.


However, we were able to match some code reuse in one of the espionage backdoor’s functionalities.


In that sense, we are emphasizing TTPs correlation in this case.


In other words, even when the new samples are developed, the attacker may have reused many of the operational techniques.


Another important consideration for attribution is that we have some historical background for Operation Earth Kitsune.


Previously, we uncovered two different campaigns in 2019 under the name of SLUB malware.


Operation Earth Kitsune is a continuation of those campaigns.


Consequently, some of the attribution indicators will span and include the previous SLUB malware campaigns.


The following sections describe the different correlations and are divided into two main categories:  Correlation related to the malware author developing environment Correlation associated with TTPs  Note that some leads are stronger than others; however, when combined, they suggest that the same threat actor behind malware previously attributed to APT37 is likely responsible for Operation Earth Kitsune.


Malware author’s developer environment


When determining attribution, the most interesting leads are the ones that can deduce information about the malware author’s working environment.


Sometimes, these leads can determine the preferred languages used in the developers’ environment.


There are also times when developers intentionally remove these associations and plant misleading information to avoid attribution.


That action by itself potentially introduces other leads that developers may forget to clean.


Operating system language version


During the analysis of the samples captured from the previous campaign related to SLUB in 2019, one of the samples, the SLUB loader exploiting CVE-2019-0803, contained a version resource section that included intentionally misleading planted data.


Figure 1 shows this:      Figure 1 Planted version information      This kind of misleading version data is quite common and does not have information relevant to attribution.


However, there is a secondary effect when the version resource is added to a binary.


For this, we are assuming this binary was compiled with a Visual Studio toolchain, which is indicated for various compiler identification tools.


When the version resource is compiled into the binary, a language ID is generated and created not in the resource payload but in the internal structure of the resource information that is not visible with Windows Explorer.


What is interesting is that this language ID is not determined by the Visual Studio current language.


Instead, it is determined by the operating system language at the time of the version resource inclusion.


Viewing this language ID requires the use of other tools.


Figure 2 shows the language ID for the SLUB dropper.


Figure 2. Language ID of the Version Resource


We found this type of OS language leak in prior samples attributed to APT37.


One of the previous malware families attributed to APT37 is known as Freenki.


Some Freenki samples had leaked the OS language ID through this same mechanism.


The image (Figure 3) taken from an analysis of Freenki shows that the same logic applies when the resource is compiled into the binary.


Figure 3. Freenki embedded resource


We assume there are multiple developers within APT37, and not all of them follow the same practices.


As such, not all samples may have the embedded resource that leaks the same OS language.


However, this commonality is just the first of many that lead us to believe the team attributed to the Freenki malware is the same team behind Operation Earth Kitsune.2 Leaked assert path and external blog references Sometimes, the malware authors know that releasing symbol information is dangerous from an attribution point of view since it can reveal information about the working environment.


That information often gets stripped from binaries.


However, that is not the only scenario where malware developers leak path information about their environment.


In some instances, malware projects require external libraries, and some libraries used the “assert()” mechanism to help the developers debug unexpected conditions.


In these cases, the compiler includes a path to the source code file along with those “assert()” calls.


These paths leak information about the third-party libraries’ installed paths.


In our case, the samples from the Operation Earth Kitsune implemented the Mattermost command and control (C2) communication and leaked a local path.


Figure 4 shows the leaked path.


Figure 4. Leaked assert() path     Public references to this path (the path to the c++ boost library) consist of Korean language blogs explaining how to set up a developer environment configuration using the same path.


We can also determine that this configuration was created manually because the default path installation does not support static compilation.


Here is a translation of the relevant section: “Well, in the end, I modified the project configuration file as below, but it doesn't seem like best practice.


There seems to be a neat way to do it, but I seek advice from experienced people.”


It is also important to note that the same paths leaked through all the SLUB samples.


This includes samples from the older SLUB campaign in 2019 and the new version that supports Mattermost.


Figure 5.


Public blog in the Korean Language     These two indicators reveal that the malware author used an “assert()” path and referenced an external blog in the same manner as previously analyzed malware.


TTPs Correlation


In our previous detailed analysis of Operation Earth Kitsune, one of the delivery architecture for the espionage backdoors is designed as shown in Figure 6.      Figure 6.


Delivery architecture


While this mechanism may sound quite common in other campaigns, what is interesting is the details they have in common with previous campaigns attributed to APT37.


In 2017, Palo Alto’s Unit 42 detailed their findings around the Freenki malware.


Even though this analysis was three years before Operation Earth Kitsune, the attackers appear to have reused the same TTPs for delivering the malware.


Figure 7 shows delivery PowerShell script sections for both campaigns.


Figure 7. PowerShell scripts downloading JPG files     The following TTPs are common in both campaigns related to the scripts in Figure 7:


Both have compromised websites where the malware samples are hosted and delivered to victim machines.


Both use PowerShell scripts to download and run the samples.


Both PowerShell scripts download multiple malware to the victim machine.


It appears the attacker is willing to implement multiple mechanisms for infecting the victim machine once it is compromised.


Both use different samples for the multiple malware downloaded.


Both use JPG as a delivering extension.


Multiple samples are delivered at the same time.


In both cases, at least one sample received command line arguments.


Another surprising similarity in the TTPs related to both campaigns is the path pointing to “udel_ok.ipp,”  as shown in Figure 7.


This is a JavaScript file that executes with wscript.exe.


Figure 8 shows the partial source code for this JavaScript.


Figure 8. Javascript executing the malware.


What got our attention is that the samples were renamed to be similar to the naming convention of Windows update files (i.e., “Windows-KB275122-x86.exe”).


While analyzing the samples that have been previously attributed to APT37, we noticed that the persistence mechanism in Operation Earth Kitsune uses the same naming convention to auto-start itself through the Windows run registry key.


We also found that older samples from the previous SLUB campaigns in 2019 used a similar naming convention.


Figure 9 shows that SLUB used “Windows-RT-KB-2937636.dll,” while Freenki used “Windows-KB275122-x86.exe.”      Figure 9 Naming convention for persistence.


We can see how the Freenki malware, previous SLUB campaigns, and Operation Earth Kitsune share many common TTPs in their delivery and persistence mechanisms.


However, these are not the only commonalities.


Again, on its own, this might not be coincidental.


However, our analysis shows further similarities that imply correlation.


GNUBoard compromised web sites


In the blog describing Operation Earth Kitsune, we noted sites using the GNUBoard Content Management System (CMS) had been compromised and were used to host malware.


The malware campaigns previously attributed to APT37 also extensively used the exploitation of web sites hosted with GNUBoard CMS.


While analyzing multiple samples, we found indicators of this strategy across the various campaigns.


Figure 10 shows an example attributed to APT37 and Operation Earth Kitsune as a comparison.


The SLUB campaign also exploited and used GNUBoard websites as part of the infrastructure.


Figure 10.


Websites created using GNUBoard CMS     Exfiltration commands


As mentioned in the previous report on Operation Earth Kitsune, one of the espionage backdoors, named agfSpy, received a “JSON” configuration with a list of native Windows commands to execute.


The output of those commands is exfiltrated back to the agfSpy command and control (C2) server.


While analyzing one malware previously attributed to APT37, it executed practically the same command sequences including the paths and extensions.


Even when the threat actor was not using the “JSON” format, the commands embedded in the various samples show a surprising amount of similarities.


Figure 11 shows a comparison of the exfiltration commands between malware previously attributed to APT37 and Operation Earth Kitsune.


Note the following similarities:  The usage of paths C:\Users and D:\ are similar The searching patterns are very similar The extension list is very similar


Note that we are comparting a sample from 2016 with agfSpy, which is from 2020.


It makes sense that new campaigns coming from the same authors/groups will add new extensions like “.xlsx” to support updated versions of Office documents.


It is also clear that the actual interest is on the “.hwp” extension for Korean Office document listing support during exfiltration.


Figure 11. Exfiltration command similarities.     Code sharing


When doing attribution, finding code sharing between different samples is one of the most desired discoveries.


However, in our case, this was difficult as we are comparing samples from 2016-2017 to those developed in 2020.


At the same time, practically all code for the SLUB malware was created from scratch.


Also, dneSpy and agfSpy are based on custom and newly developed code.


That makes it difficult to match code similarities, and that is why many of the indicators of code sharing are sparse across different samples.


However, one feature that is present in the previous malware attributed to APT37 and Operation Earth Kitsune is the screenshot capture.


We tried to find how this feature evolved across previous samples and the older SLUB samples.


During the analysis, we found a clear indication of code sharing for the screenshot functionality.


Figure 12 shows a comparison between the two samples.


While this code may have some related “internet code sharing post” origin, both samples share it.


They also have some changes that make sense, such as removing the error “failed to take…,” since this is not required for the malware functionality.


It is likely a late refactor to the code.


Figure 12.


Screenshot functionality comparison between SLUB and APT37     Working Hours


Analyzing the compile time of binaries between different samples can also provide a level of correlation between samples.


While malware authors can fake this, useful information can still be gleaned with enough samples.


In our case, we collected many samples across 2020, and we found that the compile dates and times follow a logical timeline according to the malicious activity.


Based on our analysis, we believe the malware author did not fake the compile times of the binaries.


Other public references also used the compiled binary time of samples attributed to APT37.


When compared to the compile times seen in Operation Earth Kitsune, there are several similarities.


The compile times that are listed on binaries provide an estimate of the threat actor's working hours and help approximate possible time zones where the malware was developed.


It is fair to assume that the developers work on daily working times.


When you have many samples to analyze, you can refine that expectation over time.


Figure 14 (below) shows a raw comparison across many samples using two time zones.


We can see how the UTC+9 time zone matches those previously attributed to APT37 and those from Operation Earth Kitsune.


These both equate to the daily working times for that time zone.


Figure 13.


Compile Time APT73 and Kitsune


During the capture of samples for Operation Earth Kitsune, we managed to dump information about the Mattermost server using its API and the token used by the malware itself.


Mattermost was being used as a C2 channel for the malware.


Part of the dumped information contained the action of the user with administration roles on the system.


That user was doing manual activities the majority of the time.


At the same time, we were able to locate the Mattermost server hosted in Greece, and that gave us the current time zone of the Mattermost server.


Having that reference, we plotted the actions of all users whose information we could obtain.


It is important to remember that, except for the administrator user, all other accounts were used as part of the malware deployment (SLUB malware).


Figure 15 shows a plot with “Y” representing the number of actions.


For example, an action for the SYSTEM_ADMIN could be to create a user, add a user to a channel, etc.


The “X” axis represents the hour of the day (in 24 hours).


No months are plotted, so this figure is like compressing all the activity across the full 2020-year in one day just to show the active hours in a day.


All the plots are located in UTC+9.


Figure 14.


Mattermost server activity.


Figure 15 shows that User_3 and User_4 have like random counts.


This is because those accounts are actually the ones the malware used during the infection logging activities to the Mattermost server.


However, the SYSTEM_ADMIN account has a different pattern because the actions are mostly due to manual administration activities.


Unsurprisingly, the SYSTEM_ADMIN hours perfectly line up with the daily working hours at UTC+9.


Conclusions


While no attribution is perfect, there are striking similarities between the malware attributed to APT37 and Operation Earth Kitsune.


Little can be gleaned from each individual piece, but when viewed as a whole, the group behind Operation Earth Kitsune is likely the same one behind the Freenki malware and other malware campaigns attributed to APT37.


This is somewhat surprising, considering Operation Earth Kitsune’s espionage tools were entirely fresh-developed.


We can summarize the correlated indicators in a general form as:  Use of Korean language in the system environment of the developers Reuse of multiple TTPs during operation deployments:     GNUBoard compromised web sites     Multiple malware samples deployed at the same time     A similar organization in the deployment architecture Reliance on public services and watering hole attacks to compromised victims Some code reuse, even when the samples are completely different otherwise Working hours for both matches


Exfiltration techniques and information interest are very similar if not fully matched  While it is always possible for another group to imitate the TTPs of a different group to confuse attribution, there does not seem to be any indication of that here.


Instead, what we see in SLUB and Operation Earth Kitsune is the evolution of an advanced threat actor over time: one that builds on what worked in the past to become more efficient in the present.


Tags  Articles, News, Reports | APT & Targeted Attacks | Research


Cybercriminals and malicious hackers have been shifting their tactics, techniques, and procedures (TTPs) to improve their ability to infiltrate an organization and stay under the radar of security professionals and solutions.


Moving to more targeted attack methods appears to be a mainstay among threat actors, which requires organizations to improve their visibility into the entire attack lifecycle.


Gone are the days in which these attacks only target the endpoint, and as such, an expanded connected threat defense is paramount.


Many organizations have been adopting EDR (Endpoint Detection & Response) as a way to obtain more data about attacks on the endpoint.


But as we’ve seen with even ransomware actors, the endpoint is being targeted less.


Rather, attacks are laterally moving within an organization to find critical systems that will allow them to increase their chance of the organization paying the ransom.


(See my recent webinar on trends in ransomware.)


This means the actors behind many financially motivated and targeted attacks will move across the network, and their tracks will be left in other areas of their network, not just on the endpoint.


Expanding EDR to include other areas is the definition of XDR.


The X could be network data, email or web data, data from cloud instances, and others.


This would allow an organization to get visibility into the entire attack lifecycle, including infiltration, lateral movement, and exfiltration.


This will improve the organization’s ability to prevent critical data exfiltration or the compromise of critical systems within their network.


The ability to do this requires a number of key components:   A security vendor who has solutions across the entire network, including cloud, gateway (email & web), network, server, endpoint (includes mobile), and IoT/IIoT Support for threat intelligence and data analytics.


This should be as automated as possible and should include 3rd party threat intelligence (i.e. CERT, ISAC, ISAO feeds) History of expertise in correlating multiple threat vectors and the use of AI and Machine Learning


This will require a major shift from traditional security practices, as many organizations have supported a best-of-breed approach, utilizing multiple vendors (some say 50-100 security applications on average within a large enterprise).


Instead, the future is moving to a more consolidated approach with fewer vendors.


Having multiple vendors for different areas of security results in silos and segmentation due to a lack of integration across the security industry, but XDR could bring a shift in this practice as they include more support for 3rd party intelligence feeds.


Trend Micro has been innovating for 30 years and our breadth of security products allows us to successfully build an XDR solution.


Also, our almost 15 years of investing in and building AI/Machine Learning technologies into our backend and frontend products will allow us to have the data analytics piece covered.


Lastly, we have an extensive array of global threat intelligence that will allow us to ensure we can proactively detect and protect our customers.


Stay tuned for more information about this topic in upcoming blogs.


Tags  Cloud | Malware | APT & Targeted Attacks | Cyber Crime | Expert Perspective


On March 8, President Biden signed an Executive Order to ban the sale of Russian oil, liquefied natural gas and coal to the United States.


With bipartisan support, the decision was made to deprive the Putin regime of the economic resources needed to wage war in Ukraine.


However, marking as it does an escalation in punitive actions directed at the Russian state, it may also put US companies more directly in the firing line of cyber-attacks from the east.


Leaders of the U.S. intelligence community expressed this same concern in their annual appearance on capitol hill on Tuesday.


The Director of National Intelligence Avril Haines said “Nevertheless, our analysts assess that Putin is unlikely to be deterred by such setbacks and instead may escalate, essentially doubling down.”


The good news is that best practice cybersecurity advice does not need to change.


If the security and intelligence community continues to come together to share what information we have on offensive Russian cyber activity, and customers have the right detection and response tools in place, organizations can maintain a strong defensive posture.


Waiting for the tipping point


To date, the scale of Russian state-sponsored and proxy cyber-attacks has not been as expected.


Yes, we’ve seen continuous DDoS attacks, a campaign of web defacements and various iterations of wiper malware.


But these efforts have been mainly targeted at Ukrainian organizations.


It is possible that Russia has yet to fully engage its offensive capability, or that Ukrainian counterattacks and disruptions have hit home.


Reports suggest tens of thousands of cybersecurity professionals there have enlisted as volunteers to help the country’s efforts.


Hacking collective Anonymous has also claimed responsibility for multiple hacktivist attacks in Russia.


As kinetic attacks in the region escalate, it’s likely that cyber-operations will do the same, although these should be confined to Ukraine.


However, following the Presidential EO this week, we could well see Russian APT groups or their proxies expand their targeting of U.S. critical infrastructure.


Oil and gas, banking and defense sectors are most likely to top of the list of targets.


What we can expect If this kind of escalation were to take place, it may begin through deployment of known destructive malware like IsaacWiper, HermeticWiper and WhisperKill onto already compromised targets or systems known to be vulnerable.


Follow-on phases would see the use of DDoS or other volumetric, availability-based attacks against systems that couldn’t be compromised in the first round of attacks.


Zero-day vulnerabilities held in reserve could be exploited during this phase.


Alongside the threat from Russian state hackers, Putin may call upon the “patriotic” reserves of the numerous cybercrime groups operating from within the country.


Already the Conti and Lockbit ransomware collectives have stated their support.


However, Conti was forced to equivocate its language after a Ukrainian researcher doxxed the group with a devastating leak of source code and other internal information.


Although they may not have a choice if called upon to support the Kremlin, this incident will certainly give many Russian ransomware actors a reason to think twice about joining the war effort.


Fighting back If the worst-case scenario does unfold and US organizations are attacked en masse, normal rules of best practice cybersecurity apply.


First comes continuous risk-based patching, multi-factor authentication, network monitoring, least privilege access, data encryption, phishing awareness training, and other cyber-hygiene steps.


But on top of that, organizations must have the detection and response tooling, ideally XDR, to correlate, prioritize and act on high fidelity alerts with speed and precision.


The security community, including government agencies, should quicken their pace in sharing actionable intelligence, in order to improve public and private organizations’ threat hunting and detection efforts.


Security operations (SecOPs) leaders may also want to:  Expand training and awareness for their users and partners; Collect telemetry from sources not traditionally aligned with cyber such as supply chain vendor management.


Increase attack surface enumeration across IoT, Industrial IoT, mobile and cloud; Expand or deploy a zero trust architecture framework and;  Fortify your backups


Tags  Expert Perspective | Web | Exploits & Vulnerabilities | Cyber Threats | APT & Targeted Attacks | Articles, News, Reports | Network


With additional analysis from Cyber Safety Solutions Team Developers constantly need to modify and rework their source codes when releasing new versions of applications or coding projects they create and maintain.


This is what makes GitHub—an online repository hosting service that provides version control management—popular.


In many ways, it’s like a social networking site for programmers and developers, one that provides a valuable platform for code management, sharing, collaboration, and integration.


GitHub is no stranger to misuse, however.


Open-source ransomware projects EDA2 and Hidden Tear—supposedly created for educational purposes—were hosted on GitHub, and have since spawned various offshoots that have been found targeting enterprises.


Tools that exploited vulnerabilities in Internet of Things (IoT) devices were also made available on GitHub.


Even the Limitless Keylogger, which was used in targeted attacks, was linked to a GitHub project.


Recently, the Winnti group, a threat actor with a past of traditional cybercrime -particularly with financial fraud, has been seen abusing GitHub by turning it into a conduit for the command and control (C&C) communications of their seemingly new backdoor (detected by Trend Micro as BKDR64_WINNTI.ONM).


Our research also showed that the group still uses some of the infamous PlugX malware variants—a staple in Winnti’s arsenal—to handle targeted attack operations via the GitHub account we identified.


Malware Analysis


The malware we analyzed is separated in two files: a loader, and the payload.


The loader, named loadperf.dll, is a modified version of its legitimate, similarly named counterpart—a Microsoft file which helps manipulate the performance registry.


An extra component has been added to its sections.


It copies itself on %WINDIR%\system32\wbem\ and replaces the original DLL.


It leverages the WMI performance adapter service (wmiAPSrv), a legitimate file in Windows that collects information related to system performance, to import the loader via services.exe.


The system also imports all related DLL files and includes the payload “loadoerf.ini”.


The infection chain includes an additional (albeit empty) function imported from loadoerf.ini, gzwrite64, which works as a fake Application Program Interface (API) that serves as the payload’s entry point.


Although gzwrite64 is imported by loadperf.dll, the payload’s main function is actually located in the DLLMain of “loadoerf.ini”.


Figure 1: Extra section .idata added to the original loadperf.dll  Figure 2: Extra imported function gzwrite64


The payload is a file named loadoerf.ini that contains decryption, run, and code injection functions.


When it is loaded by the system, DLLMain decrypts the payload via CryptUnprotectData.


Since the function highly depends on the actual “machine ID”, decryption on another machine that isn’t the original infected host is not viable, making malware analysis more difficult.


Figure 3: Part of the decryption function used in the payload


After decryption, partial code is run on the machine, which is then injected to svchost.exe (a key Windows component); payload is then loaded into memory.


Figure 4: Execution/infection flow of loadoerf.ini


How is GitHub abused?


Upon successful infection, the malware starts communicating with an HTML page from a repository stored in a GitHub project.


Figure 5: GitHub account hosting an HTML page used for C&C communication


Any malware threat analyst will immediately recognize Line 3 in the image above as a potential PlugX-encrypted line.


The beginning and end markers, DZKS and DZJS, are typical in PlugX. A closer look, however, shows that the decryption algorithm is different from PlugX.


In this case, decrypting them reveals references to its actual command and control (C&C) server: an IP address and a port number the malware will connect to.


Winnti currently uses different encryption algorithms to store those C&C references in the files they stored on Github.


Among them is an algorithm utilized by PlugX.


In fact, we found references to PlugX in the C&C strings we analyzed, indicating that the group may also be using the same backdoor in this particular campaign.


Although we were unable to find a PlugX sample through that particular GitHub, we surmise some PlugX variants in the wild use this GitHub repository to get their C&C information.


Nearly all the other algorithms used in this GitHub campaign are derived from the original PlugX algorithm:  PlugX style + shift string + Base64 PlugX style + shift string + Base64 + XOR PlugX style + Base64 + XOR  One algorithm is also built in mark strings + shift string + Base64 encoding.


Following Winnti's Trails The GitHub account used by the threat actor was created in May 2016.


It created one legitimate project/repository (mobile-phone-project) in June 2016, derived from another generic GitHub page.


The repository for Winnti’s C&C communications was created on August 2016.


We surmise that the GitHub account was not compromised, and instead created by Winnti.


By March 2017, the repository already contained 14 different HTML pages created at various times.


Timeline of the Campaign


We mapped Winnti’s activities for this campaign by analyzing the dates exposed in GitHub.


For each file, GitHub stores first-and-last commit timestamps; these enabled us to create a timeline of the first use of the group’s many C&C servers.


We monitored the period during which IP addresses were found connecting to Winnti’s C&C servers and found that they started their operations in the afternoon up to late evening.


The timetable resembles traditional working hours for cybercriminals, compared to those with less structure who prefer starting their days late, but also working until very late hours.


In fact, we only observed one instance of activity during the weekend, where a new HTML file was created.


The earliest activity we tracked on the GitHub account was from August 17, 2016, with the most recent in March 12, 2017.


Here is a timeline of when the C&C server’s IP addresses were first used, based on our monitoring: Figure 6: Timeline of the C&C server’s IP addresses C&C Servers


The GitHub account used by Winnti shows 12 different IP addresses, with various port numbers used for them.


All communication to these C&C servers are done on three different port numbers: 53 (DNS), 80 (HTTP), and 443 (HTTPS).


These are typical techniques PlugX and Winnti malware variants use to communicate between compromised machines and their C&C servers.


Nearly all the C&C servers are hosted in the U.S., while two are located in Japan.


C&C Server's IP Address Port Number 160[.]16[.]243[.]129 443 (HTTPS) 160[.]16[.]243[.]129 53 (DNS) 160[.]16[.]243[.]129 80 (HTTP) 174[.]139[.]203[.]18 443 (HTTPS) 174[.]139[.]203[.]18 53 (DNS) 174[.]139[.]203[.]20 53 (DNS) 174[.]139[.]203[.]22 443 (HTTPS) 174[.]139[.]203[.]22 53 (DNS) 174[.]139[.]203[.]27 53 (DNS) 174[.]139[.]203[.]34 53 (DNS) 174[.]139[.]62[.]58 80 (HTTP) 174[.]139[.]62[.]60 443 (HTTPS) 174[.]139[.]62[.]60 53 (DNS) 174[.]139[.]62[.]60 80 (HTTP) 174[.]139[.]62[.]61 443 (HTTPS) 61[.]195[.]98[.]245 443 (HTTPS) 61[.]195[.]98[.]245 53 (DNS) 61[.]195[.]98[.]245 80 (HTTP) 67[.]198[.]161[.]250 443 (HTTPS) 67[.]198[.]161[.]250 53 (DNS) 67[.]198[.]161[.]251 443 (HTTPS) 67[.]198[.]161[.]252 443 (HTTPS)   Figure 6: IP addresses used for C&C communication, and the port numbers they use


We have privately disclosed our findings to GitHub prior to this publication and are proactively working with them about this threat.


Conclusion


Abusing popular platforms like GitHub enables threat actors like Winnti to maintain network persistence between compromised computers and their servers, while staying under the radar.


Although Winnti may still be employing traditional malware, its use of a relatively unique tactic to stay ahead of the threat landscape’s curve reflects the increased sophistication that threat actors are projected to employ.


Related Hashes (SHA256) detected as BKDR64_WINNTI.ONM: 06b077e31a6f339c4f3b1f61ba9a6a6ba827afe52ed5bed6a6bf56bf18a279ba — cryptbase.dll 1e63a7186886deea6c4e5c2a329eab76a60be3a65bca1ba9ed6e71f9a46b7e9d – loadperf.dll 7c37ebb96c54d5d8ea232951ccf56cb1d029facdd6b730f80ca2ad566f6c5d9b – loadoerf.ini 9d04ef8708cf030b9688bf3e8287c1790023a76374e43bd332178e212420f9fb — wbemcomn.ini b1a0d0508ee932bbf91625330d2136f33344ed70cb25f7e64be0620d32c4b9e2 — cryptbase.ini e5273b72c853f12b77a11e9c08ae6432fabbb32238ac487af2fb959a6cc26089 — wbemcomn.dll        Tags  Malware | APT & Targeted Attacks | Endpoints | Research

Schau mal bitte drüber


We discovered a malware family called Maikspy — a multi-platform spyware that can steal users’ private data.


The spyware targets Windows and Android users, and first posed as an adult game named after a popular U.S.-based adult film actress.


Maikspy, which is an alias that combines the name of the adult film actress and spyware, has been around since 2016.


Our analysis of the latest Maikspy variants revealed that users contracted the spyware from hxxp://miakhalifagame[.]com/, a website that distributes malicious apps (including the 2016 adult game) and connects to its C&C server to upload data from infected devices and machines.


Multiple Twitter handles were found promoting the adult game called Virtual Girlfriend and sharing the malicious domain via short links.


Figure 1. Tweets that mention Virtual Girlfriend and the short link of hxxp://miakhalifagame[.]com/ Maikspy on the Android platform  Figure 2.


Infection chain of Maikspy Android variant


Based on the analysis of samples that were last seen in the wild in March 2018, the Maikspy variant (detected by Trend Micro as AndroidOS_MaikSpy.HRX) that runs on Android poses as Virtual Girlfriend to lure users into visiting the attackers’ malicious domain.


When users open the short link version of the domain shared on Twitter, a page that shows gender option buttons will appear followed by a page that will let users choose their “first girlfriend” and lead them to the download page.


Figure 3.


Virtual Girlfriend’s option buttons (first and second screen from the left) and download page (third screen)


When the downloaded APK file is installed and launched, it will send the infected device’s Unix timestamp to 0046769438867, a phone number containing Sweden’s code.


This is presumably used for the device’s ID registration:  Figure 4.


Code snippet of the device’s Unix timestamp being sent to 0046769438867 Subsequently, the Maikspy-carrying app will display "Error: 401. App not compatible.


Uninstalling


as an attempt to deceive the user into thinking that the app is already removed from the device.


However, the spyware just hides itself and runs in the background.


There, the malicious app first checks the required permissions and then proceeds with its routine:  Steal phone number Steal accounts Steal installed app list Steal contacts Steal SMS  The stolen information will be either written into .txt or .csv formats before being uploaded to the C&C server.


After fetching and uploading the abovementioned stolen data, the malicious app will check the command (CMD) from the C&C server every 60 seconds.


The following are the supported commands:  CMD Details startrecording Start recording the sound around the device stoprecording Stop recording uploaddata Upload /sdcard/DCIM,/sdcard/Downloads, /sdcard/Movies, /sdcard/Pictures, /sdcard/Documents files getnumber Get and upload phone number getclipboard Get and upload clipboard contents sms- Send SMS get- Get and upload dedicated files getcontacts Get and upload Contacts getinstalledapps


Get and upload installed APP list getmsgdata Get and upload received SMS getmsgdatasent Get and upload sent SMS getaccounts


Get and upload Accounts tree


Get and upload dedicated directory file list


In the first launch of Virtual Girlfriend, the malicious app will use a combination of the Unix timestamp, the device’s Bluetooth adapter name, and the name of user’s Twitter account as device identification name: Timestamp_BTAdapterName_TwitterAccount.


If the user doesn’t have the Twitter app, it will just be a null string (“”).


If the user has multiple Twitter accounts, the spyware will use the account where the user is logged in.


Figure 5.


Code snippet of the process where the Unix timestamp, the device’s Bluetooth adapter name, and the name of user’s Twitter account are combined to produce a device identification name


Additionally, the spyware will open hxxp://miakhalifagame[.]com/get_access2[.]php when first installed.


It will display the page below.


Figure 6.


The spyware displays the online dating scam website upon the installation of the malicious Virtual Girlfriend app What will be shown is the registration page of an online dating site, which will lure users into giving out their credit card information.


When users register, their credit cards will be charged.


This happens when the data is uploaded with the hidden iframe found in the bottom right part of the page (underlined in red).


As a result, the attackers behind the scheme will not only obtain the credit card information of the victim, but also steal any money charged to the credit card, so long as the user doesn’t request a chargeback.


Maikspy on the Windows platform  Figure 7.


Infection chain of Maikspy Windows variant  Figure 8.


These buttons greeted users who clicked the Twitter short link of hxxp://miakhalifagame[.]com/


In the case of the Windows variant (WORM_INFOKEY.A) of Maikspy last seen in April 2017, the user will be tricked into downloading a MiaKhalifa.rar file, which contains the files seen in the screenshot below:


Figure 9.


Content of the MiaKhalifa.rar file README.txt provides instructions teaching the user how to turn off the anti-virus software and how to turn on the network, which the attacker needs to steal and upload data to its C&C server.


Figure 10.


Content of README.txt register.bat is used to gain administrator privilege.


Figure 11.


Code snippet of register.bat Uninstall.exe is a copy of the open-source hacking tool Mimikatz (https://github[.]com/gentilkiwi/mimikatz).


It has the ability to extract plaintext passwords, hash, PIN code, and Kerberos tickets from memory.


Here, Uninstall.exe is used to get the Windows account and password, and then writes the result to C:\Users\%username%\AppData\local\password.txt.


Setup.exe is the core module used to steal data.


Like the Android Maikspy, it first sends a notification to its C&C server to register the device.


Figure 12.


Code snippet of notification being sent to the C&C server to register the device


After that, it fetches .jpg, .jpeg, .png, .txt, .wav, .html, .doc, .docx and .rtf files from the following directories: C:/Users/%username%/Desktop, C:/Users/%username%/Pictures, C:/Users/%username%/Documents, and C:/Users/%username%/Downloads.


File lists of the directories are also stolen.


Subsequently, it writes them into files before uploading it to the C&C server.


Figure 13.


Code snippets of the scanning, fetching, and uploading of .jpg, .jpeg, .png, .txt, .wav, .html, .doc, .docx and .rtf files (left).


It also steal information about the machine’s system i.e. default browser, OS version, Firefox version, Chrome version, IE version and Network configuration (right).


We also stumbled upon a Chrome extension plugin (VirtualGirlfriend.crx) that Windows users can contract upon visiting hxxp://miakhalifagame[.]com.


When the extension plugin (BREX_INFOSTEAL.A) is downloaded, the victims will be instructed how to load it into the browser.


After that, the malware will collect the username and password inputs from web pages and sends it to hxxps://miakhalifagame[.]com/testinn[.]php.


Figure 14.


Instructions given to the user on how to load the malicious Chrome extension  Figure 15.


Code snippet of the malicious extension plugin Connection between Round Year Fun and Maikspy


We looked into one of the Twitter accounts (seen in Figure 1) that promoted Virtual Girlfriend.


The name of the Twitter account is Round Year Fun (hxxps://twitter[.]com/RoundYear_Fun), and its homepage is full of tweets that promote games from hxxp://www[.]roundyearfun[.]org.


Figure 16.


Twitter homepage of Round Year Fun hxxp://www[.]roundyearfun[.]org is a portal that promotes games on Twitter.


As seen in the figure below, it also has other games aside from Virtual Girlfriend.


Upon checking the cached version of the page, we discovered that it was also used to distribute the adult game first used by the attackers behind Maikspy.


Figure 17.


Virtual Girlfriend in the list of games advertised by hxxp://www[.]roundyearfun[.]org  Figure 18.


The adult game first used by the attackers was also found in the list of games advertised by hxxp://www[.]roundyearfun[.]org Our analysis revealed that hxxp://www[.]roundyearfun[.]org was also used as a C&C address to save victims’ data.


The malware also shares the same certification with Virtual Girlfriend.


One of the samples was sourced from hxxp://roundyearfun[.]org/noavi/MiaKhalifa[.]apk.


Interestingly, we discovered an image that shows the logo of Round Year Fun, found at hxxp://miakhalifagame[.]com/img/ryf[.]jpg.


Figure 19. Round Year Fun logo found at Maikspy’s malicious domain


Based on these findings, it’s possible that the attackers behind Maikspy operate //www[.]roundyearfun[.]org/ and hxxp://miakhalifagame[.]com/.


Another thing that we discovered about the games offered by Round Year Fun is that if you authorize it to use your Twitter account, the author can use the account to promote games using automation tools.


The author used the other Twitter handle in Figure 1, rifusthegr8, to tweet about Virtual Girlfriend and retweet Round Year Fun’s own Twitter promotion of the game.


History of Maikspy from 2016 to 2018


The first variant of Maikspy appeared on the Windows platform in December 2016.


It disguised itself as the adult game named after an adult film actress.


It has the ability to update itself from hxxp://fakeomegle[.]com/, and steal .jpg, .jpeg, .png, .txt, .wav, .html, .doc, .docx and .rtf files located in the Desktop, Picture, Documents, and Downloads folders, as well as information about the machine’s Internet Explorer, Chrome, Firefox or default browsers, OS, and network configuration.


The spyware connects to 107[.]180[.]46[.]243.


Meanwhile, the first Android variant of this spyware family appeared in January 2017.


It was also under the guise of the previously mentioned adult game and still connects to the aforementioned C&C server.


It was capable of recording phone calls and stealing information such as the device’s location, SMS, contacts, WhatsApp database, and record sound around the affected device.


The next variant appeared quickly, and it added the following abilities to its routines: Steal information about the device’s clipboard, phone number, installed app list, and accounts.


Meanwhile, the ability to steal the WhatsApp database was removed.


It also changed its command format.


In March 2017, another new variant appeared with the ability to steal photos when users take them using the camera.


The code structure and package name also changed, as well as its C&C address: 198[.]12[.]155[.]84.


It was in April 2017 when the last Windows variant of Maikspy appeared with the following changes: The C&C server was changed to 198[.]12[.]155[.]84, password theft is added, as well as the theft of .doc, .docx, and .rtf files.


Between June and December 2017, the Android variant had the following alterations: C&C server was changed to 192[.]169[.]217[.]55, the ability to record phone calls was removed, and the C&C server was again changed to 198[.]12[.]149[.]13.


In January 2018, the Android variant’s app label changed to Virtual Girlfriend.


Two months later, the C&C server was changed to hxxp://miakhalifagame[.]com.


The attackers were found using the HTTP protocol to transfer data.


The ability to steal location and pictures was removed from its routine.


Relationship between variants and C&C servers used by Maikspy


The attackers behind Maikspy have changed domains and IP addresses over the years, but all were found hosted in a publicly traded internet domain registrar and web hosting company in the U.S.


The following figures show how Maikspy variants from 2016 to 2018 are connected to C&C servers (found in this appendix, along with the Android and Windows hashes) used by the attackers:  Figure 20.


The connection of Maikspy variants to 198[.]12[.]155[.]84, hxxp://roundyearfun[.]org/, and 192[.]169[.]217[.]55.


Note: The green nodes represent Android samples, while the blue nodes represent Windows samples.


Figure 21. Connection of Maikspy variants to 107[.]180[.]46[.]243 and hxxp://fakeomegle[.]com  Figure 22. Connection of Maikspy variants to 198[.]12[.]149[.]13and hxxp://miakhalifagame[.]com/


Countermeasures


Downloading only from legitimate app stores like Google Play can prevent Maikspy from compromising computers and mobile devices.


It is also important to be aware of what apps are allowed to access, and to understand the risks before accepting any terms or granting certain permissions to apps.


Trend Micro’s Mobile App Reputation Service (MARS) already covers Android and iOS threats using leading sandbox and machine learning technology.


It can protect users against malware, zero-day and known exploits, privacy leaks, and application vulnerability.


End users and enterprises can also benefit from multilayered mobile security solutions such as Trend Micro™ Mobile Security for Android™ which is also available on Google Play.


For organizations, Trend Micro™ Mobile Security for Enterprise provides device, compliance and application management, data protection, and configuration provisioning, as well as protects devices from attacks that leverage vulnerabilities, preventing unauthorized access to apps, as well as detecting and blocking malware and fraudulent websites.


The Trend Micro™ Deep Discovery™ threat protection platform enables companies to detect, analyze, and respond to modern threats such as sophisticated malware, targeted attacks, and APTs.


Trend Micro™ Smart Protection for Endpoints with Maximum XGen™ security infuses high-fidelity machine learning into a blend of threat protection techniques to eliminate security gaps across user activity and any endpoint—the broadest possible protection against advanced attacks.        Tags  APT & Targeted Attacks | Endpoints | Research | Mobile | Articles, News, Reports | Network


Real enterprises are messy places.


One messy reality is that enterprises don’t manage all their endpoints.


A smart colleague turned me onto using the % of endpoints and servers managed as a prime security metric.


On one end of the spectrum are places like universities that maybe manage 10% of the endpoints on their network.


On the other end are places like some large banking and R&D companies that can manage about 98 or 99%.


A financial services company that was spending millions of dollars on getting from 96% to achieving 98%, using the very good reasoning that they were “cutting their biggest security problem in half” rather than “2%, meh.” So even the very best enterprises can have unmanaged endpoints that can be more easily exploited than ones with a security agent deployed on them.


A lot of the advanced security we’ve been delivering on the last few years has been focused on this problem.


EDR is an example of how stealthy or evasive attackers can be better uncovered than with traditional endpoint protection.


EDR is great for endpoints they are on.


Ian Loe of NTUC gives a killer example of uncovering stealthy attacks using EDR and MDR here.


But most of EDR’s capabilities are for endpoints they are on: ones they manage.


Sure there’s some herd-immunity with EDR that the greater number of managed endpoints the harder it is for an attacker to move laterally or deeper.


But more capable, patient, and stealthy attackers are getting better at being evasive, knowing that EDR may be or is deployed.


Mark Nunnikhoven does a great job in this post talking about lateral movement.


EDR can only go so far on its own to help spot attacks that are exceptionally low and slow, and/or using unmanaged endpoints.


Endpoint security needs to step outside the endpoint silo to keep step with advanced attackers.


An attack using many hops could see movement between managed endpoints, IoT, email, network components, containers and cloud-based servers over the course of many months.


The delivery and reconnaissance could involve multiple protocols, emails, payloads, files, and credentials.


Pulling together the tenuous and ephemeral threads of such an intentional attack needs more modern tools, rather than hoping we stumble on a supply of highly advanced threat hunters.


Pulling together deep security information from across your enterprise is what is needed to face off against such advanced and intentionally evasive attacks.


XDR is intended to be that security data lake of deeper enterprise infrastructure and security information than we’ve previously gathered in a single addressable pool and designed to be useful for threat hunters and analysts.


In these posts here and here we talk about what XDR is and how it brings in more sources, such as network data.


In the game of measure-countermeasure that is cybersecurity today and tomorrow, XDR is the next evolutionary step in dealing with more evasive threats.


Tags  Cloud | APT & Targeted Attacks | Cyber Crime | Expert Perspective | Articles, News, Reports | Cyber Threats


As we’ve discussed in previous blogs, XDR is a better way to detect attacks within a network since it is able to coordinate and collaborate threat intelligence and data across multiple threat vectors, including endpoint (including mobile and IIoT), server, network, messaging, web, and cloud.


In this blog I want to discuss an area of the attack sequence that can help organizations identify an attack, and that is the lateral movement.


Malicious actors, once in an organization’s network, will need to move beyond their initial infection location to other parts of the network, seeking out areas that hold the data or critical systems they wish to utilize.


Whether that is the data center, an OT network, or finding critical business systems to support their criminal or destructive intent.


There are a number of ways lateral movement is performed, but the key is to hide and remove evidence of their presence.


Initially they will look to scan the internal network using similar scanning tools used by admins to identify what systems are available to them.


Hacking tools and keyloggers will be used to steal user accounts and passwords to obtain legitimate user credentials within systems.


More tools will typically be downloaded using the command & control infrastructure to help with their attack.


After obtaining more powerful user accounts, the attacker can laterally move to other systems and use “normal” tools to perform other activities.


These activities may be difficult to identify for defenders due to the use of these things like:     PSEXEC to execute a program from remote system Schedule a remote task to execute back door or malicious code RDP or net use to connect to other hosts


Leverage WMI for fileless intrusion Execute Powershell script for fileless intrusion


Utilize exploits targeting unpatched systems for known vulnerabilities Execute normal tool like Bitlocker, to encrypt customer data like ransomware did.


But normal tools will not detect by antivirus system.


This is where adding network intelligence to an XDR and correlating with other intelligence from different areas of the network can be most beneficial.


An XDR that supports advanced detection capabilities can identify correlate data across areas to identify events that would otherwise go unnoticed.


Additionally, in many attacks the malicious actors are removing their tracks once finished with that area, so having the ability to capture and keep intelligence can help with root cause analysis and correlate the different disparate components of an attack.


This correlation allows an organization to put the pieces of the attack puzzle together to see the full picture.


Some recent RYUK ransomware attacks are a good example.


In these attacks, attackers utilized the Eternal Blue exploit and harvested credentials as they moved across the environment, and then used existing system tools to kill security services within machines to hide their presence.


In both cases the intelligence coming from endpoints, servers, and the network allowed researchers to identify the attack chain and all the components used within the attack.


Most attacks today, including ransomware, are utilizing lateral movement.


Including detection of this as part of an overall XDR platform will improve the prevention, detection, and remediation of sophisticated attacks on an organization.


Stay tuned for more upcoming blogs on how XDR will help improve our overall security strategy moving forward.


Tags  Cloud | APT & Targeted Attacks | Cyber Crime | Expert Perspective | Cyber Threats