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

0day DoS: Mikrotik Server side DoS attack

Intro..

After exploring the winbox clientserver protocol, i wanted to find some ways to get rid of winbox service and winbox client…
This finding, has to do only with the mikrotik router, who has winbox service running (on port 8291 or in any other port)
On my try to make a test on the server, in order to cause a lot of traffic, i saw the service being unstable, causing various probs to whole router. The minimum prob was the 100% cpu load, but there are various probs depending on hardware and routeros version. The exploit’s logic is very simple, and the winbox protocol analysis is simple too.So it made me identify that vulnerability very easy. The vulnerability found while trying to download a DLL/plugin file from mikrotik router (just like winbox client does) and choose a big file, and request the 1st part of it many times.. That is what causes the DoS. The only file needed here is the .py script, and it is tested on python 2.4 and 2.7 versions.

More details, download and usage, are below.. :

Continue reading

0day: Mikrotik’s Winbox Client Side attack. A remote code execution exploit

Hello ppl,
In this post I wanna present you a vulnerability I found and exploited, concerning Winbox. Winbox is the client that controls mikrotik routers.. It is a popular router OS. For more info www.mikrotik.com 🙂
Winbox has a custom protocol communicating with the mikrotik routers and you can select between secure/unsecure communication. Winbox uses a tcp port 8291 by default. Old routers had that port hardcoded, newer ones have the ability to change port. At the bottom of the post, you’ll find a link to download the script and the files needed. You’ll find info how/why in script comments or here…

About the exploit
The exploit you will see in this post, is a mikrotik winbox service emulator. It is a listener, that waits for a winbox client/victim to connect, sends him a malicious dll/plugin and winbox executes it. Using this feature (that we can inject dlls in winbox) we exploit also the fact that a secure connection can be decided by server-side.. So no matter what client has selected, we can sent unencrypted data in his winbox. So attacker have to social his victim or via a MiTM can gain a shell.

Download the exploit code: mtikInject
* Updated on 30/4/2012 Lines 99 & 148 as said in Post’s comments *

 

 Vulnerability Description
===========================
When you connect to mikrotik router using winbox, it is asking for an index with plugins (DLLs) their size, version and CRCs. If something new is found, or if that client haven’t connected to that mikrotik version yet, winbox requests the new plugin(s) (.dll file(s)) from mikrotik router. When winbox downloads all the DLLs required in order to load the controlling interface of the mikrotik router, loads those DLLs (executes the DllMain() of each one) and then tries to make an authentication to the remote mikrotik router. The vulnerability exploits that winbox is loading the remote dlls before authentication and without any further confirmation of plugins originality.

Continue reading

API Hooking tool injecting code in the PE: tool explanation and application examples..

Hello again.. There was a long time since my last post, cos i was busy with several issues, but most time with this tool.. Checking it’s operation, testing the hooked PE in different OSs, changing the method used, etc..

Finally i came up with this tool, and below i will explain exactly how it works, give you the source code and a binary, and show you some applications of this tool with video and/or shots…

This is an API hooking tool, which uses the PE IAT patch method, and runs the payload, injecting the code in the PE permanently, changing the PE Header apropriately (section sizes, OEP, ..) The final executable produced (hooked, and code-injected) tested on most OSs:

  • Windows 7 x64 – SUCCEED
  • Windows 7 x32 – SUCCEED
  • Windows 2008 x32 – SUCCEED
  • Windows 2000 – FAILED (The VEH APIs not supported by OSs <= Win2k)
  • Windows 2003 x32 – SUCCEED
  • Windows XP x32 – SUCCEED
  • MAC OS running wine – SUCCEED

Here is the tool! CPP Source with injected asm (i could say ASM with injected cpp 😛 ) and the compiled .exe .. if you don’t trust me to run binary 😛 just cl hooking.cpp /w and you got it 🙂

Hooking.zip – Get it!

What did I use to do it, was just some VMs to test it in different environments, and:

And ofcourse for the IAT and EAT of the PE Structure, I visited IcZelion’s guides (IAT, EAT) and used those methods in this tool.. Also I use the PEB method to obtain the Kernel Base in runtime on standalone codes, method used by most shellcodes.

Why whould you need an API Hooker ?? There are several reasons.. like :

  • Backdoor files
  • Change the API parameters on runtime
  • Spy API execution on specific process
  • etc

The method used from this tool, is physical modifying the Import Table of the PE, and patching/injection the user’s code so it is executed right BEFORE the API execution begins.. The tool just asks you which API you want to hook, and which is the file with the raw data (asm binary code) that will be inserted before the api execution.. The code that will be inserted must, for sure, be absolutely stand alone, what means that it must keep stack calibrated, must not refer to memory location out of the code (except from locals made in stack or imported functions from PEB) .. You have to know what you’re doing 🙂

