<?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>Configuration-Audit - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/configuration-audit/</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>Mon, 29 Jan 2024 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/configuration-audit/feed.xml" rel="self" type="application/rss+xml"/><item><title>Zoom Meetings Created Without Passcodes</title><link>https://feed.craftedsignal.io/briefs/2024-01-29-zoom-meeting-no-passcode/</link><pubDate>Mon, 29 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-29-zoom-meeting-no-passcode/</guid><description>Detection of Zoom meetings created without a passcode, which are susceptible to Zoombombing and potential disruption or exposure of sensitive information.</description><content:encoded><![CDATA[<p>This brief focuses on the risk associated with Zoom meetings created without a passcode. When meetings lack this basic security measure, they become vulnerable to &quot;Zoombombing,&quot; where unauthorized individuals disrupt the session with offensive or inappropriate content. The Elastic detection rule, published on 2026-04-10, identifies such meetings by monitoring Zoom event logs. This is particularly relevant for organizations using Zoom for internal and external communication, as the lack of a passcode can lead to reputational damage, exposure of sensitive information, and overall disruption of business operations. Ensuring that all meetings are password-protected is a simple yet effective way to mitigate this risk.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>A Zoom meeting is created by a user without enabling the passcode feature.</li>
<li>The meeting details (including the meeting ID) are potentially shared publicly or become discoverable through automated tools.</li>
<li>Attackers or malicious actors identify the unprotected Zoom meeting.</li>
<li>Attackers join the meeting without any authentication or authorization.</li>
<li>Once inside the meeting, attackers disrupt the session by sharing inappropriate content (e.g., images, videos, audio).</li>
<li>Participants within the meeting are exposed to the offensive content, leading to disruption and potential reputational damage.</li>
<li>The meeting organizer is forced to terminate the session to stop the disruption.</li>
<li>The organization experiences a loss of productivity and may face public criticism due to the incident.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Failure to secure Zoom meetings with passcodes can lead to significant disruptions, with potential exposure of sensitive information and reputational damage. While the exact number of victims is difficult to quantify, Zoombombing incidents have affected organizations across various sectors. Successful attacks can result in the shutdown of meetings, loss of productivity, and the need for damage control. The impact extends beyond immediate disruption to potential long-term damage to an organization's reputation and client trust.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rule provided below to detect Zoom meetings created without a password.</li>
<li>Enable Zoom Filebeat module to properly ingest the Zoom logs required for detection.</li>
<li>Review Zoom configuration settings to enforce mandatory passcodes for all future meetings.</li>
<li>Implement enhanced monitoring and alerting for Zoom meeting creation events to quickly detect and respond to any future instances of meetings being set up without passcodes.</li>
<li>Educate users on the importance of using passcodes for all Zoom meetings to prevent unauthorized access and potential disruptions.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>zoom</category><category>initial-access</category><category>configuration-audit</category><category>zoombombing</category></item><item><title>Azure Key Vault Modified by Unusual User</title><link>https://feed.craftedsignal.io/briefs/2024-01-azure-keyvault-modified/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-azure-keyvault-modified/</guid><description>This rule identifies modifications to Azure Key Vaults by unusual users, potentially leading to data breaches or service disruptions through defense evasion or impact operations.</description><content:encoded><![CDATA[<p>This detection identifies modifications to Azure Key Vault, a service that safeguards encryption keys and secrets. Given the sensitivity of the data stored, access should be tightly controlled. This detection uses a new terms rule to identify when Key Vault modifications are performed by a user who hasn't been seen performing this activity within a 14-day period. This activity could indicate compromised credentials, insider threats, or misconfigured access controls. This rule helps security teams quickly identify and respond to potentially unauthorized modifications to sensitive resources within Azure environments, specifically targeting unusual user activity that deviates from established baselines. The original rule was created on 2020/08/31, and updated on 2026/04/10.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains unauthorized access to an Azure account, potentially through credential compromise or account takeover.</li>
<li>The attacker leverages the compromised account to authenticate to the Azure environment.</li>
<li>The attacker enumerates available Key Vault resources within the Azure subscription.</li>
<li>The attacker attempts to modify a Key Vault configuration, such as changing access policies, secrets, or encryption keys.</li>
<li>The modification is logged as an Azure Activity Log event with operation name <code>MICROSOFT.KEYVAULT/VAULTS/*</code> and event outcome of <code>Success</code>.</li>
<li>The &quot;new terms&quot; rule triggers because the user performing the modification (<code>azure.activitylogs.identity.claims_initiated_by_user.name</code>) is not a known user of Key Vaults, based on a 14-day history.</li>
<li>The attacker leverages the modified Key Vault configuration to access sensitive data or disrupt services.</li>
<li>The attacker may further attempt to cover their tracks by deleting audit logs or other evidence of their activity.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Unauthorized modifications to Azure Key Vault can have significant consequences, including data breaches, service disruptions, and compliance violations. The rule has a low severity and a risk score of 21. If an attacker successfully modifies a Key Vault, they could potentially access sensitive secrets and encryption keys, leading to the compromise of critical applications and data. This could affect multiple organizations that rely on the compromised Key Vault for securing their cloud infrastructure.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Deploy the Sigma rules provided in this brief to your SIEM to detect unusual Key Vault modifications.</li>
<li>Investigate any alerts generated by the Sigma rules, focusing on the user (<code>azure.activitylogs.identity.claims_initiated_by_user.name</code>), the Key Vault resource ID (<code>azure.activitylogs.resource_id</code>), and the type of modification (<code>azure.activitylogs.operation_name</code>).</li>
<li>Review Azure Key Vault access policies and ensure that only authorized users and applications have the necessary permissions.</li>
<li>Enable multi-factor authentication (MFA) for all Azure accounts, especially those with access to sensitive resources like Key Vaults.</li>
<li>Monitor Azure Activity Logs for any suspicious activity related to Key Vault modifications (Data Source: Azure Activity Logs).</li>
</ul>
]]></content:encoded><category domain="severity">low</category><category domain="type">advisory</category><category>azure</category><category>keyvault</category><category>configuration-audit</category><category>impact</category><category>defense-evasion</category></item></channel></rss>