How to Read Server Logs to Detect Unknown Malware on Custom PHP Sites in 2026

How to Read Server Logs to Detect Unknown Malware on Custom PHP Sites in 2026

You've built your custom PHP website with all sorts of cool features. It's your baby. Then, one day, things get weird. Maybe your site is slow, or visitors are reporting strange pop-ups. You suspect malware, but your security scanner isn't flagging anything. This is where server logs become your best friend. I've been cleaning up hacked sites for over 8 years, and trust me, logs tell a story the scanners sometimes miss.

Look, most folks don't think about server logs until something breaks. But for custom PHP sites, they're goldmines for spotting threats that aren't tied to common CMS vulnerabilities. Think of them as the security camera footage of your web server. You just need to know what to look for.

Why Logs Are Crucial for Custom PHP Malware

Custom PHP sites are a bit different than, say, a WordPress site where we know common exploit points. For a custom build, the attacker might find a unique flaw in your code. This kind of attack won't necessarily leave the usual breadcrumbs that standard security tools are programmed to find. That's why digging into your server logs is so important for detecting unknown malware.

Here's the thing: hackers often try to cover their tracks. They'll inject code, create backdoor files, or set up malicious redirects. But they still have to interact with your server to do it. Those interactions? They're recorded.

Understanding Apache/Nginx Access Logs

Your web server (usually Apache or Nginx) keeps access logs. These logs record every single request made to your website. Each line is a snapshot of an interaction. We're talking IP address, date, time, the requested URL, status code, and how much data was transferred.

What should you be looking for? Lots of garbage requests from the same IP, especially ones hitting random, non-existent files. Or a sudden surge in requests to your admin area or PHP files from suspicious IPs. It's like seeing someone repeatedly trying to pick locks on every door of your house. It's just not normal behavior.

Example Log Entry (Apache):

192.168.1.10 - - [10/Oct/2026:14:35:12 +0000] "GET /wp-admin/admin-ajax.php?action=hacked_script¶m=123 HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

In this simplified example, the IP 192.168.1.10 made a request. The important part is what's being requested. If you see requests with weird, random-looking query parameters like ?action=hacked_script¶m=123 hitting core PHP files or even non-existent ones, that's a red flag. It suggests someone is trying to trigger or exploit a piece of code.

Spotting Suspicious GET and POST Requests

Attackers often use GET requests to pass malicious data through URL parameters. They might also use POST requests to send data through forms or API endpoints.

When you're reviewing your access logs, pay close attention to the requested URLs. Are there unusually long URLs? Are they filled with strange characters or commands? For example, you might see something like this:

GET /malicious.php?cmd=ls -la&user=admin HTTP/1.1

This kind of request is a dead giveaway. The attacker is trying to execute commands on your server. If you don't have a file named malicious.php, but you see it being requested thousands of times, that's a problem. Also, watch for POST requests to unusual PHP files that don't normally handle user input.

Analyzing Error Logs for Clues

Your error logs are just as important, if not more so, than your access logs. These record any errors your web server or PHP itself encounters. Malware often tries to do things it's not supposed to, and that usually results in errors.

I've seen cases where malware attempts to write to files it doesn't have permission for, or tries to execute functions that aren't available. These actions will definitely show up in your PHP error logs. Look for messages like:

• PHP Fatal error: Call to undefined function malicious_backdoor()
• PHP Warning: fopen(/path/to/sensitive/file.txt): failed to open stream: Permission denied
• PHP Parse error: syntax error, unexpected 'eval' (T_EVAL)

That last one, unexpected 'eval', is a classic sign of obfuscated PHP code being executed. Attackers love using PHP's `eval()` function because it lets them run code hidden within strings. If you see errors referencing `eval()` or similar functions being called unexpectedly, it's a strong indicator of injected malware.

The Role of PHP-FPM Logs

If you're using PHP-FPM (which most modern setups do), you'll have additional logs to check. These logs are specific to the PHP process manager. They can reveal issues with how PHP scripts are being handled.

PHP-FPM logs can show if processes are crashing unexpectedly, or if there are unusual spikes in resource usage for certain PHP scripts. This can point to a malicious script hogging your server's resources. Again, it's about spotting abnormal behavior that deviates from your site's normal operations. For custom sites, this level of detail can be the key to finding those hidden threats.

Identifying Backdoor Files

Malware often tries to create backdoor files. These are typically small PHP files with innocuous names that contain malicious code. They're designed to give attackers continued access to your server.

How do you find these in logs? It's tricky. They often try to blend in. But sometimes, you'll see access logs showing requests to files that shouldn't exist, or files that have been modified very recently. If a file suddenly starts getting accessed heavily from IPs you don't recognize, or if you see PHP errors originating from a file you didn't create, investigate it immediately. For instance, a file named config_backup.php that suddenly has GET requests pointing to it could be hiding something. Always check the modification dates of your PHP files against your logs.

Detecting Malicious Redirects

One of the most common things malware does is redirect your visitors to spam sites or phishing pages. This can happen even on custom PHP sites.

In your access logs, look for lots of requests to your homepage or other common pages, followed by a 301 or 302 redirect status code. The `Referer` header might also be interesting here, though attackers often spoof this. If you see an abnormal number of redirects originating from your server, especially to sites you don't recognize, it's a major red flag. This is similar to what we see with website redirect viruses on WordPress, but the method of injection on a custom site can be much more varied.

What About File Integrity Monitoring?

While not strictly a log analysis technique, running file integrity checks regularly is a smart move. Tools that monitor your files and alert you to any changes can complement your log analysis. If a log shows activity on a file, and your integrity checker shows that file was modified around the same time, you've got a strong lead.

This is especially useful for detecting those sneaky backdoor files. If a file appears out of nowhere or has its timestamp changed, it's a warning sign. Combined with suspicious log entries, it paints a clearer picture of a compromise.

Putting It All Together: A Detective Approach

Reading server logs isn't just about spotting obvious errors. It's about acting like a detective. You're looking for anomalies, unusual patterns, and deviations from normal behavior. Think about what your site *should* be doing. Anything that doesn't fit that picture needs a closer look.

If you're running a custom PHP site, and it's not a major CMS like WordPress or Joomla, specialized removal services are essential. While we have services for WordPress malware removal, OpenCart malware removal, and Joomla malware removal, custom builds require a different approach. That's why we offer custom / other platform malware removal.

I've seen this happen dozens of times: a site owner spends hours trying to figure out why their custom PHP site is acting up. They run scanners, check code, and come up empty. Then they look at the logs, find a few suspicious entries, and within minutes, we can pinpoint the infection. It's incredibly frustrating when a simple log check could have saved so much time.

When to Call in the Pros

Look, I get it. You've put a lot of work into your custom PHP site. The thought of someone messing with it is infuriating. If you're looking at your logs and seeing things you can't explain, or if you've tried to clean it yourself and it's still acting weird, it's probably time to get help.

Trying to manually clean a hacked custom PHP site can be like performing surgery with a butter knife. You can do more harm than good. Especially with the increasing sophistication of attacks, like those we see targeting custom builds, it's often more efficient and safer to bring in experts. We know where to look, what tools to use, and how to ensure your site is truly clean and secure moving forward. We've helped countless businesses get back online after dealing with complex hacks, from credit card skimmers in OpenCart stores to database injections in Drupal.

If you're feeling overwhelmed or just want to be sure your site is 100% clean, don't hesitate. You can always start with a free malware scan to get an initial idea of what's going on. Or, if you know you've got a problem and want expert eyes on it, get a free quote for our services. We're here to help.

FAQ Section

Q1: How often should I check my server logs?

For any active website, especially a custom PHP one, checking logs at least weekly is a good practice. If you notice any unusual activity or your site starts behaving strangely, check them immediately. Daily checks might be necessary for very high-traffic sites or those handling sensitive data.

Q2: What if the malware is hiding in a core PHP file I can't identify?

This is where file integrity monitoring and expert knowledge come in. If a core file looks suspicious, comparing it against a known clean version (if available) or looking for deviations in functionality that logs point to is key. Often, malware will inject code into legitimate-looking functions or create new, obscure functions. For custom sites, this usually means bringing in someone experienced with that specific platform.

Q3: Can I use a scanner on my custom PHP site instead of logs?

Standard scanners are great for known threats and common CMS vulnerabilities. However, for unknown or highly custom malware on a custom PHP site, scanners often miss them. Logs provide behavioral evidence that scanners can't always detect. It's best to use both: scanners for known issues, and log analysis for the unknown threats. If you're worried about your site's security, consider a professional custom malware removal service.