Mar 25, 2024The Hacker NewsData Breach / Password Security

In January 2024, Microsoft discovered they’d been the victim of a hack orchestrated by Russian-state hackers Midnight Blizzard (sometimes known as Nobelium). The concerning detail about this case is how easy it was to breach the software giant. It wasn’t a highly technical hack that exploited a zero-day vulnerability – the hackers used a simple password spray attack to take control of an old, inactive account. This serves as a stark reminder of the importance of password security and why organizations need to protect every user account.

Password spraying: A simple yet effective attack

The hackers gained entry by using a password spray attack in November 2023, Password spraying is a relatively simple brute force technique that involves trying the same password against multiple accounts. By bombarding user accounts with known weak and compromised passwords, the attackers were able to gain access to a legacy non-production test account within the Microsoft system which provided them with an initial foothold in the environment. This account either had unusual privileges or the hackers escalated them.

The attack lasted for as long as seven weeks, during which the hackers exfiltrated emails and attached documents. This data compromised a ‘very small percentage’ of corporate email accounts, including those belonging to senior leadership and employees in the Cybersecurity and Legal teams. Microsoft’s Security team detected the hack on January 12th and took immediate action to disrupt the hackers’ activities and deny them further access.

However, the fact that the hackers were able to access such sensitive internal information highlights the potential damage that can be caused by compromising even seemingly insignificant accounts. All attackers need is an initial foothold within your organization.

The importance of protecting all accounts

While organizations often prioritize the protection of privileged accounts, the attack on Microsoft demonstrates that every user account is a potential entry point for attackers. Privilege escalation means that attackers can achieve their goals without necessarily needing a highly privileged admin account as an entry point.

Protecting an inactive low-privileged account is just as crucial as safeguarding a high-privileged admin account for several reasons. First, attackers often target these overlooked accounts as potential entry points into a network. Inactive accounts are more likely to have weak or outdated passwords, making them easier targets for brute force attacks. Once compromised, attackers can use these accounts to move laterally within the network, escalating their privileges and accessing sensitive information.

Second, inactive accounts are often neglected in terms of security measures, making them attractive targets for hackers. Organizations may overlook implementing strong password policies or multi-factor authentication for these accounts, leaving them vulnerable to exploitation. From an attacker’s perspective, even low-privileged accounts can provide valuable access to certain systems or data within an organization.

Defend against password spray attacks

The Microsoft hack serves as a wake-up call for organizations to prioritize the security of every user account. It highlights the critical need for robust password protection measures across all accounts, regardless of their perceived significance. By implementing strong password policies, enabling multi-factor authentication, conducting regular Active Directory audits, and continuously scanning for compromised passwords, organizations can significantly reduce the risk of being caught out in the same way.

1. Active Directory auditing: Conducting regular audits of Active Directory can provide visibility into unused and inactive accounts, as well as other password-related vulnerabilities. Audits provide a valuable snapshot of your Active Directory but should always be complemented by ongoing risk mitigation efforts. If you’re lacking visibility into your organization’s inactive and stale user accounts, consider running a read-only audit with our free auditing tool that gives an interactive exportable report: Specops Password Auditor.
2. Robust password policies: Organizations should enforce strong password policies that block weak passwords, such as common terms or keyboard walks like ‘qwerty’ or ‘123456.’ Implementing long, unique passwords or passphrases is a strong defense against brute-force attacks. Custom dictionaries that block terms related to the organization and industry should also be included.
3. Multi-factor authentication (MFA): Enabling MFA adds an authentication roadblock for hackers to overcome. MFA serves as an important layer of defense, although it’s worth remembering that MFA isn’t foolproof. It needs to be combined with strong password security.
4. Compromised password scans: Even strong passwords can become compromised if end users reuse them on personal devices, sites, or applications with weak security. Implementing tools to continuously scan your Active Directory for compromised passwords can help identify and mitigate potential risks.

Continuously shut down attack routes for hackers

The Microsoft hack underscores the need for organizations to implement robust password protection measures across all accounts. A secure password policy is essential, ensuring that all accounts, including legacy, non-production, and testing accounts, aren’t overlooked. Additionally, blocking known compromised credentials adds an extra layer of protection against active attacks.

