Web shells Detectting and Hardening servers against webshell


web shells and its Challenges in detecting 


Web shells can be built using any of several languages that are popular with web applications. Within each language, there are several means of executing arbitrary commands and there are multiple means for arbitrary attacker input. Attackers can also hide instructions in the user agent string or any of the parameters that get passed during a web server/client exchange.
 
When analyzing script, it is important to leverage contextual clues. For example, a scheduled task called “Update Google” that downloads and runs code from a suspicious website should be inspected more closely.

With web shells, analyzing context can be a challenge because the context is not clear until the shell is used. In the following code, the most useful clues are “system” and “cat /etc/passwd”, but they do not appear until the attacker interacts with the web shell:

Another challenge in detecting web shells is uncovering intent. A harmless-seeming script can be malicious depending on intent. But when attackers can upload arbitrary input files in the web directory, then they can upload a full-featured web shell that allows arbitrary code execution—which some very simple web shells do.

These file-upload web shells are simple, lightweight, and easily overlooked because they cannot execute attacker commands on their own. Instead, they can only upload files, such as full-featured web shells, onto web servers. Because of their simplicity, they are difficult to detect and can be dismissed as benign, and so they are often used by attackers for persistence or for early stages of exploitation.

Finally, attackers are known to hide web shells in non-executable file formats, such as media files. Web servers configured to execute server-side code create additional challenges for detecting web shells, because on a web server, a media file is scanned for server-side execution instructions. Attackers can hide web shell scripts within a photo and upload it to a web server. When this file is loaded and analyzed on a workstation, the photo is harmless. But when a web browser asks a server for this file, malicious code executes server side.

These challenges in detecting web shells contribute to their increasing popularity as an attack tool. We constantly monitor how these evasive threats are utilized in cyber attacks, and we continue to improve protections


Web shell: Finding Web Shells

Purpose: Identify web shells (stand-alone|injected)

Data Required : Web server logs (apache, IIS, etc.)

Collection Considerations : Collect from all webservers, and ensure that parameters are collected.

POST data should be collected.

• For apache consider using mod_security or mod_dumpio

• For IIS use Failed Request Tracing / Custom Logging

Analysis Techniques:

Look for parameters passed to image files (e.g., /bad.png?zz=ls

 

Web logs things to notice

    • User-Agent is rare

    • User-Agent is new

    • Domain is rare

    • Domain is new

    • High frequency of http connections

    • URI is same

    • URI varies but length is constant.

    • Domain varies but length is constant

    • Missing referrer

    • Missing or same referrer to multiple uri’s on single dest.

 

 

Endpoint detection strategies:

• Look for creation of processes whose parent is the webserver (e.g., apache, w3wp.exe); these will come from functions like:

○ PHP functions like exec(), shell_exec(), etc.

○ asp(.net) functions like eval(), bind(), etc.)

• Looking for file additions or file changes (if you have a change management process and schedule to easily differentiate 'known good') -- (using something like inotify on linux (or FileSystemWatcher in .NET), to monitor the webroot folder(s) recursively)

 

Other Notable things:

IIS instance (w3wp.exe) running commands like ‘net’, ‘whoami’, ‘dir’, ‘cmd.exe’, or ‘query’, to name a few, is typically a strong early indicator of web shell activity.

 

Look for suspicious process that IIS worker process (w3wp.exe), Apache HTTP server processes (httpd.exe, visualsvnserver.exe), etc. do not typically initiate (e.g., cmd.exe and powershell.exe)

 

Look for suspicious web shell execution, this can identify processes that are associated with remote execution and reconnaissance activity (example: “arp”, “certutil”, “cmd”, “echo”, “ipconfig”, “gpresult”, “hostname”, “net”, “netstat”, “nltest”, “nslookup”, “ping”, “powershell”, “psexec”, “qwinsta”, “route”, “systeminfo”, “tasklist”, “wget”, “whoami”, “wmic”, etc.)

 

lolbas:

    - rundll32.exe

    - dllhost.exe

    tools:

    - net.exe

    - powershell.exe

    - ipconfig.exe

    - CobaltStrike

    - BloodHound

    - nslookup.exe

 

execution:

        - "T1055.012 - Process Injection: Process Hollowing"

    - behavior: RUNDLL32 created ~20 instances of DLLHOST without command-line arguments.

      id: 1669ecb0-3a8a-4858-9efd-23e5c01ad643

      type: Process Created

      cmdLine:

      - C:\\Windows\\System32\\dllhost.exe

      process: C:\\Windows\\System32\\dllhost.exe

      parentProcess: C:\\Windows\\System32\\rundll32.exe

 

Attackers need to execute tools. Look at Windows Event ID's 4688/592. Stack and look for outliers. Group by execution time and user."

 

Hardening servers against web shells

A single web shell allowing attackers to remotely run commands on a server can have far-reaching consequences. With script-based malware, however, everything eventually funnels to a few natural chokepoints, such as cmd.exe, powershell.exe, and cscript.exe. As with most attack vectors, prevention is critical.

Organizations can harden systems against web shell attacks by taking these preventive steps:

  • Identify and remediate vulnerabilities or misconfigurations in web applications and web servers. Use Threat and Vulnerability Management to discover and fix these weaknesses. Deploy the latest security updates as soon as they become available.
 
  • Implement proper segmentation of your perimeter network, such that a compromised web server does not lead to the compromise of the enterprise network.
 
  • Enable antivirus protection on web servers. Turn on cloud-delivered protection to get the latest defenses against new and emerging threats. Users should only be able to upload files in directories that can be scanned by antivirus and configured to not allow server-side scripting or execution.
 
  • Audit and review logs from web servers frequently. Be aware of all systems you expose directly to the internet.
 
  • Utilize the Windows Defender Firewall, intrusion prevention devices, and your network firewall to prevent command-and-control server communication among endpoints whenever possible, limiting lateral movement, as well as other attack activities.
 
  • Check your perimeter firewall and proxy to restrict unnecessary access to services, including access to services through non-standard ports.
 
  • Practice good credential hygiene. Limit the use of accounts with local or domain admin level privileges.

0 comments:

Post a Comment

Twitter Facebook Favorites More