After building and releasing PWNboard, I got some great feedback from many folks especially Vyrus (seriously thanks!). Vyrus gave me a little insight into what he and the National CCDC team were prepping which made me realize they were leagues ahead of PWNboard. But it served as pure inspiration. I started thinking about Red Ream Telemetry (RTT) beyond CCDC, what lengths could one take it to and how could I use telemetry to convey impact and insights on red team engagements.

I built an operations tool for our Midwest CCDC Red Team called PWNboard. Our biggest challenge in these competitions is that we’re in a virtual environment where teams can revert the machines at any point and essentially kill our access. So monitoring the checkins and backdoors is essential to maintaining access for the duration of the event. And that’s why I made PWNboard, an operational board that monitors our implants and backdoors.

Working for an organization with a strict data security policy puts a few challenges on a Red Team, especially when it comes to building robust infrastructure. m0ther_ and I set out to build a robust, multi-redirector infrastructure similar to what Raphael Mudge described in his blog post, Cloud-based Redirectors for Distributed Hacking, except we wanted to host the team server on-prem. The post below describes two iterations of infrastructure we built to meet our needs.

Recently, I tried to hire an AppSec contractor to add some capacity to our team. The request went out to some contracting firms and we received six resumes just a few days after posting. Now, the problem is that my team and I don’t have the capacity to interview that many candidates or even a subset of candidates. So I decided to send all of the candidates a few relatively straight forward web app vulnerability challenges, or at least I thought they should have been straight forward or relatively simple to solve.

Updated: 2017.03.03 One of the interesting things about Node.js (server-side JavaScript) apps/APIs is that they’re event driven. As an attacker, this means there are new options for post-exploitation code execution, so I wrote a little PoC to demonstrate that. In the scenario below, we’re going to assume we’ve already identified Server-Side JavaScript Injection (SSJI) in the app. This is not a new vulnerability in Express, but an experiment in post-exploitation.