Thursday, March 5, 2020

Bisonal: 10 years of play


By Warren Mercer, Paul Rascagneres and Vitor Ventura.

Update 06/03/20: added samples from 2020.


Executive summary


  • Security researchers detected and exposed the Bisonal malware over the past 10 years. But the Tonto team, the threat actor behind it, didn't stop.
  • The victimology didn't change over time, either. Japanese, South Korean and Russian organizations were the prime targets for this threat actor.
  • The malware evolved to lower its detection ratio and improve the initial vector success rate.

What's new?

Bisonal is a remote access trojan (RAT) that's part of the Tonto Team arsenal. The peculiarity of the RAT is that it's been in use for more than 10 years — this is an uncommon and long period for malware. Over the years, it has evolved and adapted mechanisms to avoid detection while keeping the core of its RAT the same. We identified specific functions here for more than six years.

How did it work?

Bisonal used multiple lure documents to entice their victims to open and then be infected with Bisonal malware. This group has continued its operations for over a decade and they continue to evolve their malware to avoid detection. Bisonal primarily used spear phishing to obtain a foothold within their victims' networks. Their campaigns had very specific targets which would suggest their end game was more around operational intelligence gathering and espionage.

So what?

This is an extremely experienced group likely to keep their activities even after exposure, even if we identified mistakes and bad copy/paste, they are doing this job for more than 10 years. We think that exposing this malware, explaining the behavior and the campaigns where Bisonal was used is important to protect the potential future targets. The targets to this point are located in the public and private sectors with a focus on Russia, Japan and South Korea. We recommend the entities located in this area to prepare for this malware and actor and implement detections based on the technical details provided in this article.



Victimology and campaigns


From our analysis and the intelligence shared by the community throughout the last decade of activities of Bisonal, we can conclude that the actor behind this malware is specifically targeted at the South East Asian region, namely Japan and Korea with another significant focus on Russian-speaking victims.


We identified a couple of decoy documents pointing to the victims. During the Heartbeat campaign documented in 2012 by Trend Micro, dating back to 2009, the attacker used Hangul Word Processor (HWP) decoy documents. This file format is mainly used in South Korea. The report mentioned political parties, media outfits, a national policy research institute, a military branch of South Korean armed forces, a small business sector organization and branches of the South Korean government. Later in 2018, Unit 42 released a Bisonal paper where we can see a spear-phishing campaign in Russian and a decoy document alleged to be from Rostec, a Russian state-owned holding conglomerate headquartered in Moscow.

Finally, in 2018, Ahnlab released a paper about "Operation Bitter Biscuit" where Bisonal was used against Korean and Japanese entities. India is also mentioned, but it was by another malware named "Bioazih" by Ahnlab. In this paper, the editor mentions targets such as manufacturers, defense industry and government.

Additionally, we can provide additional decoy documents. For example, a Korean document used in September 2014 where the title was "Contact member and counselor of the Agriculture, Forestry, Livestock, Food and Marine Fisheries Committee:"

Or a Russian document about the CIPR Digital conference used in April 2018. This is an application document that has been used to provide a decoy to the Bisonal malware. This conference has some high-ranking government and business attendees.

In 2019, a Russian RTF document — судалгаа.doc (research.doc) — was used with an exploit to drop the winhelp.wll file, which contains Bisonal.

Last year, we also identified multiple Korean decoy documents using similar RTF exploits to deliver Bisonal, namely ☆2020년도 예산안 운영위 서면질의 답변서_발간(1).doc (State Council Candidate (Minister of Justice Chumiae) Personnel Hearing Execution Plan (1) .doc) and 국무위원후보자(법무부장관 추미애) 인사청문회 실시계획서(1).doc (Written Inquiry from the 2020 Budget Operation Committee (Published) (1) .doc) which are both alleged government documents.

Based on our research and the released paper mentioned above, the Bisonal malware is part of the Tonto Team arsenal. Tonto Team was mentioned in the media in 2017 as one of the actors who targeted South Korea, when the country announced it would deploy a Terminal High-Altitude Air Defense (THAAD) in response to North Korean missile tests. At this time, researchers connected the Tonto Team to China.

10 years of evolution


Introduction


The first variant of Bisonal publicly released went by the name of "HeartBeat." At the end of 2019, the actor changed their TTP and started using the Microsoft Office extension (.wll) to execute the Bisonal payload. Based on this recent change, we decided to dive into the 10 years of evolution of Bisonal. To do so, we analysed more than 50 different samples and focused on the changes that appear during the years of usage.

2010: the birth


The oldest version of Bisonal we identified was compiled on Dec. 24, 2010. This version is the simplest we identified. The attacker created a Windows library (.dll) designed as a Windows service (ServiceMain() entry point). When executed, the malware uses the Windows API to communicate with the Service Control Manager (SCM) and finally execute a thread. This thread contains the code of the malware.

The C2 server of this first Bisonal variant is young03[.]myfw[.]us (port 8888). We can notice the usage of a dynamic DNS service. This is a Bisonal pattern. Even the newest version we identified used this kind of service. The domain name was not obfuscated:

The IP address is a rollback if the first C2 server is down. In this campaign, the rollback was not used as it is configured to localhost. The communication to the C2 server is performed by using raw sockets:

The first action of the malware is to send the hostname of the infected system and the "kris0315" string. The sent data is not encrypted or obfuscated. We assume the string is an identifier:

The malware supports only three commands:

  • Command execution: The execution is performed by the ShellExecuteW() API
  • Listing the running processes
  • Cleaning the malware: The malware first removes the registry key of the service and removes the library. As the library is currently running, the deletion cannot be performed immediately. The developer decided to use MoveFileEx() API with the MOVE_DELAY_UNTIL_REBOOT to remove the file at the reboot.

The malware contains the Bisonal string. It is interesting to notice the string is not used but is still visible:

The sample was used in the HeartBeat campaign mentioned above.

Sha256: ba0bcf05aaefa17fbf99b1b2fa924edbd761a20329c59fb73adbaae2a68d2307
C2 server: young03[.]myfw[.]us

2011: obfuscation my darling & more espionage capabilities


2011 March: commect()


We identified a sample from March 18, 2011. The sample is really similar to the variant from 2010. We can notice that the developers wanted to hide some API usage. They use the LoadLibrary() API followed by GetProcAdress(). But they obfuscated the function name strings by splitting it in two. Here is an example:

Once the two strings are concatenated and with the little-endian, the string becomes "commect." After the malware replaces the "m" by "n:"

They use this trick for a couple of other API such as CreateThread(), CreatePipe(), PeekNamedPipe(), CreateProcessA(), CreateToolhelp32Snapshot(), ReadFile(), WriteFile() and, finally, the string "cmd.exe."

The attacker also implemented a new order: execution of a command by using named pipe to get the output of the executed command. The attackers execute cmd.exe, followed by the command to be executed. An interesting point is the adding of a charset on each executed command:

This charset is designed to cover languages that use Cyrillic script such as Russian, Bulgarian and Serbian. This hardcoded string could be an indicator concerning the targets of this malware.

sha256 : bb61cc261508d36d97d589d8eb48aaba10f5707d223ab5d5e34d98947c2f72af
C2 server: kissyou01[.]myfw[.]us

2011 September: The big changes


The developer decided to remove the MFC library and put almost all the code in a unique function. The number of functions is divided by three. Here is the main thread graph flow:

Additionally, the string such as the domain names of the URLs is encoded by using the XOR algorithm (0x1f for example). The network communication is also obfuscated with a XOR (0x28).

On the version, the attacker supports the proxy server. It was a limitation of the previous variants. If the target would have a proxy, the malware would not be able to communicate outside. The attacker retrieves the proxy configuration in the registry:

The network communication is divided in two parts. The first part uses the Microsoft Windows Wininet library. The purpose is to send reconnaissance information to the attackers. The data is sent to the server via InternetOpenA() and InternetOpenURLA(). The C2 server of the analysed sample is hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp. The malware sent to the operator the following information: the campaign ID (named Flag by the developer), the hostname of the compromised system, the IP address, the OS version, the proxy server of the system and if the system is running on VMware. To get this information, the attacker the VMXh-Magic-Value (0x0a). The second part of the communication is dedicated to the orders and the exfiltration. This part is similar to the previous samples: raw sockets usage.

The features of the malware are the same as previously with new capabilities such as file creation and removal.

The author removed the malware cleaning feature and implements two others features: the developer adds PostThreadMessageW() to send message inside the thread and in the previous version the developer used TerminalProcess() API to stop the process executed via the named pipes, in the version the developer append the "exit\r\b" string to the executed command in order to exit properly:

Another interesting change is the fact they don't use CHCP command anymore to force the charset but use code page. You can see in the screenshot 0x4E3 (1251 - Cyrillic Russian) and 0x362 (866 - DOS Cyrillic Russian):

Sha256: 43606116e03672d5c2bca7d072caa573d3fc2463795427d6f5abfa25403bd280
C2 for the orders: dnsdns1[.]PassAs[.]us
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp

2011 October: oops where is my cleaning function?


In October 2011, the attacker re-implements the cleaning function.

In this implementation, the developer first uses the Windows service management API in order to remove the service (instead of removing directly the registry key as he did previously) and, finally, remove the file with the same API as previously (MoveFileExA()).

Sha256:43459f5117bee7b49f2cee7ce934471e01fb2aa2856f230943460e14e19183a6
C2 for the orders: jennifer998[.]lookin[.]at
C2 for rollback: 196[.]44[.]49[.]154
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp

2011 December: Not a service anymore


The new variant from December 2011 is not a service anymore but a simple library (.dll). The library is executed via a launcher (conime.exe) and the persistence mechanism is not a service anymore but a registry key (CurrentVersion\\Run\\task).

The malware is lighter than the previous version but includes more espionage features such as file exfiltration, file listing, driver listing, process-killing, file removing. The other features are the same as previously.

It is interesting to note that the obfuscated reconnaissance is still hard-coded in the binary but it is not used anymore. The code used for the reconnaissance was removed but the developer forgot the IP variable.

Sha256: 915ad316cfd48755a9e429dd5aacbee266aca9c454e9cf9507c81b30cc4222e5
C2 for the orders: v3net[.]rr[.]nu
C2 for rollback: faceto[.]UglyAs[.]com
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/mh/o.asp

Hardcoded identifiers


In this version, we identify hard coded identifiers. We assume these IDs are campaign or target ID. Here is a list of IDs:
  • 1031
  • jp0201
  • jp-serv
  • mhi
  • m1213
  • classnk
  • 95mhi
  • nscsvc

In the next version, a campaign ID will be also used. The ID we believe is in reference to Japan targets. We believe these targets to sit within both the public and private sectors and they are specifically targeted to further enhance the attacker's capabilities through espionage.

2012: File format year


February: Let's hide my code in an almost legit library


In February 2012, the developer tried to hide the malicious code in the middle of a legit library. The malicious library was named msacm32.dll and contains the same exports as a legit library from Microsoft Windows named msacm.dll. Here is the export of the malicious library with the same name than the real one:

As previously the hard-coded C2 for reconnaissance variable is here. Without being used.

Sha256: 6f8bbea18965b21dc8b9163a5d5205e2c5e84d6a4f8629b06abe73b11a809cca
C2 for the orders: since[.]qpoe[.]com
C2 for rollback: applejp[.]myfw[.]us
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp

2012 May & December: l miss services


In May and December 2012, the developers modified the .dll to come back to a Windows service.

As previously described, the hardcoded C2 for reconnaissance variable is here. Without being used.

Sha256: b75c986cf63e0b5c201da228675da4eff53c701746853dfba6747bd287bdbb1d
C2 for the orders: since[.]qpoe[.]com
C2 for rollback: 69[.]197[.]149[.]98
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp

Sha256: 979d4e6665ddd4c515f916ad9e9efd9eca7550290507848c52cf824dfbd72a7e
C2 for the orders: usababa[.]myfw[.]us
C2 for rollback: indbaba[.]myfw[.]us
C2 URL for reconnaissance: hxxp://indbabababa[.]dns94[.]com/o.asp

