{"id":3421,"date":"2025-12-26T17:18:18","date_gmt":"2025-12-26T14:18:18","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/cleaning-up-hacked-php-websites-backdoors-ftp-ssh-scans-and-safe-migration\/"},"modified":"2025-12-26T17:18:18","modified_gmt":"2025-12-26T14:18:18","slug":"cleaning-up-hacked-php-websites-backdoors-ftp-ssh-scans-and-safe-migration","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/cleaning-up-hacked-php-websites-backdoors-ftp-ssh-scans-and-safe-migration\/","title":{"rendered":"Cleaning Up Hacked PHP Websites: Backdoors, FTP\/SSH Scans and Safe Migration"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>If your PHP website is hacked, the most dangerous part is usually not the defaced homepage or the visible spam links. The real risk is the hidden backdoor that lets attackers come back anytime they want, even after you &#8220;clean&#8221; the obvious damage. In our day-to-day work at dchost.com, we regularly help customers recover from compromised PHP sites on shared hosting, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> and <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s. The pattern is always the same: the first cleanup looks successful, traffic and SEO seem normal again, and then a week later malicious files reappear from nowhere. The cause is almost always an undetected backdoor.<\/p>\n<p>This article walks through a practical, no-drama process to clean hacked PHP websites properly. We will focus on how to detect backdoors, how to scan code over FTP or SSH, and when it is safer to migrate to a fresh hosting account or server instead of trying to patch a badly compromised environment. The steps apply to WordPress, Laravel, custom PHP apps and most other PHP-based systems.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Hacked_PHP_Sites_Are_Hard_to_Clean_Properly\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Hacked PHP Sites Are Hard to Clean Properly<\/a><\/li><li><a href=\"#First_Response_Contain_the_Incident_and_Collect_Evidence\"><span class=\"toc_number toc_depth_1\">2<\/span> First Response: Contain the Incident and Collect Evidence<\/a><ul><li><a href=\"#1_Limit_damage_and_stop_automated_abuse\"><span class=\"toc_number toc_depth_2\">2.1<\/span> 1. Limit damage and stop automated abuse<\/a><\/li><li><a href=\"#2_Take_full_backups_before_cleaning\"><span class=\"toc_number toc_depth_2\">2.2<\/span> 2. Take full backups before cleaning<\/a><\/li><li><a href=\"#3_Write_down_basic_incident_details\"><span class=\"toc_number toc_depth_2\">2.3<\/span> 3. Write down basic incident details<\/a><\/li><\/ul><\/li><li><a href=\"#Detecting_PHP_Backdoors_and_Hidden_Malware\"><span class=\"toc_number toc_depth_1\">3<\/span> Detecting PHP Backdoors and Hidden Malware<\/a><ul><li><a href=\"#Typical_backdoor_patterns_in_PHP_code\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Typical backdoor patterns in PHP code<\/a><\/li><li><a href=\"#Searching_for_backdoors_over_SSH\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Searching for backdoors over SSH<\/a><ul><li><a href=\"#1_Search_for_dangerous_functions\"><span class=\"toc_number toc_depth_3\">3.2.1<\/span> 1. Search for dangerous functions<\/a><\/li><li><a href=\"#2_List_recently_modified_files\"><span class=\"toc_number toc_depth_3\">3.2.2<\/span> 2. List recently modified files<\/a><\/li><li><a href=\"#3_Use_command-line_malware_scanners_if_allowed\"><span class=\"toc_number toc_depth_3\">3.2.3<\/span> 3. Use command-line malware scanners (if allowed)<\/a><\/li><\/ul><\/li><li><a href=\"#Scanning_when_you_only_have_FTP_access\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Scanning when you only have FTP access<\/a><\/li><\/ul><\/li><li><a href=\"#Cleaning_and_Hardening_in_Place_vs_Migrating_to_a_New_Hosting_Account\"><span class=\"toc_number toc_depth_1\">4<\/span> Cleaning and Hardening in Place vs Migrating to a New Hosting Account<\/a><ul><li><a href=\"#When_it_is_relatively_safe_to_clean_in_place\"><span class=\"toc_number toc_depth_2\">4.1<\/span> When it is relatively safe to clean in place<\/a><\/li><li><a href=\"#When_you_should_migrate_to_a_fresh_account_or_VPS\"><span class=\"toc_number toc_depth_2\">4.2<\/span> When you should migrate to a fresh account or VPS<\/a><\/li><\/ul><\/li><li><a href=\"#Safe_File-Level_Cleanup_Step-by-Step\"><span class=\"toc_number toc_depth_1\">5<\/span> Safe File-Level Cleanup: Step-by-Step<\/a><ul><li><a href=\"#1_Build_a_clean_baseline\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 1. Build a clean baseline<\/a><\/li><li><a href=\"#2_Replace_core_and_vendor_files_from_trusted_sources\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 2. Replace core and vendor files from trusted sources<\/a><\/li><li><a href=\"#3_Clean_uploads_custom_code_and_themesplugins\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 3. Clean uploads, custom code and themes\/plugins<\/a><\/li><\/ul><\/li><li><a href=\"#Database_Inspection_and_Cleanup\"><span class=\"toc_number toc_depth_1\">6<\/span> Database Inspection and Cleanup<\/a><\/li><li><a href=\"#Planning_and_Executing_a_Safe_Migration\"><span class=\"toc_number toc_depth_1\">7<\/span> Planning and Executing a Safe Migration<\/a><ul><li><a href=\"#1_Prepare_the_new_environment_securely\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 1. Prepare the new environment securely<\/a><\/li><li><a href=\"#2_Copy_scan_and_verify_before_DNS_cutover\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 2. Copy, scan and verify before DNS cutover<\/a><\/li><li><a href=\"#3_Post-migration_security_checklist\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 3. Post-migration security checklist<\/a><\/li><\/ul><\/li><li><a href=\"#Long-Term_Hardening_to_Avoid_Repeat_Hacks\"><span class=\"toc_number toc_depth_1\">8<\/span> Long-Term Hardening to Avoid Repeat Hacks<\/a><\/li><li><a href=\"#Bringing_Your_Hacked_PHP_Site_Back_Under_Control\"><span class=\"toc_number toc_depth_1\">9<\/span> Bringing Your Hacked PHP Site Back Under Control<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Hacked_PHP_Sites_Are_Hard_to_Clean_Properly\">Why Hacked PHP Sites Are Hard to Clean Properly<\/span><\/h2>\n<p>PHP malware rarely behaves like a single obvious file named &#8220;virus.php&#8221; sitting in your web root. Attackers usually:<\/p>\n<ul>\n<li>Plant multiple small backdoors in different folders<\/li>\n<li>Inject code into existing files (themes, plugins, libraries, index.php, configuration files)<\/li>\n<li>Abuse writable directories (like uploads or cache) to store arbitrary PHP shells<\/li>\n<li>Modify the database to inject spam links or malicious JavaScript<\/li>\n<\/ul>\n<p>On top of that, most shared hosting and even many VPS setups have:<\/p>\n<ul>\n<li>Weak file permissions (world-writable directories, 777 folders)<\/li>\n<li>Outdated PHP versions and libraries<\/li>\n<li>Multiple sites sharing the same user account<\/li>\n<\/ul>\n<p>All of this makes a hacked PHP site a bit like an apartment with several hidden spare keys left under different doormats. You can change the main lock, but if the spare keys remain, intruders will keep coming back. That is why a proper cleanup combines:<\/p>\n<ul>\n<li>Immediate containment and backups<\/li>\n<li>Systematic search for backdoors in files and database<\/li>\n<li>Security hardening of PHP, file permissions and web server<\/li>\n<li>Often, migration to a fresh hosting account or VPS<\/li>\n<\/ul>\n<h2><span id=\"First_Response_Contain_the_Incident_and_Collect_Evidence\">First Response: Contain the Incident and Collect Evidence<\/span><\/h2>\n<p>Before touching files or deleting anything, take a methodical first-response approach. You want to:<\/p>\n<h3><span id=\"1_Limit_damage_and_stop_automated_abuse\">1. Limit damage and stop automated abuse<\/span><\/h3>\n<ul>\n<li><strong>Change all passwords<\/strong> related to the site: hosting panel, FTP\/SFTP\/SSH, database, CMS admin, and any deployment keys.<\/li>\n<li><strong>Enable maintenance mode<\/strong> or a temporary 503 page if possible, especially if the site is actively distributing malware or spam.<\/li>\n<li>If you use a reverse proxy or CDN like Cloudflare, make sure basic WAF and rate limiting rules are enabled. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cloudflare-guvenlik-ayarlari-rehberi-kucuk-isletme-siteleri-icin-waf-rate-limit-ve-bot-korumasi\/\">Cloudflare security settings with WAF, rate limiting and bot protection<\/a> shows practical rules we recommend.<\/li>\n<\/ul>\n<h3><span id=\"2_Take_full_backups_before_cleaning\">2. Take full backups before cleaning<\/span><\/h3>\n<p>Even if the site is hacked, you must keep a snapshot of the compromised state for two reasons:<\/p>\n<ul>\n<li>Forensic analysis later (where did the attack start?)<\/li>\n<li>Ability to roll back specific changes if you remove something important by accident<\/li>\n<\/ul>\n<p>At minimum, take:<\/p>\n<ul>\n<li>A complete copy of all web files (public_html or application directory)<\/li>\n<li>Database dumps for all related databases<\/li>\n<li>Configuration files outside the web root (.env, config directories, etc.)<\/li>\n<\/ul>\n<p>If your site is on cPanel, you can follow our <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelde-tum-siteyi-yedekleme-ve-geri-yukleme-rehberi\/\">full cPanel backup and restore guide<\/a> to quickly capture a full account backup before you start cleaning. Longer term, implement a robust plan like the <a href=\"https:\/\/www.dchost.com\/blog\/en\/3-2-1-yedekleme-stratejisi-neden-ise-yariyor-cpanel-plesk-ve-vpste-otomatik-yedekleri-nasil-kurarsin\/\">3-2-1 backup strategy with automated backups on cPanel, Plesk and VPS<\/a> so you always have clean restore points.<\/p>\n<h3><span id=\"3_Write_down_basic_incident_details\">3. Write down basic incident details<\/span><\/h3>\n<p>Even a simple text document helps later when you review security:<\/p>\n<ul>\n<li>When did you first notice the hack?<\/li>\n<li>What symptoms appeared (defacement, redirects, spam emails, high CPU)?<\/li>\n<li>Did your registrar, hosting provider or browser show phishing\/malware warnings?<\/li>\n<li>What software versions are you running (PHP, CMS, key plugins)?<\/li>\n<\/ul>\n<p>These details help you narrow down which vulnerability was most likely exploited.<\/p>\n<h2><span id=\"Detecting_PHP_Backdoors_and_Hidden_Malware\">Detecting PHP Backdoors and Hidden Malware<\/span><\/h2>\n<p>Once you have backups, the main battle is discovering every backdoor. Attackers usually hide them in writable folders, obscure filenames, or inside legitimate files.<\/p>\n<h3><span id=\"Typical_backdoor_patterns_in_PHP_code\">Typical backdoor patterns in PHP code<\/span><\/h3>\n<p>Although malware authors constantly obfuscate their code, most PHP backdoors still use a small set of risky functions and patterns, such as:<\/p>\n<ul>\n<li><strong>Dynamic execution:<\/strong> <code>eval()<\/code>, <code>assert()<\/code>, <code>create_function()<\/code>, <code>preg_replace()<\/code> with <code>\/e<\/code> modifier.<\/li>\n<li><strong>System commands:<\/strong> <code>system()<\/code>, <code>exec()<\/code>, <code>passthru()<\/code>, <code>shell_exec()<\/code>, <code>popen()<\/code>.<\/li>\n<li><strong>Obfuscation helpers:<\/strong> <code>base64_decode()<\/code>, <code>gzinflate()<\/code>, <code>str_rot13()<\/code>, nested multiple times.<\/li>\n<li><strong>Suspicious superglobal access:<\/strong> building PHP code from <code>$_POST<\/code>, <code>$_GET<\/code>, <code>$_COOKIE<\/code>, then passing it to <code>eval<\/code> or <code>assert<\/code>.<\/li>\n<li><strong>Random filenames and paths:<\/strong> small PHP files with random names inside <code>uploads<\/code>, <code>cache<\/code> or temporary directories.<\/li>\n<\/ul>\n<p>Example of a simplified backdoor pattern (heavily simplified, real ones are more obfuscated):<\/p>\n<pre>&lt;?php\nif (isset($_POST['cmd'])) {\n    eval(base64_decode($_POST['cmd']));\n}\n?&gt;<\/pre>\n<p>Real-world malware usually wraps similar logic with obfuscation, huge useless string arrays, and confusing variable names to hide from quick inspection.<\/p>\n<h3><span id=\"Searching_for_backdoors_over_SSH\">Searching for backdoors over SSH<\/span><\/h3>\n<p>If your hosting plan or VPS gives you SSH access, you have a huge advantage. You can scan the filesystem quickly using command-line tools. Some useful approaches:<\/p>\n<h4><span id=\"1_Search_for_dangerous_functions\">1. Search for dangerous functions<\/span><\/h4>\n<p>From the site root directory:<\/p>\n<pre>grep -R \"eval(\" -n .\ngrep -R \"base64_decode\" -n .\ngrep -R \"gzinflate\" -n .\ngrep -R \"shell_exec\" -n .<\/pre>\n<p>Then review the results manually. Not every use of these functions is malicious, but in many CMS and frameworks they are rare and stand out. Focus on files that:<\/p>\n<ul>\n<li>Appear in unexpected folders (for example, <code>wp-includes\/fonts\/<\/code> containing PHP)<\/li>\n<li>Have random-looking names (e.g. <code>k9s8d.php<\/code>)<\/li>\n<li>Are very small yet contain heavy obfuscation and long encoded strings<\/li>\n<\/ul>\n<h4><span id=\"2_List_recently_modified_files\">2. List recently modified files<\/span><\/h4>\n<p>Attackers often touch many files in a short window. Look at the last few days or weeks:<\/p>\n<pre>find . -type f -mtime -7 -name \"*.php\" -ls<\/pre>\n<p>This lists PHP files changed in the last seven days. Compare the timeline against when you first noticed symptoms.<\/p>\n<h4><span id=\"3_Use_command-line_malware_scanners_if_allowed\">3. Use command-line malware scanners (if allowed)<\/span><\/h4>\n<p>On VPS and dedicated servers, you can install open-source antivirus or malware scanners to assist manual review. They are not perfect, but they catch many known signatures and suspicious patterns. Run them against the document root and uploads directories. Combine their findings with your own grep and diff analysis.<\/p>\n<h3><span id=\"Scanning_when_you_only_have_FTP_access\">Scanning when you only have FTP access<\/span><\/h3>\n<p>Many shared hosting environments only offer FTP or SFTP access. You can still scan effectively with a few extra steps:<\/p>\n<ol>\n<li><strong>Use SFTP instead of FTP<\/strong> if your account supports it. FTP sends credentials in clear text and is a frequent source of stolen passwords. We explain why this matters in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ftp-yerine-sftp-kullanmanin-zamani-geldi\/\">switching from FTP to SFTP for secure file transfer<\/a>.<\/li>\n<li><strong>Download a full copy<\/strong> of your site to a local machine dedicated for analysis (not your everyday laptop if possible).<\/li>\n<li><strong>Scan locally<\/strong> with your desktop antivirus and any specialized web malware scanner you trust.<\/li>\n<li><strong>Search the code<\/strong> with your local tools: text editor search, <code>grep<\/code> or IDE inspections for functions like <code>eval<\/code>, <code>base64_decode<\/code>, <code>gzinflate<\/code>, etc.<\/li>\n<li><strong>Use diff tools<\/strong> to compare your downloaded code with a fresh copy of the same CMS or framework from the official source.<\/li>\n<\/ol>\n<p>Even with only FTP, careful searching and comparison against clean source code will reveal most backdoors.<\/p>\n<h2><span id=\"Cleaning_and_Hardening_in_Place_vs_Migrating_to_a_New_Hosting_Account\">Cleaning and Hardening in Place vs Migrating to a New Hosting Account<\/span><\/h2>\n<p>One of the biggest decisions is whether to clean the website in its current hosting environment or move to a fresh account or server. We see both approaches work, but there are clear cases where migration is the safer option.<\/p>\n<h3><span id=\"When_it_is_relatively_safe_to_clean_in_place\">When it is relatively safe to clean in place<\/span><\/h3>\n<p>Consider staying on the current account if:<\/p>\n<ul>\n<li>This is the first known compromise and the scope looks limited.<\/li>\n<li>You have SSH access and can fully audit file permissions and logs.<\/li>\n<li>Only a single site is hosted under that user, and there is no evidence of privilege escalation beyond the web user.<\/li>\n<li>File permissions and ownership are sane (no world-writable web root, no 777 directories all over).<\/li>\n<\/ul>\n<p>Even then, plan a full security review after cleaning: PHP version, CMS and plugin updates, file permissions, WAF and firewall rules.<\/p>\n<h3><span id=\"When_you_should_migrate_to_a_fresh_account_or_VPS\">When you should migrate to a fresh account or VPS<\/span><\/h3>\n<p>Migration is strongly recommended when:<\/p>\n<ul>\n<li>Multiple sites under the same user are compromised.<\/li>\n<li>There are signs of deeper intrusion (new system users, strange cron jobs, unusual SSH keys).<\/li>\n<li>File permissions and ownership are a complete mess (lots of 777, mixed owners, leftover panel migrations).<\/li>\n<li>You do not have SSH access or meaningful logs and you cannot fully trust the current environment.<\/li>\n<li>The hosting account is overloaded or outdated, and you were planning to upgrade anyway.<\/li>\n<\/ul>\n<p>In those cases, set up a fresh environment (new shared hosting account, VPS, dedicated server or colocation server at dchost.com) with hardened defaults, then carefully migrate only cleaned data. Our team handles this pattern often for customers whose sites suffered repeated compromises on older hosting setups.<\/p>\n<h2><span id=\"Safe_File-Level_Cleanup_Step-by-Step\">Safe File-Level Cleanup: Step-by-Step<\/span><\/h2>\n<p>Whether you clean in place or before migrating, use a structured process for files. Random manual edits almost always miss something.<\/p>\n<h3><span id=\"1_Build_a_clean_baseline\">1. Build a clean baseline<\/span><\/h3>\n<p>For any CMS or framework (WordPress, Laravel, PrestaShop, custom frameworks), download a fresh, official copy of the same major version you are running. This gives you a <strong>baseline<\/strong> to compare against:<\/p>\n<ul>\n<li>Core files that must match exactly<\/li>\n<li>Default themes or skeleton app files<\/li>\n<li>Standard directory structure<\/li>\n<\/ul>\n<p>Then:<\/p>\n<ul>\n<li>On SSH: use <code>diff -r<\/code> or similar tools to compare your live code with the clean baseline.<\/li>\n<li>Over FTP: compare folders locally using a diff-capable file manager or IDE.<\/li>\n<\/ul>\n<p>Any file present on your site but not in the baseline (outside known app-specific custom folders) is suspicious and should be reviewed.<\/p>\n<h3><span id=\"2_Replace_core_and_vendor_files_from_trusted_sources\">2. Replace core and vendor files from trusted sources<\/span><\/h3>\n<p>As a rule of thumb, <strong>never try to clean core or vendor files by hand<\/strong>. Instead:<\/p>\n<ul>\n<li>Delete the entire core directory (e.g. <code>wp-admin<\/code>, <code>wp-includes<\/code> for WordPress, or the <code>vendor<\/code> directory for Composer-based apps).<\/li>\n<li>Upload or deploy a fresh copy from the official download or your version control repository.<\/li>\n<li>Restore only configuration files (<code>wp-config.php<\/code>, <code>.env<\/code>, etc.) after carefully checking them for suspicious code.<\/li>\n<\/ul>\n<p>For WordPress in particular, we go into more detail in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-siteniz-surekli-hackleniyorsa-ne-yapmalisiniz\/\">what to do if your WordPress site keeps getting hacked<\/a>, but the same principles apply to most PHP applications.<\/p>\n<h3><span id=\"3_Clean_uploads_custom_code_and_themesplugins\">3. Clean uploads, custom code and themes\/plugins<\/span><\/h3>\n<p>Uploads folders are high-risk because they are usually writable by the web server. Ideally, they should contain only images, documents and other non-executable content.<\/p>\n<ul>\n<li><strong>List PHP files<\/strong> inside uploads and similar folders: any PHP file is suspicious and often malicious.<\/li>\n<li><strong>Delete or move out<\/strong> unknown PHP files, then test the application to ensure nothing critical relied on them.<\/li>\n<li><strong>Review custom code<\/strong> (themes, modules, custom libraries) line by line, or re-deploy from your version control repository if you have one.<\/li>\n<li><strong>Update or remove old plugins<\/strong> and modules. Many infections start via outdated extensions that are no longer maintained.<\/li>\n<\/ul>\n<p>A good practice is to ensure uploads directories cannot execute PHP at all (for example, with <code>.htaccess<\/code> rules on Apache or location blocks on Nginx), which we often combine with other measures such as <a href=\"https:\/\/www.dchost.com\/blog\/en\/linux-dosya-izinleri-644-755-777-paylasimli-hosting-ve-vps-icin-guvenli-ayarlar\/\">correct Linux file permissions like 644\/755 on shared hosting and VPS<\/a>.<\/p>\n<h2><span id=\"Database_Inspection_and_Cleanup\">Database Inspection and Cleanup<\/span><\/h2>\n<p>Even if all files are clean, attackers may have injected spam or scripts into the database. Typical signs include:<\/p>\n<ul>\n<li>Strange content added to posts, products or pages (hidden links, iframes)<\/li>\n<li>Unknown admin users or users with elevated roles<\/li>\n<li>Malicious code in settings fields that get printed on every page<\/li>\n<\/ul>\n<p>Steps:<\/p>\n<ol>\n<li><strong>Backup the database<\/strong> again before editing.<\/li>\n<li><strong>Search for suspicious content<\/strong> using SQL or your CMS admin:<\/li>\n<\/ol>\n<pre>SELECT * FROM posts_table WHERE content LIKE '%&lt;iframe%';\nSELECT * FROM posts_table WHERE content LIKE '%base64_decode%';\nSELECT * FROM options_table WHERE option_value LIKE '%&lt;script%';<\/pre>\n<p>Adjust table names to match your application. Look for base64 blobs, iframes to unknown domains, and JavaScript snippets that do not belong to your site.<\/p>\n<ol start=\"3\">\n<li><strong>Review user accounts<\/strong> and remove or downgrade any suspicious admins.<\/li>\n<li><strong>Check configuration tables<\/strong> for values that inject code into headers, footers or widgets.<\/li>\n<\/ol>\n<p>For WordPress specifically, database bloat and strange options in <code>wp_options<\/code> can also hurt performance. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-veritabani-optimizasyonu-wp_options-ve-autoload-sismesini-temizleme-rehberi\/\">WordPress database optimization and cleaning up wp_options\/autoload bloat<\/a> shows how to safely inspect and tidy up the most sensitive tables.<\/p>\n<h2><span id=\"Planning_and_Executing_a_Safe_Migration\">Planning and Executing a Safe Migration<\/span><\/h2>\n<p>If you decide to migrate to a new hosting account, VPS, dedicated server or colocation setup, treat the move as both a cleanup and an upgrade opportunity. The goal is to leave all backdoors behind, not to copy them faithfully to a fresh server.<\/p>\n<h3><span id=\"1_Prepare_the_new_environment_securely\">1. Prepare the new environment securely<\/span><\/h3>\n<p>On the new hosting or server:<\/p>\n<ul>\n<li>Use a supported, up-to-date PHP version with hardened settings (disable dangerous functions where possible).<\/li>\n<li>Configure secure file permissions and ownership from day one (no 777, minimal write access).<\/li>\n<li>Enable basic firewall rules and, on VPS\/dedicated, follow the best practices we outlined in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucu-guvenligi-nasil-saglanir-kapiyi-acik-birakmadan-yasamanin-sirri\/\">securing a VPS server without leaving ports open<\/a>.<\/li>\n<li>Request or configure SSL\/TLS correctly and plan for <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-x-frame-options-ve-referrer-policy-dogru-nasil-kurulur\/\">HTTP security headers like HSTS, CSP and Referrer-Policy<\/a> once the site is live.<\/li>\n<\/ul>\n<h3><span id=\"2_Copy_scan_and_verify_before_DNS_cutover\">2. Copy, scan and verify before DNS cutover<\/span><\/h3>\n<p>For a clean migration flow:<\/p>\n<ol>\n<li><strong>Copy only what you trust<\/strong> from old hosting:\n<ul>\n<li>Fresh core\/framework files from official sources or your Git repository<\/li>\n<li>Carefully reviewed custom themes\/modules<\/li>\n<li>Uploads and media after scanning them for PHP and malware<\/li>\n<li>Cleaned database dump<\/li>\n<\/ul>\n<\/li>\n<li><strong>Scan again on the new server<\/strong> using grep, your malware scanner and manual review. Do not skip this step; many reinfections we see come from missed backdoors that were migrated.<\/li>\n<li><strong>Test the site<\/strong> using a hosts file override or temporary subdomain before switching your main domain. Verify logins, contact forms, checkout, and any custom integrations.<\/li>\n<li><strong>Plan DNS change<\/strong> with reduced TTL for minimal downtime. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/\">TTL strategies for zero-downtime migrations<\/a> explains how to make DNS propagation feel almost instant.<\/li>\n<\/ol>\n<h3><span id=\"3_Post-migration_security_checklist\">3. Post-migration security checklist<\/span><\/h3>\n<p>Once your domain points to the new environment:<\/p>\n<ul>\n<li>Rotate all passwords again (CMS, database, panel, SFTP\/SSH).<\/li>\n<li>Remove any leftover test accounts or demo data.<\/li>\n<li>Verify that directory listing is disabled and uploads directories cannot execute PHP.<\/li>\n<li>Set up monitoring and alerts for uptime and unusual errors.<\/li>\n<li>Confirm that old hosting credentials are revoked and, ideally, the old account is closed or wiped after you are sure the migration is stable.<\/li>\n<\/ul>\n<h2><span id=\"Long-Term_Hardening_to_Avoid_Repeat_Hacks\">Long-Term Hardening to Avoid Repeat Hacks<\/span><\/h2>\n<p>A cleaned site without hardening is almost guaranteed to be hacked again, often via the same vulnerability. Use the incident as a trigger to raise your baseline security:<\/p>\n<ul>\n<li><strong>Keep software updated:<\/strong> CMS, plugins, themes, frameworks, PHP, database server.<\/li>\n<li><strong>Review file permissions:<\/strong> ensure web files are typically 644 and directories 755, with minimal writable locations. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/linux-dosya-izinleri-644-755-777-paylasimli-hosting-ve-vps-icin-guvenli-ayarlar\/\">Linux file permissions 644, 755 and 777<\/a> goes through safe defaults for shared hosting and VPS.<\/li>\n<li><strong>Segment sites:<\/strong> avoid hosting multiple unrelated sites under the same panel user if possible. A compromise in one app should not automatically expose another.<\/li>\n<li><strong>Use a WAF:<\/strong> either at the application level (ModSecurity with a modern ruleset) or via a CDN with WAF features.<\/li>\n<li><strong>Enforce strong authentication:<\/strong> long random passwords, 2FA where available, restricted admin URLs and IP-based limits for sensitive panels.<\/li>\n<li><strong>Monitor logs:<\/strong> regularly inspect web server logs for suspicious requests and unexpected HTTP status patterns.<\/li>\n<li><strong>Automate backups:<\/strong> daily off-site backups with versioning, and periodic restore tests.<\/li>\n<\/ul>\n<p>For WordPress sites in particular, we have a practical checklist in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-wordpress-guvenligi-eklentiler-waf-2fa-ve-yedekler\/\">WordPress security on shared hosting using plugins, WAF, 2FA and backups<\/a>, but the main principles apply to most PHP applications.<\/p>\n<h2><span id=\"Bringing_Your_Hacked_PHP_Site_Back_Under_Control\">Bringing Your Hacked PHP Site Back Under Control<\/span><\/h2>\n<p>Cleaning up a hacked PHP website is less about a single magic scanner and more about a disciplined process. First you contain the damage and preserve evidence. Then you methodically search for backdoors in files and databases using grep, diff, scanners and manual review. Where practical, you replace core and vendor code from trusted sources instead of editing by hand. If the environment itself is suspect or outdated, you migrate to a new, hardened hosting account or server, copying over only carefully cleaned data.<\/p>\n<p>From our experience at dchost.com, the customers who recover cleanly and stay clean are those who treat a hack as a turning point. They invest in regular backups, controlled deployments, timely updates, safer file permissions and basic protections like WAF and security headers. You do not have to turn into a security engineer overnight, but you do need a clear, repeatable playbook. Use the steps in this article as your baseline, and if you host with us, our team can help you plan the practical side: from choosing the right shared hosting, VPS, dedicated or colocation setup to configuring backups, firewalls and monitoring in a way that keeps your PHP websites calm and under control.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>If your PHP website is hacked, the most dangerous part is usually not the defaced homepage or the visible spam links. The real risk is the hidden backdoor that lets attackers come back anytime they want, even after you &#8220;clean&#8221; the obvious damage. In our day-to-day work at dchost.com, we regularly help customers recover from [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3422,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3421","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3421","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3421"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3421\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3422"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}