Saturday, December 2, 2023

Agent Racoon Backdoor Targets Organizations in Middle East, Africa, and U.S.

Organizations in the Middle East, Africa, and the U.S. have been targeted by an unknown threat actor to distribute a new backdoor called Agent Racoon.

"This malware family is written using the .NET framework and leverages the domain name service (DNS) protocol to create a covert channel and provide different backdoor functionalities," Palo Alto Networks Unit 42 researcher Chema Garcia said in a Friday analysis.

Targets of the attacks span various sectors such as education, real estate, retail, non-profits, telecom, and governments. The activity has not been attributed to a known threat actor, although it's assessed to be a nation-state aligned owing to the victimology pattern and the detection and defense evasion techniques used.

The cybersecurity firm is tracking the cluster under the moniker CL-STA-0002. It's currently not clear how these organizations were breached, and when the attacks took place.

Some of the other tools deployed by the adversary include a customized version of Mimikatz called Mimilite as well as a new utility called Ntospy, which utilizes a custom DLL module implementing a network provider to steal credentials to a remote server.

"While the attackers commonly used Ntospy across the affected organizations, the Mimilite tool and the Agent Racoon malware have only been found in nonprofit and government-related organizations' environments," Garcia explained.

It's worth pointing out a previously identified threat activity cluster known as CL-STA-0043 has also been linked to the use of Ntospy, with the adversary also targeting two organizations that have been targeted by CL-STA-0002.

Agent Raccoon, executed by means of scheduled tasks, allows for command execution, file uploading, and file downloading, while disguising itself as Google Update and Microsoft OneDrive Updater binaries.

The command-and-control (C2) infrastructure used in connection with the implant dates back to at least August 2020. An examination of VirusTotal submissions of the Agent Racoon artifacts shows that the earliest sample was uploaded in July 2022.

Unit 42 said it also uncovered evidence of successful data exfiltration from Microsoft Exchange Server environments, resulting in the theft of emails matching different search criteria. The threat actor has also been found to harvest victims' Roaming Profile.

"This tool set is not yet associated with a specific threat actor, and not entirely limited to a single cluster or campaign," Garcia said.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News

Russian Hacker Vladimir Dunaev Convicted for Creating TrickBot Malware

Dec 02, 2023NewsroomCybercrime / Malware

A Russian national has been found guilty in connection with his role in developing and deploying a malware known as TrickBot, the U.S. Department of Justice (DoJ) announced.

Vladimir Dunaev, 40, was arrested in South Korea in September 2021 and extradited to the U.S. a month later.

"Dunaev developed browser modifications and malicious tools that aided in credential harvesting and data mining from infected computers, facilitated and enhanced the remote access used by TrickBot actors, and created a program code to prevent the TrickBot malware from being detected by legitimate security software," the DoJ said.

"During Dunaev's participation in the scheme, 10 victims in the Northern District of Ohio, including Avon schools and a North Canton real-estate company, were defrauded of more than $3.4 million via ransomware deployed by TrickBot."

Dunaev, who pleaded guilty to committing computer fraud and identity theft and conspiracy to commit wire fraud and bank fraud, faces a maximum of 35 years in prison. He is scheduled to be sentenced on March 20, 2024.

Dunaev is also the second TrickBot gang malware developer to be arrested after Alla Witte, a Latvian national who, was sentenced to two years and eight months in prison in June 2023.

The development came nearly three months after the U.K. and U.S. governments sanctioned 11 individuals suspected of being part of the TrickBot cybercrime group.

TrickBot, which started off as a banking trojan in 2016, evolved into a multi-purpose tool capable of delivering additional payloads to infected hosts and acting as an initial access facilitator for ransomware attacks.

After surviving law enforcement to dismantle the botnet, the infamous Conti ransomware crew gained control over the operation. However, both Conti and TrickBot suffered a major blow last year following Russia's invasion of Ukraine, when Conti pledged allegiance to Russia.

This led to a series of leaks dubbed ContiLeaks and TrickLeaks that gave away valuable information about their internal chats and infrastructure, ultimately resulting in the shut down of Conti and its disintegration into numerous other groups.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News

Friday, December 1, 2023

New FjordPhantom Android Malware Targets Banking Apps in Southeast Asia

Dec 01, 2023NewsroomMobile Security / Banking Security

Cybersecurity researchers have disclosed a new sophisticated Android malware called FjordPhantom that has been observed targeting users in Southeast Asian countries like Indonesia, Thailand, and Vietnam since early September 2023.

"Spreading primarily through messaging services, it combines app-based malware with social engineering to defraud banking customers," Oslo-based mobile app security firm Promon said in an analysis published Thursday.

Propagated mainly via email, SMS, and messaging apps, attack chains trick recipients into downloading a purported banking app that comes fitted with legitimate features but also incorporates rogue components.

Victims are then subjected to a social engineering technique akin to telephone-oriented attack delivery (TOAD), which involves calling a bogus call center to receive step-by-step instructions for running the app.

A key characteristic of the malware that sets it apart from other banking trojans of its kind is the use of virtualization to run malicious code in a container and fly under the radar.

The sneaky method, Promon said, breaks Android's sandbox protections as it allows different apps to be run on the same sandbox, enabling the malware to access sensitive data without requiring root access.

"Virtualization solutions like the one used by the malware can also be used to inject code into an application because the virtualization solution first loads its own code (and everything else found in its app) into a new process and then loads the code of the hosted application," security researcher Benjamin Adolphi said.

In the case of FjordPhantom, the host app downloaded includes a malicious module and the virtualization element that's then used to install and launch the embedded app of the targeted bank in a virtual container.

In other words, the bogus app is engineered to load the bank's legitimate app in a virtual container while also employing a hooking framework within the environment to alter the behavior of key APIs to grab sensitive information from the application's screen programmatically and close dialog boxes used to warn malicious activity on users' devices.

"FjordPhantom itself is written in a modular way to attack different banking apps," Adolphi said. "Depending on which banking app is embedded into the malware, it will perform various attacks on these apps."

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News

New Tool Set Found Used Against Middle East, Africa and the US

A pictorial representation of malware like Agent Racoon, Ntospy and Mimilite. An open laptop against a blue background is flanked by exclamation points. On the laptop screen are overlapping windows with a bug icon representing the malware.

Executive Summary

Unit 42 researchers observed a series of apparently related attacks against organizations in the Middle East, Africa and the U.S. We will discuss a set of tools used in the course of the attacks that reveal clues about the threat actors’ activity. We are sharing this research to provide detection, prevention and hunting recommendations to help organizations strengthen their overall security posture.


These tools were used to perform the following activities:

  • Establish backdoor capabilities
  • For command and control (C2)
  • Steal user credentials.
  • Exfiltrate confidential information

Unit 42 is sharing these results with the purpose of helping organizations defend against the tools observed here.

We assess with medium confidence that this threat activity cluster aligns to nation-state related threat actors due to the nature of the organizations that were compromised, the TTPs observed and the customization of the tool set. We have not confirmed a particular nation-state or threat group.

Tools that were used in this cluster were the following:

  • A new backdoor we’ve named Agent Racoon
    • This malware family is written using the .NET framework and leverages the domain name service (DNS) protocol to create a covert channel and provide different backdoor functionalities. Threat actors have used this along with the other two tools in multiple attacks targeting organizations across the U.S., Middle East and Africa. Its C2 infrastructure dates back to 2020.
  • A new tool we’ve named Ntospy
    • This malware is a Network Provider DLL module designed to steal user credentials.
  • A customized version of Mimikatz called Mimilite

The compromised organizations belong to the following industries:

  • Education
  • Real estate
  • Retail
  • Non-profit organizations
  • Telecom companies
  • Governments

Based on unique similarities in tools as well as tactics, techniques and procedures (TTPs), we are tracking this threat activity cluster as CL-STA-0002.

What follows is a detailed description of the activity we observed as well as characteristics of the tool set.

Palo Alto Networks customers receive protection from these threats through Cortex XDR as well as Advanced URL Filtering, DNS Security and Advanced Wildfire. Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.

Table of Contents

