Formbook Phishing Campaign with old Payloads

Recently, Seqrite Lab saw a phishing campaign delivering formbook stealers through email attachments. Formbook, as seen since 2016, has evolved in many ways from stealth features to evasion techniques. Being sold on hacking forums as Malware as a Service, we can see a number of variants. While the evasion technique remains the same, multiple layers are used before deploying the payload, and they are loaded only in memory to avoid getting identified. As with other variants, this also uses steganography to hide malicious files inside images, decrypting them to load and invoke in memory.

This variant contains three stages before the final payload

1. Purchase Order.exe/XXXI.exe
2. Arthur.dll
3. Montero.dll
4. MASM(Final Payload)

Technical Analysis:

 It starts with a spear phishing email containing a purchase order along with an attachment of zip file. Upon extraction it contains only a single pe file PurchaseOrder.exe which is a dotnet compiled binary. 

                                      

 

Stage 1 (Purchase Order.exe):

This variant hides stage 2 and stage 3 malware in the resource of Purchase Order.exe. Resource name “Hkyl” as shown in Fig 2 is stage 3 binary.
Initially, the malware sleeps for nine seconds before proceeding to decrypt stage 2 payload. As shown in Fig 3 it retrieves stage 2 encrypted data from APP resource present in resource of Purchase Order.exe and stores it in the bytes array. It also stores 16 bytes of decryption key for stage 2 payload which is “AP7H9H5OI4478F8CH05FGA”.

 

Before decrypting stage 2 payload, as shown in Fig 4 it creates 3^rd array of size 256 bytes and initializes it with value from 0 to 255.

 

After that it sets up array3 by copying 16 bytes key into random positions.

Once it sets up the array3 value, it performs xoring of encrypted data with array3 and saves it in array2 which now contains Stage 2 PE file arthur.dll,

In order to execute the stage 2 dll file it uses InvokeMember() to load decrypted assembly ( Arthur.dll) into the memory  by Load method. As shown in Fig 5 it doesn’t use the Load function directly but gets the value from an object, value of HJ is Load.                                                                       

Stage 2 (Arthur.dll):   

Once loaded in memory, it invokes MainForm.Justy() from stage 2 PE file with three arguments. It uses these arguments in the stage 2 PE file to get stage 3 PE file.                                 

 

Stage 2 PE file is obfuscated by smart Assembly. As shown in Fig 6, there are three arguments passed to this method.

• WA = “486B796C”=Hkyl (Resource in PurchaseOrder.exe, Fig 2)
• WZ = “62616F”=bao (Decryption Key for stage 3)
• @namespace = “AssessExampleCombatForm”[Project Name of PurchaseOrder.exe]

Initially, this stage 2 sleeps for fourteen-seconds before proceeding to decrypt its stage 3.

This function decrypts an image by using a key passed as an argument then it extracts the red, green, and blue values from each non-transparent pixel in an image and creates an array.

 

This array when XORed by using value[bao] passed during stage 2 brings stage 3 montero.dll which is also loaded in memory using Assembly.Load methd. After obtaining the main method gnWmyvSdDoAS8VNPBy.ukHjJHqoK1() of stage 3 module it invokes it.

Stage 3 (Montero.dll):

In this stage 3 PE file, before invoking the main method ukHjJHqoK1(), its constructor decrypts required configuration settings. These settings contain decryption key of final payload, mutex name and mutex flag enabled or not, file dropping location, file download behavior is enabled or not ,file download location etc. these configuration settings stored in the array[gnWmyvSdDoAS8VNPBy.YiEuqBAod0]

 After decrypting the configuration settings, it checks if the Mutex flag is enabled in 29^th location of array YiEuqBAod0, if true, it creates mutex with name “zpkpGXyWHvBpdzNULuLRtAzq”. If the mutex is already present, it will terminate itself. This behavior is commonly implemented to evade detection by security vendors and to avoid running a second instance of the same malware. Then it verifies the Sleep flag, if enabled, it would sleep to delay its execution for sandboxes to not capture its malicious behavior.

Then it checks if the message box displaying flag is enabled in 30^th location of array YiEuqBAod0, if enabled, it pops the message box to deceive the user.

After that it verifies 10^th location of array YiEuqBAod0 which is used as exclusions path capability. If enabled, it adds the malware path in exclusions and execute this cmdlet by LOL binary[powershel.exe] in hidden window attributes to evade detection of AV vendor as well as hide their behavior from victim.

5^th location of array YiEuqBAod0, this location is used as either download another payload or update the task feature. If this flag is enabled, it downloads another malware family or receives command from the threat actor C2 and inserts that command in XML file in %temp% location and execute that file from %temp% location. This xml is given as import in the schedule task.

