Minimizing Permissions for Cloud Forensics: A Practical Guide to Tightening Access in the Cloud
Most cloud environments struggle to strike the right balance between security and accessibility. This blog breaks down why traditional approaches to cloud forensics often fail and outlines practical, security-first strategies to solve the access dilemma. You’ll learn how to enable effective investigations without over-permissioning your environment.
No items found.
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
No items found.
Share
11
Aug 2025
Most cloud environments are over-permissioned and under-prepared for incident response.
Security teams need access to logs, snapshots, and configuration data to understand how an attack unfolded, but giving blanket access opens the door to insider threats, misconfigurations, and lateral movement.
So, how do you enable forensics without compromising your security posture?
The dilemma: balancing access and security
There is a tension between two crucial aspects of cloud security that create a challenge for cloud forensics.
One aspect is the need for Security Operations Center (SOC) and Incident Response (IR) teams to access comprehensive data for investigating and resolving security incidents.
The other conflicting aspect is the principle of least privilege and minimal manual access advocated by cloud security best practices.
This conflict is particularly pronounced in modern cloud environments, where traditional physical access controls no longer apply, and infrastructure-as-code and containerization have transformed the landscape.
There are several common but less-than-ideal approaches to this challenge:
Accepting limited data access, potentially leaving incidents unresolved
Granting root-level access during major incidents, risking further compromise
Relying on cloud or DevOps teams to retrieve data, causing delays and potential miscommunication
[related-resource]
Challenges in container forensics
Containers present unique challenges for forensic investigations due to their ephemeral and dynamic nature. The orchestration and management of containers, whether on private clusters or using services like AWS Elastic Kubernetes Service (EKS), introduce complexities in capturing and analyzing forensic data.
To effectively investigate containers, it's often necessary to acquire the underlying volume of a node or perform memory captures. However, these actions require specific Identity and Access Management (IAM) and network access to the node, as well as familiarity with the container environment, which may not always be straightforward.
An alternative method of collection in containerized environments is to utilize automated tools to collect this evidence. Since they can detect malicious activity and collect relevant data without needing human input, they can act immediately, securing evidence that might be lost by the time a human analyst is available to collect it manually.
Additionally, automation can help significantly with access and permissions. Instead of analysts needing the correct permissions for the account, service, and node, as well as deep knowledge of the container service itself, for any container from which they wish to collect logs. They can instead collect them, and have them all presented in one place, at the click of a button.
A better approach: practical strategies for cloud forensics
It's crucial to implement strategies that strike a balance between necessary access and stringent security controls.
Here are several key approaches:
1. Dedicated cloud forensics accounts
Establishing a separate cloud account or subscription specifically for forensic activities is foundational. This approach isolates forensic activities from regular operations, preventing potential contamination from compromised environments. Dedicated accounts also enable tighter control over access policies, ensuring that forensic operations do not inadvertently expose sensitive data to unauthorized users.
A separate account allows for:
Isolation: The forensic investigation environment is isolated from potentially compromised environments, reducing the risk of cross-contamination.
Tighter access controls: Policies and controls can be more strictly enforced in a dedicated account, reducing the likelihood of unauthorized access.
Simplified governance: A clear and simplified chain of custody for digital evidence is easier to maintain, ensuring that forensic activities meet legal and regulatory requirements.
Using cross-account IAM roles, the forensics account can access other accounts, but only with permissions that are strictly necessary for the investigation. This ensures that the principle of least privilege is upheld, reducing the risk of unauthorized access or data exposure during the forensic process.
3. Temporary credentials for just-in-time access
Leveraging temporary credentials, such as AWS STS tokens, allows for just-in-time access during an investigation. These credentials are short-lived and scoped to specific resources, ensuring that access is granted only when absolutely necessary and is automatically revoked after the investigation is completed. This reduces the window of opportunity for potential attackers to exploit elevated permissions.
Pre-deploying access control based on resource tags is another effective strategy. By tagging resources with identifiers like "Forensics," access can be dynamically granted only to those resources that are relevant to the investigation. This targeted approach minimizes the risk of overexposure and ensures that forensic teams can quickly and efficiently access the data they need.
The shift to cloud environments demands a rethinking of how we approach forensic investigations. By implementing strategies like dedicated cloud forensic accounts, cross-account roles, temporary credentials, and tag-based access control, organizations can strike the right balance between access and security. These practices not only enhance the effectiveness of forensic investigations but also ensure that access is tightly controlled, reducing the risk of exacerbating an incident or compromising the investigation.
Find the right tools for your cloud security
Darktrace delivers a proactive approach to cyber resilience in a single cybersecurity platform, including cloud coverage.
Darktrace’s cloud offerings have been bolstered with the acquisition of Cado Security Ltd., which enables security teams to gain immediate access to forensic-level data in multi-cloud, container, serverless, SaaS, and on-premises environments.
In addition to having these forensics capabilities, Darktrace / CLOUD is a real-time Cloud Detection and Response (CDR) solution built with advanced AI to make cloud security accessible to all security teams and SOCs. By using multiple machine learning techniques, Darktrace brings unprecedented visibility, threat detection, investigation, and incident response to hybrid and multi-cloud environments.
Learn how to evaluate cloud investigation and incident response tools
Discover how real forensics solutions can help your team efficiently understand and respond to cloud threats.
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Understanding the Canadian Critical Cyber Systems Protection Act
Introduction: The Canadian Critical Cyber Systems Protection Act
On 18 June 2025, the Canadian federal Government introduced Bill C-8 which, if adopted following completion of the legislative process, will enact the Critical Cyber Systems Protection Act (CCSPA) and give Canada its first federal, cross-sector and legally binding cybersecurity regime for designated critical infrastructure providers. As of August 2025, the Bill has completed first reading and stands at second reading in the Canadian House of Commons.
Political context
The measure revives most of the stalled 2022 Bill C-26 “An Act Respecting Cyber Security” which “died on Paper” when Parliament was prorogued in January 2025, in the wake of former Prime Minister Justin Trudeau’s resignation.
The new government, led by Mark Carney since March 2025, has re-tabled the package with the same two-part structure: (1) amendments to the Telecommunications Act that enable security directions to telecoms; and (2) a new CCSPA setting out mandatory cybersecurity duties for designated operators. This blog focuses on the latter.
If enacted, Canada will join fellow Five Eyes partners such as the United Kingdom and Australia, which already impose statutory cyber-security duties on operators of critical national infrastructure.
The case for new cybersecurity legislation in Canada
The Canadian cyber threat landscape has expanded. The country's national cyber authority, the Canadian Centre for Cybersecurity (Cyber Centre), recently assessed that the number of cyber incidents has “sharply increased” in the last two years, as has the severity of those incidents, with essential services providers among the targets. Likewise, in its 2025-2026 National Cyber Threat Assessment, the Cyber Centre warned that AI technologies are “amplifying cyberspace threats” by lowering barriers to entry, improving the speed and sophistication of social-engineering attacks and enabling more precise operations.
This context mirrors what we are seeing globally: adversaries, including state actors, are taking advantage of the availability and sophistication of AI tools, which they have leverage to amplify the effectiveness of their operations. In this increasingly complex landscape, regulation must keep pace and evolve in step with the risk.
What the Canadian Critical Cyber Systems Protection Act aims to achieve
If enacted, the CCSPA will apply to operators in federally regulated critical infrastructure sectors which are vital to national security and public safety, as further defined in “Scope” below (the “Regulated Entities”), to adopt and comply with a minimum standard of cybersecurity duties (further described below) which align with those its Five Eyes counterparts are already adhering to.
Who does the CCSPA apply to
The CCSPA would apply to designated operators that deliver services or systems within federal jurisdiction in the following priority areas:
telecommunications services
interprovincial or international pipeline and power line systems, nuclear energy systems, transportation systems
banking and clearing
settlement systems
The CCSPA would also grant the Governor in Council (Federal Cabinet) with powers to add or remove entities in scope via regulation.
Scope of the CCSPA
The CCSPA introduces two key instruments:
First, it strengthens cyber threat information sharing between responsible ministers, sector regulators, and the Communications Security Establishment (through the Cyber Centre).
Second, it empowers the Governor in Council (GIC) to issue Cyber Security Directions (CSDs) - binding orders requiring a designated operator to implement specified measures to protect a critical cyber system within defined timeframes.
CSDs may be tailored to an individual operator or applied to a class of operators and can address technology, process, or supplier risks. To safeguard security and commercial confidentiality, the CCSPA restricts disclosure of the existence or content of a CSD except as necessary to carry it out.
Locating decision-making with the GIC ensures that CSDs are made with a cross-government view that weighs national security, economic priorities and international agreement.
New obligations for designated providers
The CCSPA would impose key cybersecurity compliance and obligations on designated providers. As it stands, this includes:
Establishing and maintaining cybersecurity programs: these will need to be comprehensive, proportionate and developed proactively. Once implemented, they will need to be continuously reviewed
Mitigating supply chain risks: Regulated Entities will be required to assess their third-party products and services by conducting a supply chain analysis, and take active steps to mitigate any identified risks
Reporting incidents: Regulated Entities will need to be more transparent with their reporting, by making the Communications Security Establishment (CSE) aware of any incident which has, or could potentially have, an impact on a critical system. The reports must be made within specific timelines, but in any event within no more than 72 hours;
Compliance with cybersecurity directions: the government will, under the CCSPA, have the authority to issue cybersecurity directives in an effort to remain responsive to emerging threats, which Regulated Entities will be required to follow once issued
Record keeping: this shouldn’t be a surprise to many of those Regulated Entities which fall in scope, which are already likely to be subject to record keeping requirements. Regulated Entities should expect to be maintaining records and conducting audits of their systems and processes against the requirements of the CCSPA
It should be noted, however, that this may be subject to change, so Regulated Entities should keep an eye on the progress of the Bill as it makes its way through parliament.
Enforcement of the Act would be carried out by sector-specific regulators identified in the Act such as the Office of the Superintendent of Financial Institutions, Minister of Transport, Canada Energy Regulator, Canadian Nuclear Safety Commission and the Ministry of Industry.
What are the penalties for CCSPA non-compliance?
When assessing the penalties associated with non-compliance with the requirements of the CCSPA, it is clear that such non-compliance will be taken seriously, and the severity of the penalties follows the trend of those applied by the European Union to key pieces of EU legislation. The “administrative monetary penalties” (AMPs) set by regulation could see fines being applied of up to C$1 million for individuals and up to C$15 million for organizations.
SEO Poisoning and Fake PuTTY sites: Darktrace’s Investigation into the Oyster backdoor
What is SEO poisoning?
Search Engine Optimization (SEO) is the legitimate marketing technique of improving the visibility of websites in organic search engine results. Businesses, publishers, and organizations use SEO to ensure their content is easily discoverable by users. Techniques may include optimizing keywords, creating backlinks, or even ensuring mobile compatibility.
SEO poisoning occurs when attackers use these same techniques for malicious purposes. Instead of improving the visibility of legitimate content, threat actors use SEO to push harmful or deceptive websites to the top of search results. This method exploits the common assumption that top-ranking results are trustworthy, leading users to click on URLs without carefully inspecting them.
As part of SEO poisoning, the attacker will first register a typo-squatted domain, slightly misspelled or otherwise deceptive versions of real software sites, such as putty[.]run or puttyy[.]org. These sites are optimized for SEO and often even backed by malicious Google ads, increasing the visibility when users search for download links. To achieve that, threat actors may embed pages with strategically chosen, high-value keywords or replicate content from reputable sources to elevate the domain’s perceived authority in search engine algorithms [4]. In more advanced operations, these tactics are reinforced with paid promotion, such as Google ads, enabling malicious domains to appear above organic search results as sponsored links. This placement not only accelerates visibility but also impacts an unwarranted sense of legitimacy to unsuspected users.
Once a user lands on one of these fake pages, they are presented with what looks like a legitimate software download option. Upon clicking the download indicator, the user will be redirected to another separate domain that actually hosts the payload. This hosting domain is usually unrelated to the nominally referenced software. These third-party sites can involve recently registered domains but may also include legitimate websites that have been recently compromised. By hosting malware on a variety of infrastructure, attackers can prolong the availability of distribution methods for these malicious files before they are taken down.
What is the Oyster backdoor?
Oyster, also known as Broomstick or CleanUpLoader, is a C++ based backdoor malware first identified in July 2023. It enables remote access to infected systems, offering features such as command-line interaction and file transfers.
Oyster has been widely adopted by various threat actors, often as an entry point for ransomware attacks. Notable examples include Vanilla Tempest and Rhysida ransomware groups, both of which have been observed leveraging the Oyster backdoor to enhance their attack capabilities. Vanilla Tempest is known for using Oyster’s stealth persistence to maintain long-term access within targeted networks, often aligning their operations with ransomware deployment [5]. Rhysida has taken this further by deploying Oyster as an initial access tool in ransomware campaigns, using it to conduct reconnaissance and move laterally before executing encryption activities [6].
Once installed, the backdoor gathers basic system information before communicating with a command-and-control (C2) server. The malware largely relies on a ‘cmd.exe’ instance to execute commands and launch other files [1].
In previous SEO poisoning cases, the file downloaded from the fake pages is not just PuTTY, but a trojanized version that includes the stealthy Oyster backdoor. PuTTY is a free and open-source terminal emulator for Windows that allows users to connect to remote servers and devices using protocols like SSH and Telnet. In the recent campaign, once a user visits the fake software download site, ranked highly through SEO poisoning, the malicious payload is downloaded through direct user interaction and subsequently installed on the local device, initiating the compromise. The malware then performs two actions simultaneously: it installs a fully functional version of PuTTY to avoid user suspicion, while silently deploying the Oyster backdoor. Given PuTTY’s nature, it is prominently used by IT administrators with highly privileged account as opposed to standard users in a business, possibly narrowing the scope of the targets.
Oyster’s persistence mechanism involves creating a Windows Scheduled Task that runs every few minutes. Notably, the infection uses Dynamic Link Library (DLL) side loading, where a malicious DLL, often named ‘twain_96.dll’, is executed via the legitimate Windows utility ‘rundll32.exe’, which is commonly used to run DLLs [2]. This technique is frequently used by malicious actors to blend their activity with normal system operations.
Darktrace’s Coverage of the Oyster Backdoor
In June 2025, security analysts at Darktrace identified a campaign leveraging search engine manipulation to deliver malware masquerading as the popular SSH client, PuTTY. Darktrace / NETWORK’s anomaly-based detection identified signs of malicious activity, and when properly configured, its Autonomous Response capability swiftly shut down the threar before it could escalate into a more disruptive attack. Subsequent analysis by Darktrace’s Threat Research team revealed that the payload was a variant of the Oyster backdoor.
The first indicators of an emerging Oyster SEO campaign typically appeared when user devices navigated to a typosquatted domain, such as putty[.]run or putty app[.]naymin[.]com, via a TLS/SSL connection.
Figure 1: Darktrace’s detection of a device connecting to the typosquatted domain putty[.]run.
The device would then initiate a connection to a secondary domain that hosts the malicious installer, likely triggered by user interaction with redirect elements on the landing page. This secondary site may not have any immediate connection to PuTTY itself but is instead a hijacked blog, a file-sharing service, or a legitimate-looking content delivery subdomain.
Figure 2: Darktrace’s detection of the device making subsequent connections to the payload domain.
Following installation, multiple affected devices were observed attempting outbound connectivity to rare external IP addresses, specifically requesting the ‘/secure’ endpoint as noted within the declared URIs. After the initial callback, the malware continued communicating with additional infrastructure, maintaining its foothold and likely waiting for tasking instructions. Communication patterns included:
· Endpoints with URIs /api/kcehc and /api/jgfnsfnuefcnegfnehjbfncejfh
· Endpoints with URI /reg and user agent “WordPressAgent”, “FingerPrint” or “FingerPrintpersistent”
This tactic has been consistently linked to the Oyster backdoor, which has shown similar URI patterns across multiple campaigns [3].
Darktrace analysts also noted the sophisticated use of spoofed user agent strings across multiple investigated customer networks. These headers, which are typically used to identify the application making an HTTP request, are carefully crafted to appear benign or mimic legitimate software. One common example seen in the campaign is the user agent string “WordPressAgent”. While this string references a legitimate web application or plugin, it does not appear to correspond to any known WordPress services or APIs. Its inclusion is most likely designed to mimic background web traffic commonly associated with WordPress-based content management systems.
Figure 3: Cyber AI Analyst investigation linking the HTTP C2 activity.
Case-Specific Observations
While the previous section focused on tactics and techniques common across observed Oyster infections, a closer examination reveals notable variations and unique elements in specific cases. These distinct features offer valuable insights into the diverse operational approaches employed by threat actors. These distinct features, from unusual user agent strings to atypical network behavior, offer valuable insights into the diverse operational approaches employed by the threat actors. Crucially, the divergence in post-exploitation activity reflects a broader trend in the use of widely available malware families like Oyster as flexible entry points, rather than fixed tools with a single purpose. This modular use of the backdoor reflects the growing Malware-as-a-Service (MaaS) ecosystem, where a single initial infection can be repurposed depending on the operator’s goals.
From Infection to Data Egress
In one observed incident, Darktrace observed an infected device downloading a ZIP file named ‘host[.]zip’ via curl from the URI path /333/host[.]zip, following the standard payload delivery chain. This file likely contained additional tools or payloads intended to expand the attacker’s capabilities within the compromised environment. Shortly afterwards, the device exhibited indicators of probable data exfiltration, with outbound HTTP POST requests featuring the URI pattern: /upload?dir=NAME_FOLDER/KEY_KEY_KEY/redacted/c/users/public.
This format suggests the malware was actively engaged in local host data staging and attempting to transmit files from the target machine. The affected device, identified as a laptop, aligns with the expected target profile in SEO poisoning scenarios, where unsuspecting end users download and execute trojanized software.
Irregular RDP Activity and Scanning Behavior
Several instances within the campaign revealed anomalous or unexpected Remote Desktop Protocol (RDP) sessions occurring shortly after DNS requests to fake PuTTY domains. Unusual RDP connections frequently followed communication with Oyster backdoor C2 servers. Additionally, Darktrace detected patterns of RDP scanning, suggesting the attackers were actively probing for accessible systems within the network. This behavior indicates a move beyond initial compromise toward lateral movement and privilege escalation, common objectives once persistence is established.
The presence of unauthorized and administrative RDP sessions following Oyster infections aligns with the malware’s historical role as a gateway for broader impact. In previous campaigns, Oyster has often been leveraged to enable credential theft, lateral movement, and ultimately ransomware deployment. The observed RDP activity in this case suggests a similar progression, where the backdoor is not the final objective but rather a means to expand access and establish control over the target environment.
Cryptic User Agent Strings?
In multiple investigated cases, the user agent string identified in these connections featured formatting that appeared nonsensical or cryptic. One such string containing seemingly random Chinese-language characters translated into an unusual phrase: “Weihe river is where the water and river flow.” Legitimate software would not typically use such wording, suggesting that the string was intended as a symbolic marker rather than a technical necessity. Whether meant as a calling card or deliberately crafted to frame attribution, its presence highlights how subtle linguistic cues can complicate analysis.
Figure 4: Darktrace’s detection of malicious connections using a user agent with randomized Chinese-language formatting.
Strategic Implications
What makes this campaign particularly noteworthy is not simply the use of Oyster, but its delivery mechanism. SEO poisoning has traditionally been associated with cybercriminal operations focused on opportunistic gains, such as credential theft and fraud. Its strength lies in casting a wide net, luring unsuspecting users searching for popular software and tricking them into downloading malicious binaries. Unlike other campaigns, SEO poisoning is inherently indiscriminate, given that the attacker cannot control exactly who lands on their poisoned search results. However, in this case, the use of PuTTY as the luring mechanism possibly indicates a narrowed scope - targeting IT administrators and accounts with high privileges due to the nature of PuTTY’s functionalities.
This raises important implications when considered alongside Oyster. As a backdoor often linked to ransomware operations and persistent access frameworks, Oyster is far more valuable as an entry point into corporate or government networks than small-scale cybercrime. The presence of this malware in an SEO-driven delivery chain suggests a potential convergence between traditional cybercriminal delivery tactics and objectives often associated with more sophisticated attackers. If actors with state-sponsored or strategic objectives are indeed experimenting with SEO poisoning, it could signal a broadening of their targeting approaches. This trend aligns with the growing prominence of MaaS and the role of initial access brokers in today’s cybercrime ecosystem.
Whether the operators seek financial extortion through ransomware or longer-term espionage campaigns, the use of such techniques blurs the traditional distinctions. What looks like a mass-market infection vector might, in practice, be seeding footholds for high-value strategic intrusions.
Credit to Christina Kreza (Cyber Analyst) and Adam Potter (Senior Cyber Analyst)
Appendices
MITRE ATT&CK Mapping
· T1071.001 – Command and Control – Web Protocols
· T1008 – Command and Control – Fallback Channels
· T0885 – Command and Control – Commonly Used Port
· T1571 – Command and Control – Non-Standard Port
· T1176 – Persistence – Browser Extensions
· T1189 – Initial Access – Drive-by Compromise
· T1566.002 – Initial Access – Spearphishing Link
· T1574.001 – Persistence – DLL
Indicators of Compromise (IoCs)
· 85.239.52[.]99 – IP address
· 194.213.18[.]89/reg – IP address / URI
· 185.28.119[.]113/secure – IP address / URI
· 185.196.8[.]217 – IP address
· 185.208.158[.]119 – IP address
· putty[.]run – Endpoint
· putty-app[.]naymin[.]com – Endpoint
· /api/jgfnsfnuefcnegfnehjbfncejfh
· /api/kcehc
Darktrace Model Detections
· Anomalous Connection / New User Agent to IP Without Hostname
· Anomalous Connection / Posting HTTP to IP Without Hostname
· Compromise / HTTP Beaconing to Rare Destination
· Compromise / Large Number of Suspicious Failed Connections
· Compromise / Beaconing Activity to External Rare
· Compromise / Quick and Regular Windows HTTP Beaconing
· Device / Large Number of Model Alerts
· Device / Initial Attack Chain Activity
· Device / Suspicious Domain
· Device / New User Agent
· Antigena / Network / Significant Anomaly / Antigena Breaches Over Time Block
The content provided in this blog is published by Darktrace for general informational purposes only and reflects our understanding of cybersecurity topics, trends, incidents, and developments at the time of publication. While we strive to ensure accuracy and relevance, the information is provided “as is” without any representations or warranties, express or implied. Darktrace makes no guarantees regarding the completeness, accuracy, reliability, or timeliness of any information presented and expressly disclaims all warranties.
Nothing in this blog constitutes legal, technical, or professional advice, and readers should consult qualified professionals before acting on any information contained herein. Any references to third-party organizations, technologies, threat actors, or incidents are for informational purposes only and do not imply affiliation, endorsement, or recommendation.
Darktrace, its affiliates, employees, or agents shall not be held liable for any loss, damage, or harm arising from the use of or reliance on the information in this blog.
The cybersecurity landscape evolves rapidly, and blog content may become outdated or superseded. We reserve the right to update, modify, or remove any content without notice.