2012 October: Standalone PE


In October 2012, the attackers used an .exe. The attacker chose a standalone PE.

As previously the hard coded C2 for reconnaissance variable is here. without being used.

Sha256: 6f4a1b423c3936969717b1cfb25437ae8d779c095f158e3fded94aba6b6171ad
C2 for the orders: mycount[.]MrsLove[.]com
C2 for rollback: mycount[.]MrsLove[.]com
C2 URL for reconnaissance: hxxp://fund[.]cmc[.]or[.]kr/UploadFile/fame/x/o0.asp

2013: RIP


We did not identify any Bisonal samples used in 2013. The first explanation could be that it was used so much that it stays under our radar. The second explanation could be a publication from Trend Micro on January 3, 2013. In the publication, the editor described a campaign where Bisonal was used. Maybe the actor decided to stop using Bisonal?

2014: The rebirth


Packer


For the first time, the Bisonal developers decided to use a packer: MPRESS. The Bisonal string also disappears from the binary however the workflow of the malware stays the same and some features are copy/pasted from the previous Bisonal variant.

Obfuscation


The domain and the port number are obfuscated but it is not a simple XOR anymore. The developers implemented its own byte manipulation algorithm. The developer also implemented an obfuscation concerning OS detection. The OS version string is not stored as a string anymore but as bytes:

It is interesting to note that a few samples from 2014 do not use the obfuscation described above.

Malware core


The developer rewrote a large part of the code however the workflow is the same as previously and some features are copy/paste. The binary is compiled with the MFC framework.

The biggest change is the network communication with the C2 server. The malware does not use a raw socket anymore but all the communications are performed with WinInet. The malware performs connection to the C2 server by using InternetOpenA() with an hardcoded User-Agent: "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322". Note the missing parenthesis at the end of the User-Agent. This typo will be there till today.

This variant has exactly the same features as the previous variant: file listing, OS version getting, process killing, drive listing, execution via ShellExecuteW(), execution via named pipe, cleaning, file removal, file downloading.

Here is an example of code similarities on the execution via named pipe function. On the left a sample from Bisonal 2014 and on the right Bisonal 2011. The code is not exactly the same but the workflow and some constants are similar.

Hard-coded Identifiers & URL pattern


In this new version, we identify three hard-coded identifiers:

  • Campaign ID: an ID put in the exfiltrated data with the hostname and the OS version. We assume this ID is used to identify the campaign and the target by the operator;
  • Malware ID: used to generate the first "word" of the URL. We assume this ID is used to identify the malware version (from a network protocol point of view);
  • Third ID: used to generate the end "word" of the URL. It generally looks like a file name.


The URL pattern is the following: hxxp://C2_domain:PORT/MalwareIDVictimIPThirdID

SHA256: c6baef8fe63e673f1bd509a0f695c3b5b02ff7cfe897900e7167ebab66f304ca
C2 URL: hxxp://www[.]hosting[.]tempors[.]com:443/av9d0.0.0.0akspbv.txt

2016: More packers


In 2016, the developer implemented a new way of packing Bisonal. An initial static analysis immediately shows an executable with very little information. IDA Pro only shows five functions and almost no imports.


Looking at the few functions available it becomes clear the packer uses several anti-analysis tricks. In the unpacking stage, the malware has a lot of useless jumps and calls which makes the code tracking in the debugger harder.

After the unpacking is done the malware continued to use several anti-analysis measures. There are almost no direct calls to functions. It is common during the unpacking process to find useless code, like sequences of one instruction followed by a jump or increments in register values almost immediately followed by decrements. The initial unpacking is based on the manipulation of the return addresses pushed in the stack and the ordering of the data within the .text section. A second stage will allocate memory and unpack code into it, which finally will unpack code into a section that is originally empty called .textbss. This is where the core of the malware will be.

All API calls are made through a dispatcher function. Which is not called directly either, before this function is called it goes through a series of jumps and the stack is filled with encoded offset values.

The call of the jump table entry:

