Unknown PHP files, shells that return after deletion, casino or betting snippets in Google, unexpected redirects, unusual CPU load and unfamiliar administrator accounts do not automatically share the same root cause. This guide separates symptoms from evidence and correlates the filesystem, application, database, hosting accounts and access logs on one incident timeline.
If compromise is still active, do not start by deleting everything. Limit impact and preserve evidence first. Export a full file copy, database dump and available web/WAF/panel logs before timestamps or rotated records are lost.
Avoid uncontrolled testing on production. Quarantine suspicious files, validate a clean copy in staging, rotate hosting, FTP/SFTP, SSH, database and CMS credentials, revoke unknown sessions and enable MFA where available.
Unexpected .php or .phtml files, executable scripts under uploads, repeated changes to .htaccess or .user.ini, reappearing files, unknown cron jobs, new admin users and unexplained outbound links are high-value investigation signals.
A site can look normal in your browser and still be compromised. Conditional code may react only to a specific referrer, user agent, cookie, device or crawler. Microsoft documented cookie-controlled PHP webshell tradecraft in Linux hosting environments in April 2026.
Do not delete files based on a single keyword. Functions such as eval, base64_decode, gzinflate, shell_exec, system, exec, passthru and proc_open also appear in legitimate software. Risk increases when they are combined with external input, heavy obfuscation, a recent modification and an unexpected path.
Review recently changed PHP files, executable content under upload/cache/tmp directories, double extensions, misleading image-like filenames, file ownership and permissions. Record hashes and timestamps so findings can be correlated with requests later.
find public_html -type f -name "*.php" -mtime -7 -printfind public_html -type f -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -100find public_html -path "*/uploads/*" -type f \( -name "*.php" -o -name "*.phtml" \) -printgrep -RInE "eval\s*\(|base64_decode\s*\(|gzinflate\s*\(|shell_exec\s*\(" public_html --include="*.php"Reappearance usually means the persistence mechanism was not removed. Cron, scheduled hosting tasks, .user.ini auto_prepend_file, rewrite rules, a malicious plugin, database-stored payload or a second backdoor can recreate the visible file.
Microsoft’s 2026 hosting research describes incidents where scheduled jobs recreated removed PHP loaders. “The shell file is gone” and “the incident is remediated” are therefore different statements.
crontab -lfind /home \( -name .user.ini -o -name .htaccess \) 2>/dev/nullgrep -RIn "auto_prepend_file\|auto_append_file" /home 2>/dev/nullfind public_html -type f -mmin -180 -lsGoogle classifies unauthorized content injection, hidden links, cloaking and malicious redirects as hacked content patterns. A redirect may occur only when users arrive from search or from a specific device while a direct visit appears normal.
Use site: queries as a quick visibility check, but do not treat search results alone as malware proof. Correlate Search Console Security Issues, URL Inspection, sitemaps, canonicals, HTTP responses and actual source output.
site:alanadi.com casinosite:alanadi.com betsite:alanadi.com slotsite:alanadi.com viagraNot every intrusion starts with an application exploit. Stolen FTP credentials, password reuse, session theft or a compromised administrator workstation can produce the same file changes. Compare panel/account activity with the file timeline.
After password rotation, revoke old sessions and unknown API tokens or SSH keys. If multiple sites share accounts or credentials on the same server, check them for cross-impact.
Hacked links and spam do not always live in a physical PHP file. CMS options, widgets, post metadata, theme settings and custom tables can inject HTML or JavaScript dynamically.
Take a database dump before bulk searching or replacing values. Review suspicious domains, spam terms, iframe/script fragments and newly created privileged users. Database structure differs across WordPress, OpenCart, Laravel and custom PHP applications, so there is no safe one-query cleanup.
Start with the approximate creation or modification time of a suspicious file. Inspect a narrow time window around it for POST/PUT requests, upload endpoints, successful status codes and follow-up requests to the newly created script.
An IP address in a log is a technical indicator, not proof of a person’s identity. VPNs, CDNs, proxies, botnets and compromised hosts can sit in between. Attribute the event using multiple signals: time, URL, method, account activity and file changes.
Avoid global string replacement across all PHP files, deleting logs, running unbacked SQL replacements on production, or removing only the visible shell while leaving credentials and persistence untouched.
When a clean upstream release or version-controlled repository exists, compare against it. Custom applications benefit from file-level diffs and controlled functional tests to avoid breaking legitimate code while removing malicious changes.
Depending on scope, the review can use a ZIP/site backup, SQL dump, cPanel/Plesk logs, Search Console evidence or explicitly authorized SSH access. Static file review, recent changes, persistence, spam URL behavior, log timelines and application controls are assessed together.
After cleanup, controlled validation is performed only on an authorized copy or staging environment. The report separates discovered artifacts, likely entry points, residual risks and hardening actions. Search-engine reindexing is documented as a separate process from technical file cleanup.
This tool runs in your browser and does not send your selections to the server. It does not replace a professional review.
Standard cases are usually scheduled for a 24–72 hour analysis window after pre-assessment. Timing varies with file count, log access, malware spread and application architecture.
Important note: Only test systems you own or are explicitly authorized to assess.
No. If cron, another backdoor, a stolen account or the original application flaw remains, the file can return.
Yes. Cloaking and cookie/header-controlled logic can stay dormant for ordinary visits.
No. Content may come from the database, routing, rewrite rules or conditional crawler output.
Logs can reveal incident-related source IPs, but an IP does not prove the real person behind it.
No. Start with the symptom, platform, backup status and sample logs or screenshots.
No. It is a planning window; scope is confirmed after pre-assessment.