[EP_X0FF]

https://www.kaspersky.com/blog/shadow-h ... ser/26149/

Injected code called inside MS VC CRT code part, __crtExitProcess of Setup.exe

Itself represent an encrypted shellcode. Dumped shellcode also in attach. Uses hashes for API search.

Lookup table.

Code: Select all

query kernel32!LoadLibraryExW
query kernel32!GetProcAddress
LoadLibraryExW(wininet)
LoadLibraryEx(kernel32)
VirtualAlloc
GetModuleFileNameW
WritePrivateProfileStringW
GetSystemTimeAsFileTime
FileTimeToSystemTime
VirtualFree
LoadLibraryExW(ntdll)
memcpy
memcmp
memset
swprintf
sprintf
strncat
LoadLibraryExW(ntdll)
MD5Init
MD5Update
MD5Final
LoadLibraryExW(iphlpapi)
GetAdaptersAddresses
LoadLibraryExW(wininet)
InternetOpenA
InternetOpenUrlA
InternetQueryDataAvailable
InternetReadFile

Simplified execution scheme:

1) Get API pointers-> loading dlls and hash lookup (some dlls referenced twice, quality shellcode).
2) Call GetAdaptersAddresses, allocate buffer for result - call GetAdapterAddresses again, lookup each adapter entry and calculate MD5 hash for MAC address value to preallocated buffer.
3) Compare results with hardcoded targets values. If they are identical build unique request value for "hxxps://asushotfix.com/logo2.jpg?" (down at this moment) query InternetOpenA->InternetOpenUrlA->InternetQueryDataAvailable. Read data from server with InternetReadFile to the preallocated VirtualAlloc(ERW 5 MB) buffer and transfer execution to it.
4) If Target does not match then create idx.ini in the root of drive from where setup.exe was launched (GetModuleFileNameW and extract drive label) and fill it with the following values (WritePrivateProfileStringW):

(GetSystemTimeAsFileTime + FileTimeToSystemTime)

Code: Select all

[IDX_FILE]
XXX_IDN=Current Date
XXX_IDE=Current Date
XXX_IDX=Current Date

Targeted attack, nothing fancy so far except way of distribution through ASUS crapware. Proclaimed effect is slightly overestimated for AV marketing reasons.

[R136a1]

Nice analysis! Want to add some additional details.

9a72f971944fcb7a143017bc5c6c2db913bbb59f923110198ebd5a78809ea5fc (from Kaspersky blog post)
The attacker patched the original call to ___crtCorExitProcess inside ___crtExitProcess with a call to some injected code at the end of the .text section:

Original:

original.png (49.45 KiB) Viewed 370 times

Patched:

patched.png (49.55 KiB) Viewed 370 times

The patched call to ___crtCorExitProcess in turn normally calls CorExitProcess:

core_exit.png (72.81 KiB) Viewed 370 times

And ___crtExitProcess gets called within these 3 functions:

crt_exit.png (56.01 KiB) Viewed 370 times

The 3 exit calls which end up in ___crtExitProcess

Code: Select all

_exit -> _doexit -> ___crtExitProcess
__cexit -> _doexit -> ___crtExitProcess
__c_exit -> _doexit -> ___crtExitProcess

As already mentioned, the injected code at the end of the .text section checks for specific MACs and if positive the C&C domain gets contacted to download the 2nd stage payload. Just want to add that the matching MD5 gets appended to the URL, e.g.:

Code: Select all

https://asushotfix.com/logo2.jpg?00B006C7DAB6ACE6C25C3799EB2B6E14

The MAC MD5 hashes in this sample are as follow:

