aidenpearce369
Published on

How I hacked an Enterprise

My First Red Team Engagement 🚩

Hello World! I haven't posted a blog on my website in a long time.Since the middle of 2022, I've been devoting my time and energy to learning Red Teaming techniques and am still exploring the vast ocean.During my training, I practised with vulnerable environments (Hack the Box machines and other vulnerable VMs set up locally). From all my experience, I would say this field is drastically emerging, with lots of new attack vectors and mitigations on a day-to-day basis. This field doesn't stop, and it will be racing towards a competitive pace for Red Teamers 🚩 and Blue Teamers 🏳️.

With my best efforts, I started to understand how enterprise networks work and how their typical architecture is set up.Recently, I came across my first red team engagement. The client for this engagement was a large FinTech company with a vast network. The approach for the engagement is to perform an adversary simulation with Assume Breach Scenario. This blog purely describes the engagement methodology I follow on my own, and it may vary with the perspective of other Red Teamers.

The target company had many domains on the internet, hosting various applications for their employees and customers. Every piece of website information is important to a Red Teamer. Web Application Pentesting plays a crucial role while performing a Red Team Engagement. After gathering information through the public internet, we got to know about the various other domains being used by the company. Some important enumeration tactics that are required to be done before starting to probe the enterprise's internal network directly are,

  • Subdomain Enumeration
  • GitHub Dorking
  • Shodan Dorking
  • Google Dorking
  • External Application Pentesting
  • Familiarising with Enterprise Architecture

We can list various applications (both external and internal) used by the enterprise by performing extensive subdomain enumeration. The scale of the target scope just expands randomly based on the organisation while performing subdomain enumeration.

cat targetDomains.txt | while read -r domain; do
( echo $domain | subfinder -silent >>subdomains.txt );
done

For subdomain enumeration, I personally use subfinder, which is integrated with many API keys. It's always good to probe and check the subdomains, whether they are accessible from the public internet or not. httpx does the work for me.

cat subdomains.txt | httpx -silent -sc

Here I found many subdomains named for internal web applications that are not accessible from the public internet. But most of them are accessible. So, it's time to pentest these applications.

It was tedious work pentesting these applications, most of them were static ones for business marketing purposes. The more dynamic the feature, the more interesting it becomes for us. Our team had found many Web application vulnerabilities in the vast target scope. Personally, I love to test for SQL Injection, XML External Entity and Open Redirection for red team engagements. You may think, "Why specifically these bugs?"

Well, there is a pretty good reason to hunt for these bugs because SQL Injection & XML External Entity are injection based attacks that help an attacker retrieve sensitive information from the backend / server, which is real-time data being used by the enterprise. This can be further used for lateral movement in the succeeding phase. And in today's InfoSec world, Open Redirection may be treated as an ordinary bug, where bug bounty hunters and platforms have normalised it. But Red Teamers know the value of it, because it can be used to lure a victim from the enterprise. Victims are easily duped by this illusion because the redirection to our malicious URL occurs from their enterprise domain name.Mostly non-technical employees in an enterprise fall for this technique. There are many known vulnerabilities in the wild, but these are my favourites to look for, which can be easily used to further our engagement.

While looking for web vulnerabilities, our team members found many SQL injections from the target scope. I started to aggregate the domains and manually fuzzed the vulnerability to find what database that server was using.

When it comes to SQL Injection, I always use Portswigger's SQL Injection Cheat Sheet for reference.

While pentesting those sites, I discovered one thing in common that was shared by all of them. Some specific groups of sites were using the same tech stack for their web applications. They were using .NET for the front end, IIS Server for hosting, and MSSQL (fuzzed manually) for the back end.

# Typical Enterprise Web Application Stack

Front End (.NET) <---> Server (IIS) <---> Back End (MSSQL)

Apart from these, they have been using Wordpress applications and apps with PHP + MySQL which has similar behaviour to Wordpress but it's not Wordpress.

I used sqlmap to dump the entire DB from the MySQL database, and the other sites (including MSSQL, where they had a common DB synced with many web applications) had Blind SQLi which took more time to bruteforce and dump the data. Dumping the database names and table names alone gave me a good understanding of their internal domains and internal web applications.

