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.
As a part of the periodic review of NIST’s cryptographic standards
and guidelines, NIST’s Crypto Publication Review Board announced
the review of FIPS 198-1 The
Keyed-Hash Message Authentication Code (HMAC) in August
2021. In response, NIST received public comments.
NIST proposes to convert FIPS 198-1 to a NIST Special Publication
(SP), and apply the following changes:
Update the HMAC specification
to include block sizes for the SHA-3 family of hash functions
Include a discussion on
truncation
Improve the editorial quality
and update references
Conversion to an SP: NIST typically specifies
fundamental cryptographic primitives—block ciphers, digital signatures
algorithms, and hash functions—as FIPS publications, whereas other
cryptographic schemes—modes of operation, message authentication codes,
etc.—are published as a part of the NIST SP 800 series. (For more information,
see Section 3 of NISTIR 7977.)
To be consistent with that approach, NIST proposes to convert FIPS 198-1 to an
SP.
In particular, NIST proposes to develop a draft SP for the HMAC
specification, updated as described above, which would be released for public
comment. When the SP is finalized and published, FIPS 198-1 would be withdrawn
simultaneously.
Send comments on the decision proposal by October 20, 2022 to cryptopubreviewboard@nist.gov
with “Comments on FIPS 198-1 decision proposal” in the subject
line.
Comments received in response to this request will be posted on the Crypto
Publication Review Project site after the due date. Submitters’
names and affiliations (when provided) will be included, while contact
information will be removed. See the project site for additional information
about the review process.
The NIST SP 800-90 series supports the generation of high-quality
random bits for cryptographic and non-cryptographic use. The security of a
random number generator depends on the unpredictability of its outputs, which
can be measured in terms of entropy. The NIST SP 800-90 series uses min-entropy
to measure entropy. A full-entropy bitstring has an amount of entropy equal to
its length. Full-entropy bitstrings are important for cryptographic
applications, as these bitstrings have ideal randomness properties and may be
used for any cryptographic purpose. Due to the difficulty of generating and
testing full-entropy bitstrings, the SP 800-90 series assumes that a bitstring
has full entropy if the amount of entropy per bit is at least 1 – ε, where ε is
at most 2-32. NIST IR 8427 provides a justification for the
selection of ε.
The public comment period for NIST IR 8427 is open through October
31, 2022. See the publication
details for a copy of the draft and instructions for submitting
comments.
The Post-Quantum Cryptography (PQC) standardization process is
continuing into a fourth round with the following key-encapsulation mechanisms
(KEMs) still under consideration: BIKE, Classic McEliece, HQC, and SIKE.
However, there are no remaining digital signature candidates under
consideration. As such, NIST
is requesting additional digital signature proposals to be considered in the
PQC standardization process.
NIST is primarily interested in additional general-purpose
signature schemes that are not based on structured lattices. For certain
applications, such as certificate transparency, NIST may also be interested in
signature schemes that have short signatures and fast verification. NIST is
open to receiving additional submissions based on structured lattices but is
intent on diversifying the post-quantum signature standards. As such, any
structured lattice-based signature proposal needs to significantly outperform
CRYSTALS-Dilithium and FALCON in relevant applications and ensure substantial
security properties in order to be considered for standardization.
Complete instructions on how to submit a candidate package,
including the minimal acceptability requirements, are posted on the PQC: Digital Signature Schemes project page.
The finalized evaluation criteria that will be used to assess the submissions
are also posted at the same website. Submission
packages must be received by NIST by June 1, 2023.