Activity Summary
Gaining Access to Credentials with Ntospy
Credentials Dumping Through Mimilite
Agent Racoon Backdoor
Data Exfiltration
Indicators of Compromise
Additional Resources

Activity Summary

The threat actor used temporary directories such as C:\Windows\Temp and C:\Temp to deploy specific components of their tool set across the different affected organizations. They used the following similar filenames for batch and PowerShell scripts:

  • c:\windows\temp\crs.ps1
  • c:\windows\temp\ebat.bat
  • c:\windows\temp\install.bat
  • c:\windows\temp\mslb.ps1
  • c:\windows\temp\pb.ps1
  • c:\windows\temp\pb1.ps1
  • c:\windows\temp\pscan.ps1
  • c:\windows\temp\set_time.bat
  • c:\windows\temp\usr.ps1

While the attackers commonly used Ntospy across the affected organizations, the Mimilite tool and the Agent Racoon malware have only been found in nonprofit and government-related organizations’ environments.

After each attack session, the threat actor leveraged cleanmgr.exe to clean up the environment used during the session.

Gaining Access to Credentials with Ntospy

To perform credential theft, the threat actor used a custom DLL module implementing a Network Provider. A Network Provider module is a DLL component implementing the interface provided by Microsoft to support additional types of network protocols during the authentication process.

This technique is pretty well documented. Sergey Polak demonstrated the technique at BlackHat back in 2004 at his session titled “Capturing Windows Passwords using the Network Provider API.” In 2020, researcher Grzegorz Tworek uploaded his tool NPPSpy to GitHub, which also implements this technique.

Due to the file naming patterns of the DLL module, and as a reference to the previous research and tools, Unit 42 researchers named this malware family Ntospy. The threat actor registers the Ntospy DLL module as a Network Provider module to hijack the authentication process, to get access to the user credentials every time the victim attempts to authenticate to the system.

Figure 1 illustrates the path of the processes the malware used during the authentication process to load the malicious DLL module in an MS Exchange Server environment.

Image 1 is a screenshot of the different paths of the processes loading the DLL module in the Microsoft Exchange Server environment.
Figure 1. Image path of processes loading the malicious DLL component in an MS Exchange environment.

The threat actor’s implementation of this technique has some unique features. They created different versions of the Ntospy malware over the time frame we observed. They all share similarities, such as the following:

  • Using filenames with Microsoft patch patterns.
  • .msu extensions pretending to be Microsoft Update Package files to store the received credentials in cleartext.
  • RichPE header hashes that link different samples to the same compilation environment.

To install the DLL module, the threat actor registers a new Network Provider called credman. They do so by using an installation script found at C:\Windows\Temp\install.bat that installs the Network Provider by using reg.exe. The malware then sets the DLL module path by pointing to the malicious DLL module c:\windows\system32\ntoskrnl.dll.

Many lines of code. Attacker registers as credman.

Figure 2 shows static commonalities across the different DLL modules we identified as belonging to the same malware family. The image also illustrates that there are overlaps on the RichPE header hash as well as the PE sections of the samples.

Image 2 is a diagram of the static features as they relate across samples. Dark grey arrows leading from orange top-level icons point to red mid-level icons in the shape pf a virus. These in turn use light grey arrows to point to icons of files.
Figure 2. Graph of static features relation across samples.

In the group of samples with the same RichPE header hash, we saw that they had been compiled using the same environment. In this case, that was Visual Studio 2019 v16.0.0 build 27508. Other samples of the malware family have been compiled on different environments or even tweaked to avoid overlapping.

The samples that don’t share the same build environment are actually similar in behavior, but they have some differences in implementation. For instance, some of the malware samples contain the file path used to store the credentials hard-coded in plain text. Figures 3 and 4 show how others use an encrypted file path and stack strings.

Image 3 is a screenshot of many lines of code. It is the pseudocode showing the hard-coded file path as indicated by a red arrow.
Figure 3. Pseudocode showing the hard-coded file path in cleartext.
Image 4 is a screenshot of many lines of code. It is the pseudocode showing the encrypted file path as indicated by a red arrow.
Figure 4. Pseudocode showing the file path encrypted with a stream cipher.

Decrypting the file path at runtime shows that the versions using an encrypted file path also use the same file path pattern, as shown in Figure 5.

Image 5 is a screenshot of the file path decrypted at runtime. There are three columns visible: Address, Hex, ASCII.
Figure 5. File path decrypted at runtime.

All the DLL modules we identified use the same file path pattern, abusing the .msu file extension to masquerade as a Microsoft Update Package. The following paths are used by the malware samples:

  • c:/programdata/microsoft/~ntuserdata.msu
  • c:/programdata/package cache/windows10.0-kb5000736-x64.msu
  • c:/programdata/package cache/windows10.0-kb5009543-x64.msu
  • c:/programdata/packag~1/windows 6.1-kb4537803.msu

Also, the DLL files are stored in the following file paths:

  • C:\Windows\System32\ntoskrnl.dll
  • C:\Windows\Temp\ntoskrnl.dll
  • C:\Windows\Temp\ntos.dll

While the first file path is the one used to actually install the Network Provider module, the Temp directory is the working directory used by the threat actor to temporarily store the DLL modules. As shown in the file paths above, the threat actor used Windows binary name patterns (based on the Windows system file named ntoskrnl.exe) in an attempt to trick victims and analysts into overlooking the malicious DLL component.

The first activity is identified with the malware sample with the file hash SHA256 bcd2bdea2bfecd09e258b8777e3825c4a1d98af220e7b045ee7b6c30bf19d6df. This overlaps with another threat activity cluster that we call CL-STA-0043, originally published in June 2023.

Credentials Dumping Through Mimilite

Another tool used for gathering credentials and sensitive information is a customized version of the well-known Mimikatz tool that, according to references within the sample, the threat actor calls Mimilite.

The tool is a reduced version of Mimikatz, which needs to be given a password through the command line to run:

C:\temp\update.exe 1dsfjlosdf23dsfdfr

When the binary is executed, it takes the command-line argument as a decryption key to decrypt the actual payload using a stream cipher. Before executing the decrypted payload, the binary verifies that the payload has been successfully decrypted with the right key by performing an integrity check. This check is done by comparing the MD5 hash of the decrypted payload with the hard-coded value b855dfde7f778f99a3724802715a0baa, as shown in the code snippet in Figure 6.

Image 6 is a screenshot of many lines of code. Three red arrows indicate the execution logic.
Figure 6. Execution logic.

When executed properly, the tool dumps the credentials to the file path C:\Windows\Temp\KB200812134.txt. This choice of filename is another attempt by the threat actors to masquerade as a Microsoft update.

The Mimilite sample was found at C:\temp\update.exe with the file hash SHA256 3490ba26a75b6fb295256d077e0dbc13e4e32f9fd4e91fb35692dbf64c923c98. It was first uploaded to VirusTotal on 2020-05-11 05:43:00 UTC and first identified in the wild on 2021-02-12 21:54:35 UTC. What we find interesting is that according to VirusTotal, this sample has been uploaded and discovered in the wild using the following path and filename:




The elements of this path might suggest that the same binary has been involved in some sort of research that the uploader believed was linked with nation-state actors.

Agent Racoon Backdoor

The Agent Racoon malware family is built to provide backdoor capabilities. It is written using the .NET framework, and leverages DNS to establish a covert channel with the C2 server. Unit 42 researchers named the malware family Agent Racoon due to some references found within the code of the identified samples, as shown in Figure 7.

Image 7 is a screenshot of the .NET project details. There are entries for Assembly name, which is raccoon; Default namespace, which is agent; Target framework, which is .NET Framework 4; Output type, which is Console Application; and Startup object, which is agent.Program. Auto-generate binding redirects is not selected.
Figure 7. .NET Project details.

When executed, the threat has some predefined settings such as:

  • The base domain used to create the DNS covert channel
  • A unique key per sample, used as a seed to generate an encryption password to encrypt the DNS communication
  • A fallback DNS server if no DNS server can be read from the compromised system

All the C2 domains identified fulfill the same base pattern, with unique values for the four character identifier across different samples:

[4 characters].telemetry.[domain].com