Specops Password Policy with Breached Password Protection offers automated, ongoing protection for your Active Directory. It protects your end users against the use of more than 4 billion unique known compromised passwords, including data from both known leaks as well as our own honeypot system that collects passwords being used in real password spray attacks.

The daily update of the Breached Password Protection API, paired with continuous scans for the use of those passwords in your network, equals a much more comprehensive defense against the threat of password attack and the risk of password reuse. Speak to expert today to find out how Specops Password Policy could fit in with your organization.

Mar 15, 2024NewsroomData Privacy / Artificial Intelligence

Cybersecurity researchers have found that third-party plugins available for OpenAI ChatGPT could act as a new attack surface for threat actors looking to gain unauthorized access to sensitive data.

According to new research published by Salt Labs, security flaws found directly in ChatGPT and within the ecosystem could allow attackers to install malicious plugins without users’ consent and hijack accounts on third-party websites like GitHub.

ChatGPT plugins, as the name implies, are tools designed to run on top of the large language model (LLM) with the aim of accessing up-to-date information, running computations, or accessing third-party services.

OpenAI has since also introduced GPTs, which are bespoke versions of ChatGPT tailored for specific use cases, while reducing third-party service dependencies. As of March 19, 2024, ChatGPT users will no longer be able to install new plugins or create new conversations with existing plugins.

One of the flaws unearthed by Salt Labs involves exploiting the OAuth workflow to trick a user into installing an arbitrary plugin by taking advantage of the fact that ChatGPT doesn’t validate that the user indeed started the plugin installation.

This effectively could allow threat actors to intercept and exfiltrate all data shared by the victim, which may contain proprietary information.

The cybersecurity firm also unearthed issues with PluginLab that could be weaponized by threat actors to conduct zero-click account takeover attacks, allowing them to gain control of an organization’s account on third-party websites like GitHub and access their source code repositories.

“‘auth.pluginlab[.]ai/oauth/authorized’ does not authenticate the request, which means that the attacker can insert another memberId (aka the victim) and get a code that represents the victim,” security researcher Aviad Carmel explained. “With that code, he can use ChatGPT and access the GitHub of the victim.”

The memberId of the victim can be obtained by querying the endpoint “auth.pluginlab[.]ai/members/requestMagicEmailCode.” There is no evidence that any user data has been compromised using the flaw.

Also discovered in several plugins, including Kesem AI, is an OAuth redirection manipulation bug that could permit an attacker to steal the account credentials associated with the plugin itself by sending a specially crafted link to the victim.

The development comes weeks after Imperva detailed two cross-site scripting (XSS) vulnerabilities in ChatGPT that could be chained to seize control of any account.

In December 2023, security researcher Johann Rehberger demonstrated how malicious actors could create custom GPTs that can phish for user credentials and transmit the stolen data to an external server.

New Remote Keylogging Attack on AI Assistants

The findings also follow new research published this week about an LLM side-channel attack that employs token-length as a covert means to extract encrypted responses from AI Assistants over the web.

“LLMs generate and send responses as a series of tokens (akin to words), with each token transmitted from the server to the user as it is generated,” a group of academics from the Ben-Gurion University and Offensive AI Research Lab said.

“While this process is encrypted, the sequential token transmission exposes a new side-channel: the token-length side-channel. Despite encryption, the size of the packets can reveal the length of the tokens, potentially allowing attackers on the network to infer sensitive and confidential information shared in private AI assistant conversations.”

This is accomplished by means of a token inference attack that’s designed to decipher responses in encrypted traffic by training an LLM model capable of translating token-length sequences into their natural language sentential counterparts (i.e., plaintext).

In other words, the core idea is to intercept the real-time chat responses with an LLM provider, use the network packet headers to infer the length of each token, extract and parse text segments, and leverage the custom LLM to infer the response.

Two key prerequisites to pulling off the attack are an AI chat client running in streaming mode and an adversary who is capable of capturing network traffic between the client and the AI chatbot.

To counteract the effectiveness of the side-channel attack, it’s recommended that companies that develop AI assistants apply random padding to obscure the actual length of tokens, transmit tokens in larger groups rather than individually, and send complete responses at once, instead of in a token-by-token fashion.

“Balancing security with usability and performance presents a complex challenge that requires careful consideration,” the researchers concluded.