Push parameter for dispatch function into the stack:

Push all general-purpose registers into the stack:

Before calling the actual dispatch function, all registers are saved to the stack, by doing this the offset value is no longer on the top of the stack so the malware needs to put it back on the top of the stack.

At this time and just before the argument in the stack we also have the return address, inside the core of the malware. The dispatcher function will push the desired API function address into the stack. Afterward, it will do the same for the general-purpose registers.

After calling the dispatcher function the malware will first restore the generic purpose registers from the stack, thus leaving the API function address at the top of the stack. Logically, after the ret instruction is executed the code will jump into the API function.

This mechanism allows the malware to execute API functions without ever using the Call instruction, making it difficult to perform the analysis. The other side effect is that even after the code is unpacked if the analyst tries to dump it and analyze it statically, it will be hard for the disassembler to understand the code.

The dispatcher function has other tricks up its sleeve. Every time it is called it will use the anti-debug GetTickCount() to check if it is being debugged. If there is a discrepancy in the timing it will terminate the process. The termination can be as simple as a call to ExitProcess(), or it will first resume a thread that will display a message to the user. So that it ensures the thread has a chance to run, it will return the API call sleep() no matter what was originally requested. Once sleep() is executed, the error message thread will have a chance to be executed and will terminate the process.

From the functionality point of view, there aren't many differences between the 2014 versions. Always using three hard-coded identifiers mentioned previously but with different values.

SHA256: 15d5c84db1fc7e13c03ff1c103f652fbced5d1831c4d98aad8694c08817044cc
C2 URL: hxxp://emsit[.]serveirc[.]com/ks8d0.0.0.0akspbu.txt

2018: I miss you


During 2018, the attackers used a mix of samples using the MFC framework or the Visual C libraries. The registry key used for the persistence is now named "mismyou".

In September 2018, the developer made a mistake. Normally on this variant of Bisonal the domain names are encoded. However, the developer forgot to obfuscate the strings and put them in clear text into the variables but the deobfuscation function is still executed:



The mistake has for effect to destroy the domain and generate garbage strings. The malware will try to perfect connection to this bad domain (hxxp://硟满v鐿緲赥e ?r雀溝1kdi簽:70/ks8d0.0.0.0akspbu.txt). You can see here a screenshot of the debugger trying to perform a connect on it:

SHA256: 92be1bc11d7403a5e9ad029ef48de36bcff9c6a069eb44b88b12f1efc773c504
C2: kted56erhg[.]dynssl[.]com

SHA256: d83fbe8a15d318b64b4e7713a32912f8cbc7efbfae84449916a0cbc5682a7516
C2 fail: hxxp://硟满v鐿緲赥e ?r雀溝1kdi簽:70/ks8d0.0.0.0akspbu.txt

2019 - Office Extension and a new packer


Packer


Static analysis of this executable shows only two functions, but a regular number of imports. This time the packer shares some of the characteristics from the advanced one used in 2016.

There is a lot of useless code, including jumps and bswap operations. Upon detecting a debugger attached to it, the malware will display the message below and terminate the execution.

This message translates to "The debugger was found to be running in your operating system. This turns it off before running the program again!".

This packer also hides the calls to API functions. This time instead of using a dispatcher function, the malware pushes the arguments into the stack as usual but will then perform a call to a jump table built during the unpacking, in the .text section memory region.

Even though a call is made, these are not functions, in fact, most of the code in this jump table is useless except for the last instruction of each entry. Each entry finishes with a jmp instruction into the respective API function. Effectively the malware doesn't do any call to API functions, it always performs a jump. The return address is loaded into the stack when the malware does a call to the jump table. The end result is the same has in the packer from 2016, but with a simpler mechanism.

The majority of the code was moved into a packed area. The malware configuration (such as C2 server and the User-Agent) is outside that area. The packer uses a thread-local storage (TLS) callback to unpack some of the code. At this stage, it uses in-place unpacking avoiding memory allocations. One of the anti-analysis features included in this packer is the lack of calls to API functions. In the early stages of execution, the malware loads the libraries and retrieves the addresses from functions it needs.

Feature-wise, there is no change when compared with the 2016 version, in fact when compared the C2 beaconing functions even share some of the offsets.

Office Extension


In 2019, the actor behind Bisonal used a new way to deploy the machine on the target's systems. They sent a malicious RTF document to the targets with an exploit targeting the CVE-2018-0798 (Microsoft's Equation Editor vulnerability). The purpose of the shellcode was not to execute the malware (as it is usual) but simply to drop it in the %APPDATA%\microsoft\word\startup\ repository with the .wll extension.

