<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Cloud-Storage - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/cloud-storage/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Wed, 03 Jan 2024 15:30:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/cloud-storage/feed.xml" rel="self" type="application/rss+xml"/><item><title>Potential Data Exfiltration via Rclone</title><link>https://feed.craftedsignal.io/briefs/2024-01-rclone-exfiltration/</link><pubDate>Wed, 03 Jan 2024 15:30:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-rclone-exfiltration/</guid><description>The rule detects the abuse of rclone, a legitimate file synchronization tool, potentially renamed to evade detection, to exfiltrate data to cloud storage or remote endpoints, using copy/sync commands and specific file filters.</description><content:encoded><![CDATA[<p>This detection identifies the potential abuse of rclone, a legitimate command-line program used for managing files on cloud storage, for malicious data exfiltration. Attackers might rename rclone to masquerade it as a security or backup utility and blend it with administrative traffic. They can then use rclone's copy or sync functions with specific cloud backends (like S3) and filters to target and exfiltrate sensitive file types. The use of rclone with suspicious arguments and without legitimate configuration paths can be a strong indicator of malicious activity. This activity is observed on Windows systems. Defenders need to be aware of this technique as it allows attackers to exfiltrate data without using conventional malware.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to a Windows system (e.g., through compromised credentials or exploiting a vulnerability).</li>
<li>The attacker downloads rclone to the compromised system.</li>
<li>The attacker renames <code>rclone.exe</code> to a less suspicious name (e.g., <code>TrendFileSecurityCheck.exe</code>) to evade detection based on process name.</li>
<li>The attacker uses rclone's <code>copy</code> or <code>sync</code> command to initiate data transfer to a remote cloud storage service such as Amazon S3 or a web server accessible via HTTP.</li>
<li>The attacker uses the <code>--include</code> flag to specify the file types to be exfiltrated (e.g., documents, source code, or databases).</li>
<li>The attacker may use the <code>--transfers</code> flag to increase the number of parallel transfers, speeding up the exfiltration process.</li>
<li>The attacker sets up a cron job to run rclone periodically, ensuring continuous exfiltration of data.</li>
<li>The data is exfiltrated to the attacker's controlled cloud storage, completing the objective.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation can lead to the exfiltration of sensitive company data, including intellectual property, financial records, or customer data. This data breach can result in financial losses, reputational damage, legal liabilities, and loss of competitive advantage. While the number of victims and sectors are unknown, the consequences of a successful data exfiltration can be severe for any organization.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule &quot;Potential Data Exfiltration via Rclone&quot; to your SIEM and tune for your environment to detect suspicious rclone activity based on process names and command-line arguments.</li>
<li>Implement the Sigma rule &quot;Rclone Process Without Standard Path&quot; to alert when rclone is executed from non-standard directories, which could indicate a renamed or moved copy of the tool.</li>
<li>Investigate any processes where <code>process.pe.original_file_name</code> is <code>rclone.exe</code> but the process name is different, indicating a possible attempt to evade detection as described in the Overview.</li>
<li>Review rclone command-line arguments for usage of <code>copy</code> or <code>sync</code> commands in conjunction with <code>--include</code> or <code>--exclude</code> flags to identify potentially targeted data as noted in the Triage section.</li>
<li>Monitor process creation events (Sysmon Event ID 1) for the execution of <code>rclone.exe</code> or renamed copies with unusual command-line arguments, using the provided log source details.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>exfiltration</category><category>rclone</category><category>cloud storage</category><category>windows</category></item><item><title>Azure Storage Account Data Exfiltration via AzCopy and SAS Token Abuse</title><link>https://feed.craftedsignal.io/briefs/2024-01-02-azure-storage-azcopy-exfiltration/</link><pubDate>Tue, 02 Jan 2024 15:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-02-azure-storage-azcopy-exfiltration/</guid><description>Successful GetBlob operations on Azure Storage Accounts using the AzCopy user agent with SAS token authentication can indicate data exfiltration by adversaries abusing compromised SAS tokens.</description><content:encoded><![CDATA[<p>This threat involves the potential exfiltration of data from Azure Storage Accounts by abusing the AzCopy command-line utility with compromised Shared Access Signature (SAS) tokens. AzCopy is a legitimate tool for transferring data to and from Azure Storage, but adversaries can exploit it to download sensitive data if they gain access to valid SAS tokens. The activity is characterized by successful GetBlob operations originating from the AzCopy user agent and authenticated using SAS tokens. This activity is a concern for defenders because it allows attackers to bypass traditional access controls and exfiltrate data without directly compromising storage account credentials. The Elastic detection rule identifies the first occurrence of GetBlob operations from a specific storage account using this pattern.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker gains unauthorized access to a valid SAS token for an Azure Storage Account. This could be achieved through phishing, credential stuffing, or exploiting a misconfigured application.</li>
<li>The attacker uses the AzCopy command-line utility on a compromised host or cloud instance.</li>
<li>AzCopy is configured with the compromised SAS token to authenticate against the target Azure Storage Account. The attacker sets the target using the storage account name.</li>
<li>The attacker issues a <code>GetBlob</code> request to retrieve specific blobs. They identify the target using the <code>objectKey</code>.</li>
<li>The Azure Storage Account logs the successful <code>GetBlob</code> operation. The logs include the <code>AzCopy</code> user agent, the SAS token authentication method, and a status code of 200.</li>
<li>The attacker repeats steps 4 and 5 to exfiltrate multiple blobs. They may first use <code>ListBlobs</code> or <code>ListContainers</code> to enumerate storage contents.</li>
<li>The exfiltrated data is stored on the attacker's controlled infrastructure.</li>
<li>The attacker uses the exfiltrated data for malicious purposes, such as extortion, espionage, or financial gain.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>A successful attack can lead to the exfiltration of sensitive data stored within the Azure Storage Account. The damage depends on the sensitivity of the data, which could include confidential business documents, customer data, or proprietary code. The number of victims depends on the scope of the affected storage account. Organizations in any sector that rely on Azure Storage Accounts are at risk. Data breaches can result in financial losses, reputational damage, and legal repercussions.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Enable Azure Storage Diagnostic Logs, specifically the <code>StorageRead</code> log, and stream them to an Event Hub for analysis (references: setup section of the content).</li>
<li>Deploy the provided Sigma rule to your SIEM to detect suspicious <code>GetBlob</code> operations with the <code>AzCopy</code> user agent and SAS token authentication. Tune the rule to your environment to minimize false positives (reference: rules section below).</li>
<li>Review Azure Activity Logs for SAS token generation events to identify potentially compromised tokens (reference: overview section of the content).</li>
<li>Implement shorter expiration times and restrictive permissions on SAS tokens to limit the potential impact of compromised credentials (reference: overview section of the content).</li>
<li>Investigate alerts generated by the Sigma rule by reviewing the <code>azure.platformlogs.properties.accountName</code>, <code>azure.platformlogs.properties.objectKey</code>, <code>source.address</code>, and <code>azure.platformlogs.identity.tokenHash</code> fields to understand the context of the activity (reference: overview section of the content).</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>azure</category><category>exfiltration</category><category>cloud-storage</category><category>azcopy</category></item></channel></rss>