Showing posts with label webshell. Show all posts
Showing posts with label webshell. Show all posts

Tuesday, April 6, 2021

Bamboozle D 3 f en d e r Effortlessly (BDE) - File Lock on Shell Code

Still confirming this is working the way I intend it, updates and detailed POC to follow...


I found RCE in a web application, and place a web shell file in a publicly facing directory on the server. However, AV keeps deleting it, so as part of my command injection, I spin up a process to put a file handle on the shell. Even though defender is detecting it, it's not deleting it. (I know it's detecting it because I've also gained remote desktop access and can see the alerts.)


In the past I have focused mainly on detection evasion but deletion evasion is looking a lot easier right now.


UPDATE: Well, turns out my webshell was a low-priv account, but the process I was doing command injection through was running as NT AUTHORITY\SYSTEM, so woot! No wonder I can successfully lock the webshell file using a process that starts on startup. This doesn't work for Meterpreter payloads that spin off their own processes that then become detected. So maybe it works, but it's limited.

Sidenote:

A bit about how difficult it was to figure out I was root when my RCE was Java arbitrary code execution...


The webshell was written to C:\inetpub\wwwroot by my Java process. It executed commands as a low privilege AppPool type IIS user. Running whoami through the shell will tell you this


Asking the Java Virtual Machine  was a little useless. Calling System.getProperty("user.name") just returns the USERNAME environment variable from (I believe) when the JVM was initiated. This gave me PC-NAME$ where PC was the domain name of another user I got access another way, i.e. PC-NAME\otheruser.


FINALLY I got the idea to run "cmd.exe /c whoami" directly through the Java injection, write the results to a publicly served directory and check out the results. NT AUTHORITY\SYSTEM! Whew! At this point I guess I don't need evasion, I could just turn off the AV!




Sunday, November 29, 2020

Palo Alto Networks - WAF Bypass for Webshell

I originally found/reported to Palo Alto in 2018.

You can use the default Kali Linux aspx webshell to get RCE on a server protected by Palo Alto Networks... as long as you change the "m" in cmd.exe to an "M".

That's it! That's the whole hack..! It bypasses the whitelist.

So my discovery process...

While I was trying to upload my webshell, I noticed the font of the error looked different than the rest of the application. I googled the wording, trying to figure out what service was displaying it. It looked similar to an image of a Palo Alto dialog:

Mine:

Theirs:

 

Close enough - I assumed I was dealing with a Palo Alto firewall. The logs confirmed this was true. The bypass worked and eventually I upgraded my webshell to a Meterpreter shell. The Palo Alto WAF bypass process wasn't fancy, but it was instrumental in owning the server.

 


 

 



Tuesday, May 28, 2019

Running Unicorn Payload Through Web Shell

This for escalating a low-privileged web shell to a Meterpreter shell. In this example, the Powershell execution policy was changed (using the web shell) to RemoteSigned using powershell Set-ExecutionPolicy. The normal method of storing a unicorn reverse-https payload wasn't working, since the file couldn't be written to the server (either through permissions restrictions or being picked up by antivirus).

Take the contents of the generated unicorn payload from the file, and run it as a Powershell command in the browser: