KeyLogger Analysis

hewwo! I guess its time to make a malware analysis we’re gonna use the book Practical Malware Analysis by Michael Sikorski and Andrew Honig for making it catchall (9'-')9

THE MALWARE:

https://bazaar.abuse.ch/sample/83dac5c3b8e0950221ce5144840dcb8151d07225936e56cce46dafea1d839a80/

Tools:

die(detect it easy), mewnalyzer - first sight file expecting (headers,sections, entropy, packers, imports and hash information, etc) autoit-ripper - extracting the autoit script

were using mewnalyzer(link) for static analysis, u can find the result in this repository.

as we can see, the possible packer is themida which actively fights debuggers and analysis tools.

well, it seems strange, but lets take a step back and look at some basics:

1. Hashing: A Fingerprint for Malware

mewnalyzer helps us calculate hashes:
MD5: 61c5dc23d7043b5eb29150a2b0d3ca4b
S1: 467b038511f21fad0ed013e3c1a3d1b5f0b3c8c6
S256: 83dac5c3b8e0950221ce5144840dcb8151d07225936e56cce46dafea1d839a80
we already know it’s a malware, so there's no need searching it

2. Finding Strings

as we can see from the output, it’s not a themida-packed exe but a third-party compiled AutoIt script compiled with an AutoIt compiler (likely Aut2Exe).

we can also look at some things i found in strings:

• pcre (Perl Compatible Regular Expressions) - extensive regular expression patterns, indicating pattern matching capabilities.
• almost every windows DLL is imported,
• network ops (WININET.dll)
• GUI capabilities (USER32.dll, GDI32.dll)
• registry manipulation (ADVAPI32.dll)
• process manipulation (KERNEL32.dll)
• AU3! magic string - compiled AutoIt script signature
• EA06 - the script was compiled

It probably can be a compiled AutoIt script that was created using visual C++ tools, this kinda explains why we see AutoIt signatures and visual C++ imports and structures. The compressed AutoIt script is in .rsrc, as DiE said.

3. Packed and Obfuscated Malware

well, thats pretty it. we need to extract it(im using autoit-ripper) https://github.com/nazywam/AutoIt-Ripper

file/script.au3 is the decompiled AutoIt script(was protected in the executable) contains a huge encrypted/obfuscated string variable ($UEJVOGGLI), a decryption function (QSCHEGLTNK), a helper function (ZMPRYPDSE) that converts characters to ASCII codes and last but not least some code that creates a DLL structure and executes something.

sticket appears to be another binary file that the AutoIt script extracts using FileInstall. Based on the content, it looks like another executable or DLL or some payload. it actually could be the malware component.

lets look whats inside of the .au3 script

* FileInstall ( "sticket" , @TempDir & "\\sticket" , 1 ) - extracts "sticket" to temp directory |
* Global $UEJVOGGLI \= …  - encryped string, the main payload
* $UEJVOGGLI \= QSCHEGLTNK ( $UEJVOGGLI , "Tc55s2WqM" ) - decrypts the string using the key "Tc55s2WqM"
* $ISBCSMSZJ \= Execute ( "DllCall(...)" ) - calls multiple decrypted strings
* $ISBCSMSZJ \= $ISBCSMSZJ \[ 0 \] - gets the result
* $SQQALJBVR \= DllStructCreate ( ... & BinaryLen($UEJVOGGLI) ... , $ISBCSMSZJ ) DllStructSetData ( $SQQALJBVR , 1 , $UEJVOGGLI ) - creates a structure and writes the decrypted data
* Execute ( "DllCallAddress(... , $isbcsmszj \+ 0x23d0)" ) - executes code at offset 0x23d0 in the allocated memory

this looks like pe injection: the script decrypts the encrypted string, allocates memory using windows API, copies the decrypted data to this memory and executes the code from this memory at offset 0x23d0

lets add this code to script.au3 to save the decrypted payload to decrypted_payload.bin:

as the result, this payload contains some interesting stuff:

here's what i found in decrypted_payload.bin

\<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"\>
 	\<dependency\>
 		\<dependentAssembly\>
 			\<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" language="\*" processorArchitecture="\*" publicKeyToken="6595b64144ccf1df"/\>
 		\</dependentAssembly\>
 	\</dependency\>
 	\<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"\>
 		\<security\>
 			\<requestedPrivileges\>
 				\<requestedExecutionLevel level="asInvoker" uiAccess="false"/\>
 			\</requestedPrivileges\>
 		\</security\>
 	\</trustInfo\>
	\<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"\>
 		\<application\>
 			\<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/\>
			\<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/\>
			\<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/\>
			\<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/\>
			\<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/\>
		\</application\>
 	\</compatibility\>

\</assembly\>

xml manifest means we've probably found another executable hidden inside the first one.

so, here’s what we can say: script.au3 decrypts a payload, writes it to memory and executes it. this new payload is might itself be an executable, it contains its own manifest (Windows Common Controls) and probably will extract and run when executed

the entropy doesn't seem high...

LOOK FOR UPDATES!!! ^o^/ ^o^/ ^o^/