Acknowledgments
I would like to acknowledge and graciously thank the following people:
My Wife, for putting up with my countless sleepless nights and non-stop obsessing while I worked to crack this puzzle.
Bev Robb, without you, I don’t think I would have been able to solve the mystery of TDO. Sometimes the most random connections and pieces of information can lead to the most significant discoveries, and that is exactly what happened. Thank you so much for putting up with my millions of questions and late-night text messages. I am eternally grateful to you and hope I can one day repay the favor.
Christopher Meunier, for never letting go of that easily identifiable chip on your shoulder that relentlessly muttered statements like this, giving me all the motivation I needed to keep pressing on:
whitepacket@xmpp.is: I'm sorry man but you sound like you're either LE or a f***ing retard, probably the latter.
Dennis Karvouniaris, Thanks for all the info and help you gave me along the way. I’m sorry things had to work out this way. I always enjoy our chats and hope that by the time you read this you will have taken my advice.
Chris “The Human Hacker” Hadnagy, for believing in me enough to connect me with the fine folks at Wiley, ultimately landing me this book deal.
Alex Heid and Jesse Burke, for all the back and forth and continued help pulling some of these pieces together.
And to all of this book’s guest experts, I can’t thank you enough for volunteering your time to contribute your stories and opinions for this book. I will be giving you all proper credits in the first chapter, but I had to give you all an extra shout-out here as well.
One of the more recent investigations I worked on involved the hack of a multibillion dollar organization. Their stolen data was posted for sale in private circles, and upon finding this out, I immediately contacted the organization. The organization had many questions, and given my prior investigative work, I was able to reach out to the threat actor on their behalf and obtain information on how the breach occurred.
The following text is a portion of the writeup provided by NSFW, a threat actor we will be covering in much greater detail throughout this book, where he describes, in detail, how he was able to hack this organization’s network. The process he used was sophisticated, and by no means a run-of-the-mill drive-by hack.
This was very well planned and executed.
All identifying information has been changed.
HACK WRITEUP: NSFW
Firstly I realised that GitHub is adding new device verification within the week, therefore I tried to identify as many developers as possible and sign into their GitHub account to access organisation private repo’s.
I then identified software developers working for Company using LinkedIn.
Partially doxing each one to obtain Gmail accounts, I found Bob.
Performing database lookups in hope for password reuse (or rules to be applied to their previous password) in order to login with valid credentials.
The way I got into the GitHub was due to Bob, who reused the password “BobsTiger66” (Which GitHub had told was insecure with a red banner, yet he chose to ignore it), and was reused on multiple private databases and one public database (ArmorGames).
Once logged in I had to act quick to avoid GitHub’s new ML algorithm to lock accounts out of using new IPs, so I immediately used ssh-keygen to add a new public SSH key to the user profile, I had realised you had added Okta SSO preventing the clone of private repos, in order to bypass this I looked at potential integrations.
CircleCI is a popular CI/CD tool which is inherently linked to organisations via either SSH key linkage or PAT’s, therefore I realised the build processes could be exploited in order to obtain private repos, however this was not needed. You guys had added a weird implementation of Okta STS with AWS, producing time-limited tokens, I realised these were spawned everytime a new build process was triggered, therefore I accessed Circle debug mode and managed to extract these time limited tokens, and used them to download your internal datalakes.
Unfortunately these tokens were not given any further privileges, therefore you got lucky or else I would have gained access to RDS via CLI and cloned a snapshot.
When I read this, I was immediately impressed by the level of effort he put into the hack. And despite the outcome, the client was, too.
In the end, this breach had a happy ending, because I was able to provide useful intel to the customer that allowed them to identify how the breach happened, and to also put in proper safeguards to ensure that this did not happen again. That’s ultimately the point, right?
Not to provide customers with a useless writeup of generic TTPs (tactics, techniques, and procedures) regarding assumed threat actors—which is what so many threat intelligence companies do—but to actually provide useful context for how a threat actor breaches their systems.
So many companies just rely on providing existing reports on threat actor groups and never actually get to the core of how an attack happened. Sometimes it takes actually hunting down the threat actors and speaking to them directly. They are usually pretty open and willing to brag about how they did it, because on some level all hackers want to be famous; and as we will see in future chapters, vanity always trumps OPSEC (operational security).
In this particular case, I was already speaking to NSFW about several other hacks he is associated with, so it was no issue to ask how he was able to pull this off.
And if you are paying close attention, you will have noticed several misspellings and important “tells” associated with his writeup. Common misspellings or even regional differences in spelling (e.g., organisation vs. organization) can be very important investigative clues that we will discuss in future chapters.
But before we dive into all that, I feel it is important to shed some light on who I am, so you can get to know me a little better, understand what makes me tick, and maybe get accustomed to some of the dry humor and sarcasm that you will find sprinkled throughout this book.
My Story
When I started writing this book, I asked myself a simple question: Am I qualified to write this book? To this day, my answer is still “probably not.” I don’t believe one person can know everything there is to know about a topic, which is why you will find tips and stories from other industry experts throughout this book. I admire and respect each of the people that I have asked to contribute to this book. I know their work firsthand, which is why I feel they each bring their own unique perspective that complements and reinforces the topics I will be putting forward.
But before we get to that, here is some insight into who I am and what makes me tick.
History
I was about 10 years old when my dad brought home an IBM PS/2. I had no idea what it was or what it could do, but I was mesmerized. This was before the Windows 3.1 days. I remember turning it on and staring at a DOS prompt and just hacking my way through it. The whole thing was like a giant puzzle, which is probably why it sucked me in.
I am a huge puzzle junkie. The more complex, the better. One of my strengths (and also admittedly a weakness) is that I can be relentless when I am trying to find a solution to a complex problem. Some have referred to this behavior as “obsessive.” I get it, and I acknowledge the behavior.
There are nights where I am still cranking away at 4 a.m. because I just can’t stop. It’s part of who I am, and it is a big part of why I feel that I am very good at what I do—whether that be trying to hack into a system or assembling the story behind a criminal investigation.
Roots and Raves
In case you are wondering, I started out my career as a web developer writing HTML and JavaScript in the late ’90s. I grew up in New Jersey and was always into electronic music. Naturally, I was also entranced with the rave culture. Nightclubs like Limelight and Tunnel were the big thing, and I wanted to be a part of it.
Unfortunately these clubs had a 21+ age requirement, which was a problem because I was 16. So I taught myself HTML and offered to build a free website for one of the club’s resident DJs. From then on, I could just walk in with him because I was his “web guy.” Problem solved.
Penetration testing is not much different, which is why I have been doing it (in one form or another) all my life. It’s all a matter of understanding what the rules are, then figuring out a way to circumvent them.
I have always been good at finding ways to get around the rules, which I think is a trait shared by most penetration testers.
Don’t get me wrong, rules are important. Some people like living their lives in a well-defined sandbox, while others enjoy the challenge of trying to find ways to break out of it. I am the latter.
Developing a Business Model (with Lasers!!)
One evening circa 2011, I was browsing the Internet the same way most people do: with Burp suite active and running passive recon on all sites that I visited.
I was telling my wife about an awesome site that sells high-powered lasers in different colors, hoping she would let me buy one. That was a hard no, but much to my surprise, Burp suite found a passive SQL injection vulnerability in the site. I had to check it out, and before I knew it, I was able to see the site’s user accounts with hashed passwords. Logging in to the site with one of the admin accounts meant having to crack the admin’s password hash, which wasn’t difficult using any number of online hash crackers given that the password was some variation of Admin123.
I logged in to the site and voilà! I had full access to everything. System records, user accounts, order information, and all.
NOTE Yes, I now realize this action was not exactly “legal,” but don’t judge. We all have to start somewhere. Plus, this story has a happy ending.
It was that exact moment that I felt the entrepreneurial spark. What if I could take this information and give it to the site’s owners so they could fix the injection bug, preventing others from accessing the site in the same way? Surely they would repay this random act of kindness with some of their badass high-power lasers?
I am now the proud owner of a 2,000mW blue laser, and a 1,000mW green laser! Nice, right? The lasers actually burn stuff. They are pretty bad-ass. More importantly, the site closed the SQL injection vulnerability, and I had a model for a business to provide services that could actually help people.
In the process, I also learned an extremely valuable lesson: If you hack into a website first, then try to offer the solution to the customer and ask for a “tip” in the form of a product from their website, it could be interpreted as extortion. Oops. That clearly wasn’t my intent, which I think came off in my email with the CEO, but looking back, I am sure I could have been in some trouble. So while this particular exercise worked out well for everyone, I clearly had to do some work in refining the business model.
Education
One day while I was working for the Department of Defense, I heard from a senior leader that he was going to be bringing someone onto his team that recently completed his “ethical hacking” certification.
Certification? I bet I could do that, seeing as how I already had the skills to hack into things and had been doing it all my life. It sounded like a great career path doing something that I really enjoyed, so I started looking into it.
By this point, I had already earned a bachelor’s degree. I started working a tech-support job while I was in high school, then only took a semester of college before dropping out. It was not until much later that I decided to go back and finish my online bachelor’s degree.
After some research, I found a master’s program at Western Governor’s University (WGU) that specialized in information security and included the Certified Ethical Hacker (CEH) and Certificated Hacking Forensic Investigator (CHFI) certifications as part of the coursework. So I decided to get my master’s degree.
After a few years, I finished my master’s and had all of the certifications that I wanted. Thinking back, I guess I felt a lot like Forrest Gump when he was running across the country: I had already made it this far, so I might as well keep going, right? So I decided to skip the customary CISSP certification and went for my PhD.
I spent about four more years taking online classes and wrote my dissertation on the “perceived effectiveness of the cybersecurity framework among CISOs of varying industries.” I received my PhD in 2018.
Starting Night Lion Security
Having worked with a number of large organizations, including being director of security services for RSM (a top-five accounting firm), I felt that I had a unique perspective on how other organizations performed penetration testing and risk assessments, and I knew I could provide something better.
In 2014, I decided to start Night Lion Security, my own security consulting firm. My vision was (and still is) to assemble an elite force of hackers and penetration testers in order to deliver a report that is thorough and useful.
Being a startup security consulting firm is difficult enough on its own. Being a security startup and trying to compete against giants like Optiv, KPMG, SecureWorks, and AT&T has been brutally difficult.
I feel that I was able to stand out in such an oversaturated market by being heavily active in the news and media. I feel that being on TV is one of the core reasons why companies were willing to take their chance with a small startup that no one had ever heard of. I don’t think I would have been able to make it this far without that.
I have been criticized for this approach because I am seen as the person that is “self-promoting” by going on TV. But in the end, I feel it was worth it because doing so has allowed me to give back in a way that I would not have been able to otherwise. The following is a perfect example.
We recently completed a penetration test for a large, publicly traded bank. At the end of the test, the VP of security went out of his way to tell me that our test was “the first actual penetration test they ever had.” All of the big “board approved” companies they used in the past did nothing more than provide a glorified vulnerability scan, and we were able to give them something much more valuable. I am extremely proud of this, and so thankful that he told me because this is exactly the vision I set out to accomplish when I started Night Lion.
Digital Investigations and Data Breaches
The transition to digital investigations was so seamless that it wasn’t a transition at all. I wouldn’t even say I “moved” to digital investigations, because it was always just something that I did. Working incident response cases, penetration testing, solving complex problems—it is all the same. It’s all about cracking a puzzle.
As I quickly found out, working on your own cases (i.e., looking for exposed data leaks and breaches) can quickly become more of a challenge in dealing with the aftermath than actually finding and exposing the data.
I uncovered a number of high-profile data leaks including Exactis, Apollo.io, and Verifications.io (which I will discuss more in Chapter 14), and in each case the aftermath of the exposure was different every time.
Verifications.io was particularly interesting because that led to a situation of discovering that the exposed data had actually been stolen from someone else. The company turned out to be completely fake, and once I started poking around, they shut it all down and went running.
There have also been many times where I have gone in circles sending copies of data to dozens of companies trying to find the owner.
Something to consider: If you contact a company inquiring about a possible data breach (or leak), that company is under no obligation to tell you whether the data actually belongs to them.
Despite the fact that people in this industry may be trying to do the right thing, there are significant repercussions that go along with a company having to publicly admit to a data breach (or leak)—for one, someone is almost always going to get fired, or worse. . . .
In Chapter 14 I detail my own account of the Exactis breach and other discoveries. Let’s just say it’s never fun (or easy) when a CEO sends you a text message on a Saturday night asking why you’ve ruined his life. Here is Troy Hunt, owner of HaveIBeenPwned, with a similar story:
EXPERT TIP: TROY HUNT
An incident that comes to mind is when V-Tech, the Hong Kong toy maker, was breached. This would have been around 2015. This was a huge amount of data relating to kids, including the kids’ photos. V-Tech had SQL injection all over the place, it was just an absolute train wreck.
The trouble there as well is it’s a Hong Kong toy maker, and as soon as you seem to get to that part of the world, it can be really, really hard to get ownership for these incidents because the company will just sort of shut the doors on you and ignore it, which is what happened in my case.
Breaches with that level of sensitivity are, I think, particularly interesting.
Along those lines as well, the Red Cross Blood Service in Australia had a similar incident a couple years ago insofar as it was a large amount of very sensitive data, including mine. My blood donation application was in there.
This was about half a million Australians, including your blood type and including eligibility criteria or the questions to eligibility criteria such as have you had at-risk sexual activity. It is a perfectly valid question to ask someone about to donate blood, but not a perfectly valid thing to back up from a production server to a publicly facing test server with enabled directory browsing.
The difference with the Red Cross is they just did an enormously good job of their handling of the incident once it actually went live. They regularly stand out now as the gold standard for post-breach incident handling, which is good.
Everything has its ups and downs, but at the end of the day, I love what I do. This book is the culmination of the past twenty years of my life. I have filled it with real-life stories, scenarios, and techniques that will hopefully one day help you in your own investigations. With that, let’s rock and roll.
Hunting Cyber Criminals
Getting Started
This chapter covers the important items that you should know before getting started, as well as topics like what you will and won’t find in this book, the top takeaways from this book that will be discussed regularly in subsequent chapters, and some prerequisites to help ease your journey in cyber investigations.
Some of you may be looking for a reason to get into the field. Some of you may already be in the field and looking for new techniques to use during your own investigations.
In either case, I feel the need to warn you that starting an investigation can be like running a marathon. It can be slow and tedious, and take forever to get where you’re going.
You need to be extremely self-motivated because trying to connect dots in an entire Internet of unorganized clues and information can be extremely discouraging.
But if you press on, and muster through that initial pain, it will eventually happen.
There is a feeling you will eventually find during an investigation. It’s the same feeling experienced by coders or hackers—it triggers the moment you pull on that first major thread or unlock that first tumbler, which gives way to the second, and the third . . . and eventually the entire world lights up.
There is nothing better or more exhilarating than entering “the zone.” It’s like a precision laser-focused state—your own “bullet time”—where you can’t be slowed or stopped until you’ve solved the puzzle, hacked the system, or accom-
plished the thing that you’re working on. It’s a rush better than any stimulant or drug—in a word, it’s amazing.
Throughout this book, I will provide you with information on my own personal arsenal of tools that I hope will help guide you to exactly that place. I will also provide you with my own experiences and thought processes using many of those tools, because I’ve found that it can be much more helpful to learn how a person uses a particular tool, rather than just re-creating a user’s manual.
Why This Book Is Different
I have read a number of digital investigation books, and they all seem to just list every tool possible, provide a short summary of what that tool does, and move on to the next. Almost like herding software cattle.
Many of the OSINT and investigative books I read or referenced before starting this book made me feel overwhelmed with information, like trying to understand a technical encyclopedia without actually giving you any guidance or useful advice tied to what you are reading.
I feel this book is different because I deep dive into the tools and try to provide stories behind actual investigations and how those tools were used in a way that actually proved useful (or not).
Another difference is that the examples won’t only show you positive results with every example. I hate when other books do that because the results are typically unrealistic. Real testing often yields no useful information, which is something I will show when comparing different tools.
What You Will and Won’t Find in This Book
This book will cover a lot of tools and technical uses of those tools. It will also cover my thought process and the stories behind how I used certain tools to further an investigation.
This book will contain a number of my personal experiences during actual investigations or breach scenarios. While the names may be changed to protect the companies or people involved (but mostly to protect me), the stories and scenarios presented are completely nonfiction. I have a very “out-of-the-box” approach to life, so I will offer life lessons and hacks along the way that may someday help you.
I also don’t like that most technical books only feature the perspective of a single person (the author).
I will be the first to admit that I don’t know everything about OSINT or digital investigations. Many different facets of technology can come up during an investigation that may require a unique perspective or an understanding that comes from years of hands-on experience, which is why I have always tried to surround myself with people that I respect and that I feel are experts I can learn from.
I thought it would be really interesting to you, the reader, if I also included the opinions and experiences of some of those people alongside my own. Since I am writing a book on a subject, why not also include the opinions of people who are also really good at said subject?
So I asked a handful of people that I consider experts in their field to contribute a story, an opinion, or even a technique on some part of the informationgathering or investigative process.
I found each of their stories to be unique and thought-provoking, and I know you will, too!
Getting to Know Your Fellow Experts
I would like to give a very special thank-you and shout-out to the following people for their contributions as experts in this book (in alphabetical order):
■ Alex Heid VP research, SecurityScoreCard & founder of HackMiami
■ Bob Diachenko
Security Researcher, Founder of SecurityDiscovery.com
■ Cat Murdock
Threat and Attack Simulation, Guidepoint Security
■ Chris Hadnagy
Chief Human Hacker, Social-Engineer, LLC, SEVillage owner
■ Chris Roberts
Chief Security Strategist, Attivo Networks
■ Leslie Carhart Principal Threat Hunter, Dragos, Inc.
■ John Strand Founder, Black Hills Information Security, Senior SANS Instructor
■ Jonathan Cran Founder, Intrigue.io, Head of Research, Kenna Security
■ Nick Furneux
Computer Forensic Investigator, Crypto Investigation Expert
■ Rob Fuller Red Team Heavyweight
■ Troy Hunt
Security Researcher, Microsoft VP, Founder, Have I Been Pwned
■ William Martin Researcher, developer of SMBetray
