Trying to decompile it with ILSpy, it’s obvious that the dropper is obfuscated..

Fynloski obfuscated in ILSpy

..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

Fynloski crashes when opened with OllyDbg

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

Fynloski mem/disk strings compare

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):

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

Dumping Stealer’s PE Header using OllyDbg

..saving to a file with HxD

Paste bin data from olly to HxD making the new PE

..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 😛

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

.NET PWS on ILSpy

StealMail functionality of the PWS:

MailStealer function and a little tip for the author 😀

The spread function.. Spreads itself to the current host..

Malware Spreads itself on the infected machine using autoruns on every drive

Startup persistence.. Registry and file..

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 😛

Decryption function.. Base64 encoding of AES256 encrypted strings. Key can be seen from the caller

After messing around in Olly, I found out the de-base64 .NET function… :

.NET de-base64 function in unicode format

The decryption routine… producing plaintext in unicode string format

Part of the mail decryption

Part of the mail password (SMTPS login):

Part of the SMTPS password decrypted..

Continuing, I logged in the email and it was an afghan’s email..

Afghan’s mail 1st screen

Used a pakistan proxy to see the inbox… But where are the inbox logs?? 😀

Afghan’s Inbox via Pakistan proxy..

That’s why you don’t see logs in inbox.. there is a forwarding rule:

Mail forwarding settings.. This is the real mail of the operator

You can see in trash some messages 😛

Some messages can be seen in Trash 😛

Finally

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.

Great stuff, love the detailed analysis. Was wondering if I could also get a sample to test with my malware heuristics scanner. Also, if you happen to know good places to find stuff like this (RunPE and crypter samples), please let me know.