StellarComms
Challenge Lab (Medium) - by Mac
The following post by 0xb0b is licensed under CC BY 4.0
Scenario
Objective / Scope
Stellar Communications, a regional telecommunications provider, has retained the Hack Smarter Red Team to conduct a covert internal network penetration test. The client is concerned about the resilience of their internal Active Directory infrastructure against insider threats and compromised VPN endpoints.
Your objective is to simulate a compromised remote worker, pivot through the internal network, and demonstrate the ability to compromise high-value targets (HVTs) without triggering the Blue Team's SOC alerts.
Initial Access
Our initial access team has successfully established a VPN tunnel into the environment. We have identified a valid username, likely belonging to a new hire or junior staff member.
Valid User:
Username:
junior.analystPassword: Unknown
Summary
Summary
In StellarComms we begin as a simulated remote worker with VPN access and an identified username, junior.analyst. Enumeration of the domain controller DC-STELLAR reveals an exposed FTP service containing onboarding documents that disclose default passwords. Using these, we authenticate as junior.analyst and perform BloodHound enumeration, discovering a misconfigured ACL allowing WriteOwner over the stellar-ops_control group. Abusing this, we gain full control of the group and reset the password of ops.controller, achieving remote access via WinRM. From this foothold, we extract Firefox credentials from local profiles, revealing the password of astro.researcher. With this account, we leverage a WriteDACL privilege over eng.payload to reset its password, and from there, read the managed password of the gMSA account satlink-service$. Since this account has DCSync rights, we replicate domain credentials and recover the NT hash of the Administrator account. Using Pass-the-Hash via WinRM, we log in as Domain Admin and retrieve the final flag.
Recon
We use rustscan -b 500 -a 10.1.129.141 -- -sC -sV -Pn to enumerate all TCP ports on the stellarcomms machine, piping the discovered results into Nmap which runs default NSE scripts -sC, service and version detection -sV, and treats the host as online without ICMP echo -Pn.
A batch size of 500 trades speed for stability, the default 1500 balances both, while much larger sizes increase throughput but risk missed responses and instability.
The stellarcomms machine is actually a domain controller with exposed services including FTP 21 allowing anonymour login, DNS 53, Kerberos 88/464, an IIS /10.0 web server on port 80, multiple MSRPC endpoints 135, 593, 49664+, SMB 139/445, LDAP and LDAPS 389/636/3268/3269 tied to Active Directory, RDP 3389, and .NET Remoting 9389. This indicates a fully integrated Windows AD environment where LDAP/LDAPS and Kerberos provide authentication, SMB and RPC enable remote management, and RDP/WinRM serve as remote access points.
FTP
We start with the FTP service and gain access via anonymous login.
Here we find documents in the Docs folder. Among other things, we find something that could refer to onboarding documents: Stellar_UserGuide.pdf.
We download every file and inspect each. It turns out that Stellar_UserGuide.pdf is for real an on-boarding document. Among other things, it contains default credentials a default password for testing purposes. We note that down.
WEB
For now, we'll continue and take a look at the website hosted via the IIS. It appears to be a purely static site. We find a contact form, but it doesn't seem to be functional.
At the gallery we find some Pictures. In the metadata of the pictures, we find the artist and creator who is the provided user from the scenario.
SMB
Before we dive in with the credentials of the on-boarding document and the provided user we try to authenticate as guest and anonymously against SMB, but without success. Nevertheless we generate the hosts file entry like the following
We add the following to our /etc/hosts file. We could also directly append the entry to our hosts file by providing the path to /etc/hosts in the NetExec command.
Access as junior.analyst
We test whether the junior.analyst user is using the default password. To do this, we use NetExec to authenticate ourselves to SMB as junior.analyst. We are successful. However, we do not find any special shares.
We could enumerate further users from here, but we will skip this and enumerate the domain using BloodHound, since we now have access as the user junior.analyst.
BloodHound Enumeration
We enumerate the AD using BloodHound.
We identify the Domain Admin.
And we see that the user junior.analyst has WriteOwner permission to the stellar-ops_control group.
This would allow us to set ourselves as the owner of the group, then set GenericAll to the group, so that we can add ourselves as the user junior.analyst and thus gain the permissions of the group and move laterally. But first, let's see what the group can do.
We query for the Shortest Path from Owned objects. We see that we can move laterally via our WriteOwner over the stellar-ops_control group, from there we can change the password of the user ops.controller via the ForceChangePassword permission. With that resulting user we can gain initial foothold, since the user is in the remote management users group.
Furthermore we query for the Shortest Path to Domain Admins. We observe that we can move laterally via the WriteDacl permission of the astro.researcher user over eng.payload, allowing us to grant ourselves access to read the gMSA password of satlink.services. From there, we can authenticate as satlink.services, which has DC Sync privileges, which allows us to simulate the replication process from the domain controller. This leads to the compromise of the credential material on the domain controller.
However, we also see that there is no path from junior.analyst to astro.researcher. So we need to make sure that we escalate from our foothold on to astro.researcher in order to fully compromise the domain controller.
Shell as ops.controller
We first pursue our enumerated attack path from our Bloodhound enumeration and escalate from junior.analyst to ops.controller to gain initial foothold on the domain controller.
Recalling the results form the enumeration:
We query for the
Shortest Path from Owned objects. We see that we can move laterally via ourWriteOwnerover thestellar-ops_controlgroup, from there we can change the password of the userops.controllervia the ForceChangePassword permission. With that resulting user we can gain initial foothold, since the user is in theremote management usersgroup.
First we need to add junior.analyst to the stellar-ops_control group.
And we see that the user junior.analyst has WriteOwner permission to the
stellar-ops_controlgroup.This would allow us to set ourselves as the owner of the group, then set
GenericAllto the group, so that we can add ourselves as the userjunior.analystand thus gain the permissions of the group and move laterally. But first, let's see what the group can do.
WriteOwner -> change ourself to owner
We change the ownership of the target Active Directory object stellarops-control to our controlled account junior.analyst so we gain full control over it.
Grant us GenericAll over the Group
We grant the account junior.analyst GenericAll permissions over the target group stellarops-control, giving us full control over the object and its attributes.
AddMember: Add junior.analyst to the group
We add the account junior.analyst as a member of the stellarops-control group to inherit its privileges.
This abuse can be carried out when controlling an object that has a GenericAll, GenericWrite, Self, AllExtendedRights or Self-Membership, over the target group.
ForceChangePassword
We reset the password of the ops.controller account to a known value, allowing us to authenticate as that user.
We test the credentials using NetExec and are able to authenticate against SMB on DC-STELLAR.
Next, we get an interactive session using evil-winrm and are able to connect. We find the user flag at C:\Users\ops.controller\Desktop\user.txt.
Access as astro.researcher
On the Desktop of ops.controller we find an installer for Firefox 91.0 esr next to the flag. What we could try now is to extract the browser credentials.
There is also an interesting article on this topic that goes into detail about various browsers.
What we need in the end is a logins.json and a key4.db file to decrypt the credentials of a firefox profile.
Where are the creds stored?Users’ Firefox profiles are each stored in their own directory under
C:\Users\Apr4h\Roaming\Mozilla\Firefox\Profiles\<random text>.default\. In recent versions of Firefox, there are two relevant artefacts required for decryption of stored credentials.
C:\Users\Apr4h\Roaming\Mozilla\Firefox\Profiles\<random text>.default\key4.db
C:\Users\Apr4h\Roaming\Mozilla\Firefox\Profiles\<random text>.default\logins.json
We find the following two profiles: 67wyvfsfs.default and v8mn7ijj.default-esr.
Of which v8mn7ijj.default-esr...
is not empty, we download both required files:
To extract the credentials from the files we can make use of the following project called firepwd:
We try to decrypt the credentials contained in the v8mn7ijj.default-esr (the folder contains both files) and find the credentials of astro.reaseacher.
We test the credentials using NetExec and are able to authenticate against SMB on DC-STELLAR.
Recalling our BloodHound enumeration, we can now follow the attack path starting from astro.researcher to completely compromise the domain controller.
Furthermore we query for the
Shortest Path to Domain Admins. We observe that we can move laterally via theWriteDaclpermission of theastro.researcheruser overeng.payload, allowing us to grant ourselves access to read thegMSA passwordofsatlink.services. From there, we can authenticate assatlink.services, which hasDC Syncprivileges, which allows us to simulate the replication process from the domain controller. This leads to the compromise of the credential material on the domain controller.However, we also see that there is no path from
junior.analysttoastro.researcher. So we need to make sure that we escalate from our foothold on toastro.researcherin order to fully compromise the domain controller.
Access as eng.payload
Grant us GenericAll over the eng.payload
We grant the account astro.researcher GenericAll permissions over the eng.payload user, giving us full control to modify it as needed.
ForceChangePassword
Now we reset the password of the eng.payload, since we have GenericAll permissions over that.
We test the credentials using NetExec and are able to authenticate against SMB on DC-STELLAR.
Access as satlink-services
ReadGMSAPassword
We read the managed password of the gMSA account satlink-service$ by querying its msDS-ManagedPassword attribute using our authorized access via eng.payload.
This abuse stands out a bit from other abuse cases. It can be carried out when controlling an object that has enough permissions listed in the target gMSA account's
msDS-GroupMSAMembershipattribute's DACL. Usually, these objects are principals that were configured to be explictly allowed to use the gMSA account.The attacker can then read the gMSA (group managed service accounts) password of the account if those requirements are met.
We retrive the NT hash of satlink-service$.
We test the hash using NetExec and are able to authenticate against SMB on DC-STELLAR.
Shell as Domain Administrator
Now that we have access as satlink-service$ we can perform the DCSync attack.
DCSync is a technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller. This attack can lead to the compromise of major credential material such as the Kerberos
krbtgtkeys used legitimately for tickets creation, but also for tickets forging by attackers. The consequences of this attack are similar to an NTDS.dit dump and parsing but the practical aspect differ. A DCSync is not a simple copy & parse of the NTDS.dit file, it's aDsGetNCChangesoperation transported in an RPC request to the DRSUAPI (Directory Replication Service API) to replicate data (including credentials) from a domain controller.
We perform the secretsdump and are able to retrieve the NT hash of the Domain Admin among others.
We log in as the Domain Admin using the retrieved hash via evil-winrm. We find the final flag at C:\Users\Administrator\Desktop\root.txt.
Last updated
Was this helpful?