The Silent Reconnaissance Already Hitting Your Website

Have you ever looked at your website's access logs?

Mixed in with visits from real customers and partners, there are often requests that no one in your organization made. They come from automated programs, commonly called bots, that scan for weaknesses.

This article walks through real scan data to show what these bots are looking for and what small businesses can do about it.

What the logs actually show

Over a 12-hour window, one site recorded 169 total requests. Thirteen of those were requests for paths ending in .php.

This site does not use PHP at all. Every one of these requests was looking for a file that does not exist. Roughly 8% of all traffic was this kind of silent reconnaissance.

What these scans are looking for

Each request has a purpose behind it.

Configuration files and admin pages

Requests for conf.php or edit.php are looking for files that might contain database credentials, API keys, or other secrets. In some PHP applications, sensitive information is written directly in configuration files, and a misconfigured server can expose them to the outside world.

Server information

php.php and php8.php are looking for leftover test pages that display server details. If one of these pages exists, an attacker can see the server's software version, loaded modules, and internal settings.

Traces of a previous break-in

ms.php and jp.php are known names for backdoors. These scans check whether a previous attacker left a back door open that someone else can now reuse.

CMS directory structure

/css/index.php assumes a directory layout common in WordPress and similar content management systems. The goal is to identify what software the site runs and find known weaknesses for that version.

Why PHP draws most of the fire

It may seem pointless to scan a non-PHP site for PHP files. From the attacker's perspective, though, it makes perfect sense.

• PHP is the most widely used server-side language on the web, powering a large share of all websites, including WordPress
• Historically, PHP applications have been prone to configuration mistakes that expose sensitive files
• Bots do not check which language a site uses before scanning — they simply scan everything

If even one out of a thousand sites turns out to be vulnerable, the scan has already paid for itself. The reality is not "we don't use PHP, so this doesn't apply to us." It is "they scan every site regardless."

What you can do to protect your site

Block unnecessary paths

If your site does not use PHP, you can set a firewall rule to reject every request that ends in .php. That single rule turns away all of these scans before they reach your application.

Most hosting and cloud platforms include a firewall or WAF (Web Application Firewall) that you can configure from a dashboard. Check what your own environment offers.

Build a habit of reading your logs

Scans like these are invisible unless someone looks.

Even once a month is enough. If you see requests for paths that do not exist on your site, you are looking at scan traces.

Keep unused files off the public web

Test pages, old admin interfaces, and backup files left in a public directory are exactly what these bots are hunting for. Review what is actually accessible and remove anything that should not be.

Do not assume your site is too small to matter

Bots do not filter by company size. Every site on the public internet is a target.

tiny-csirt note

Your site's access logs probably contain more than you expect. Taking a first look at those logs is where defense begins.