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

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