I just had something similar happen with one of the sites I support. In my case it appears that the intruder obtained filesystem access (I’m more-than-concerned about how that happened), got into the database, created a user called systemwpadmin, logged in as that user, did whatever he was going to do, and then deleted the systemwpadmin user afterward to cover his tracks. Assuming you had a similar scenario, that would explain why Wordfence didn’t block the user. If a user with the name in question exists, the blocking spec is ignored.
Would you mind using the contact form on my business site (flyingsealsystems.com) to start an email dialog about this? I’m interested in who your website host is. I don’t want to list mine here because I don’t want to cast possibly-undeserved suspicions in a public forum.
In my case one thing the intruder left behind was some indecipherable code at the very beginning of the functions.php files in both my active theme and an inactive one. (Wordfence helped me find that as well.) Do you have something similar?
After making a copy for further research, I’ve completely restored the website from backup and changed passwords at all levels (including the hosting account).
Without Wordfence I’d be blissfully (for now) unaware that all this had happened. Very scary.
@fsbob
Thanks for the help. Can you send that code to me at tim [at] wordfence.com? Include a link to this post and your username here.
Thanks!
tim
This has happened to 2 sites so far… different hosts
@Debwork: Did you find the code added to the beginning of the functions.php files in your sites’ active and inactive themes?
I provided Tim from WFSupport a copy of the code that was added to mine–it will be interesting to learn what he finds.
Yes I saw that but restored the functions.php files.
WF reported successful logins by systemwpadmin WF shows from Russian Federation.
Also note:
Files with the following endings were added to the site and not reported by WF but were reported by the web host’s scan. I did not contact WF support yet.
“..old.php”, “..indesit.php”, “..prevv1.php”, “…ver1.php”, “…noversion.php”, “…new.php”, “…backup.php”
I found 15 files with those endings, but there were only 4 different sets of sets of contents between them. They’re all using the same technique of setting variables in the first part, and then concatenating strings from them in the second. I haven’t seen exactly what the results are, but likely it’s some form of eval() exploit. Interestingly, they all start with <?php, but it’s not closed at the end. They all end with );, sometimes with a trailing space, too.
This is on a site I just cleaned, removing a bunch of ll.php hacks sprinkled through function.php files and post content.
@drylander – were those files reported in your WordFence scan?
My clues are the admin login and the functions.php exploit to look for these other files.
Actually, I’m using a different security plugin, which shall remain nameless (okay, it’s WP Security), but it wasn’t installed when the site was compromised. My first clue was anonymous links showing up on pages. Reviewing the site back-ups, I saw that the hacks were in the content from 2011, so it’s been a bit of a pain cleaning things up. Identifying (and removing) the files you mentioned above is a big deal!
Thread Starter
e dev
(@efishinsea)
It can be easier (and better?) to just replace the files in question. Most of the time you can easily just re-upload WordPress core files and plugin and theme files with originals, which means no searching for “what got hacked?” type changes.
Of course, I usually do that (search for changes) because I’m interested in what is going on and how my site has potentially been exploited, but just doing a blanket replacement (as in delete the old, re-upload the new) is the best way to ensure you don’t miss anything.
Caveats to this would be custom themes (which hopefully, you also have a local copy of already) and whatever is in the upload folder.
Additionally, if you use any caching plugins, you will want to be sure you delete *ALL* old cached files (which could include the exploited code) before you are done.
Finally, don’t forget to check your htacess or web.config files for additional hacky redirects, which is a common path to exploit too.
The “Re-install Now” feature on the updates page is very nice, and a fresh install would be even nicer. The problem is when exploits have been embedded in page content or superfluous files like @Debwork mentioned above. None of the 15 files I removed even belong, but unless I’d installed from scratch (new directory structure and all), they’d still be there.
I had a customers site hacked using the administrator name “systemwpadmin” as well this weekend. Nothing was changed on the main WP site but files where uploaded to another WP directory on the same server. Left no trace of themselves in the database and no trace in the main web site. the only evidence seen was that my security plugin logged the user systemwpadmin as a successful login. There’s only one user for this site and no others. What concerns me is how this was done.
