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, andMeraki 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: