Executive Summary

Malware 591d32 (an Emotet variant) is a sophisticated reconnaissance tool that profiles victim systems by harvesting OS and security software details. Its advanced stealth and persistence mechanisms provide attackers with a hidden foothold, making it a highly probable precursor to a follow-up attack such as ransomware or data theft. High severity. Immediate action required

Technical Analysis

Technical Summary

Note: The list of discovery items are not exhaustive and further investigation may be required to map out the full extent of what information is being gathered. Analyst strongly believes this is used to profile before a follow-up attack campaign due to the sheer amount of defense evasion techniques employed.

N.B.: Static detection rules may not be completely effective in detecting this sample. Behavior detection tool is strongly recommended.

Objective: Information gathering

ATT&CK Kill Chain:

Key Findings:

1. Evasion via multiple methods, with emphasis on API resolution via PEB Walking and custom polynomial API hashing
2. Persistence via service and registry creation
3. Queries OS information, running processes, and potentially other data
4. Employs data serialization and hybrid encryption (AES for DEK, RSA for KEK) to encrypt stolen information
5. Exfiltrates encrypted data via HTTP

Critical ATT&CK:

1. T1027.007
2. T1005
3. T1041

Critical IoC:

1. SHA256: 591d32aeae0554f744df8843727e794d33495ff0a4b90a9f7861ab526988ded7
2. “shlpchx” key in Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and services list
3. HTTP Communication to 201[.]184[.]105[.]243

For an exhaustive list of ATT&CK and IoC, consult Appendix A and Appendix C.

Deep Dive

Initial Access (T1204.002)

It’s assumed that the malware is deployed post-exploitation as analyst did not find any evidence of exploitation/escalation that could be present in the malware

Anti-Analysis

Dynamic API Resolution (T1027.007)

In order to gain access to critical functions and evade detection, a PEB walk is performed whenever a critical library needs to be loaded into malware context

To resolve the functions, a custom polynomial API hash algorithm was implemented in the malware:

Then this hash would be compared against known hash table depending on the context of the loaded libraries (one of NTDLL, kernel32, crypt32, shell32, urlmon, wininet, wtsapi32, userenv):

For example here, 0x7A3B4F94 translates to DestroyEnvironmentBlock. Some of these values are filled with garbage as there are only about 150 hashes (hash list available in Appendix D) that resolve to a named function out of 2193 and less that analyst saw usage through the analysis session.

String Encryption (T1027.002)

By leveraging encryption, it can hide the string required to load a library, do format print, or simply to call library functions.

Some of these string decryption and construction return value can be used to construct the true string:

As seen in picture above, ESI register (output of “malware_construct_str” function) contains a bunch of comma delimited strings that was passed in the “malware_generate_str” function to output a different string entirely, resulting in a “streamtoner” wide string. This will be used frequently in the malware to avoid static detection tools since the original data source came from a blob of gibberish data.

SysWOW64 Masquerading (T1036.005)

The malware performs a move of its own file to system location to achieve two objectives: persistence and masquerading.

Anti-Forensic

Zone Identifier Deletion (T1564.004)

Zone.Identifier is an Extended Attribute in NTFS to particularly store data of whether this file comes from the internet or locally. Malware deleting it erases the origin of the file, avoiding forensic analysis.

Persistence Phase (TA0003)

After the malware was moved to windows directory, Service is created:

Registry (T1547.001)

At some point in the execution, malware creates a registry as second part of persistence method:

Discovery Phase (TA0007)

Information regarding currently run process was collected via CreateToolhelp32Snapshot function:

In addition, OS information was queried via RtlGetVersion and GetNativeSystemInfo:

Last one is to derive a unique identifier based on desktop name and CRC32 of the binary:

These are the only three that are confirmed by the analyst to be exfiltrated later. Other information such as directories and such are not confirmed as of the writing.

Exfiltration Phase (TA0010)

Encryption (T1573)

It’s important to know that malware actually implements unknown data serialization algorithm based on the gathered information from the discovery phase:

Next it would import an RSA public key from the same gibberish blob of data and proceeds to generate an AES-128 key to encrypt the serialized data with:

It’s unknown where the hash result is used, likely as part of HMAC.

HTTP Request (T1071.001) and Base64 Encoding (T1132.001)

Malware establishes communication with C2 server in order to send the now serialized, encrypted, and base64 encoded data:

For more details consult Appendix D.

Analysis Insight

Key Challenges and Resolution

