Disguising Exfiltrated Data

There's an interesting article on a data exfiltration technique.

What was unique about the attackers was how they disguised traffic between the malware and command-and-control servers using Google Developers and the public Domain Name System (DNS) service of Hurricane Electric, based in Fremont, Calif.

In both cases, the services were used as a kind of switching station to redirect traffic that appeared to be headed toward legitimate domains, such as adobe.com, update.adobe.com, and outlook.com.

[...]

The malware disguised its traffic by including forged HTTP headers of legitimate domains. FireEye identified 21 legitimate domain names used by the attackers.

In addition, the attackers signed the Kaba malware with a legitimate certificate from a group listed as the "Police Mutual Aid Association" and with an expired certificate from an organization called "MOCOMSYS INC."

In the case of Google Developers, the attackers used the service to host code that decoded the malware traffic to determine the IP address of the real destination and redirect the traffic to that location.

Google Developers, formerly called Google Code, is the search engine's website for software development tools, APIs, and documentation on working with Google developer products. Developers can also use the site to share code.

With Hurricane Electric, the attacker took advantage of the fact that its domain name servers were configured, so anyone could register for a free account with the company's hosted DNS service.

The service allowed anyone to register a DNS zone, which is a distinct, contiguous portion of the domain name space in the DNS. The registrant could then create A records for the zone and point them to any IP address.

Honestly, this looks like a government exfiltration technique, although it could be evidence that the criminals are getting even more sophisticated.

Posted on August 21, 2014 at 6:08 AM • 20 Comments

Comments

WmAugust 21, 2014 7:01 AM

Interesting enough, the 'interesting article' link is timing out:

The connection has timed out
The server at www.infoworld.com is taking too long to respond.

The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer's network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.

MendaxAugust 21, 2014 8:05 AM

The Infoworld link is totally unreachable anywhere. Archive.org does not have a single copy either.

"edirect" should probably read "redirect".

Scott "SFITCS" FergusonAugust 21, 2014 8:50 AM

@Mendax


The Infoworld link is totally unreachable anywhere. Archive.org does not have a single copy either.

Tested working here using a number of DNS providers including Google (8.8.8.8). What DNS were/are you using and who is your ISP?

"edirect" should probably read "redirect".
http://www.infoworld.com/

GET / HTTP/1.1
Host: www.infoworld.com
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-au,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

HTTP/1.1 200 OK
Date: Thu, 21 Aug 2014 13:34:47 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.3.3
X-Drupal-Cache: HIT
Etag: "1408627828-0"
Cache-Control: public, max-age=0, public, max-age=600
Last-Modified: Thu, 21 Aug 2014 13:30:28 +0000
Expires: Sun, 11 Mar 1984 12:00:00 GMT
Vary: Cookie, Accept-Encoding
X-Cnection: close
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Transfer-Encoding: chunked

curl inforworld.com | grep http
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1372  100  1372    0     0    504      0  0:00:02  0:00:02 --:--:--  1214

    
    
        Click here to go to inforworld.com.
curl inforworld.com?epl=mCqU83bfycTYzb1hIeGLgVAbC8ZBQuEUyV3se_IY6oStHiBVwo9KfZEynZGucjPqn6a0eOfCzWPTjRF7kprAMd6zlFDa07nlp74WsOUeUgtG0OBM0A2dJgUh50YVdAVmVdgytV4GGBkKPjExNPT1FaKQfmoaETWGa6KkSdAAgkN6vvwAA4H0BAABAgNsKAADUxoJxWVMmWUExNmhaQpUAAADw | head -n 4
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  9 47478    9  4658    0     0   1422      0  0:00:33  0:00:03  0:00:30  3042

No cache? Google, Blekko, and the Internet archive/Wayback machine? There are others but it doesn't seem necessary to check.


Kind regards

Bob S.August 21, 2014 8:57 AM

I've always distrusted Hurricane Electric. In my opinion it's likely a government operation which besides using it as a spy platform allows crooks and hackers on board for salt.

Clive RobinsonAugust 21, 2014 11:04 AM

Part of the reason this attack worked was the fact the targeted organisations outbound firewall rules were not correctly set up...

Back in the 1990's the advise was that an administrator would not allow users computers to use anything other than the internal Organisational DNS, and that only the organisational DNS would make external requests using fixed IP addresses to "known good" external servers for the first queary... This of course caused "growing pain" problems and it thus sunk below the waves... However blocking outbound requests from clients at the firewall and using them to trigger a "potential malware" alarm would have picked this up...

roll your own snifferAugust 21, 2014 2:48 PM

Many moons ago, when Sun Microsystems was still alive producing Solaris, I wrote a little network traffic tracker using Solaris 'snoop' and Perl. With less than 25 lines of Perl code I tracked and categorized all traffic going out to the Internet. And yes, I do mean all, where it originated, and where it was going. I didn't bother with delving into the actual content, though.

Here is the kinds of things that would have raised my eyebrows:
Why is there an inordinate amount of data going OUT?
Why are there ANY DNS requests going to a server that isn't the one that's been configured?
And of course, mine looked up the IP addresses independently.

While the article mentions the DNS reroute, it doesn't mention how the data was actually sent back. Based on the URLs used, I'm guessing the data was exfiltrated as email.

This is clever, but I wouldn't put it up there as some kind of genius level hack.

65535August 22, 2014 6:22 AM

@ Bob S.

ā€œI've always distrusted Hurricane Electric.ā€ ā€“ Bob S.

I Agree.

I see a number of UDP "echo+chargen bomb(s)" and TCP "suspicious" packets from Hurricane Electric show up in customer's firewall logs - many times. I first dismissed this as a cacheing device or IPv6 tunneling device gone wild. But, I am not so sure.

I notice Hurricane Electric was formerly who owned by a French company with a number of valid IP'sā€¦ Could this be a Vupen operation?

IP address lookup

IP Address 74.82.47.61
Address type IPv4
Hostname scan-12m.shadowserver.org
ISP Hurricane Electric
Organization LaFrance Internet Services (formerly New Media)
Timezone America(UTC-7)

http://db-ip.com/74.82.47.61


Bob S,August 22, 2014 7:05 AM

@65535

Cryptome (when it's up) doesn't have much use for Hurricane Electric, either.

The exploits mentioned in this article involve the same DNS mentioned here:

http://cryptome.org/nsa-ping.htm

(sandy.thehideout.net gave me and many others the blues for a long time.)

65535August 23, 2014 10:27 AM

@ Bob S.

Good link.

The combination of Hurricane Electric and Google/NSA should be examined. Hijacking domains and abusing certs must be illegal. The only entity that could get away with it is a nation/state entity or sub-contractors to those nation/state entities.

JeffAugust 23, 2014 8:57 PM

the complaints about HE free DNS miss the point.. anyone can run a NS and serve whatever answers they want, of course. this is no different. looking at DNS queries (and not the responses) to identify malware is obviously going to have holes...

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Resilient Systems, Inc.