Feb 16, 2024NewsroomCybersecurity / Data Breach

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has revealed that an unnamed state government organization’s network environment was compromised via an administrator account belonging to a former employee.

“This allowed the threat actor to successfully authenticate to an internal virtual private network (VPN) access point,” the agency said in a joint advisory published Thursday alongside the Multi-State Information Sharing and Analysis Center (MS-ISAC).

“The threat actor connected to the [virtual machine] through the victim’s VPN with the intent to blend in with legitimate traffic to evade detection.”

It’s suspected that the threat actor obtained the credentials following a separate data breach owing to the fact that the credentials appeared in publicly available channels containing leaked account information.

The admin account, which had access to a virtualized SharePoint server, also enabled the attackers to access another set of credentials stored in the server, which had administrative privileges to both the on-premises network and the Azure Active Directory (now called Microsoft Entra ID).

This further made it possible to explore the victim’s on-premises environment, and execute various lightweight directory access protocol (LDAP) queries against a domain controller. The attackers behind the malicious activity are presently unknown.

A deeper investigation into the incident has revealed no evidence that the adversary moved laterally from the on-premises environment to the Azure cloud infrastructure.

The attackers ultimately accessed host and user information and posted the information on the dark web for likely financial gain, the bulletin noted, prompting the organization to reset passwords for all users, disable the administrator account as well as remove the elevated privileges for the second account.

It’s worth pointing out that neither of the two accounts had multi-factor authentication (MFA) enabled, underscoring the need for securing privileged accounts that grant access to critical systems. It’s also recommended to implement the principle of least privilege and create separate administrator accounts to segment access to on-premises and cloud environments.

The development is a sign that threat actors leverage valid accounts, including those belonging to former employees that have not been properly removed from the Active Directory (AD), to gain unauthorized access to organizations.

“Unnecessary accounts, software, and services in the network create additional vectors for a threat actor to compromise,” the agencies said.

“By default, in Azure AD all users can register and manage all aspects of applications they create. These default settings can enable a threat actor to access sensitive information and move laterally in the network. In addition, users who create an Azure AD automatically become the Global Administrator for that tenant. This could allow a threat actor to escalate privileges to execute malicious actions.”

Feb 03, 2024NewsroomVulnerability / Social Media

The decentralized social network Mastodon has disclosed a critical security flaw that enables malicious actors to impersonate and take over any account.

“Due to insufficient origin validation in all Mastodon, attackers can impersonate and take over any remote account,” the maintainers said in a terse advisory.

The vulnerability, tracked as CVE-2024-23832, has a severity rating of 9.4 out of a maximum of 10. Security researcher arcanicanis has been credited with discovering and reporting it.

It has been described as an “origin validation error” (CWE-346), which can typically allow an attacker to “access any functionality that is inadvertently accessible to the source.”

Every Mastodon version prior to 3.5.17 is vulnerable, as are 4.0.x versions before 4.0.13, 4.1.x versions before 4.1.13, and 4.2.x versions before 4.2.5.

Mastodon said it’s withholding additional technical specifics about the flaw until February 15, 2024, to give admins ample time to update the server instances and prevent the likelihood of exploitation.

“Any amount of detail would make it very easy to come up with an exploit,” it said.

The federated nature of the platform means that it runs on separate servers (aka instances), independently hosted and operated by respective administrators who create their own rules and regulations that are enforced locally.

This also means that not only each instance has a unique code of conduct, terms of service, privacy policy, and content moderation guidelines, but it also requires each administrator to apply security updates in a timely fashion to secure the instances against potential risks.

The disclosure arrives nearly seven months after Mastodon addressed two other critical flaws (CVE-2023-36460 and 2023-36459) that could have been weaponized by adversaries to cause denial-of-service (DoS) or achieve remote code execution.

Jan 24, 2024NewsroomCloud Security / Kubernetes

Cybersecurity researchers have discovered a loophole impacting Google Kubernetes Engine (GKE) that could be potentially exploited by threat actors with a Google account to take control of a Kubernetes cluster.

The critical shortcoming has been codenamed Sys:All by cloud security firm Orca. As many as 250,000 active GKE clusters in the wild are estimated to be susceptible to the attack vector.

