Last Updated: 2015-08-10 18:47:01 UTC
by Johannes Ullrich (Version: 1)
Today, our reader Jeff noted how domains ending in ".com.com" are being redirected to what looks like malicious content. Back in 2013, A blog by Whitehat Security pointed out that the famous "com.com" domain name was sold by CNET to known typo squatter dsparking.com . Apparently, dsparking.com paid $1.5 million for this particular domain. Currently, the whois information uses privacy protect, and DNS for the domain is hosted by Amazon's cloud.
All .com.com hostnames appear to resolve to 22.214.171.124, also hosted by Amazon (amazon.com.com is also directed to the same IP, but right now results in more of a "Parked" page, not the fake anti-malware as other domains)
The content you receive varies. For example, on my first hit from my Mac to facebook.com.com , I received the following page:
And of course the fake scan it runs claims that I have a virus :)
As a "solution", I was offered the well known scam-app "Mackeeper"
Probably best to block DNS lookups for any .com.com domains. The IP address is likely going to change soon, but I don't think there is any valid content at any ".com.com" host name.
The Whitehat article does speak to the danger of e-mail going to these systems. A MX record is configured, but the mail server didn't accept any connections from me (maybe it is overloaded?).
Amazon EC2 abuse was notified.
Last Updated: 2015-08-10 15:58:44 UTC
by Johannes Ullrich (Version: 1)
Here at the ISC, we operate a number of honeypots. So it is nice to see how honeypots in different shapes are starting to become popular again, with even a couple of startups specializing in honeypot solutions. Back around 2001, we had products like Symantec's "Mantrap", open source efforts like the Deception Toolkit, and of course the Honeynet project.
I don't think honeypots ever "went away" (after all, we have been running a few, and the honeynet project still has a some great tools and such to run them). But honeypots never really caught on in enterprise networks. I think there were several reasons for that: First of all, pretty much all honeypots are pretty easy to discover, and typically do not deceive the more advanced attackers enterprises are most afraid about. Secondly, a good honeypot deployment, in particular if it involves difficult to detect "full interaction" honeypots, can be difficult to manage. Lastly, enterprises dont want to be accused of "inviting" an attacker by providing "honey" to trap them.
More recently, a couple of companies sprung up to solve some of these problems. They offer either an "outsourced" honeypot (or better "deception") solution and redirect traffic from your network to their honeypot, or they leverage virtualization to make honeypots easier to deploy and manage across an existing network. In addition, they also make it easier to collect indicators from honeypots and deploy them using existing enterprise security solutions.
At Blackhat, a couple of talks focused on these newer "Deception" technologies (this is what they call honeypots these days):
Breaking Honeypots for Fun and Profit (by several people from Cymmetria)
Must read for anybody deploying low interaction honeypots. These honeypots are simple (and of course imperfect) simulations of existing systems. For example Kippo and Dioneah. If you run one of these honeypots, you should check out the techniques outlined in the talk. It shouldn't be too hard to adapt your honeypot to evade these detection techniques.
Bring Back the Honeypots (Haroon Meer and Marco Slaviero)
This talk gives a good summary of more modern honeypots and honey tokens. If you are familiar with John Strands ADHD Linux distribution, you may already know about things like booby trapped documents.
Other talks do not deal directly with honeypot deployment, but instead presented results collected from honeypots. Honeypots in our experience have been very helpful in emulating "IoT" devices, and so it is no surprise that SCADA security research takes advantage of honeypots to detect and measure attack activity.