As a malware researcher I just got my hand on one of the latest TDSS Malware.
The malware uses protection against an execution on a virtual machine by using the SIDT query technique, in case a VMware environment is detected, the malware simply terminates and removes itself from the machine. For this analysis I used solely real machine to perform the analysis. The malware prevent itself from being executed several times using name event, it is pretty convenient as a signaling synchronization as well.
** TO VIEW THE FULL REPORT . http://www.flap71.com/tdss/ **
push offset aGfdjhfd ; "gfdjhfd"
push 1 ; bInitialState
push 1 ; bManualReset
push 0 ; lpEventAttributes
Date: Wed, 21 Apr 2010 06:23:01 -0120
Subject: April Discount #88724
From: USA VIAGRA
Command & Coordination Communication (Data is being encoded)
HTTP/1.1 200 OK
magic-number : 128|1|176:78:92:79:102:102:50:246:184:71:97:63:185:238:83:142:67:
content-length : 40448
entity-info : 1271783310:40448:2;
x-powered-by : PHP/5.2.6-1+lenny8
vary : Accept-Encoding
server : nginx/0.6.32
connection : close
version : 1
date : Wed, 21 Apr 2010 07:30:58 GMT
rnd : 11988440
content-type : text/html; charset=utf-8
Today we are going to inspect a Rootkit Technology based Banker, called Win32.Banz.a or RKIT/Banker.9088.
This rootkit presents some interesting aspects from a reverse engineering point of view because has two
layers of protection:
Before starting the direct analysis let's study the general structure, with a PE inspection.
Today I was at Best Buy playing with the iPad, when I tried loading Offensive Computing on the web browser. It seems that Best Buy thinks that this site has something to do with hacking. I wonder if some customers were stress testing the demo machines' antivirus products.
The picture is blurry so here is the text:
This Page Cannot Be Displayed Based on your corporate access policies, access to this web site ( http://offensivecomputing.net/ ) has been blocked because the web category "Hacking" is not allowed. Store Network If you have questions, please contact a Best Buy Employee and provide the codes shown below. Notification codes: (1, WEBCAT, BLOCK-WEBCAT, 0x0021ed3a, 1270677200.557, AAAdUAAAAAAAAAAAyf8AEP8AAAA=, http://offensivecomputing.net/)
This is the latest malware I got from the malware repositories, here I present how this malware infect the system and which third-party actions is doing by this specimen .
written in Visual Basic 6.0
MD5 Checksum : cb702c3319a27e792b84846d3d6c61ad
Size : 61493 Bytes
Extract itself to %windir%\System32 with 3 different names : update.exe, security.exe, avg.exe
it's also open the internet explorer and tends to surf golo.com website.
Seems it also uses the following library : Microsoft Base Cryptographic Provider v1.0
usename of the author is Basic, so we can name the author Basic .
Also trying to download the following files to system32 .
when start to executing, it's also drop a driver named "drive.sys" and "drive.sys.off" to system32\Drivers, had some rootkit behavior, while scanning with RKU it reports try to hide process update.exe .
Open a Handle to Cmd.exe .
seems, there's no hooking behavior available in this sample .
set itself as startup to the following key with 3 different entries:
easy to kill, just terminate update.exe , security.exe and globo.exe, so the malware become inactive .
vt result : Result: 6/42 (14.29%)
vt perma link :
download sample from here :
pass : Infected
P.S : I've been added it OC dataBase, try to search this one : cb702c3319a27e792b84846d3d6c61ad
In this blog post we are going to Investigate the malicious network activity of a still-alive Backdoor-Zombie called Backdoor.IRC.Zapchast, here a little summary of its functionalities:
* Changes security settings of Internet Explorer
* Survives to System Restart
* Creates various copies of itself into Windows directory
* Produces other Processess
* Join to IRC Network, This is the most interesting functionality
Long time not blogging due to real life issues. Today we are going to inspect Win32.Parite.B a trojan that modifies System Files and Enstablishes a Network Activity with an Irc Server and Downloads other potential threats. We can consider Parite.B an IrcBot Client.
Let's perform a first basilar inspection of the malicious binary. The executable is delivered under the name of Protesto_Serasa.exe
Application presents an interesting Section Directory
Apparently appears to be a classical UPX packed application, but if we go to inspect deeply the .wtq section we can suddenly see that the EntryPoint is located at 00096000 that belogs exactly to .wtq. This means that
at loading time, UPX presence is quite useless because the first code that will be execute comes out from .wtq that as we will see contains layer of decryption for the rest of the code.
Pay attention that exists also a TLS Directory, so in debugging phase we have to set TLS Awareness (Break on TLS) to be sure that we are able to follow the potentially hidden to debugger code.
A friend of mine was infected with this Rootkit, I thank him for contributing the sample.
He saved the sys file from a backup, and uploaded it for us at Rapidshare.
A thread discussing behavioral details, and removal instructions for the rootkit
Courtesy of Spybot S&D - http://forums.spybot.info/showthread.php?&t=55711
I tried viewing the SYS file with Wordpad (not a disassembler) and found APIs like IoDeleteDevice and APIs which are hidden.
recently i came across a blog about detection of induc by av's.
Really interesting work.
Today I'm going to expose how to perform the preliminar analysis of a Rootkit Application both via the classical Reverse Engineering approach and Crytpanalysis one.
We will inspect a recent threat commonly detected as Rootkit Agent.adah, this rootkit is delivered in the usual form of executable (.exe) via Compromised or Malicious Websites.
Usually the main executable is delivered in packed/compressed form and presents other executables embedded as resources, in other cases we can have blocks of encrypted data that will be decrypted on fly by the main executable.
In the first step we are going to see how is structured the executable. CFF reveals us that the application is packed with UPX v3.0;
Due to the nature of UPX, that is essentially a compressor, we will see a pattern almost constant, stabilized at high levels of entropy. Here a graph plot
As should be evident, the internal structure and presence of embedded data is protected cause the constancy of the Entropy along the executable. In other words in this case the contribution from knowledge of entropy does not help us to have additional information. We have to perform more specific inspections, this time by using Floating Frequency Analysis.
Let's spend some word about what mean Floating Frequency..
The floating frequency of a document is a characteristic of its local information content at individual points in the document. The floating frequency specifies how many different characters are to be found in any given 64-character long segment of the document. The function considers sequences of text in the active window that are 64 characters long and counts how many different characters are to be found in this "window". The "window" is then shifted one character to the right and the calculation is repeated. This procedure results in a summary of the document in which it is possible to identify the places with high and low information density. A document of length n > 64 bytes has n-63 such index numbers in its characteristics.
This is how work, implicitly should be clear enough how to interpret a Floating Frequency Graph,
high values which deviate markedly from the background in an executable suggest that encrypted data or even cryptographic keys will be found in those places.
Let's inspect the first graph:
As you can see, with floating frequency we are now able to distinguish the PE Header that presents a low Differences Ratio, suddenly after the PE Header we can see UPX at work, plot is constant and uniform, near the end happens an interesting thing, a marked decrease of frequency that remains stable and uniform for a certain offset range, at the end of this isolated behaviour we register another abrupt decrease, this is the end of PE and obviously of the file.
The isolated behaviour is truly interesting, the offset of this 'object' is placed in .rsrc section and presents a strong entropy due the evident density of Floating Freq. plot. A good compression algo introduces a significative increase of entropy, but if the block has already an high entropy this increase obviously cannot happen.We may think that the resource is compressed/encrypted. For example we could have another packed exectable.
After this preliminary inspection we unpack the main malicious executable and inspect in the same way the unpacked one.
Here the Entropy Plot of unpacked sample:
As you can the, now the situation is different, emerges the evidence of PE Header, after a normal ammount of entropy, globally lower that the previous graph, a central drop caused by Zero Padding for PE Alignment, sucessively an increase long a defined amount of bytes (a block) and suddenly after an evident increase of entropy that reaches the RED Level. This mean that our previous observations on floating frequency plot was correct, here the 'object' that certainly is packed/compressed. Finally we have a classical slow down caused by the intrinsic structure of PE Format.
Again let's perform the Floating Frequency inspection of the unpacked executable, here how changes the graph:
Again Floating Frequency reveals us more details, or better (in this case) highlights better the structure of the whole executable plus the conformations of the two objects. If you pay attention to the first one, you can see that this corpse is truly similar to the global look of the unpacked executable, in other words we can state that the first object is effectively another merged executable!
The second one is certainly a compressed object, the reason is clear just lookup the previous explaintions.
Now let's see practically the whole body of our unpacked executable, from a classical Reverse Engineering point of view. We said that the two objects are placed into .rsrc section, let's look with Great CFF (I love this Tool :) ) if this is true.
Bang! correct, the two merged resources are definitely two executables!
The first one is a clean .sys, this is clear due to the presence of INIT in the PE Header.
Also the second resource corresponds to our predictions, we have an UPX packed executable.
Now should be trivial to carve these two executables, just locate the starting offset and by delimiting with Block Start/End function of CFF we obtain the executable size that added to the starting offset give us the final offset where to cut.
The Block End corresponds obviously with the end of first/second resource.
The .sys is the core file of our rootkit, I'll reverse it in a future post, the second executable, when unpacked become clear that is a DLL, if we take a look to some function name for exampe this:
_NF_STATUS __cdecl nf_addRule(struct _NF_RULE *)
became clear that this DLL acts as Network Filter by using NetFilterSDK ( http://netfiltersdk.com/ )
But this is matter of future blog post.
Hope you enjoyed this little paper :)
Giuseppe 'Evilcry' Bonfa'
Vizsec 2010, or the Visualization Security conference, is one of those conferences that I feel strongly could change the nature of security field. If you have any ideas for visualization, especially reverse engineering related visualization, I strongly recommend you submit a paper there. Here are the relevant dates:
April 30, 2010 Full papers
May 21, 2010 Short papers