[RPZ] Trojan.Spachanel - Using SPF records for malware signaling (problem for RPZ sinkholing?)

Rod Rasmussen rod.rasmussen at internetidentity.com
Tue Jan 29 20:24:16 UTC 2013


It looks like some malware author has gotten very cute, and good at figuring out how to get around some standard detection methods for DNS tunneling/signaling.  The miscreants are burying hostnames and IPs to use for assembling URLs in SPF records for domains they control.  Thus you won't see weird looking TXT records or some other odd stuff that could indicate signaling/tunneling in DNS queries, but rather vanilla-looking SPF records.  Clever.  Further, I'm wondering how this will affect certain RPZ implementations.  Clearly I can still use the NX Domain approach to cut-off signals if I have the DGA cracked, but what about if I'm redirecting to a sinkhole?  What happens to the TXT lookup that my infected computer is asking for?  Can I provide a fake answer under RPZ, will it provide nothing, or will it give the actual value published by the AUTH servers for the domain?  I think the first, but can someone confirm?  My sinkhole will never see traffic though, as a TXT lookup won't result in actual malware traffic to my sinkhole IP like an A record would.  That's a nasty problem for detection of these, and I would suppose I'm then limited to logging of the requestor on the internal network side in order to track down my bot.

Thoughts on how to deal with the sinkhole issue presented here via RPZ?

Thanks,

Rod

> 
> 
> http://www.pcworld.idg.com.au/article/452057/browser-hijacking_malware_talks_attackers_using_spf_email_validation_protocol/
> 
> 
> A new Trojan program that displays rogue advertisements during browsing sessions uses a DNS-based email validation protocol called the Sender Policy Framework (SPF) in order to receive instructions from attackers without being detected, according to security researchers from Symantec.
> 
> The new malware is called Trojan.Spachanel and its purpose is to inject malicious JavaScript code into every Web page opened on infected computers, Symantec researcher Takashi Katsuki said Friday in a blog post.
> 
> The malware injects HTML script elements that load JavaScript files from remote URLs. The role of the JavaScript code is to display rogue advertisements inside pop-up windows and trick users to click on them, which generates income for the attackers, Katsuki said.
> 
> However, the most interesting aspect of this malware is the way in which it receives updated URLs from attackers to use in the rogue HTML script elements.
> 
> The malware periodically generates a domain name according to a predefined algorithm and makes an SPF lookup for it. Knowing in advance which domain will be generated, the attackers register it and configure its SPF record to contain IP (Internet Protocol) addresses or host names that will be used by the malware to construct new malicious URLs.
> 
> SPF was designed to detect email spoofing and is implemented using the DNS (Domain Name System).
> 
> A domain name owner can specify an SPF policy -- a number of IP addresses or host names that are allowed to send emails from that particular domain -- inside a DNS TXT or SPF record. Email servers can then perform SPF lookups via DNS in order to check that email messages appearing to have been sent from that domain actually came from an IP address authorized by the domain administrator.
> 
> If the sender IP address or host specified in an email's header is not listed in the SPF policy for the corresponding domain name then the email sender's address was probably spoofed.
> 
> In the case of Trojan.Spachanel, the SPF policy for the domain name is not used to validate emails, but to provide a new list of malicious host names to be used by the malware.
> 
> Using this technique, attackers can hide the malicious traffic from firewalls and other security products that might otherwise block direct connections to known malware command-and-control servers.
> 
> That's because in order to perform SPF lookups, the malware queries a trusted DNS server located on the local network or the Internet service provider's network. This server then queries other DNS servers up the chain until the request reaches the authoritative DNS server for the domain name, which responds with a TXT or SPF record containing the SPF policy.
> 
> "In some cases, specific domains are blocked by a local DNS server, but this malware generates a domain that is rarely filtered," Katsuki said
> 
> 
> 
Rod Rasmussen
President/CTO





E-mail: rod.rasmussen at internetidentity.com
Office: +1.253.590.4088 | Mobile: +1.253.297.0377 | Fax: +1.425.699.6597 
24/7 Service Line: +1.253.590.4100 ext. 0 | 888.239.6932 ext. 0




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/dnsfirewalls/attachments/20130129/bf98d9e2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IID_email.png
Type: image/png
Size: 8786 bytes
Desc: not available
URL: <http://lists.redbarn.org/pipermail/dnsfirewalls/attachments/20130129/bf98d9e2/attachment.png>


More information about the DNSfirewalls mailing list