Author: Scott Dahlke

Categories
Cybersecurity Advisories Uncategorized

Vulnerability in XZ Utils Data Compression Library Impacting Multiple Linux Distributions (CVE-2024-3094)

Description of the vulnerability per NIST:

“Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting, and modifying the data interaction with this library.”

This vulnerability was intentionally induced by a supply chain attack. Starting in 2021, a suspected Threat Actor started to submit patches to open-source project on GITHUB, eventually focusing on the XZ Utils repository and becoming a co-developer. A fuller timeline of events can be found here. The backdoor/vulnerability was fully introduced in versions 5.6.0 and 5.6.1 of xz utils in February. Most production Linux distributions have not adopted these patches, but please check the following section to confirm that no affected versions are present in your environment.

Affected & Fixed Versions

Recommendations and Mitigations

SecurIT360 Managed SOC Clients:

  • For all active managed SOC EDR clients, we have checked our inventory across products and have already reached out if you have an affected Linux distribution.
  • For all active managed SOC MDR clients, we have also run an external Nessus vulnerability scan looking for affected versions and have again already reached out to any and all affected clients.

Otherwise, if you have any Linux endpoint that we do not monitor that you are concerned may be affected by this vulnerability, you can run a simple command of “xz –version” or “xz ultis –version” on these endpoints to confirm your versioning on the endpoint in question:

If any of your endpoints do presently use 5.6.0 and 5.6.1 of XZ Utils, we would recommend either updating or downgrading packages per the table above. For the case of Fedora 40-41 and Rawhide specifically the recommendation from Red Hat would be to power-down or stop using Rawhide for the time being, and to move to packages 5.4.X for Fedora 40-41. See Red Hat’s blog post on the subject for more information.

Resources & Related Articles

Categories
Cybersecurity Advisories

Russia-linked Midnight Blizzard Cyberattack: Awareness and Guidance

Given the recent report from Microsoft regarding a cyber-attack on their organization by Russian state-sponsored hacking group, Midnight Blizzard, our SOC Team wanted to raise awareness concerning Threat Actor behavior related to Entra ID (formerly Azure ID) app registrations/app consent per what we have been seeing in the news and in the wild.

You can read Microsoft’s report detailing this behavior that was observed during their own recent compromise by this threat actor group: https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/

This post explains that the threat actor group “Midnight Blizzard” gained access to an account through a password spray and then leveraged existing OAuth applications and created additional applications to escalate privileges and compromise additional accounts.

Our DFIR team has also seen similar behavior recently during BEC investigations, where compromised account gave consent to a specific third-party application called “PerfectData Software” likely in an attempt to exfil mailbox data.

See the following link for additional information on this specific behavior: How Abuse of ‘PerfectData Software’ May Create a Perfect Storm: An Emerging Trend in Account Takeovers | Darktrace Blog

The following will detail the actions we are detecting on our end to better detect this type of post-compromise behavior related to app consent grants/permissions/registrations and how we recommend you can mitigate this type of attack in your environment.

SecurIT360 SOC Managed Services

Last week, our managed SOC services rolled out a new alert that will detect the creation of a service principal that looks for “PerfectData Software” specifically. A service principal in Entra ID (Formerly Azure AD) is an identify created to manage access for applications, hosted services, and/or automated tools.

We also plan to create an additional rule or rules to provide auditing for application management within our Monthly MDR reports. 

Additionally, as always, we will continue to provide monitoring and alerting concerning initial access by looking for possible password sprays, MFA bombing, suspicious logins, etc. to attempt to prevent this sort of behavior before it happens. However, as we believe in a defense in depth approach, we will continue to expand and refine our post-access detection capabilities through the rules mentioned above. 

Please feel free to contact the SOC via email at soc@securit360.com if you have any questions or concerns.  

Mitigation Recommendations

By default, users are allowed to register applications and give consent to third party applications. This means that if a Threat Actor compromises a standard user account they can give consent to apps or register apps, without having any admin permissions or an admin being notified.

However, you can restrict this behavior by editing default role permissions and require admin consent to be given before a user gives access to an application.  We strongly recommend you adjust this default permission and review all active registrations ASAP.

How to Change Default Permissions

  1. In order to restrict default user role permissions, within the Azure portal you can go to Microsoft Entra ID -> Users -> User settings and change the slider for “Users can register applications” to “No”:

See the following Microsoft KB article to learn more about default user permissions: Default user permissions – Microsoft Entra | Microsoft Learn

  1. To turn off or edit a user’s ability to grant consent to third part applications you can go to the Microsoft Entra admin center -> Identity- > Applications -> Enterprise applications -> Consent and permissions -> User consent settings.

  2. You can also configure a workflow that would allow admins to consent on behalf of users: Configure the admin consent workflow – Microsoft Entra ID | Microsoft Learn

Review Existing App Registrations

Once the permissions have been changed, perform a review of all current App Registrations within your Azure/Entra ID environment and consider disabling all of them that are not approved.

Additionally, as we saw in the Microsoft case, regular auditing of app registrations and permissions in addition to similar auditing for user accounts is always recommended and an important part of lowering the potential impact of an account compromise.

Please let us know if you have additional questions or concerns. We are always happy to help you adjust in response to new or emerging threats.

Ready to make cybersecurity your strength, not your weakness? Contact us today and let’s build a safer, more secure digital future for your business.

Categories
Email Security

How to configure warning messages for Microsoft 365 emails from external senders

Configure Warning Messages Office 365 Emails External Sender

As a security precaution, it’s a good idea to remind your staff not to open attachments from unknown senders. One easy way to implement this in Microsoft 365 is by setting up a mail flow rule in the Exchange admin center. If you have ever set up a Disclaimer mail flow rule, the setup is almost identical. In this tutorial, we’ll cover how to setup your own warning message for all external email sent to users inside your organization.

Steps to Configure Attachment Security in Microsoft 365

1. Log in to your Microsoft 365 Admin account at: https://portal.office.com

2. On the lefthand side of the homepage, select the “Admin” app from your list of Apps:

3. On the resulting page, select “Exchange” under “Admin centers” located on the left-side menu

4. Again on the left menu, expand the dropdown menu for “Mail flow” and select “Rules”

5. On the resulting page, next hit the plus symbol under “Rules” and select “create a new rule…”

 

6. Fill out the “New Rule” popup window in the detailed steps 7-14:

7. Make the name, “Warning: Received from Scope Outside the Organization” or whatever best suits you or your organization’s naming convention

8. For *Apply this rule if…  Select “The sender is located…”, from the drop-down menu then choose “Outside the organization” from the resulting “select sender location” window:

9. For *Do the following… , select “Apply a disclaimer to the message…” , “append the disclaimer”.

10. Select “*Enter text…” and enter the below HTML into the “specify disclaimer text” pop-out window

[CAUTION:  This email originated from outside of the organization.  Do not click links or open attachments unless you recognize the sender and know the content is safe]

The warning will look like the following if entered correctly:

11. After entering the Text, you’ll need to specify the fallback action. (by clicking “*Select one…”). Choose Wrap, then “OK”.

12. For the “Priority level of this rule” set according to any other rules you have configured. If this is the only rule, you can set “Audit this rule with severity level to “High”.

13. For “Choose a mode for this rule” leave at the selected default “Enforce” in place.

14. Click Save.

That’s it! You should start seeing the warning on external emails within a few minutes.

If you would like to learn more about how you can protect your corporate data, please click here to contact us. Keep up with the latest cybersecurity news here. SecurIT360 provides audits, scans, and analysis of various systems and businesses across multiple industries including legal, financial, utilities, and healthcare. Let us help you determine where you should spend your time and money protecting your information.