Skip to content

Locpick2.0

Scenario

We've been hit by Ransomware again, but this time the threat actor seems to have upped their skillset. Once again a they've managed to encrypt a large set of our files. It is our policy NOT to negotiate with criminals. Please recover the files they have encrypted - we have no other option! Unfortunately our CEO is on a no-tech retreat and so can't be reached.

The sherlock archive contains the following:

  • A directory (share) with three files:
    • countdown.txt
    • expanding-horizons.pdf.24bes
    • takeover.docx.24bes
  • A .zip archive (malware.zip) with a single file named update.

When unzipped, the file appears to be an ELF executable:

1
2
$ file malware/update               
malware/update: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), statically linked, no section header

Binary Analysis

It's likely that the provided files were encrypted by the provided update binary, which means the binary needs to be analyzed to determine how the files were encrypted.

A good first step in analyzing any binary to run strings on it to look for any plain-text strings. In this case, it appears it has been packed with UPX:

1
2
3
4
5
6
7
8
$ strings malware/update 
...
W^YH
PROT_EXEC|PROT_WRITE failed.
$Info: This file is packed with the UPX executable packer http://upx.sf.net $
$Id: UPX 3.96 Copyright (C) 1996-2020 the UPX Team. All Rights Reserved. $
_j<X
...

Binaries packed with UPX can be unpacked using the same upx tool that is used for packing them:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
$ upx -d malware/update -o update-unpacked
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2024
UPX 4.2.4       Markus Oberhumer, Laszlo Molnar & John Reiser    May 9th 2024

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
     29499 <-      9540   32.34%   linux/amd64   update-unpacked

Unpacked 1 file.

Once unpacked, strings returns a lot more plain text strings, including:

  • A list of extensions (.txt, .pdf, .sql, .docx, .xlsx, .pptx, .zip, .tar, .tar.gz), which are likely the file types that the malware targets.
  • A URL to a pastebin (https://pastes.io/raw/foiawsmlsk) containing the ransom note.
  • The string b7894532snsmajuys6.
  • The string %s.24bes used for naming the encrypted files.
  • Multiple calls to cURL libraries.
  • Calls to OpenSSL library functions.
    • One call is to EVP_aes_256_cbc@OPENSSL_3.0.0, suggesting that the malware uses AES256 encryption in CBC mode.
  • General status and error messages.

Given the above, it's likely that the binary interacts with the network and uses cURL to retrieve files.

Static Analysis

Analyzing the binary statically is siginificantly more involved as the URLs used for retrieving content aren't stored as plain text inside the binary, but rather as encrypted strings.

Loading the malware binary into Ghidra and stepping through main(), there is a call to get_key_from_url() early on:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
...
  OPENSSL_init_crypto(2,0);
  OPENSSL_init_crypto(0xc,0);
  res = get_key_from_url(local_128,local_228);
  if (res == 0) {
    for (i = 0; i < 32; i = i + 1) {
    }
    for (j = 0; j < 16; j = j + 1) {
    }
    putchar(L'\n');
    handle_directory("/share/",local_128,local_228);
  }
  else {
    fwrite("Update failed.\n",1,0xf,stderr);
  }
...

The get_key_from_url() function appears to act as a self-updater. Inside it, there is a call to another function named xor_cipher():

1
2
3
4
5
6
7
...
  curl_global_init(3);
  res = curl_easy_init();
  if (res != 0) {
    xor_cipher(K1,local_98,HESB);
    local_14 = 0x2712;
...

It's not immediately clear what the parameter local_98 above is used for, but the two other parameters point to what appears to be a key and a cipher.

K1:

alt text

Note

Ghidra fails to detect the data type used, which can make it tricky to spot that the undefined values are part of the same data structure.

HESB:

alt text

Using HESB as the key and K1 as the cipher produces an URL:

alt text

Decryption

The URL is a direct link to a file hosted on Dropbox:

alt text

The downloaded file is tiny (48 bytes). At two characters per byte, it's 96 chraracters long. From the context it most likely has something to do with the encryption process carried out by the malware.

The file only contains raw data:

1
2
3
4
$ cat updater | xxd
00000000: f3fc 056d a118 5eae 370d 76d4 7c4c f9db  ...m..^.7.v.|L..
00000010: 9f4e fd1c 1585 cde3 a7bc c6cb 5889 f6db  .N..........X...
00000020: 0144 8c79 0993 9e13 ce35 9710 b9f0 dc2e  .D.y.....5......

Written out as a plain hex string, the file contents become:

1
2
$ hexdump -ve '1/1 "%.2x"' updater
f3fc056da1185eae370d76d47c4cf9db9f4efd1c1585cde3a7bcc6cb5889f6db01448c7909939e13ce359710b9f0dc2e

Assuming the malware encrypts files in AES256 CBC mode, a 32 byte key and 16 byte initialization vector (IV) is needed to decrypt them. Taking the first 32 bytes (32 * 2 = 64 characters) as the key leaves 32 characters (16 bytes) for the IV:

1
2
Key: f3fc056da1185eae370d76d47c4cf9db9f4efd1c1585cde3a7bcc6cb5889f6db
IV: 01448c7909939e13ce359710b9f0dc2e

Using the above as decryption parameters, the two documents in the share directory can be decrypted:

alt text

Note

While the PDF file decrypts fine, the Word document appears to be somewhat corruped after decryption and won't open in LibreOffice Write. This is likely repairable, but the file contents can still be read by giving the file a .zip extension, extracting it and opening word/document.xml.

Tasks

What type of encryption has been utilised to encrypt the files provided?

This is listed in the strings output from the unpacked binary, as well as when analyzing the binary in a disassembler.

The encryption used is AES.

Which market is our CEO planning on expanding into? (Please answer with the wording utilised in the PDF)

Mentioned on the second page of the expanding-horizons.pdf file:

alt text

Please confirm the name of the bank our CEO would like to takeover?

This is mentioned in the takeover.docx document:

I am writing to inform you that Forela Group is interested in acquiring Notionwide Bank. Our company is a well-established financial institution with a strong track record of success, and we believe that the acquisition of Notionwide Bank would be a strategic move for us.

The bank's name is Notionwide.

What is the file name of the key utlised by the attacker?

The file retrieved from Dropbox by the malware is named updater.

What is the file hash of the key utilised by the attacker?

1
2
$ md5sum updater                                         
950efb05238d9893366a816e6609500f  updater

What is the BTC wallet address the TA is asking for payment to?

The address is listed in the ransom note (share/countdown.txt):

...\ Send payment to our wallet deep,\ BTC Address: 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2,\ To verify and make us weep.\ ...

How much is the TA asking for?

This is also mentioned in the ransom note:

...\ A million pounds in Bitcoin bright,\ Shall bring your data back to light.\ ...

They are demaning £1000000.

What was used to pack the malware?

As mentioned above, the malware was packed with UPX.