Arama Yap Mesaj Submit
Request a Callback
+90
X
X

Select Your Currency

Turkish Lira $ US Dollar Euro
X
X

Select Your Currency

Turkish Lira $ US Dollar Euro

Contact Us

Location Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
INCIDENT RESPONSE · 2026

Has My Server Been Hacked? Website and Server Security Check

Unknown PHP files, shells that return after deletion, casino or betting snippets in Google, unexpected redirects, unusual CPU load and unfamiliar administrator accounts do not automatically share the same root cause. This guide separates symptoms from evidence and correlates the filesystem, application, database, hosting accounts and access logs on one incident timeline.

Eka Sunucu technical team investigating a website and server security incident
Technical investigation image
Siteyi hemen rastgele silip yeniden kurmayın; önce yedek ve kanıt kopyası alın.
Şüpheli dosyanın değiştirilme zamanını, erişim logları ve panel hareketleriyle eşleştirin.
uploads, cache, tmp, images gibi normalde PHP çalıştırmaması gereken alanları ayrıca kontrol edin.
Cron, .user.ini, .htaccess ve yeni yönetici hesaplarını kalıcılık açısından inceleyin.
Google spam görünüyorsa dosya temizliği ile indeks temizliğini ayrı süreçler olarak yönetin.

Contents

  1. What should you do in the first 15 minutes?
  2. 20+ signs that justify a security investigation
  3. How to inspect the filesystem for shells and backdoors
  4. Why does the shell return after you delete it?
  5. What if Google shows betting, casino or strange parameter URLs?
  6. Check cPanel, Plesk, FTP, SSH and CMS accounts
  7. Could the malicious content be coming from the database?
  8. Correlate file timestamps with access logs
  9. Common cleanup mistakes to avoid
  10. How EKA performs file, log and code-security review
01

What should you do in the first 15 minutes?

If compromise is still active, do not start by deleting everything. Limit impact and preserve evidence first. Export a full file copy, database dump and available web/WAF/panel logs before timestamps or rotated records are lost.

Avoid uncontrolled testing on production. Quarantine suspicious files, validate a clean copy in staging, rotate hosting, FTP/SFTP, SSH, database and CMS credentials, revoke unknown sessions and enable MFA where available.

02

20+ signs that justify a security investigation

Unexpected .php or .phtml files, executable scripts under uploads, repeated changes to .htaccess or .user.ini, reappearing files, unknown cron jobs, new admin users and unexplained outbound links are high-value investigation signals.

A site can look normal in your browser and still be compromised. Conditional code may react only to a specific referrer, user agent, cookie, device or crawler. Microsoft documented cookie-controlled PHP webshell tradecraft in Linux hosting environments in April 2026.

03

How to inspect the filesystem for shells and backdoors

Do not delete files based on a single keyword. Functions such as eval, base64_decode, gzinflate, shell_exec, system, exec, passthru and proc_open also appear in legitimate software. Risk increases when they are combined with external input, heavy obfuscation, a recent modification and an unexpected path.

Review recently changed PHP files, executable content under upload/cache/tmp directories, double extensions, misleading image-like filenames, file ownership and permissions. Record hashes and timestamps so findings can be correlated with requests later.

CLI 1
find public_html -type f -name "*.php" -mtime -7 -print
CLI 2
find public_html -type f -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -100
CLI 3
find public_html -path "*/uploads/*" -type f \( -name "*.php" -o -name "*.phtml" \) -print
CLI 4
grep -RInE "eval\s*\(|base64_decode\s*\(|gzinflate\s*\(|shell_exec\s*\(" public_html --include="*.php"
04

Why does the shell return after you delete it?

Reappearance usually means the persistence mechanism was not removed. Cron, scheduled hosting tasks, .user.ini auto_prepend_file, rewrite rules, a malicious plugin, database-stored payload or a second backdoor can recreate the visible file.

Microsoft’s 2026 hosting research describes incidents where scheduled jobs recreated removed PHP loaders. “The shell file is gone” and “the incident is remediated” are therefore different statements.

CLI 1
crontab -l
CLI 2
find /home \( -name .user.ini -o -name .htaccess \) 2>/dev/null
CLI 3
grep -RIn "auto_prepend_file\|auto_append_file" /home 2>/dev/null
CLI 4
find public_html -type f -mmin -180 -ls
05

