<?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>Security_controls — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/security_controls/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Wed, 03 Jan 2024 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/security_controls/feed.xml" rel="self" type="application/rss+xml"/><item><title>GitHub Organizations 2FA Disabled</title><link>https://feed.craftedsignal.io/briefs/2024-01-03-github-2fa-disabled/</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-03-github-2fa-disabled/</guid><description>The disabling of two-factor authentication (2FA) in GitHub Organizations is detected through audit log monitoring, potentially indicating an attacker's attempt to weaken account security and facilitate unauthorized access.</description><content:encoded><![CDATA[<p>This detection identifies instances where two-factor authentication (2FA) requirements are disabled within GitHub Organizations. By monitoring GitHub Organizations audit logs, this analytic tracks changes to 2FA requirements, capturing details about the actor, organization, and associated metadata. Disabling 2FA weakens security controls, increasing the risk of account compromise via password-based attacks. The absence of 2FA can lead to unauthorized access to sensitive code repositories, intellectual property, and potential compromise of the software supply chain. The activity observed in this analytic aligns with actions outlined in the MITRE ATT&amp;CK framework such as impair defenses (T1562.001) and supply chain compromise (T1195).</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to a privileged GitHub account, possibly through credential compromise or social engineering.</li>
<li>The attacker authenticates to the GitHub organization with the compromised account.</li>
<li>The attacker navigates to the organization&rsquo;s security settings within GitHub.</li>
<li>The attacker disables the requirement for two-factor authentication (2FA) for the organization.</li>
<li>GitHub audit logs record the &ldquo;org.disable_two_factor_requirement&rdquo; event, capturing details of the actor and organization.</li>
<li>With 2FA disabled, the attacker can now access other accounts within the organization more easily without needing to bypass multi-factor authentication.</li>
<li>The attacker then uses the compromised accounts to access sensitive code repositories or other resources within the organization.</li>
<li>The attacker exfiltrates sensitive data or injects malicious code into the software supply chain.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Disabling 2FA in GitHub organizations increases the risk of account takeover and unauthorized access to sensitive code and intellectual property. A successful attack could lead to the compromise of the software supply chain, impacting not only the organization itself but also its customers and users. This can result in reputational damage, financial losses, and legal liabilities. The Google Cloud Community reported on using Google Security to monitor for suspicious GitHub activity.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Enable and maintain the Splunk Add-on for GitHub to ingest GitHub Organizations audit logs as detailed in the references.</li>
<li>Deploy the Sigma rule <code>GitHub Organizations Disable 2FA Requirement</code> to detect instances of 2FA being disabled.</li>
<li>Investigate any alerts generated by the Sigma rule, focusing on the <code>actor</code>, <code>actor_id</code>, and <code>actor_ip</code> fields to identify potentially compromised accounts.</li>
<li>Monitor user agent strings (<code>user_agent</code> field) for suspicious or anomalous activity related to the disabling of 2FA.</li>
<li>Review and enforce strong password policies and educate users about the importance of 2FA to prevent initial account compromise.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>github</category><category>2fa</category><category>security_controls</category><category>supply_chain</category></item><item><title>ESXi Lockdown Mode Disabled</title><link>https://feed.craftedsignal.io/briefs/2024-01-esxi-lockdown-disabled/</link><pubDate>Tue, 02 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-esxi-lockdown-disabled/</guid><description>The disabling of Lockdown Mode on an ESXi host may indicate a threat actor attempting to weaken host security controls to enable broader remote access for data exfiltration, lateral movement, or VM tampering.</description><content:encoded><![CDATA[<p>This detection identifies when Lockdown Mode is disabled on an ESXi host. Threat actors might disable this mode to weaken host security controls, allowing broader remote access via SSH or the host client. This action could be a precursor to further malicious activities such as data exfiltration, lateral movement within the environment, or tampering with virtual machines. Identifying this activity is crucial as it signifies a potential compromise of the ESXi host, which could lead to significant disruption and data loss. The detection logic is based on ESXi Syslog data.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains initial access to the ESXi host, potentially through compromised credentials or exploiting a vulnerability.</li>
<li>The attacker authenticates to the ESXi host.</li>
<li>The attacker executes a command to disable Lockdown Mode. This may be done through the vSphere client or directly via SSH if enabled.</li>
<li>The ESXi host logs the event of Lockdown Mode being disabled within its syslog.</li>
<li>With Lockdown Mode disabled, the attacker gains broader access to the host&rsquo;s management interfaces.</li>
<li>The attacker performs reconnaissance activities, gathering information about the host and its virtual machines.</li>
<li>The attacker moves laterally to other systems within the environment, leveraging the compromised ESXi host.</li>
<li>The attacker exfiltrates sensitive data or manipulates virtual machines, achieving their final objectives.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Disabling Lockdown Mode can lead to a complete compromise of the ESXi host and the virtual machines it manages. This can result in data exfiltration, data corruption, or the deployment of ransomware on the virtual machines. Depending on the environment, this can affect hundreds or thousands of virtual machines, potentially disrupting critical business operations. The &ldquo;Black Basta Ransomware&rdquo; analytic story is related to this threat.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Configure ESXi hosts to forward syslog output to a SIEM or log aggregation system to enable detection of this activity, as detailed in the &ldquo;How to Implement&rdquo; section of the source.</li>
<li>Deploy the Sigma rule <code>ESXi Lockdown Mode Disabled</code> to your SIEM to detect instances where Lockdown Mode is disabled on ESXi hosts.</li>
<li>Investigate any alerts generated by the Sigma rule <code>ESXi Lockdown Mode Disabled</code> to determine the root cause and scope of the potential compromise.</li>
<li>Monitor ESXi syslog for messages indicating changes to host security configurations.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>esxi</category><category>vmware</category><category>lockdown_mode</category><category>security_controls</category></item></channel></rss>