Trojan:MSIL/WebShell.BP represents a sophisticated backdoor component designed to provide attackers with persistent remote access to compromised web servers and application servers. Written in Microsoft Intermediate Language (MSIL), this threat typically targets ASP.NET-based web applications and IIS servers, allowing threat actors to execute arbitrary commands, upload additional malicious payloads, and exfiltrate sensitive data from the infected system. While primarily a server-side threat, home users running local development environments or small business servers are increasingly vulnerable as attacks against smaller targets have grown more common.
This webshell variant belongs to a family of MSIL-compiled backdoors that leverage the .NET framework to maintain a low profile while providing extensive system access. The modular nature of webshells means that an infected server becomes a foothold for broader network compromise, data theft, or additional malware deployment.
Threat Profile
| Attribute | Details |
|---|---|
| Threat Classification | Backdoor / Webshell / Remote Access Tool |
| Family | MSIL/WebShell (multiple variants within the BP cluster) |
| Platform | Windows servers running IIS with ASP.NET; requires .NET Framework |
| Target Environment | Web servers, application servers, development machines with IIS/ASP.NET |
| Typical File Extensions | .aspx, .ashx, .asmx (disguised as legitimate web pages) |
| Distribution Methods | Exploitation of web vulnerabilities, compromised FTP credentials, SQL injection follow-up |
| Persistence Mechanism | Deployed within legitimate web directories; relies on web server uptime for availability |
| Primary Capabilities | Command execution, file upload/download, database access, lateral movement support |
| Communication Method | HTTP/HTTPS POST requests to the webshell URL; typically password-protected |
| Common Artifacts | Suspicious .aspx files in web roots, unusual IIS log entries, obfuscated MSIL code |
| Detection Evasion | Code obfuscation, timestamp manipulation, legitimate-looking filenames |
| Removal Difficulty | Moderate—requires careful file analysis and log review to identify all components |
How It Spreads
Trojan:MSIL/WebShell.BP reaches servers through active exploitation rather than the social engineering tactics used against typical end users. Attackers scan the internet for vulnerable web applications, unpatched content management systems, or servers with weak authentication controls. Once they identify a weakness—whether it's an SQL injection point, an outdated DNN installation, or exposed FTP credentials—they upload the webshell file directly into a web-accessible directory on the target server.
Small business owners running their own web servers are particularly vulnerable because they may lack dedicated security staff to monitor for intrusion attempts. A business website hosted on a local server in the office, or a development machine that's accidentally exposed to the internet, can become an entry point. Home users who run personal web servers for hobbies or learning purposes also fall into this risk category if proper hardening hasn't been applied.
Common infection vectors include:
- Web application vulnerabilities — Unpatched CMS platforms (WordPress, DotNetNuke, SharePoint) with file upload or remote code execution flaws
- Compromised credentials — Stolen or weak FTP, SSH, or RDP passwords that allow direct file upload to web directories
- SQL injection attacks — Using database vulnerabilities to write files directly to the web server filesystem via
xp_cmdshellor similar functions - Supply chain compromise — Infected website templates, plugins, or themes downloaded from untrusted sources
- Lateral movement — After initial compromise of one system on a network, attackers deploy webshells to additional servers for redundancy
- Insider threats — Disgruntled employees or contractors with legitimate access deliberately planting backdoors
What It Does On Your Machine
Once installed on a web server, Trojan:MSIL/WebShell.BP functions as a hidden control panel accessible only to the attacker through a web browser. The webshell typically presents a password-protected interface that looks nothing like normal website content—instead displaying file managers, command prompt interfaces, database query tools, and network scanning utilities. The attacker accesses this interface by navigating to the specific URL where the webshell was planted, such as https://yoursite.com/images/cache/system.aspx, which to casual observers appears to be a legitimate system file.
The primary function of this webshell is command execution. Through the interface, attackers can run PowerShell scripts, execute system commands, enumerate user accounts, dump password hashes from memory, and install additional tools. They can browse the entire filesystem—reading configuration files that contain database credentials, accessing customer data, or examining email archives. File upload and download capabilities mean they can exfiltrate gigabytes of sensitive information or bring in specialized hacking tools like Mimikatz for credential harvesting.
Many webshell variants in this family include database management interfaces that allow direct SQL queries against any database the web application can reach. For an e-commerce site, this means credit card data. For a medical practice management system, patient records. For a small business, client lists and financial information. The webshell essentially grants the same level of access the legitimate web application has—but with no logging, no audit trail, and no business logic controls to prevent abuse.
Network reconnaissance is another common capability. Attackers use the compromised server as a pivot point to scan internal networks, identify additional vulnerable systems, and map out the environment before launching broader attacks. For businesses, this means a simple website compromise can become the entry point for ransomware that spreads to every computer and server on the office network.
Manual Removal — Step by Step
Isolate the Infected Server Immediately
Disconnect the server from your network by unplugging the network cable or disabling the network adapter. If this is a production web server, understand that taking it offline will interrupt business operations—but leaving it online allows active data theft and network spread. For critical systems, consider failover to a backup while you remediate. Do not simply block the webshell URL at the firewall; attackers may have planted multiple backdoors.
Document the Compromise for Investigation
Before making changes, capture IIS logs from C:\inetpub\logs\LogFiles\, particularly focusing on POST requests to unusual .aspx files. Screenshot any suspicious files you discover. Note the timestamps of modifications to files in your web directories. This documentation is critical for understanding the scope of compromise and may be needed for insurance claims, legal requirements, or law enforcement if customer data was exposed. Copy these logs to external media before proceeding.
Boot Into Safe Mode or Use Recovery Environment
Restart the server and press F8 during boot to access the Advanced Boot Options menu, then select Safe Mode with Networking. For Windows Server 2016 and later, you may need to use the Settings app to access recovery options. Safe Mode prevents IIS and most web services from starting, which stops the webshell from being actively accessible while you work. If the server is severely compromised, consider booting from a Windows PE environment or mounting the drive in a clean system.
Identify and Quarantine Webshell Files
Navigate to your web root directory (typically C:\inetpub\wwwroot\) and examine all .aspx, .ashx, and .asmx files. Look for files with suspicious names (random characters, system-sounding names in unusual locations like cache.aspx in an images folder), recent modification dates that don't match your deployment schedule, or files you didn't create. Move suspicious files to a quarantine folder outside the web root rather than deleting immediately—you may need them for forensic analysis. Check subdirectories thoroughly, especially upload folders, admin directories, and temporary cache folders.
Search for Additional Persistence Mechanisms
Webshell attackers often plant multiple backdoors for redundancy. Use Windows Search or the command prompt to find recently modified .aspx files across the entire system drive: open Command Prompt as Administrator and run forfiles /P C:\inetpub /S /M *.aspx /D -30 /C "cmd /c echo @path @fdate @ftime" to list all .aspx files modified in the last 30 days. Review the bin directory for unexpected DLL files. Check for scheduled tasks that might recreate the webshell by opening Task Scheduler and examining tasks created around the time of compromise.
Remove the Initial Entry Point
Determine how the attacker gained access originally—review your web application for known vulnerabilities, check FTP/RDP logs for unauthorized access, examine database logs for SQL injection attempts. If you're running a CMS, ensure all components are updated to the latest security patches. Change all passwords associated with the server: FTP accounts, database credentials, CMS admin accounts, and Windows user accounts. Assume that any password stored in configuration files the attacker could access has been compromised.
Run Comprehensive Antimalware Scans
Install and run Malwarebytes (business edition for servers) and Microsoft Defender Offline scan. These tools may not detect every webshell variant, especially obfuscated ones, but they'll catch common secondary payloads and provide an additional verification layer. Run a full system scan, not just a quick scan. For servers, consider using specialized webshell detection tools like Nepstech CDIR, Microsoft's Azure Security Center (if applicable), or YARA rules designed for webshell hunting.
Restore from Clean Backup If Available
If you maintain regular backups of your web application and can verify that a backup predates the compromise (check your IIS logs for the earliest suspicious activity), the safest remediation is to wipe the web directories and restore from that clean backup. After restoration, immediately apply all security updates before bringing the server back online. This approach eliminates the risk of missing hidden backdoors that manual removal might overlook. Verify backup integrity before restoring to ensure the backup itself wasn't compromised.
Harden the Server Before Reconnecting
Before bringing the server back online, implement security improvements: enable Windows Firewall with strict rules, install a web application firewall (WAF), disable unnecessary IIS modules, remove write permissions from web directories where they're not required, enable request filtering to block suspicious patterns, and implement file integrity monitoring that alerts on unauthorized changes to web files. Review and minimize the privileges of the IIS application pool identity account.
Monitor Intensively After Restoration
For at least two weeks after remediation, review IIS logs daily for suspicious patterns—POST requests to unusual files, access from unexpected IP addresses, unusual traffic volumes. Monitor system resource usage for unexpected CPU or network activity. Set up alerts for file modifications in your web directories. Consider implementing a SIEM solution or at minimum enable Windows Event Forwarding to collect security logs centrally. If you detect any signs of reinfection, the server likely needs to be rebuilt from scratch rather than attempting further remediation.
Prevention
- Keep all server software current with security patches — Subscribe to security bulletins for your web platform (IIS, ASP.NET, any CMS you use) and apply updates within 48 hours of release for critical vulnerabilities. Enable automatic updates for the Windows Server operating system and the .NET Framework.
- Implement strong authentication and minimal permissions — Use complex passwords or certificate-based authentication for all server access (FTP, RDP, web admin panels). Follow the principle of least privilege: the IIS application pool should run under a service account with minimal permissions, not as SYSTEM or an administrator account. Disable FTP entirely if you can deploy via more secure methods like FTPS or SFTP.
- Deploy a web application firewall and intrusion detection — A WAF like ModSecurity or a cloud-based service can block common attack patterns (SQL injection, directory traversal, command injection) before they reach your application. Pair this with host-based intrusion detection that monitors file integrity and alerts on unexpected changes to your web directories.
- Regularly audit your web directories for unauthorized files — Implement a weekly manual review or automated scanning of your web root looking for new .aspx files, especially those with suspicious names or locations. Maintain a whitelist of known-good files and investigate any deviations. Use tools like Tripwire or AIDE for file integrity monitoring on Linux servers, or configure Windows File Screening for Windows environments.
- Restrict write access to web directories — Your web application should not need write permissions to most of its own directory structure. Configure IIS and NTFS permissions so that only specific upload or cache directories have write access, and never allow uploaded files to be executable. Implement upload validation that checks file extensions and MIME types, and store uploaded content outside the web root when possible.
- Segment your network properly — Web servers should be in a DMZ with strict firewall rules that only allow necessary inbound traffic (HTTP/HTTPS) and prevent the server from initiating arbitrary outbound connections. If your web server is compromised, network segmentation limits the attacker's ability to pivot to internal systems containing employee computers or database servers.
- Enable comprehensive logging and review it regularly — Configure IIS to log all requests including POST data (be mindful of privacy regulations). Centralize these logs to a separate system so attackers can't delete evidence if they compromise the web server. Use log analysis tools to identify anomalous patterns—unusual user agents, unexpected geographic sources, POST requests to files that shouldn't receive them.
- Consider professional managed security for business-critical servers — If your business depends on web services but you lack in-house security expertise, managed detection and response (MDR) services provide 24/7 monitoring, threat hunting, and incident response capabilities. The cost of professional monitoring is typically far less than the business impact of a successful breach involving customer data theft or extended downtime.
Bring It In
Server compromises demand expertise that goes beyond typical malware removal. Webshells provide sophisticated attackers with extensive access to your data and network, and incomplete remediation leaves backdoors that can be exploited months later. Computer Repair Roswell has handled server intrusions for Roswell businesses ranging from dental practices to engineering firms—we understand the urgency of restoring operations while ensuring the threat is completely eliminated.
Our technicians will perform thorough forensic analysis to determine the scope of the compromise, identify all planted backdoors, assess what data may have been accessed, and rebuild your security posture to prevent recurrence. We work with your schedule to minimize downtime, and we can coordinate with your web hosting provider or ISP if needed. Call us at (770) 710-9166 or bring your server to 1750 Hembree Road, Roswell, GA 30076. For business-critical systems, we offer emergency after-hours service—because every hour an active webshell remains on your server puts your data and your customers at greater risk.