ScanTitan’s incident response team analyzes suspicious PHP, JavaScript and .htaccess code from your site, decodes every layer of obfuscation, and traces the payload, the injection method and the persistence mechanism, so cleanup removes the backdoor that would otherwise let the infection return.
MITRE ATT&CK tracks web shells as T1505.003
Obfuscated code is catalogued as T1027, decoding as T1140
No plugin or server agent needed for the scan that flags the files
NSA and ASD issued joint web shell guidance on 22 April 2020
A malware code analyzer reads suspicious source code and works out what it does without running it. For website malware, that means decoding obfuscated PHP, JavaScript and .htaccess rules until the payload, the injection method and the persistence mechanism are visible. A signature scanner tells you a file looks wrong. A code analyzer tells you what the file does, how it got there and what else the attacker left behind, which is the information a cleanup needs before anyone deletes anything.
Website malware is mostly text. Attackers write it in PHP and JavaScript, then wrap it in encoding so a search for the word eval finds nothing. The NSA and the Australian Signals Directorate (ASD) warned in their April 2020 joint guidance on web shell malware that web shells continue to evade many security tools, and that attackers often create them by adding or modifying a file in an existing web application. A clean-looking file in a real plugin folder is exactly what that sentence describes.
Tools built for Windows malware, such as Ghidra and x64dbg, read compiled binaries. A WordPress backdoor is usually a short text file, and it needs a different method: read it, peel the layers, follow what it does. If you run a store or an agency site without a security team, nobody on staff has time to decode a 4,000-character base64 string at 2 a.m. That is the work this page describes.
Six stages take a flagged file from “something looks wrong” to a documented finding that a cleanup can act on. Analysts read the code. They do not run it on your production server.
The external scan identifies where infections sit. With SFTP or cPanel access, analysts then document every infected file before touching it and pull the neighbors too, because attackers rarely drop a single file.
Base64, gzinflate, ROT13 style encodings and character-by-character string building are reversible, so analysts reverse them in order and record what each layer produced.
It shows what the code accepts (a POST field, a cookie, a user-agent string), what it fetches, what it writes to disk and which functions it calls.
A decoded loader that resembles a documented web shell gets the same label that MITRE ATT&CK and threat reports use, which makes the finding searchable and comparable.
Analysts look for the vulnerable plugin or stolen credential that let the file in, then for second copies, modified core files, rogue admin accounts and database-stored payloads that would restore the infection.
Every finding carries the file path, line number and code snippet, plus the decoded behavior and the fix, so the cleanup is targeted instead of a guess.
A fintech shipping a REST API imported its OpenAPI spec and, on the first authenticated scan, found a BOLA flaw on the /accounts/{id} endpoint that returned any user’s balance by changing the ID. Fixed and re-verified in a day, before any bug bounty report.
Analysis reads what is on disk or in the database. Most website malware is built from standard, reversible encodings, so most of it opens up. Some of it does not, and a page that pretended otherwise would be wasting your time.
Request volume, deep enumeration sends a large number of requests, so ScanTitan rate-limits it and lets you schedule it off-peak. You can allowlist our scan sources and lower the rate if your host is strict.
Analysis ends with a fix list in the order that matters: remove the persistence first, then the loader, then close the entry point. Scan again after cleanup. A clean result on the same files is the evidence that the backdoor is gone, and a repeat finding in the same folder tells you that something still writes it back.
Obfuscation means rewriting code so it behaves the same but reads as noise. MITRE ATT&CK catalogues the practice as T1027, Obfuscated Files or Information, and the reverse step as T1140, Deobfuscate/Decode Files or Information. Attackers use it for one reason: each layer defeats a plain string match. A rule that looks for eval misses a file that builds the word from pieces.
| Technique | What it looks like | What the analysis recovers |
|---|---|---|
| Encoded eval | A call to eval wrapped around a base64 decode of one long string | The decoded PHP source and its first action |
| Layered decode chain | Several decode and decompress calls nested inside each other | Each layer in order, down to the readable payload |
| Character building | Function names assembled from character codes or split strings | The real function name the attacker hides |
| Variable functions | A string stored in a variable, then called like a function | The call target after the variable is resolved |
| Packed JavaScript | atob() or String.fromCharCode() feeding an eval | The external script URL or skimmer loader |
| Conditional .htaccess rules | Rewrite conditions on user agent, referrer or device | The redirect target and the audience it filters for |
| Database-stored payloads | Encoded values in the options table loaded by a small stub | The stub and the stored payload together |
A worked example shows why one layer is never the whole story. The code below is an illustrative sample with a placeholder string, not live malware.
Layer 0: what the file contains
<?php eval(gzinflate(base64_decode('PLACEHOLDER-ENCODED-STRING'))); ?>
Layer 1: after base64 decode and gzinflate
$a = 'ba'.'se64_'.'decode';
eval($a($_POST['x']));
Layer 2: what it means
The file runs any PHP the attacker sends in the POST field named x.Layer 0 hides everything. Layer 1 shows the real mechanism, and it is two lines. Layer 2 is the finding: a remote control for your server that costs the attacker one HTTP request per command. That one-line pattern is common because it is tiny, and tiny files hide well in a folder of hundreds.
MITRE defines a web shell as a script placed on an openly accessible web server that gives an adversary access to the server as a gateway into a network. Some come with a client program: the China Chopper web shell has a small server component and a separate client that talks to it. The same page records APT28 using a modified and obfuscated version of the reGeorg web shell to keep persistence on an Outlook Web Access server. Web shells are a persistence tool for serious attackers and a staple of ordinary site compromises alike.
The backdoor is the part that survives a surface cleanup. Remove the visible redirect, leave the shell, and the attacker returns the same week. That is why the analysis hunts for the shell before it touches anything else.
The code, the configuration and the database, not just one file type.
Analysts decode PHP loaders, injected functions in theme and plugin files, and modified core files. A webshell is a script that gives an attacker remote control of the server. The finding names the file, the line, the decoded behavior and the account or plugin that probably let it in.
Malicious JavaScript sits in theme files, injected script tags and encoded loaders. Skimmers that copy payment form data and scripts that redirect only mobile visitors are the common cases. The analysis recovers the external domain the script talks to, which is the detail a blocklist request needs.
Attackers write conditional rewrite rules that redirect visitors arriving from search engines or on mobile devices and show administrators a normal site. Analysts read the conditions, record the redirect target and check for PHP configuration directives that load attacker code before every request.
Encoded payloads, injected script tags in posts and options, and unfamiliar administrator accounts live in the database, where file scanners never look. Analysts examine the WordPress options table and post content for stored loaders and compare user lists against what the site owner expects.
PHP files in media folders, directories with random names and copies of the same shell under different file names are the usual pattern. Analysts map every executable file in places that should only hold media, so one deleted shell does not hide five more.
Cracked premium themes and plugins arrive with backdoors built in. Analysts compare installed code against the vendor's published version and flag differences, which also shows whether a vulnerable plugin was the entry point. A website vulnerability scan finds the known flaw, and the code analysis shows what the attacker did with it.
Decoding gives you readable text. These three methods turn it into a classification you can act on and compare with public threat reporting.
YARA is a tool that helps malware researchers identify and classify samples by pattern. A rule is a set of strings plus a boolean condition, and a file matches when the condition holds. Analysts use pattern rules to confirm that a decoded loader belongs to a known family and to find other files on your site that share the same pattern.
Entropy is a measure of randomness, scored from 0 to 8 bits per byte. Encoded and compressed text looks far more random than ordinary PHP, so an unusually high score in a text file is a reason to read it. Entropy cannot prove malice. It tells analysts which of two thousand files to open first.
Findings are labeled with ATT&CK technique IDs such as T1505.003 for web shells and T1027 for obfuscation. A shared label lets your host, your insurer or your own developer look up what the technique means without reading our notes.
Built for two readers: the developer who removes the files and the owner who has to explain what happened to customers.
Lists every flagged file with its path, size, modification date and status.
Shows the readable version of each obfuscated file, with the layers listed in order.
Explains what the code accepts, what it fetches, what it writes and which attack technique it maps to.
Names the likely way in, plus every second copy, account or scheduled task that would bring the infection back.
Sending code from a compromised site to a third party raises fair questions. Here are the answers that apply before you connect anything.
SFTP or cPanel access is needed only during the cleanup phase. It is a one-time, scoped connection that your team controls, and the external scan that flags the files needs no access at all.
Analysis is reading, not execution. Analysts decode and inspect the code and do not run it on your production site.
Analysts document every infected file before changing it, so you keep a record of the original state. That record is what makes a cleanup reviewable later.
Compromised credentials for admin accounts, FTP and the database are reset as part of cleanup, because an attacker who stole a password does not need the backdoor at all.
ScanTitan is headquartered in the Netherlands. Incident response data handling is built to meet GDPR Article 32, which matters for any site that stores personal data.
Findings are reviewed by a credentialed security professional, listed at the bottom of this page. You are not reading the output of a black box.
Analysis explains an infection. It does not remove one. The report hands off to cleanup, and three different tools sometimes get confused for each other.
Reads website code, decodes it, and explains the behavior. It fits when you have a suspicious PHP, JavaScript or .htaccess file and need to know what it does and what else it touched. It is the fast, practical choice for website owners and developers.
Runs a sample in an isolated environment and records what it does. Sandboxes are strong for Windows executables and documents, where behavior is the clearest signal. They are a weaker fit for a PHP file that only does something when an attacker sends it a request.
An analyst takes a compiled binary apart with a disassembler such as Ghidra. It is slow and expensive, and it is the right tool for ransomware families and custom implants. Most website infections never need it.
All of these are legitimate tools, built for different jobs. The table records what each vendor’s own pages describe, not an opinion of the tools. Most of them are built for compiled malware, which is a different problem from website code.
| Feature | ScanTitan | Joe Sandbox Cloud Basic | CIS MCAP | Malware-Analyzer (GitHub) |
|---|---|---|---|---|
| Primary input | PHP, JavaScript, .htaccess and database content from websites | Windows, macOS and Linux files, plus URLs | Executables, DLLs, documents, other files and URLs | Windows PE, Linux ELF and Android APK files |
| Website source code analysis (PHP, .htaccess) | ✓ | Not documented | Not documented | Not documented |
| Analysis method | Static analysis by analysts | Dynamic sandbox with code analysis options | Cisco Secure Malware Analytics sandbox | Static analysis with YARA, entropy and AI summaries |
| Who can use it | Any site owner, developer or agency | Free tier is non-commercial and results are public | Only MS-ISAC U.S. state, local, tribal and territorial members | Anyone, self-hosted under the MIT license |
| Evidence in the report | File path, line number, code snippet, decoded payload | Detailed analysis reports | Dropped files, registry changes, persistence, network callouts | Verdict, entropy, imports, YARA matches |
| Cleanup after analysis | ✓ | Not documented | Not documented | Not documented |
| Entry point | Free malware scan | Free tier, 15 analyses per month | Membership application | Clone the repository and run it locally |
How to read this table: ✓ means the capability is described on the vendor's own page. Not documented means we found no description of it in the sources below at the time of review. It is not a claim that the tool cannot do it.
Sources reviewed 6 October 2026: the Joe Sandbox Cloud Basic submission page, the CIS Malicious Code Analysis Platform page, and the Malware-Analyzer repository README on GitHub. Next scheduled review: January 2027. Spotted something out of date? Tell us and we will correct it.
A malware code analyzer is a tool or service that reads suspicious source code to work out what it does, without running it on the target system. For website malware it decodes obfuscated PHP, JavaScript and .htaccess files, then identifies the payload, how the code got onto the site and how it stays there. The result is a documented explanation of the file, not just a yes or no flag.
A scanner checks files and responses against known signatures and behavior patterns and reports where an infection sits. A code analyzer takes a flagged or suspicious file and explains it. You normally need both: the website malware scan finds the problem, and the code analysis explains how deep it goes and what to remove.
Yes. Encoded eval chains, nested decode and decompress calls, character-code string building and split function names are all reversible, so analysts peel each layer in order and record the result. Obfuscation slows a reader down but does not hide the logic from someone who decodes it step by step. The limits are payloads fetched from servers that are offline and code encrypted with a key the attacker supplies at request time.
No. Analysts read and decode the code and do not run it on your production site. Static reading is the safer first step for website malware, because a PHP webshell executes whatever an attacker sends it. Behavior is inferred from the decoded code and the file changes around it, and the report states which findings are confirmed and which are inferred.
Payloads that a loader downloads from a remote server that has since been taken down cannot be read. The same goes for code encrypted with a key held only by the attacker, fileless code that never reaches the disk and files the analysts are not given access to. Compiled binaries dropped on the host need dedicated reverse engineering. The report names these gaps instead of guessing.
No plugin is needed for the external scan that flags the infected files. The code analysis itself needs the files, so SFTP or cPanel access is used during the cleanup phase. It is a one-time, scoped connection that your team controls and can end when the work is done.
No. Reverse engineering Windows malware means taking compiled executables apart with tools such as Ghidra or x64dbg, and it is a specialist job. Website malware is mostly readable text under a layer of encoding. Malware code analysis for websites is closer to reading and decoding than to disassembly. If your sample is a Windows executable or ransomware binary, a malware sandbox or a reverse engineer is the better fit.
The report goes into the cleanup. Persistence goes first, then the loader, then the entry point, with credentials reset and the vulnerable component patched. After that, a firewall and monitoring reduce the chance of a repeat. The website malware removal hub explains the full sequence from detection to blocklist delisting.
ScanTitan flags infected files from outside, then analysts decode the suspicious ones, trace the entry point and hand the cleanup a list that includes the backdoor. Start with a free malware scan.
CISSP · GXPN · GCIH · GWAPT · CISA · CEH · EnCE · ISO 27001 Lead Auditor · COBIT 5 · 12+ years in information security. Author profile →