00B006C7DAB6ACE6C25C3799EB2B6E14
5977BAA3F8CE0CA1C96D6AC9A40C9A91
409D8EEBCE8546E56A0AD740667AADBD
7DA42DD34574D4E1A7EA0E708E7BC9A6
ADE62A257ADF118418C5B2913267543E
4268AED64AA5FFF2020D2447790D7D32
7B14C53FD3604CC1EBCA5AF4415AFED5
3A8EA62E32B4ECBE33DF500A28EBC873
CC16956C9506CD2BB389A7D7DA2433BD
FE4CCC64159253A6019304F17102886D
F241C3073A5777742C341472E2D43EEC
4EC2564ACE982DC58C1039BF6D6EA83C
AB0CEF9E5957129E23FBA178120FA20B
F758024E734077C70532E90251C5DF02
F35A60617AB336DE4DAAC799676D07B6
6A62EAD801802A5C9EC828D0C1EDBB5B
600C7B52E7F80832E3CEE84FCEC88B9D
6E75B2D7470E9864D19E48CB360CAF64
FB559BCD103EE0FCB0CF4161B0FAFB19
690AD61EC7859A0964216B66B5D33B1A
09DA9DF3A050AFAD0DF0EF963B41B6E2
FAE3B06AB27F2B0F7C29BF7F2B03F83F
D4B958671F47BF5DCD08705D80DE9A53

[EP_X0FF]

Would be interesting to look on payload. I guess it is target specific. Also interesting to know what all these ~600 people share in common. Perhaps Kaspersky will shed some light on this in near future.

[R136a1]

Yeah, would be interesting to know. Also, earlier samples are patched in a different way, more primitive.

6aedfef62e7a8ab7b8ab3ff57708a55afa1a2a6765f86d581bc99c738a68fc74
The difference to the previous sample is that not the call of ___crtCorExitProcess in ___crtExitProcess was patched, but instead the WinMain function.

Original:

winmain.png (95.71 KiB) Viewed 361 times

Patched:

winmain_patched.png (113.85 KiB) Viewed 361 times

Doing it this way, the program has to crash at some point which it also does. Nevertheless, the malicious code is still executed.

Moreover, the payload is present in the resource section as previously (patched the EXE resource), but as a complete PE file in cleartext:

patched_exe_res.png (186.77 KiB) Viewed 361 times

When we extract the patched executable, we get the a complete PE file with the following PDB path left:

Code: Select all

D:\C++\AsusShellCode\Release\AsusShellCode.pdb

The PE file has a compilation time stamp of 7/10/2018 5:58:19 AM which looks legit. The file is just the compiled PE version of what is later realized as an encrypted shellcode in the EXE resource. This resource normally contains a Asus application named "SelfUpdt.EXE", but was just overwritten with the malicious PE and later with the shellcode. Note that the EXE resource with the complete malware PE file has still the same size as the original one, since just the first x bytes are overwritten and the rest of the original file is untouched. The later version with the shellcode present doesn't have anything left from the original file, thus the resource has only the size of the shell itself.

Due to the way the original Asus updater sample was patched, the signature is not valid anymore. Because the sample was one of the first uploaded trojanized Asus updater files, I think it is one of the first attempts in doing so. It's very simple as the payload is there in cleartext as complete PE file, functions are just patched without caring if overall sample still works correctly, ...

Later samples with patched function call in ___crtExitProcess look a bit more advanced. One can clearly see the evolution the attackers made over time of several months making the trojanized updater less suspicious. It looks like the attackers either didn't have access to the signing infrastructure first. Or maybe they just wanted to drop a trojanized Asus updater as soon as possible after gaining access to the update server and later care to create and release a not so suspicious setup file.

[EP_X0FF]

Does anyone tried to convert these MD5 back to MAC?

[R136a1]

360 security did some cracking or hash calculations:

md5s.jpg (62.74 KiB) Viewed 346 times

Source: https://twitter.com/360TIC/status/1110797967621914625

[EP_X0FF]

Another summary for Setup.exe https://www.vkremez.com/2019/03/lets-le ... ation.html

[R136a1]

Two more analyses:

• https://www.countercept.com/blog/analys ... e-payload/
• https://skylightcyber.com/2019/03/28/un ... -mac-list/

Nothing new though, except for the almost complete list of targeted MAC addresses:
https://github.com/skylightcyber/shadow ... r/list.txt