The libraries in this directory with this specific extension will be loaded as a Microsoft Office extension. So next time the user opens an Office application, the malware will be loaded and executed. The purpose of the malware is to deploy Bisonal on the infected system ($tmp$\tmplogon.exe) and to create a Run registry key in order to execute Bisonal at the next reboot of the system.

We think the purpose of this multistage execution is an anti sandbox technique. If you look at the report after executing the malicious document, you only see one action: the .wll file creation. The user also needs to open an Office application and finally a reboot is needed in order to execute the real payload: Bisonal.

Bigger is better


We identified a version of Bisonal using Office extension with a really specific behavior during the installation of the malicious payload. The dropper appends 80MB of binary data at the end of the Bisonal binary:

The binary value is "56MM" is ASCII characters. If we look at the malware, we can see the appended data:

We are not sure of the purpose of the creation of a huge binary. It could be an anti-analysis technique. Some tools limit the size of the analyzed files. For example, by using the VirusTotal standard API, we cannot upload files bigger than 32MB. We also identified sandboxes that cannot handle big files correctly. Remember, size matters.

Malware code


The developer partially refactored the code. The variant from 2019 keeps exactly the same features. The two main changes are the obfuscation and the network protocol to communicate to the C2 server.

The developers used two different obfuscation algorithms: one for the C2 encoding and one for the data. The C2 encoding is a simple XOR (as in 2012):

The C2 encoding communication is also different. As the data are now sent with the GET method, the data must be in ASCII. That's they add base64 encoding in order to get supported characters in the HTTP query.

For the first time, the developer switched from POST requests to GET requests:

The exfiltrated data is appended to the URL. Here is the pattern: hxxp://C2_domain/MalwareIDVictimIPThirdIDExfiltratedDataBase64

SHA256:37d1bd82527d50df3246f12b931c69c2b9e978b593a64e89d16bfe0eb54645b0
C2 URL:hxxp://www[.]amanser951[.]otzo[.]com/uiho0.0.0.0edrftg.txt

2020 Business as Usual


Ahnlab, a South Korean software company, simultaneously published a paper regarding Bisonal's activity in South Korea. In this case, the infection vector has changed from previous samples. The initial stage is a binary that drops a decoy document (Powerpoint or Excel document), a VisualBasic script and the packed Bisonal payload. The payload is dropped with a .jpg extension that's been renamed to ".exe." Here is an example decoy document:
The purpose of the VisualBasic script is to execute the payload. Similar to attacks in 2019, the attacker appends data in order to generate a large binary. Although the malicious part of the binary is only 2MB, the final file is more than 120MB in size, padded out with random data. This may be an attempt to evade antivirus engines that only scan up to a maximum file size. The payload has been packed with a new packer.

The code of Bisonal is similar to the version of 2019. The attacker implements indirect API calls by using GetProcAddress() and LoadLibrary() API.
Sha256: b7ef3ec4d9b0fd29c86c9a4b2a94819a80c83e44cdc47a9091786d839be6a7c4
C2: imbc[.]onthewifi[.]com

Bisonal timelines summary

Conclusion


The actor behind Bisonal is clearly motivated and has an interest in Russian, Korean and Japanese victims. The development of Bisonal has been active for more than a decade. We have observed the code evolving with the different publications but also with the evolution of Microsoft Windows.

However, specific functions are still used today, many years after the original implementation of the Bional malware. Even if Bisonal could be considered as simple with less than 30 functions, it has spent its life targeting sensitive entities in both the public and private sectors. Some campaigns were even mentioned on mainstream media against military entities within the mentioned regions.

