Hunting Cyber Criminals: A Hacker's Guide to Online Intelligence Gathering Tools and Techniques

Prologue

One of the more recent investigations I worked on involved the hack of a multi‐billion 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.

CHAPTER 1

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 accomplished 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 information‐gathering 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

A Note on Cryptocurrencies

An extra super shout‐out to Nick Furneux for writing the primer to crypto investigations later in this chapter. For those interested in really diving into how to investigate cryptocurrencies, please check out his book, Investigating Cryptocurrencies: Understanding, Extracting, and Analyzing Blockchain Evidence (published by Wiley).

What You Need to Know

The following themes will be discussed regularly throughout this book and should be considered key takeaways. The takeaways are ordered by a natural flow of information and not by order of importance:

When dealing with a young and aspiring hacker (aka skid aka script kiddie), Vanity will always trump OPSEC. This book will provide many examples proving this statement.

Access to historical information can often make or break an entire investigation. If a young or aspiring cyber criminal is willing to sacrifice OPSEC for their own vanity, then being able to look back in time will most likely lead you to the answer you are looking for. The more historical information you can access, the better the odds of finding whoever or whatever it is you are looking for.

You always get what you pay for. If you want access to the best and most complete sources of historical information, it won't be cheap. If you want cheap (or free), don't expect to have access to everything.

Never rely on one tool for all of your answers. You should always try all tools and techniques at your disposal, even if in the past they have not provided any useful results. Sometimes you get lucky. This book is full of examples where I was completely blown away by the results, which is why you should…

Save everything, and keep meticulous documentation so you can find it later.

WARNING This is the worst part of any investigation, especially when you are on a roll finding new details … so I can't stress this enough. There are a few key items from my own research that I can't believe I did not save. I was sure I took screenshots, but I must have been so consumed with the research (and in the zone) that I forgot to save the items. Now those items are gone and I kick myself every day about it.

So again, save everything.

Paid Tools and Historical Data

Throughout this book, I will do my best to use free and open‐source tools as much as possible, but back to takeaway #3, you always get what you pay for.

Intelligence research and information gathering is no different. You can always go the cheap route and depend on truly free tools, but it may end up costing you in the quality of information that you are able to retrieve and the amount of time you spend looking for the information.

I truly believe that the most crucial part of an investigation will often come down to the level of historical data you can access. It will be rare to find open‐source tools with much of a backlog of historical data.

A few tools in particular contain a wealth of information that I gladly pay for. I will talk about those tools in greater detail later, but for now, just know that not all the techniques I discuss will use completely free tools. It's a trade‐off. You will need to make a decision on whether you want to spend money—but just be aware that not everything can be free.

What about Maltego?

Maltego is a powerhouse tool for digital investigations, perhaps even the industry standard investigative tool. It has been covered extensively in just about every other digital investigations book, and certainly in books dedicated to only covering its many uses and applications, which is why I made the decision to leave Maltego out of this book.

Don't get me wrong, I use Maltego religiously, but the program is so vast that in order to cover it properly, I would have to dedicate most of this book to that one topic. So many other useful and noteworthy tools are available that just don't get the attention they deserve. Now they will.

Prerequisites

Only two prerequisites are required to effectively use the tools and techniques described in this book.

Know How to Use and Configure Linux

The majority of the tools and examples provided will be in Linux. Having at least a basic understanding of how to run the commands will be important.

It will be up to you to set up and install the tools and their respective dependencies. You have many different Linux environments to choose from, each with its own set of benefits. I would rather spend time focusing on techniques and stories to help in your investigation, instead of trying to provide exhaustive tech support.

If you're not sure how to set up your own Linux distribution, I highly recommend downloading Kali Linux. The majority of everything you will need will already be set up for you. You can download Kali at www.kali.org.

Get Your API Keys in Order

Many of the tools in this book will have API connections to multiple sites/services. One of the most frustrating things to deal with during your initial setup is having to set up the API keys in each tool.

Keep a master list. There is not much more I can say about this topic, but I want to call it out because of how much time it will save you in the long run. If you don't have a long list of API keys, that's OK. Start with just one. I use the format Sitename: APIKEY, and I store everything in my 1password vault. It's simple and easy to get to when I need it.

I would probably stay away from posting your keys on any public site like an AWS bucket, a Trello board, or a OneNote file. I never knew Trello boards were publicly searchable until one day there was a story about passwords and other account details being exposed on the service. My point is that I would probably steer clear of posting your keys or passwords on something that you don't have direct control over.

Important Resources

The following resources are extremely useful guides to help advance your knowledge of OSINT and investigations.

OSINT Framework

The OSINT framework is a collection of Open Source Intelligence tools designed to make the process of gathering intelligence and data collection easier.

The OSINT framework provides an exhaustive list of tools (much more than what is covered in this book) in an easy‐to‐use web interface.

The online interface (shown in Figure 1.1) provides categories and classifications for different intelligence sources, making it an important checklist (or road map) to ensure you are investigating all possible sources.

The OSINT framework is an excellent resource for investigators and penetration testers, and you can find it at https://osintframework.com.

OSINT.link

OSINT.link (www.osint.link) provides an exhaustive resource of links, search engines, and web directories designed to help gather information. Figure 1.2 shows the different search engines categories, which is only one of many available parent categories of available links and resources.

Figure 1.1

IntelTechniques

Fellow author and OSINT expert Michael Bazzell hosts www.inteltechniques.com, which until recently, provided very useful social media and investigative search engines. As of April 2019, this site is no longer free and only available to paid members of the site's video training. See what I mean about you get what you pay for?

I have used this site on many occasions, and therefore it's worth suggesting if you are willing to pay for the training.

Figure 1.2

Termbin

I love Termbin (www.termbin.com).

Have you ever been in a situation where you are working in Linux and need to send yourself some text data but can't directly transfer the data out of the machine?

Rsync may not be an option if you are connected through one or more levels of jump servers. Setting up a web server would mean punching a hole through the firewall, which is probably a bad thing, so what do you do if you need to send yourself text from one of these servers?

In this case, Termbin is for you!

Send the contents of the file to termbin.com using netcat, and receive a private link where you can download your text.

For example, let's send a file called surprise.txt to Termbin using the following command:

root@osint> cat surprise.txt | nc termbin.com 9999

You will get back a custom URL that looks like this: https://termbin.com/cpc4.

Hunchly

Hunchly is a last‐minute addition to this book. If I had known about the tool earlier I would have covered it in greater detail in another chapter because it is utterly fantastic.

Hunchly is a tool for online investigations that automatically collects documents and annotates every web page you visit.

There are so many instances where I wish I would have saved a particular screenshot, or even when I know I saved it, but I just can't find it. Hunchly eliminates that by capturing everything in your browser and tagging it to a particular investigation.

If you are an investigative professional, or even just an OSINT enthusiast, you absolutely should download this tool.

Hunchly is available for Windows, Mac, and Linux, and directly integrates with Chrome for a seamless experience. When you are ready to start researching a particular investigation, you can quickly switch on the plugin, select which case you are working on, and Hunchly will do the rest for you.

I wish I could have covered this tool in greater detail because being able to properly save and document your investigation findings is so incredibly important, even from the standpoint of being able to go back and figure out how you reached a particular conclusion.

Hunchly is available at www.hunch.ly.

Wordlists and Generators

The use of wordlists will come up regularly in this book. Plenty of generic wordlists are available, and those will typically get the job done in most situations. When you are bruteforcing or looking for hidden treasure you will typically want to use your own list variations.

SecLists

Your first stop should be the SecLists GitHub page.

SecLists is a GitHub page maintained by Daniel Miessler and is home to an excellent collection of many different types of wordlists including usernames, passwords, name combinations, data patterns, fuzzing payloads, and many more.

Download the wordlists on the SecLists GitHub page at https://github.com/danielmiessler/SecLists.

SecLists provides a great starting point for wordlists. You can use the following tools to create your own custom wordlists, all of which are available in Kali Linux.

Cewl

Cewl is an open‐source custom wordlist generator designed to build wordlists specific to your targets. Cewl builds its lists by spidering target URLs and returning lists of keywords that can be used in various password‐cracking apps like JTR.

If you are looking to build a list of keywords specific to your target, Cewl is the sniper rifle you are looking for.

Think of how many specific keywords you can gain by scraping a person's social media pages. Once you have those keywords, you can generate permutations using the app's standard combinations or your own custom syntax.

You can download Cewl at https://github.com/digininja/CeWL.

Crunch

Crunch is a free tool that generates complex and exhaustive wordlists using custom patterns and permutations.

Crunch would be your shotgun approach to developing a wordlist, and an excellent tool to use when looking for obscurely named public repositories and S3 buckets.

You can download Crunch at https://sourceforge.net/projects/crunch-wordlist.

Proxies

When running OSINT searches (such as NMAP scans or directory bruteforcing), it may make sense to use proxies to avoid detection.

One option would be to purchase 50 or 100 private proxies that you can auto‐rotate through a tool like ProxyChains. Hundreds of proxy sites are available where you can purchase private, high‐quality proxies.

My two favorites are:

Lime Proxies (www.limeproxies.com)

Squid Proxies (www.squidproxies.com)

Storm Proxies (Auto‐Rotating)

My favorite proxy site for OSINT searching, investigations, and web scraping is Storm Proxies (www.stormproxies.com).

Storm Proxies automatically rotates proxies for you without the need to set up ProxyChains or some other rotating proxy service on your server. With Storm Proxies, you send all requests to a specific IP address, which then routes your traffic through one of thousands of its own private proxy servers.

You can choose to use a 3‐ or 15‐minute proxy, which changes your IP every 3 or 15 minutes, respectively, or even send every request through a different proxy server (which is an excellent way to avoid firewall detection).

Storm Proxies is a paid service, but fairly inexpensive considering the amount it would cost to purchase and manage hundreds of private proxies yourself.

Now a word from Nick Furneux: an introduction to investigating crypto currencies.

Cryptocurrencies 101

By Nick Furneux

At the end of 2008 the enigmatic Satoshi Nakamoto wrote a whitepaper about a self‐creating, self‐managing currency based on a new type of database called a blockchain. In early 2009 a proof‐of‐concept blockchain system called Bitcoin was created, which promised to revolutionize currencies with its model of decentralization—essentially, no banking or government control. Bitcoin has gone on to be something of an enigma itself, not really fitting the criteria of a currency while somehow generating an accepted value and tradability. Most commentators now prefer the term cryptoasset rather than a cryptocurrency.

The blockchain concept is essentially a clever way of storing contracts such as coin transactions in a database that protects its data using cryptographic methods and makes it very difficult for an attacker to change entries in the database without significant processing power. The term blockchain has joined other technology terms such as AI and Cloud to be used to sell systems that rarely require the stated technologies to function well, or indeed to improve current methods, but they sound good on marketing material and hence people buy into them. In 2017 a