The value of Program.dns_ip is different for each sample found, which could indicate that the threat actor is building the binary with specific settings gathered from the targeted environment.

Image 8 is a screenshot of many lines of code. Three red arrows indicate the main function of the malware sample.
Figure 8. Main function of the malware sample.

With that pattern, the threat communicates with the C2 server by adding additional subdomains to build the DNS query. It uses Internationalizing Domain Names for Applications’ (IDNA) domain names with Punycode encoding. This encoding type is a representation of Unicode values over the ASCII encoding for internet hostnames.

The domain names follow the pattern below:

[random_val].a.[4 characters].telemetry.[domain].com

The screenshot from Wireshark in Figure 9 illustrates a complete DNS query:

Image 9 is a screenshot of many lines of code. Indicated by a red bracket is the sample DNS query.
Figure 9. Sample DNS query.

To manage the communication with the C2 server, the malware uses a communication loop shown in Figure 10.

Image 10 is a screenshot of many lines of code. Four red arrows indicate the communication loop.
Figure 10. Communication loop.

The following are some main features of the communication loop above:

  • The communication loop finishes when the answer xn--cc is received from the C2 server, or a communication error occurs.
  • The randomized delay between messages can have multiple reasons:
    • To avoid network spikes.
    • To avoid potential network congestion.
    • To provide randomness as an attempt to avoid network beaconing detection.
  • The encryption of all the communication messages through Program.Util.RC.

The encryption routine implements a stream cipher that takes the initial unique key per sample Program.key (this.defaultkey), as shown in Figure 11. It then creates a 1-byte encryption key to later encrypt the message with an XOR.

Image 11 is a screenshot of many lines of code. Two red arrows point to instances of (this.defaultkey) and one red arrow points to the “message” line inside brackets.
Figure 11. Stream cipher routine.

Depending on the length of the message sent to the C2 server, different subdomains are added to the query, as shown in the code snippet in Figure 12.

Image 12 is a screenshot of many lines of code. Indicated by a red bracket is the crafting of a partial request.
Figure 12. Partial request crafting.

The this.Rand() component of the fully qualified domain name (FQDN) build is intended to avoid caching and ensure the request reaches out to the C2 server.

Agent Racoon provides the following backdoor functionality:

  • Command execution
  • File uploading
  • File downloading

Although Agent Racoon does not provide any sort of persistence mechanism by itself, during the activity we observed, the threat was executed by using scheduled tasks.

Unit 42 researchers discovered the following samples using different subdomains of telemetry.geoinfocdn[.]com, as shown in Figure 13. The domain geoinfocdn[.]com was registered on 2022/08/19 UTC for one year.

Image 13 is a hierarchy diagram of the malware samples linked to the file bath and the base command and control domain.
Figure 13. Samples linked with file path and base C2 domain.

Unit 42 researchers were able to track the Agent Racoon malware family back to July 2022. Two samples of the malware family were uploaded to VirusTotal from Egypt and Thailand in September 2022 and July 2022 with the following SHA256 hashes:

  • 3a2d0e5e4bfd6db9c45f094a638d1f1b9d07110b9f6eb8874b75d968401ad69c
  • dee7321085737da53646b1f2d58838ece97c81e3f2319a29f7629d62395dbfd1

These two samples used the same subdomain patterns, but this time the domain used for C2 was telemetry.geostatcdn[.]com. Threat actors performed the following activities regarding this domain on the dates shown:

  • Registered: 2020/08/27 UTC
  • First seen in the wild: 2021/06/17 23:10:58 UTC
  • Renewed: 2021/08/18 UTC
  • Expired: 2022/08/27 UTC

Figure 14 shows that with this information, two groups of malware samples can be identified using different C2 domain names and file paths since 2020.

Image 14 is a hierarchy diagram of the malware samples linked to the file path and the base command and control domain.
Figure 14. Malware samples identified.

The threat actor tried to disguise the Agent Racoon binary as Google Update and MS OneDrive Updater binaries.

The malware developers made small modifications to the source code in an attempt to evade detection. Some samples used a domain hard-coded in plain text to establish the DNS covert channel (as shown in Figure 15), whereas other samples used a Base64 encoded string.

Image 15 is a screenshot of many lines of code. Red arrows indicate the command and control domain string.
Figure 15. Base64 encoded C2 domain.

Aside from the Base64 feature, the differences are in the settings and not in the actual source code, except for the sample with SHA256 hash 354048e6006ec9625e3e5e3056790afe018e70da916c2c1a9cb4499f83888a47.

This sample has a compilation timestamp that was modified and is outside the time frame of activity: 2075/02/23 08:12:59 UTC.

As shown in Figure 16, the threat actor also tried to obfuscate the constant cmd.exe to avoid signature-based detections. They did so by using the equivalent Base64 encoded value with the added constant 399 so the equivalent Base64 encoded string can’t be detected through signatures.

Image 16 is two screenshots side by side. Red arrows point to the obfuscated cmd.exe pattern found in the samples.
Figure 16. Obfuscated cmd.exe pattern.

Data Exfiltration

Unit 42 researchers also identified the collection and successful exfiltration of confidential information, such as emails from MS Exchange environments, using PowerShell snap-ins to dump the emails.

PowerShell snap-in code to dump emails

In the search criteria from the command above, the threat actor used similar commands to search through different folders, mailboxes and dates to dump those emails.

After dumping the emails, the threat actor tried to compress the .pst file with a command-line RAR tool before exfiltrating it:

Command-line RAR tool to compress the .pst file.

However, the threat actor canceled the attempt to compress the .pst file by using the tool taskkill.exe approximately eight minutes later.

PowerShell snap-in code to dump emails

Eventually the threat actor discarded the usage of raren.exe and simply renamed the .pst file, moving it to the IIS root directory and mimicking an error log in a compressed file to download it through the web server.

Command-line RAR tool to compress the .pst file.

And finally, the ai.pst file is removed.

Use of tool taskkill to cancel the compression attempt.

This process is repeated for several mailboxes with different search criteria.

In addition to the email exfiltration, Unit 42 researchers identified exfiltration of the victim’s Roaming Profile. A Roaming Profile is used to serve the same profile to the user when logging in from different computers from the same Active Directory environment.

To exfiltrate this, the threat actor compressed the directory by using the standalone version of the 7-Zip tool (which they dropped into the system using certutil.exe), and split the compressed file into chunks of 100 MB.

Removing the ai dot pst file.

Compressing the directory. Splitting the file into segments of 100 MB.

Later, following the same procedure, the threat actor exfiltrated the content.

Exfiltration of content.


Our hope in sharing the descriptions of this tool set is that readers can use this information to search their networks to identify other possible attacks using these tools. This tool set is not yet associated with a specific threat actor, and not entirely limited to a single cluster or campaign.

As mentioned at the beginning of this article, we found an overlapping Ntospy sample with SHA256 bcd2bdea2bfecd09e258b8777e3825c4a1d98af220e7b045ee7b6c30bf19d6df with a previously identified threat activity cluster CL-STA-0043. However, the overlaps are not limited to that sample.

We have also identified two compromised organizations in common across both activity clusters. Some of the TTPs match on both clusters, such as the MS Exchange PowerShell snap-ins and one of the Network Provider DLL modules.

Unit 42 researchers believe this threat activity cluster aligns with medium confidence to nation-state related threat actors for the following reasons:

  • The detection and defense evasion techniques used
  • The exfiltration activity observed
  • The victimology
  • The customization level of the tools used
  • The TTPs observed

Palo Alto Networks customers receive protections from the threats discussed above through the following products:

  • Cortex XDR includes detections and protections related to the IoCs shared in this research
  • Advanced URL Filtering and DNS Security blocks related C2 domains as malicious
  • The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.


During the research activity related to the tool set uncovered on this blog, Unit 42 researchers identified a set of TTPs, which we’ve mapped to the MITRE ATT&CK matrix in the table below.

