What 14 Days of Internet Scanning Looks Like

The Constant WordPress Probing

The majority of requests targeted WordPress environments.

Paths included:

• /wp-admin/
• /wp-login.php
• /wp-content/plugins/...
• /xmlrpc.php
• Known vulnerable plugin endpoints

The application was not running WordPress.

That didn’t matter.

Attackers do not check what stack you use. They spray common CMS paths across every public IP and domain. If one in a thousand is misconfigured or outdated, the scan pays off.

Credential Harvesting Attempts

The second largest category involved direct attempts to retrieve secrets:

• .env
• .git/config
• .aws/credentials
• config.php
• parameters.yml
• Source tree paths like src/main/resources/.../.env

These are not random guesses. They are part of curated wordlists built from:

• GitHub repositories
• Past breaches
• Public misconfiguration incidents

The logic is simple:

If a developer accidentally exposed a repository or deployed a project root as the web root, secrets are often sitting in plain text.

Most of the requests returned 404.

That’s the expected and desired outcome.

AWS and Cloud Metadata Probing

Several requests attempted path traversal attacks like:

../../../../../../~/.aws/credentials

This is an attempt to exploit a local file inclusion vulnerability and extract AWS access keys directly from the host filesystem.

Other patterns suggest probing for internal cloud metadata endpoints, a common technique used to extract IAM role credentials from misconfigured servers.

These attacks rely on one mistake:

An endpoint that reads files without proper input validation.

If present, the attacker doesn’t need to brute force anything. They simply download credentials.

Redis and Internal Service Enumeration

The logs also contained probes for:

• Redis default ports and paths
• Oracle-related infrastructure directories
• Kubernetes-related paths
• Container registry references
• Internal API forwarders

These are not generic “script kiddie” patterns. They reflect awareness of modern cloud infrastructure.

Open Redis instances remain one of the most abused misconfigurations in cloud deployments. Attackers check constantly.

React-to-Shell Exploitation Attempts

One interesting category involved probing for build artifacts and front-end frameworks, including paths commonly associated with React deployments.

This matters because attackers increasingly chain:

• Frontend exposure
• Misconfigured static hosting
• Backend API assumptions
• File upload vulnerabilities

In poorly segmented architectures, this can escalate from a client-side application flaw to server-side code execution.

There were also generic attempts to upload or access .php shells — even though the application did not run PHP.

Automation does not care what you actually use.

SolarWinds-Style Probing

There were also probes referencing paths and patterns historically associated with supply-chain compromises and enterprise tooling, including SolarWinds-related identifiers.

This doesn’t mean the application was targeted specifically for SolarWinds.

It means scanners look for high-impact enterprise software exposures wherever they can find them.

If a misconfigured internal admin interface or update endpoint is exposed publicly, it becomes a high-value target.

What This Tells Us

Across 14 days:

• The traffic was continuous.
• The payloads were automated.
• The IP addresses rotated.
• Most were residential or cloud-hosted.
• Very few were flagged by reputation services.

This is important.

Reputation checks are not a reliable indicator of intent.

Behavior is.

A residential IP attempting to download ~/.aws/credentials is malicious, even if VirusTotal shows “clean.”

The Reality of Public Infrastructure

Any public endpoint will experience:

• CMS scanning
• Secret scraping
• Cloud credential harvesting
• Internal service probing
• Framework-specific exploitation attempts
• Supply chain reconnaissance

This is not an anomaly.

This is baseline internet behavior.

Security is not about preventing scans. That’s impossible.

It’s about ensuring scans find nothing useful.

Why This Matters

Many teams assume:

“We’re too small to be targeted.”

The logs show otherwise.

Attackers are not choosing you.

They are scanning everything.

The only difference between noise and incident is misconfiguration.

A publicly exposed .env file turns background noise into breach.

An open Redis port turns scanning into ransomware.

An exposed debug endpoint turns probing into credential theft.

Recommendations: Designing for Inevitable Scanning

The takeaway from 14 days of logs is not that scanning exists.

It’s that scanning is constant.

The goal is not to stop probes. The goal is to make sure nothing useful is exposed when they arrive.

Below are practical safeguards that meaningfully reduce risk.

1. Assume Secrets Will Be Requested Directly

Attackers will try:

• /.env
• /.git/config
• /config.php
• /parameters.yml
• ~/.aws/credentials

Do not rely on “nobody will guess that path.”

Instead:

• Never deploy project roots as web roots.
• Ensure .env files are excluded from container images.
• Use managed secret services (e.g., Secret Manager, Vault) instead of plaintext files.
• Disable directory listing everywhere.

If a secret exists as a readable file inside your runtime container, it is a liability.

2. Remove Development Artifacts From Production

Common mistakes include:

• Leaving debug endpoints enabled.
• Exposing test routes.
• Deploying source directories.
• Shipping unused admin interfaces.

Production builds should contain only what is required to serve the application.

Nothing more.

Development convenience becomes production exposure.

3. Enforce Principle of Least Privilege

If an attacker does find a foothold, limit the blast radius.

• Use IAM roles instead of static AWS keys.
• Restrict roles to only necessary permissions.
• Do not grant wildcard permissions like s3:*.
• Segment internal services from public-facing services.

Credential theft is common. Over-permissioned credentials are what turn theft into catastrophe.

4. Lock Down Internal Services

Repeated probes targeted Redis, container registries, and internal infrastructure paths.

Ensure:

• Redis is not publicly exposed.
• Admin panels are IP-restricted or behind authentication layers.
• Internal APIs are not reachable from the public internet.
• Cloud metadata endpoints are protected against SSRF.

Internal services should never rely on “security by obscurity.”

5. Monitor for Behavior, Not Just Reputation

Many malicious requests came from IP addresses with no reputation flags.

Reputation feeds are useful, but insufficient.

Monitor for:

• Path traversal attempts
• Requests for secret files
• Repeated framework probing
• Unusual request patterns

An IP attempting to read /etc/passwd is malicious even if it has a clean history.

Detection must focus on behavior.

6. Treat Frontend and Backend as a Unified Threat Surface

Probing for React artifacts and CMS paths highlights a common misconception:

Frontend exposure can become backend compromise if APIs are poorly secured.

Ensure:

• APIs validate authentication independently of the frontend.
• File uploads are strictly validated.
• Static hosting does not expose build or config artifacts.
• CORS is properly configured.

Client-side frameworks do not protect server-side infrastructure.

7. Log Retention and Periodic Review

The insights in this analysis came from routine log review.

Maintain:

• At least 30 days of access logs.
• Centralized log aggregation.
• Automated alerting for suspicious patterns.
• Periodic manual inspection.

You cannot improve what you do not observe.

Final Thought

Internet scanning is not an event.

It is the environment.

Security posture is not measured by the absence of probes.
It is measured by the absence of successful exploitation despite constant probing.

The difference between noise and incident is usually one overlooked configuration.

Design accordingly.