2^nd location of array YiEuqBAod0, the threat actor used this location as file dropping. If this flag is enabled, the malware initially checks “qwwnzxGmN.exe” whether the file already present in the “C:UsersusernameAppDataRoaming” of victim’s host. If that file is not present in that location, it creates the file with hidden attribute set, self-copy of parent file. This property can be used by attackers to disguise this malware’s presence to prevent administrators and users from finding it.

Once the parent file is self-copied in the “%appdata%Roaming” location as mentioned in Fig 14, this file will be added in the exclusion path. Then it decodes the base64 encoded data, which was decrypted in the constructor of main method of stage 3, to string which is a XML file. This XML file contains a value that generates a task. These values are malware file hidden attribute, persistence, feature enabled, command execution of file path etc.

 

 

This XML file is created in the %temp% location as “*.tmp”, then it updates their required values in the XML file such as ‘”Location” and “USERID” etc. After that it creates scheduled task with hidden widow attribute for hide their behavior from victim for persistence such as “updatesqwwnzxGmN” and import that XML file. The threat actor deleted tmp file to avoid the traces for security analyst .

Fig 18 shows 3^rd stage module decrypting the final payload. The variable gnWmyvSdDoAS8VNPBy.AtOuOF5iCk = “4kQLt8DIME” is the name of resource(in motero.dll). gnWmyvSdDoAS8VNPBy.NJMuDv6Sv6 = “pqDVZxpXC” is the key. It loads the resource and passes it to the decryption method Pp62t2mj9p along with The KEY.

Decryption method stores final payload in gnWmyvSdDoAS8VNPBy.w9Yu0dnomp.

This final payload is a 32-bit, MASM compiled binary with only the “.text” section. Its highly obfuscated file decrypting and encrypting code on the basis of requirements.

Once decrypted the final payload in the buffer it checks the 1^st location of the array YiEuqBAod0, based on this value it selects the target process for process hollowing. Threat actor has provided the value 0 to 4. If the value is 4 it loads the final payload in the memory by assembly load method and  executes entry point of final payload .

if the value is “1” it selects target process name as MSBuild.exe for process hollowing, if the value is  “2” the target process name is vbc.exe, if the value is “3” the target process name is RegSvcs.exe. If none of the above value is mentioned then it selects the target process as parent file.

 

In Stage 3 constructor it decrypted the API sequence for Process hollowing in Method bLmuzQDIA5()  stored CreateProcessA, this malware create the targeted process based on the above value Fig 17 and creates that process in the suspended  mode.

Method je3uFjEe5y() stored the WriteProcessMemory, it decrypted final payload “.text” section in the targeted process memory .

IOCS:

6A9F890C529C410FA32793F496E7F200

0DA34A44EE4876DD5E35939AF02F1D32

D751816C3673935BF989716ABD0DAB21

F8EC1BE3F2BD8269DB033375ED1A841E

 

 

Detections:

            Trojan.Formbook.S34651912

 

Yara rule :

 

import “pe”

rule Formbook_varainat

{

strings:

$s1=”AP7H9H5OI4478F8CH05FGA” wide ascii

$s2 ={67 B7 76 87 0A C8 C4 5E 29 AC 76 8F 70 E8 6E 09 91 40 4A AE 28 D5 7F CE AB 90 4B D3 07 C1 A8 B2 A0 B3 88 B9 58 F3 CA A9 43 9D C5 C1}

$s3 ={78 33 66 C6 4D CD 82 2F B8 D6 10 8A B7 E9 D5 65 8B 45 1A B7 ED 08 2E B3 89 2F 0B 89 75 F5 08 5D}

condition:

all of them

}

 

MITRE ATTACK TTPs:

 

Tactic	Technique / Procedure
Initial Access	T1566.001: Spear phishing Attachment
Execution	T1059.001:Command and Scripting Interpreter:PowerShell
	T1053.005:Scheduled Task/Job:Scheduled Task
Persistence	T1053.005:Scheduled Task/Job:Scheduled Task
Defense Evasion	T1027.003:Obfuscated Files or Information:Steganography
	T1036:Masquerading
	T1497:Virtualization/Sandbox Evasion
	T1055.012:Process Injection:Process Hollowing
Discovery	T1082:System Information Discovery
	T1083:File and Directory Discovery
	T1057:Process Discovery

 

Conclusion:

With malware as a service, we can see multiple versions of formbook. Often the wrapper keeps on changing but the final payload remains the same, this is to avoid AV detections. Threat actors deliver this malware through spear phishing mail in which attached are malicious documents or executable binaries. Users are advised to avoid opening suspicious emails with attachments. This variant implements evasion techniques to maintain persistence. Avoiding getting caught by system administrator or user by hiding file attribute. Ensuring only one instance of malware is running in the system by creating mutex.

 

Author: Rumana Siddiqui and Manoj Kumar Neelamegam

The post Formbook Phishing Campaign with old Payloads appeared first on Blogs on Information Technology, Network & Cybersecurity | Seqrite.