Post Exploitation Enumeration
Now that we have obtained a reverse shell,
we’ll perform some post exploitation enumeration,
both to get an idea of which attack paths are possible from here,
but also to figure out which security mitigations we are up against.
The output from our sysinfo command reveals that the OS version is reported
as “Windows 2016+”, but the build number of 17763 tells the full story.
Windows Server 2016 and 2019 both build on the Windows 10 codebase
and there have been numerous releases.
In essence, build number 17763 equates to Windows 10 version 1809
or Windows Server 2019.
Armed with this information, we can attempt privilege escalation,
but first we have to make some quality-of-life improvements
since this shell is not ideal.
The primary issue here is that our initial Meterpreter shell is based on the
aspx web shell, which means our shell will die if the web worker process times out.
We can solve this by migrating our shell to a different process.
Normally, we could migrate to a process like explorer.exe,
but since the IIS service account uses a non-interactive logon,
the explorer.exe process does not exist in this context.
In fact, the only process running as the DefaultAppPool user is the web worker.
To solve this, we can create a hidden instance of Notepad,
and migrate into it:
With this more stable shell, we can start our post-exploitation enumeration.
We already know that antivirus is present on this machine,
but we would like to determine which product is in place
in order to simplify our bypass attempt.
We also need to know if the antivirus supports AMSI.
We can use the PowerShell HostRecon script to detect a multitude of
host-based settings and information.
Since this is a PowerShell script, we’ll use Meterpreter’s shell
to open a command prompt,
which we can convert to PowerShell.
Next, we’ll download HostRecon.ps1 from our Kali web server
and load it into memory with a download cradle.
We automatically bypass the PowerShell execution policy
with the Invoke-Expression cmdlet.
Now we can execute the Invoke-HostRecon function.
The output reveals that the antivirus engine is likely Windows Defender,
which employs AMSI.
Furthermore, it does not appear that LAPS is in use.
Next, we’ll check the RunAsPPL registry key
to determine if LSA protection is enabled, with the Get-ItemProperty cmdlet.
LSA protection is indeed enabled,
which means we cannot directly obtain NTLM hashes from LSASS.
Finally, we need to determine if application whitelisting is in effect.
We already know that Windows Defender is the antivirus product in use,
which means that if application whitelisting is employed,
it is likely through AppLocker.
The AppLocker rules will typically be enforced through GPOs
in an Active Directory environment, but they will be written to the registry,
and we can dump them with the PowerShell Get-ChildItem cmdlet.
The output shows that AppLocker is indeed in use and the rule
only allows executables signed by Microsoft.
This seems very formidable but AppLocker rules do not apply
to the built-in local accounts such as Local System, Local Service,
or Network Service.
Neither do they apply to the IIS DefaultAppPool account,
which means we only have to worry about AppLocker
if we migrate into a process of a different user.
Next, we want to perform post-exploitation enumeration against Active Directory
to detect any possible attack avenues.
PowerView excels at this, but due to its popularity, it will be detected by AMSI,
which we can attempt to bypass.
Based on our previous research, we know that we can corrupt the first four bytes
of the amsiContext structure to turn off AMSI
for the remainder of the PowerShell process runtime.
Let’s reuse this code.
To use this bypass, we’ll use a download cradle to execute it in memory.
Once AMSI is disabled, we’ll also download PowerView
and load it into memory as well.
Once PowerView is ready, we can begin our enumeration.
For any large Active Directory infrastructure,
this can be a lengthy task.
However, in our smaller simulated penetration test,
it is possible to perform the enumeration of Computers,
Users,
and Groups.
Unfortunately, this does not reveal any direct attack vectors.
At the moment, our attack options are fairly limited
since we only have access to a low-privileged account on a single server
and no domain users are logged into it.
Besides enumerating computers, users, and groups, we should also consider enumerating
Kerberos delegation, including constrained delegation.
The output indicates that the current computer,
is configured for constrained delegation to the CIFS service on file01.
Furthermore, web01 has the TRUSTED_TO_AUTH_FOR_DELEGATION flag set,
which means it can impersonate any user through the S4U protocol transition.
If we can exploit the constrained delegation,
we could compromise file01 and strengthen our foothold.
Post-exploitation enumeration is important
and in a penetration test against a real-world Active Directory
infrastructure, this can take hours, if not days, to perform.
Fortunately, in our small test environment
this process moves along relatively quickly.
However, this process mirrors what we might see in a larger environment.