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.. 🙂
Continue reading

AutoIT Malware. A detailed analysis

 

This is a sample that came to my hands by a spam campaign, and caught in a corporate honeypot. Make a comment under this post with your email if you want a sample.

Sorry for some false positive AV alarms while browsing this post.. It was due to some code listings. I removed the AutoIT script, but it can be found here: https://www.dropbox.com/s/xu1ra236lx8n5dc/clean.au3?dl=0 .

~ Due to big amount of requests, I uploaded the sample here too. Pass is “malware” ~
Here is an overview of what you’re going to see in this post:

1) First malware file: .exe
– recognition of the executable’s type (WinRAR SFX)

2) Drops: update.exe + 3 files
– recognition of the dropped PE (AutoIT), and obfuscated AutoIT script
– making a custom python script of script de-obfuscation
– Clear AutoIT script analysis, methods and some thoughts about it.

3) LoadPE method (by the AutoIT script) using an encrypted drop
– making a custom script to decrypt the drop (RC2 encrypted usign CryptoAPI)
– analysis of the final malware. What data does it collect, which format, how does it send them and where.
– reveal some console log messages of the app by just changing it’s IMAGE_SUBSYSTEM byte from PE Header

..so let’s go..
Continue reading

Ubuntu/Backtrack: Read only filesystem fix

Long long time same prob with VMs..
forgot to take a snapshot, it didn’t shutdown correctly, and in next boot stucks in fsck check..
It is a huge problem having lot of ppl with VMs..
Finaly i came to a solution reading lot of forums.. I combined them to a single solution..

Most ppl say that you’ll solve your prob doing this
mount -o remount,rw /

But that didn’t work in my case..

 

I fixed my issue in the followng steps..:

– First of all, while you are in the read-only filesystem, check your boot errors with [code]dmesg |grep mount[/code]
and you may see some msg saying that it remounted your system in read-only mode (like “remount-ro”)
Remember this.. we’ll compare it to the next dmesg after following these steps:

1. Boot with a ubuntu/backtrack live iso

2. Mount the filesystem
mkdir /root/test
mount /dev/sda1 /root/test

3. And edit /etc/fstab of the mounted drive in /root/test/etc/fstab nano /root/test/etc/fstab and change to zero all counters..
Also if there is an error status writing “error=…” and “remount-ro” delete it and replace with “defaults” save the file and exit..

4. Type the following inline bash script to fix all drive errors:
for i in $(ls /dev/sd*);do e2fsck $i -C0;done

..and reboot..
After reboot check errors dmesg |grep mount
If the remount-ro message is missing, you are ok.. :p

That’s it..