In a report shared with The Hacker News, security researcher Ofir Yakobi said it “stems from a likely widespread misconception that the system:authenticated group in Google Kubernetes Engine includes only verified and deterministic identities, whereas in fact, it includes any Google authenticated account (even outside the organization).”

The system:authenticated group is a special group that includes all authenticated entities, counting human users and service accounts. As a result, this could have serious consequences when administrators inadvertently bestow it with overly permissive roles.

Specifically, an external threat actor in possession of a Google account could misuse this misconfiguration by using their own Google OAuth 2.0 bearer token to seize control of the cluster for follow-on exploitation such as lateral movement, cryptomining, denial-of-service, and sensitive data theft.

To make matters worse, this approach does not leave a trail in a manner that can be linked back to the actual Gmail or Google Workspace account that obtained the OAuth bearer token.

Sys:All has been found to impact numerous organizations, leading to the exposure of various sensitive data, such as JWT tokens, GCP API keys, AWS keys, Google OAuth credentials, private keys, and credentials to container registries, the last of which could then be used to trojanize container images.

Following responsible disclosure to Google, the company has taken steps to block the binding of the system:authenticated group to the cluster-admin role in GKE versions 1.28 and later.

“To help secure your clusters against mass malware attacks that exploit cluster-admin access misconfigurations, GKE clusters running version 1.28 and later won’t allow you to bind the cluster-admin ClusterRole to the system:anonymous user or to the system:unauthenticated or system:authenticated groups,” Google now notes in its documentation.

Google is also recommending users to not bind the system:authenticated group to any RBAC roles, as well as assess whether the clusters have been bound to the group using both ClusterRoleBindings and RoleBindings and remove unsafe bindings.

Orca has also warned that while there is no public record of a large-scale attack utilizing this method, it could be only a matter of time, necessitating that users take appropriate steps to secure their cluster access controls.

“Even though this is an improvement, it is important to note that this still leaves many other roles and permissions that can be assigned to the group,” the company said.

Jan 11, 2024NewsroomOnline Security / Cryptocurrency

The compromise of Mandiant’s X (formerly Twitter) account last week was likely the result of a “brute-force password attack,” attributing the hack to a drainer-as-a-service (DaaS) group.

“Normally, [two-factor authentication] would have mitigated this, but due to some team transitions and a change in X’s 2FA policy, we were not adequately protected,” the threat intelligence firm said in a post shared on X.

The attack, which took place on January 3, 2023, enabled the threat actor to take control of the company’s X account and distribute links to a phishing page hosting a cryptocurrency drainer tracked as CLINKSINK.

Drainers refer to malicious scripts and smart contracts that facilitate the theft of digital assets from the victim’s wallets after they are tricked into approving the transactions.

According to the Google-owned subsidiary, multiple threat actors are believed to have leveraged CLINKSINK since December 2023 to siphon funds and tokens from Solana (SOL) cryptocurrency users.

As observed in the case of other drainers like Angel Drainer and Inferno Drainer, affiliates are roped in by the DaaS operators to conduct the attacks in exchange for a cut (typically 20%) of the stolen assets.

The identified activity cluster involves at least 35 affiliate IDs and 42 unique Solana wallet addresses, collectively netting the actors no less than $900,000 in illegal profits.

The attack chains involve the use of social media and chat applications such as X and Discord to distribute cryptocurrency-themed phishing pages that encourage the targets to connect their wallets to claim a bogus token airdrop.

“After connecting their wallet, the victim is then prompted to sign a transaction to the drainer service, which allows it to siphon funds from the victim,” security researchers Zach Riddle, Joe Dobson, Lukasz Lamparski, and Stephen Eckels said.

CLINKSINK, a JavaScript drainer, is designed to open a pathway to the targeted wallets, check the current balance on the wallet, and ultimately pull off the theft after asking the victim to sign a fraudulent transaction. This also means that the attempted theft will not succeed if the victim rejects the transaction.

The drainer has also spawned several variants, including Chick Drainer (or Rainbow Drainer), raising the possibility that the source code is available to multiple threat actors, allowing them to mount independent draining campaigns.

“The wide availability and low cost of many drainers, combined with a relatively high potential for profit, likely makes them attractive operations for many financially motivated actors,” Mandiant said.

“Given the increase in cryptocurrency values and the low barrier to entry for draining operations, we anticipate that financially motivated threat actors of varying levels of sophistication will continue to conduct drainer operations for the foreseeable future.”