ID Name
T1003 OS Credential Dumping
T1018 Remote System Discovery
T1021.006 Remote Services: Windows Remote Management
T1027.009 Obfuscated Files or Information: Embedded Payloads
T1030 Data Transfer Size Limits
T1036.005 Masquerading: Match Legitimate Name or Location
T1036.008 Masquerading: Masquerade File Type
T1041 Exfiltration Over C2 Channel
T1046 Network Service Discovery
T1047 Windows Management Instrumentation
T1053.005 Scheduled Task/Job: Scheduled Task
T1059.001 Command and Scripting Interpreter: PowerShell
T1059.003 Command and Scripting Interpreter: Windows Command Shell
T1070.004 Indicator Removal: File Deletion
T1070.006 Indicator Removal: Timestomp
T1071.004 Application Layer Protocol: DNS
T1074 Data Staged
T1078.002 Valid Accounts: Domain Accounts
T1087.002 Account Discovery: Domain Account
T1112 Modify Registry
T1114 Email Collection
T1132.001 Data Encoding: Standard Encoding
T1136.002 Create Account: Domain Account
T1140 Deobfuscate/Decode Files or Information
T1505.003 Server Software Component: Web Shell
T1556.008 Modify Authentication Process: Network Provider DLL
T1560.001 Archive Collected Data: Archive via Utility
T1564.002 Hide Artifacts: Hidden Users
T1570 Lateral Tool Transfer
T1573.001 Encrypted Channel: Symmetric Cryptography
T1583.001 Acquire Infrastructure: Domains
T1583.002 Acquire Infrastructure: DNS Server
T1587.001 Develop Capabilities: Malware

Indicators of Compromise

IoC Type Description
2632bcd0715a7223bda1779e107087964037039e1576d2175acaf61d3759360f SHA256 C:\Windows\Temp\install.bat
ae989e25a50a6faa3c5c487083cdb250dde5f0ecc0c57b554ab77761bdaed996 SHA256 C:\Windows\Temp\install.bat
C:\Windows\Temp\install.bat File path Script to install the Network Provider module
c:/programdata/microsoft/~ntuserdata.msu  File path File to store the stolen user credentials
c:/programdata/packag~1/windows 6.1-kb4537803.msu File path File to store the stolen user credentials
c:/programdata/package cache/windows10.0-kb5009543-x64.msu  File path File to store stolen user credentials
c:/programdata/package cache/windows10.0-kb5000736-x64.msu  File path File to store stolen user credentials
credman Network provider name Network Provider name
HKLM\SYSTEM\CurrentControlSet\Services\credman Registry key path Registry path of the Network Provider
c:\windows\system32\ntoskrnl.dll File path Network Provider module file path
C:\Windows\Temp\ntos.dll File path File path used to temporarily store the DLL module
C:\Windows\Temp\ntoskrnl.dll File path File path used to temporarily store the DLL module
e30f8596f1beda8254cbe1ac7a75839f5fe6c332f45ebabff88aadbce3938a19 SHA256 Ntospy DLL Module
1a4301019bdf42e7b2df801e04066a738d184deb22afcad9542127b0a31d5cfa SHA256 Ntospy DLL Module
e7682a61b6c5b0487593f880a09d6123f18f8c6da9c13ed43b43866960b7aa8e SHA256 Ntospy DLL Module
58e87c0d9c9b190d1e6e44eae64e9a66de93d8de6cbd005e2562798462d05b45 SHA256 Ntospy DLL Module
7eb901a6dbf41bcb2e0cdcbb67c53ab722604d6c985317cb2b479f4c4de7cf90 SHA256 Ntospy DLL Module
f45ea12579f636026d29009190221864f432dbc3e26e73d8f3ab7835fa595b86 SHA256 Ntospy DLL Module
bcd2bdea2bfecd09e258b8777e3825c4a1d98af220e7b045ee7b6c30bf19d6df SHA256 Ntospy DLL Module
C:\temp\update.exe File path Mimilite
1dsfjlosdf23dsfdfr Encryption key Mimilite decryption key
b855dfde7f778f99a3724802715a0baa MD5 Mimilite payload hash
4351911f266eea8e62da380151a54d5c3fbbc7b08502f28d3224f689f55bffba SHA256 Agent Racoon
e0748ce315037253f278f7f8f2820c7dd8827a93b6d22d37dafc287c934083c4 SHA256 Agent Racoon
baed169ce874f6fe721e0d32128484b3048e9bf58b2c75db88d1a8b7d6bb938d SHA256 Agent Racoon
3a2d0e5e4bfd6db9c45f094a638d1f1b9d07110b9f6eb8874b75d968401ad69c SHA256 Agent Racoon
4351911f266eea8e62da380151a54d5c3fbbc7b08502f28d3224f689f55bffba SHA256 Agent Racoon
354048e6006ec9625e3e5e3056790afe018e70da916c2c1a9cb4499f83888a47 SHA256 Agent Racoon
dee7321085737da53646b1f2d58838ece97c81e3f2319a29f7629d62395dbfd1 SHA256 Agent Racoon
geostatcdn[.]com Domain C2
telemetry.geostatcdn[.]com Domain C2
fdsb.telemetry.geostatcdn[.]com Domain C2
dlbh.telemetry.geostatcdn[.]com Domain C2
lc3w.telemetry.geostatcdn[.]com Domain C2
hfhs.telemetry.geostatcdn[.]com Domain C2
geoinfocdn[.]com Domain C2
telemetry.geoinfocdn[.]com Domain C2
g1sw.telemetry.geoinfocdn[.]com Domain C2
c:/windows/temp/onedriveupdater.exe File path Agent Racoon path
c:/windows/system32/msmdlb.exe File path Agent Racoon path
c:/windows/temp/onedriveupdater.exe File path Agent Racoon path
c:/program files (x86)/google/update/googleupdate.exe File path Agent Racoon path
c:\windows\temp\mslb.ps1 File path Script used to deploy the Agent Racoon
c:\windows\temp\set_time.bat File path Script used to perform timestomping against additional tools
c:\windows\temp\pscan.ps1 File path Script to scan the network
c:\windows\temp\crs.ps1 File path Helper script
c:\windows\temp\usr.ps1 File path Helper script
c:\windows\temp\pb.ps1 File path Helper script
c:\windows\temp\ebat.bat File path Helper script 
c:\windows\temp\pb1.ps1 File path Helper script
c:\windows\temp\raren.exe File path Command line RAR
aabbcc123 Password Password used to create the email archive
086a6618705223a8873448465717e288cf7cc6a3af4d9bf18ddd44df6f400488 SHA256 raren.exe file hash
P@ssw0rd1 Password Password used to compress the user profile directory
Assistance$ Username User created for persistence
Zaqwsx123 Password User created for persistence

Additional Resources

Get updates from
Palo Alto

Sign up to receive the latest news, cyber threat intelligence and research from us

from Unit 42

Discover How Gcore Thwarted Powerful 1.1Tbps and 1.6Tbps DDoS Attacks

Dec 01, 2023The Hacker NewsNetwork Security / Cyber Attack

The most recent Gcore Radar report and its aftermath have highlighted a dramatic increase in DDoS attacks across multiple industries. At the beginning of 2023, the average strength of attacks reached 800 Gbps, but now, even a peak as high as 1.5+ Tbps is unsurprising. To try and break through Gcore's defenses, perpetrators made two attempts with two different strategies. Read on to discover what happened and learn how the security provider stopped the attackers in their tracks without affecting end users' experiences.

A Powerful DDoS Attacks

In November 2023, one of Gcore's customers from the gaming industry was targeted by two massive DDoS attacks, peaking at 1.1 and 1.6 Tbps respectively. The attackers deployed various techniques in an unsuccessful attempt to compromise Gcore's protective mechanisms.

Attack #1: 1.1 Tbps UDP-based DDoS

In the first cyber assault, the attackers sent a barrage of UDP traffic to a target server, peaking at 1.1 Tbps. Two methods were employed:

  • By using random UDP source ports, they hoped to evade conventional filtering mechanisms.
  • The attackers concealed their genuine identity by forging source IP addresses.

This was a classic flood (or volumetric) attack, whereby the attackers hoped to consume all available bandwidth of or to a data center or network, overwhelming the target servers with traffic and making them unavailable to legitimate users.

The graph below shows customer's traffic during the attack. The peak of 1.1 Tbps shows an aggressive but short-lived attempt to flood the network with data. The green line ("total.general.input") shows all inbound traffic. The other colored lines on the graph represent the network's responses, including measures to filter and drop malicious traffic, as the system manages the deluge of data.

Line graphs showing a spike in a Gcore customer's network traffic, peaking at 1.1 Tbps, indicative of a substantial DDoS attack
The attack comprised a short but intense peak of 1.1 Tbps around 22:55

Attack #2: 1.6 Tbps TCP-based DDoS

Graph of nine-hour attack with consistent traffic volume of 700 Mbps and peak of 1600 Mbps at the onset
The attack's consistent traffic volume was 700 Mbps and at the onset peaked at 1600 Mbps

This time, the attackers attempted to exploit TCP protocol with a mix of SYN flood, PSH, and ACK traffic.

In a SYN flood attack, several SYN packets are delivered to the target server without ACK packets. This means the server generates a half-open connection for each SYN packet. If successful, the server will ultimately run out of resources and stop accepting connections.

The PSH, ACK phase of the attack rapidly sends data to the target system. The ACK flag signals that the server received the previous packet. This pushes the system to handle data promptly, wasting resources. A SYN flood assault using PSH, ACK packets is harder to defend against than a SYN flood, since the PSH flag causes the server to process the packet contents immediately, consuming more resources.

As before, the goal was to overload the customer's servers and make their services inaccessible to authorized users. This SYN flood had a peak volume of 685.77 Mbps and the PSH, ACK had a magnitude of 906.73 Mbps.

Gcore's Defensive Strategies

Gcore's DDoS Protection effectively neutralized both attacks while preserving regular service for the customer's end users. The general approach of fending off DDoS security threats includes several techniques, such as Gcore's front-line defenses:

  • Dynamic traffic shaping: Dynamically adjusted traffic rates effectively mitigate the impact of the attack while ensuring the continuity of critical services. In order to prioritize genuine traffic while slowing harmful transmissions, adaptive thresholds and rate restrictions are used.
  • Anomaly detection and quarantine: Models based on machine learning analyze behavior to identify anomalies. When an anomaly occurs, automated quarantine mechanisms redirect erroneous traffic to isolated segments for additional analysis.
  • Regular expression filters: To block malicious payloads without disrupting legitimate traffic, regular expression-based filter rules are implemented. Their continuous fine-tuning ensures optimal protection without false positives.
  • Collaborative threat intelligence: Gcore actively engages in the exchange of threat intelligence with industry peers. Collective insights and real-time threat feeds guide Gcore's security techniques, allowing a rapid response to developing attack vectors.

By employing these strategies, Gcore was able to effectively mitigate the impact of DDoS attacks and protect their customer's platform from disruption, negating potential reputational and financial losses.


DDoS attacks of 1.5+ Tbps volume pose an increasing danger across industries, with attackers using imaginative techniques to try and bypass protection services. Over the course of 2023, Gcore has registered increases in both average and maximum attack volumes, and these two connected attacks demonstrate that trend.

In the attacks covered in the article, Gcore was able to prevent any damage through a combination of dynamic traffic shaping, anomaly detection, regular expression filters, and collaborative threat intelligence. Explore DDoS Protection options to secure your network against ever-evolving DDoS threats.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News

WhatsApp's New Secret Code Feature Lets Users Protect Private Chats with Password

Dec 01, 2023NewsroomPrivacy / Data Protection

Meta-owned WhatsApp has launched a new Secret Code feature to help users protect sensitive conversations with a custom password on the messaging platform.

The feature has been described as an "additional way to protect those chats and make them harder to find if someone has access to your phone or you share a phone with someone else."

Secret Code builds on another feature called Chat Lock that WhatsApp announced in May, which moves chats to a separate folder of their own such that they can be accessed only upon providing their device password or biometrics.

By setting a unique password for these locked chats that are different from the password used to unlock the phone, the aim is to give users an additional layer of privacy, WhatsApp noted.

"You'll have the option to hide the Locked Chats folder from your chatlist so that they can only be discovered by typing your secret code in the search bar," it added.

The development comes weeks after WhatsApp introduced a "Protect IP Address in Calls" feature that masks users' IP addresses to other parties by relaying the calls through its servers.

It also follows calls by the French government urging ministers, secretaries of state, and cabinet members to refrain from using popular messaging apps like WhatsApp, Signal, and Telegram in favor of homegrown alternatives like Tchap (based on the Matrix protocol) and Olvid by December 8, 2023.

The news, which was first reported by Le Point, cited a circulated document that claimed: "these digital tools are not devoid of security vulnerabilities and therefore do not ensure the security of conversations and information shared through them."

In response, Meredith Whittaker, president of Signal, hit back at the French government's decision, stating, "this claim is not backed by any evidence, and is dangerously misleading esp. coming from gov." Will Cathcart, the head of WhatsApp, concurred, saying, "we are of the same opinion."

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News

U.S. Treasury Sanctions North Korean Kimsuky Hackers and 8 Foreign Agents

Dec 01, 2023NewsroomCyber Espionage / Cryptocurrency

The U.S. Department of the Treasury's Office of Foreign Assets Control (OFAC) on Thursday sanctioned the North Korea-linked adversarial collective known as Kimsuky as well as eight foreign-based agents who are alleged to have facilitated sanctions evasion.

The agents, the Treasury said, helped in "revenue generation and missile-related technology procurement that support the DPRK's weapons of mass destruction (WMD) programs."

The sanctions against Kimsuky for gathering intelligence to support the regime's strategic objectives, come more than four years after the OFAC imposed similar measures against the Lazarus Group and its offshoots Andariel and BlueNoroff in September 2019.

The actions are in response to North Korea's launch of a military reconnaissance satellite late last month, the Treasury added. They also arrive a day after a virtual currency mixer service called Sinbad was sanctioned for processing stolen assets linked to hacks perpetrated by the Lazarus Group.

Kimsuky – also called APT43, ARCHIPELAGO, Black Banshee, Emerald Sleet (previously Thallium), Nickel Kimball, and Velvet Chollima – is a prolific cyber espionage crew that primarily targets governments, nuclear organizations, and foreign relations entities to collect intelligence that help further North Korea's interests.

"The group combines moderately sophisticated technical capabilities with aggressive social engineering tactics, especially against South Korean and U.S.-based government organizations, academics, and think tanks focused on Korean peninsula geopolitical issues," Google-owned Mandiant noted in October 2023.

Like the Lazarus Group, it's also an element within the Reconnaissance General Bureau (RGB), which is North Korea's primary foreign intelligence service that's responsible for intelligence collection operations. It's known to be active since at least 2012.

"Kimsuky employs social engineering to collect intelligence on geopolitical events, foreign policy strategies, and diplomatic efforts affecting its interests by gaining illicit access to the private documents, research, and communications of their targets," the Treasury said.

The agency also identified Kang Kyong Il, Ri Sung Il, and Kang Phyong Guk for acting as weapons sales representatives; So Myong, Choe Un Hyok, and Jang Myong Chol for engaging in illicit financial transfers to procure material for North Korea's missile programs; and Choe Song Chol and Im Song Sun for running front companies involved in generating revenue by exporting skilled workers.

"The geographic breakdown of North Korean threat groups' targeting in the cryptocurrency industry [follows a multi-pronged approach], where Kimsuky has been seen targeting the cryptocurrency industry in South Korea, and Lazarus Group has a more global presence in their cryptocurrency targeting operations," Recorded Future said in a new report published this week.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News

Zyxel Releases Patches to Fix 15 Flaws in NAS, Firewall, and AP Devices

Dec 01, 2023NewsroomFirewall / Network Security

Zyxel has released patches to address 15 security issues impacting network-attached storage (NAS), firewall, and access point (AP) devices, including three critical flaws that could lead to authentication bypass and command injection.

The three vulnerabilities are listed below -

  • CVE-2023-35138 (CVSS score: 9.8) - A command injection vulnerability that could allow an unauthenticated attacker to execute some operating system commands by sending a crafted HTTP POST request.
  • CVE-2023-4473 (CVSS score: 9.8) - A command injection vulnerability in the web server that could allow an unauthenticated attacker to execute some operating system commands by sending a crafted URL to a vulnerable device.
  • CVE-2023-4474 (CVSS score: 9.8) - An improper neutralization of special elements vulnerability that could allow an unauthenticated attacker to execute some operating system commands by sending a crafted URL to a vulnerable device.

Also patched by Zyxel are three high-severity flaws (CVE-2023-35137, CVE-2023-37927, and CVE-2023-37928) that, if successfully exploited, could allow attackers to obtain system information and execute arbitrary commands. It's worth noting that both CVE-2023-37927 and CVE-2023-37928 require authentication.

The flaws impact the following models and versions -

  • NAS326 - versions V5.21(AAZF.14)C0 and earlier (Patched in V5.21(AAZF.15)C0)
  • NAS542 - versions V5.21(ABAG.11)C0 and earlier (Patched in V5.21(ABAG.12)C0)

The advisory comes days after the Taiwanese networking vendor shipped fixes for nine flaws in select firewall and access point (AP) versions, some of which could be weaponized to access system files and administrator logs, as well as cause a denial-of-service (DoS) condition.

With Zyxel devices often exploited by threat actors, it's highly recommended that users apply the latest updates to mitigate potential threats.

Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News

Improving FLARE’s Malware Analysis Tools at Google Summer of Code 2023

This summer marked the FLARE team’s first year participating in Google Summer of Code (GSoC). GSoC is a global online mentoring program focused on introducing new contributors to open source software development. GSoC contributors work with mentors to complete 12+ week projects that support open source organizations. During 2023 FLARE was accepted into GSoC and had the privilege of working with four contributors.

FLARE is a team of reverse engineers and researchers who specialize in malware analysis, exploit analysis, and malware training. FLARE develops, maintains, and publishes various open-source tools to improve binary analysis.

Each of our 2023 GSoC contributors’ projects added new features to FLARE’s open source malware analysis tooling. This blog post kicks off a series of blog posts with the goal of introducing you to our contributors and their projects. 

Here is an overview of the FLARE 2023 GSoC projects:


Tool: FakeNet-NG redirects and intercepts network traffic.


GSoC Project: Beleswar Prasad Padhi developed an HTML interface for FakeNet-NG that displays network indicators in an analyst-friendly way.


Tool: FLOSS extracts and deobfuscates strings from programs.


GSoC Project: Arnav Kharbanda extended FLOSS to extract language-specific strings from Go and Rust programs.


Tool: capa identifies capabilities in programs.


GSoC Project: Colton Gabertan integrated capa with Ghidra, the NSA’s open source reverse engineering tool.


GSoC Project: Yacine Elhamer extended capa to identify capabilities in dynamic sandbox traces, specifically for the CAPE sandbox.

GSoC Contributor Introductions

We asked our 2023 GSoC contributors to introduce themselves and answer a few questions related to their experiences this summer. Before they answer in their own words, we’d like to acknowledge the great work each and everyone did. It was a pleasure collaborating, discussing, and advancing the projects. We learned a lot from this program and look forward to similar experiences in the future.

Beleswar Prasad Padhi

I am Beleswar, a final-year Computer Science undergraduate based in India. My primary field of interest is cyber security and software development. I am an open source enthusiast and firmly believe that contributing to open source software shapes the world of software. I frequently participate in Capture The Flag (CTF) competitions to take on security challenges for fun. I have been using Linux as my main system for the past three years (I use Arch). I aspire to pursue my career as a software engineer.

How did you learn about GSoC and about FLARE?

I learned about GSoC through one of my acquaintances who has been working in the software industry. After reading about GSoC and hearing about past contributors' experiences, I felt motivated to apply for the program. Since I was particularly interested in projects in the security domain, FLARE caught my attention as a pioneer in reverse engineering. I started researching FLARE projects and became excited about contributing to them, thus deciding to apply for FLARE.

What motivated you to apply to your selected project?

My project involved working with FakeNet-NG, a network analysis tool. I had significant experience with the tech stack required for my project. Then I began exploring the FakeNet-NG tool, and this motivated me to contribute code to a tool widely utilized for malware analysis purposes. I was particularly impressed by the project scope, which aimed to simplify the work of malware analysts by generating a summarized report of the network-based indicators captured during FakeNet-NG sessions.

What were some challenges that you had to overcome?

Coming up with initial solutions for issues can be sufficient, but the real challenge lies in devising optimal solutions. To achieve that, I had to delve deep into networking protocols and advanced coding concepts in Python, such as callbacks, abstraction, and mixins. Another challenge I faced was balancing academics at my university with working on the project. To tackle this, I developed a time management plan to effectively learn new concepts while maintaining my academics.

What did you learn from this experience?

This project introduced me to network programming and systems programming in depth. It taught me to receive code reviews and feedback positively and work on them diligently. I got familiarized with the project's coding practices, such as object-oriented programming, code styles, linting, etc. Additionally, I have also developed many soft skills, like communication, time management, task scheduling, and progress tracking.

What advice do you have for future GSoC contributors?

Remaining open to "learning on the fly" is vital for tackling project challenges that arise. Communication is essential. Keep your mentor updated on your progress and discuss any roadblocks you encounter. Don't hesitate to request debugging sessions, it can provide new perspectives on problem-solving. Engage in brainstorming for solutions and seek feedback to improve your work. GSoC's greatest privilege is having a dedicated, experienced mentor. Make the most out of it.

Arnav Kharbanda

Hey, I'm Arnav Kharbanda, currently a junior in Computer Science at IIT Ropar, India. I started my journey over five years ago with a keen passion for making secure systems and contributing to open source software by solving problems that benefit society. I also love playing soccer, going on long treks, and participating in CTF competitions.

How did you learn about GSoC and about FLARE?

I learned about it from my friend and classmate, Shobhit, with whom I have frequently collaborated on cybersecurity initiatives and participated in CTF competitions.

What motivated you to apply to your selected project?

The convergence of my passion for cybersecurity, active engagement in CTF competitions, and a growing excitement for delving into the world of open source technology were the main driving forces behind my decision to apply for this specific project.

What were some challenges that you had to overcome?

Initially, wrestling with my own laziness was like trying to convince a cat to take a bath. Although I had some experience with CTF competitions, I had limited knowledge about reverse engineering. As I progressed, I also faced other hurdles, like managing intricate merge conflicts and setting up Continuous Integration (CI) tests.

What did you learn from this experience?

Besides learning about coding aspects such as coding style, CI testing, Docker, and optimizing Python code, I also improved my communication skills.

What advice do you have for future GSoC contributors?

Just dive in. Get involved in what you love. Take the first step and get started.

Colton Gabertan

I'm Colton Gabertan, a senior Computer Science student at the University of Nevada Las Vegas. I became interested in reverse engineering and malware analysis during my sophomore year through CTF competitions and ended up interning with the FLARE team a year later.

How did you learn about GSoC and about FLARE?

I learned about the FLARE team through CTF competitions as well as through Mandiant's reputation in the information security industry. GSoC was a new addition after Mandiant's acquisition and was introduced to me by word-of-mouth from the FLARE team. 

What motivated you to apply to your selected project?

My motivation to apply to the project to integrate capa and Ghidra was knowing that it would enable more reverse engineers to analyze malware in an extremely efficient manner. I also wanted to learn more about capa’s design and sharpen my programming skills along the way.

What were some challenges that you had to overcome?

Some of the biggest challenges involved learning the Ghidra scripting API thoroughly enough to create a production-ready product within the allocated GSoC period as well as integrate the relatively new project, Ghidrathon, as a core aspect of its design.  

What did you learn from this experience?

I obtained a much deeper understanding of the Ghidra framework and capa. In doing so, I was able to learn how to make better choices when it came to programmatically handling large amounts of binary data and processing it in a meaningful way. A new skill that was picked up from my experience is the automation of testing code and how to set up CI workflows. 

What advice do you have for future GSoC contributors?

Stay open-minded and willing to learn all about the project you have chosen. Engage with the community and your fellow contributors, and don't be afraid to ask any and all questions, especially to the mentors. As a final tip, when creating your proposed timeline for the planned deliverables, design it in a way that allows for flexibility and buffer room as unexpected events and other obligations are more than likely to affect your progress.

Yacine Elhamer

My name is Yacine Elhamer. I have a Bachelor's degree in Computer Science from USTHB Algiers, and I am currently doing a Master's in Cybersecurity at the University of Turku in Finland. I am passionate primarily about malware analysis, security research, and software development.

How did you learn about GSoC and about FLARE?

I first learned about GSoC from my older brother who participated in it years ago by means of the Pharo programming language, and also through a friend who worked on Rapid7's Metasploit project last year. As for FLARE, I have already been familiar with them from the FLARE-On annual CTF competition, as well many of their tools which I have been actively using such as FLARE-VM.

What motivated you to apply to your selected project?

Coming into this year's GSoC application period, I was mainly looking for a cybersecurity-related project since that is the area I am most passionate about. I was also intending to prioritize projects which use Python and/or C since those are my two favorite languages to work with. Luckily enough, I found that FLARE was doing GSoC this year, and that they were offering innovative projects for their malware analysis tools.

What were some challenges that you had to overcome?

Some of the main challenges were mainly due to capa’s popularity making its code refactoring more complicated. We had to make sure not to morph the tool too much so that it would render existing capa rules and scripts useless. All while ensuring maximal use of all the new features that dynamic analysis could bring to capa.

What did you learn from this experience?

I learned several valuable skills from my summer with FLARE. Namely, technical ones such as software design, malware analysis concepts, use of several Python libraries (pytest, pydantic, etc.), and the practical experience of working in parallel with a team on a project using Git. I also improved my communication skills and organizational skills such as time management and task prioritization.

What advice do you have for future GSoC contributors?

I highly encourage contributors to utilize the community bonding period, since it is an excellent way to get to know what working with an organization and your mentors is like ahead of the project start.

Additional Contributors

The FLARE team wants to thank the additional contributors who noticed and supported our projects through GSoC. It’s been a rewarding experience collaborating with so many motivated people interested in open source and security projects. Among the dozens of contributors we would like to especially thank Aayush Goel and Deeya Singh.

Aayush provided numerous new features, code improvements, and bug fixes, landing 13 merged pull requests for capa. These included a script to highlight features which are unused during matching and adding feature support for COM classes and interfaces.

Deeya is currently working on a website that describes capa and exposes the default rule set – the related tasks are tracked on GitHub.


We hope that you enjoyed getting to know and learning about the experiences of our 2023 GSoC contributors. Each contributor collaborated with their FLARE mentors to write a blog post that covers their project in greater detail. Keep an eye out as we release these posts in the upcoming weeks.


from All Blog Listing

Thursday, November 30, 2023

Exploring a Critical Risk in Google Workspace's Domain-Wide Delegation Feature

A pictorial representation of a vulnerability such as that found in Google Workspace. A stylized cloud with a lock hanging from it surrounded by technical tools. The Palo Alto Networks and Unit 42 logos.

Executive Summary

Unit 42 researchers discovered a security risk in the Google Workspace (formerly known as G Suite) domain-wide delegation feature. We exposed an unexpected way to gain access to the Google Workspace domain data from Google Cloud Platform (GCP).

We found that a GCP identity with the necessary permission can generate an access token to a delegated user. A malicious insider or an external attacker with stolen credentials can use this access token to impersonate Google Workspace users, granting unauthorized access to their data or to perform operations on their behalf.

In this article, we will highlight the risk of the Google Workspace domain-wide delegation feature. In doing so, we will explore its potential misuse by malicious actors and examine the implications for the security of Google Workspace data.

As organizations increasingly rely on the power of cloud-based services like Google Workspace and Google Cloud Platform GCP, it becomes crucial to delve into the intricacies of their security features and vulnerabilities. We will discuss the link between GCP and Google Workspace and examine how the GCP permission model can impact the security of Google Workspace.

Palo Alto Networks customers receive protection from the issue discussed in this article through Cortex XDR and Prisma Cloud.

Table of Contents

Domain-Wide Delegation Misuse Overview
Google Workspace
What Is a Service Account?
What Is Domain-Wide Delegation?
How Does Domain-Wide Delegation Work?
Understanding the Risks and Implications of the Domain-Wide Delegation Feature
Using Audit Logs From Both Ends to Identify Potential Misuse
Disclosure Timeline

Domain-Wide Delegation Misuse Overview


A possible attack path shown in Figure 1 could be a malicious insider (e.g., a developer with editor permissions in a GCP project) exploiting their access. They could do so by abusing a service account that is granted domain-wide delegation permissions in Google Workspace. The insider has permission to generate access tokens to service accounts within the same GCP project.

Image 1 is a diagram of the attack scenario. The objects inside the blue box represent the organization. From the World Wide Web, inside the Google workspace cloud is the computer default service account and the service account. A red arrow points to Google Workspace, including Gmail, Calendar, Google Drive. The super admin has access to the grey boxes representing administration, research and development, and finance. A yellow arrow points back from the super admin to the service account.
Figure 1. Second attack scenario.

With the domain-wide delegation permissions enabled, a malicious insider can impersonate users in the Google Workspace domain and use the access tokens to authenticate API requests. By leveraging the appropriate scopes and API access, the insider can access and retrieve sensitive Google Workspace data, potentially compromising emails, documents and other confidential information stored within the domain. Such actions highlight the threats of the domain-wide delegation feature.

A worst case scenario would come about if an attacker has obtained a GCP service account token attached to a compute engine instance (e.g., the compute engine default service account, which has editor permissions by default). From there, the attacker may be able to exploit the domain-wide delegation feature for larger impact. If in the same project, a service account with domain-wide delegation exists, this can lead the attacker to impersonate the delegated service account and move laterally from GCP to gain access to the Google Workspace environment.

Google Workspace

Before we delve into the intricacies of a recent security risk that surfaced within Google Workspace and GCP, it is crucial to establish a solid foundation of understanding about these powerful cloud-based services.

Google Workspace apps are a collection of cloud-based collaboration tools. Organizations use Google Workspace to enhance their productivity and communication through various tools such as the following:

  • Email
  • Calendar
  • File storage and sharing
  • Team communication
  • Workflow automation
  • Security
  • Administration

Google Workspace provides role-based access control (RBAC) capabilities and allows administrators to assign specific roles to users, granting them predefined sets of permissions based on their responsibilities and needs. These roles include the following:

  • Super admin
  • Groups admin
  • User management admin

Each role has specific privileges and controls over different aspects of the organization's Google Workspace environment. The Google Workspace super admin holds elevated permissions and broader domain management responsibilities, including the ability to grant domain-wide delegation permission to service accounts, which we will explore in more detail later.

Google Workspace administrators can also define application-specific permissions and restrict sharing and visibility settings. For example, an administrator can enforce policies that prevent users from publicly sharing files and limit sharing options to ensure files remain within authorized boundaries.

A common use case for a link between GCP and Google Workspace is when an application hosted on GCP needs to interact with one of the Google Workspace services. These services include the following:

  • Gmail
  • Calendar
  • Drive
  • Docs

This integration allows the application to access and manipulate user-specific data, perform actions on behalf of users, or leverage the collaboration and productivity features of Google Workspace.

A delegated GCP service account is required to create an application that interacts with Google services, accesses Google APIs, handles users' data or performs actions on their behalf.

What Is a Service Account?

A service account is a special type of account in GCP that represents nonhuman entities, such as applications or virtual machines. It allows them to authenticate and interact with Google APIs. A service account is associated with the application itself rather than an individual end user.

Service accounts are not members of your Google Workspace domain, unlike user accounts. They aren't subject to domain policies set by Google Workspace administrators and can only access users' data if they are granted domain-wide delegation.

What Is Domain-Wide Delegation?

Domain-wide delegation is a feature in Google Workspace that allows GCP service accounts to access Google Workspace users' data and to act on their behalf within a specific domain.

When using the domain-wide delegation feature, applications can act on behalf of users in a Google Workspace domain without requiring individual users to authenticate and authorize the application.

Only a Google Workspace super admin can authorize an application, acting as the service account, to access data on behalf of users in a domain. This authorization is called “delegating domain-wide authority" to a service account.

How Does Domain-Wide Delegation Work?

To use the domain-wide delegation feature, the following steps (shown in Figure 2) are required:

  1. Enabling Domain-Wide Delegation: The Google Workspace super admin grants domain-wide delegation for a service account, along with a set of OAuth scopes allowed for that access. These scopes detail which specific services and specific actions the service account will have access to. For example, if just the scope /auth/gmail.readonly is granted, the service account will have access to read a user’s Gmail messages when acting on behalf of that user, but not their other Workspace data such as access to files in Drive.
  2. Requesting Google Workspace Access Token: The application sends a request to the Google Workspace token endpoint with the appropriate credentials. This includes the service account's client ID and client secret, as well as the desired scopes for accessing the user data. If the request is valid and the service account has been granted the necessary domain-wide delegation privileges, the token endpoint responds with an access token. The application can use this access token to access user data across the domain within the limits of the scopes requested.
  3. API Access: The application includes the access token in API requests as an authorization header, and it acts as proof of authentication and authorization on behalf of the service account.
Image 2 is a diagram of the domain-wide delegation flow. Inside the cloud is Google Workspace, the Cloud IAM, and the users in the service account. Step one. A yellow arrow points from the Google Workspace to the service account. Enabling domain-wide delegation. The second step. A red arrow points from the service account to the super admin. GWS access token request. The third step. A yellow arrow points from the super admin to the service account. API access.
Figure 2. Domain-wide delegation flow.

When granted domain-wide delegation, a service account in Google Workspace can access user data, act on their behalf and authenticate requests to Google APIs. The specific capabilities and data accessible depend on the defined scopes.

Understanding the Risks and Implications of the Domain-Wide Delegation Feature

Once the domain-wide delegation is granted to a GCP service account, a GCP identity with the necessary permission can generate an access token to a delegated service account in the same project. A malicious insider can then use this access token to impersonate Google Workspace users, granting unauthorized access to the users' data or performing operations on their behalf.

This scenario creates a mismatch between the sensitivity of the domain-wide delegation permission and the permission model managed on the GCP platform.

Google documentation includes a cautionary notice concerning the domain-wide delegation feature, which outlines the significant capabilities of this feature. Google mentions that, “For this reason, only super admins can manage domain-wide delegation, and they must specify each API scope that the app can access.”

Google has an article suggesting not using automatic role grants for Service Accounts, which in the described case would have prevented the creation of a default Google Compute Engine Service Account. To help reduce excess permissions, Google has documentation on GCP role recommendations best practices, which also mentions their "Recommender API" tool.

Using Audit Logs From Both Ends to Identify Potential Misuse

It is impossible to understand the complete picture of the activity and identify any potential misuse of the domain-wide delegation feature without analyzing the audit logs from both platforms, GCP and Google Workspace. The generation of a service account key log will appear in GCP logs while Google key generation and API call execution logs will appear in Google Workspace logs.

In Figure 3, there is an XQL query from the Cortex web interface that is searching for service account key creation in GCP audit logs.

Image 3 is a screenshot of the search for service account key creation. There are three lines of code. Dataset, filter, and fields.
Figure 3. Searching for service account key creation.
Image 4 is a screenshot of a single line of code. This is the equivalent query in Prisma Cloud. A green checkmark precedes the query.
Figure 4. Equivalent query in Prisma Cloud RQL syntax.

Figure 5 shows an XQL query that searches for the service account authorization log.

Image 5 is a screenshot of the search for access token request. There are three lines of code. Dataset, filter, and fields.
Figure 5. Searching for the Google Workspace access token request.
Image 6 is a screenshot of a single line of code. This is the equivalent query of Figure 5 in Prisma Cloud. A green checkmark precedes the query.
Figure 6. Equivalent query in Prisma Cloud RQL syntax.

Figure 7 shows we checked who gave this service account domain-wide delegation permission and when that happened.

Image 7 is a screenshot of the search for the log confirming service account permissions were granted. There are three lines of code: dataset, filter and fields.
Figure 7. Searching for the log that indicates that domain-wide delegation permissions were granted to a service account.
Image 8 is a screenshot of a single line of code. This is the equivalent query of Figure 7 in Prisma Cloud. A green checkmark precedes the query.
Figure 8. Equivalent query in Prisma Cloud RQL syntax.

Figure 9 shows the alert “A Google Workspace admin has enabled domain-wide delegation to a GCP service account and granted him access to a sensitive scope” was triggered in the Cortex web interface.

Image 9 is a screenshot of Alerts in Cortex XDR. The information includes the timestamp, user name, severity, alert source, action, category, alert name and description. Some of the information has been redacted.
Figure 9. Domain-wide delegation alert in the Cortex web interface.


The security risk we have identified lies in the mismatch between the initial permissions necessary for a malicious insider to misuse the domain-wide delegation feature and the potential impact.

Optimal security practices for service accounts with domain delegation permissions are to position them within a higher-level folder in the GCP hierarchy. In the GCP hierarchy model, access control is hierarchical.

Permissions and policies set at a higher level (e.g., organization or folder) do not automatically grant access to lower-level folders or projects. Access control is not inherited downward in the hierarchy, meaning that lower-level folders or projects do not have automatic access to higher-level ones.

Image 10 is the GCP hierarchy tree. At the top is the company in the organization row. The next row, folders, includes departments and shared infrastructure. These flow into teams and products. The third row is projects. The final row is resources.
Figure 10. GCP resource hierarchy tree

This strategy reduces the surface area for security breaches by potential malicious insiders who would normally only have permissions within lower-level folders or projects within the GCP hierarchy shown in Figure 10. You can stop entities in lower-level areas from getting the service account's access tokens by making sure that only entities in the same or higher-level folders or projects can generate access tokens to the delegated service account. This helps prevent the misuse of domain-wide delegation permissions and prevents access to Google Workspace data.


We’ve been discussing this issue with Google through a variety of contact points since June 2023. This issue was also identified by Team Axon, which they have also reported to Google.

There are risks and implications associated with the domain-wide delegation feature that security defenders need to consider when configuring this permission. Depending on the scope that was granted with the domain-wide delegation, an attacker can use the feature to impersonate Google Workspace users, perform actions on their behalf and gain unauthorized access to their data.

It’s important to highlight the mismatch between the initial permissions required for the attacker to misuse this feature, and the possible impact. In worst cases, an attacker or a malicious insider can leak sensitive Google Workspace data, such as emails, documents, and other confidential information stored within the domain.

Palo Alto Networks customers receive protection from the issue discussed in this article through both Cortex XDR and Prisma Cloud.

Cortex XDR capabilities can identify and alert on various abnormal activities such as the granting of domain wide delegation permissions or the creation of GCP service account keys. Cortex XDR is able to learn the behavior of GCP and Google Workspace entities and detect unusual behavior.

Prisma Cloud CIEM can help mitigate risky and over-privileged access by providing:

  • Visibility, alerting, and automated remediation on risky permissions
  • Automatic findings of unused permissions with Least-privilege access remediations

Prisma Cloud Threat Detection capabilities can alert on various identity-related anomalous activities such as unusual usage of credentials from inside or outside of the cloud.

Prisma Cloud can also perform runtime operation monitoring and provide governance, risk and compliance (GRC) requirements for any component associated with their cloud environment.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Disclosure Timeline

  • June 27, 2023: Palo Alto Networks submitted a report about the domain-wide delegation security risk to the Google Workspace product team.
  • July 10, 2023: Security discussion between Google Workspace product team and Palo Alto Networks cloud research group.
  • July 18, 2023: Palo Alto Networks submitted a report to the Google Vulnerability Reward Program regarding this issue.
  • Aug. 2, 2023: Palo Alto Networks filed a bug with the Google Workspace product team and they replied that they would implement a fix if required.
  • August 2023: Palo Alto Networks notified Google of the intention to publish on the security risk and offered the opportunity for fixes or input.
  • Nov. 8, 2023: Palo Alto Networks invited Google’s input on our article on the domain-wide delegation security risk.

Get updates from
Palo Alto

Sign up to receive the latest news, cyber threat intelligence and research from us

from Unit 42