1

Tracking Coreflood from Shellcode

Sometimes, it can be surprisingly difficult to get malicious code removed from servers. It can be due to a lack of server support by the owners and their support staff, a lack of responsiveness from the ISP, or an intended scheme to profit from malware distribution, as with the groups involved at the RBN this past year.
It’s just as surprising when users’ systems are getting attacked with malcode that’s been in circulation for at least five years and right now, it’s almost completely undetected by the major av vendors. Here are some scanning results on the executable. Four of thirty two scanners is not pretty:

Anyways we are observing some download and execute shellcode attacking user systems that pull down the malicious file from a server (that server’s admin, the owners of the site, and the ISP have all been contacted over the past couple of days. At least the ISP got back to us with a low priority ticket). Here is an example of the malcode calling “urlmon.UrlDownloadToFileA” on hxxp:// 20x.x16.xx.xx/ white.ccs and copying the undetected “AFCode” or “CoreFlood” variant download to c:index.tmp. We use a tool and process that we posted last year for shellcode examination:

And here is the call to “kernel32.Winexec” to get that file started on the system, which drops and loads its dll file:

The binary, c:index.tmp, doesn’t carry much of an unpacking stub. We see more xor loops and import redirection tricks than anything, which makes it unusual that the AV crowd can’t keep up with this one. It drops a set of unusual looking dat files, and adds CLSIDs and an unusual ShellIconOverlayIdentifiers registry entry for startup. Inside the dropped dll, we find a slew of strings that suggest this malicious component is simply reused Coreflood code:
AFCORE
Removing AF from the system . . .
AF up time: %t
Flooding %s . . .
Flooding of %s has been completed
Processing diskflood log file %s . . .

The file immediately POSTs information about its host operating system, version of the software, etc, back to another server over http, among other things.

It’s not especially fun to see this coreflood family back in the wild. Coreflood seems to have caused problems for individuals performing online banking in the past few years, as the Secret Service found it on Joe Lopez’s laptop in the disturbing BofA v Lopez. But I suppose we’ll never really know for sure about that one. It was settled out of court, and neither side will respond to repeated calls regarding their own settlement.

Update: over the weekend, the malicious “white.ccs” file was silently removed from the server. And the ISP handling the problem interestingly deleted the support ticket they had issued for my request.

This entry was posted in Online Fraud. Bookmark the permalink.

3 Responses to Tracking Coreflood from Shellcode

  1. Willy Wonka says:

    Any chance that you guys have been able to figure out how it would spread inside a company? Would it use net view or query against network neighboorhood or something like that to figure out where to propagate?

    Thanks

  2. Willy Wonka says:

    Can you please post more detail about the information it gathers from the host and then posts?

    Thanks

  3. ThreatFire Blogger says:

    Heya Willy:

    Robert Vamosi commented on Joe Stewart’s post here:
    http://news.cnet.com/8301-10789_3-9981248-57.html

    And Joe Stewart posted some info on Coreflood’s use of Sysinternals’ PsExec tool, to spread within a company on systems using domain admin accounts. Also, your question about infostealing is answered here as well:
    http://www.secureworks.com/research/threats/coreflood/?threat=coreflood

    And Willy, Charlie got the golden ticket, but family will make you happy. Sometimes at least.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>