Technical analysis and information sharing in the handling of high-profile targeted attacks

Technical analysis and information sharing in the handling of high-profile targeted attacks Boldizsár Bencsáth Laboratory of Cryptography and System Security (CrySyS) Budapest University of Technology and Economics Department of Telecommunications http://www.crysys.hu/ http://www.crysysatm.com/ this is joint work with Gábor Pék, Levente Buttyán, and Márk Félegyházi and the “Flame/sKyWIper” Team

Who are we • CrySyS Lab, BME discovered Duqu, sibling of Stuxnet • Our Lab participated in an international collaboration and published paper on “sKyWIper/Flame” malware • Duqu team of 4 researchers • We’ve been working solutions against targeted attacks since 1999 • Duqu, Flame came as an opportunity and we seized it • current work: results + expertise  dependable security solution(s) to mitigate “Advanced (Persisent) Threat” attacks

Duqu • Stuxnet and Duqu, sophisticated targeted attacks of recent times • Stuxnet: self-replicating malware to harm Iran’s uranium enrichment centrifuges • Duqu: information gathering • Duqu is a malware that we discovered in the wild in an incident reponse investigation • Naming: infostealer component creates files starting with the string “~DQ” • Duqu = Stuxnet ? • striking similarity in terms of design philosophy, internal structure and mechanisms, implementation details, and the estimated amount of effort needed to create it Human dropper 

Our main contributions • Discovery, naming, and first analysis of Duqu • wrote the first 60-pages report – show the striking similarities with Stuxnet • shared our analysis with major anti-virus vendors and with Microsoft • an anonymized and shortened version of this report was published as an appendix of the first Symantec report on Duqu • Identification of the dropper • MS word document with a 0-day Windows kernel exploit • made the dropper available to Symantec that sanitized and shared it with other anti-virus vendors and Microsoft • Development and open-source distribution of a Duqu Detector Toolkit • based on heuristics, follows a different approach than signature based malware detection • detects live Duqu instances and remains of an earlier infection by Duqu • a real-life experiment resulting in much insight on the whole case • Mediators of information sharing for efficient security response • delicate position – lot of trust needed • How and what to share? • Conflict of interest among parties • Successful sharing of the sample from a private company – privacy, anonymity concerns • Took the most time

sKyWIper/Flame • In May/2012 we participated in an international collaboration to investigate a novel malware, we called it sKyWIper • 27/05 – National CERT of IRAN (Maher) disclosed they are investigating a malware “Flamer” • 28/05 – CrySyS released initial tech report on Flame/sKyWIper; Kasperksy released details about their work on “Flame”. • We give no details what was exactly the collaboration, with whom we were working on and how -> potential personal risks to be avoided.

Flame • Flame is possibly the most complex malware ever • We produced an initial detailed analysis of Flame with the help of others: http://www.crysys.hu/skywiper/skywiper.pdf • We wrote some blog entries on insights of Flame (USB storage, GPL license violation of Duqu, WuSetupV.exe URL creation http://blog.crysys.hu/ • sKyWIper name is for ~KWI temporary files and the possible connection between “wiper” malware of Iran

Stuxnet/Duqu vs. flame

So what is Stuxnet/Duqu/Flame • Duqu/Stuxnet are built on a common platform (also called it as “TildeD”) • Duqu is an info stealer created from the lego kit • Stuxnet is a sabotage tool created from a bit different pieces of the plaftorm • Flame is developed by totally different way of thinking: Totally different team • Flame compontent was found in Stuxnet/2009: independent teams, but cooperated some times

How to work with such malware? • Clueless: You obtain information about strange things but you cannot decide how important it is. • It should be possible to guess the importance of such things. It needs general expertise. • Flexibility: You decide to work on some unimportant/marginal topic, or an important one without funding. • You need an environment where it is possible to rearrange work at personal level, or in the group. • Secrecy: You find something very important that cannot be told to others even inside the company • Again, a very flexible environment is needed to be able to keep secrets. You also need good friends to trust, inside and outside of the company.

Skills needed • Responsibility • Reverse engineering • Forensics: Pinpoint important in big data, use tools efficiently • Knowing some about encryptions (but not cryptographer) • Skill to understand complex systems and select next tiny part to focus on • Programming (small scripts etc., but efficiency is not important) • Flexibility to learn novel things (think Lua) • Knowing how malware works (but knowing them all is not needed) • Knowing networking technologies (including how to make MiTM for SSL connections, etc.) • Knowing how Windows/Linux works (internals) • Knowing some tools to work with to find clues • Virtualization and sandboxing. • Thinking like an attacker is thinking (tricks, etc.) • Having friends and contacts

Registry data Keylogger Registry data internal DLL(keylogger) jminet7.sys (loader) cmi4432.sys (loader) netp191.pnf (payload) netp192.pnf (config) cmi4432.pnf (payload) cmi4464.pnf (config) nep191_res302.dll cmi4432_res302.dll cmi4432_203627 (exe?)(comm module) netp191.zdata.mz Duqu components found at CrySyS case

Just the first round of modules of Flame Local data files dstrlog.dat lmcache.dat mscrypt.dat ntcache.dat rccache.dat ssitable Zlib compr. OCX files mssecmgr.ocx 6M-resource 146 (2,5M) advnetcfg.ocx 0,6M msglu32.ocx 1,6M nteps32.ocx 0.8M soapr32.ocx 0,2M sqlite Created during startup Temp data files ~HLV084.tmp 0,6k ~HLV294.tmp 0,2M ~KWI ~rf288.tmp Temp code files To691.tmp 1,5M ccalc32.sys boot32drv.sys Encrypted sqllite file list log, no reproduction at C

#Flame: list of affected files (partial) ~dfc855.tmp Ef_trace.log contents.btr wrm3f0 scrcons.exe Wavesup3.ocx Ntep32.ocx m4aaux.dat mpgaud.dat msaudio mspbee32 ~a49.tmp wpgfilter.dat Ssitable urpd.ocx lib.ocx lss.ocx target.lnk stamn32 guninst32 ~HLV ~DEB93D.tmp lib.ocx lss.ocx ~DEB83C.tmp stamn32 ~dra53.tmp nteps32 cmutlcfg.ocx ~DFL983.tmp ~DF05AC8.tmp ~DFD85D3.tmp ~a29.tmp dsmgr.ocx ~f28.tmp desc.ini fib32.bat ~d43a37b.tmp preg.exe ntcache.dat lmcache.dat rccache.dat dcomm.dat dmmsapi.dat ~dra52.tmp commgr32 target.lnk ccalc32.sys ~DEB13DE.tmp zff042 urpd.ocx Pcldrvx.ocx ~KWI guninst32

Complexity vs. analysis • Flame is just too complex to analyze within limited timeframe

WuSetupV structure of flame • Took some weeks to get someone disclose details

Duqu keylogger internal part • No detailed analysis on some aspects, after half a yer

Duqu – jminet7 driver structure • Still some find out interesting things in the code

Browse32 • Flame Suicide module, Browse32 is 450k large • High complexity: Why? – Known for weeks, detailed analysis: N/A

Duqu/ Netp191 main module uncompressed • Maybe just a bunch of libraries, but who no one can be sure

Process of finding new malware vs. outsiders think about • Outsiders think it’s “You found something, you analyze it, you share it” • Reality: • You obtain (receive/find) some sample – and you find it is a normal OS file • You obtain other sample – and you find it’s a modified version of malware X • You obtain a sample of an ultra-important malware – but it’s not a code, just an encrypted data file or similar. You cannot do too much even if you exactly know it is important. Otherwise you dismiss it (most likely happened many times) • You obtain a part of a malware that can be analyzed – finally you can work, but most likely it’s just a partial data. Maybe elements are missing and you need more forensics to go on. • You obtained a number of pieces of the malware – You cannot be sure that it is total. You cannot handle so many modules/much information, you cannot categorize things, you cannot keep on with the different versions of the same malware • Need to share findings to get others with more knowledge etc. work • We think that the best way to go forward is what we did: Producing technical document detailing with all findings in detail and even all questions • The major goal is not publicity, but helping other tech people • For publicity producing high-level material is much better and easier

Management and mediator role • 70-80% of the work is non-technical, much of that is after disclosure • What to tell, share, disclose • What not to tell, share or disclose • What permissions needed • Obtaining legitimate contact points to partners • Checking identity (legitimity) of parties) • Encryption related problems (key exchange, key check etc) • Checking press, twitter, webinars, etc. to keep up status • Selecting, saving important information found on the net

Sharing problems • Duqu: Code/sample cannot be shared until prooved that no data related victim is in the sample • Flame: Sample cannot be shared in full depth as it can contain sensitive/victim related information • Both: Even if the malware had victims in Europe, it is still a question if, or when public disclosure of informations should be done • Duqu: Company wanted to remain anonymous • We had to have our report published as anonymous appendix of Symantec report • Many newspapers stated Symantec found Duqu • Reputation/trust is more important than publicity

Ccalc32.sys • Obviously it’s encrypted • But what it is, should I share?

Ccalc32.sys after decryption • It’s not executable, but data • Maybe it contains target sepecific values • Sharing is problematic

WuSetupV.exe list of URL parameters usage mp: is fixed 1 for first query jz: session identifier fd: computer identifier am: MAC address of interface ef: IP address pr: is 0 if StandardSize already exists, pr=1 for new installations ec: generally 0, probably some error checking related to ~DHF593.tmp file ov: Windows version number pl: Process list ac: is fixed 1; used in second query gb: 0, ?? rt: is a0b0c0d, ?? dd: value of StandardDateBias, if set (see http://blog.crysys.hu/ for details)

Targeted attacks – what’s new? • Targeted attacks are asymmetric attacks (like sniper attacks) • The sniper can aim at any time, any means, any target, any vulnerability, etc. – consumer grade products cannot protect against them • Traditional tools can help, but don’t solve the problem (firewalls, IDS, IPS, UTM, spam filtering, etc.) • What we propose to be used against such threats (proved to work): • Anomaly detection • Baits, honeypots, traps • Whitelisting and anomaly detection • Event correlation, situation analysis, manual analysis and professional care • Innovative and individual solutions (tailored to the customer)

Discussion on code signing • code signing is extensively used today to authenticate the identity of the producer of a software and the integrity of the code • unsigned software can no longer be installed on recent and future versions of Windows without warning messages • a common assumption is that if code is signed then it can be trusted • FALSE !!! • signature key may be compromised • a valid signature does not tell anything about the trustworthiness of the signer (even if the signature key is intact) • there are multiple ways to get a piece of malware signed in practice (see CARO’10 slides of Jarno Niemela, F-Secure) • The Flame Microsoft certificate abuse (MD5 collision + PKI architecture problems) is one of the most important problems lately. – • PKI / code signing can have flaws.

Problems with code signing misplaced incentives and scalability issues  negligent key management limited effectiveness in establishing trust in software Software companies do not really care: • CAs have strict authentication policies when evaluating a certicate request, but… • no periodic audits aiming at the verication of how the private keys are handled and used by the certificate owner • has there been any case when the certificate of a software maker was revoked due to its negligence in key management and code signing procedures??? • as a consequence, software companies have no real incentives to follow strict key management policies • code signing keys are often stored on development machines without strong protection

Problems with code signing misplaced incentives and scalability issues  negligent key management limited effectiveness in establishing trust in software CA’s do not really care either: • whoactually should perform the auditing of software companies? • CA’s may be interested, but it would not be scalable,and it would be too costly for them • what if a software company is detected negligent? • CA revokes its keys and does not issue new certificates • company obtains certificates from another CA with weaker requirements • strict CAs lose their customers • CAs have no incentive to do strict verifications

Discussion on signature based detection • signature based malware detection is important, as it is the most effective way of detecting known malware – not good to targeted attacks • however, Duqu and other recent targeted attacks clearly show that it is not sufficient • creators of high-profile targeted threats have the resources to fine-tune their malware until it passes the verication of all known anti-virus products, • such threats will basically never be detected by signature based tools before they are identified and their signatures are added to the signature database • possible approach: heuristic anomaly detection • main problem is false positive alarms • more work on white listing techniques and cloud based information sharing may improve the situation • academic research could contribute a lot in this area • In some application domains, false positives are acceptable

What are we working on? – CrySyS ATM • CrySyS Advanced Threat Mitigation technology – www.crysysatm.com • 10+ years in designing security solutions and proposing solutions against this kind of threat • Integration of results • Adaptation to CI and similar environment • Make our solutions more scalable • Our solutions already proved to work, but there are challenges in commercial deployment: • prove that the solution does not affect the operation of existing infrastructure • lowering the need of trust in the company who runs such mitigation services by controlling what they can do • adaptation to processes of the host • adaptation of techniques to different areas,e.g. PLC, embedded system honeypot • Protecting the protector: our solutions should not elevate the risk in any sense

Questions? http://www.crysys.hu/

Duqu known versions (Kaspersky)

Technical analysis and information sharing in the handling of high-profile targeted attacks