'Stealth' Worm Hinders Sandbox Analysis

Tuxedo Jack writes "The Register reports that the new Atak worm cannot be analyzed or debugged by antivirus companies without quite a bit of work, due to the author being sloppy with his or her code. Windows machines, as per the norm, are the only vulnerable ones, and it still requires user intervention to infect. Perhaps future worms will start including this 'bug' in their releases. We can only hope not." It doesn't sound like a bug at all, from the virus writer's perpective.

Comments

Not a worm

[goldspider]

"...and it still requires user intervention to infect."

Then it's not a worm.

Clarification, there are 2 issues

[ItWasThem]

Hopefully this clears up the "Is it sloppy or is it devious?" posts. It is both.

Number 1 (from the article):
Atak uses a variety of tactics in its attempts to escape antivirus analysis. Its main trick is to check to see if it's being run in a debugging environment. If so, it exits to avoid detection. The ploy prevents casual perusal of the code by researchers and (potentially) rival virus writers.
So that part is intentional.

A possible bug, related to the way Atak checks its activation date, prevents it from being run in a "sandbox". A sandbox is a virtual environment commonly used by AV researchers to look at the behaviour of malware in a safe environment.

So what I think they are saying is that even with it's ability to detect if it's being run in debug mode they would still normally be able to run it in a sandbox. Unfortunately (for the AV companies) there's the second thing. The seemingly unintentional bug that prevents it from working in a virtual environment.

Re:How does it do that?

[JamesO]

You hook the int 2 (?) and int 3 during the run, so your code gets called before the debugger's breakpoint handler, amongst other techniques.

Have a look at this paper and be enlightened :)

It's part of the API - From MSDN

[soundman32]

IsDebuggerPresent
The IsDebuggerPresent function indicates whether the calling process is running under the context of a debugger.
This function is exported from KERNEL32.DLL.
BOOL IsDebuggerPresent(VOID)
Parameters This function has no parameters. Return Value If the current process is running in the context of a debugger, the return value is nonzero. If the current process is not running in the context of a debugger, the return value is zero. Remarks This function allows an application to determine whether or not it is being debugged, so that it can modify its behavior. For example, an application could provide additional information using the OutputDebugString function if it is being debugged.

Re:Hex it?

[micromoog]

It's hard, but not impossible. To go with your first analogy, a skilled auto engineer WOULD be able to tell you many things about the real-world performance, based only on reading the blueprint.

Unless the writer has gone to great lengths to obfuscate, a disassembler combined with a skilled x86 assembly programmer should be able to tell you all about what it does. Maybe the AV companies don't have those skills . . . methinks they should.

Re:How does it do that?

[ryants]

There are a couple of ways. Here's one that I took from "Building Secure Software". Debuggers tend to reset the processor instruction cache on every operation. Normally this doesn't happen except when a jump happens. So you can write code that changes instructions that should definitely be in the cache. If we're not running under the debugger, this has no effect, because the change doesn't cause the cache to refresh. Under a debugger, things can break:

1 cli

2 jmp lbl1

lbl1:
3 mov bx, offset lbl2

4 move byte ptr cs:[bx], 0C3h

lbl2:
5 nop

6 sti

; Continue normal operations here

Commentary:

1 Clear interrupt bit, so that code is sure to stay in the cache the entire time

2 Causes CPU I cache to reload

3 Store addr of lbl2

4 Store a RET over the nop at lbl2 (0C3h = RET)

5 nop to be clobbered only if under debugger

6 Remove interrupt bit

Of course you need to be a bit stealthier than this, but this is the basic idea.

Re:Hex it?

[frenetic3]

I'm guessing it's a standalone EXE, and it would require some advanced knowledge, but you could create the process with the CREATE_SUSPENDED flag and then inject code to replace in the import table any API calls the virus uses to detect the debugging environment (I'm guessing the one they use is the simple IsDebuggerPresent() Win32 API call)

This used to be a pretty heinous hack but seems well documented now; googling for the keywords:

SetThreadContext ebp eip CreateProcess CREATE_SUSPENDED WriteProcessMemory

will get you some interesting results and tutorials.

* http://codeproject.com/system/api_spying_hack.asp
* http://tochna.technion.ac.il/project/Win32APIInter ceptor/doc/Win32APIInterceptorNew.pdf

Pretty cool shit.. anyway, the point is after you put a dummy IsDebuggerPresent that always returns false, you can step through it normally.

Or, heh, a method that would probably be a million times easier would to simply step through the code until it calls IsDebuggerPresent and change the value of EAX to 0 after it returns (since the return value of functions is placed in EAX after return).

Anyway, just musing and putting up those links because I learned a lot about how Windows internals work through playing with things like that and figured others might want to learn.

-fren

Nothing new

[Anonymous Coward]

Viruses which could detect that they are being run in a debugger were common 10 years ago when I used to work for an anti-virus company. For example, One-Half is such a virus.

Re:Mailers?

[mrogers]

This paper predicts that a fast-scanning Nimda-like worm launched against a small "hit list" of known vulnerable machines could infect millions of machines in minutes - too fast for any human-mediated response. Such a worm could reach saturation point and begin destroying its hosts before most admins had even noticed what was happening. Even those who noticed would not have time to study the worm's behaviour, let alone analyze its code. Stealth code would therefore be unnecessary, except to make it more difficult for subsequent investigations to identify the source of the worm.

The hit list technique speeds up the initial phase of infection, which is normally slow and vulnerable to isolated failures. The list is compiled ahead of time by normal vulnerability scanning; the machines on the list are simultaneously infected to start the attack. Each copy of the worm then scans for and infects further vulnerable machines as quickly as possible, dividing the address space at each hop to avoid unnecessary overlaps (some redundancy might be desirable, but completely random scanning would be inefficient). The list can be divided in a topology-aware way to reduce congestion that might otherwise limit the rate of infection.

Remember the old days

[Eudial]

Remember the old days of self modifying assembly code?

(ie:
instruction purpose
1-20 alter instruction 21-40
21-40 alter instruction 1-20, jump to 1
1-20 do something
21-40 alter 50-70 and 1-20
50-70 do something, jump to 1-20)

All alteration naturally is done in the most tricky of ways.

Ah, those were the days.