Monday, May 10, 2021

Android users’ privacy at risk Bug in Qualcomm mobile chip


Qualcomm has confirmed the bug and fixed the issue and mobile players are notified, according to the researchers.

According to researchers with Israeli cybersecurity firm Checkpoint have discovered a high-risk security vulnerability in Qualcomm mobile chip responsible for cellular communication in nearly 40 per cent of the high-end phones offered by Google, Samsung, LG, Xiaomi and OnePlus.

If exploited, the vulnerability in Qualcomm mobile station modem (MSM) would have allowed an attacker to use Android OS itself as an entry point to inject malicious and invisible code into phones, granting them access to SMS messages and audio of phone conversations, according to Check Point Research.

“During our investigation, we discovered a vulnerability in a modem data service that can be used to control the modem and dynamically patch it from the application processor,” they said in a blog post on Thursday.

According to Counterpoint Research, Qualcomm’s Mobile Station Modem is a system of chips that provides capabilities for things like voice, SMS, and high-definition recording, mostly on higher-end devices.

“This means an attacker could have used this vulnerability to inject malicious code into the modem from Android, giving them access to the device user’s call history and SMS, as well as the ability to listen to the device user’s conversations,” they added.

A hacker can also exploit the vulnerability to unlock the device’s SIM, thereby overcoming the limitations imposed by service providers on it.

Mobile devices should always be updated to the latest version of the OS to protect against the exploitation of vulnerabilities. Only installing apps downloaded from official app stores reduces the probability of downloading and installing a mobile malware,” the researchers advised.

In August 2020, Check Point Research found over 400 vulnerabilities on Qualcomm’s Snapdragon DSP (Digital Signal Processor) chip that threatened the usability of mobile phones.

Vulnerability also could have potentially allowed an attacker to unlock a mobile device’s SIM, according to the cyber security company.

Monday, April 26, 2021

Securing the Industrial Internet of Things—Cybersecurity for Distributed Energy Resources: Preliminary Draft of SP 1800-32 Available for Comment


Securing the Industrial Internet of Things—Cybersecurity for Distributed Energy Resources: Preliminary Draft of SP 1800-32 Available for Comment

NIST’s National Cybersecurity Center of Excellence (NCCoE) has posted for comment a Preliminary Draft of Special Publication (SP) 1800-32, Volumes A and B, on Securing the Industrial Internet of Things: Cybersecurity for Distributed Energy Resources.

The use of small-scale distributed energy resources (DERs), such as wind and solar photovoltaics, are growing rapidly and transforming the power grid. In fact, a distribution utility may need to remotely communicate with thousands of DERs and other grid-edge devices—many of which are not owned by them.  Any attack that can deny, disrupt, or tamper with DER communications could prevent a utility from performing necessary control actions and could diminish grid resiliency.

In this practice guide, the NCCoE applies standards, best practices, and commercially available technology to protect the digital communication, data, and control of cyber-physical grid-edge devices. The guide demonstrates an example solution for monitoring and detecting unusual behavior of connected industrial internet of things devices and building a comprehensive audit trail of trusted IIoT data flows. 

By releasing Volumes A and B as a preliminary draft, we are sharing our progress made to date, using the feedback received to shape future drafts of the practice guide, and featuring technologies and practices that organizations can use to monitor, trust, and protect information exchanges between commercial- and utility-scale distributed energy resources (DERs). 

The public comment period is open through May 24, 2021. See the publication details for a copy of the draft volumes and instructions for submitting comments.

NCCoE homepage:

Publication detail:

Project homepage:

NIST Requests Comments for Updated Guide to Industrial Control Systems Security


NIST Requests Comments for Updated Guide to Industrial Control Systems Security

Today NIST initiated an update for SP 800-82, Guide to Industrial Control Systems (ICS) Security, to incorporate lessons learned over the past several years, to provide alignment to relevant NIST guidance (e.g., NIST SP 800-37 Rev. 2NIST SP 800-53 Rev. 5, NIST SP 800-53B, and the Cybersecurity Framework v1.1), to provide alignment to other relevant control system cybersecurity standards and recommended practices, and to address changes in the threat landscape.

NIST seeks input from SP 800-82 stakeholders to ensure that the future update will continue to deliver the guidance necessary to help organizations manage the cybersecurity risks associated with their control systems.

Specifically, NIST requests input on the following:

  • Expansion in scope of SP 800-82 from industrial control systems to control systems in general                                                                               
  • Application of new cybersecurity capabilities in control system environments
  • Development of guidance specific to small and medium-sized control system owners and operators
  • Updates to control system threats, vulnerabilities, standards and recommended practices
  • Updates to the control system Overlay
  • Removal of material from the current document that is outdated, unneeded, or no longer applicable.

See the full call for comments for additional details.

All comments are due by May 28, 2021. Please submit your comments by email to When providing comments, please be specific and include the rationale for any proposed additions or deletions of material.

An Initial Public Draft of the update, which will be published as SP 800-82 Rev. 3, is scheduled for a late 2021/early 2022 release.

Call for Comments on SP 800-82:

Other publication details:

SP 800-37 Rev. 2:

SP 800-53 Rev. 5:

SP 800-53B:

NIST Cybersecurity Framework v1.1:

More Security Blogs from Microsoft


Title: Defending against cryptojacking with Microsoft Defender for Endpoint and Intel TDT
Date Published (MM/dd/YYYY): 04/26/2021

With cryptocurrency mining on the rise, Microsoft and Intel have partnered to deliver threat detection technology to enable EDR capabilities in Microsoft Defender for Endpoint.


Title: Non-interactive logins: minimizing the blind spot
Published On (MM/dd/yyyy): 04/25/2021

Special thanks to   for collaborating on this blog post with me! 


In this blog post, we will review the new Azure Sentinel data streams for Azure Active Directory non-interactive, service principal, and managed identity logins. We will also share the new security content we built and updated in the product, which includes analytics rules for the detection part and workbooks to assist our customers to deal with this blind spot.


The shift to the cloud and the rise of automation tasks and service-to-service integration have contributed to a dramatic increase in the use of managed applications, service principals, and managed identities.

These new security objects perform login activity which is not captured in Azure Active Directory’s traditional sign-in logs.

The updated Azure Active Directory data connector now brings these important sign-in events into Azure sentinel.

 What are non-interactive logins?

Non-interactive user sign-ins are sign-ins that were performed by a client app or an OS component on behalf of a user. Like interactive user sign-ins, these sign-ins are done on behalf of a user. Unlike interactive user sign-ins, these sign-ins do not require the user to supply an Authentication factor. Instead, the device or client app uses a token or code to authenticate or access a resource on behalf of a user. In general, the user will perceive these sign-ins as happening in the background of the user’s activity. 

Some activity that is captured in these logs:

  • A client app uses an OAuth 2.0 refresh token to get an access token.
  • A client uses an OAuth 2.0 authorization code to get an access token and refresh token.
  • A user performs single sign-on (SSO) to a web or Windows app on an Azure AD joined PC.
  • A user signs in to a second Microsoft Office app while they have a session on a mobile device using FOCI (Family of Client IDs).


Why is it so important to monitor and detect activities in this area?


Some examples that highlight why it’s so important to collect, and get visibility into these logs as part of your detections and hunting:


  1. SolarWinds campaign – As part of our learning on the SolarWinds campaign investigation, we used these logs in the hunting phase to check if the malicious actor used a sensitive app to gain “Data Access”.


Title: Best practices for leveraging Microsoft 365 Defender API's - Episode Two
Published On (YYYY-dd-MM):2021-26-04

In the previous episode we provided recommendations about how to use the Microsoft 365 Defender API and, specifically, how to optimize the Advanced hunting query.

In this episode we will demonstrate use cases detailing how to access the API data and use this information in other products. 

One of the most common uses of the API is for visualization in PowerBIThis provides the capability to analyze, visualize, and share your data with others quickly and easily.

If you are not familiar with PowerBi, we suggest you visit the Microsoft PowerBi web site, and download PowerBI desktop. 

We already documented how to use PowerBI to create custom reports using  
Microsoft Defender for Endpoint APIs connection to Power BI - Windows security | Microsoft Docs. 


Title: Best practices for leveraging Microsoft 365 Defender API's - Episode Three
Published On (YYYY-dd-MM):2021-26-04

In the previous episode, we described how you can easily use PowerBi to represent Microsoft 365 data in a visual format. In this episode, we will explore another way you can interact with the Microsoft 365 Defender API. We will describe how to automate data analysis and hunting using Jupyter notebook.

 Automate your hunting queries 

While hunting and conducting investigations on a specific threat or IOC, you may want to use multiple queries to obtain wider optics on the possible threats or IOCs in your network. You may also want to leverage queries that are used by other hunters and use it as a pivot point to perform deep analysis and find anomalous behaviors. You can find a wide variety of examples in our Git repository where various queries related to the same campaign or attack technique are shared.  

In scenarios such as this, it is sensible to leverage the power of automation to run the queries rather than running individual queries one-by-one.  

This is where Jupyter Notebook is particularly useful. It takes in a JSON file with hunting queries as input and executes all the queries in sequence. The results are saved in a .csv file that you can analyze and share. 


