<?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>Account_manipulation - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/account_manipulation/</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 18:23:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/account_manipulation/feed.xml" rel="self" type="application/rss+xml"/><item><title>External User Added to Google Workspace Group</title><link>https://feed.craftedsignal.io/briefs/2024-01-gworkspace-external-user-group/</link><pubDate>Wed, 03 Jan 2024 18:23:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-gworkspace-external-user-group/</guid><description>Detection of an external Google Workspace user account being added to an existing group, potentially indicating an adversary attempting to intercept shared files or emails by adding accounts where the domain name of the target doesn't match the Google Workspace domain.</description><content:encoded><![CDATA[<p>This detection identifies instances where an external user account is added to a Google Workspace group. Attackers may leverage this technique to intercept shared files or emails directed to the group. The rule focuses on identifying user accounts where the domain name of the target does not match the Google Workspace domain. The attack often starts with phishing or exploiting container-bound scripts to add external Google accounts to an organization's groups, sometimes granting editorial privileges. This allows the attacker to receive any information shared with the group, leading to potential data leaks or weaponization of documents for further intrusion. Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker performs reconnaissance to identify a target Google Workspace organization and its group structure.</li>
<li>A phishing email is crafted to steal credentials of a user with group management privileges or to directly add an external user to a group via a malicious link.</li>
<li>Alternatively, the attacker compromises a container-bound script with sufficient privileges to modify group memberships.</li>
<li>The compromised user or script adds an external user account (e.g., a Gmail account controlled by the attacker) to a target Google Workspace group.</li>
<li>The external user account receives emails and shared files intended for the group, potentially containing sensitive information.</li>
<li>The attacker monitors the intercepted communications for valuable data, such as credentials, financial information, or proprietary documents.</li>
<li>The stolen information is exfiltrated to an external location.</li>
<li>The attacker uses the stolen information to further compromise the organization or its partners.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Compromising Google Workspace groups can lead to significant data breaches, with potentially thousands of internal documents and communications exposed to unauthorized external actors. Successful attacks can result in the loss of confidential business data, intellectual property theft, and regulatory compliance violations. The targeted groups could range from small teams to company-wide distribution lists, affecting customer data, financial records, and strategic plans. Depending on the group's function, the impact could range from minor data leakage to severe reputational and financial damage, depending on the sensitivity and volume of data accessed.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule &quot;External User Added to Google Workspace Group&quot; to your SIEM to detect suspicious group membership changes.</li>
<li>Investigate alerts generated by the Sigma rule by examining the <code>user.name</code> or <code>user.email</code> and the <code>group.name</code> fields to identify involved accounts and groups.</li>
<li>Review Google Workspace audit logs for <code>event.action: &quot;ADD_GROUP_MEMBER&quot;</code> to identify other group modifications and potential external user additions.</li>
<li>Implement multi-factor authentication (MFA) for all Google Workspace accounts, particularly those with administrative privileges, to mitigate credential theft.</li>
<li>Enforce strict access control policies and regularly review group memberships to ensure only authorized users have access to sensitive data.</li>
<li>Configure alerts for unusual activity, such as external account additions to internal groups, to reduce the mean time to detect (MTTD).</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>google_workspace</category><category>initial_access</category><category>account_manipulation</category></item><item><title>Entra ID Application Credential Modification</title><link>https://feed.craftedsignal.io/briefs/2024-01-03-entra-id-application-credential-modification/</link><pubDate>Wed, 03 Jan 2024 10:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-03-entra-id-application-credential-modification/</guid><description>An adversary may add unauthorized credentials to an Azure application, enabling persistent access, evading defenses, and escalating privileges by modifying certificates or secrets.</description><content:encoded><![CDATA[<p>This detection identifies when a new credential is added to an application in Azure. Azure applications use credentials like certificates or secret strings for identity verification during token requests. Adversaries may exploit this by adding unauthorized credentials, enabling persistent access or evading defenses. This tactic allows attackers to maintain access even if the original compromised account is remediated. The targeted applications are within the Entra ID environment. This activity is logged within the Azure audit logs and can be detected by monitoring for successful &quot;Update application - Certificates and secrets management&quot; operations.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker gains initial access to an account with permissions to modify Azure application registrations (e.g., via phishing or credential stuffing).</li>
<li>The attacker identifies a target application registration within Entra ID.</li>
<li>The attacker modifies the application registration to add a new certificate or secret string credential.</li>
<li>The attacker uses the newly added credential to authenticate as the application.</li>
<li>The attacker leverages the application's permissions to access resources within the Azure environment.</li>
<li>The attacker may escalate privileges by granting the application additional roles or permissions.</li>
<li>The attacker maintains persistent access to the Azure environment even if the initially compromised account is disabled.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation allows attackers to maintain a persistent foothold within the Azure environment, even after the initial compromise is remediated. This can lead to data exfiltration, unauthorized access to resources, and further lateral movement within the cloud infrastructure. The severity depends on the application's permissions and the scope of the attacker's access, but could affect critical business functions if a high-privilege application is compromised.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule &quot;Entra ID Application Credential Modified&quot; to detect unauthorized credential modifications within your Azure environment, ingesting <code>logs-azure.auditlogs-*</code> and <code>filebeat-*</code> indices.</li>
<li>Review Azure audit logs for the &quot;Update application - Certificates and secrets management&quot; operation name to identify potential malicious activity.</li>
<li>Implement stricter access controls and multi-factor authentication for accounts with permissions to manage Azure application registrations.</li>
<li>Monitor application access logs for unusual or unauthorized activity originating from application principals with newly added credentials.</li>
<li>Correlate application credential modifications with other suspicious activities, such as failed login attempts or privilege escalation events, to identify potential indicators of compromise.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>azure</category><category>persistence</category><category>entra_id</category><category>account_manipulation</category></item></channel></rss>