☑️Web Shells

Introduction

During external penetration tests, we often find that clients' perimeter networks are well-hardened. They do not expose vulnerable services such as SMB or other elements that we used to frequently encounter. Those elements we now primarily anticipate during an internal penetration test. During our external penetration tests, we most commonly "get in" (gain a foothold inside the internal network) via web application attacks (file upload attacks, SQL injection, RFI/LFI, command injection, etc.), password spraying (against RDS, VPN portals, Citrix, OWA, and other applications using Active Directory authentication), and social engineering.

There are many other ways that we may find to upload a web shell that is outside the scope of this module. What comes next once we have identified an unrestricted upload vulnerability or misconfiguration?

A web shell is a browser-based shell session we can use to interact with the underlying operating system of a web server. Again, to gain remote code execution via web shell, we must first find a website or web application vulnerability that can give us file upload capabilities. Most servers delete uploaded files after a certain period of time so to maintain persistence we then will gain a more interactive reverse shell but this is how we initially gain remote code execution.

Btw, when to use GET and when to use REQUEST in the simple PHP payload?

Laudanum

Laudanum is a repository of ready-made files that can be used to inject onto a victim and receive back access via a reverse shell, run commands on the victim host right from the browser, and more. The repo includes injectable files for many different web application languages to include asp, aspx, jsp, php, and more. It is installed by default on Kali.

The Laudanum files can be found in the /usr/share/laudanum directory. Some of the files we can copy and paste into the victim machine while other will require modifications such as with our attack hosts IP address.

Lets say we were able to upload files so we upload /usr/share/laudanum/aspx/shell.aspx as demo.aspx in the web server. We can access it if we know the path for example www.site.com/path/uploads/demo.aspx. Sometimes the servers will change the name of the uploaded files which will make it harder for us to access but if its not the case, then when we visit this page it should give us a simple web shell:

Antak Webshell

Active Server Page Extended (ASPX) is a file type/extension written for Microsoft's ASP.NET Framework. On a web server running the ASP.NET framework, web form pages can be generated for users to input data. On the server side, the information will be converted into HTML. We can take advantage of this by using an ASPX-based web shell to control the underlying Windows operating system.

Antak is a web shell built-in ASP.Net included within the Nishang project. Nishang is an Offensive PowerShell toolset that can provide options for any portion of your pentest.

The Antak files can be found in the /usr/share/nishang/Antak-WebShell directory.

Antak web shell functions like a Powershell Console. However, it will execute each command as a new process. It can also execute scripts in memory and encode commands you send. As a web shell, Antak is a pretty powerful tool. (Lots of 4688s??)

Lets say we are using /usr/share/nishang/Antak-WebShell/antak.aspx, here we only have to modify the username and password. This prevents others to access our shell and makes our operations more secure. When we access the webshell we have to user these credentials.

PHP Web Shells

PHP is the most popular server-side programming language. Hypertext Preprocessor or PHP is an open-source general-purpose scripting language typically used as part of a web stack that powers a website. PHP is used by 78.6% of all websites whose server-side programming language we know.

Knowing that a web server is using PHP gives us pentesters a clue that we may gain a PHP-based web shell on this system.

Since PHP processes code & commands on the server-side, we can use pre-written payloads to gain a shell through the browser or initiate a reverse shell session with our attack box.

Lets say we get into a web page where we can upload a logo which only accepts .png,.jpeg file types. We want to upload our PHP web shell using WhiteWinterWolf's PHP Web Shell. We can bypass this restriction with Burp Suite.

Our goal is to change the content-type to bypass the file type restriction in uploading files to be "presented" as the logo image so we can navigate to that file and have our web shell.

After intercepting, we will change Content-type from application/x-php to image/gif. This will essentially "trick" the server and allow us to upload the .php file, bypassing the file type restriction. Once we do this, we can select Forward twice, and the file will be submitted.

Considerations when Dealing with Web Shells

When utilizing web shells, consider the below potential issues that may arise during your penetration testing process:

• Web applications sometimes automatically delete files after a pre-defined period

• Limited interactivity with the operating system in terms of navigating the file system, downloading and uploading files, chaining commands together may not work (ex. whoami && hostname), slowing progress, especially when performing enumeration -Potential instability through a non-interactive web shell

• Greater chance of leaving behind proof that we were successful in our attack

Depending on the engagement type (i.e., a black box evasive assessment), we may need to attempt to go undetected and cover our tracks. We are often helping our clients test their capabilities to detect a live threat, so we should emulate as much as possible the methods a malicious attacker may attempt, including attempting to operate stealthily. This will help our client and save us in the long run from having files discovered after an engagement period is over. In most cases, when attempting to gain a shell session with a target, it would be wise to establish a reverse shell and then delete the executed payload. Also, we must document every method we attempt, what worked & what did not work, and even the names of the payloads & files we tried to use. We could include a sha1sum or MD5 hash of the file name, upload locations in our reports as proof, and provide attribution.