1. Malware relaunching: In order to avoid complete analysis by public sandbox tools (any.run, cuckoo, etc.), the malware attempts to relaunch itself with arguments and validate said arguments in order to launch real malware functions. Solution: Manipulate the program execution flow via debugger. Accuracy may suffer since preconditions are not fully met but it gives the analyst a lot more context regarding the program in a single analysis session.

Novel Findings

1. Custom polynomial hash for windows API
2. Process enumeration
3. Extended Attribute deletion
4. Malware relaunching multiple times to avoid analysis tools

Analysis Difficulty

1. This is the longest sample yet in terms of analysis time: spread of 8 days including this very report writing due to various issues
2. Figuring out data serialization

Appendix A — Indicators of Compromise

Indicators of Compromise

Appendix B — Detection Recommendations

YARA

Appendix C — ATT&CK Entries

ATT&CK

Appendix D — Analysis Artifacts

Artifacts.pdf

Appendix E — References

FILE_OPFLAGS used for SHFileOperation: https://www.pinvoke.net/default.aspx/Enums/FILEOP_FLAGS.html

Executive Summary

Malware Petya implements sophisticated anti analysis techniques to encrypt computers for financial motive. KEY RECOVERY POSSIBLE, High severity. Immediate action required to prevent further damage.

Technical Analysis

Technical Summary

Objective: To encrypt computer at bootloader level for financial gain via ransom

ATT&CK Kill Chain:

Key Findings:

1. Evasion via PEB walk and in-memory loading
2. PhysicalDrive access in order to query boot sector information and overwrite it
3. Derives symmetrical key from AES-CTR-128 algorithm and custom SHA256
4. Overwrites bootloader with malicious bootkit
5. Triggers kernel-level exception to force malicious bootkit to load

Critical ATT&CK:

1. T1620 Reflective Loading
2. T1486 Bootkit Encryption
3. T1491.001 Ransom Display

Critical IoC:

1. Dropper SHA256: 26b4699a7b9eeb16e76305d843d4ab05e94d43f3201436927e13b3ebafa90739
2. Real malware SHA256: ae8aad97ce7d2b95911f8e1b602fbbc69d6b2b127c90cd08e66c34b1621a763f
3. C2 URLs:

• hxxp://petya5koahtsf7sv[.]onion/
• hxxp://petya37h5tbhyvki[.]onion/

For an exhaustive list of ATT&CK and IoC, consult Appendix A and Appendix B.

Deep Dive

Initial Access (T1204.002)

The malware posed itself as a “GoogleCrashHandler_unsigned.exe” which requires admin privilege and user interaction via execution.

Anti-Analysis (T1620)

From the dropper, it automatically loads the malicious function disguised as “__calloc_crt” via __mtinit function and calls it. From there it starts a lengthy assembly execution chain that involves the following:

1. Obfuscation via redundant calls and/or instructions
2. PEB walk to retrieve critical loading functions
3. VirtualProtect RWX to ensure second stage DLL has execute permission
4. Decryption loop to load second stage DLL to memory
5. Jump to DLL via DLLEntryPoint

Next, the malware attempts to PEB walk and find API hash based on ROR13 algorithm:

As shown, it’s trying to get certain handles of either critical DLL or functions such as KERNEL32, LOADLIBRARYA, GETPROCADDRESS, etc. Next it tries to call VirtualProtect in order to ensure that the second stage DLL is executable in the memory itself.

Then the malware decrypts the second stage payload via XOR operation and jumps into DLLEntryPoint function:

Discovery Phase (TA0007)

After the malware switches context to second stage, analyst discovered that it tries to query information regarding the boot sector via access to PhysicalDrive:

After this it checks whether the bootloader information is MBR/GPT and handles each case (while still maintaining uniform write later). After handling each case, it would call the payload construction function next and derive a symmetrical key while generating a unique identifier for the victim to be used as part of the ransom message.

Impact Phase (TA0040)

The malware derives a symmetrical key based on multiple algorithms, then it converts it into string representation:

Next it generates 6 bytes unique alphanumerical identifier to be used as the part of ransom message:

Malware after it finished constructing ransom message

Analyst included the symmetrical key derivation process because for the next step it copies malicious bootkits including the symmetrical key itself into the boot sectors; specifically it tries to overwrite following boot sectors to achieve persistence:

1. Initial malicious bootkit
2. Main bootkit
3. Ransom message
4. Encrypted bootkit, analysts hypothesize it’s the original bootkit.

After it finishes writing into boot sectors, it raises a kernel-level exception via ntdll to force the victim to boot into the malicious bootkit, completing the killchain:

For more details, consult Appendix C.

Analysis Insight

Key Challenges and Resolution

