Support » Fixing WordPress » iFrame Injection Attack WP 3.4.2:

  • Resolved Robert


    My WordPress 3.4.2 site appears to have an iFrame injection attack. The symptoms are a blank page showing only a semicolon ; displays instead of the normal website. Reloading the page may display a single line with a semicolon followed by the normal web site content.

    I inspected the page with FireBug and found the following HTML source immediately after the </head> and <body class=…> section:

    <body class=”home blog gecko”>
    <iframe width=”1″ scrolling=”no” height=”1″ frameborder=”0″ src=””>

    Sucuri Site Check ( says my site is clean. I’ve tried disabling plugins, which appeared to make the problem temporarily go away, but with the plugin disabled the iFrame returned a short time later.

    The site is registered by a person in Moscow, Russia.

    Any ideas how to fix this?


Viewing 7 replies - 1 through 7 (of 7 total)
  • Moderator kmessinger




    Thank you very much for the advice and site checker links. Sucuri, Unmask Parasites and Google all return a clean bill of health for my WordPress site.

    I applied the WordPress Hardening advice early this year, well before the problem; I suspect a plugin to be the problem.

    I seem to have solve the problem by disabling several popular plugins and reinstalling WP 3.4.2. The site looks good now from several computers and web browsers (FireFox, IE and Chrome). I also changed my CPanel and FTP password to a really long randomized string that even I can’t remember without saving to an offline file. Support said my site was having “CPU Throttling” issues – the CPanel report was showing up to 200 seconds per hour. After the corrective actions I’ve had almost no CPU Throttling issues. My website loads way faster now, too.

    I will restore a web site backup from yesterday and redo today’s corrective actions one-by-one to isolate the problem.



    As of this morning, the iFrame injection is back. This is the full HTML when my page loads showing only the semicolon. Notice the URL has change from to

    [ Redacted, please do not post that here ]

    Looking for help to isolate and remove this hack.


    Moderator Jan Dembowski


    Brute Squad and Volunteer Moderator

    How far did you get with replacing all of your files with originals? Did you change the file and directory permissions for your installation?

    If you’ve done all that successfully then it may be your web server itself that’s compromised. That needs to be checked as well.



    Here’s what I’ve done so far:
    1) Did a complete file and database restore from a weekly site backup.
    2) Changed all passwords: MySQL, WordPress login, FTP, CPanel, etc.
    to really long alpha/numerica/special character random passwords.
    3) Changed all my WordPress Secret Keys using the online generator:
    4) Reinstalled WP 3.4.2
    5) Updated a couple of plugins (minor dot release upgrades).
    6) Verified all directories are set to 755 and files to 644.
    7) Double checked .htaccess and wp-config.php permissions.
    8) Verified .htaccess and wp-config.php are still protected by:
    <Files .htaccess>
    order allow,deny
    deny from all
    9) Installed the 6Scan Security plug-in with the monthly paid subscription for the WordPress firewall features. 6Scan only reported 3 minor vulnerabilities during the initial site scan. I’m hoping the firewall features will prevent the iFrame injection hack, etc. Installation was a breeze and the dashboard is user-friendly. Enabled automatic e-mail alerts, failed login lockout timer and all firewall options.

    So far (only ~1 hour since all the updates) the site is working fine.

    Later, I plan to run a file diff compare on the old site versus the new site to see if anything turns up.

    BTW – I have a dedicated IP and SSL certificate. I’m the only active login account and setup WP to force HTTPS sessions. My SSL certificate expired earlier last week because the automatic renewal & install somehow failed. I was running for a few days on an expired certificate until my hosting provider tech support manually installed the new certificate. Wonder if that could have opened a vulnerability window?

    Thanks for the help.



    Hackers infected my website with several backdoors. It was scary to see, the hacker would simply point the web brower to a the full URL of an infected PHP file, type in a user name and a file management dialog box displayed to upload and delete files. The hackers could grab wp-config.php and view the MySQL DB user name and password, too. Whenever I reinstalled WordPress, an infected PHP file would simply reinfect WordPress.

    I subscribed to the 6Scan Security firewall plugin ( and We Watch Your Website ( 6Scan Support identified the hacked files and have been amazingly helpful! WeWatchYourWebsite performed the malicious code cleanup within a day and has done an outstanding job.

    I believe the hackers got in through an existing backdoor in an older and unsupported advertising plugin, but I may never know for certain. From there the hackers infected various PHP files with lots of obfuscated PHP code that looks like a monkey on a typewriter: “JTkVULCBTT0NLX1NUUkVBTS….” that goes on line after line. The obfuscated code is converted to executable PHP through base64_decode and various string functions with tedious loops and counters to hide what it’s about. Even the base64_decode() function was in a string “b.a.s.e.6.4._d.e.c.o.d.e” to thwart grep searches.

    The purpose of the hack was not to necessarily damage my website, rather to load malware into the rendered web page from hacker sites to install a trojan on the visitor’s computer. The trojan could to any number of things, including spyware and spreading new infections. I scanned my local computer with the latest McAfee and MalwareBytes; nothing was found. On the advice of 6Scan, I downloaded the free Microsoft Security Essentials which found two spyware trojans and removed those. I’ve since purchased Avast Internet Security Suite on the security experts advice. Wow! Avast is so much more robust.

    I think the semicolon page display was a screw-up on the hackers part that alerted me to the problem. The web site checkers ( all reported my site clean before- and after the hack.

    FireBug in FireFox will display the malware code if you inspect the page source and have an idea of what to look for.

    Lot’s of bother changing all my website and hosting passwords, including my online banking and other accounts.

    The services provided by WeWatchYourWebsite and 6Scan are very affordable and go way beyond the WordPress Hardening Recommendations – which is still a necessary step.

    My site now loads much faster because it’s not requesting malicious code from the hacker sites.

    Going forward I’ll stick with WeWatchYourWebsite and 6Scan firewall for prevention and notifications of suspicious activity. Now that I understand what they do, I won’t leave home without it.



    OK – the dust has settled and my WordPress site is now clean.

    My site was hacked by the Filesman ( PHP backdoor which enables a hacker to install, modify and delete nearly ANY file on the WordPress site; PHP and .htaccess files were targeted in my case.

    Here’s how the hack works:
    1. The hacker gained access to my site via one of at least four or maybe five vulnerabilities that have been documented and since fixed over the past 12 months in a variety of plugins, theme (paid, not free) or TimThumb (thumb.php). Because there’s no central mechanism or clearinghouse that I’m aware of for receiving notifications of vulnerabilities and fixes across all themes and plugins, my site was exposed for months.

    2. Fileman backdoor installed by the hacker. Not in once place, but many. Sometimes it was a new file masquerading as a legitimate file with a similar name, other times new code added to an existing PHP file in WordPress, the theme or plugin.

    3. The hacker used the Filesman backdoor to insert the “drive-by download” malware code in a number of WordPress, theme and plugin PHP files. My .htaccess was also modified to allow foreign access. My site was acting as a “Typhoid Mary” ( vector to infect website visitors.

    4. When someone visited my site, the infected PHP file injected the iFrame in the web page code that contained Javascript malware and links to trojans pulled from overseas websites.

    5. Hopefully, the web site visitor’s anti-virus software will block the drive-by trojan to prevent a PC infection. If not, the trojan infects the visitor’s computer – which is the ultimate goal – to do any of a number of things such spyware to steal online banking passwords, taking remote control of the PC, distribute spam, etc.

    My home desktop was infected by the JS:Kryptik-D. The website malware further was identified as the Backdoor:PHP/Seqangle exploit. McAfee and MalwareBytes missed the Kryptik-D trojan in the drive-by download. Microsoft Security Essentials, Microsoft ForeFront and Avast Internet Security all detected, removed and blocked future downloads of the trojan. This isn’t a comment on the anti-virus programs, rather the arms race of constantly updating virus signatures. I am now running Avast Internet Security and really like it.

    The difficulty of removing the WordPress site malware is you cannot rely on looking at file dates for changed files because the PHP malware uses programming calls to reset the infected PHP file back to it’s original date.

    The only way to detect the infected PHP files is to:
    A. Manually examine each file if you’re an expert and know what to look for. One of the PHP malware infected files had a nicely commented and formatted function to blend in with the standard WordPress code! And that new function did not contain obfuscated code.

    B. Compare file checksums (binary equivalents) and file sizes against the known “clean” base release of WordPress, the theme and plugins. Impractical to do without automated tools.

    C. Examine the MySQL database for infections – a very cumbersome effort due to the large database size and formatting of a SQL dump. A security expert is needed here.


    The solution was multi-layered approach:
    1. Hire a security professional to diagnose and clean the WordPress site. An examination of the raw server logs and automated scan tools are essential.

    2. Install a WordPress firewall plugin and server-side scanning script to monitor for all changes and block bad IP addresses.

    3. The security professionals hardened .htaccess and other items to prevent access to files, execution of PHP in certain directories, obtaining directory listings, etc.

    3. Change ALL passwords: CPanel, MySQL, WordPress.

    4. Delete any plugins and unused themes that you can do without to reduce the possible set of vulnerabilities and total file count on the server. Reducing the file count makes the “finding the needle in the haystack” situation easier. When I look at some of the plugin PHP code and see URLs to Amazon Web Services (AWS) and remote web sites, it makes me cringe.

    5. Check the Security and Firewall logs daily for suspicious activity; changed files, successful & failed logins, etc.

    The WordPress firewall constantly blocks access from “bad” IP addresses (hackers, spammers), shows that hackers are constantly trying to guess the Admin WordPress password (delete the Admin user now if you already haven’t!), trying to access now-fixed exploits in WordPress and plugins, and execute PHP files remotely (e.g.

    My advice is:
    * If you haven’t signed up with a WordPress security service and installed a WordPress firewall, then you’re either already hacked and don’t know it, or it’s just a matter of time before you are hacked. The analogy is not running an anti-virus program on your home computer.

    * Use plugins very sparingly and check the change logs regularly.

    * Check the change log, blog or Twitter feed for your WordPress theme for any notices on a regular basis.

    * Make regular full site backups and save these offline for long term storage. My hosting provider’s nightly, weekly and monthly backup service (a premium service) was very helpful.

    Hope this helps.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘iFrame Injection Attack WP 3.4.2:’ is closed to new replies.