The initial public draft introduced four significant changes to
NIST SP 800-140B:
Defines a more detailed
structure and organization for the Security Policy
Captures Security Policy
requirements that are defined outside of ISO/IEC 19790 and ISO/IEC 24759
Builds the Security Policy
document as a combination of the subsection information
Generates the approved
algorithm table based on lab/vendor selections from the algorithm tests
This second draft addresses the comments made on the initial
draft, including concerns with the structure of the Security Policy and the
process for creating it. Appendix B provides details on these changes.
The NIST SP 800-140x series supports Federal Information
Processing Standards (FIPS) Publication 140-3, Security Requirements for Cryptographic Modules,
and its associated validation testing program, the Cryptographic Module
Validation Program (CMVP). The series specifies modifications to ISO/IEC 19790
Annexes and ISO/IEC 24759 as permitted by the validation authority.
The public comment period is open through December 5, 2022. See
the publication
details for instructions on submitting comments.
The HIPAA Security Rule specifically focuses on protecting the
confidentiality, integrity, and availability of electronic protected health
information (ePHI), as defined by the Security Rule. All HIPAA-regulated
entities must comply with the requirements of the Security Rule.
This draft:
Includes a brief overview of
the HIPAA Security Rule
Provides guidance for regulated
entities on assessing and managing risks to ePHI
Identifies typical activities
that a regulated entity might consider implementing as part of an
information security program
Lists additional resources that
regulated entities may find useful in implementing the Security Rule
Please submit comments to [email protected] through October 5, 2022.
See the publication
details for a copy of the draft and instructions for submitting
comments.
Created in 2014, this collaborative event is cooperatively
developed, organized and sponsored by the leading information security industry
organizations and chapters, including NY Metro ISSA. The strength of
organizational membership, the provision of desirable CPE credits and the
concurrence of National Cyber Security Awareness Month, is always well-attended
by members of the information technology, information security, audit,
academic, and business communities.
CISA warns users to remain on alert for malicious cyber activity targeting
potential disaster victims and charitable donors following a hurricane. Fraudulent
emails—often containing malicious links or attachments—are common after major
natural disasters. Exercise caution in handling emails with hurricane-related
subject lines, attachments, or hyperlinks. In addition, be wary of social media
pleas, texts, or door-to-door solicitations relating to severe weather
events.
To avoid becoming victims of malicious activity, users and administrators
should review the following resources and take preventative measures.
If you believe you have been a victim of cybercrime, file a complaint with
Federal Bureau of Investigation’s Internet Crime Complaint Center (IC3) at www.ic3.gov.
The NIST SP 800-90 series of documents supports the generation of
high-quality random bits for cryptographic and non-cryptographic use. SP
800-90A specifies several deterministic random bit generator (DRBG) mechanisms
based on cryptographic algorithms. SP 800-90B provides guidance for the
development and validation of entropy sources. SP 800-90C specifies
constructions for the implementation of random bit generators (RBGs) that
include DRBG mechanisms as specified in SP 800-90A and that use entropy sources
as specified in SP 800-90B.
This draft includes constructions for three classes of RBGs:
An RBG1 construction provides
random bits from a device that is initialized from an external RBG.
An RBG2 construction includes
an entropy source that is available on demand.
An RBG3 construction includes
an entropy source that is continuously accessed to provide output with
full entropy.
SP 800-90C includes a note to readers, guidance for accessing and
handling the entropy sources in SP 800-90B, specifications for the
initialization and use of the three RBG constructions that incorporate the
DRBGs from SP 800-90A, and guidance on health testing and implementation
validation using NIST’s Cryptographic Algorithm Validation Program (CAVP) and
the Cryptographic Module Validation Program (CMVP) that is jointly operated by
NIST and the Canadian Centre for Cyber Security (CCCS).
The public comment period for NIST SP 800-90C is open through
December 7, 2022. See the publication
details for a copy of the draft and instructions for submitting
comments.
NIST IR 8286C describes methods for combining risk information
from across the enterprise, including notional examples for aggregating and
normalizing the results from cybersecurity risk registers (CSRRs) while considering
risk parameters, criteria, and business impacts. The resulting integration and
normalization of risk information informs enterprise-level risk decision-making
and monitoring, which helps create a comprehensive picture of the overarching
cyber risk. The report describes the creation of an enterprise risk profile
(ERP) that supports the comparison and management of cyber risks along with
other risk types.
The NIST IR 8286 series enables risk practitioners to integrate
CSRM activities more fully into the broader enterprise risk processes. Because
information and technology comprise some of the enterprise’s most valuable
resources, it is vital that directors and senior leaders have a clear
understanding of cybersecurity risk posture at all times. It is similarly vital
that those identifying, assessing, and treating cybersecurity risk understand
enterprise strategic objectives when making risk decisions.
The authors of the NIST IR 8286 series hope that these
publications will spark further industry discussion. As NIST continues to
develop frameworks and guidance to support the application and integration of
information and technology, many of the series’ concepts will be considered for
inclusion.
Our analysis of a recent version of a previously reported info-stealing Android malware, delivered through an ongoing SMS campaign, demonstrates the continuous evolution of mobile threats. Masquerading as a banking rewards app, this new version has additional remote access trojan (RAT) capabilities, is more obfuscated, and is currently being used to target customers of Indian banks. The SMS campaign sends out messages containing a link that points to the info-stealing Android malware. The malware’s RAT capabilities allow the attacker to intercept important device notifications such as incoming messages, an apparent effort to catch two-factor authentication (2FA) messages often used by banking and financial institutions. The malware’s ability to steal all SMS messages is also concerning since the data stolen can be used to further steal users’ sensitive info like 2FA messages for email accounts and other personally identifiable information (PII).
Figure 1. Typical SMS campaign attack flow
Our investigation of this new Android malware version started from our receipt of an SMS message containing a malicious link that led us to the download of a fake banking rewards app. The fake app, detected as TrojanSpy:AndroidOS/Banker.O, used a different bank name and logo compared to a similar malware reported in 2021. Moreover, we found that this fake app’s command and control (C2) server is related to 75 other malicious APKs based on open-source intelligence. Some of the malicious APKs also use the same Indian bank’s logo as the fake app that we investigated, which could indicate that the actors are continuously generating new versions to keep the campaign going.
This blog details our analysis of the recent version’s capabilities. We strongly advise users never to click on unknown links received in SMS messages, emails, or messaging apps. We also recommend seeking your bank’s support or advice on digital options for your bank. Further, ensure that your banking apps are downloaded from official app stores to avoid installing malware.
Microsoft researchers recently investigated an attack where malicious OAuth applications were deployed on compromised cloud tenants and then used to control Exchange Online settings and spread spam. The investigation revealed that the threat actor launched credential stuffing attacks against high-risk accounts that didn’t have multi-factor authentication (MFA) enabled and leveraged the unsecured administrator accounts to gain initial access. The unauthorized access to the cloud tenant enabled the actor to create a malicious OAuth application that added a malicious inbound connector in the email server. The actor then used the malicious inbound connector to send spam emails that looked like they originated from the targets’ domain. The spam emails were sent as part of a deceptive sweepstakes scheme meant to trick recipients into signing up for recurring paid subscriptions.
Microsoft has been monitoring the rising popularity of OAuth application abuse. One of the first observed malicious usage of OAuth applications in the wild is consent phishing. Consent phishing attacks aim to trick users into granting permissions to malicious OAuth apps to gain access to user’s legitimate cloud services (mail servers, files storage, management APIs, etc.). In the past few years, Microsoft has observed that more and more threat actors, including nation-state actors, have been using OAuth applications for different malicious purposes – command-and-control (C2) communication, backdoors, phishing, redirections, and so on.
This recent attack involved a network of single-tenant applications installed in compromised organizations being used as the actor’s identity platform to perform the attack. As soon as the network was revealed, all the related applications were taken down and notifications to customers were sent, including recommended remediation steps.
This blog presents the technical analysis of this attack vector and the succeeding spam campaign attempted by the threat actor. It also provides guidance for defenders on protecting organizations from this threat, and how Microsoft security technologies detect it.
Figure 1. Overview of the attack chain. The time between application deployment and usage varied; there were cases where the actor took months before using the application.
Initial access
For the attack to succeed, the threat actor needed to compromise cloud tenant users with sufficient permissions that would allow the actor to create an application in the cloud environment and give it admin consent. The actor performed credential stuffing attacks against their targets, attempting to access users with the global admin role. The authentication attempts, which originated from a single IP address, were launched against the Azure Active Directory PowerShell application (app ID: 1b730954-1685-4b74-9bfd-dac224a7b894). The same application was later used to deploy the rest of the attack.
Based on the success ratio of the authentication attempts, it is inferred that the attacker used a dump of compromised credentials. The investigation also revealed that 86% of the compromised tenants had at least one admin with a real-time high risk score, which means they were flagged by Azure AD Identity Protection to be most likely compromised. It is also important to note that all the compromised admins didn’t have MFA enabled, which could have stopped the attack. These observations amplify the importance of securing accounts and monitoring for high-risk users, especially those with high privileges.
Deploying malicious OAuth application
Once the threat actor gained access to privileged users, their next step was to set up the malicious application. Based on analysis of the event user agent (Swagger-Codegen/1.4.0.0/csharp) and how quickly the deployment of the application was done, it is likely that the actor ran a PowerShell script to perform the following Azure Active Directory (AAD) management activities in all targeted tenants:
Register a new single–tenant application with the naming convention of [domain name]_([a-zA-Z]){3} (for example: Contoso_GhY)
Add the legacy permission Exchange.ManageAsApp which can be used for app-only authentication of Exchange Online PowerShell module
Grant admin consent to the above permission
Give global admin and Exchange Online admin roles to the previously registered application
The threat actor added their own credentials to the OAuth application, which enabled them to access the application even if the initially compromised global administrator changed their password.
The activities mentioned gave the threat actor control of a highly privileged application. It was observed that the threat actor did not always use the application right after it was deployed. In some cases, it took weeks or months before the application was utilized. Also, in organizations that didn’t monitor for suspicious applications, the applications were deployed for months and used multiple times by the threat actor.
CISA and the National Security Agency (NSA) have published a joint
cybersecurity advisory about control system defense for operational technology
(OT) and industrial control systems (ICSs). Control System
Defense: Know the Opponent is intended to provide critical infrastructure
owners and operators with an understanding of the tactics, techniques, and
procedures (TTPs) used by malicious cyber actors. This advisory builds on NSA
and CISA 2021 guidance provided to stop
malicious ICS activity against connect OT, and 2020 guidance to reduce
OT exposure.
CISA and NSA encourage critical infrastructure owners and operations to
review the advisory, [Control System Defense: Know the Opponent], and apply the
recommended mitigations and actions. For more information on CISA’s resources
and efforts to improve ICS cybersecurity, visit CISA’s role in industrial control systems webpage.
The new consumer profile reflects the next steps discussed in the summary report on
the work done on the IoT cybersecurity labelling criteria portion of the work
responding to Executive Order
14028. This profile builds on prior releases and the stakeholder
feedback they generated.