Title: March Ahead with Azure Purview: Access management in Azure Purview - Part 3
Date Published (MM/dd/YYYY): 04/22/2021

Hopefully, you have read my previous blog posts about Azure Purview access management Part 1 and Part 2 to find about Azure Purview control plane and data plane roles and tasks. In this post, I will cover the following topic:


  • Overview of dashboards and roles required to extend your M365 Sensitivity Labels to Azure Purview.


By extending M365 Sensitivity Labels to Azure Purview you can automatically assign labels to files and database columns in Azure Purview.


We have a new Azure Purview bog for your consideration. Please remember that Azure Purview is a unified data governance service, and security is one of its pillars.

Title: Azure Purview resource set pattern rules available in Public Preview
Date Published (MM/dd/YYYY): 04/21/2021

At-scale data processing systems typically store a single table in a data lake as multiple files. This concept is represented in Azure Purview by using resource sets. A resource set is a single object in the data catalog that represents a large number of assets in storage. To learn more, see the resource set documentation.


When scanning a storage account, Azure Purview uses a set of defined patterns to determine if a group of assets is a resource set. In some cases, Azure Purview's resource set grouping may not accurately reflect your data estate. Resource set pattern rules allow you to customize or override how Azure Purview detects which assets are grouped as resource sets and how they are displayed within the catalog.


Pattern rules are currently supported in public preview in the following source types:

  • Azure Data Lake Storage Gen2
  • Azure Blob Storage
  • Azure Files

To learn more on how to create resource set pattern rules, see our step-by-step how-to documentation!


Title: eDiscovery in Microsoft 365 One Stop Shop Resource Page
Date Published (MM/dd/YYYY): 04/21/2021


Welcome to the eDiscovery in Microsoft 365 One Stop Shop Resource Page!


We built this page to help you easily find all relevant content and resources relating to the compliance solutions in Microsoft 365. Please bookmark this page for future reference as we will update it on an ongoing basis.


CISA and NIST Release New Interagency Resource: Defending Against Software Supply Chain Attacks

 Original release date: April 26, 2021

A software supply chain attack—such as the recent SolarWinds Orion attack—occurs when a cyber threat actor infiltrates a software vendor’s network and employs malicious code to compromise the software before the vendor sends it to their customers. The compromised software can then further compromise customer data or systems.

To help software vendors and customers defend against these attacks, CISA and the National Institute for Standards and Technology (NIST) have released Defending Against Software Supply Chain Attacks. This new interagency resource provides an overview of software supply chain risks and recommendations. The publication also provides guidance on using NIST’s Cyber Supply Chain Risk Management (C-SCRM) framework and the Secure Software Development Framework (SSDF) to identify, assess, and mitigate risks.

CISA encourages users and administrators to review Defending Against Software Supply Chain Attacks and implement its recommendations.

Tuesday, April 13, 2021

Apply Microsoft April 2021 Security Update to Mitigate Newly Disclosed Microsoft Exchange Vulnerabilities


Cybersecurity and Infrastructure Security Agency (CISA) - Defend Today, Secure Tomorrow

You are subscribed to National Cyber Awareness System Current Activity for Cybersecurity and Infrastructure Security Agency. This information has recently been updated, and is now available.

Apply Microsoft April 2021 Security Update to Mitigate Newly Disclosed Microsoft Exchange Vulnerabilities

Original release date: April 13, 2021

Microsoft's April 2021 Security Update mitigates significant vulnerabilities affecting on-premises Exchange Server 2016 and 2019. An attacker could exploit these vulnerabilities to gain access and   maintain persistence on the target host. CISA strongly urges organizations to apply Microsoft's April 2021 Security Update to mitigate against these newly disclosed vulnerabilities. Note: the Microsoft security updates released in March 2021 do not remediate against these vulnerabilities.

In response to these the newly disclosed vulnerabilities, CISA has issued Supplemental Direction Version 2 to Emergency Directive (ED) 21-02: Mitigate Microsoft Exchange On-Premises Product Vulnerabilities. ED 20-02 Supplemental Direction V2 requires federal departments and agencies to apply Microsoft's April 2021 Security Update to mitigate against these significant vulnerabilities affecting on-premises Exchange Server 2016 and 2019.

Although CISA Emergency Directives only apply to Federal Civilian Executive Branch agencies, CISA strongly encourages state and local governments, critical infrastructure entities, and other private sector organizations to review ED 21-02 Supplemental Direction V2 and apply the security updates immediately. Review the following resources for additional information:

Microsoft April 2021 Security Update Summary

