Sign up to our newsletter
At this time of year I’m usually getting ready to travel to Virus Bulletin, maybe the year’s most important conference for an anti-malware researcher. Sadly, for the second year running I’m unable to attend, though it would have been nice to see Prague again – the conference is at the Clarion Congress Hotel – and the networking with other researchers is always an attraction. It’s also something of a milestone in that for the first time since 2007, I don’t have a paper to present there. But maybe 15 VB papers since 1997 is enough for one lifetime. :)
Other presentations that caught my eye included Does prevalence matter? Ranking anti-malware products by potential victim impact by Microsoft’s Holly Stewart and three of the guys from AV-Comparatives, a Small Talk on The Clean Software Alliance, security, and the future of unwanted behaviours, and a paper on Effectively testing APT defences by Simon Edwards, Richard Ford, and Gabor Szappanos.
And, as most years, there is plenty of representation from my colleagues at ESET. (In the case of papers with more than one author, all authors are listed, but they won’t necessarily all be onstage for the presentation, of course.)
Wednesday 30th September between 12.00 and 12.30 in the Red Room.
Cybercrime certainly feels like a major threat to network security. Criminals routinely use networks to steal data, defraud companies and consumers, and disrupt normal business operation in both public and private sectors. But just how big a threat is cybercrime? For a problem long characterized as both huge and existential by politicians and industry pundits, cybercrime has largely gone unmeasured, if ‘measure’ is taken to mean ‘ascertain the size of the problem using sound scientific methodology’.
This presentation reviews the cybercrime literature, both commercial and academic, for answers as to why we lack reliable, consistent, longitudinal data on the size and scope of the cybercrime problem. The following issues are addressed:
The paper concludes with suggestions as to how the current dearth of reliable data may be remedied and a call to action to educate the industry on the appropriate use of available data.
At the same time, there’s a talk by ESET’s Righard Zwienenberg, Symantec’s Mark Kennedy and Professor Igor Muttik of Intel Security: Wednesday 30 September 12:00 – 12:30, Small Talk.
More and more HTTP traffic is being encrypted (HTTPS). This increases security by preventing listening into the conversation, but it also creates a problem for security products that need access to that information as well. To address this, many security companies implement a ‘man-in-the-middle’ protocol, where they broker the keys from both ends of the conversation, and thus are able to inspect the content.
For some websites now — and perhaps many more in the future — the client is checking to verify that the SSL certificate is routed to the server. However, these checks will fail because the certificate returned by the security product will not match the server’s domain. We see some of these failures in the field today, and more will likely follow.
The IEEE Industry Connections Security Group is working on a secure solution to this growing problem. We will show where we are, and discuss how we will move forward towards an industry solution.
Wednesday 30 September 15:00 – 15:30, Red room.
How do you win a game when the rules don’t let you?
You change the rules!
In the computer security field, one possible game changer is aggressively fighting back. Star Trek’s fictional James T. Kirk changed the Kobayashi Maru simulation from a no-win situation to one where a winning solution, but can we do the same? What are the ethical and legal challenges?
The dilemma stems from the problem that fighting back will have consequences, sometimes technical, sometimes ethical, sometimes legal. In a world where pointing NMAP at another’s host is considered more than just impolite, using an exploit to gain control of an alleged C&C server, which is probably illegal in most countries anyway, is stepping well over the line. But not changing the rules means we persist in our course of staying one step behind the criminals. This is not satisfactory as it looks like everyone is losing in this scenario – except the criminals.
In this paper we will present various real and hypothetical scenarios of fighting back. For example: sinkholing; SSH honeypots that counter attack (yes, this is real); abusing open directories; hacking C&C servers; taking over botnets by either hijacking the C&Cs or buying them; shutting down DHT-based botnets; modifying phishing pages so they no longer work; using DDoS attacks against criminal infrastructure; and so on. We are not advocating any of these aggressive methods, and what we lay out in the paper is unlikely to be exhaustive. However, we will discuss where we, as the authors, see the boundaries of what we can do so that the readers come away with a better ethical framework for their own activities.
This discussion is long overdue as some mild forms of aggressive defensive tactics have already been tried, and some common daily working activities of security analysts may have potential legal consequences where few currently imagine there might even be ethical considerations. In some cases, the law is in conflict with what may seem like ‘technical common sense’. However, these laws usually have solid foundations and being seen to violate them, even if there are no likely legal consequences, can have negative effects on cooperation with other companies and/or law enforcement agencies, or on public perception. We see this not as a final statement on the matter, but the beginning of a discussion that should accompany our actions in this new frontier.
Wednesday 30 September 16:30 – 17:00, Green room.
Obfuscation techniques have become increasingly prevalent in malware programs, employed as tools to thwart reverse engineering efforts or to evade signature-based detection by security products. Among the most popular methods, the use of packers – which are programs that transform an executable file’s appearance without affecting its semantic execution – is now widely adopted by malware authors. However, despite the rise in the number of malicious programs distributed with packers, we still lack a global picture of their current use. What kind of packers protect malware nowadays? Is there a common model? Previous attempts, based on static database-signature tools, failed to build an accurate picture of the use of packers by malware, their main limitation being that static analysis says nothing about the actual behaviour of the packers and, due to its static nature, misses run-time features.
In this paper, we present WaveAtlas, a novel framework designed to map the code used by packers. Using a dynamic analysis approach, it reconstructs in a nutshell the structure of the code modification tree where the root is the packed code and packer, and the nodes represent snippets of code extracted in successive ‘waves’. We report on a large-scale experiment conducted on a representative sample of thousands of pieces of self-modifying malicious code. Our results allowed us to successfully identify common features of malware packers, ranging from their self-modification code usage to exotic choices of machine instructions. In particular, we were able to confirm some commonly held beliefs regarding the use of packers by malware writers. For example, a malicious payload (e.g. code including network callbacks) is typically present in the last or penultimate wave. Furthermore, the number of waves is relatively small and the structure of the trees relatively simple, indicating that malware authors are probably using simpler tools and parameters as a compromise between stealth and efficiency.
Wednesday 30 September 17:00 – 17:30, Green room.
Nowadays, .NET samples are increasingly common, necessitating specialized techniques for processing and analysis, especially when obfuscation is used: .NET packers have many tricks up their sleeves, but fortunately we do too.
A skilled researcher can often glance inside ‘good old-fashioned’ native executables and see what they do despite protection with strong packers. However, .NET files are different.
Analysing clean .NET files with dedicated tools shows us almost everything, but if the file is obfuscated we sometimes see nothing at all. In .NET analysis we face one main obstacle — complex runtime technology which introduces some level of abstraction and therefore makes debugging harder.
This paper combines analysis of methods collected from various sources with techniques originating with the author’s own experience, in order to improve sample management. It describes simple tricks for getting strings after packer decryption or logging APIs used as well as some more sophisticated examples.
All the problems addressed relate to real cases often encountered in the context of commercial packers or of custom protectors used by malware.
Such tricks can be used for single analyses for adding breakpoints in locations of interest or as building blocks for constructing a powerful tool for analysing .NET samples.
Thursday 1 October 14:00 – 14:30, Green room.
With the geopolitical situation in Ukraine still in turmoil, targeted cyber-espionage attacks in the country continue to escalate. One of the attacks we analysed in depth last year was BlackEnergy (a.k.a. Sandworm). In 2015, one of the malware families we have been focusing on is another threat mostly active in post-Soviet countries: Potao.
Win32/Potao is a trojan that has recently been used (the most recent attacks were detected in July 2015) to spy on high-value targets such as Ukrainian government and military entities and one of the major Ukrainian news agencies. Other countries targeted by this universal cyber-espionage toolkit include Russia, Georgia and Belarus. In Russia, for example, the malware was used to spy on members of MMM, a popular financial pyramid scheme.
One of the most interesting discoveries during our Potao research was the connection to a Russian version of the popular open-source encryption software TrueCrypt. We discovered a website that has been serving a Russian-language-localized version of the TrueCrypt application that also contains a backdoor, targeting specific targets. In a few cases the trojanized TrueCrypt was used to install the Potao trojan.
In addition to an overview of the attack campaigns using Potao or the trojanized TrueCrypt (detected by ESET as Win32/FakeTC), we will also present the highlights of our detailed technical analysis of both trojans.
Recently, we have released a comprehensive whitepaper with details on our findings. The presentation will supplement a summary of key points already made public with our most recent discoveries, as well as possible links to other malware families and APT groups.
Thursday 1 October 14:00 – 15:30, Small Talk.
We’ve all heard horror stories about how little diversity there is in the greater tech field, as well as in InfoSec in particular, a phenomenon often apparent at industry events. But how does our current situation compare with the past? And what can (or should) we do to change that? Is there truly a shortage of candidates for employment in security jobs and if so, can greater diversity help solve that problem.
This presentation looks at multiple aspects of the diversity in tech problem, assessing what has been, and what might be done in the future. For example, we examine trends over time to determine patterns, and look at cyber security job listings to compare them with those in the broader tech industry to see if this provides clues to solving the problem.
Efforts are underway to change the composition of the security industry, making it more inclusive, and this paper provides a look at existing groups and initiatives that focus on supporting minorities in tech and InfoSec careers. We will also offer resources for those seeking to provide mentorship opportunities for students and others seeking to enter this industry.
[Lysa offers a taste of what the talk will cover in a recent blog: Virus Bulletin small talk: Diversity in tech.]
Thursday 1 October 14:30 – 15:00, Green room.
Embedded Linux platforms have been increasingly targeted by malware authors over the past few years. The targeted devices, labelled under the umbrella term ‘Internet of Things’, are generally consumer routers, gateways or modems. They are compromised remotely via brute-forcing of their credentials or being victim of an unpatched vulnerability, such as the infamous Shellshock. Most of these compromises result in the targeted system being assimilated into a botnet.
Recently active examples of embedded Linux botnets include Linux/Aidra, Linux/Dofloo (AES.DDoS), Linux/DNSAmp (Mr.Black), Linux.Gafgyt, Linux/Moose and Linux/Tsunami. Due to the availability of malware source code, several disjoint botnets co-exist; they target several architectures including ARM, MIPS and x86, with variants (or forks) of the threats being common. Of the aforementioned malware list, only Linux/Moose stands out as being one of the rare threats not in the DDoS business, with no x86 variant found and controlled by a single group of actors.
Linux/Moose is built with SOCKS and HTTP proxying capabilities as well as a generic packet sniffer with an exfiltration mechanism. It is used by its operators to commit follow, like and view fraud on social networking sites such as Facebook, Instagram, Twitter and YouTube. It has the ability to spread on its own with a little assistance from its C&C server to provide binaries specific to the victim’s architecture. It targets ARM and MIPS architectures with the latter targeted in both big- and little-endian variants. Additionally, the malware has code to pivot past firewalls and perform NAT traversal to allow attackers to operate from within firewalled networks.
This talk will first describe some of the challenges of reverse engineering embedded malware and analysis. Then we will cover Linux/Moose and the way it was operated. Expanding on the paper we released last spring about this threat, we will give an update on the current status of the botnet and the various means we are using to find its next evolution. To conclude, we will draw some conclusions on whether our publication successfully scared the operators and killed the threat or not.
Author David Harley, ESET