Record and replay debugging against in-the-wild exploit kits and other practical cases

Friday 6 October 10:00 - 10:30, Small talks

Jarkko Turkulainen (F-secure)
Jarno Niemelä (F-secure)



'Record and replay' code analysis has been a topic of interest in academia for the last 10 years, but has not yet offered practical results when applied to exploit analysis. A 'record and replay' approach to debugging - specifically, a responsive and deterministic implementation that can record a full code execution and replay it offline, as well as step it forwards and backwards, set breakpoints and handle other common debugging tasks - would be a great advantage to exploit researchers, provided it can circumvent current anti-debugging tactics used by malware authors.

Several papers have been published on the 'record and replay' approach as it pertains to JavaScript. The tools these papers relate to, however, rely on specific web browsers (most commonly Firefox) or specific functions in browsers. The tools' lack of support for other browsers, particularly the popular target Internet Explorer (and to a lesser extent, Edge or Chrome) make them ineffective against real-life exploit kits with anti-debugging or anti-tracing capabilities. These kits are able to detect if an exploit is being run in a different browser from the expected target - for example, if exploit code for Internet Explorer or Chrome is being run in Firefox. In such conditions, the kit will refuse to work, under the assumption that a researcher is trying to debug and analyse the exploit.

In our research, we successfully apply the 'record and replay' approach to debugging to showcase its potential benefits, and demonstrate a real-life implementation of it which can interactively debug JavaScript exploits and other malicious code. Our implementation is browser-agnostic, able to work natively in any browser being targeted by the exploit. JavaScript API manipulation is used to make it appear as though the exploit is running on a vulnerable targeted browser, leading the exploit kit to complete its attack. In reality, the malicious code is run in a secured browser where the full exploit code and execution flow is exposed without crashing the browser, allowing us to easily identify known exploits.

 (Note: this is a reserve paper for VB2017. Unless needed to replace another paper on the main programme, it will be presented in the Small Talks room at 09:30 on Friday 6 October. Programme changes will be announced at the event and displayed on the VB2017 programme page.) 

 

Jarkko-Turkulainen-web.jpg

Jarkko Turkulainen

Jarkko Turkulainen works as a senior researcher for F-Secure. He joined the company in 2004 as a malware analyst and since then has been working in various roles, ranging from daily malware sample handling to anti-virus engine R&D. Now his main focus is on prevalent advanced threats.

 

 

Jarno-Niemela-web.jpg

Jarno Niemelä

Jarno Niemelä has spent the past 17 years at F-Secure security lab working on analysing and identifying malicious behaviour and planning automatic malware handling systems. His current duties focus on automating cyber-attack detection and planning new cyber-defence systems for F-Secure products and services. Keen on data science and on analysing APT and malware behavioural patterns, he also teaches cyber defence at Metropolia University of Applied Sciences. He often speaks at cybersecurity events.

@jarnomn



VB2018 MONTREAL!

VB2017 OVERVIEW

VB2017 SPEAKERS

VB2017 PROGRAMME

VB2017 PHOTOS

2017 PÉTER SZŐR AWARD


Other VB2017 papers

The state of cybersecurity in Africa: Kenya

Tyrus Kamau (Euclid Consultancy)

The cyber threats Kenya faces range from basic hacking such as website defacements, financial fraud, social media account…

Walking in your enemy's shadow: when fourth-party collection becomes attribution hell

Juan Andres Guerrero-Saade (Kaspersky Lab)
Costin Raiu (Kaspersky Lab)

Attribution is complicated under the best of circumstances. Sparse attributory indicators and the possibility of overt…

Keynote address: Inside Cloudbleed

John Graham-Cumming (Cloudflare)

In February 2017, Cloudflare was revealed to have been leaking private information including HTTP headers, cookies and POST data…