Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
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 https://bit.ly/3T47wvR
via IFTTT
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 https://bit.ly/3sYXjpW
via IFTTT
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 https://bit.ly/3sYgtfH
via IFTTT
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.
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.
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.
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.
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.
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.
Figure 3. Pseudocode showing the hard-coded file path in cleartext.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.
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:
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.exe1dsfjlosdf23dsfdfr
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.
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.
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.
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 screenshot from Wireshark in Figure 9 illustrates a complete 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.
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.
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.
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.
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:
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.
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.
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.
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.
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:
However, the threat actor canceled the attempt to compress the .pst file by using the tool taskkill.exe approximately eight minutes later.
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.
And finally, the ai.pst file is removed.
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.
Later, following the same procedure, the threat actor exfiltrated the content.
Conclusion
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
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: +31.20.299.3130
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.
MITRE ATT&CK Mapping
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
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.
The attack comprised a short but intense peak of 1.1 Tbps around 22:55
Attack #2: 1.6 Tbps TCP-based DDoS
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.
Conclusion
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 https://bit.ly/47XrfS9
via IFTTT
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 https://bit.ly/3uxVPDu
via IFTTT
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 imposedsimilar 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 prolificcyber 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 https://bit.ly/3RoaF7B
via IFTTT
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.
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 https://bit.ly/46IFbym
via IFTTT
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-NGredirects and intercepts network traffic.
GSoC Project:Beleswar Prasad Padhideveloped an HTML interface for FakeNet-NG that displays network indicators in an analyst-friendly way.
Tool:FLOSSextracts and deobfuscates strings from programs.
GSoC Project:Arnav Kharbandaextended FLOSS to extract language-specific strings from Go and Rust programs.
GSoC Project:Colton Gabertanintegrated capa with Ghidra, the NSA’s open source reverse engineering tool.
GSoC Project:Yacine Elhamerextended capa to identify capabilities in dynamic sandbox traces, specifically for the CAPEsandbox.
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.
Deeya is currently working on a website that describes capa and exposes the default rule set – the related tasks are tracked on GitHub.
Conclusion
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 https://bit.ly/40ZqTs9
via IFTTT
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.
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.
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:
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.
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.
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.
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.”
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.
Figure 3. Searching for service account key creation.Figure 4. Equivalent query in Prisma Cloud RQL syntax.
Figure 5 shows an XQL query that searches for the service account authorization log.
Figure 5. Searching for the Google Workspace access token request.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.
Figure 7. Searching for the log that indicates that domain-wide delegation permissions were granted to a service account.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.
Figure 9. Domain-wide delegation alert in the Cortex web interface.
Mitigation
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.
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.
Conclusion
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: +31.20.299.3130
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
Networks!
Sign up to receive the latest news, cyber threat intelligence and research from us
