Security, Engineering, Research

Current: Engineer at Google

Previous: Engineer/Team Lead at Databricks, from security to client-side JavaScript and build tooling.

Before joining Databricks I specialized in abuse and security. I worked at ICSI and EECS @ UC Berkeley as a research scientist. My research was part of the overall effort called CESR: Center for Evidence-based Security Research (UCB EECS, ICSI, UCSD, and NYU) and funded by the NSF.

My specialties include: computer security, malware analysis, abuse, account fraud and compromise, spam, web security, networking, operating systems.

Security at Google

At the end of February 2017 I joined a software engineering team that works on security at Google. I work out of the SF office.

I work on security features for Google Cloud customers to make their environments on GCP and elsewhere more secure.

Engineering at Databricks

In August of 2014 I joined Databricks. At Databricks I have had a few different roles and fill in where needed on work in security and networking.

I started as an IC on a team that does full stack web development. My projects included planning and executing a nearly complete rewrite of the Databricks frontend to move from Backbone and Underscore templates to React, as well as significant work on the web serving tier (Scala + Jetty). I have also contributed to frontend engineering code quality and stability by introducing a unit testing framework for JS and building a JS build pipeline. Along the way I have also worked closely with other teams at Databricks for compliance and security purposes.

In January of 2015, I took responsibility for the team as an engineering tead lead and managed the team for about a year as it grew to 11 people. The focus for the team continued to be on web engineering and in particular user facing features. Once the team had grown, I divided the team into two and continued to manage the user-facing and frontend focused half.

In March, 2016 I changed roles and became the team lead for the internal tools and infrastructure engineering team. The focus of the team is on build, test, and release stability. The team's goal was to improve all aspects of engineering productivity.

Studying Bulk Account Creation

Kurt Thomas presented one of our recent research papers at USENIX Security 2013 (in Washington, DC). The paper is available here, and USENIX will be putting the talk online. The other content is available from the USENIX Security site and is free.

Several news articles have been written about it, here’s a few:

As far as our work goes, this continues our line of research looking at the abuse of social networks. We have documented abuse in several forms before (CCS’10, S&P’11, IMC’11, LEET’12), but the goal with this project was to develop an understanding of how accounts are created in bulk, as well as the market for these accounts.

We set out to perform this study by buying accounts from the underground market. Once we started buying accounts, we determined that we could build a classifier to retroactively identify accounts that came from any of the merchants we had bought accounts from. This let us examine several aspects of the automation infrastructure that enables this marketplace, such as IP address diversity, captcha solving rates, and others. In all, the classifier found millions of accounts that had been created by the 27 merchants we bought from (with the top few merchants responsible for the vast majority). Twitter then suspended the accounts we identified in several large batches.

Censoring Political Speech on Twitter

We have a paper this year at LEET — it’s a interesting look at policitically motivated spam on Twitter. We caught this thanks to an article Brian Krebs wrote ( and followed up investigaing the attack. Not only did this type of attack happen again during the actual Russian elections, but is a problem elsewhere in the world too (see:

It appears that the infrastructure that was used to perform the attack (accounts and computers) was drawn from general spam-as-a-service stores and you can read more in our paper, or come see Kurt Thomas give the talk on April 24th:

“Adapting Social Spam Infrastructure for Political Censorship.” Kurt Thomas, Chris Grier, and Vern Paxson. To Appear in the Proceedings of the USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET). April 2012. PDF BIB

Paper at IEEE S&P 2012

I’m a co-author on a paper this year at IEEE S&P that looks at the methodology behind how malware experiments have been conducted in recent papers at top-tier venues.

“Prudent Practices for Designing Malware Experiments: Status Quo and Outlook,” Christian Rossow, Christian J. Dietrich, Christian Kreibich, Chris Grier, Vern Paxson, Norbert Pohlmann, Herbert Bos and Maarten van Steen.

The goal is to come up with a set of guidelines to help guide malware experiments so that other members of the research community are able to better assess the proposed techniques. We found that often malware researchers fail to perform critical steps in their experiments (leading to misleading results) as well as omit important details in their paper, leaving the reader unable to understand the evaluation. There’s a website up for people to comment and suggest guidelines for better experimental methodology:

If you would like a copy of the paper, email me: