madjenja

Thanks kmessinger I have used that scan in the past but it didn’t pick up everything. VaultPress did pick up more, but again it didn’t catch all the injected code.

Apparently its hard to detect some injected code…

Specifically, the following snippet is what tipped me off:

https://22degrees.co.nz/wp/wp-content/themes/lightweight/main.php";echo "\n";echo
"https://alf-mutschelbach.de/wp-content/themes/lightweight/track.php";echo "\n";echo
"https://newsweetpix.com/assets/track.php";echo "\n";echo
"https://fugitif.eu/wp-content/themes/lightweight/atom-conf.php";echo "\n";echo
"https://morrow-technologies.com/wp-content/themes/lightweight/inc.php

Found them…

taxonomy-portfolio_cats.php
and
another that i can’t remember right now. ;D

OK I may have found the problem. On the homepage, the same issue had arisen. I was looking in index.php for clues when I found:

<a href="<?php the_permalink(' ') ?>" title="<?php the_title(); ?>" class="opacity"><?php the_post_thumbnail('portfolio'); ?></a>

I tried changing the href code from
the_permalink(‘ ‘)
to
the_permalink()

That caused the thumbs on the home page to go to their respective detail page.

Now I want to try the same thing on the gallery page thumbs. Does anyone know the php file that generates the gallery page?

OK I may have found the problem. On the homepage, the same issue had arisen. I was looking in index.php for clues when I found:

” title=”<?php the_title(); ?>” class=”opacity”><?php the_post_thumbnail(‘portfolio’); ?>

I tried changing the href code from
the_permalink(‘ ‘)
to
the_permalink()

That caused the thumbs on the home page to go to their respective detail page.

Now I want to try the same thing on the gallery page thumbs. Does anyone know the php file that generates the gallery page?

I’m guessing it is part of the exploit because:

1. it placed a single quote and dot on every page of my site.

2. this particular piece of suspected code was not present one month ago.

I found it in the theme folder’s footer.php file.

$raw = base64_decode($encoded);
$res = ”;
for ($i = 0; $i < strlen($raw); $i++) {
$res .= chr(ord($raw[$i]) ^ ord(‘x’));
}

I know this is a trick used by exploits. I removed it (and the loooong encoded variable that came before it, and the ‘. is gone.

I’m a bit troubled as to why wordpress.com’s premium security scanner didn’t catch this.

It appears to be linked to the theme.

Thanks for responding stern and James.

For anyone else who may be affected by this exploit, there are two additional actions I took based on the feedback:

1. Changed passwords! This seemed to “maim” the exploit.

2. I upgraded to WordPress.com’s premium service and they ran the VaultPress scanner, which identified three problem files, which I deleted. These files were missed by both the host’s scanner and sucuri’s scanner.