[…] Recently, the Microsoft Detection and Response Team (DART) has seen an increase in attackers utilizing token theft for this purpose. By compromising and replaying a token issued to an identity that has already completed multifactor authentication, the threat actor satisfies the validation of MFA and access is granted to organizational resources accordingly. This poses to be a concerning tactic for defenders because the expertise needed to compromise a token is very low, is hard to detect, and few organizations have token theft mitigations in their incident response plan.

[…]

Tokens are at the center of OAuth 2.0 identity platforms, such as Azure Active Directory (Azure AD). To access a resource (for example, a web application protected by Azure AD), a user must present a valid token. To obtain that token, the user must sign into Azure AD using their credentials. At that point, depending on policy, they may be required to complete MFA. The user then presents that token to the web application, which validates the token and allows the user access.

When Azure AD issues a token, it contains information (claims) such as the username, source IP address, MFA, and more. It also includes any privilege a user has in Azure AD. If you sign in as a Global Administrator to your Azure AD tenant, then the token will reflect that. Two of the most common token theft techniques DART has observed have been through adversary-in-the-middle (AitM) frameworks or the utilization of commodity malware (which enables a ‘pass-the-cookie’ scenario).

[…]

When the user is phished, the malicious infrastructure captures both the credentials of the user, and the token.

If a regular user is phished and their token stolen, the attacker may attempt business email compromise (BEC) for financial gain.

[…]

A “pass-the-cookie” attack is a type of attack where an attacker can bypass authentication controls by compromising browser cookies.

[…]

Commodity credential theft malware like Emotet, Redline, IcedID, and more all have built-in functionality to extract and exfiltrate browser cookies. Additionally, the attacker does not have to know the compromised account password or even the email address for this to work— those details are held within the cookie.

[…]

Recommendations

Protect

Organizations can take a significant step toward reducing the risk of token theft by ensuring that they have full visibility of where and how their users are authenticating. To access critical applications like Exchange Online or SharePoint, the device used should be known by the organization. Utilizing compliance tools like Intune in combination with device based conditional access policies can help to keep devices up to date with patches, antivirus definitions, and EDR solutions. Allowing only known devices that adhere to Microsoft’s recommended security baselines helps mitigate the risk of commodity credential theft malware being able to compromise end user devices.

For those devices that remain unmanaged, consider utilizing session conditional access policies and other compensating controls to reduce the impact of token theft:

• Reducing the lifetime of the session increases the number of times a user is forced to re-authenticate but minimizes the length of time session token is viable.
• Reducing the viable time of a token forces threat actors to increase the frequency of token theft attempts which in turn provides defenders with additional chances at detection.
• Implement Conditional Access App Control in Microsoft Defender for Cloud Apps for users connecting from unmanaged devices.

Protect your users by blocking initial access:

• Plan and implement phishing resistant MFA solutions such as FIDO2 security keys, Windows Hello for Business, or certificate-based authentication for users.
  • While this may not be practical for all users, it should be considered for users of significant privilege like Global Admins or users of high-risk applications.
• Users that hold a high level of privilege in the tenant should have a segregated cloud-only identity for all administrative activities, to reduce the attack surface from on-premises to cloud in the event of on-premises domain compromise and abuse of privilege. These identities should also not have a mailbox attached to them to prevent the likelihood of privileged account compromise via phishing techniques.

[…]

In instances of token theft, adversaries insert themselves in the middle of the trust chain and often subsequently circumvent security controls. Having visibility, alerting, insights, and a full understanding of where security controls are enforced is key. Treating both identity providers that generate access tokens and their associated privileged identities as critical assets is strongly encouraged.

[…]

Source: Token tactics: How to prevent, detect, and respond to cloud token theft – Microsoft Security Blog

[…] If an attacker inserts their own SIM into a target’s Android, then enters the wrong SIM PIN three times, they can enter their SIM’s PUK to be able to create a new SIM PIN. Once they do, they bypass the lock screen entirely and access the phone. You can watch the hypothetical attack play out in the video below:

Pixel 6 Full Lockscreen Bypass POC

Schütz brought this flaw to Google’s attention back in June of this year, but it took the company five months to finally push a patch.[…]

Source: Fix the Android Security Flaw That Lets Anyone Unlock Your Phone