New DNS Vulnerabilities, Impacting 100+ Millions of Enterprise and Consumer Devices

 Forescout Research Labs, partnering with JSOF Research, disclose NAME:WRECK, a set of nine vulnerabilities affecting four popular TCP/IP stacks (FreeBSD, Nucleus NET, IPnet and NetX). These vulnerabilities relate to Domain Name System (DNS) implementations, causing either Denial of Service (DoS) or Remote Code Execution (RCE), allowing attackers to take target devices offline or to take control over them.

The widespread use of these stacks and often external exposure of vulnerable DNS clients lead to a dramatically increased attack surface. This research is further indication that the community should fix DNS problems that we believe are more widespread than what we currently know.

This research uncovered vulnerabilities on very popular stacks:

1. Nucleus NET is part of the Nucleus RTOS. The Nucleus RTOS website mentions that more than 3 billion devices use this real-time operating system, such as ultrasound machines, storage systems, critical systems for avionics and others. The most common device types running Nucleus RTOS include building automation, operational technology and VoIP.

2. FreeBSD is widely known to be used for high-performance servers in millions of IT networks and is also the basis for other well-known open-source projects, such as firewalls and several commercial network appliances. The most common device types on Device Cloud running FreeBSD include computers, printers and networking equipment.

3. NetX is usually run by the ThreadX RTOS. Typical applications include medical devices, systems-on-a-chip and several printer models. ThreadX was known to have 6.2 billion deployments in 2017, with mobile phones (probably in baseband processors), consumer electronics and business automation being the most common product categories. The most common device types running ThreadX include printers, smart clocks and energy and power equipment in Industrial Control Systems.

Organizations in the Healthcare and Government sectors are in the top three most affected for all three stacks. If we conservatively assume that 1% of the more than 10 billion deployments discussed above are vulnerable, we can estimate that at least 100 million devices are impacted by NAME:WRECK.

The details of these vulnerabilities are described in our technical report and will be presented at Black Hat Asia 2021.

Helping the community to fix DNS vulnerabilities

Disclosing these vulnerabilities to vendors provides much-needed information and education on the impacted products and continues the dialogue in the research community:

1. We urge developers of TCP/IP stacks that have yet to be analyzed to take the anti-patterns available in our technical report, check their code for the presence of bugs and fix them. To help with this process, we are releasing open-source code developed for the Joern static analysis tool. This code formalizes the anti-patterns we identified, allowing researchers and developers to automatically analyze other stacks for similar vulnerabilities.

2. We invite researchers, developers and vendors to reach out to us if they are interested in a set of small proof-of-concept crashing network packets for the identified anti-patterns. These packets can be used to automatically test intrusion detection rules.

3. We realized that many vulnerabilities exist because RFC documents are either unclear, ambiguous or too complex. To help prevent such issues from reappearing in the future, we have submitted to the IETF an informational RFC draft where we list the anti-patterns we identified and how to avoid them while implementing a DNS client or server.

Recommended Mitigation

Complete protection against NAME:WRECK requires patching devices running the vulnerable versions of the IP stacks. FreeBSD, Nucleus NET and NetX have been recently patched, and device vendors using this software should provide their own updates to customers.

However, patching devices is not always possible, and the required effort changes drastically depending upon whether the device is a standard IT server or an IoT device.

Given the challenges of patching, we also recommend the following mitigation strategy:

1. Discover and inventory devices running the vulnerable stacks. Forescout Research Labs has released an open-source script that uses active fingerprinting to detect devices running the affected stacks. The script is updated constantly with new signatures to follow the latest development of our research. Forescout customers using eyeSight can also automatically identify devices using FreeBSD, Nucleus RTOS, ThreadX or VxWorks.

2. Enforce segmentation controls and proper network hygiene to mitigate the risk from vulnerable devices. Restrict external communication paths, and isolate or contain vulnerable devices in zones as a mitigating control if they cannot be patched or until they can be patched.

3. Monitor progressive patches released by affected device vendors and devise a remediation plan for your vulnerable asset inventory, balancing business risk and business continuity requirements.

4. Configure devices to rely on internal DNS servers as much as possible and closely monitor external DNS traffic since exploitation requires a malicious DNS server to reply with malicious packets.

5. Monitor all network traffic for malicious packets that try to exploit known vulnerabilities or possible 0-days affecting DNS, mDNS and DHCP clients. Anomalous and malformed traffic should be blocked, or its presence should be at least alerted to network operators. To exploit NAME:WRECK vulnerabilities, an attacker should adopt a similar procedure for any TCP/IP stack. This means that the same detection technique used to identify exploitation of NAME:WRECK will also work to detect exploitation on other TCP/IP stacks and products that we could not yet analyze. In addition, Forescout eyeInspect customers that enabled the threat detection SD script delivered as part of AMNESIA:33 can detect exploitation of NAME:WRECK.

For more information, visit our NAME:WRECK resources page