Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
If your website shows malware, unauthorized redirects, SEO spam, rogue administrators, backdoors, phishing pages or recurring compromise, we first separate the visible symptom from the likely technical layer. The initial review uses checks that can be performed from the public website; file-system, database or server access is requested only when deeper verification is required.
We do not ask for wp-admin, FTP, SSH or hosting passwords for the first review. Send the website URL, a short description of the symptom and, if available, a screenshot from Search Console or your hosting security scanner.
Malware, redirect, spam and breach indicators
Unexpected redirects, foreign-language spam pages in Google, unknown administrators, executable files inside upload directories, modified core files, malicious JavaScript, files that return after deletion, Search Console Security Issues, browser phishing warnings, unusual cron jobs and abnormal server traffic can all be indicators. No single signal proves compromise; files, database, accounts, scheduled tasks, logs and server scope should be correlated.
A hidden backdoor or database payload cannot always be discovered from a domain name alone. Public analysis can identify visible symptoms, redirects, browser resources and security warnings. Definitive remediation commonly requires file-system, database, account, cron and server-log review.
A hidden backdoor or database payload cannot always be discovered from a domain name alone. Public analysis can identify visible symptoms, redirects, browser resources and security warnings. Definitive remediation commonly requires file-system, database, account, cron and server-log review.
The same symptom can originate from several layers, so it should be matched with evidence and a verification method.
| Symptom | Likely layer | First check |
|---|---|---|
| Website redirects elsewhere | Injected JavaScript, server rewrite, plugin/theme, database or edge rule | Redirect chain, source, different clients and referrers |
| Japanese/Chinese spam in Google | Hacked SEO spam, cloaking or automated spam URLs | site: search, Search Console, sitemap and routing |
| Browser warns about deceptive site | Phishing/social engineering or malicious content | Search Console Security Issues and example URLs |
| Unknown admin account appears | Unauthorized account creation, stolen admin session or persistence | User list, creation time, roles and logs |
| Deleted malware returns | Backdoor, cron, MU plugin, sibling-site or server persistence | Cron, server tasks, sibling sites and logs |
| CPU suddenly spikes | Bots, brute force, spam generation, miner or heavy scheduled task | Access logs, process list and cron |
“Malware” is not one technical problem; remediation depends on the compromise and persistence type.
A hidden mechanism that allows an attacker to regain access after the obvious malware has been removed.
A server-side script that exposes file or command capabilities through the web application.
Unauthorized gambling, pharmacy, fake-product or foreign-language pages created for search traffic.
Fraudulent login or payment pages hosted under the compromised domain.
Injected browser-side code used for redirects, pop-ups, fake forms or remote payload loading.
An unauthorized privileged account that can provide persistent application access.
Malicious scripts, links or redirects stored in application records rather than files.
Scheduled tasks that recreate deleted malware or fetch remote payloads.
Unexpected changes in core or repository-managed files that require verification.
A breach outside the CMS layer that may reinfect otherwise clean application files.
A slow site, a 500 error or encoded PHP is not proof of malware. Security findings should be correlated with file provenance, timestamps, logs and expected application behavior.
Build a timeline: when did the symptom begin, what changed before it, were new administrator or FTP accounts created, did the hosting provider send alerts and are sibling sites affected?
This reduces false positives and helps identify why a supposedly cleaned site becomes infected again.
Malicious redirects may trigger only for mobile users, search-engine visitors, first-time visitors or specific countries. Testing from one browser can therefore miss the issue.
Check server redirects, .htaccess/Nginx rules, CMS URL settings, themes, plugins, MU plugins, configuration, database options and client-side JavaScript.
Blocking the destination domain is not remediation; locate the injection source.
Unauthorized search results can indicate hacked SEO spam or cloaking. Attackers may generate thousands of URLs while normal visitors still see the legitimate site.
Removing URLs from Search Console does not remove the generator. The rewrite, file, database record, plugin or backdoor responsible must be cleaned.
After remediation, verify 404/410 behavior, sitemap, canonical signals and Search Console security status.
Google can surface hacked content, malware and social-engineering findings in the Security Issues report, often with example URLs.
A browser deceptive-site warning may relate to phishing or social-engineering content. Remediate the compromise before requesting review.
Example URLs are evidence, not necessarily a complete inventory of all affected pages.
A backdoor can be a PHP file, injected plugin code, rogue admin, scheduled task, SSH key or server-level mechanism.
Deleting only the file flagged by a scanner often produces temporary relief if persistence or the entry vector remains.
When several sites share a hosting account, an abandoned installation can reinfect the cleaned site.
WP-CLI can compare WordPress core files with WordPress.org checksums and can verify repository-hosted plugins as well.
A mismatch is not automatically malware; custom edits and incomplete updates can also differ. Interpret results in context.
Premium and custom plugins require comparison with a trusted vendor package, repository or known-clean backup.
WordPress media directories normally contain media rather than executable PHP. Attackers frequently abuse writable directories for shells.
Do not blindly delete every PHP file; verify whether a legitimate plugin generated it and inspect its role and timestamp.
After cleanup, script-execution restrictions in upload directories can add defense where application compatibility permits.
Injected code can be stored in theme files, widgets, options, page-builder data or compromised third-party tags.
Browser Network and Sources panels help identify unexpected domains and the resource responsible for loading them.
If a tag-management or advertising account is compromised, application files may look clean while visitors still receive malicious code.
Scripts, iframes, spam links and redirects may be stored in options, posts, widgets or plugin tables.
Blind string replacement can destroy legitimate content. Back up first and verify the affected record.
File cleanup alone will not remove database-stored payloads.
Capture creation time, email, role and relevant logs before removing an unauthorized administrator where possible.
Rotate administrator, hosting, FTP/SSH and other relevant credentials and invalidate active sessions.
If the account was created through a vulnerable endpoint or backdoor, password changes alone will not prevent recurrence.
WordPress cron, control-panel cron, system crontab and application schedulers can all be abused for persistence.
Laravel queues/schedulers and other workers also need consideration outside WordPress.
Identify what a suspicious task runs and when it was created before simply deleting it.
A sibling site, FTP account, control-panel account, SSH key or server service can be the reinfection source.
Persistent incidents should expand the scope beyond the CMS when evidence points there.
On shared hosting, provider logs may be needed when system-level visibility is unavailable.
Update supported core, themes and plugins; remove unused components; use unique passwords and 2FA; minimize privileged accounts.
Review ownership, permissions, config protection, upload execution policy and application-specific XML-RPC/REST needs.
WAF, backups, logging and integrity monitoring work best as layers and do not replace patching or cleanup.
Send the domain, symptom, approximate start date and any security screenshot. Public checks are performed without requesting passwords.
We separate visible compromise from configuration or application errors and explain whether authenticated file/database inspection is required.
Remediation, database changes, backdoor removal and server-log analysis are scoped separately if needed.
These examples are defensive checks. Do not automatically delete every file reported by a scanner or checksum difference.
Turkey (Turkish)
Germany (German)
Worldwide (English)
wp core verify-checksums --include-rootwp plugin verify-checksums --all --strictwp user list --fields=ID,user_login,user_email,roles,user_registeredwp cron event listfind wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -printfind . -type f -name "*.php" -mtime -7 -printThe software does not need to have been purchased from us. With source visibility and authorized access, the existing application can be assessed.
Core, themes, plugins, users, cron, uploads and configuration
WordPress plus checkout, payment scripts, webhooks and order integrity
Extensions, modifications, admin accounts, configuration and upload surface
Modules, overrides, admin accounts, cache and modified PHP files
Core, extensions, templates, accounts and configuration
.env, public/storage, Composer/vendor integrity, scheduler/queue and custom code
File, database, authentication, upload, cron and log review according to the application
Cleanup is more than deleting files. Scope, entry vector, persistence and reinfection risk should be handled together.
Confirm redirect, spam, warning or suspicious file.
Keep file/database copies and available logs before destructive changes.
Determine whether one site, the hosting account, email or server layer is affected.
Review vulnerable components, accounts, backdoors, cron and server layer.
Remove malicious content and replace/update weak components with trusted copies.
Change application, hosting, FTP/SSH, database, mail and relevant API secrets.
Apply 2FA, least privilege, WAF, permissions, backups and monitoring.
Recheck integrity, users, cron and public behavior; complete search-engine review if required.
For the free preliminary analysis, send the domain and a short description of the symptom. No password is requested at the first stage. If deeper remediation is needed, the required access and scope are explained separately.
For security content we prefer official WordPress and Google documentation plus technical vendor documentation.
If the preliminary analysis points to security, application or another layer, use the related service page.
Direct answers to the symptoms and questions website owners most often encounter.
Visible redirects, spam and warning signals can be reviewed publicly, but hidden backdoors or database payloads may require authenticated access.
No. The initial review starts with the domain and symptom description.
Yes, when source code and the required authorized access are available.
No. Misconfiguration and legitimate redirect rules can also cause it; the source must be identified.
It can indicate hacked SEO spam or cloaking. The generator must be removed, not only the indexed URLs.
Clean the malicious or phishing content and close the vulnerability first, then use Search Console’s security review process.
Persistence such as a backdoor, cron task, rogue account, sibling site or server-level compromise may remain.
No. Scanners are useful signals but may miss custom, database or server-level persistence.
No. Encoding is used legitimately too; compare the file with a trusted source and inspect context.
Investigate first. They are suspicious but may occasionally be created by legitimate software.
Rotate all credentials relevant to the incident scope, not only the CMS administrator password.
No. It can provide WAF and traffic controls but does not clean compromised application files or database records.
No. Patching, 2FA, least privilege, trusted software, backups, logging and monitoring are also needed.
Yes. Its provenance cannot be trusted and it may contain hidden malicious code or miss security updates.
For evidence, comparison and rollback. Do not blindly restore an infected copy to production.
Not if the vulnerability remains, and it may lose recent orders or user data.
No. The mechanism generating the URLs must be remediated.
Yes. A web shell or compromised script can abuse mail functions, while a mailbox may also be compromised separately.
No. It can also be legitimate traffic, bots, cron or heavy queries. Logs and process data are needed.
No. We do not perform unauthorized exploitation or brute force. It is a passive/public preliminary review plus interpretation of evidence you provide.
Scope differs by platform, file count, data sensitivity, persistence, server access and forensic/log requirements.
Yes. The software does not need to have been purchased from Eka Sunucu or Eka Yazılım if authorized access and source visibility are available.
After malicious content, persistence and the vulnerability have actually been remediated and the site has been rechecked.
No. HTTPS encrypts transport; it does not patch vulnerable applications or stolen accounts.
The domain, symptom, approximate start date and any Search Console or hosting alert screenshot. Do not send passwords in the first step.
For the free preliminary analysis, send the domain and a short description of the symptom. No password is requested at the first stage. If deeper remediation is needed, the required access and scope are explained separately.