#Fuzz for SQL Injection
sqlmap -r request.txt 
#Specifying Database
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 
#Fuzzing Vulnerable Param 
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 -p <PARAM_NAME_VULNERABLE_TO_SQLi> 
#Dump database names
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 --dbs 
#Dump table names
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 --tables 
#Dump all data from the given database & table
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 -D <DB_NAME> -T <TABLE_NAME> --dump

Dumping the SQL DBs was a gold mine because it had many email IDs and their passwords (stored in plain text, a bad security practice) stored in it.

Apart from web app pentesting, I got so many exposed internal domains with their IPs due to their SSL certificate from Shodan Dorking. From Shodan, I even got an open RDP port 3389 into their organization.

Last but not least, I got a pair of credentials from GitHub Dorking, where their internal developers wrote some scripts to test some API functionality and left them without scraping it from their git commit. I also got a bunch of internal email IDs for their enterprise.

After using some grep commands and bash automation, I wrote those credentials from the SQLi dump and dorking into a single file, which had nearly 340 credentials in it. That's a huge number, and that shows the enterprise is not following good security compliance and mitigations. So what's next?

Before actively using these credentials, I just wanted to try to explore other subdomains to look for other possibilities. During that phase, I came across a MS Exchange Server of their domain. Their OWA Portal (Outlook Web App Portal) login page was there, and seeing it I got very intrigued. Since I have been reading feeds from many security researchers whom I follow on Twitter, I know at the instant ProxyShell Exploit can be done on that server. There's a good talk by Orange Tsai about this vulnerability, and his blog was a reference to me. Immediately I fuzzed the OWA app with Burpsuite and found the Exchange Server version in the response header. I ran publicly available exploits for this attack, specifically this one and one of my friends who had reproduced this exploit helped me with his perspective on attacking it. Even though it got me a shell, I could not successfully run commands. I knew something was wrong and started reproducing the exploit manually using Burp and my own Python scripts. From doing that I understood, the email IDs in the Exchange Server was a rabbit hole to me. The FQDN and email IDs were specifically placed inside the server to lure a Red Teamer (my first time encountering Blue Team tactics). I had spent nearly 4 days on beleiving this exploit alone, atlast the belief became broken.

And bringing myself up from failed attempt for a fake low hanging fruit. I started exploring other subdomains too. Some of the sites redirected me to an SSO login page.

https://login.microsoftonline.com/getuserrealm.srf?json=1&login=fakeID@domain.com

Querying from the above link, I confirmed that the domains run as a Federated Service for AD. That means they've connected to Microsoft Cloud (O365).

Now, it's time to use the credentials that I prepared earlier. I started spraying those credentials using O365 Sprayer over the target domain. Only one of those credentials was working. This was the turning point for this whole red team engagement. The password used for the valid credential is a simple combination used by the domain.

It's time to go cloudy. Using that credential, I logged myself in as the user in their domain via Azure AD PowerShell module. In order to connect with Azure Cloud, we need Tenant ID of the domain.

https://login.microsoftonline.com/<TARGET_DOMAIN>/v2.0/.well-known/openid-configuration

By querying the above link, we get the Tenant ID of the target domain in response. Using that tenant ID to connect with Azure AD.

Connect-AzureAD -TenantId <TENANT_ID>

After getting connected with Azure AD in our PowerShell, enumeration becomes much easier with Azure AD PS Module. Enumerating Azure AD Users,Groups & Devices via Get-AzureADUser -All $true ,Get-AzureADGroup -All $true, Get-AzureADDevice -All $true and many more. Using Get-AzureADDomain we can check the authentication type for the domains connected to it.

I can now easily obtain all email IDs used in the domain from the enumerated users. I thought of performing Password Spray attack with default combinations for the domain considering the Account Lockout Policy and its cool down period. After performing password spray, nearly 60 accounts have been compromised by their weak, predictable passwords.

Using these credentials, I got into a machine with a default AD user privilege account. The machine was running in a constraint with several EDRs (not the top rated) and AV products for a newbie Red Teamer like me 😞. I started listing the process and found the Defending products running in the machine. When I tried to view some offensive PowerShell scripts in the browser, it flagged them as malicious sites. I understood my situation at the momemnt that I'm gonna walk on a landmine.

