-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
324 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,324 @@ | ||
|  | ||
|
|
||
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ||
|
|
||
| # Enumeration: | ||
|
|
||
| I started by scanning for open ports and services using `rustscan` on the target environment. This scan revealed multiple open ports, providing insights into the available services. | ||
|
|
||
|  | ||
|
|
||
| ``` | ||
| PORT STATE SERVICE REASON VERSION | ||
| 53/tcp open domain syn-ack ttl 127 Microsoft DNS 6.1.7601 (1DB15D39) (Windows Server 2008 R2 SP1) | ||
| | dns-nsid: | ||
| |_ bind.version: Microsoft DNS 6.1.7601 (1DB15D39) | ||
| 88/tcp open kerberos-sec syn-ack ttl 127 Microsoft Windows Kerberos (server time: 2024-08-31 07:50:43Z) | ||
| 135/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC | ||
| 139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn | ||
| 389/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: cascade.local, Site: Default-First-Site-Name) | ||
| 445/tcp open microsoft-ds? syn-ack ttl 127 | ||
| 636/tcp open tcpwrapped syn-ack ttl 127 | ||
| 3268/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory LDAP (Domain: cascade.local, Site: Default-First-Site-Name) | ||
| 3269/tcp open tcpwrapped syn-ack ttl 127 | ||
| 5985/tcp open http syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) | ||
| |_http-server-header: Microsoft-HTTPAPI/2.0 | ||
| |_http-title: Not Found | ||
| 49154/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC | ||
| 49155/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC | ||
| 49157/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0 | ||
| 49158/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC | ||
| 49165/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC | ||
| Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port | ||
| Device type: general purpose|phone|specialized | ||
| Running (JUST GUESSING): Microsoft Windows 8|Phone|7|2008|8.1|Vista (92%) | ||
| OS CPE: cpe:/o:microsoft:windows_8 cpe:/o:microsoft:windows cpe:/o:microsoft:windows_7 cpe:/o:microsoft:windows_server_2008:r2 cpe:/o:microsoft:windows_8.1 cpe:/o:microsoft:windows_vista::- cpe:/o:microsoft:windows_vista::sp1 | ||
| OS fingerprint not ideal because: Missing a closed TCP port so results incomplete | ||
| Aggressive OS guesses: Microsoft Windows 8.1 Update 1 (92%), Microsoft Windows Phone 7.5 or 8.0 (92%), Microsoft Windows Embedded Standard 7 (91%), Microsoft Windows 7 or Windows Server 2008 R2 (89%), Microsoft Windows Server 2008 R2 (89%), Microsoft Windows Server 2008 R2 or Windows 8.1 (89%), Microsoft Windows Server 2008 R2 SP1 or Windows 8 (89%), Microsoft Windows 7 (89%), Microsoft Windows 7 Professional or Windows 8 (89%), Microsoft Windows 7 SP1 or Windows Server 2008 R2 (89%) | ||
| No exact OS matches for host (test conditions non-ideal). | ||
| TCP/IP fingerprint: | ||
| SCAN(V=7.94SVN%E=4%D=8/31%OT=53%CT=%CU=%PV=Y%DS=2%DC=T%G=N%TM=66D2CBBA%P=x86_64-pc-linux-gnu) | ||
| SEQ(SP=105%GCD=1%ISR=109%TI=I%II=I%SS=O%TS=7) | ||
| SEQ(SP=105%GCD=1%ISR=109%TI=I%II=I%SS=S%TS=7) | ||
| OPS(O1=M53CNW8ST11%O2=M53CNW8ST11%O3=M53CNW8NNT11%O4=M53CNW8ST11%O5=M53CNW8ST11%O6=M53CST11) | ||
| WIN(W1=2000%W2=2000%W3=2000%W4=2000%W5=2000%W6=2000) | ||
| ECN(R=Y%DF=Y%TG=80%W=2000%O=M53CNW8NNS%CC=N%Q=) | ||
| T1(R=Y%DF=Y%TG=80%S=O%A=S+%F=AS%RD=0%Q=) | ||
| T2(R=N) | ||
| T3(R=N) | ||
| T4(R=N) | ||
| U1(R=N) | ||
| IE(R=Y%DFI=N%TG=80%CD=Z) | ||
| Uptime guess: 0.010 days (since Sat Aug 31 03:37:55 2024) | ||
| Network Distance: 2 hops | ||
| TCP Sequence Prediction: Difficulty=261 (Good luck!) | ||
| IP ID Sequence Generation: Incremental | ||
| Service Info: Host: CASC-DC1; OS: Windows; CPE: cpe:/o:microsoft:windows_server_2008:r2:sp1, cpe:/o:microsoft:windows | ||
| Host script results: | ||
| | smb2-time: | ||
| | date: 2024-08-31T07:51:47 | ||
| |_ start_date: 2024-08-31T07:38:25 | ||
| | p2p-conficker: | ||
| | Checking for Conficker.C or higher... | ||
| | Check 1 (port 51409/tcp): CLEAN (Timeout) | ||
| | Check 2 (port 47234/tcp): CLEAN (Timeout) | ||
| | Check 3 (port 10882/udp): CLEAN (Timeout) | ||
| | Check 4 (port 58957/udp): CLEAN (Timeout) | ||
| |_ 0/4 checks are positive: Host is CLEAN or ports are blocked | ||
| | smb2-security-mode: | ||
| | 2:1:0: | ||
| |_ Message signing enabled and required | ||
| |_clock-skew: 1s | ||
| TRACEROUTE (using port 139/tcp) | ||
| HOP RTT ADDRESS | ||
| 1 222.13 ms 10.10.14.1 | ||
| 2 222.17 ms 10.10.10.182 | ||
| ``` | ||
|
|
||
| From the port scan results, I observed a domain `cascade.local`. To facilitate further enumeration and potential exploitation, I added this domain to my hosts configuration file to ensure proper name resolution | ||
|
|
||
| ## Kerbrute: | ||
|
|
||
| Given that port 88 (Kerberos) is open, I proceeded with Kerberos enumeration using `kerbrute`. This tool helps in identifying valid usernames in the network by leveraging the Kerberos protocol. I used a common set of usernames for this purpose: | ||
|
|
||
| ``` | ||
| kerbrute userenum --dc cascade.local -d cascade.local /usr/share/SecLists/Usernames/cirt-default-usernames.txt | ||
| ``` | ||
|
|
||
| Despite trying a list of usernames, `kerbrute` was able to identify only one valid user in the network: `Administrator`. | ||
|
|
||
|  | ||
|
|
||
| ## RPC Enumeration | ||
|
|
||
| Seeing that RPC is available and responding, I tried to enumerate information using NULL authentication, which indeed worked: | ||
|
|
||
| ``` | ||
| rpcclient -U '' -N cascade.local | ||
| ``` | ||
|
|
||
| Using RPC, I queried for domain users and groups, which revealed a significant amount of information: | ||
|
|
||
|  | ||
|
|
||
| From these results, I compiled a list of valid usernames found in the domain. These usernames can now be leveraged for further enumeration or attacks, such as password spraying, brute force. | ||
|
|
||
| ## LDAP enumeration: | ||
|
|
||
| For the confirmation purpose, I again checked the domain users using the `ldapsearch` & observed that we have total, 15 users exccluding the machine account: | ||
|
|
||
| ``` | ||
| ldapsearch -x -H ldap://cascade.local -b 'dc=cascade,dc=local' 'objectClass=person' | grep "sAMAccountName:" | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| ## SMB Enumeration: | ||
|
|
||
| Using the list of valid usernames gathered from RPC enumeration, I proceeded with SMB enumeration. My first step was to check the password policy using `netexec` to determine if there were any restrictions on password attempts, such as account lockout thresholds. | ||
|
|
||
| ``` | ||
| nxc smb cascade.local -u "" -p "" --pass-pol | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| The results revealed no account lockout threshold, indicating that it would be possible to perform password spraying or brute-force attacks without risking account lockouts. I attempted to use the `user:user` credential combination for authentication, but this was unsuccessful: | ||
|
|
||
|  | ||
|
|
||
| I then attempted to authenticate as a NULL user and an anonymous user to access SMB file shares, but neither of these attempts was successful: | ||
|
|
||
|  | ||
|
|
||
| ## AS-REP Roasting: | ||
|
|
||
| With a list of valid usernames, I attempted an AS-REP roasting attack to extract Kerberos tickets for users with the `UF_DONT_REQUIRE_PREAUTH` attribute set. This attack can be effective when such users exist, as it allows for offline brute-forcing of the extracted ticket hashes. | ||
|
|
||
| I used the following command with Impacket's `GetNPUsers` script: | ||
|
|
||
| ``` | ||
| impacket-GetNPUsers -dc-ip 10.10.10.182 -request cascade.local/ -format hashcat -usersfile users.txt -no-pass | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| Unfortunately, the AS-REP roasting attack failed. None of the users in the cascade.local domain had the `UF_DONT_REQUIRE_PREAUTH` attribute set, which is necessary for this type of attack. | ||
|
|
||
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ||
|
|
||
| # Initial Access: | ||
|
|
||
| After various failed attempts, I revisited the LDAP enumeration results to find any overlooked information. I noticed an attribute called `cascadeLegacyPwd` associated with the user `Ryan Thompson`. The value appeared to be a base64-encoded password. | ||
|
|
||
|  | ||
|
|
||
| I decoded the cascadeLegacyPwd attribute using base64 decoding, which revealed the plaintext credentials: | ||
|
|
||
|  | ||
|
|
||
| I tried to login with this credential but that didn't worked: | ||
|
|
||
|  | ||
|
|
||
| The decoded credentials didn't work for an interactive login, so I used a password spraying technique with `netexec` to find which services they could access. It turned out that the credentials worked for SMB access under the username `r.thompson`. | ||
|
|
||
|  | ||
|
|
||
| Using `smbmap`, I identified accessible SMB shares. The `Data` share seemed interesting: | ||
|
|
||
| ``` | ||
| smbmap -u 'r.thompson' -p 'rY4n5eva' -H cascade.local | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| To explore the `Data` share, I initially used `smbclientng`, but it didn't work as expected, so I switched to `smbclient`: | ||
|
|
||
| ``` | ||
| smbclient -U 'cascade/r.thompson' //cascade.local/Data | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| I started downloading all files from the share, but found access was limited to the `IT` folder. Using `smbclient`, I recursively downloaded files from the `IT` directory. | ||
|
|
||
| ``` | ||
| recurse ON #to download everything recursively | ||
| prompt OFF #to off the prompt | ||
| mget * #to download everything | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| ## Analyzing the Files | ||
|
|
||
| In the `IT/Email Archive folder`, the file `Meeting_Notes_June_2018.html` mentioned a temporary admin account: | ||
|
|
||
| ``` | ||
| Username is TempAdmin (password is the same as the normal admin account password) | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| In `IT/Temp/s.smith`, a file named `VNC Install.reg` contained a VNC password in hex format. | ||
|
|
||
|  | ||
|
|
||
| ## Decrypting the VNC Password | ||
|
|
||
| Using the decryption method found [here](https://tenaka.gitbook.io/pentesting/useful-commands/password-cracking/vnc-decrypt-password), I successfully decrypted the VNC password: | ||
|
|
||
| ``` | ||
| echo -n 6bcf2a4b6e5aca0f | xxd -r -p | openssl enc -des-cbc --nopad --nosalt -K e84ad660c4721ae0 -iv 0000000000000000 -d | hexdump -C | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| ### Successful Login as s.smith | ||
|
|
||
| After another password spray attempt, I found that the decrypted password worked for `s.smith`: | ||
|
|
||
|  | ||
|
|
||
| Using these credentials, I logged in as `s.smith` and successfully retrieved the user flag: 🙂 | ||
|
|
||
|  | ||
|
|
||
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ||
|
|
||
| # Root.txt | ||
|
|
||
| After obtaining the user flag, I began searching for methods to escalate my privileges. I started by examining my privileges using the following command, which revealed no special privileges assigned: | ||
|
|
||
| ``` | ||
| whoami /all | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| Next, I checked the group memberships and noticed that the s.smith user belonged to two unique groups: `Audit Share` and `IT`: | ||
|
|
||
| ``` | ||
| net user s.smith | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| ## s.smith --> arksvc | ||
|
|
||
| To gather more information, I used the `net` command to list the details of these groups. The `Audit Share` group had an interesting comment hinting at access to shared resources, but `s.smith` was the only member: | ||
|
|
||
|  | ||
|
|
||
| However, direct access to the shared directories from the host was not possible: | ||
|
|
||
|  | ||
|
|
||
| Instead, using `smbclient`, I accessed the `Audit` share and found several files and directories: | ||
|
|
||
|  | ||
|
|
||
| I downloaded an interesting file named `Audit.db` from the DB directory: | ||
|
|
||
|  | ||
|
|
||
| Using sqlitebrowser to inspect `Audit.db`, I found four tables. One of the tables, Ldap, contained a base64-encoded password associated with the user `ArkSvc`: | ||
|
|
||
|  | ||
|
|
||
|  | ||
|
|
||
| Attempting to decode this base64 string resulted in a non-standard encoding: | ||
|
|
||
|  | ||
|
|
||
| ## Extracting Encryption Keys | ||
|
|
||
| I found a batch file named `RunAudit.bat` in the same share, indicating the use of the `CascAudit.exe` and `CascCrypto.dll` files. These files suggested custom encryption was being used: | ||
|
|
||
|  | ||
|
|
||
| After downloading both the executable and DLL files, I used `dnSpy` to decompile them. The decompiled code revealed the decryption key and the IV: | ||
|
|
||
|  | ||
|
|
||
| The decryption process involved base64 decoding followed by AES-128 decryption using the extracted IV and key: | ||
|
|
||
|  | ||
|
|
||
| I replicated these decryption steps using `CyberChef`, successfully revealing the plaintext password: | ||
|
|
||
|  | ||
|
|
||
| Using the decrypted password, I logged in as the `ArkSvc` user: | ||
|
|
||
|  | ||
|
|
||
| ## ArkSvc -> Administrator: | ||
|
|
||
| After logging in as `ArkSvc`, I discovered this account belonged to the `AD Recycle Bin` group: | ||
|
|
||
|  | ||
|
|
||
| Following a guide on [HackTricks](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/privileged-groups-and-token-privileges#a-d-recycle-bin), I learned that this membership allows reading deleted Active Directory objects, which can include sensitive information: | ||
|
|
||
| ``` | ||
| Membership in this group allows for the reading of deleted Active Directory objects, which can reveal sensitive information: | ||
| ``` | ||
|
|
||
|  | ||
|
|
||
| Using a PowerShell command from the blog, I retrieved multiple deleted items, including details of the `TempAdmin` account referenced earlier in the HTML file: | ||
|
|
||
|  | ||
|
|
||
| Decoding the credentials associated with TempAdmin and using them with the Administrator account finally granted me access as an administrator. Using this elevated access, I navigated to the Administrator's desktop and retrieved the root flag, achieving full system compromise:(pwn3d!🎉) | ||
|
|
||
|  | ||
|
|
||
|
|
||
|
|