Today we are excited to release Shufflecake, a tool aimed at helping people whose freedom of expression is threatened by repressive authorities or dangerous criminal organizations, in particular: whistleblowers, investigative journalists, and activists for human rights in oppressive regimes. Shufflecake is FLOSS (Free/Libre, Open Source Software). Source code in C is available and released under the GNU General Public License v3.0 or superior.

[…]

Shufflecake is a tool for Linux that allows creation of multiple hidden volumes on a storage device in such a way that it is very difficult, even under forensic inspection, to prove the existence of such volumes. Each volume is encrypted with a different secret key, scrambled across the empty space of an underlying existing storage medium, and indistinguishable from random noise when not decrypted. Even if the presence of the Shufflecake software itself cannot be hidden – and hence the presence of secret volumes is suspected – the number of volumes is also hidden. This allows a user to create a hierarchy of plausible deniability, where “most hidden” secret volumes are buried under “less hidden” decoy volumes, whose passwords can be surrendered under pressure. In other words, a user can plausibly “lie” to a coercive adversary about the existence of hidden data, by providing a password that unlocks “decoy” data. Every volume can be managed independently as a virtual block device, i.e. partitioned, formatted with any filesystem of choice, and mounted and dismounted like a normal disc. The whole system is very fast, with only a minor slowdown in I/O throughput compared to a bare LUKS-encrypted disk, and with negligible waste of memory and disc space.

You can consider Shufflecake a “spiritual successor” of tools such as Truecrypt and Veracrypt, but vastly improved. First of all, it works natively on Linux, it supports any filesystem of choice, and can manage up to 15 nested volumes per device, so to make deniability of the existence of these partitions really plausible.

[…]

Source: Introducing Shufflecake: plausible deniability for multiple hidden filesystems on Linux – Kudelski Security Research

More than two dozen Lenovo notebook models are vulnerable to malicious hacks that disable the UEFI secure-boot process and then run unsigned UEFI apps or load bootloaders that permanently backdoor a device, researchers warned on Wednesday.

At the same time that researchers from security firm ESET disclosed the vulnerabilities, the notebook maker released security updates for 25 models, including ThinkPads, Yoga Slims, and IdeaPads. Vulnerabilities that undermine the UEFI secure boot can be serious because they make it possible for attackers to install malicious firmware that survives multiple operating system reinstallations.

[…]

Short for Unified Extensible Firmware Interface, UEFI is the software that bridges a computer’s device firmware with its operating system. As the first piece of code to run when virtually any modern machine is turned on, it’s the first link in the security chain. Because the UEFI resides in a flash chip on the motherboard, infections are difficult to detect and remove. Typical measures such as wiping the hard drive and reinstalling the OS have no meaningful impact because the UEFI infection will simply reinfect the computer afterward.

[…]

Disabling the UEFI Secure Boot frees attackers to execute malicious UEFI apps, something that’s normally not possible because secure boot requires UEFI apps to be cryptographically signed. Restoring the factory-default DBX, meanwhile, allows attackers to load vulnerable bootloaders. In August, researchers from security firm Eclypsium identified three prominent software drivers that could be used to bypass secure boot when an attacker has elevated privileges, meaning administrator on Windows or root on Linux.

The vulnerabilities can be exploited by tampering with variables in NVRAM, the non-volatile RAM that stores various boot options. The vulnerabilities are the result of Lenovo mistakenly shipping Notebooks with drivers that had been intended for use only during the manufacturing process. The vulnerabilities are:

• CVE-2022-3430: A potential vulnerability in the WMI Setup driver on some consumer Lenovo Notebook devices may allow an attacker with elevated privileges to modify secure boot settings by changing an NVRAM variable.
• CVE-2022-3431: A potential vulnerability in a driver used during the manufacturing process on some consumer Lenovo Notebook devices that was mistakenly not deactivated may allow an attacker with elevated privileges to modify the secure boot setting by altering an NVRAM variable.
• CVE-2022-3432: A potential vulnerability in a driver used during the manufacturing process on the Ideapad Y700-14ISK that was mistakenly not deactivated may allow an attacker with elevated privileges to modify the secure boot setting by adjusting an NVRAM variable.

Lenovo is patching only the first two. CVE-2022-3432 will not be patched because the company no longer supports the Ideapad Y700-14ISK, the end-of-life notebook model that’s affected. People using any of the other vulnerable models should install patches as soon as practical.

Source: Lenovo driver goof poses security risk for users of 25 notebook models | Ars Technica