Authored by Neil Tyagi
In cybersecurity, threats constantly evolve, and new ways to exploit unsuspecting users are being found. One of the latest menaces is a recent AsyncRAT variant, a sophisticated remote access trojan (RAT) that’s been making waves by marketing itself as cracked software. This tactic plays on the desire for free access to premium software, luring users into downloading what appears to be a harmless application. However, beneath the surface lies dangerous malware designed to infiltrate systems, steal sensitive information, and give cybercriminals complete control over infected devices.
In this blog, we’ll examine the mechanics of AsyncRAT, how it spreads by masquerading as cracked software, and the steps you can take to protect yourself from this increasingly common cyber threat.
McAfee telemetry data shows this threat has been in the wild since March 2024 and is prevalent with infected hosts worldwide.
-
- We have many initial vectors for this chain, masquerading as different software
-
- Theme: CCleaner. Hash: 6f976e1b53271178c2371bec7f64bd9cf2a2f936dc9670c40227c9d7ea56b8e6
-
- Theme: Sidify Music Converter. Hash: 9aaabe9807f9ba1ad83bbb33b94648d32054f9dc575a5b77f92876d018eed91c
-
- Theme: Ease US Partition Master. Hash: 84521572d3baeb218996daa3ab13be288b197095a677940146bf7a0285b71306
-
- Theme: YouTube Downloader Hash: 00a1afd74d1a40593539a4e9115ab4c390cad9024d89931bd40d4279c95e9b6a
-
- Asyncrat is coming in the theme of AnyDesk software. HASH: 2f1703c890439d5d6850ea1727b94d15346e53520048b694f510ed179c881f72
- In this blog, we will analyze the AnyDesk-themed malware; the other noted themes are similar in nature.
- Also, note that the setup.dll file shown in the above pictures is the same as it has the same hash.
-
- Anydesk 8.0.6 Portable.exe is a 64-bit .NET file. However, it is not the original Anydesk file; it is malware.
-
- Carried within the malware is an Anydesk.data file, the genuine anydesk application.
-
- We can confirm that the Anydesk. data file has a valid digital signature from the publishers of Anydesk software.
-
- When we rename the anydesk.data file to anydesk.exe, we can also see the anydesk software running.
-
- Setup.dll is a bat file, as we can see in the above image
- We start debugging by putting the malicious AnyDesk executable into the Dnspy tool to review the source code.
-
- The primary function calls the IsAdmin function, which checks the current context of the running process. Based on this, it calls four functions in succession: AddExclusion, CopyAndRenameFile, RunScript, and ExecuteScript. We will check each function call separately.
- The primary function calls the IsAdmin function, which checks the current context of the running process. Based on this, it calls four functions in succession: AddExclusion, CopyAndRenameFile, RunScript, and ExecuteScript. We will check each function call separately.
-
- The AddExlusion function passes the above string into the RunHiddenCommand Function.
- The AddExlusion function passes the above string into the RunHiddenCommand Function.
-
- Runhidden command will take that string, launch an instance of PowerShell, and execute that string as an argument.
- This will effectively add a Windows Defender scan exclusion for the entire C drive.
- The CopyAndRenameFile Function will rename the setup.dll file to the setup.bat file and copy it to the appdata\local\temp folder.
-
- After the bat file is copied to the temp folder, it will be executed using a process start call.
- After the bat file is copied to the temp folder, it will be executed using a process start call.
-
- Now, to convince the user that he has indeed opened the AnyDesk software, the AnyDesk.data file containing the original AnyDesk software will be renamed AnyDesk.exe.
- This is the whole purpose of the malware AnyDesk.exe file. Now, the attack chains move to execute the bat script, which we will analyze further.
- The bat file uses dos obfuscation
- It is setting environment variables to be used later during execution.
- Also, lines 6 and 7 have two long comments and an encrypted payload.
- In line 13, it echoes something and pipes it to the %Ahmpty% environment variable.
-
- We can easily deobfuscate the strings by launching an instance of cmd, executing the set commands, and echoing the contents of the variables.
- One thing to note here is that %variablename% will echo the entire contents of the variable, but %varibalename:string=% will replace any occurrence of “string” in the contents of “variable name” with a null character.
-
- The above image is after deobfuscation of all strings and formatting of the script in a human-readable form.
- Script first sets @echo as off
- Then, it checks if the environment variable Ajlp is set. If not, it sets Ajlp to 1 and again starts the execution of the bat script (%0 contains the path to the same script) in minimized form, exiting the original script.
- Then we have our two comments, which later turn out to be encrypted payloads
- Then the script checks which version of PowerShell is present on the system because, for older versions of Windows, PowerShell is sometimes located in the syswow64 folder. For successful exploitation of those versions of Windows, this check is done
- Then, a long script is echoed at the end and piped for execution to PowerShell.
- One interesting thing to note is that %~0 is echoed as part of the script and passed to PowerShell for execution. This trick passes the path of the bat script to the PowerShell script for further processing.
-
- Difference b/w contents of %0 and %~0 variable, you can notice they only differ in double quotes.
- Difference b/w contents of %0 and %~0 variable, you can notice they only differ in double quotes.
-
- Moving on to the PowerShell script, we can see it sets the PowerShell window title to the path of the bat script using the $host. UI.RawUI.WindowTitle call.
- As we saw before, this path of bat script was passed to it during echo of %~0 environment variable in bat script.
- Then we have some string replacement operations.
-
- We can see the contents of the variable after the string replacement operation is done. It is being used to hide strings with malicious intent, such as invoke, load,frombase64string, etc.
- Then we have a command to hide the PowerShell window
- Then we have two functions. The first one is used for AES decryption, and the second one is used for Gzip decompression
- Then, we have some operations that we will investigate in detail next.
- Then we have two calls to System.reflection.assembly, which reflectively loads the assembly into memory.
- This is the deobfuscated and high-level view of the script for easy readability.
-
- We can see that the $lmyiu variable contains the contents of the entire bat file. It reads using the System.IO.File call, which takes a parameter of the path supplied through [console]: Title. We know the title was set to the path of the original bat script at the beginning.
- Now, indexes 5 and 6 are being read from the bat file, which translates to lines 5 and 6, which contain the comments (indexing starts from 0).
- Now, the first two characters are removed using substring to remove the two colons (::) which represent a comment in the bat file
- In the above image, we can see the output of that line, which contains the comment.
- Now, the comment is converted from a base64 string and passed to a function that does AES decryption. The result is passed into a function that does GZIP decryption and stored in the assembly1 variable. The same thing happens for the second comment to get the second assembly.
- Once both assemblies are decrypted, they are reflectively loaded into memory using the System.reflection.assembly call.
- We can dump the two decrypted assemblies onto the disk for further analysis, as shown in the above image.
- After writing to disk, we load both assemblies in CFF Explorer.
- Assembly1 in CFFExplorer.
-
- Assembly2 in CFFExplorer.
- Assembly2 in CFFExplorer.
-
- We load both assemblies into Dnspy for further debugging.
- We can see that both assemblies are heavily obfuscated using Confuser Packer, and their contents are not easily readable for analysis.
- This is intended to slow down the debugging process.
- We will use the .NET reactor slayer to deobfuscate the two assemblies. This will remove the confusing obfuscation and give us readable assemblies.
- We use it for both assemblies and write the deobfuscated versions to disk.
- When we load the assemblies into Dnspy, we see they have cleaned up nicely, and confuser obfuscation is entirely removed.
- We can see first it checks the console title of the current process.
- We can also see a few anti-debugging API calls, IsDebuggerPresent and CheckRemoteDebuggerPresent. If any of these calls return true, the program exists.
- After that, there is a call to smethod_3
-
- Inspecting the smethod_3 function, we see some encrypted strings, all of which are being passed as arguments to the smethod_0 function.
- Inspecting the smethod_3 function, we see some encrypted strings, all of which are being passed as arguments to the smethod_0 function.
-
- By checking the smethod_0 function, we get the StringBuilder function, which will be used to convert the encoded strings into readable form.
- By checking the smethod_0 function, we get the StringBuilder function, which will be used to convert the encoded strings into readable form.
- We put a breakpoint on the return call to see the decoded string being populated in the local window in case it is related to a scheduled task.
- Checking further, we get the call where the assembly is being written to disk in the appdata\Roaming folder with the name Network67895Man.cmd using the file.WriteAllBytes call. We can inspect the arguments in the local window.
- In the above image, we see that the Network67895Man.cmd file is being executed using the process. Start call.
- We can confirm that the hash of Network67895Man.cmd and our assembly are the same. We can also visually confirm that the file is in the appdata\roaming folder.
- Now that we see the persistence mechanism, we can see the return value of our string builder function related to the scheduled task.
- We copy the complete string and inspect it in Notepad++. We see that the PowerShell command is used to schedule a task named ‘OneNote 67895’. This will trigger At Logon, and the action is the execution of the Network67895Man.cmd file with some more parameters.
-
- We can confirm the task being scheduled in the Task Scheduler window.
- Moving on, see how the next stage is decrypted and loaded into memory
- One thing to observe here is that this assembly contains a resource named P, which turns out to contain the encrypted next-stage payload.
-
- Dumping the resource onto disk and checking its content, we see the encrypted payload bytes starting from 1F 8B 08 00…
- Dumping the resource onto disk and checking its content, we see the encrypted payload bytes starting from 1F 8B 08 00…
- In the local window, we can see the string P is being passed to the smethod_3 function, which will read the resource stream and the bytes of the P resource.
- We can confirm that the bytes have been read from the resource and can be seen in the local window in the result variable. We can see the same bytes, i.e., 1F 8B 08 00.
- Now, we put a breakpoint on the load call and inspect the contents of the raw assembly variable to see the decrypted payload.
- We dump it on the desk for further inspection.
- Checking it in CFF Explorer, we see this is also a 32-bit. net assembly file with internal name of stub.exe
-
- Putting it in Dnspy, we can see an unobfuscated Asyncrat client payload named AsyncClient.
- We can see all the functions in clear text, like Anti-analysis, Lime logger, mutex control, etc.
- This is the final Asyncrat client payload that we have got after so many layers of the attack chain.We will now see some interesting features of the Asyncrat payload.
-
- We can see it has its own persistence mechanism, which checks if the file is running as admin. If true, it creates a scheduled task by launching cmd.exe; otherwise, it creates a run key in the Windows registry for persistence.
- We can see it has its own persistence mechanism, which checks if the file is running as admin. If true, it creates a scheduled task by launching cmd.exe; otherwise, it creates a run key in the Windows registry for persistence.
- We can see the encrypted config of the Asyncrat client, including the port used, host, version, key, etc.
- We can see the decrypt method is called on each config parameter. In the above image, we have documented the Asyncrat CNC domain that it is using, orostros.mywire.org
- It turns out that this is a dynamic DNS service that the malware author is abusing to their advantage.
In conclusion, the rise of AsyncRAT and its distribution via masquerading as cracked software highlights the evolving tactics, techniques, and procedures (TTPs) employed by cybercriminals. By exploiting the lure of free software, these attackers are gaining unauthorized access to countless systems, jeopardizing sensitive information and digital assets.
Understanding these TTPs is crucial for anyone looking to protect themselves from such threats. However, awareness alone isn’t enough. To truly safeguard your digital presence, it’s essential to use reliable security solutions. McAfee antivirus software offers comprehensive protection against various threats, including malware like AsyncRAT. With real-time scanning, advanced threat detection, and continuous updates, McAfee ensures your devices remain secure from the latest cyber threats.
Don’t leave your digital assets vulnerable. Equip yourself with the right tools and stay one step ahead of cybercriminals. Your security is in your hands—make it a priority today.