Managed Code Rootkits: Hooking into Runtime Environments was written by Erez Metula, who founded AppSec Labs, and published by Syngress (Elsevier) in 2010.
Amazon · Elsevier · ScienceDirect · Black Hat USA 2009 slides · DEF CON 17 presentation · Talk (video)
How it started
It began with a talk. Erez Metula presented the managed code rootkits research at Black Hat USA 2009 and DEF CON 17. Before that conference was over, an acquisitions editor at Syngress had been in touch with a question that changes a year: would you like to develop a book from your Black Hat presentation? They met at the show. The publisher would provide the editor and arrange a technical editor. He said yes.
Then he did the part that made it real: he left his job — he was running the application security department at 2BSecure — to give the book the time it needed. It took most of 2010.
He spent that same year founding AppSec Labs. The book and the company were born together, out of the same research and the same conviction: that the interesting security problems are the ones underneath the application, where nobody is looking.
The idea
Most security work in 2010 assumed the platform underneath an application was trustworthy. The book asked what happens when it is not — when an attacker modifies the runtime rather than the application: the .NET CLR, the Java JVM, Android’s Dalvik.
The consequences are unusually nasty. A rootkit inside the framework sees every application running on it. It can change what a method returns without touching that method’s code — so a password check can succeed for everyone, encryption can quietly return plaintext, and a logging call can lie — while every line of application source still reads exactly as its authors wrote it. Reviewing the application finds nothing, because the application was never modified.
The book worked through how such attacks are built, deployed and detected, and came with ReFrameworker, a tool for modifying framework binaries so the technique could be studied and defended against rather than merely described.
The technical editor: Michael Howard
The publisher arranged a technical editor, and the one who agreed was Michael Howard — which, for anyone who came to security after the 2000s, deserves explaining.
Howard co-wrote Writing Secure Code, the book that taught a generation of developers how to build software that holds up when someone attacks it. When Microsoft turned the company toward Trustworthy Computing, that book is what its engineers were handed. He spent years as a senior security program manager at Microsoft, was a principal architect of the Security Development Lifecycle — the model most modern secure-development programmes descend from — and was consulting editor of Microsoft Press’s Secure Software Development Series. For most of that period he was, more than anyone, the voice of secure development at Microsoft.
He worked through the manuscript chapter by chapter across 2010, and the book is better for it. Erez Metula met him in Austin, Texas in 2011 and gave him a signed copy — which, given what Writing Secure Code had meant to him as a developer, was an honour he still talks about.
Why it reads differently today
In 2010 this was an exotic attack. The underlying question — what else is executing inside your process, and who put it there? — is now one of the industry’s central problems. Dependency confusion, malicious packages, compromised build pipelines and poisoned updates are all the same shape: code the developers did not write, running with the application’s privileges, invisible to a review of the application’s own source.
The book’s argument was that the boundary you actually have to defend is not the edge of your code but the edge of your process. That has aged well.
Why this is on a penetration-testing site
Because it is the same instinct we test with. The findings that matter in a real assessment are rarely the ones a scanner reports; they come from asking what a system assumes and what happens when the assumption is wrong. A trusted runtime is one such assumption. So is a client that has already authenticated, an object identifier that belongs to someone else, or a workflow step that everyone assumes runs in order.
Expert-led testing of complex authenticated applications – multi-tenant isolation, authorization/BOLA, business-logic and workflow abuse, complex role models – with developer-usable remediation.
Talk to us about testing your application. See also our Black Hat trainings, Autorize, and the people who came through here, the training years, and the tools we built and retired.