Welcome back to the deep Dive. Today. We're kracking open a really fascinating stack of sources. It's excerpts from a book called The Art of Network Penetration Testing. And this isn't a theory, right, it's like a practical guide on how the pros simulate cyber attacks on company networks.
That's exactly it. Our deep dive today is basically pulling back the curtain on how ethical hackers operate. We're trying to understand, you know, what does a network penetration test? Why do companies even need them? And maybe the most interesting part the actual steps, the phases and techniques they use. It's all straight from this how to guide.
So it's like we're getting the attackers playbook, but you know, used for.
Defense precisely the core idea and the source really emphasizes this is simulating how a real adversary thinks and acts, trying to find those security weaknesses before the bad guys do.
The book uses that analogy, doesn't it hiring a professional adversary?
It does, and it's kind of surprising how much the whole process can feel like like planning movie heist.
Huh okay, I like that you.
Know, mapping the place out, finding entry points, moving around, just replace laser grids with firewalls. Maybe we'll walk through all that, the planning, getting in, moving deeper, and then the reporting. Lots of interesting stuff here.
Okay, let's definitely unpack this. So first things first, what exactly is a penetration test a pentist?
Well, think of it as an authorized simulated attack. The goal isn't just scanning passively, it's actively trying to exploit weaknesses, you know, just like a real attacker.
Would, so actively trying to break in, essentially exactly.
And the book points out sometimes these tests are done almost secretly, like the client's security team might not even know what's happening until they get the final report.
Wow, okay, trying to sneak past the guards, that's the idea.
You're adopting that malicious mindset. But here's a really important point the book makes early on. A pentist isn't very useful if the company's basic security, their hygiene is just bad house. So well, if you've got what they call low hanging fruit everywhere, default passwords not changed, people sharing logins, everyone having admin rights, critical patches missing, ye appentis is just going to find all those really obvious things first.
So like, if you haven't even locked the front door, don't pay someone fancy to tell you the front door's unlocked.
That's a perfect way to put it. Fix the absolute basics first. Default passwords, for instance, The source says they're shockingly common and attackers actively look for them because they're such easy wins.
It makes total sense. Fix the big holes before you check for tiny cracks now. The book also mentions for anyone wanting to learn this stuff, setting up a lab.
Oh definitely, learning by doing is crucial. The source suggests using something like the Capsule Core Pentest project. It gives you a pre built credit environment to practice on. Okay, and for your own machine, the attacker machine, they strongly recommend starting with Linux Opuntu for example. So many of the standard pen testing tools are built for Linux. They just run better there.
Right, Getting the tools and the environment set up kind of step zero.
Absolutely, you need that stable tool rich setup Linux is really fundamental for this kind of work.
Okay, So let's get into the actual process. The book lays out a pretty standard four phase approach for specifically internal network penetration tests or ionpts.
That's right, And interestingly, they mentioned a typical IMPT can often wrap up within a normal forty hour work week.
Really okay, Yeah.
These four phases are basically the attackers playbook once they're inside the network perimeter. Yeah, even if that initial inside access is just simulated for the test itself.
Gotcha. So phase one, if we're sticking with the heist analogy, this sounds like the planning, the recon phase casing the joint exactly.
That Phase one is all about information gathering. The main goal is to map out the target's attack surface. You need to figure out, Okay, what systems are actually alive on this network, what services are they running, where the potential entry point?
How you even start finding systems? Networks can be huge.
That's the host discovery part. You're looking for live machines within whatever IP range you've been given, or you're trying to discover the source. Talks about different scopes. Here, white box where the client gives you a list of targets, sure, black box where you basically start blind, and gray box, which is somewhere in between. Maybe you get some IP ranges. But here's a really interesting point from the book. Even in a white box test where the client gives you
a list. Experienced PEN testers often still scan the whole range anyway. Why is that because clients frequently miss systems on their own network inventories.
No kidding, so their own map might be wrong. That's a big deal, it really is.
It shows why this kind of independent testing is so valuable for techniques. You've got simple stuff like ping, but mostly you're using powerful tools like ENMP. The book mentions specific n MAP options like at PN to assume hosts or up or things like min rate to speed up the scanning significantly to cover faster exactly. They also mentioned maybe sniffing network traffic with wireshark, looking for hosts talking, or even hunting for hidden subnets if the scope allows.
Okay, so you found the live machines. What's next in this info gathering phase.
Necktub is service discovery. So now you know who's home, you need to figure out what doors are open on those houses and what's behind.
Them doors being ports right.
Finding which services are running on which ports across that whole range zero to six, five, five, three five, and figuring out what the service is. Is it a web server, a database, something.
Else, like checking the signs on the shops and you're building analogy earlier.
Exactly, and many services advertise themselves with service banners. It's like that sign telling you the software name and maybe even the version number. Tools like Curl can grab this from web servers, for example, and getting that version info. That's gold for an attacker looking for known exploits.
And end map is key here too for finding the open ports.
Oh. Absolutely, enmap is your main cool for port scanning. You're looking for common ones twenty two for Ssh, eighty and four forty three for web three three eighty nine for Windows Remote desktop. The source gets practical tips on how to parse end map's output, maybe using command line tools like rep or cut to filter results my filter. So you can create specific target lists for the next step, like okay, here's a list of just the web servers
or just the systems. Running Microsoft Seql helps you focus your efforts.
Which leads to vulnerability discovery. Now you know what services are running. Time to check if the locks on those doors.
Are weak precisely, Now you analyze those identified services for known weaknesses. Is there an authentication problem, a configuration mistake? Is it missing critical security patches?
Oh?
Okay, And this is where pintesting really differs from just running say an SS or Qualis scan. Those tools often flag potential issues based on version numbers, known cvs.
Right, theoretical problems.
Yeah, ap Pennus focuses on finding things that are actually exploitable in that specific environment. Can I really use this weakness to get in?
Like finding a specific old software version with a known working exploit.
Exactly That and missing patches are a huge one. The book uses MS seventeen zero ten the eternal Blue vulnerability as a prime example. It's famous from twenty seventeen, but the source says finding system still missing this patch is often an easy quick win for attackers.
Still wow, yep.
You can even use tools within frameworks like metasploit to specifically check for it. Finding Eternal Blue unpatched that's a major red flag.
One of the things like weak passwords authentication issues.
Oh, absolutely critical. The source talks a lot about guessing or brute forcing passwords, trying default credentials, building clients. Specific word lists may be based on the company name They mentioned using metasploit modules again to hammer login prompts for databases like MSCL or myceycle or even VNC remote access services, which sometimes don't lock accounts after too many bad guesses. Yikes.
And here's another surprising bit. The book notes that successful password guessing often leads logs, but companies frequently do monitor those logs closely enough, or they ignore the alerts.
So the alarm is ringing but nobody's listening.
Per pick analogy. Then you've got configuration vulnerabilities. Services just set up insecurely, maybe using default settings. The book suggests a cool tool called web shot.
What does that do?
It takes screenshots of lots of web servers really quickly, helps you visually scan and spot potentially interesting things, maybe an old admin interface or specific platforms like Apache, Tomcat or Jenkins which are known to have remote code execution possibilities if you can guess their admin passwords.
So Phase one is really about building this incredibly detailed map of the network's weak spots, understanding the landscape exactly.
It's deep reconnaissance lets you make an informed decision about the path of least resistance, which vulnerability looks most promising to get you that initial access, rather than just you know, randomly trying stuff.
Okay, map complete weak points identified. Phase two focus penetration. Now the heist crew actually makes their move right getting inside the building.
That's the goal, precisely gain that initial foothold. You're actively exploiting one or more of those vulnerabilities found in phase one to get remote control, usually called getting a shell.
How does that work attacking a web server for.
Example, Well, say you found weak admin credentials on that Tomcat or Jenkin server. You might be able to achieve remote code execution RCE, basically tricking the server into running your commands. Okay, for Tomcap, maybe you upload a malicious web application file a war file through the admin panel. That file then runs and gives you a command prompt on the.
Server, a shell.
A shell. Yeah. Now, the source distinguishes between interactive shells like a normal command prompt and non interactive ones, which can be more limited. They even list some safe commands you can usually run in those limited shells, like ipconfig to check network settings, task lists to see processes, or during kat to look at files.
So you might not get full easy control right away.
It depends on the exploit and the shell you get back. Sometimes even limited access is enough. Here's a really clever Windows trick. The book details the sticky keys back door.
Sticky keys like the accessibility feature.
Exactly, you replace the program that runs when you hit shift five times sets dot ex with the command prompt cmd dot ex. If you have remote desktop access RDB and the right permissions to swap the files. Uh huh, you can hit shift five times at the Windows login screen and instead of sticky keys options, you get a system level command prompt.
Whoo, that's disius, there really is.
The book mentions you might need tools like cackles dot ex first to mess with file permissions to allow the replacement.
Okay, what about attacking databases like that ms sql example, if.
You found credentials in phase one, maybe that's SAFF password one combo. The source uses as an example. You connect to the database now if a specific stored procedure called xpcmd shell is enabled, which shouldn't be usually. Why not because it lets you run operating system commands directly from the database. So you could type CQ commands that execute
WAMI or if config on the underlying server. You definitely check what account the d B service itself is running, asked to see how much power you just got?
Gotcha? And if you found that eternal blue vulnerability MS seventeen M zero ten zero, that's.
Often a much more direct route. You'd use a pre built exploit module like MS one CO ten p XC and metasploit pointed at the vulnerable machine, run it and often boom you get a show.
And you mentioned some shells are better than others.
Materpreter, Yeah, Interpreter is metasploits enhanced shell. It has a lot more built in capabilities, specifically for the next phases of the attack post exploitation. Simple commands like EPs in Interpreter let you see running processes and crucially who's logged in the source gives an example of spotting a domain user capsule Cartian logged in via RDP this.
Way, so you can see other users on the system exactly.
Interpreter also lets you easily run more advanced modules, and you can even generate custom versions of the Materpreter payload using tools like m venom to try and evade antivirus.
So summing up phase two, it's all about getting that first access that beachhead and maybe compromising multiple systems quickly if possible.
That's the core idea. Get inside established presence. The more systems you initially compromise, the better your chances of finding useful information like credentials or finding a path that leads deeper into the network. For Phase three, okay.
We're in. We have shells on one or more machines. Phase three post exploitation and privileged escalation. Back to the heist. The crews inside now they're moving around looking for the vault, getting keys to restricted areas.
Perfect analogy. That's exactly what this phase is about. The key goals here, according to the source, are maintain reliable re entry, harvest credentials, maybe install more permanent back doors, and move laterally jump from system.
To system maintaining re entry. That sounds important. You don't want your shell to just die if the user logs off or rebooths.
Precisely, you need persistence. For Windows. The book talks about using a meterpretcript called persistence. It can set up a simple backdoor, maybe a VBScript that runs automatically on startup and connects back to your attack machine. Very and the Sorts mays a critical ethical point here. You must keep detailed notes of everything you installed or change so you can clean it up perfectly. Later for Linux or Uni
X systems. They talk about using kron job scheduled tasks, maybe to automatically set up reverse SSH tunnels, using pre shared keys for passwordless access back.
In okay, persistence covered. What about credential harvesting finding usernames and passwords?
This is huge. It's like finding spare keys lying around the building. On Windows, the go to tool is mimicats, often run through metasploids KB extension. It's famous for being able to dump clear text passwords directly from the computer's memory if they're stored there. Commands like tspkg or w digest do this.
Clear text passwords and memory often Yes.
You can also try to grab cash domain credentials hashes of passwords for users who've logged into that box before, using formats like mscash two. On Linux unn the X, you might check the user's commandhistoryfile dot bash history. People sometimes type passwords on a command.
Line Oh wow, seriously it happens.
Or you grab the password hashes from the ETCA shadow file, which stores them in a hashed format.
So you're grabbing credentials from memory history.
What else searching the filesystem itself, looking for configuration files where developers might have hard coded passwords. The source list's common examples web dot ca fig for asp, dot net apps, tomcatusers dot xml for tomcat, can figure out ink dot php. For some PHP apps, you'd use system search commands like find star on Windows or grap on Linux to hunt for keywords like password or PWD within files.
Okay, so now you've potentially got a collection of usernames, maybe some clear text passwords, and a bunch of password hashes. What do you do with the hashes?
You try to crack them using tools like John the Ripper. The book explains the difference between brute force cracking trying every single combination, which is super slow for strong passwords, and dictionary attacks.
Using lists of common passwords.
Exactly like the famous Rocky dot txt list. Dictionary attacks are surprisingly effective against weaker common passwords. The source mentions cracking the hash for that user t in and finding the password was password eighty two to two, pretty common format.
Okay, so cracked passwords or harvested clear text ones, Now you can move laterly.
Yes, that's lateral movement. You take those credentials or even just to hashes and use them to log in to other computers on the network that you couldn't access before. For Windows, the source highlights a really powerful technique called pass the hash pa'ss the hash Yeah. Tools like crack map, exec CME or Metasploit's smug in module let you authenticate to other Windows machines using just the user's password hash. You don't even need to crack it to the plain text password first.
That's incredible. You just need the hash fingerprint, not the actual key.
Essentially, yes, it works because of how Windows authentication protocols can operate, so as you're moving laterally, you're also constantly looking for privileged escalation.
Opportunities getting more power on the machines you land on.
Right going from a regular user to administrator on Windows or to the root user on Linux. On Linux unax, the source mentions looking for misconfigured SUID binaries. These are special programs that run with the permissions of the file's owner, not the user running it. The password command is a classic example. It needs root privileges to change the password
file even when run by a normal user. If you find a custom program mistakenly set with SUID and owned by rout, you might be able to exploit it to become route. The book even gives an example of potentially backdooring the ETSETA password file itself this way to add a new root level user.
Okay, so you're moving sideways, grabbing more power. What's the ultimate goal?
Usually in most corporate environments using Windows Active directory, the ultimate prize is domain administrator privileges. That's basically the keys to the entire kingdom full control.
How do you get there?
Well, first you need to identify who the domain admins are, like net group domain admins. Domain can list them. Then you need to figure out where they might be logged in currently, maybe using commands like hinsta on servers you already have access to.
Okay, find the admins, fine, where they are? Then what?
Then? You try to compromise that session or machine. Maybe you can impersonate their logged in session using tools like Metasplois incognito. Or maybe you get lucky and use mimicats on the machine where a domain admin is logged in and steal their password or hash right out of memory.
So target the admins directly? Is there another way?
Yes? The real holy grail, as the source calls it, is getting your hands on the NTDs dotd it file from a domain controller.
The domain controller that's the main server for the Windows domain.
Exactly, and that NTBs dotd it file it contains the password hashes for every single user and computer in the entire domain. It could be thousands.
Wow, but isn't that file locked super tight by the OS.
It is while the domain controller is running. You can't just copy it. So the book describes the standard TECHNIQE using volume shadow copies VSC.
Shadow copies like the system backups.
Kind of yeah. You can use a built in Windows command VS and flyming and create shadow to create a point in time snapshot of the domain controller's hard drive. This snapshot acts like a separate mounted volume, like plugging in.
A USB drive that has a copy of the system files from a moment ago.
Exactly like that. And crucially, the files on this shadow copy aren't locked by the live operating system, so you can just copy the NTDs dot dt file from the shadow copy. You also need one other file from the shadow copy, the System registry hive.
Why that one?
You need the system hive because it contains the key required to decrypt the hashes stored in NTDs dot d. Once you have both files NTDs dot D and system. You take them offline to your attack machine. Then you use tools like secret stump dot PUI from a toolkit called impack it. You feed it those two files and it extracts all the domain passwerd hashes.
All of them thousands, potentially game over basically pretty much.
With all those hashes, you can use past the hash to access almost anything or start cracking the important ones. So yeah, Phase three is really about leveraging that initial access, moving strategically, escalating privileges, and aiming for that total control to show maximum potential impact.
Okay, incredible, We've planned the heist, reached the building, moved through it, grab the crown jewels. Phase four documentation. This isn't the part where the heist crew vanishes, is it.
No? Quite the opposite. This phase is absolutely critical. The goal here is to deliver real value back to the client, and you need to clearly report exactly how you got in, what you found, what the risks are, and most importantly, how they can fix it. The book really stresses this. You need meticulous notes during the test. You can't write a good report weeks later from memory.
Makes sense. What goes into this report. What are the key sections?
The source lays out the standard components. First, the executive summary, high level, non technical for managers, for leadership. It answers the basic questions, who did the test, what was the scope, what were the major find When did it happen? And why does it matter? The how comes later?
Got it? Big picture first exactly?
Then the engagement methodology. This explains your approach. Was it whitebox, gray box, black box? It outlines the four phases you followed. After that comes the attack narrative, the story of the heist exactly. It's the step by step story of your specific compromise. How did you get that first shell? What credentials did you find? How did you move from machine AID to machine B? How did you eventually get domain admin? If you did it.
Reads like a narrative, okay, that makes it understandable.
Then you have the core technical details. The technical observations are findings. Each finding needs structure. The source suggests severity like high, medium, low. High usually means direct compromise or a clear path to it, a clear title. The observation itself.
The example found default Tomcat admin password, The impact what an attacker could do gain make code execution on the server, evidence, screenshots, command output to prove it assets affected, which specific servers ips and finally a recommendation and what's.
The philosophy behind what counts as a finding?
This is important. The book emphasizes finding should be based on demonstrable compromise or a clear attack path you successfully executed or validated. It's not usually about just listing minor best practice deviations like maybe an old SSL cipher being enabled, unless you could actually leverage that weakness somehow during your attack.
So focus on what an attacker could really do, not just theoretical stuff exactly.
It's about proven risk and the recommendations need to be actionable. Update this software and force stronger password complexity, disable xpcmd shell. One key ethical point the source makes is not to recommend specific vendor products unless that was part of the agreement. You identify the type of control needed, not push a particular brand.
And supporting infogos and appendices.
Yeah, things like how you define severity levels, the full list of live hosts and open ports you found, maybe a list of the tools used, references all the supporting data.
Okay, that's comprehensive. And one last really crucial step. The book mentions cleanup absolutely critical.
Responsible pen testing means leaving the client's environment exactly as you found it or arguably slightly more secure. By removing any tools or changes you made, you cannot leave them more vulnerable.
What does cleanup involve?
It means killing all your active sessions and shells, Removing any files you uploaded, any backdoors you installed, like that persistent script or the sticky keys hack, Reversing any configuration changes you made, like if you had to enable xpcmd shell to prove a point you disabled it again, delete any temporary shares you created. It's about meticulous housekeeping.
Got it, leave no trace except for the report exactly. So wow, we've really walked through that entire simulated attack life cycle based on this guide, from the initial planning and discovery, finding those weak spots, getting that foothold, moving laterally and escalating privileges, potentially gaining full control, and then crucially documenting it all so the organization can actually improve.
It's a really powerful process when done right. And that core takeaway which the source hits on again and again, is that understanding how an attacker thinks and operates, which is what a good pentis simulates is probably the best way to figure out how to build effective defenses. And that low hanging fruit we talked about at the start,
default passwords, missing patches, it's not just theory. The book makes it clear that's often the actual way attackers get their first foothold basic security hygiene, getting the fundamentals right. It really does go an incredibly long way.
It is pretty striking, isn't it. How finding just one mistake, one oversight, that default password, that unpatched vulnerability like eternal Blue can potentially unravel the security of an entire network Using the kinds of techniques laid out here. It really underscores that old saying defenders have to be right every time, attackers only need to be right once.
It's a sobering reality for anyone in defense. Yeah, but understanding the attack paths makes defense much smarter.
Absolutely so for you listening to this, thinking about this whole process, the reconnaissance, the exploitation, the lateral movement, the sheer power of finding just one open door. What single security practice maybe in your own work or even personal setup, feels like it might be that potential weak point, that one thing that maybe deserves a closer look after hearing all this something to definitely think about after this deep dive into the art and science of network penetration testing.