Website Hacking is unauthorized access to a web resource with the purpose of stealing data, inserting malicious content, or disrupting service. Detecting and analyzing a hack is a critical step in restoring security and preventing similar incidents in the future.

Common Signs of Compromise:

• Unauthorized content changes (ads, redirects, spam links)
• Server performance degradation
• Search engine blocking
• Suspicious activity in access logs
• Unexpected server restarts or failures
• Unusual user account behavior

Server Log Analysis

Server logs are a key source of information when investigating a hack. They contain records of all actions performed on the server and can point to specific vulnerabilities or attack vectors.

Website Access Analysis

First, examine the access.log files, which contain information about all requests to the web server:

192.168.1.100 - - [10/Apr/2025:13:55:36 +0200] "GET /wp-admin/install.php HTTP/1.1" 200 1324 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
45.227.255.34 - - [10/Apr/2025:13:58:42 +0200] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 5237 "http://example.com/wp-admin/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
45.227.255.34 - - [10/Apr/2025:13:59:01 +0200] "GET /wp-content/uploads/backdoor.php HTTP/1.1" 200 0 "-" "Mozilla/5.0"

Pay attention to:

• Suspicious IP addresses with multiple requests
• Attempts to access administrative sections (/wp-admin/, /administrator/, /admin/)
• Unusual or non-existent URLs
• Requests to files with suspicious extensions (.php, .aspx, .jsp)
• Large volume of requests in a short time from a single IP address

Server Error Analysis

Error log files (error.log) can contain valuable information about server failures that may have been caused by an attack:

2025/04/10 13:59:15 [error] 31923#31923: *17 FastCGI sent in stderr: "PHP Warning: include(/tmp/backdoor.php): failed to open stream: Permission denied in /var/www/html/index.php on line 23" while reading response header from upstream

Finding Recently Modified Files

One of the most important steps after a site hack is to identify which files were modified and determine who or what initiated these changes. This helps understand which attack vector was used.

1. Search for files modified in recent days

Use the find command to discover which files were modified, for example, in the last 7 days:

find ~/www -type f -mtime -7 -ls | sort -k 8,9

• -type f – search for files only
• -mtime -7 – modified in the last 7 days
• -ls – displays complete file information
• sort -k 8,9 – sorts by date and time

Example result:

1234567 12 -rw-r--r-- 1 www-data www-data 2048 Apr 28 03:22 /www/test/wp-content/themes/twentytwentyone/functions.php
1234568  8 -rw-r--r-- 1 www-data www-data  512 Apr 29 02:14 /www/test/.htaccess

2. Get the exact date and time of file modification

If you found a suspicious file, check its detailed metadata:

stat ~/www/test.com.ua/wp-content/themes/twentytwentyone/functions.php

Example result:

Modify: 2025-04-28 03:22:10.000000000 +0300
Change: 2025-04-28 03:22:11.000000000 +0300
Access: 2025-04-29 08:00:02.000000000 +0300

3. Search for changes during night or unusual hours

It’s also useful to search for changes made during atypical hours:

find ~/www -type f -newermt "2025-04-28 23:00" ! -newermt "2025-04-29 06:00" -ls

• find – Utility for searching files in the file system
• ~/www – Directory to search in (you can specify the full path instead of ~)
• -type f – Limits search to files only (no directories)
• -newermt “2025-04-28 23:00” – Find files modified after the specified time (MT = Modification Time)
• -newermt “2025-04-29 06:00” – Exclude files modified after 06:00 (i.e., find only between 23:00–06:00)
• -ls – Outputs detailed information about each found file (like ls -l)

4. Correlate modified files with HTTP requests

After you’ve identified the exact time of a suspicious file change, check the access log for the same time period to determine which request potentially caused the change.

Search the access log for a time range of ±1 minute from the modification time:

# This command will find all requests made at 03:22 on April 28, 2025, excluding "noise" from static resources
grep "\[28/Apr/2025:03:22" ~/logs/*.access.log | grep -v ".js\|.css\|.jpg\|.gif\|.png"

The following command is useful for identifying HTTP requests to a specific file:

grep "functions.php" ~/logs/*.access.log

Example result:

45.227.255.34 - - [28/Apr/2025:03:22:11 +0300] "POST /wp-content/themes/twentytwentyone/functions.php HTTP/1.1" 200

If your logs are archived in .gz (e.g., access.log.1.gz, access.log.2.gz), use zgrep:

zgrep "functions.php" ~/logs/access.log*.gz

Finding Malicious Code in Site Files

After identifying modified files, it’s important to check their contents for backdoors, webshells, and malicious functions that allow attackers to regain access.

1. Searching for dangerous functions in PHP files

The most common functions used in backdoors:

• eval()
• base64_decode()
• gzinflate()
• system(), exec(), passthru(), shell_exec()
• assert() – often used as an eval alternative

grep -r --include="*.php" -E "eval\(|base64_decode\(|gzinflate\(|system\(|shell_exec\(|assert\("~/www

Example result:

www/test.com.ua/wp-includes/load.php: eval(base64_decode($payload));

2. Searching for long obfuscated strings:

Malicious code often begins with an endless string of characters that looks suspicious, done to make understanding its purpose impossible:

grep -r --include="*.php" -E "[A-Za-z0-9+/]{200,}"~/www/html

Example:

3. Searching for files with atypical names or suspicious extensions:

find ~/www -type f \( -iname "*.php*" -o -iname "*.phtml" \) -size -20k

• -size -20k — often malicious scripts are very small, up to 20 KB, but this is not mandatory
• Searching for .php — includes even files with double extensions: file.php.jpg
• .phtml is an example of an atypical/suspicious extension

4. Analyzing .htaccess for hidden redirects

grep -iE "redirect|RewriteRule" ~/www/test.com.ua/.htaccess

Look for:

• Redirects to external sites
• URL masking
• Access restrictions based on User-Agent

Typical Locations for Malicious Code

• Web server root directories
• File upload directories (/uploads/, /media/)
• CMS themes and plugins
• Temporary file directories (/tmp/, /temp/)
• Hidden directories (names starting with .)

CMS Vulnerability Analysis

If your site uses a content management system (CMS) such as WordPress, Joomla, or Drupal, thorough inspection of its components is mandatory when a hack is suspected.

Checking Plugins and Themes

Vulnerable or outdated plugins are one of the most common attack vectors.

1. List all plugins/themes with their versions
2. Compare with open CVE databases and WPScan.io
3. Scan plugins for code changes — compare with the official version

Analysis of Changes Initiated by Plugins and CMS Components

Use CMS logs and server errors to identify suspicious actions:

# Check error logs for suspicious plugin activity
grep -r "plugin_name" ~/logs/*.error.log

# CMS logs (WordPress debug.log)
grep -r "plugin" ~/www/test.com.ua/wp-content/debug.log

If a plugin raises suspicions:

1. Temporarily deactivate it
2. Check the plugin’s source code for malicious functions (especially eval(), base64_decode(), and external inclusions)
3. Compare the installed plugin code with the original version from the official repository
4. Analyze which files were modified or created by the plugin

Checking Access Permissions

Incorrectly configured access permissions can allow an attacker to upload and execute malicious code:

find ~/www -type f -name "*.php" -perm -o+w

The following commands will help set the proper access permissions:

# For files (e.g., .php, .html, .js, etc.)
find ~/www -type f -exec chmod 644 {} \;

# For directories
find ~/www -type d -exec chmod 755 {} \;

• permissions 644:
  • owner – read + write
  • group/others – read only
• permissions 755:
  • owner – read + write + execute
  • group/others – read + execute

Checking the CMS Database

For WordPress and other popular CMS, it’s useful to check the options tables in the database — this is where data about plugin activation and actions may be stored. This helps identify which plugins are active and whether any traces remain in the system.

Execute the following SQL queries through phpMyAdmin — a web interface for database management available in the hosting control panel:

-- For WordPress: check activated plugins
SELECT option_value FROM wp_options WHERE option_name = 'active_plugins';

-- Check changes in the options table recently (for MySQL)
SELECT * FROM wp_options WHERE option_name LIKE '%plugin%' 
AND option_name NOT LIKE '%active_plugins%' ORDER BY autoload;

-- Check events related to plugins (if there's a logs table)
SELECT * FROM wp_logs WHERE action LIKE '%plugin%' ORDER BY timestamp DESC LIMIT 50;

Common Attack Vectors

SQL Injection – an attack where the attacker injects malicious SQL code into website database queries.

Signs:

• Unusual database queries in logs
• Strange parameters in URLs (e.g., '1'='1')

Example:

SELECT * FROM users WHERE '1'='1';

Provides access to the entire table without authorization.

XSS (Cross-Site Scripting) allows an attacker to inject malicious JavaScript code into website pages.

Signs:

• Strange scripts or iframe elements in page HTML code
• Redirects to external resources

Example:

<script>alert('XSS')</script>

Can steal cookies, redirect users, and manipulate the interface.

File Upload Vulnerabilities

If the site has forms for uploading files without proper verification, an attacker can upload a malicious script.

Signs:

• Unknown executable files in upload directories
• Log entries about uploading files with suspicious extensions

Measures to Remediate Hack Consequences

After identifying the cause of the hack, steps must be taken to restore website security:

1. Remove malicious code and all suspicious files
2. Update software: CMS, plugins, themes, libraries, and server software
3. Change passwords for all accounts (CMS administrators, FTP, databases, SSH)
4. Fix vulnerabilities that allowed the hack to occur
5. Check backup files for malicious code before restoration

Preventive Security Measures

Regular Software Updates

Timely updates of all website components is a fundamental security measure:

Instructions for updating WordPress can be found here

Or follow the actions shown in the screenshot:

• Update the CMS, its plugins, and themes to the latest version
• Use only supported plugins and themes
• Monitor server software updates

Security Monitoring

Set up a monitoring system for early detection of suspicious activity:

• Install an intrusion detection system (IDS)
• Configure alerts for suspicious activity
• Regularly analyze server logs

Backup

Regular backups will help quickly restore the site after an incident:

• Create backups of all files and the database
• Store copies on a separate server or cloud storage
• Verify backup integrity

Additional Tools for Security Analysis

There are many tools that can help in analyzing website security and identifying the causes of a hack:

Vulnerability Scanners

• OWASP ZAP – a free tool for testing web application security
• Nikto – a web server scanner for identifying potential problems
• OpenVAS – a comprehensive vulnerability scanning system

Malicious Code Analysis Tools

• ClamAV – an open-source antivirus scanner
• Maldet (Linux Malware Detect) – a specialized scanner for detecting malicious code on web servers
• PHP-Malware-Finder – a tool for finding malicious PHP code

Intrusion Detection Systems (IDS)

• ModSecurity – a web application firewall (WAF) for Apache, Nginx, and IIS
• Fail2ban – a tool for blocking suspicious IP addresses
• OSSEC – a host-based intrusion detection system