1. Debugging: Analyst had problem when trying to debug the malware in IDAPro due to gibberish instruction being generated, and debugging the second stage DLL with IDAPro. Resolution: switch to x32/x64 debugger with automatic DLL loading and coherent assembly
2. Anti-analysis: The sample tried to PEB walk and load critical functions by matching ROR13 hash with predetermined value. The analyst failed to implement a clean room for this. Resolution: Look up ROR13 hash that matches the cmp instructions

Novel Findings

Despite being known malware, manual analysis revealed:

1. Reflective Loading: By including the second stage payload inside the dropper, and employing PEB walk, it ensures the second stage payload remains undetected
2. Bootloader probing: Passes “\\.\C:” or “\\.\PhysicalDrive0” into CreateFile to gain access to physical disk storage
3. Bootloader overwriting: By overwriting initial boot code with malicious 16-bit based instructions, it ensures the victim boots into ransom message along with ensuring its persistence by writing other boot sectors

Analysis Difficulty

Four full days are spent to complete the analysis and report. This is personally the most difficult yet due to the obfuscation and Reflective Loading that is present in the dropper, and figuring out bootloader stuff.

Appendix A — Indicators of Compromise

IoC CSV File

Appendix B — Detection Recommendations

YARA

ATT&CK

Appendix C — Analysis Artifacts

Compiled artifacts in PDF

Appendix D — References

IOCTL Codes: https://github.com/tpn/winsdk-7/blob/master/v7.1A/Include/WinIoCtl.h

Reflective DLL Loading Code and API Hash: https://gist.github.com/Niko10/578e8945f142070a7cff10e7d617bbef

This article analyzes Ploutus-L malware which demonstrates great knowledge of eXtensions for Financial Services (which will now be abbreviated as XFS) middleware to manipulate cash dispensing operations on ATM while displaying fake maintenance message.

Key Findings:

1. Target XFS Compliant ATM
2. Manipulates execution context for interactive ATM control
3. Cash accounting manipulation
4. Optimization algorithm to maximize theft

Yara

rule ATM_XFS_Malware {
  meta:
    author = "SOC Team"
  strings:
    $xfs1 = "WFSExecute"
    $xfs2 = "WFSGetInfo" 
    $xfs3 = "msxfs.dll"
    $reg = "NoInteractiveServices"
    $usb_check = "\\\\\\\\.\\\\PhysicalDrive1"
    $killswitch = "C:\\\\xfs\\\\license.dat" 
  condition:
    3 of ($xfs*) and $reg and $usb_check and not $killswitch
}

IoCs

• d9c1151ac686be204e2bdf368130fdb972668d3090b9f9fb0d0e60ebae473776
• HKLM\SYSTEM\CurrentControlSet\Control\Windows\NoInteractiveServices set to 0
• WFSExecute with commands 303, 311, 304
• WinStationSwitchToServicesSession

Technical Analysis

Exploitation Context

The malware first tries to build some exploitation context:

These snippet shows that the malware tries to launch fake maintenance message for malicious purpose in which we will dive in.

XFS/CDM Recon

The malware attempts to enumerate the XFS that the ATM is using by establishing connection via WFSOpen function call:

Next, it determines which logic to take based on the obtained XFS and its version. It can simply set money to be taken, or try to optimize the bank notes types to maximize theft value.

Anti Forensic

By leveraging the XFS API, specifically the WFS_CMD_START_EXCHANGE and WFS_CMD_END_EXCHANGE, it can wipe transaction history and make analysis more difficult:

Banknote record falsification

If it can, the malware will forge a fake banknote count in order to avoid detection:

Banknote optimization

The malware can optimize the available banknotes (i.e. selects the high value banknotes) on the ATM and perform optimization based on Knapsack problem, maximizing the theft value.

Theft

Using WFS API, it can withdraw the available banknotes while leaving behind the forged banknote count as stated in Anti Forensic section above.

PostScript

This is the first of many malware analysis I’m going to cover and post here in Medium as part learning how malware operates, how to write detection and mitigate the malware threat. Thanks to VX-UG for providing free malware samples for people to dissect and study!

Appendix

XFS API spec: https://www.cencenelec.eu/media/CEN-CENELEC/AreasOfWork/CEN%20sectors/Digital%20Society/CWA%20Download%20Area/XFS/16926-1.pdf

XFS CDM spec: https://www.cencenelec.eu/media/CEN-CENELEC/AreasOfWork/CEN%20sectors/Digital%20Society/CWA%20Download%20Area/XFS/16926-5.pdf

Malware sample:
https://vx-underground.org/Samples/ATM%20Malware/ATM%20Malware