Suspicious Domain Hosting Indexed Article — Possible Journal Hijacking?

Describe the issue or problem
Our article The Experiences of Maguindanaon Women School Heads in the Armed Conflict Areas is indexed in Google Scholar, but the link points to a suspicious and unrelated domain (garagedoorlansing.com) instead of our official journal site. When clicking the link, users cannot access the legitimate article and may encounter errors or misleading content. We expected the link to direct users to the official article hosted on the JPAIR website (philair.ph).

Steps I took leading up to the issue

  1. Searched for the article title on Google Scholar.
  2. Clicked the top search result link pointing to garagedoorlansing.com.
  3. The page either failed to load correctly or showed unrelated content.
  4. Verified the official article URL on the JPAIR site (philair.ph), which works as expected.

What application are you using?
OJS 3.3.0-8 (JPAIR journal platform)

Additional information
This appears to be a case of possible journal hijacking or unauthorized content duplication on a misleading domain. The suspicious domain is unrelated to academic publishing and could harm our journal’s reputation and user trust. We have not authorized this domain to host our content. Any advice on how to report or prevent this issue would be appreciated.

Best Regards
Darryl

Hi @darrylnuydaph,

Thanks for sharing this. If I click through other versions that are indexed, I see the legitimate article there, it’s just that somehow this spoofed clone of your site, has somehow been prioritized for indexing over the legitimate version of your article.

We don’t control how or what Google Scholar indexes content, so I think our ability to fix this issue may be limited.

I’ll forward this along to the rest of our team to see what advice they may have to offer.

-Roger
PKP Team

Check your server if there is another google search console id file which is not your google search console id file. Delete it.

Maybe they hack your ojs and upload a google search console id file and inject a php script somewhere

1 Like

Hi @darrylnuydaph,

OJS 3.3.0-8 is quite out of date, and we are aware of automated attacks against known flaws in older releases (particularly 3.3.0-15 and older). I’d recommend updating your codebase, and reviewing your installation for malicious modifications and unexpected user accounts.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

I’m very sorry — the OJS version I initially mentioned was incorrect. The actual version I encountered is OJS 3.4.0-8.

Best Regards
Darryl

Hi, @darrylnuydaph

The case you have is so interesting and provides new insights into the hacking methods used by the hacker. We are curious about this case and try to examine further.

I noticed that while the official domain of your journal (philair.ph) is still active and shows no signs of being hacked directly (after we checking the source code of the page scrutiny), the fact that Google Scholar is redirecting to a suspicious domain like garagedoorlansing.com suggests the possibility of a system duplication by an irresponsible party.

My assumption is that your journal (philair.ph) has most likely experienced an unusual form of hacking. Instead of inserting toxic backlinks as is commonly done by hackers based on our experience when handling such link injection gambling cases, here the perpetrators appear to have stolen or duplicated information from your OJS database, then installed a duplicate version of OJS on another server, complete with identical data. I say this based on a similar experience we have tested for Google Scholar indexing purposes. In that test, we:

  • Installing OJS on a new domain (e.g.: newDomain.com),

  • Using the config.inc.php file from the original domain (oldDomain.id),

  • Still access the same database as on the original domain.

As a result, both domains can display the same journal content because they are connected to a same database content. This means that anyone who manages to get their hands on your database configuration files and credentials can replicate your journal system entirely on another server.

If this is indeed the case in your case, then I suggest the following steps to confirm and resolve the situation:

  1. Analyze your server for any backdoor, knowing the method on how the hacker can gain access to the server and stole your database. There must be a backdoor somewhere in your server.

  2. Immediately change the database access credentials (user, password) and update the configuration in config.inc.php.

  3. Restrict access to the database so that it cannot be accessed externally from outside your server.

  4. Upgrade your OJS to the latest version and separate the server with other platform such as WordPress or other unsecured platform

  5. Upgrade the application to the latest for patching the known vulnerability such as your Apache, PHP and MySQL even your Linux OS.

To share our experience, we have knew that hacker can gain access to your server based on these cause :

  1. Hacking the OJS using known vulnerability (trust me they have document all the dictionaries of vulnerability and use it to hack the victim site of OJS).
  2. Through another platform such as WordPress or other platform that is built unsecure
  3. Hacking using application vulnerability such as this one : https://cyberpress.org/php-vulnerabilities/

We hope this information is useful and we would greatly appreciate it if you could continue to provide updates regarding the current case.

Regards,
Almadani
OJT Team

4 Likes

@darrylnuydaph,

Another avenue you might try: Make a request to have the site removed from Google search results as either copyright infringement or spam. The form is here: https://support.google.com/legal/troubleshooter/1114905?hl=en#ts=1115655

-Roger
PKP Team

2 Likes