I grew up as an insanely curious kid. My parents have seemingly endless numbers of stories of me taking things apart and trying to put them back together (sorry about the lawnmower, dad). There’s something about solving puzzles that has always captivated me.
As I got older and entered the workforce, I continued looking for ways to scratch that itch and why I ultimately ended up working in offensive security. My favorite part of my job isn’t phishing, working through privilege escalation chains, or taking over “crown jewel” systems — it’s research. Much like when I was a child, the dissection of something, whether it be an operating system component, a piece of malware, or legitimate software, is a process that I’ve fallen in love with over the past ten years.
I recently read Yarden Shafir’s Security Research and the Creative Process post and have been advising a few friends’ research projects, which inspired me to document and share my research process. My hope here is to provide some insight into what this looks like behind the curtain and help another curious kid somewhere in the world scratch that same itch I have.
Identify
The first, and often hardest, part of research is selecting a topic to dig into. Many people, myself included, have felt like there will be some lightning strike of inspiration that never seems to come around. In reality, there are plenty of different ways to find a target, none of which being the “right” way. Here are just a few:
- Exposure: Happening across a topic that looks interesting to you. This doesn’t have to happen at work. For example, the whole reason I got into driver security was because I was looking at video game anti-cheat software.
- Branching: Finding an interesting area while working on something else. This tends to happen when focusing on a broad topic, such as Active Directory, where there are many separate components that all tie into that root topic.
- Prior Art: Drawing inspiration from other’s work. This can be somewhat taboo, but the way I look at it is that we’re all learning from each other and growing together. By giving credit early and often, the original effort can be acknowledged and those ideas can be expanded on by your own efforts.
- Requirement: Sometimes your research topic is chosen for you, whether it be a job requirement, an answer your team needs, or any other external force that directs your focus to a specific topic. This has happened to me recently where we had an operational need for full disk encryption on an ARM device, leading me down the rabbit hole that is Adiantum.
Whatever the method of identifying your research topic, you should have a question formed by the end of this phase. This can be as simple as “what is X?” to as specific as “can I make X do Y in Z case?”
Understand
When the topic has been identified, an extremely common instinct I have seen is being so eager to dive in that they try to jump straight to the end of the research. What I advocate for is slowing down and seeking to deeply understand the topic. I know that this can be frustrating to hear. I was very much one to try to jump to the end until I had a mentor tell me to take a step back and truly understand what I was looking at. In that moment, I resented that idea and felt like I was being held back for no reason. As time went on, I started to understand where he was coming from.
Think about building a pyramid. If you build a small base, you’re only going to be able to build that pyramid so tall before it eventually topples. If you spend the time building the base, its height will quickly surpass the one which was built as tall as possible from a small base.
Which looks sturdier?
Another component in which I am a huge believer that fits into this phase is the concept of “build then break”. This is the process of gaining a deeper understanding of the topic by implementing it yourself. For example, if you’re interested in Active Directory security, deploy your own forest. If you’re interested in RPC, write your own RPC server. Through this process, you gain exposure to underlying design patterns, potential missteps, and quirky implementation details, all of which deepen your understanding of the topic.
By the end of this phase, you’ve done the preliminary legwork to get up to speed on your topic, giving you a strong base on which you’ll build the rest of your pyramid.
Explore
Building off of the knowledge gained in the last phase, this portion is the longest section of any research project and involves exploring any of the interesting things you observed previously and latch onto it. This may be things like a weird API, a misconfiguration related to faulty documentation, or a cool detection chokepoint, but it’s really anything that speaks to you.
This phase of research is where anything from a groundbreaking discovery to your initial idea falling flat on its face will occur. A personal example of the latter is some research I did on WebUSB recently. I thought it would be pretty cool if we could fingerprint connected USB devices like mice, keyboards, and integrated cameras for sandbox detection. It turned out that it wouldn’t work for my use case as WebUSB only lets you collect that information after a user accepts a prompt.
In my and many others’ experience, research is never a straight line from forming a hypothesis to proving it. There are times where you go down the wrong path, find something even more interesting that pulls you in a different direction, run into a brick wall, or are forced to step back to address a knowledge gap that’s preventing you from moving forward.
If your original idea does fall flat here, that doesn’t mean that the effort was meaningless. Think about what you learned from the Understand phase and how much more of a solid grasp on the topic you have. Through exploring the specific thing that piqued your interest in this section, you’ve undoubtedly come to learn a few new things about it, generated more ideas related to it, and been exposed to new areas that could potentially before the focus of your next research effort. What’s important is that you don’t look at a research idea that didn’t pan out as a failure but rather an inevitable of consequence of doing something new and an opportunity to share what you’ve learned.
If your research effort does yield something, congratulations! That high you’re feeling after seeing your idea pan out is hard to describe. Appreciate that moment because after you come down from cloud nine, there’s still a long road ahead. Next comes the portion of the project where you take everything you’ve generated — from scratch pads to code snippets to drawings — and distill it down into a proof of concept.
Develop
Before entering this phase, you’ve proven out a research idea but it is still in its rough form. Think about it like finding a raw diamond. You are technically holding a diamond, but it still needs to be cut and polished before it can really stand out. This phase is where you refine your proof, test assumptions, hunt for corner cases, and develop the idea further to gain as deep of an understanding of it as possible. You should seek to answer questions like:
- Why does this work?
- How does this work?
- In what cases will this not work?
- Are there more succinct ways demonstrate this?
- What happens if X happens when I’m expecting Y?
An example where this phase shined was when I was working on Shhmon. Originally, the tool looked for a minifilter sitting at altitude 385201 with the name “SysmonDrv”, Sysmon’s default, and would unload it. While I was polishing up the proof of concept (PoC) that would eventually become the tool, Matt Graeber posed the questions “What if Sysmon isn’t at its default altitude?” and “What if they name it something other than ‘SysmonDrv’?” At the time, I hadn’t considered those problems and they would have left huge gaps. I went back and looked at ways to find Sysmon running with non-standard altitudes and names and implemented those checks, making a more robust PoC and giving me a deeper understanding of the problem set.
At the end of this phase, you should have a (ideally refined and succinct) PoC that proves your hypothesis and can be demonstrated to an audience.
Share
The last, and most important, phase of research is sharing what you’ve learned. After working in environments where sharing things publicly, for one reason or another, was discouraged, I am incredibly passionate about this phase. By sharing what you’ve learned during your research, you improve that audience collectively, regardless of size.
I often hear from friends hesitant to share research that didn’t pan out the way they wanted it to. There’s a lot to be said about this notion of research being “good enough”, but I will say there is a huge amount of value in reading through another person’s thought process and experiences. Such an emphasis is placed on the end state that we tend to neglect the value of the journey to get there. There have been more than a few times where I was working on something and happened across some random forum post from 2006 where a user had the same issue as me and the thread is full of discussions and debugging notes that saved me countless hours of going it alone, even if the original poster never found a solution. Putting things like this out there lets someone pick up the baton at a later time and we need more of it.
Additionally, not everything you share needs to be groundbreaking. Sometimes simply restating something using your own style can be immensely helpful. For example, I’ve never been great at interfacing with LDAP. All of the documentation I had read previously didn’t “click” for me mostly due to density and lack of applicability. Then Hope Walker published her post An Introduction to Manual Active Directory Querying with Dsquery and Ldapsearch and immediately it all made sense. It wasn’t anything new, per se, but the way Hope was able to convey what she was trying to do and how she went about doing it just made everything fall neatly into my head.
Find your preferred format and share. For me, it’s blog posts as I prefer longer-form content. For some friends, it’s conference talks. For others, it‘s posting on forums. The medium isn’t as important as just getting the content out to the world. Additionally, the size of your platform does not correlate to the value of your work. Having a small audience does not make your research less valuable. For example, one of my all time favorite conference talks is Genetic Malware by Travis Morrow and Josh Pitts from INFILTRATE 2016. This talk shaped research for me for the two years following and led to the release of Spotter. There were < 50 people in the room and the video has ~250 views.
All this is to encourage you to put yourself out there, regardless of the outcomes of your research. There are no entry requirements for publishing research. If you found it valuable, then undoubtedly there will be someone else who will as well.
Conclusion
Research can be as daunting as it is exciting. I hope sharing some of my experiences from over the past few years helps shine a light on how things look in the real world and not just the end states you’re seeing on Twitter. While this is how I approach the process, there is no right way. Some people like completely unstructured research while others set up Scrum boards with deadlines. I’m somewhere in the middle of those two groups, as I’m sure many of you are, and we each need to find a process that works for us as individuals.
Regardless of what you end up researching, I hope you can apply some of the concepts in this post, continue sharing what you learn, and grow to love the process just as much as the outcome.
Formalized Curiosity was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.
Article Link: https://posts.specterops.io/formalized-curiosity-3c550ece803e?source=rss----f05f8696e3cc---4