Inscrivez-vous maintenant pour un meilleur devis personnalisé!
This post was authored by Alex Chiu and Xabier Ugarte Pedrero.
Talos recently spotted a targeted phishing attack with several unique characteristics that are not normally seen. While we monitor phishing campaigns used to distribute threats such as Dridex, Upatre, and Cryptowall, targeted phishing attacks are more convincing because the format of the message is personalized to the targeted user. This targeted attack was more difficult to detect because adversaries chose to leverage AutoIT, a well known freeware administration tool for automating system management in corporate environments. This notable characteristic made this attack worthy of further analysis.
Utilizing AutoIT within a payload is unique because it is a legitimate management tool. In this attack, AutoIT was utilized to install a Remote Access Trojan (RAT) and maintain persistence on the host in a manner that's similar to normal administration activity. RATs allow adversaries to fully control compromised hosts remotely to conduct malicious operations, such as exfiltrating sensitive information. The use of AutoIT is potentially an extremely effective method of evading detection by traditional anti-virus technologies and remaining hidden on the system if it is used by the target to manage systems. The combination of a legitimate administration tool being used to install a back-door onto a target system is unique and is why this attack caught our attention.
Another characteristic of this attack that was notable is how adversaries went to great lengths to spoof a phishing message that would appear credible to the user. In this attack, an actual business was impersonated, using the logo and physical address of the business, in order to appear legitimate. The bait in this case is a Microsoft Word document containing a macro that downloads and executes a binary from hxxp://frontlinegulf[.]com/tmp/adobefile.exe.
Figure 1: A screenshot of the Word document, demonstrating how adversaries impersonated a real company to trick the target.Throughout our investigation, adversaries changed the payload hosted on the external host several times. As we mentioned earlier, one particular payload that caught our attention was a self-extracting archive that used AutoIT to execute an AutoIT script and several other files. While the inclusion of AutoIT is unique, the AutoIT script contained the actual functionality that performed anti-analysis checks, payload decryption, malware installation, and persistence. This was also unusual because these bits of functionality are typically concealed and executed from an encrypted binary instead of a script. Ultimately, the actual payloads for the majority of the samples that the adversaries hosted externally were Remote Access Trojans (RATs).
Targeted phishing attacks are always a challenge to detect due to how convincing and authentic they may appear. Adversaries use these types of attacks along with social engineering tactics to convince users to run their malware. Additionally, the use of legitimate administration tools to evade traditional antivirus technologies and install malware is fairly unique. This attack shows that adversaries are constantly adapting to ensure their attacks have a greater chance of success. Understanding how the threat landscape evolves is essential to how Talos develops coverage for these types of attacks - the goal being that we increase the chances of detection with multiple approaches to detecting the same threat.
As previously mentioned, the Microsoft Word document (0BCFE9255C6308DDD36F8838EC248D8F342B0EB8BCFE248E1904E36F30A1F668) contains a macro that downloads and runs an executable from hxxp://frontlinegulf[.]com/tmp/adobefile.exe. Throughout our analysis of this attack, Talos witnessed adversaries change the executable at least three times.
The first binary Talos observed the document drop can be identified with the following SHA256:
A086A7CA8149D010AE1236C3BAC16496D366DE0080CEE37BA6B9E8AB56AAC08F
This file is a PE that is actually a self-extracting archive that contains the following:
Once all the files have been extracted from the archive, the AutoIT executable (txsexy.exe) runs immediately with the script (bpouses) passed as an argument to parse and execute.
The bpouses AutoIT script follows this general execution flow:
Upon initial execution the script will call the wekfw() function, which specifically checks for the presence of the avast process. If the avast process is present, the script sleeps for 20,000 milliseconds (20 seconds).
After the avast process check, the script progressively checks to see if certain configuration parameters are defined in the configuration file (mcey.WEK) that is included with AutoIT and AutoIT script. The configuration file is read using the IniRead() AutoIT function, which will read files that contain defined settings in this structured format:
[Section]field=value
The script looks for parameters where the Section, Field, and Value exactly match specific values. It does this in order to determine which specific function is triggered in the script. In the sample we analyzed, the configuration file defined the following parameters:
[5269015]8084590=3977349[4093447]1664943=1870865[4677522]4677522=rt9ug8f2a
The script we analyzed looked for the following (Section, Field, Value) parameters (shown here as tuples) in order to determine if the corresponding function should be triggered. Entries in italics indicate that the parameter was defined and its corresponding function executed:
After the selected checks and anti-analysis functions are executed, the script proceeds to decrypt the payload.
The decryption of the payload begins in the submain() function where the key is defined in a configuration file parameter. In this sample, the parameter is (4677522, 4677522, rt9ug8f2a) where the decryption key is the "rt9ug8f2a". This is the RC4 key used to decrypt the binary in the archive (ogrtsfsrpaz.LRD). The resulting file is a PE32 binary.
After the binary has been decrypted, the script checks for the existence of the following parameter in the configuration file before calling the _RunPE() function (which executes the 32-bit binary).
(commandline1,commandline2,commandline3)
This parameter changes the way the script calls the _RunPE() function by passing " command-line-replace" as the second function argument if the parameter is defined. This ultimately gets passed as an argument to a DllCall() function call later on.
In either case, the _RunPE() function is called and creates a process for one of the following binaries on the system: RecSvcs.exe, RegAsm.exe, or AppLaunch.exe. It creates a process for the first binary it finds on the system, immediately deallocates the new process' memory, and allocates memory for the new image (the decrypted PE). At this point, the script will then check and see if it is executing under a 32-bit AutoIT process on a 64-bit system and terminate if it detect it is. Otherwise, the script will then read portions of the decrypted binary and extract several magic values and check to make sure they match to expected values. If the values do not match, the script terminates. Finally, the script will inject the image and fix the locations using its own loader to fix everything and set the context appropriately so that the process can run.
The check for detecting whether AutoIT was running as a 32-bit process on a 64-bit system was peculiar and our investigation into why this functionality was included points to a way of potentially increasing the reliability of the script. 64-bit versions of AutoIT may present problems for custom C/C++ structures created by means of DllStructCreate(), which is used heavily to by the script to manipulate the injected process' context. It is possible that the malware authors might have had problems with AutoIT representing 32-bit structures in a 64-bit AutoIT process and left this check in, even though the AutoIT executable is 32-bit in this case.
At this point, the script will setup and run through a series of runtime checks using the configuration file to determine if certain checks should be set to run. Similar to earlier in execution, the script will check for the presence and values of certain parameters within the configuration file using the IniRead() AutoIT function. However, instead of executing a specific function immediately, the script instead registers a specific function to run at predefined intervals using the AdlibRegister() AutoIT function.
The following is a list of parameter checks that were included in the script along with the corresponding function that is registered if the parameter is defined. Entries in italics denote that the parameter was present and the corresponding function registered:
In addition to the above parameter/function registration pairs, the script also contains a list of applications which the script will inject custom messages into (which were not defined in our sample) when the user is writing a message. When the user presses Enter/Return, the script copies the message to the clipboard, triggers a Ctrl+V, and a Enter/Return. Applications that the script targets are:
Finally, if any of the previous checks have been triggered, it enters a loop checking if the file C:\ds\clean.txt exists. If it exists, it tries to protect the script using the anti_hook() function registered with the (protectprocess1, protectprocess2, protectprocess3) parameter (defined earlier). The script also checks for windows with the title equal to the path where the script is located, and closes them. The script loops on this functionality every 100ms.
The payload (19A891B4BD71E410B985598E35374A0FCB135AD01ECC65C78D9838464C1BD9E7) that gets decrypted and executed by the AutoIT script wound up being the CyberGate RAT based on the binary containing the following strings:
CODE:004095AC 00000020 unicode CYBERGATEUPDATECODE:004095E8 00000026 unicode SOFTWARE\CyberGateCODE:00409648 0000001C unicode CYBERGATEPASS
The second binary that was dropped on client boxes can be identified by the following SHA256:
7C919199F2DD490714F9F64666025509B8FA4D596C80AED3FD56F532555C0679
Analysis of this binary showed that it is a packed version of the Nanocore RAT. The first layer of unpacking decrypts the content of theqD8hIi9Fwlresource with the keypSILlzCwXBusing simple XOR. That layer is loaded reflectively and decrypts the next layer.
The encrypted content is contained within the resource namedtSrQ1Vb72t6bIXtKRand it is encrypted with the same key, following this scheme, where key represents the key, and byte_0 the content to decrypt.
English
Pусский
Français
Español
Português
num = (len(byte_0) -1) * 2for i in range(0,num+1): byte_0[i % len(byte_0)] = struct.pack("B",((((ord(byte_0[i % len(byte_0)]) ^ ord(key[i % len(key)])) - ord(byte_0[((i+1) % len(byte_0))])+ 0x100) % 0x100)))
The final layer is then processed based upon what the dropper is instructed to do. The dropper can be instructed to perform one of several actions depending upon the options defined within the Param resource string. In the sample we analyzed, the dropper was configured to create a process and inject the decrypted code into the new process. Additionally, the dropper can be configured to dump the binary to disk so that it can be run afterward or to install the binary to a specific directory and a set to run on boot up via a shortcut placed in the Startup folder.
The final binary is the Nanocore RAT, based on the strings found:
NanoCore Client.exeNanoCoreNanoCore.ClientPluginHost.IClientDataHost.get_ClientSettingsNanoCore.ClientPluginHost
Using an open source tool for decoding RATs, we were able to dump to configuration of the bot:
-----
Key: BypassUAC Value: 00Key: ClearAccessControl Value: 01Key: ClearZoneIdentifier Value: 00Key: ConnectDelay Value: 4000Key: Domain1 Value: apananco.no-ip.bizKey: Domain2 Value: Key: EnableDebugMode Value: 00Key: Group Value: STARTUPSKey: Mutex Value: f78f22f296fd1344bee71dddfe9355d3Key: Port Value: 1177Key: PreventSystemSleep Value: 01Key: PrimaryDNSServer Value: 8.8.8.8Key: RequestElevation Value: 00Key: RestartDelay Value: 5000Key: RunOnStartup Value: 01Key: SetCriticalProcess Value: 00Key: UseCustomDNS Value: 01Key: Version Value: 1.2.2.0
-----
The extracted binary has the following SHA256: F50D9134A76E3B8509D855712D66B690FAFF0A249C3D55DDCFC9EB74A7743970
The third and final binary that was dropped on client boxes can be identified by the following SHA256:
8035104E69F097393EE96C85D80C16C60C0706B6A330C1CF34D98E5FA162968D
ClamAV identifies this binary sample as Win.Virus.Tainp. However, closer analysis of the sample found that the sample is actually a Tainp sample infected with the Parite worm.
Please note that the the majority of these files are not in VirusTotal.
Hashes
Domains
Phishing attacks are a serious threat that users and organizations face everyday. While the well-known identified threats are monitored, Talos is also interested in the more subtle, hard-to-detect targeted attacks. Addressing the threat requires organizations to be aware that adversaries will adapt and evolve to overcome any obstacle they face. Using a multi-layered defensive approach that includes user education will give organizations a better chance of detecting these evolving threats. Adversaries will continue to utilize social engineering tactics, such as spoofing document origins and impersonating legitimate businesses, to try and evade detection and trick users. Defenders must remain aware of how adversaries are adapting in order to ensure appropriate detection technologies remain effective.
Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.
CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks.
The Network Security protection of IPS and NGFW have up-to-date signatures to detect malicious network activity by threat actors.
ESA can block malicious emails including phishing and malicious attachments sent by threat actors as part of their campaign.
Tags chauds:
Cisco Talos
Talos
phishing
worm
RAT
trojan
Attack
Inscrivez-vous par courriel maintenant pour le Stock de Promotion hebdomadaire
100% free, Unsubscribe any time!
Add 1: Room 605 6/F FA YUEN Commercial Building, 75-77 FA YUEN Street, Mongkok KL, HongKong Add 2: Room 405, Building E, MeiDu Building, Gong Shu District, Hangzhou City, Zhejiang Province, China
Whatsapp/Tel: +8618057156223 Tél. : + 33 (0) 3 88 88 20: 0086 571 86729517 Tel à HK: 00852 66181601
Courriel:: [email protected]