During the decade of activities, we also can see mistakes and rollbacks from the attackers. For example, in one campaign they put the domain name of the C2 server in plaintext in the malware which had the function to generate a non-ASCII string for the C2 servers once decoded. In this condition, the malware cannot work on the compromised system. Even after so many years of activities, the attackers make mistakes.

We don't see any reason why this actor will stop in the near future. With this investigation and the analysis of this decade of activity, we hope to force this actor to innovate by providing a better understanding of his arsenal and more specifically how Bisonal works.

Coverage


Ways our customers can detect and block this threat are listed below.


Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors. Exploit Prevention present within AMP is designed to protect customers from unknown attacks such as this automatically.

Cisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.

Email Security can block malicious emails sent by threat actors as part of their campaign.

Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), Cisco ISR, and Meraki MX can detect malicious activity associated with this threat.

AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.

Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.

Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.


IOCs

OSQuery

Cisco AMP users can use Orbital Advanced Search to run complex OSqueries to see if their endpoints are infected with this specific threat. For specific OSqueries on this threat, click below:

SHA256:


0cf9d9e01184d22d54a3f9b6ef6c290105eaa32c7063355ca477d94b130976af
7dc58ff4389301a6eccc37098682742b96e5171d908acdeb62aeaa787496c80a
0ff88a6cd7dcd27f14ebb7b2c97727b81e1aa701280d1164685c52c234e4a9df
8252f2cdedf16f404d43c81d005ea8ebb10594477f738e40efacf9013e1470d2
915ad316cfd48755a9e429dd5aacbee266aca9c454e9cf9507c81b30cc4222e5
1128d10347dd602ecd3228faa389add11415bf6936e2328101311264547afa75
92be1bc11d7403a5e9ad029ef48de36bcff9c6a069eb44b88b12f1efc773c504
15d5c84db1fc7e13c03ff1c103f652fbced5d1831c4d98aad8694c08817044cc
9638e7bb963ac881bd81071d305dea91b040536c55b7ee79b526b8afcfad6972
1e66579b856cd331518d67c351bcb2b102399d8ade53370797228b289e905dc1
979d4e6665ddd4c515f916ad9e9efd9eca7550290507848c52cf824dfbd72a7e
22b3a86f91d2eb5a8a1e1cdc044bcf6aca898663071be5233bac00c0f0d3c001
9c86c2dd001c47b933c6b5f43c8f87a6d0c01c066e3520e651fab51d19355d3c
2c1e0facf563bb2054d9a883144ef9bad77ba75cdb46cc80843821c363c0a9dc
a4a5c60a392d236b76907f58597e83ba9c9d4cfc6a4502ef3e0e149b8710a0c6
359835c4a9dbe2d95e483464659744409e877cb6f5d791daa33fd601a01376fc
b1da7e1963dc09c325ba3ea2442a54afea02929ec26477a1b120ae44368082f8
37d1bd82527d50df3246f12b931c69c2b9e978b593a64e89d16bfe0eb54645b0
b75c986cf63e0b5c201da228675da4eff53c701746853dfba6747bd287bdbb1d
43459f5117bee7b49f2cee7ce934471e01fb2aa2856f230943460e14e19183a6
b85e4168972b28758984f919aef2ce0fde271ee1f0863510e521a2920fcc658e
43606116e03672d5c2bca7d072caa573d3fc2463795427d6f5abfa25403bd280
bd1a9b148580dad430683639b747d1c49932db5d8f6eb2d90e2583af976810dc
436fc9530015c2d2b952a16d2a3dfa202d1cb1c577b580811b9b48355855591b
c5496dc3fa96b657ab4467c551877bbced56fd07c00c7ccb199c1794235bf710
444e864a3bb2abb1edccab4a5cd45bc0039f2a48e01615b2719da65a40a5140e
c6baef8fe63e673f1bd509a0f695c3b5b02ff7cfe897900e7167ebab66f304ca
cdba1a69d75f3e2256dccc16255aef07ded41c257b2cc95ccb801a0063445926
5caada5737b0a6c8c8f8a27bfcd0fb2221af68a4856278c3919b37279daa7409
d19b85891dd0f83808b70fbe68a56a64e828611dfe53d04a6c1c211f1352b5b5
6676934d7f214cb256407400357c1f7ead69a523b3017f6a5bc30d06a11a8305
d7692a71b85c869ee11647b80ea6d42b2e4303233c525a8fa7e6bec3599e2c8b
67e286c7308dda5cd8fe4a1340f354927e5791ce6ef0ef02c93a4e063e11c4ad
d83fbe8a15d318b64b4e7713a32912f8cbc7efbfae84449916a0cbc5682a7516
6c714653a8fa54eef1de2f0148e5e8cf514907f6f523bf09c8ee126bebcdbdcc
dd88b31275b7079899d945fc6de2dceaf7e8fc143ef24be5bb336585ddf6af1e
6cc4707942f9323347c95066a43b30f874f1b1c783960cf8ed9ecf5914f85ba7
eb7681c653ef1942103cd3272fd124eaf73e79bb830be978535c18b73c87b985
6ef4df8460ba57b836f52a9a73e2d739a3f2aa832bec6b663af53b55dc74a63d
effd31b11bdc6486082967c2d8e53d979e59a88ba28e68a1c94f5a064a8a966d
6f4a1b423c3936969717b1cfb25437ae8d779c095f158e3fded94aba6b6171ad
6f8bbea18965b21dc8b9163a5d5205e2c5e84d6a4f8629b06abe73b11a809cca
f3a30e5f8bfd0f936597bcef7cb43df11ec566467001dff9365771900e90acb1
77a36530555eada268238050996839bd34670e8bfda477c30d9dd66574625f59
f9302b7ecc32b891edeaf61353dc5e976832b7104ec0d36f1641f1f40cf6fe12
799d858ff77c29684fc1522804ed45c24171484d9618211c817df01424bc981a
23d263b6f55ac81f64c3c3cf628dd169d745e0f2b264581305f2f46efc879587
72f6a54d0d09a16e6fde9800aa845cd1866001538afb2c8f61f3606f5e13f35a
4bad5898373eb644662a8c1d5d5c674e2558908e34bb2fd915f3350b0f28752b
b7ef3ec4d9b0fd29c86c9a4b2a94819a80c83e44cdc47a9091786d839be6a7c4

C2 servers:


0906[.]toh[.]info
dnsdns1[.]PassAs[.]us
euiro8966[.]organiccrap[.]com
jennifer998[.]lookin[.]at
kfsinfo[.]ByInter[.]net
kted56erhg[.]dynssl[.]com
mycount[.]MrsLove[.]com
since[.]qpoe[.]com
usababa[.]myfw[.]us
v3net[.]rr[.]nu
www[.]amanser951[.]otzo[.]com
www[.]amanser951.otzo[.]com
137[.]170[.]185[.]211
196[.]44[.]49[.]154
21kmg[.]my-homeip[.]net
61[.]90[.]202[.]197
61[.]90[.]202[.]198
69[.]197[.]149[.]98
agent[.]my-homeip[.]net
applejp[.]myfw[.]us
dnsdns1[.]PassAs[.]us
emsit[.]serveirc[.]com
etude[.]servemp3[.]com
euiro8966[.]organiccrap[.]com
faceto[.]UglyAs[.]com
games[.]my-homeip[.]com
hansun[.]serveblog[.]net
hxxp://硟满v鐿緲赥e ?r雀溝1kdi簽:70/ks8d0.0.0.0akspbu.txt
indbaba[.]myfw[.]us
kazama[.]myfw[.]us
kreng[.]bounceme[.]net
kted56erhg[.]dynssl[.]com
mycount[.]MrsLove[.]com
navego[.]serveblog[.]net
shinkhek[.]myfw[.]us
wew[.]mymom[.]info
www[.]hosting[.]tempors[.]com
www[.]nayana[.]adultdns[.]net
www[.]dds.walshdavis[.]com
imbc[.]onthewifi[.]com

No comments:

Post a Comment