Understanding Website Hijacking: Techniques, Cases, and Prevention Strategies

1. Overview

Recently, I have been busy handling security and emergency response for the conference. By using the company’s cloud information platform, we discovered and resolved dozens of website hijackings. I have a good grasp of hacker SEO technology. Fortunately, I have some free time to share some interesting cases I encountered before. A lot of the techniques inside have been thoroughly explored, but there’s not much information online. So I’m sharing some related cases here, mainly focusing on the thought process.

1.1 Principle

Website hijacking is a relatively old technique, primarily used by black hats for SEO purposes. The implementation of website hijacking follows these steps:

  1. Infiltrate related websites
  2. Then insert JS or modify its configuration file in the website to add corresponding hijacking code. Usually, conditions will be added to determine based on user-agent or referer. Most conditions will judge whether it is a crawler or a human. If it’s a human, the normal website will be returned; if it’s a crawler, relevant gambling or entertainment sites set by hackers will be returned.
  3. For human visits, the normal website will be displayed. However, when crawlers visit, the returned result is related gambling or entertainment sites, causing the indexed site to be the one carefully prepared by hackers.
  4. Black hat SEO is primarily aimed at what crawlers index. For normal human visits, it returns normal content, making such sites difficult to detect and allowing them to exist for a relatively long time.

The following explains the method of implementing redirection through JS hijacking encountered in practical work. This JS script uses a combination of IP address, UA, and referer determination for redirection judgment.

1.2.1 Determine IP Location

If the remote IP belongs to Anhui or Beijing, it will be directly redirected to http://www.anhui365.net/404.html; if the location is not Anhui or Beijing, it will redirect to the gambling site http://m.an888.top/

Website hijacking >

1.2.2 Determine Referer

If the referer keyword is: baidu, google, yahoo, bing, soso, 360, etc., when crawlers visit, the browserRedirect() function will be called. The browserRedirect() function is primarily for implementing redirection judgment.

Website hijacking >

1.2.3 Determine User-Agent

If the corresponding user-agent matches the keywords ipad, iphone os, midp, ucweb, android, etc., then it will redirect to http://m.an888.top/ the gambling site.

This is a classic JS judgment condition that comprehensively determines IP address, user-agent, and referer. After the hacker infiltrates the corresponding website, they only need to add references to JS in the website, usually directly in the relevant call pages such as index.php by directly inserting the following code:

1.3 Behavior

When a website is hijacked and used for SEO, the typical behavior is that human visits cannot directly open it, requiring changes to the browser’s user-agent and referer to reproduce the corresponding hijacked page. A hijacked page generally looks like this:

Hijacking Case-1 (Embedded Parasite Program)

Hijacking Case-2 (Inserted Promotional Content)

Hijacking Case-3 (Page Redirection to Gambling Site)

2. Front-End Hijacking Case

2.1 Principle

Front-end hijacking generally involves inserting JS scripts into the corresponding page of the website to conduct hijack redirections through JS.

2.2 Behavior and Detection

In case of front-end hijacking, the browser will execute the corresponding JS script, so we can capture packets to detect the relative JS scripts. Tools like burpsuite, fiddler, wireshark, etc., can be used to capture packets for analysis and detection. Additionally, you can also open the page to analyze its source code for determination, finding all loaded JS scripts from the source code and then analyzing them.

2.3 Case

A website was found redirecting to a gambling site when opened. Analyzing its source code revealed an inserted JS code segment causing the site to redirect to the gambling site upon opening.

3. Server-Side Hijacking Case

3.1 Principle

Server-side hijacking, also called back-end hijacking, involves modifying website dynamic language files, such as global.asax, global.asa, conn.asp, conn.php, etc. These are configuration files that load with each dynamic script, like loading conn.php when accessing x.php. A modification to these global dynamic script files (like global.asax) allows for a global hijacking effect when all aspx files are accessed as they load the global.asax file.

3.2 Behavior and Detection

Since these files execute on the server, unlike front-end hijacking, which allows for malicious JS script analysis, detection must occur on the server. Generally, it involves detecting global script files to analyze if they have been maliciously altered. These files typically don’t change frequently, allowing for file integrity detection. After initial configuration, MD5 or HASH values can be generated, and periodic comparisons ensure MD5 integrity. If changes occur, analyze and detect altered contents.

3.3 Case

A government website contained numerous gambling links. However, both source code and packet analysis revealed no suspicious JS scripts. This indicated server-side hijacking.

Remote connection to its server showed the website developed in aspx, with its aspx global loading file global.asax found. Source code analysis revealed the addition of crawler determination conditions; if a crawler visits, it redirects to the related gambling site.

For server-side hijacking, identifying and removing the inserted code is essential. Alternatively, using backup files to overwrite is possible, but doesn’t truly solve the issue. Usually, a modified global.asax indicates hacker penetration into the relevant server. Comprehensive emergency response is necessary, including log analysis, webshell detection, and extensive security checks at system and application levels to identify hacker access methods and resolve respective vulnerabilities.

4. Peculiar Server Hijacking Case

Typically, server-side hijacking allows detection of hacker-inserted or modified source code sections via the described methods. However, yesterday’s case involved a peculiar server hijacking incident. Source code and packet analysis confirmed server-side hijacking, yet extensive global file examination failed to locate hacker-inserted hijacking code sections.

A government site showed a parasite template using a spider UA. Directly analyzing its index.php file revealed it only called another file. The file path was: /phpcms/base.php

Locating base.php, its extensive source code prolonged hijacking code identification. Assisted by colleagues, the hijacker’s code was eventually found. Base.php loaded a common library, executing the following function:

@include(PACK(‘H*’,’443A5C7765625C6C79715C75706C6F616466696C655C323031375C303232315C31′));

Php’s pack function detail:

@include(PACK(‘H*’,’443A5C7765625C6C79715C75706C6F616466696C655C323031375C303232315C31′)); where:

H represents hexadecimal

443A5C7765625C6C79715C75706C6F616466696C655C323031375C303232315C31 denotes respective parameters, requiring conversion.

Post-conversion, content reveals \web\lyq\uploadfile\2017\0221\1, indicating base.php used include for the file \web\lyq\uploadfile\2017\0221\1. Identifying this file and analyzing its source code indeed revealed the hacker’s hijacking function file.

This unique case, while peculiar, still achieves hijacking through server-side functions to load hijacking scripts. The script placed in an upload directory caused analysis challenges. To address such hijacking, establishing critical file baselines such as index.php, global.asax, conn.php, etc., via MD5 and HASH value generation followed by periodic integrity checks ensures any file alteration is detected. Identified variations should be compared against the baseline for legitimate analysis.

Currently, beyond aforementioned methods, black hats employ JS injection for crypto mining. Despite encountering server-side crypto mining programs in practice, I have yet to face JS website injection for mining. Nevertheless, online reports of such occurrences exist, indicating an essential focus on JS within website code during security analysis. Future cloud intelligence platforms will include malicious JS identification and analysis, pending further case-sharing opportunities.