Malware

Home » Malware

Inside ClickJacking Malware

in Malware by admin Comments are off

inside-clickjacking-malware

While Clickjacking isn’t as pervasive as it was in the mid 2000’s, hackers are getting increasingly crafty in how they deploy it.

PacketSled recently contributed research to a TechCrunch article about a particularly crafty clickjacking deployment Clickjackers: Inside The Strange New World Of Modern Spyware.

“We were able to retrieve a sample which our research team analyzed for behavioral traits and indicators. From these data points we were able to preform an analysis across our sensor network for the threat. The resulting investigation not only provided ammo for the article, it increased our customer’s security posture.” said Harrigan.

It’s all part of the day to day security research at PacketSled and the industry as a whole, but we’re very pleased to help TechCrunch get this kind of information out to the wider tech public.

The Biggest Companies in the World Are Failing at Basic Detection

in Incident Response, Malware, PacketSled, Threat Detection by Matt Harrigan Comments are off
We received a really interesting email from our upstream Internet provider yesterday – AT&T, indicating that we were effectively infected with Tinba malware. For those of you who don’t remember it, Tinba is 4 year old Windows specific Malware based on the old Blackhole exploit kit that does all kinds of fun stuff like steal facebook credentials, attempt to access your online banking accounts, etc. The email was as follows: att-incident Technical and operational observations are as follows:
  • First, we don’t possess any Windows machines capable of executing this Malware, with the exception of some VMs that are turned off unless otherwise needed.
  • Second, all of those machines have adequate endpoint protection on them, such that they would have averted this ancient attack, should it have been, you know, actually happening.
Regarding the email we received, if you haven’t already found the funny part, I’d like to point that out first. Obfuscating the IP address of the site that (according to them) indicates an infection is extraordinarily unhelpful, almost to the point where I feel like they might be trying to live up to some weird obtuse legacy of what it was like to order circuits in the 1990s. Thankfully, they took the time to include the domain name, which, you know…resolves to the obfuscated IP address listed directly above it. The unfortunate part about this situation is that they simply didn’t have the proper tools to make a quick determination that this was in fact, not a threat at all, and that we were running some tests on this network against legacy threat intel. Of course, we knew that, and we could easily validate that such testing was occurring during the timeframe that they mention with a simple query in the investigator as follows:
Querying specific IPs during specific timeframes using natural language

Querying specific IPs during specific timeframes using natural language

We get one session record returned:
PacketSled Investigator

PacketSled Investigator

And immediately determine that this “threat” originated from a Mac running Wget:
Hey look, not a Windows machine. Not even a real browser.

Hey look, not a Windows machine. Not even a real browser.

Nevertheless, we received this email, meaning that someone in the AT&T SOC had to investigate this non-incident, put in a ticket, send the email and manage the eventual closure of that ticket. This scenario is extremely commonplace. The number of SOC personnel, incident responders, and general infosec professionals that routinely chase non-incidents due to only having partial data is extremely perplexing. The data is in the packets. Making it accessible to analysts and automated processes such that it can be intelligently used is the goal. With something this simple getting incorrectly bubbled up to the top, we are clearly a long way off from that goal.

© 2016 PacketSled, Inc.