web shells and its Challenges in detecting
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—
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.
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