BUT.. there is also another option of the tool. You can use the Exception Handling option.. which enables you to use code that may cause exceptions, code that does not manage it’s stack well, and maybe some 3rd party code.. This option, uses VEH (Vectored exception handling), installing the handler before your code execution, and removing the handler after the execution of your code, or after your code causes an exception.. Also the stack is being saved, so you dont have to care about the EBP and ESP values 🙂 The whole consept will be explained.

Here are two very nice and easy to understand API Hooking papers by Brian Mariani from High-Tech Bridge SA, published in exploit-db :

http://www.exploit-db.com/download_pdf/17802

http://www.exploit-db.com/download_pdf/17671

I will try to explain some basic things about how my tool is working. I hope you understand.. You can make your comments ofcourse! 🙂 Here are some Images about the operation.. :

 

Basic Hooking tool explanation

Basic Hooking tool explanation

 

 

 

 

 

 

 

 

 

 

Continue reading

PoURaN PE-Cryptor v1.01

PoURaN PE-Cryptor v1.01 cpp/asm source This time contains the executable too…

Yes am back… And this is a very short post.. I just made a new version for the PE-Cryptor because I needed to make the Cryptor work also without adding a new section! So this version has some functions changes, a new parameter for new section or not, and light changes in user messages…

I insert an image just to show the use of the new option..

 

 

New feature of pe-cryptor

PoURaN PE-Cryptor v1.01

 

PoURaN PE-Encryptor: A XOR based encryptor injecting code to EXE/DLL files..Full C/ASM source available.

 

– =[ The tool presented in this post, is the automatic process of what presented manually here : 133tsec previous post ]= –

What did I use:
PEditor – to check fast the pe header values..
Ollydbg – ofc.. the most usefull one..
M$ VC Compiler – to compile :p
HxD – HexEditor
Notepad++ – The best source/text editor 🙂

References:
Structures in PE: IMAGE_NT_HEADERS,IMAGE_FILE_HEADER,

IMAGE_OPTIONAL_HEADER,IMAGE_DATA_DIRECTORY
..And ofcourse IcZelion’s tuts are very helpful for such topics..

Source: PoURaN PE-Cryptor v1.00 cpp

Hello 🙂
As title says, am going to present you a PE Encryptor that i coded in C++ and inline asm.. Actually, I used .cpp source file and not c, for only onw reason.. to use some SEH easy.. 🙂  I used M$ Visual studio’s command line compiler, and it is a console application. I started coding it, and I was sure that in 3-4 days it should be ready 😛 but I was absolutely wrong.. The most time took me to optimize some functionalities, and to test it in many executables etc.. Many probs occured, and needed lot of debugging and changes. So after about 10-12 days, I have a good working tool 😀

  1. At the moment (in this version) it is a simple pe encryptor doing the following: Takes as input a PE file (.exe or .dll)
  2. Takes as second input a “source” file, a file with raw data, that are going to XOR encrypt the sections, and later decrypt them.. These data will be injected in the PE as is, and will be used in runtime for decryption of the sections.
  3. Asks for the output filename.. The resulted .exe/.dll with injected code and encrypted sections..

The above files must have a max of 100 chars in filenames… (no you’ll not overflow the buffer if you input > 100chars :p )

After taking some input from the user, it checks for a valid header (depends on some standard chars and if there is an exception searching the header.. look at the source). Opens and maps the files into memory. Some functions receive as argument the handle of the files, and some functions receives the pointer to the mapped file on memory.. Most of them returns a pointer to the memory where the pe file is changed.

Am starting by addind a new section in the PE file, named “.PoURaN” and giving it the correct section values so the file is correctly aligned.. The file with the new section is a copy of the original PE file with only a section added, and 4096bytes more in space, and stored in disk with a filename same with the original PE, added by “.new”.. for example if the pe file is “test.exe” the added section file will be “test.exe.new”

The next move is to take that “added section” new file, map it in memory, make again some pe verification, and then read the sections one by one, and through a function named “IsSectionEncryptable” i confirm which of the sections are gonna be encrypted. After looping all sections, i XOR encrypt the “IsSectionEncryptable” sections with the source/key file given (as second input).. Then reading the PE Header i make the proper changes to the injected assembly code, (hardcoded addresses, OEP etc..) and injecting them in the last section.. After the injected code, I add the source/key file as is.. I change the header to make the PE file valid after the changes (you can see the sources) and there it is..!

Where the encryptor doesn’t work:

  1. Files with already 8 sections: Yes doesnt work on those.. Cos normal PE has max 8 sections..
  2. Files with messed sections.. If there are random bytes between the last section header,  and the rawdata of the 1st section, this check will fail, and exit(0);
  3. At the moment, the encryptor has as “IsSectionEncryptable” criteria, the section’s characteristics.. It looks for the two executable flags (20h and 20000000h ..look the sources or video).. If there is no such section (like aspack, makes all sections C0000040h) it will not work either!! 😀
  4. Some fucked up PE Header may cause exceptions or failure of the encryptor.. 😀 let me know for that plz.. 🙂
  5.  …. maybe some more that I miss atm.. plz let me know too …

 

Ofcourse the source code is not at it’s best shape.. I know i made some n00bish fast implementation but I hope to improve it soon.. Optimizations that I already have in mind, will be posted ofcourse, and new versions… and added functionalities.. So keep in touch 🙂

Any recommendations and/or discussions, ofcourse, are welcome!

Below I show the compile, and use of the encryptor, with some executables and a dll example.. Enjoy!

Compile & use on 2 executables.. one executable i just create, and another one 3rd party executable..

 

Here am using the cryptor on a virus, facing some difficulties, and showing how i bypass them.. After that, i compare the virustotal results as expected.. 🙂

Manual code injection for runtime executable decryption : An Antivirus bypass example

In this post I show a way to inject data in an executable, and some code, to encrypt with xor the whole code segment.. As an example, I’ll use a virus executable, encrypt it in this way and upload it in VirusTotal and check it 🙂
Tools I used:

1. Hex Editor (I Recommend HxD http://mh-nexus.de/en/downloads.php?product=HxD)
2. PEditor by yoda&M.o.D. ( PEditor )
3. Ollydbg ( http://www.ollydbg.de/download.htm )

 

I will follow the below steps:
1. Find a dummy image to use it’s raw data… (1)
2. Find an executable with virus
3. Check the results in VirusTotal..
4. Modify the PE Header of infected executable, to add a new segment
5. Select some data from the image file (1) and add them in the new segment
6. Encrypt permanently the original segments
7. Inject some code to make the XOR decryption using olly to check step by step the execution flow
8. Confirming that exe is working fine, and upload to VirusTotal to check for the new results 😀

 

1. Find a dummy image to use it’s raw data

    Well, this is easy.. Let’s use google to search an image… What i searched is “virus” 🙂 Now we have to select an image with complexity.. It has to be a bit complex, cos if you think the jpeg contents, they have to be as much complex as they can, in order not to be a repeatable pattern.. So i select this image for the example http://www.healthinitiative.org/IMAGES/virus_big.jpg ..it has some complexity but not so much.. anyway i like this image 😀 ..Also think that u can use a fractal image.. it gonna give you a cool complexity! 😉

 

 2. Find an executable with virus

    These days i receive a spam from a brazilian friend (who is infected with the virus) with a trojan executable.. A quick analysis of this will be presented in a future post, cos atm is still active, and victim’s personnal info (user;pass) are available publicly…. The executable is packed with ASPack.

3. Check the results in VirusTotal

    Uploading that executable to VirusTotal I take the following results

VirusTotal Scan before encryption

VirusTotal Scan before encryption


Continue reading

A reversing / analysis approach of FlexCrypt : Exploitation-one failed

- The following stuff is done in an environment of Win XP SP3 VM w/ .NET v2.0 .. Also tested in Win7x64 and Win7x86 -
- Tools used : Just ollydbg
- App can be found in :http://www.flexcrypt.com/flexcryptfree.html . 

Everything started when I firstly saw the security magazine “Hakin9” (http://hakin9.org/) presenting FlexCrypt .. I downloaded flexcrypt, and started to testing functionality etc… But I have a bad habit… after some minutes, instead of looking the functionality, i fired up Ollydbg and started exploring its code… I focused on every interface that was accepting user’s input. I wanted to check some BoF vulnerabilities. My attention was caught by the Registration Dialogbox. Fuzzing the input by hand (exception appears in string length > 452) I noticed that the application throws an exception…! That needs examination..

First of all, we assume that the operation is simple : U press Validate -> some function (1) reads your input storing it to a buffer -> string manipulations and memory allocations happen -> some function (2) validates your input -> message for good or bad news 🙂

So, hands on.. attaching Olly on the process, cause the application to overflow entering a long input. Olly shows up, and we land in KERNEL32 :

Kernel RtlRaiseException

Continue reading