Again the malware sample came to me via spam camp, and caught in corporate network’s honeypot.
If you want sample: Comment and request it 😉
This time, the camp’s spread was not so wide.
In this post in detail:
- Recognition of the Fynloski dropper
- ..recognizing the type of protection of the dropper
- ..some details on the dropper’s encryption scheme
- Dumping the main malware process using OllyDbg (PWS in .NET)
- ..analysing the stealer.. Decompilation via ILSpy
- ..analysis of the operator’s credential encryption scheme with OllyDbg
- ..pwning the operator’s credentials revealing victim’s logs and not only..
..Let’s go.. 🙂
Everything begins with an .exe file with Adobe’s Acrobat icon. This PE is an obfuscated/encrypted .NET Application:
Here is an indicator that there is something encrypted inside this PE in the resource section (probably another PE) of size 414kb tip: no it’s not simple XOR even if it looks like it in first sight 😀
Let’s take a look in Fynloski’s strings and VT detection rate:
There’s a Path E:NEW_NETNonRecNonRecbinReleaseCryptoObfuscator_OutputTakeIt.pdb screaming out “am a CryptoObfuscator dropper for .NET”
Trying to decompile it with ILSpy, it’s obvious that the dropper is obfuscated..
..so let’s go a bit deeper.. using olly there are a lot of IsDebuggerPresent calls but it doesn’t have effect on debugger detection. What produces a crash, is an exception of E06D7363 if we don’t press Shift-F9 in order to pass the exception to the app instead of olly..
This is the crash
When Shift-F9 is pressed, everything is ok continuing execution, and in no time, we recognize that it loads another PE in the same process name. It’s the RunPE method once again, and we can see it also by comparing strings on memory and on disk via Process Explorer
Obviously it’s a decryption/decompression of the big resource inside the file, that contained finally the malicious PE.
..For those who wanna do the extra mile..: 😀 After long long time tracing in OllyDbg with hatefull .NET code, and dozens of memory breakpoints, I found out that the exact point of decryption, happens in the following code inside the native .NET module (System_ni). Here this code decrypts the new PE byte-by-byte (after tha call on 7A516B2A, AL has bytes of the new PE):
CPU Disasm Address Hex dump Command Comments 7A516B22 8B4E 0C MOV ECX,DWORD PTR DS:[ESI+0C] 7A516B25 8B56 08 MOV EDX,DWORD PTR DS:[ESI+8] 7A516B28 3909 CMP DWORD PTR DS:[ECX],ECX 7A516B2A E8 E1F8FFFF CALL 7A516410 ; decrypt next char in AL? 7A516B2F 8BD0 MOV EDX,EAX 7A516B31 85D2 TEST EDX,EDX 7A516B33 7D 07 JGE SHORT 7A516B3C 7A516B35 33C0 XOR EAX,EAX 7A516B37 E9 CF010000 JMP 7A516D0B 7A516B3C 81FA 00010000 CMP EDX,100 7A516B42 7D 18 JGE SHORT 7A516B5C 7A516B44 8B4E 04 MOV ECX,DWORD PTR DS:[ESI+4] 7A516B47 81E2 FF000000 AND EDX,000000FF 7A516B4D 3909 CMP DWORD PTR DS:[ECX],ECX 7A516B4F E8 CC0A0000 CALL 7A517620 ; memcpy one-by-one the decrypted chars 7A516B54 83C3 FF ADD EBX,-1 7A516B57 E9 9E010000 JMP 7A516CFA 7A516B5C 81FA 00010000 CMP EDX,100 7A516B62 75 17 JNE SHORT 7A516B7B 7A516B64 8B0424 MOV EAX,DWORD PTR SS:[ESP] 7A516B67 C600 01 MOV BYTE PTR DS:[EAX],1
Dumping the main malware process using OllyDbg
Well, now we are hunting the final PE which is being injected (RunPE) by the Dropper process (Fynloski). Knowing that the injection method is RunPE, gives a big advantage, cos automatically we know how to dump the process. How the RunPE is Writing the contents on the remote proc? With WriteProcessMemory ofcourse. Most times in loop for every section, and some times the dropper has the new proc already dumped, and loaded with WriteProcessMemory one time. In this case, it’s the 1st one.. One call to WriteProcessMemory for each section.
Placing a breakpoint to WriteProcessMemory and dumping PE Header and sections to a PE
..saving to a file with HxD
..and dumping section-by-section in the same way, we get a final PE. This PE is the final malware, which is a Password stealer written in .NET, not obfuscated and easily decompilable 😛
File: Stealer.exe CRC-32: f5cfb32f MD4: ba0fdeef1ac24358399b37021565f794 MD5: edda46353eacad327a5bd500e835e772 SHA-1: 8733c65d079361bdf868edb4ccb29aabd6f793a9
Also an interesting string-Path in the PE is C:UsersJovanDocumentsVisual Studio 2010ProjectsStealerCMemoryExecuteCMemoryExecuteobjReleaseCMemoryExecute.pdb
That “Jovan” guy seems to sell this thing 😀 this string/path exists in some other analysed malwares around..
ILSpy fully decompiled the .NET Stealer PE
StealMail functionality of the PWS:
The spread function.. Spreads itself to the current host..
Pwning the used email credentials
Exploring the decompiled code, we can see that there are plenty of functions with lot of work for the malware 🙂 There is function for spreading to different locations of the same machine, for startup persistence, for mail credentials stealing (nirsoft tool injection), for browser saved pass stealing (nirsoft injection again), for keyboard hooking, for clipboard stealer, minecraft credentials stealer, process killer etc..
And also several ways for reporting all those data back to the operator. There is mail sender (smtp/smtps), ftp uploader and php reporter.
This sample, uses the mail sender way, using smtps. The credentials for the three ways, are encrypted and cannot be seen from the decompiled code.
You can unstrip the smtps traffic and see the creds.. But I selected the OllyDbg way 😛
Here you can see the encrypted mail credentials:
..how you realize that it’s AES encrypted those base64 strings? here ofcourse… :
After messing around in Olly, I found out the de-base64 .NET function… :
The decryption routine… producing plaintext in unicode string format
Part of the mail password (SMTPS login):
Continuing, I logged in the email and it was an afghan’s email..
Used a pakistan proxy to see the inbox… But where are the inbox logs?? 😀
That’s why you don’t see logs in inbox.. there is a forwarding rule:
You can see in trash some messages 😛
After this journey we arrived in the last Stealer PE which is made in .NET and contains lot of stuff as seen above.. The malware contacts it’s operator via 3 different ways, one of those were SMTP mails send of the logs/data collected.. As the malware uses client side encryption, it doesn’t matter the layers and complication of encryption, we can get the plaintext credentials in a matter of time..
This was another example of malware that was made by guys that bought ready-to-deploy tools (crypter-obfuscator, keylogger) and started a spam campaign.