TheHackerPlayBook I – Section II – The Drive

Table of Contents

General Idea

This is going to be a notes taking article upon reading the book The Hacker Play Book I. I will stop playing HackTheBox or any sort of CTFs and Boxes for a period of time and focusing on reading more hands down materials, for instance, this THP series (there are 3 books now).

I'll be taking notes about anything new and considered of high value to me. And any references that I should take during the reading process, aiding the comprehension. And of course the real mentality that a penteseter/red teamer should have in a real world situation. You know, handling virtual boxes is one thing, and the real world is a whole different story.

By the way, the book is fantastic.

The Mentality Thing

First the author Peter Kim lists lots of tools, but I don't want to log every tool here since I won't be focusing on tools here. And then, he talks about the thing that I care, the difference between a guy who's mainly onto CTFs and Boxes and the one who's a real life pentester, or a red teamer.

Recall the boxes that I have been practicing on in the last few weeks. The pattern, first you get an IP, you nmap it, you look at some open ports. If 139,445, you run smbclient on it. If 80, maybe gobuster, or wpscan.

Now, from the book. Let's switch to the real world, and things are getting really complicated, and, interesting. First, what you get will become a domain instead of an IP address. And the initial step will not be a simple nmap scan, not so straight forward. It involes lots of things, the reconnaissance, usernames, emails, most importantly, subdomains, etc.

The techniques that you need is also very different. Passive recon, first know your target through all kinds of thrid party infrastructures, like shodan, censys.io, hunter.io, etc. You'll get information of the target without even touch the target's sytem. Then, if you think you've got enough info, and decided to enter next phase, which is active recon, there's also a lot more that's involved that just firing up a nmap scan. On a real world scenario, what you should constantly be doing when you are carrying out active reons is that, in my own words:

  • cooperating - which means you should communicate as much as possible with your recruiter, because sometime active recons are so loud, that's going to cause some disturbing effects, for instance the admin might receive endless warning text messages or emails if you're trying to fuzz some url path in their webserver.
  • recording - which means all sorts of scans and enumerations should be kept in output reports.
  • diffing - which means you should be able to detect the changes happened in your customers' infrasture on a timely basis. This will give you the edge to detect newly generated vulnerabilities and, as a red teamer, quickly find a way to break into the system, leave everything else to the target company's blue team and in the final assessment report.
  • Redoing every step..

The Difference Wthin

I've been missing out the difference even between a pentester and a red teamer. Here should I clarify.

Responsibility

A pentester, whose responsiblity scope, in my understanding, is narrower than that of a red teamer. Let's say a pentester is hired to test a compny infrastructure. The most important thing that he has to do is to find out the vulnerabilities hidden in the system, and file a report for the company to patch them, and, no more.

In the other hand, a red teamer, should not be limited to system breaking. A red teamer should try his best to mimic real world attacks, including but not limited to, social engineering, spear phishing, etc. All the ways that you can think of, to help test the target system, and its subsystems.

Engagement Time

Pentesters often go for short term engagements, days, or weeks.

Red teamers often go for long tem engagements, which needs continuously efforts to monitor, test the target.

Section II - The Drive - Exploiting Scanner Findings

About Payloads

You can find all knids of shell codes, exploitation code on the internet. But somethings you must do before you put that code onto your customers' system and spin it up.

Some codes might harm the system and you nerver know because you've never set your foot in the source code.

So from today on, I will go through the most frequently used payloads, look at the source, and try to understand what's behind them.

TODO
Pick some metasploit ruby modules, read the code, and any references I may need.

DEP and ASLR

DEP

Reference: DEP from Microsoft

In short, DEP (Data Execution Prevention) marks certain range of pages of memory non-executable, thus provides the system some level of security, meaning even a hacker can write shell code into a piece of memory, but the memory is protected by DEP, then there's no way to fire that shell code.

And, acoording to the article, in c programming language, memory allocated by malloc and HeapAlloc are non-executable.

And according to this article from stackexchange, DEP is a windows specific term. In Linux, it's called NX (non-executable), feel free to follow the link in the post.

ASLR

Reference: ASLR Wikipedia

ASLR (Address Space Layout Randomization) in short, obsfuscates program memory location, so a hacker cannot find the exact return point to execute his malicious code.

Goole DEP and ASLR, tons of things to read about.

Bypass DEP and ASLR by Vinay Katoch
How does DEP and ASLR Work from stackexchange

Take Aways

In this section, the most important thing to remember is to try to be tool independent. You grab some shellcode from the internet, but you have to know the code, you have to know what's behind it how it works, and fully test it before you run it on the target machine. Dig deeper, and if something went wrong, you will know how to identify the problem and modify the code to still make the exploitation work.

Here is another book recommendation, if you're really willing to dive deeper.

The-Shellcoders-Handbook-Discovering-Exploiting