After giving my fair share of interviews at multiple companies over the past 5–6 years, I’ve noticed some positive and negative qualities and behaviors among candidates. Although there are hundreds of generic interview preparation resources available, I’m hoping this set of tips will come in handy for people new to interviewing or to Infosec. Here’s a collection of tips I’ve gathered over the years:

DON’T put yourself at an immediate disadvantage by taking the phone interview from somewhere loud or distracting. Coffee shops and noisy outdoor areas offer zero control if a baby starts crying, music starts playing, or a firetruck drives down the road. Taking an interview in a loud environment shows poor judgement and planning and will likely end up distracting you in a noticeable way.
DO get to wherever you plan to take the interview at least 5 minutes early and make sure your phone is charged. Review your own resume and mentally note what your talking points are when you are about your work history. A few minutes before the call, relax, take a few deep breaths, and remember to stay positive. If you find yourself in a situation where noise happens (baby starts crying, dog starts barking), calmly explain the situation to the interviewer and take a few minutes if needed. …

I picked a heck of a project to set up my first continuous integration pipeline.

No one enjoys making silly mistakes when it comes to debugging projects, and the pain felt by those mistakes can be amplified exponentially when it takes hours of building or compiling code to discover them.

The initial setup of DetectionLab was an absolutely brutal process. Packer builds might run successfully for 90 minutes and then randomly time out while running Sysprep at the last step. Sometimes Vagrant would intermittently lose connections to the hosts it was bootstrapping, or I might typo a command and it would be hours into the build process before the bug became apparent. …

Detection Lab is a collection of Packer and Vagrant scripts that allow you to quickly bring a Windows Active Directory online, complete with a collection of endpoint security tooling and logging best practices.

Detection Lab consists of 4 total hosts:

• DC: A Windows 2016 domain controller
• WEF: A Windows 2016 server that manages Windows Event Collection
• Win10: A Windows 10 host simulating a non-server endpoint
• Logger: An Ubuntu 16.04 host that runs Splunk and a Fleet server

I started Detection Lab as a personal challenge to myself. I initially came across Stefan Scherer’s adfs2 repo which provided all of the building blocks I needed to set up Active Directory using Vagrant, and his packer-windows took the guesswork out of building Windows-based boxes. …

With the Thanksgiving holidays providing a bit of free time, I decided to poke at some of the challenges on http://pwnable.kr. I’ve been working through a handful of them over the last few days, but I really enjoyed the cmd1 and cmd2 challenges.

cmd1

The object of these challenges is usually to view the contents of the “flag” file, often by finding flaws in a compiled C binary. Here was cmd1.c:

The premise of this challenge is simple. …

If you’ve read any of my previous stories, you know that I write quite a bit about osquery. Today was an interesting journey down the debugging rabbit hole.

The Problem

While testing an osquery deployment and installation script for Windows, I ran into a weird issue where osquery was not correctly parsing the flagfile that I was passing to it. In fact, it was not parsing any of the flags inside of the flagfile. Even stranger was the fact that this same flagfile content had been working a few hours earlier before I had started testing the deployment script.

The usual suspects

At this point, I knew I had to be overlooking something obvious. I tried every combination of rebooting, installing older versions, and looked for any possible typo that could be causing the issue. Oh wait, maybe CRLF vs. LF line breaks?! Nope. No matter what I did, osquery refused to acknowledge the flags that I was passing into the flagfile. …

One security engineer’s trials and tribulations attempting to comprehend one of the least known but most powerful Windows services.

Before reading this post, please be sure to read @jepayneMSFT‘s excellent post on Windows Event Forwarding: Monitoring what matters — Windows Event Forwarding for everyone

Additionally, also check out Microsoft’s Use Windows Event Forwarding to help with intrusion detection

Introduction to Windows Event Forwarding

If you’re new to the concept of Windows Event Forwarding (WEF), the long story short is that a service exists in Windows where you can specify one or more servers to operate as Windows Event Log collectors. These collectors server as subscription managers and allow you to cherry pick which event logs you would like to collect from endpoints and the forwarded logs are then stored in buckets on the collectors. When using the Windows Event Forwarding service, the event logs are transferred natively over WinRM, which means you don’t have to worry about installing any sort of log forwarder software (Splunk/WinLogBeat/etc) on all of your endpoints to send logs to a centralized location. …

I’ve been purchasing Dell monitors ever since I can remember. The first monitor I vividly remember purchasing was a Dell 2007WFP. I loved it so much I eventually ended up with three of them.

More recently, I was exposed to the U3417W 34" Dell curved widescreen monitor. I initially thought it was ridiculous until I pulled up a giant set of Splunk query results on it and realized I could comfortably tile four different virtual machine desktops across the screen. I was provided one in my workplace and quickly purchased one for home as well.

More to the point, I also wanted a smaller, quicker monitor for gaming. The Dell S2417DG caught my eye and I snagged a new (open box) model on eBay from a seller with thousands of positive feedback. As soon as it arrived, I opened it and it quickly became apparent that this monitor was not new. The plastic wrapper had been removed from the Dell logo, the back of the stand was covered in beige colored dust, and the screen had a fair number of fingerprints. …

osquery for Security was aimed at people who are new to osquery, but this post will dive deeper into some of the more advanced and less known features that osquery has to offer. In addition to scheduling queries against aspects of your operating system, osquery has built in functionality to monitor file integrity, audit network connections and processes, and even log hardware device changes in near-realtime.

Define a Data Collection Strategy

osquery is most useful when you’ve planned out what data you want to be collecting ahead of time.

As tempting as it can be to run tools in stock configurations, much more value will be derived from doing some homework around the data you collect and potential alerts that can be built around that data. osquery doesn’t function like a traditional HIDS/IPS in the sense that those types of products generally fire “alerts” when something looks suspicious. There is a no such thing as a “one size fits all” osquery configuration — you need to see for yourself what data is available to query and make your own decisions about what to collect and how to respond to it. …