This write-up walks us through one of my many journeys in my external penetration testing and how I compromised the organization in this write-up.
After executing security assessments (e.g. Penetration Testing, Red Teaming, etc.), I make it a habit to debrief my client’s senior management on the work done and my report.
This creates an opportunity to discuss stuff such as the attack Tactics, Techniques and Procedures (TTPs) used, attack vectors used, findings, recommendations, remediation efforts, etc.
More often than not, I get surprised looks from the leadership teams about some of the ways I got my initial foothold on the network or some of the tactics I used.
For most of them, they expect some Tom Cruise Mission Impossible-style of hacking, bypassing firewalls, etc., only to find out how effortless it was for me to compromise their networks.
So, I usually take the time with my clients to shed some light on how modern-day attacks are usually carried out and how a small loophole as simple as one weak user credential can topple the entire network defense.
The truth is, cyber-attacks are more about efficiency and not necessarily elegance. Thus, adversaries don’t look for the hardest ways to break in. They mostly look for the easiest ways to get in.
We popularly term this approach the path of least resistance and one of these paths is login credentials. All it takes is just one set of user credentials and your entire network could fall to an adversary.
The Mission
Back in 2018, a large healthcare organization contracted us to conduct external penetration testing against its external network infrastructure.
For the scope of the engagement, the organization provided us with their domain name and IP address ranges. Of course, the goal was to identify attack vectors to compromise the organization from the internet.
External Penetration Testing Checklist
Reconnaissance
Among other penetration testing techniques, I need not mention or iterate the importance of reconnaissance in every cyber-attack or network penetration testing alike.
This phase of the cyber kill chain is where you gather intelligence about your target, both passively and actively.
I usually use this opportunity to do lots of passive intelligence gathering using Open Source Intelligence (OSINT) tools and platforms for External Penetration testing plans.
I barely use scanning tools against a target’s network at this phase since I can get almost all the necessary information to craft my attack strategy.
So, what am I usually looking for in this phase? Well, among the plethora of information that can be discovered from OSINT, below are the key items I normally pay attention to:
- Subdomains
- Login portals (Citrix, OWA, VPN, SharePoint, etc.)
- Types of technologies (IIS, etc.)
- Email addresses
- Usernames (lots of ‘em)
External Penetration Testing Tools
Using tools, sites, and platforms such as Google (google.com), Shodan (shodan.io), Censys (censys.io), connect.data.com, Fierce, Recon-ng, SimplyEmail, TheHarvester, SpiderFoot (spiderfoot.net), Email Hunter (hunter.io), VirusTotal (virustotal.com), FOCA, Maltego and Pastebin (pastebin.com),
I was able to harvest lots of information about my client such as subdomains, email addresses, usernames, hosts, network services, open ports, leaked credentials from prior breaches, login portals, etc.
For the sake of this write-up and to keep the confidentiality of my client’s name intact, I’m using a sample domain and Email Hunter to demonstrate one of the many ways I got the username format and email addresses (and later extracted the usernames) of my target client.
In the image below, you can see I got more than 9,000 email addresses and the username format for the target domain.
Target Development
After I had spent a considerable amount of time in the reconnaissance phase and had gathered lots of information, I used this phrase to go through the plethora of data gathered and strategically mapped out my attack surface and the attack technique I would be using.
While going through this data, I was interested in the application and network services that usually authenticate to the organization’s LDAP or AD environment.
This could be SMB, OWA, Autodiscover, VPN, Citrix, Jenkins, SharePoint, custom-made applications, etc.
Once I had discovered such services and which ones to attack, I then organized all the email addresses and usernames I discovered from the reconnaissance phase.
I made sure I had removed duplicate email addresses, and usernames and also cross-checked that the external usernames and internal domain usernames are the same formats, or if there are differences, I got that checked too.
At the end of this phase, I discovered the client’s external OWA and Citrix applications, among others, and also got close to about 1,000 unique usernames.
From here, I was ready to roll into the next phase of my kill chain.
Intrusion
This is where the actual action happens. For most attacks, this phase is where the adversary attempts to gain an initial foothold.
Lots of things are iterative in this phase since the TTPs used in this phase would vary based on the information gathered from the Reconnaissance and Target Development phases.
During External penetration testing, efficiency is key and most of the time, keeping things simple is your best route.
In the early days of penetration tests, finding vulnerabilities and exploiting them was usually the way to go.
However, as adversaries evolved in their TTPs, we had to evolve as well.
With that said one of the basic, yet effective, attack techniques is an authentication-based attack, also known as password brute-forcing.
In the typical password brute-force attack, you have one username and you try several possible passwords against that username, hoping that the user is using one of the passwords in your list.
Well, administrators became wiser and started implementing account lockout policies, thus, after login attempts meet a certain threshold (say after five attempts), the account locks out.
To counter this control, a new breed of authentication-based attack emerged called Password Spray (some call it horizontal, reverse brute-forcing, etc.).
With this attack, an adversary gathers several usernames or email addresses (depending on the type of application or network service being attacked) and then tries one password against all the usernames or email addresses to identify which one of the users may be using such a password.
This Hacking technique has had and continues to have, a high success rate in real-world attacks and on most of my penetration testing engagements.
There are several tools to carry out this attack, however, for application-based password spray attacks, my favorite go-to tool is Burp Suite.
Burp Suite gives me enough room for customizing my password spraying such as threading, throttling, grepping for strings, etc. When choosing passwords for this attack, I usually try Season + Year (e.g. Summer2018, Winter19, etc.), CompanyName + Numbers (e.g. Company123, Company2003, etc.), ideas from prior company breaches, locations, sports teams, etc. Honestly, there are no right or wrong ways in picking passwords for the password spray attack.
After setting up and configuring everything within the web penetration Testing tool Burp Suite against the client’s Citrix web application, I kick-started the attack, slowly and steadily.
My first round of spray gave me two valid user credentials with the password Winter2017.
In the image below, request numbers 208 and 853 are the valid credentials, with three levels of redirects.
Off to a good start!
Using the two user accounts discovered, I was then able to authenticate to the client’s Citrix applications as those users.
However, to my dismay, none of the users had any applications in their Citrix application catalog. What a bummer.
Since I already had two valid credentials, I used the MailSniper tool from Black Hills and dumped the client’s OWA Global Address List (GAL).
This gave me additional usernames for my next round of password spray attacks.
This time, I tried the spray attack against the client’s OWA, using the password Companyname123 (I used the actual client’s name and appended the number 123 to it).
This yielded two additional valid credentials. In the image below, request numbers 395 and 431 are the valid credentials.
This time, one of the users had an internal SAP application in their Citrix application catalog and this SAP application opens with Internet Explorer.
Lateral Movement in External Penetration Testing
At the lateral movement phase, the adversary or the penetration tester has gotten some level of access to the target, either from the application level or the network level, with either limited or full access.
The goal from this point going forward is to find ways to move within the target’s network while evading internal network security controls.
We (adversaries/pentesters) use the access gained to gather additional information to move within the target’s internal network.
Basically, we are back to reconnaissance and this can be host-based intelligence gathering and/or network-based intelligence gathering. Again, the techniques used in this phase can vary based on many factors.
Citrix Breakout
At this point, I had obtained application-level access and my next goal was to gain network-level access.
Since I had experience in breaking out of Citrix environments, I saw this as my opportunity to break into the network level.
If you are interested in reading more about Citrix breakouts, the guys at NetSPIhave a great blog on that (see On The Web section for the link to the blog).
To execute the Citrix breakout attack, I opened the victim’s SAP account with Internet Explorer and tried to save the web page’s source.
Then using the “Save As” option from the File menu, I navigated to C:\Windows\System32\ directory and called out the Windows CMD utility (cmd.exe).
This pop opened CMD and gave me access to the backend Citrix server.
With access to the backend Citrix server, I whipped up a PowerShell Empire listener, generated a PowerShell launcher, executed it on the Citrix server, and got a call back to my Empire listener from the Citrix server.
Kerberoasting
‘Nough has been said and written about Kerberoasting so I won’t dwell on its explanation here, but rather go straight to what happened next.
Most of the time, a Citrix server is considered a high-value system and as such, only a limited number of users have administrative privileges on the server.
With that said the user account with which I had gained access to the Citrix server was an unprivileged user.
However, any domain user account can be used to request Service Principal Names (SPN), a Windows feature used by Kerberos authentication to associate a service instance with a service logon account; for example, an SPN for a service account that runs IIS.
Querying the AD for service accounts can be done locally with Windows’ built-in utility setspn.exe or remotely with tools such as Empire, Impackets, Metasploit, etc.
Using my Empire session, I dumped the SPNs and went about cracking the password hashes with Hashcat. Below is an example command used for cracking the password:
hashcat -m 13100 -a 0 spn.outputpassword.list -r best64.rule -o kerb.cracked
While reviewing the SPN query output, I noticed some of the accounts belonged to the Administrators group and Hashcat happened to have cracked password hashes for one such account (IIS_Admin).
Credential Abuse/Re-use
From my initial information gathering in this External Penetration Testing, I obtained specific critical intel about the internal network such as the list of Domain Admins, Enterprise Admins, Domain Controllers, etc.
So, to effectively use the newly obtained credentials to compromise the domain, I needed to identify which systems the Domain Admins and/or Enterprise Admins had logged sessions or had previously logged in.
Tools such as netview.py and Invoke-EventHunter can be used to accomplish that objective.
After I had identified a few systems where Domain and Enterprise Admins had sessions, I kicked off CrackMapExec against those systems, using the IIS_Admin account and the cracked password.
I identified a few systems where the IIS_Admin account had administrative privileges and, using the Mimikatz module in CrackMapExec, extracted credentials from those boxes.
King’s Landing Falls!!!
Among the credentials extracted was one that belonged to a Domain Admin! The last thing I needed to do was to confirm the validity of the new Domain Admin credentials against a Domain Controller and also dump the NTDS database for offline password cracking and analysis.
Data Hunting and Exfiltration
One of the primary goals of an adversary is to access and/or extract sensitive/critical data, which we loosely call the “crown jewels” of the target. This could be:
- User credentials
- Secret formulae
- Blueprints
- Customer data
- Personally Identifiable Information (PII)
- Medical Records
- Financial data
- Intellectual Property
The exfiltration phase is where data is moved from the target’s network environment to the attacker-controlled systems (e.g. C2 server). This is usually part of the data-hunting activities.
Gone are the days when penetration testing used to be all about gaining a Domain Administrator (DA) level access and calling it a day.
Now, External penetration testing needs to demonstrate the business risk and impact your client could have suffered if your tests and attacks were executed by a real-world adversary.
With that said, this is one of the critical phases in our tests.
As a penetration tester, it might be necessary to confirm with your client if data exfiltration is required by the Rules of Engagement (RoE) before you move data out of their environment.
If allowed, I carefully analyze what type of data to exfiltrate to demonstrate the business risk and impact on the client.
Different exfiltration techniques can be used for different situations depending on the environment and the systems compromised.
Last Words – External Penetration Testing
As you may have noticed throughout this write-up, I did not run a single vulnerability scan on this test.
Why am I bringing this up? Well, there have been several instances where I have seen some penetration testing reports or work that claimed to be External penetration testing but in actuality, they were vulnerability assessments.
The debate about the differences between penetration tests and vulnerability assessments has been going on for quite some time so I will leave it alone.
However, I always tell people that, in our line of work, we learn every day from each other and from engagements and there are several ways to skin a cat.
I just wanted to share one of the many ways I execute external penetration testing. I am not an expert so please, do not hold me up to a standard if my write-up disappoints you!
Until then, thanks for reading.
Research On the Web
Citrix Break:https://blog.netspi.com/breaking-out-of-applications-deployed-via-terminal-services-citrix-and-kiosks/
SPN:(https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx).
Credits
Neal Bridges for coining the phrase “Target Development.”
Jimmy Tharel for reviewing this for me.
Recommended to Read
Penetration Testing Tools
A Complete Penetration Testing & Hacking Tools List for Hackers & Security Professionals
Most Important Security Tools and Resources For Security Researchers and Malware Analysts
Most Important Android Penetration Testing Tools for Pentesters & Security Professionals
Most Important Cyber Incident Response Tools List for Ethical Hackers and Penetration Testers
Most Important Cyber Threat Intelligence Tools List For Hackers and Security Professionals
Penetration Testing Checklist
An Ultimate Checklist for Application Security Testing
Most Important Web Server Penetration Testing Checklist
Most Important Network Penetration Testing Checklist
Wireless Penetration Testing Checklist – A Detailed Cheat Sheet
Cloud Computing Penetration Testing Checklist & Important Considerations
Web Application Penetration Testing Checklist – A Detailed Cheat Sheet
Checklist for Security Leakage Before Initiating Data Migration in Your Organization
