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.

Technical Analysis

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.

Executable#1

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:

• "txsexy.exe" -The Legitimate AutoIT v3 Executable
  FB73A819B37523126C7708A1D06F3B8825FA60C926154AB2D511BA668F49DC4B
• "bpouses" -An AutoIT script that, when expanded, is 600 MB.  Most of the space is occupied with 0x09 bytes and whitespace. This likely is an attempt to bypass typical anti-virus detection by making the file too big to scan.
  EAB0589C372E980AC50FADD5FFB42DA978000E216E5A5A0CF4547646D6C8DCC9
• "ogrtsfsrpaz.LRD"  -An RC4 encrypted binary that is decrypted and loaded at run-time by the AutoIT script
  D2F71B349B6A5E20BC660B62A04209074A2AD3D3460C113B04A28C1C20F57713
• "mcey.WEK" -A configuration file for the AutoIT script that determines what functionality in the script to execute. The decryption key for the binary is also contained in this file.
  71B1FDCD5EAE228A576C37D028D61E1FB907E20CBB8AF595E5F69E772ADA4773

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:

1. Initial checks, anti-analysis, and mutexes.
2. Decryption of the payload.
3. Execution of the payload.
4. Run-time checks, where for each of the run-time checks, a callback to the corresponding function is registered and run every 500/1000 ms.
5. Final loop, where the script protects itself from getting killed while the timer based callbacks and the decrypted process are executed.

Initial Checks & Anti-Analysis Functions

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:

• (fake1, fake2, fake3)
  fakemessage() -If value is present in config file (mcey.wek), then it prints a fake message value and creates check.txt.
• (delay1, delay2, delay3)
  delay() -30,000 milliseconds (30 seconds).
• (mutex1, mutex2, mutex3)
  mutex() -A mutex-like functionality that checks for instances of the self process already running.
• (4093447, 1664943, 1870865)
  startup()
  • Checks if UAC is enabled via Windows Registry and Windows CheckElevationEnabled() API call. Depending on this, it installs a vbs script either as a shortcut in the startup directory, or via the ("HKCU64\Software\Microsoft\Windows\CurrentVersion\RunOnce") registry key.
  • Creates cah.cmd and writes to it a line that launches AutoIT3 over the script.
  • Creates the aforementioned vbs script, which launches the .cmd file.
• (antis1, antis2, antis3)
  antis() -Anti-VM check, checks for VboxService.exe and VMwaretray.exe
• (botkiller1, botkiller2, botkiller3)
  botkiller() -Overwrites Registry Key ("HKCU64\SOFTWARE\Microsoft\Windows\CurrentVersion\Run") with empty value, and deletes files in the windows startup directory.
• (downloader1, downloader2, downloader3)
  downloader() -Downloads and executes a file. In the sample we analyzed, this functionality is present but not triggered (there is no download URI specified).
• (uac1, uac2, uac3)
  disable_uac() -Disables notifications to the user when a process tries to perform privileged actions (UAC)
• (systemrestore1, systemrestore2, systemrestore3)
  disable_syste_restore() -Turns off System Restore by modifying registry key ("HKLM\Software\Microsoft\Windows NT\CurrentVersion\SPP\Clients")
• (antitask1, antitask2, antitask3)
  antitask() -Disables Task Manager via the registry key ("HKCU64\Software\Microsoft\Windows\CurrentVersion\Policies\System", "DisableTaskMgr")

After the selected checks and anti-analysis functions are executed, the script proceeds to decrypt the payload.

Payload Decryption

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.

Running the Payload

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.

Runtime Checks

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:

• (protectprocess1, protectprocess2, protectprocess3)
  anti_hook() -Sets the running script as essential (NtSetInformationProcess([ProcessHandle], 29, 1, 4)), which causes the system to blue-screen if the process is killed
  
• (antibotkill-1, antibotkill-2, antibotkill-3)
  antibotkill() -Installs a VBS and BAT script, modifies the registry to execute the scripts at system boot, and install a shortcut link to the scripts into the startup directory to ensure the malware starts upon boot up
• (5269015, 8084590, 3977349)
  persistence() -Installs the startup VBS script if it has not yet been installed and executes it.
• (systemhide1, systemhide2, systemhide3)
  systemhide() -Hides the hidden files and disables folder options in the File Explorer via modifying the following registry keys
  • ("HKCU64\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer", "NoFolderOptions")
  • ("HKCU64\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced", "ShowSuperHidden")
• (antitask1, antitask2, antitask3)
  antitask() -Disables Task Manager via the registry ("HKCU64\Software\Microsoft\Windows\CurrentVersion\Policies\System", DisableTaskMgr)
• (uac1, uac2, uac3)
  disable_uac() -Disables notifications to the user when a process tries to perform privileged actions (UAC) via modifying the registry.

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:

• Skype
• Facebook
• Steam
• Omegle
• TinyChat
• RuneScape

The Final Loop

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

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

 

Executable#2

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.

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

Executable#3

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.

Additional Info

Please note that the the majority of these files are not in VirusTotal.

Hashes

• 0BCFE9255C6308DDD36F8838EC248D8F342B0EB8BCFE248E1904E36F30A1F668
• A086A7CA8149D010AE1236C3BAC16496D366DE0080CEE37BA6B9E8AB56AAC08F
• EAB0589C372E980AC50FADD5FFB42DA978000E216E5A5A0CF4547646D6C8DCC9
• D2F71B349B6A5E20BC660B62A04209074A2AD3D3460C113B04A28C1C20F57713
• 71B1FDCD5EAE228A576C37D028D61E1FB907E20CBB8AF595E5F69E772ADA4773
• 7C919199F2DD490714F9F64666025509B8FA4D596C80AED3FD56F532555C0679
• F50D9134A76E3B8509D855712D66B690FAFF0A249C3D55DDCFC9EB74A7743970
• 8035104E69F097393EE96C85D80C16C60C0706B6A330C1CF34D98E5FA162968D

Domains

• apananco.no-ip.biz
• frontlinegulf.com

Conclusion

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.

Protecting Users

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.