Fynloski dropper and .NET PWS (pass stealer) Analysis

Hey,
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.. 🙂

Fynloski Dropper

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”

And this is VT at the moment:

 

 

 

 

 

 

 

 

 

 

 

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

 

These are the results of VT for the stealer PE

 

 

 

 

 

 

 

 

 

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 😛

 

 

 

 

 

 

 

 

 

 

 

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.