Twitter is abuzz today about the recent Apache worm that causes servers to participate in a new threat called "Darkleech." Apache servers seem to have vulnerable modules that allow attackers to inject iframes into the browsers of certain web visitors delivering exploit code. ArsTechnica broke the story here
The story is very helpful in pointing out exactly what the meta would look like if one of your enterprise users encountered the Darkleech string.
The injected HTML iframe tag is usually constructed as
IP address/hex/q.php. Sites that deliver such iframes that aren't visible within the HTML source are likely compromised by Darkleech. Special "regular expression" searches such as this one helped Landesman ferret out reported iframes used in these attacks. Note that while the iframe reference is formed as
IP/hex/q.php, the malware delivery is formed as
To clarify, the directory is not "hex" but a long hexadecimal string that changes. This is still not a big problem to detect. We have already published rules to Live that identifies suspiciously long directories and filenames. But the key piece of meta here is the direct to IP get request. We have a risk.suspicious meta alert for just such an event.
The story also links to Urlquery.net and provides a long list of likely compromised sites. The most helpful part is the urls produced. Here's a sample:
The get request shows a direct to IP connection, followed by two hex-string directories, followed by the filename of q.php with a query appended after the question mark. So a rule to detect this in Security Analytics would be:
risk.suspicious = 'direct to ip http request' && filename = 'q.php' && query exists
Name the rule Darkleech Detected and push it to your decoders.
The same rule can be used as a custom query to look backwards in time to see if anyone has visited a Darkleech site in the past. As reminder, do the custom drill on the past three hours first, and then change the timeframe to all data.
Thanks and Happy Hunting!
-Fielder of RSA FirstWatch