The development comes amid an uptick in attacks targeting legitimate X accounts to spread cryptocurrency scams.

Earlier this week, the X account associated with the U.S. Securities and Exchange Commission (SEC) was breached to falsely claim that the regulatory body had approved the “listing and trading of spot bitcoin exchange-traded products,” causing bitcoin prices to spike briefly.

X has since revealed the hack was the result of “an unidentified individual obtaining control over a phone number associated with the @SECGov account through a third-party,” and that the account did not have two-factor authentication enabled.

Jan 05, 2024NewsroomNetwork Security / Malware

Mobile network operator Orange Spain suffered an internet outage for several hours on January 3 after a threat actor used administrator credentials captured by means of stealer malware to hijack the border gateway protocol (BGP) traffic.

“The Orange account in the IP network coordination center (RIPE) has suffered improper access that has affected the browsing of some of our customers,” the company said in a message posted on X (formerly Twitter).

However, the company emphasized no personal data was compromised and that the incident only affected some browsing services.

The threat actor, who goes by the name Ms_Snow_OwO on X, claimed to have gained access to Orange Spain’s RIPE account. RIPE is a regional Internet registry (RIR) that oversees the allocation and registration of IP addresses and autonomous system (AS) numbers in Europe, Central Asia, Russia, and West Asia.

“Using the stolen account, the threat actor modified the AS number belonging to Orange’s IP address, resulting in major disruptions to Orange and a 50% loss in traffic,” cybersecurity firm Hudson Rock said.

Further analysis has revealed that the email address of the admin account is associated with the computer of an Orange Spain employee who was infiltrated by Raccoon Stealer malware on September 4, 2023.

It’s currently not known how the stealer found its way to the employee’s system, but such malware families are typically propagated via malvertising or phishing scams.

“Among the corporate credentials identified on the machine, the employee had specific credentials to ‘https://access.ripe.net’ using the email address which was revealed by the threat actor (adminripe-ipnt@orange.es),” the company added.

Even worse, the password used to secure Orange’s RIPE administrator account was “ripeadmin,” which is both weak and easily predictable.

Security researcher Kevin Beaumont further noted that RIPE neither mandates two-factor authentication (2FA) nor enforces a strong password policy for its accounts, making it ripe for abuse.

“Currently, infostealer marketplaces are selling thousands of credentials to access.ripe.net — effectively allowing you to repeat this at organizations and ISPs across Europe,” Beaumont said.

RIPE, which is currently investigating to see if any other accounts have been affected in a similar manner, said it will directly reach out to affected account holders. It has also urged RIPE NCC Access account users to update their passwords and enable multi-factor authentication for their accounts.

“In the long term, we’re expediting the 2FA implementation to make it mandatory for all RIPE NCC Access accounts as soon as possible and to introduce a variety of verification mechanisms,” it added.

The incident serves to highlight the consequences of infostealer infections, necessitating that organizations take steps to secure their networks from known initial attack vectors.

Jan 04, 2024NewsroomCryptocurrency / Social Media

American cybersecurity firm and Google Cloud subsidiary Mandiant had its X (formerly Twitter) account compromised for more than six hours by an unknown attacker to propagate a cryptocurrency scam.

As of writing, the account has been restored on the social media platform.

It’s currently not clear how the account was breached. But the hacked Mandiant account was initially renamed to “@phantomsolw” to impersonate the Phantom crypto wallet service, according to MalwareHunterTeam and vx-underground.

Specifically, the scam posts from the account advertised an airdrop scam that urged users to click on a bogus link and earn free tokens, with follow-up messages asking Mandiant to “change password please” and “check bookmarks when you get account back.”

Mandiant, a leading threat intelligence firm, was acquired by Google in March 2022 for $5.4 billion. It is now part of Google Cloud.

“The Mandiant Twitter account takeover could have happened [in] a number of ways,” Rachel Tobac, CEO of SocialProof Security, said on X.

“Some folks are giving the advice to turn on MFA to prevent ATO and of course that is a good idea always *but it’s also possible that someone in Support at Twitter was bribed or compromised which allowed the attacker access to Mandiant’s account*.”

The Hacker News has reached out to Mandiant for further comments, and we will update the story once we hear back.