# Targeted cyber attacks: examples and challenges ahead ###### Levente Buttyán Budapest University of Technology and Economics Department of Networked Systems and Services Laboratory of Cryptography and System Security (CrySyS Lab) www.crysys.hu joint work with Boldizsár Bencsáth, Gábor Pék, and Márk Félegyházi ----- # Cyber attacks ##  cyber crime #### – financial motivations ##  hacktivism (e.g., Anonymous) #### – political motivations ##  targeted attacks #### – espionage – sabotage – DoS ----- # Targeted cyber attacks ##  highly customized tools and intrusion techniques #### – multiple different exploits in each campaign – often using zero-day (or very fresh) exploits ##  stealthy operation and persistence #### – reduced risk of detection – average time of undetected compromise is ~1 year ##  well-funded and well-staffed organizations behind #### – military or state intelligence organizations – large companies ----- # Malware ####  often used mechansim in targeted attacks  types ###### – virus, worm, Trojan, ... ####  delivery methods ###### – attachment of a targeted e-mail • spear phishing based on social engineering – redirection to a malicious web page • drive-by-download – through a compromised legitimate site • watering hole attacks – through an infected USB drive ####  infection by exploiting known or publicly unknown vulnerabilities ###### – bugs in the OS or in applications (e.g., web browser, office suite) – often allow for executing arbitrary code (e.g., installer of the malware) ----- # Phases of targeted attacks source: TrendMicro Security Intelligence Blog ----- # The problem #### RSA breach attack on Lockheed Martin Gauss EvilGrab Stuxnet DarkSeoul attack Duqu Flame Comodo attack DigiNotar compromise source: Symantec Internet Security Threat Report 2013 #### RSA breach Opera breach attack on Lockheed Martin Kimsuky Opsiness Gauss EvilGrab Gh0st RAT Stuxnet Icefog DarkSeoul attack Red October Duqu Sykipot Flame RARSTONE Comodo attack NetTraveler DigiNotar compromise Adobe breach ----- # Questions ##  Why are these attacks so successful?  How do they work? What sort of tricks do they use?  Why and how do our traditional security tools fail?  What can be done to mitigate the problem?  Are we at the dawn of a paradigm shift in security? ----- # Outline ##  some personal experience with sophisticated malware used in targeted attacks  lessons learned in these experiences  challenges for the security research community ----- # Duqu (2011) ----- # Summary of contributions ####  discovery, naming, and first analysis of Duqu ###### – creates files with names starting with ~DQ – striking similarities to Stuxnet, but different objective – advanced cyber espionage tool (keystrokes, screen shots, files) – 60-page report shared with major AV vendors and Microsoft – ~20 known victims, mainly in Iran, but also in Europe ####  identification of the dropper ###### – MS Word document with a 0-day Windows kernel exploit – anonymization of the dropper before sharing with Microsoft ####  development of the Duqu Detector Toolkit ###### – focus on heuristic behavior based detection – detects live Duqu instances and remains of earlier infections – also detects Stuxnet !! – open-source distribution (to be usable in critical infrastructures) – 12000+ downloads from 150 countries ----- # Duqu components identified **cmi4432_** **203627 (exe?)** **(comm module)** **Keylogger** **cmi4464.pnf** **(config)** **netp192.pnf** **(config)** **cmi4432.sys** **(loader)** **Registry data** **cmi4432_** **203627 (exe?)** **(comm module)** **Keylogger** **cmi4432.pnf** **(payload)** **Keylogger** **internal DLL** **(keylogger)** **Registry data** **cmi4464.pnf** **(config)** **nep191_** **res302.dll** **jminet7.sys** **(loader)** **Registry data** **netp192.pnf** **(config)** **cmi4432.pnf** **(payload)** **nep191_** **res302.dll** **jminet7.sys** **(loader)** **nep191_** **res302.dll** ----- # Static analysis of binaries ----- # Duqu jminet7 driver structure ----- # Duqu netp191 main module uncompressed ----- # Similarity to Stuxnet ----- # Duqu Detector Toolkit ##  instead of signature based identification, focus on behavior based anomaly detection #### – e.g., PNF files without corresponding INF files – detection of encrypted components and registry entries – false positives are acceptable, given the critical nature of potential targets ##  simple components (tools) provided in C source code  evaluation results #### – detect Duqu and Stuxnet.A – low number of false positive alarms ##  the toolkit has been downloaded from more than 12000 distinct IP addresses distributed over 150 countries ----- # How could Duqu have been detected? ##  manual inspection of the system status #### – multiple running instances of lsass.exe – suspicious function calls into sortEA74.nls in the stack trace of a malicious lsass instance (checked with Sysinternal’s Process Monitor) – by checking the bootlog, one can figure out that the parent process of lsass.exe is svchost.exe, whose parent process is services.exe, which injects code into lsass.exe, alg.exe, imapi.exe, spoolsv.exe and other svchost.exe instances ##  we also tested the hook detection performance of ~40 freely available rootkit detection tools on Duqu infected computers #### – several tools identified anomalies that would be very suspicious for a knowledgeable system administrator ----- # Hook detection results ----- # The Duqu experience ##  we have never done this sort of work before #### – no hands-on experience with state-of-the-art tools (e.g., IDApro) – didn’t know the information sharing practices in the AV industry – not sure about our expected role given the supposed creator(s) and purpose of Duqu ##  we worked under extreme time pressure  “Luck favors the prepared mind” (Pasteur)  increased visibility #### – media coverage – invitations to various places and visits of different “entities” ----- # Flame (aka sKyWIper) (2012) ----- # Flame (aka sKyWIper) (2012) ####  another info-stealer malware ###### – activates microphones and web cam – logs key strokes – takes screen shots – extracts geolocation data from images – sends and receives commands and data through Bluetooth ####  data saved in SQL databases  data transport via network connections and USB pen drive  infects computers by masquerading as a proxy for Windows update ###### – uses a fake certificate that looks like a valid Microsoft certificate – needed advanced collision attack on the MD5 hash function ####  thousands of victims, mostly in Iran, Israel (Palestine territories), and Sudan, but also in Hungary! ----- # Flame vs. Duqu (Stuxnet) ###  Flame is a platform different form Duqu (and Stuxnet) ##### – larger code size – use of Lua scripting language – use of SQLite databases – larger C&C infrastructure – C&C servers run different OS (Ubuntu vs. CentOS Linux) ###  they may be two implementations for the same requirement specification developed by two different teams  the two teams may not be independent ##### – Kaspersky researchers found chunks of code from a 2009 Stuxnet variant inside Flame – CrySyS Lab identified an encryption routine that is the same in Flame and Stuxnet ----- # The fake certificate used by Flame #### chains up to the MS root can be used for code signing! looks valid ----- # MD5 collision attack ----- # Rapid SSL attack in 2008 ####  collaboration of hackers and academics led by Alex Sotirov and Marc Stevens  demonstrated a practical MD5 collision attack against the RapidSSL CA ###### – resulted in a fake SSL certificate trusted by all browsers ####  generating a collision required 2 days on a cluster of 200 PS3s ###### – equivalent to about $20K computing capacity on Amazon EC2 source: presentation of Alex Sotirov ----- # Challenges for the attackers ###  serial number and validity values are not controlled by the attacker ###### – they depend on the issue time of the certificate ###  the attackers needed to get the certificate issued at the right moment (matching the preset serial number and validity) ###### – they had a 1-millisecond window to submit their query – probably large number of attempts were required ###  questions ###### – Did the attackers have a fast collision generation algorithm or a large cluster for computations? – Were they located close to Microsoft’s certificate server to minimize packet jitter? ----- # MiniDuke (February 2013) ###  targeted multiple government entities and human right organisations ##### – governmental victims have been identified in Ukraine, Belgium, Portugal, Romania, the Czech Republic, and Ireland ###  uses targeted pdf documents as droppers ##### – exploits the Acrobat Reader 0-day vulnerability that was published by FireEye on February 12, 2013 ###  drops a highly customized backdoor written in assembly language ##### – very small in size (only 20kb) and unique for all victims ###  this backdoor uses Twitter and Google to locate C&C servers ##### – The weather is good today. Sunny! uri!wp07VkkxYt3Mne5uiDkz4Il/Iw48Ge/EWg== ###  downloads stage 2 and 3 codes from C&C server disguised as GIF files ----- # Lessons learned ###  current practice to defend systems against targeted attacks have limitations ##### – Duqu, Flame, and MiniDuke passed signature based virus scanners – code signing did not help either ###### • compromised signature key in case of Duqu (and Stuxnet) • fake certificate for signature verification key in case of Flame ###  the attackers are in possession of advanced cryptographic knowledge ##### – MD5 collision attack in Flame ###  vigilant system administrators could detect advanced attacks with simple approaches and available tools ##### – manual inspection of system status, resource usage, and bootlog – available rootkit detector tools ----- # Lessons learned ##  mainstream security products are bypassed by attackers #### – McAfee, TrendMicro, Sysinternals tools failed to detect Duqu and Flame – attackers can fine-tune their code until it pass mainstream products ##  information sharing is crucial for identification of droppers (and potentially 0-day exploits) #### – we played the role of a trusted mediator between Microsoft and the Duqu victim – this led to efficient handling of the incident and the discovery of a 0-day Windows kernel exploit – unlike in our case, security vendors are often unable to obtain forensics information even when their product detected infection ###### • droppers of Flame? ----- # Challenge #1: Prevention ####  signature based scanning does not work ###### – assumes that AV company already detected the threat before it affects the user – not true for targeted attacks (you may be the first and only victim) – polymorphism allows for individualized malware samples – attacker can test AV products available on the market ####  on-the-fly dynamic analysis of behavior? ###### – open document / download web page in closely monitored virtual machine – examples: FireEye, LastLine – problems: • malware can detect the virtualized environment • ensuring transparency is very difficult ####  sandboxing and virtualization? ###### – create isolated execution environments and monitor accesses through their boundary to system resources – examples: Java VM, VMware, VirtualBox, Bromium vSentry, Qubes OS – problems: • usability, convenience, and performance issues ----- # Challenge #2: Fast detection ####  determined and resourceful attackers will eventually succeed in compromising any system  detection of being compromised can focus on lateral movement, C&C communications, and data exfiltration  Security Information and Event Management (SIEM) systems? ###### – collect and correlate event logs – raise alarms – problems: • false positives • need expert knowledge to configure properly ####  defender can also take advantage of the home ground ###### – can use traps and baits to mislead the attacker – examples: honeypots and honeytokens – also allow for observation of attacker activities, tools, and tactics – problems: • management of honeypots and honeytokens can be cumbersome • is this only a question of lacking good management tools? ----- # Challenge #3: Information asymmetry ## attackers have knowledge on available security tools, and they may also know the security posture of the defender defenders know very little about the attacker  how can we decrease this asymmetry?  hide some part of the security posture #### – custom security tools and configurations – honeypots and honeytokens could also be used here ##  try to obtain more information about the attacker #### – threat intelligence gathering from different sources – client honeypots ----- # Challenge #4: Information sharing ###  victims of attacks are reluctant to share incident information and forensics material ##### – privacy issues, sensitive company related information ###  security vendors could collect lot of information on potential new threats ##### – e.g., silent detection by AV vendors, Cisco SenderBase, cloud based protection by SIEM vendors, ... ###  but security vendors may not want to share their collected intelligence to preserve market advantage ###  standards for exchange of incident data are emerging ##### – STIX - Structured Threat Information Expression – TAXII - Trusted Automated Exchange of Indicator Information ###  legal issues may impede data sharing ##### – incident reports, traffic logs, DNS data include personally identifiable information ----- # Challenge #5: Lack of good experts ##  a good expert #### – knows about old tricks and new trends in cyber attacks – knows the systems and networks he is responsible for – can use and configure available security tools – can select new security tools to buy – has time to look into the tools’ output ##  better education, training, simulation exercises are needed ----- # Questions? ## Dr. Levente Buttyán CrySyS Lab, Budapest contact info: www.crysys.hu -----