Trojan:MSIL/WebShell.BS represents a dangerous category of server-side malware that infiltrates web applications and web servers, establishing a backdoor that grants attackers persistent remote access and control. Written in Microsoft Intermediate Language (MSIL) — the bytecode used by .NET Framework applications — this webshell trojan targets Windows-based web servers running ASP.NET applications, though end-user machines can become compromised when attackers use stolen credentials or vulnerabilities to deploy the shell through legitimate access points. While primarily a server threat, home users running local web development environments, small business owners managing their own websites, and anyone with administrative access to compromised web applications may find this malware installed on their systems.
Unlike traditional malware that spreads through email attachments or malicious downloads, webshells are typically planted by attackers who have already gained some level of access to a web server or application. Once installed, Trojan:MSIL/WebShell.BS operates as a malicious web-based interface — essentially a control panel hidden within your server's file structure — that allows attackers to execute commands, upload additional malware, steal data, modify website content, and pivot to other systems on your network. The MSIL implementation makes it particularly insidious because it runs within the .NET Framework that many Windows servers already have installed, requiring no additional runtime dependencies and blending seamlessly with legitimate ASP.NET applications.
Threat Profile
| Attribute | Details |
|---|---|
| Threat Type | Webshell Trojan / Backdoor |
| Family | WebShell (MSIL variant) |
| Aliases | MSIL/WebShell.BS, Backdoor:MSIL/WebShell, ASPXShell variant |
| Platform | Windows servers running IIS with .NET Framework; any Windows system with ASP.NET development tools |
| Target Environment | Web application directories (wwwroot, virtual directories), temporary ASP.NET compilation folders |
| Primary Distribution | Exploitation of web application vulnerabilities, compromised FTP/RDP credentials, SQL injection attacks, insecure file upload forms |
| Persistence Mechanism | File placement in web-accessible directories; may create scheduled tasks or modify web.config files for auto-loading |
| Capabilities | Remote command execution, file upload/download, database access, privilege escalation, lateral movement, additional payload deployment |
| Network Behavior | Listens on standard web ports (80/443); communicates via HTTP/HTTPS POST requests disguised as legitimate traffic |
| Typical Artifacts | .aspx, .ashx, or .asmx files with obfuscated code; unusual entries in IIS logs; temp folder executables |
| Data at Risk | Website databases, customer information, credentials, server configuration files, connected network resources |
| Removal Difficulty | Moderate to High — requires identifying all deployed files, closing the initial access vector, and verifying no secondary infections |
How It Spreads
Trojan:MSIL/WebShell.BS doesn't spread like traditional malware through infected email attachments or drive-by downloads. Instead, it's actively deployed by attackers who have gained unauthorized access to a web server or application. The most common entry point is through vulnerable web applications that haven't been properly secured or updated. An attacker might exploit an SQL injection vulnerability in a customer portal, leverage a cross-site scripting weakness in a content management system, or take advantage of an insecure file upload function that doesn't properly validate uploaded file types. Once they can upload a file to the web server, they plant the webshell disguised as a legitimate ASP.NET page.
Compromised credentials represent another major distribution vector. If an attacker obtains FTP credentials through a phishing campaign, finds default passwords on a web hosting control panel, or cracks weak Remote Desktop Protocol (RDP) passwords, they can directly upload the webshell to the server's web directory. Small businesses that reuse passwords across multiple services or maintain shared credentials among staff members are particularly vulnerable to this approach. The webshell may also be delivered as part of a larger attack chain, where initial access malware on an administrator's workstation harvests credentials that are then used to compromise the organization's web server.
Common distribution vectors include:
- Vulnerable web applications — Outdated WordPress, Joomla, DotNetNuke, or custom ASP.NET applications with unpatched security flaws
- Insecure file upload forms — Contact forms, image galleries, or document management systems that don't properly validate file extensions or content
- SQL injection attacks — Database vulnerabilities that allow attackers to execute commands and write files to the web server
- Compromised FTP/SFTP credentials — Stolen through phishing, keyloggers, or credential stuffing attacks against weak passwords
- Remote Desktop Protocol (RDP) exploitation — Brute force attacks or exploitation of exposed RDP services with weak authentication
- Supply chain attacks — Compromised third-party plugins, themes, or modules that include embedded webshells
- Server misconfigurations — Overly permissive directory permissions, disabled security features, or exposed admin panels
What It Does On Your Machine
Once deployed, Trojan:MSIL/WebShell.BS establishes itself as a malicious web page within your server's application structure. The webshell typically masquerades as a legitimate ASP.NET file with an innocuous name like "error.aspx", "default1.aspx", or "upload.ashx" — something that won't immediately stand out in a directory listing. When the attacker accesses this page through a web browser, they're presented with a command interface that allows them to interact with the server's file system, execute system commands, and perform administrative functions. Because the webshell runs under the permissions of the web application pool (often with elevated privileges), attackers can perform actions that normal users cannot.
The trojan's capabilities extend well beyond simple file browsing. Attackers use it to enumerate database connections stored in web.config files, harvest credentials from configuration files, and execute SQL queries against connected databases. They can upload additional malicious tools — such as privilege escalation exploits, network scanners, or ransomware payloads — and execute them on the server. The webshell may include features for process management, allowing attackers to view running processes, inject code into legitimate processes, or terminate security software. Some variants include built-in reverse shell capabilities that establish encrypted outbound connections to attacker-controlled servers, bypassing firewall rules that block inbound connections.
From a network perspective, the webshell communicates using standard HTTP or HTTPS protocols on the same ports your legitimate web traffic uses, making it extremely difficult to detect through network monitoring alone. The malicious traffic blends in with normal website activity — it appears in your IIS logs as POST requests to what looks like a valid page. Attackers often access the webshell through proxy services or VPN connections to obscure their true IP addresses. The shell may be configured to require authentication (a password or token known only to the attacker) to prevent discovery by security scanners or curious administrators who stumble upon the file.
Beyond the immediate server compromise, webshells serve as a beachhead for broader network intrusion. Attackers use them to map internal networks, identify connected systems, steal domain credentials from memory, and pivot to other machines on your network. For small businesses, this might mean the attacker moves from the web server to file servers, backup systems, or workstations. They may modify website content to inject malicious scripts that attack your visitors (watering hole attacks), redirect customers to phishing pages, or silently harvest submitted data like credit card numbers and login credentials.
Manual Removal — Step by Step
Disconnect the Server from the Network
Immediately isolate the compromised system by disconnecting it from your network and the internet. If this is a production web server, understand that taking it offline will impact your website's availability, but leaving an active webshell connected allows ongoing data theft and potential lateral movement to other systems. Disable network adapters or physically unplug network cables. Document the time of disconnection for incident response purposes.
Stop the IIS Service and Related Processes
Open an elevated Command Prompt (Run as Administrator) and stop Internet Information Services to prevent the webshell from being accessed or executing additional commands. Execute iisreset /stop to halt all IIS services. Also stop the W3SVC service specifically with net stop w3svc. Check Task Manager for any suspicious w3wp.exe processes (the IIS worker process) that remain running after the service stops — these might indicate malicious code that has detached from normal process management.
Create a Complete Backup for Forensic Analysis
Before making any changes, create a full disk image or at minimum copy the entire web root directory structure to an external drive. This preserved evidence may be critical for understanding how the breach occurred, what data was accessed, and for potential legal or insurance purposes. Do not simply copy files to another network location, as this could spread the infection. Use offline storage and clearly label it as potentially compromised material.
Identify and Remove Webshell Files
Search your web directories for suspicious .aspx, .ashx, .asmx, and .asax files that weren't part of your original application deployment. Pay special attention to files with recent modification dates that don't align with your deployment schedule, files in unexpected locations (like image or upload directories), and files with suspicious names. Check the actual content — webshells often contain heavily obfuscated code, base64-encoded strings, or functions for command execution. Delete all identified malicious files, but keep a record of their locations and names.
Check for Additional Persistence Mechanisms
Webshells sometimes establish fallback persistence methods. Open Task Scheduler and review all tasks — look for recently created tasks that execute scripts or executables from web directories. Check the Run and RunOnce registry keys under both HKLM and HKCU for unusual entries. Examine your web.config file for suspicious httpHandlers or httpModules that might auto-load malicious code. Review IIS application pools and virtual directories for unauthorized additions. Remove any persistence mechanisms you discover.
Scan the Entire System with Multiple Security Tools
Even after removing obvious webshell files, run comprehensive scans with reputable anti-malware tools. Use Malwarebytes, ESET Online Scanner, or Microsoft Defender Offline to check for additional payloads the attacker may have deployed. Webshells are often used to download secondary malware like cryptocurrency miners, ransomware, or credential harvesters. Scan all drives, not just the system drive. These tools may detect obfuscated variants or related malware that manual inspection missed.
Review and Analyze IIS Logs
Examine your IIS log files (typically in C:\inetpub\logs\LogFiles\) to understand the scope of the compromise. Look for POST requests to the webshell files, noting source IP addresses and timestamps. This reveals when the webshell was first accessed, how frequently it was used, and potentially what commands were executed. Check for unusual user agents, requests to non-existent files, or repeated access patterns. This information helps determine what data may have been compromised and whether the attacker accessed other systems.
Close the Initial Access Vector
Identify and remediate the vulnerability that allowed the webshell to be uploaded in the first place. If credentials were compromised, immediately change all passwords for FTP, RDP, hosting control panels, and database accounts — use strong, unique passwords. If a vulnerable application was exploited, apply all available security patches or remove the vulnerable component. If an insecure file upload function was the entry point, implement proper file type validation and move upload directories outside the web root. Without closing this door, attackers will simply re-install the webshell.
Consider a Clean Rebuild for Critical Systems
For production servers that contained sensitive data or for situations where you cannot confidently determine the full extent of the compromise, the most secure approach is to rebuild the server from scratch. Deploy the web application from known-good source code, restore databases from clean backups taken before the compromise, and reconfigure the server using hardened security settings. This eliminates any sophisticated rootkits or backdoors that might survive file-level removal. Yes, it's time-consuming, but it provides the highest assurance that the system is truly clean.
Implement Enhanced Monitoring Before Reconnecting
Before bringing the server back online, implement file integrity monitoring to alert you to unauthorized changes to web directories. Enable detailed IIS logging and consider adding a web application firewall (WAF) to filter malicious requests. Set up alerts for suspicious patterns like POST requests to unusual file types or access to newly created .aspx files. Configure your security tools to scan web directories frequently. Only after these protections are in place and you're confident the system is clean should you reconnect it to the network and resume normal operations.
Prevention
- Keep all web applications and frameworks current with security patches. Subscribe to security bulletins for your CMS platform, web framework, and server software. Apply patches promptly — most webshell compromises exploit known vulnerabilities for which patches were available weeks or months before the attack.
- Implement strict file upload controls on all web forms. Validate file extensions both client-side and server-side, verify MIME types against file content (not just the extension), store uploaded files outside the web root when possible, and never trust user-supplied filenames. Use a whitelist approach — only allow specific, necessary file types.
- Apply the principle of least privilege to web application permissions. Your IIS application pool identity should have only the minimum permissions needed to function. Don't run web applications under administrative accounts. Use separate accounts for different applications. Restrict write permissions on web directories to only those folders that absolutely require it.
- Secure all remote access methods with strong authentication. Disable FTP in favor of SFTP or FTPS with key-based authentication. Never expose RDP directly to the internet — use a VPN or Remote Desktop Gateway instead. Implement multi-factor authentication on all administrative access points. Use password managers to generate and store strong, unique passwords for each service.
- Deploy a web application firewall (WAF) with rule sets for common attacks. A properly configured WAF can block SQL injection attempts, malicious file uploads, and known webshell signatures before they reach your application. Both cloud-based (like Cloudflare or Sucuri) and on-premise WAF solutions provide value for protecting web servers.
- Enable comprehensive logging and regularly review logs for anomalies. IIS logs should capture all requests with full details. Configure alerts for unusual patterns — POST requests to files that shouldn't receive them, access to recently created files, or requests from unusual geographic locations. Use a SIEM system or log analysis tool if managing multiple servers.
- Implement file integrity monitoring on web directories. Tools that detect unauthorized file changes can alert you within minutes of a webshell being deployed. Solutions range from simple scheduled scripts that hash files and compare to baselines, to enterprise FIM products with real-time monitoring.
- Conduct regular security assessments and penetration testing. Annual or semi-annual testing by qualified professionals can identify vulnerabilities before attackers do. For smaller operations, automated vulnerability scanners provide a baseline level of assessment, though they shouldn't replace professional testing for systems handling sensitive data.
Bring It In
Webshell infections represent serious security incidents that require specialized knowledge to properly remediate. Unlike simple adware or browser hijackers, these threats indicate that an attacker actively compromised your system and may have accessed sensitive information, installed additional malware, or used your server to attack others. The forensic analysis required to determine the breach timeline, identify stolen data, and ensure complete removal goes beyond standard malware cleanup — it requires examining server logs, analyzing network traffic patterns, and understanding web application security.
Our team at Computer Repair Roswell has extensive experience remediating server compromises and securing web applications against future attacks. We'll thoroughly analyze your system to determine how the breach occurred, what the attacker accessed, and whether additional systems on your network were compromised. More importantly, we'll work with you to implement the security controls necessary to prevent recurrence — whether that means hardening server configurations, securing remote access, or patching application vulnerabilities. Located in Roswell, Georgia, we offer same-day appointments for security emergencies. Call us at (770) 695-6900 or stop by our shop at 1735 Woodstock Road. Don't let attackers maintain their foothold — every hour a webshell remains active is another hour they can steal data or spread to other systems.