What if Google shows betting, casino or strange parameter URLs?

Google classifies unauthorized content injection, hidden links, cloaking and malicious redirects as hacked content patterns. A redirect may occur only when users arrive from search or from a specific device while a direct visit appears normal.

Use site: queries as a quick visibility check, but do not treat search results alone as malware proof. Correlate Search Console Security Issues, URL Inspection, sitemaps, canonicals, HTTP responses and actual source output.

CLI 1
site:alanadi.com casino
CLI 2
site:alanadi.com bet
CLI 3
site:alanadi.com slot
CLI 4
site:alanadi.com viagra
06

Check cPanel, Plesk, FTP, SSH and CMS accounts

Not every intrusion starts with an application exploit. Stolen FTP credentials, password reuse, session theft or a compromised administrator workstation can produce the same file changes. Compare panel/account activity with the file timeline.

After password rotation, revoke old sessions and unknown API tokens or SSH keys. If multiple sites share accounts or credentials on the same server, check them for cross-impact.

07

Could the malicious content be coming from the database?

Hacked links and spam do not always live in a physical PHP file. CMS options, widgets, post metadata, theme settings and custom tables can inject HTML or JavaScript dynamically.

Take a database dump before bulk searching or replacing values. Review suspicious domains, spam terms, iframe/script fragments and newly created privileged users. Database structure differs across WordPress, OpenCart, Laravel and custom PHP applications, so there is no safe one-query cleanup.

08

Correlate file timestamps with access logs

Start with the approximate creation or modification time of a suspicious file. Inspect a narrow time window around it for POST/PUT requests, upload endpoints, successful status codes and follow-up requests to the newly created script.

An IP address in a log is a technical indicator, not proof of a person’s identity. VPNs, CDNs, proxies, botnets and compromised hosts can sit in between. Attribute the event using multiple signals: time, URL, method, account activity and file changes.

09

Common cleanup mistakes to avoid

Avoid global string replacement across all PHP files, deleting logs, running unbacked SQL replacements on production, or removing only the visible shell while leaving credentials and persistence untouched.

When a clean upstream release or version-controlled repository exists, compare against it. Custom applications benefit from file-level diffs and controlled functional tests to avoid breaking legitimate code while removing malicious changes.

10

How EKA performs file, log and code-security review

Depending on scope, the review can use a ZIP/site backup, SQL dump, cPanel/Plesk logs, Search Console evidence or explicitly authorized SSH access. Static file review, recent changes, persistence, spam URL behavior, log timelines and application controls are assessed together.

After cleanup, controlled validation is performed only on an authorized copy or staging environment. The report separates discovered artifacts, likely entry points, residual risks and hardening actions. Search-engine reindexing is documented as a separate process from technical file cleanup.

Quick incident pre-assessment

This tool runs in your browser and does not send your selections to the server. It does not replace a professional review.

Low signal
Select symptoms to update the preliminary assessment.
EKA Web Security Review

Ask the technical team to review

Standard cases are usually scheduled for a 24–72 hour analysis window after pre-assessment. Timing varies with file count, log access, malware spread and application architecture.

Important note: Only test systems you own or are explicitly authorized to assess.

Google Spam Policiesdevelopers.google.comGoogle Security Issues Reportsupport.google.comGoogle Prevent Malwaredevelopers.google.comMicrosoft Cookie-controlled PHP webshellswww.microsoft.comCISA Web Shell Guidancewww.cisa.gov

Frequently asked questions

Is deleting the shell file enough?

No. If cron, another backdoor, a stolen account or the original application flaw remains, the file can return.

Can a compromised site still look normal?

Yes. Cloaking and cookie/header-controlled logic can stay dormant for ordinary visits.

Does casino text in Google mean there must be a casino file?

No. Content may come from the database, routing, rewrite rules or conditional crawler output.

Can you identify the hacker from an IP address?

Logs can reveal incident-related source IPs, but an IP does not prove the real person behind it.

Do I need to send passwords for a first review?

No. Start with the symptom, platform, backup status and sample logs or screenshots.

Is 24–72 hours a guaranteed cleanup time?

No. It is a planning window; scope is confirmed after pre-assessment.

Top