I knew if I dropped some executable on the disk, it was going to flag me. And configuring the same EDR scenario on my local machine and compiling those binaries will take a lot of time, which is a nightmare for me. So PowerShell memory is the only hope for me. When I start downloading the exact offensive PowerShell scripts from GitHub, it flags that file. But if I Base64 Encode it and load it in the PowerShell memory, it doesn't get flagged.

# Store the Base64 encoded file
$file = <BASE64_ENCODED_CONTENT_FILE>
$data = Get-Content $file
[System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($data)) | IEX
# Delete the Base64 encoded file

That's it, the required scripts got loaded into PowerShell memory without getting caught (Suprising for me 🤪). I attempted Local privilege escalation, but to my dismay, there was nothing to escalate.

Ran SharpHound and moved the ingested data to my local machine to view in BloodHound. After loading the ingested data (took more time for thousands of AD objects), I started viewing and analysing it carefully. Always look for Outbound ACLs, because they are the hidden link between two AD objects. Some of the compromised users had PS-Session over some machines. I used their accounts to gain the PS Session and started to enumerate the privileges.

Surprisingly, some of the users had Full Privileges over their respective machines. I used that privilege to dump LSASS.exe with procdump.exe. This is a stealth way to dump LSASS.exe, since procdump.exe is a Microsoft-signed binary and that doesn't get flagged by AV/EDRs.

After moving that .dmp file to my local machine, I ran Mimikatz to analyse the dump file and got the NTLM hash for a user who is a member of a privileged group. I don't have Local Administrator Privilege over my controlled machine. As a result, I must only perform "Pass the Hash" over PS-Session.My colleague helped me with writing an undetectable reverse shell in Go. We copied that binary in the remote computer having the PS-Session and we tried PTH using Invoke-Mimikatz to run the reverse shell with PowerCat. Obviously, it ran and we got the privileged group user rights, but we stopped due to an issue. We were inside a firewall, so we were not able to query DC directly for further movement. Little poor me, didn't know that I had a plain text password for the same user in the dump. Seeing as how I was ecstatic after attempting the reverse shell PTH

Also, from the user where I got my initial access, I was able to change an account password with GenericAll ACL rights. I was able to view the LAPS password via AllExtendedRights over a machine after using the password-changed account. Unfortunately, that machine was a waste of time to proceed with.

BloodHound showed that the compromised user from the LSASS dump had a session on the machine, where one of the domain admins was also having a session. Using that plain text password, I did lateral movement with PS-Session and dumped LSASS with procdump.exe again. This time I got the plain text password for Domain Admin. Logging into DC, I have dumped the NTDS.dit file and Registry Hives.

Thats it, the final showdown. I added my required accounts for persistence and dumped all hashes from the target enterprise using secretsdump.

aidenpearce369@jackdaw:~/DC5-LSASSDump$ ls
RegHive  allHashes.txt  log.dmp  ntds.dit
aidenpearce369@jackdaw:~/DC5-LSASSDump$ cat allHashes.txt | grep ':::' | grep -v "$:" | wc -l
43856
aidenpearce369@jackdaw:~/DC5-LSASSDump$ cat allHashes.txt | grep ':::' | grep "$:" | wc -l
48587
aidenpearce369@jackdaw:~/DC5-LSASSDump$

From the dump, I got 43856 user account hashes and 48587 machine account hashes from the enterprise. From these engagements, I also learned a few EDR enumeration and bypass tactics from my colleague. This was my first red team engagement, and it was pretty awesome for me. Because, for these many days I was trying in a intentionally vulnerable environment but in this engagement I had an oppurtunity to simulate as a offensive threat actor breaching into a company which was entirely new to me. For my future engagements, I'm planning to write my own offensive C# and Go binaries to avoid getting detected and to learn more about Windows Internals for bypassing EDRs and exploit development purposes. I'm grateful to those who helped me during my difficulties and guided me to go one step higher in my learning. I'd like to end this blog post by saying that 2022 was a great year for me in terms of accomplishments and self-satisfaction. And to those who read this post: Never stop exploring.