Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label Google Cloud. Show all posts
JavaScript
API Keys Cyber Attacks Gemini CyberCrime Data Exposure Google Cloud JavaScript

Publicly Exposed Google Cloud API Keys Gain Unintended Access to Gemini Services

 










A recent security analysis has revealed that thousands of Google Cloud API keys available on the public internet could be misused to interact with Google’s Gemini artificial intelligence platform, creating both data exposure and financial risks.

Google Cloud API keys, often recognizable by the prefix “AIza,” are typically used to connect websites and applications to Google services and to track usage for billing. They are not meant to function as high-level authentication credentials. However, researchers from Truffle Security discovered that these keys can be leveraged to access Gemini-related endpoints once the Generative Language API is enabled within a Google Cloud project.

During their investigation, the firm identified nearly 3,000 active API keys embedded directly in publicly accessible client-side code, including JavaScript used to power website features such as maps and other Google integrations. According to security researcher Joe Leon, possession of a valid key may allow an attacker to retrieve stored files, read cached content, and generate large volumes of AI-driven requests that would be billed to the project owner. He further noted that these keys can now authenticate to Gemini services, even though they were not originally designed for that purpose.

The root of the problem lies in how permissions are applied when the Gemini API is activated. If a project owner enables the Generative Language API, all existing API keys tied to that project may automatically inherit access to Gemini endpoints. This includes keys that were previously embedded in publicly visible website code. Critically, there is no automatic alert notifying users that older keys have gained expanded capabilities.

As a result, attackers who routinely scan websites for exposed credentials could capture these keys and use them to access endpoints such as file storage or cached content interfaces. They could also submit repeated Gemini API requests, potentially generating substantial usage charges for victims through quota abuse.

The researchers also observed that when developers create a new API key within Google Cloud, the default configuration is set to “Unrestricted.” This means the key can interact with every enabled API within the same project, including Gemini, unless specific limitations are manually applied. In total, Truffle Security reported identifying 2,863 active keys accessible online, including one associated with a Google-related website.

Separately, Quokka published findings from a large-scale scan of 250,000 Android applications, uncovering more than 35,000 unique Google API keys embedded in mobile software. The company warned that beyond financial abuse through automated AI requests, organizations must consider broader implications. AI-enabled endpoints can interact with prompts, generated outputs, and integrated cloud services in ways that amplify the consequences of a compromised key.

Even in cases where direct customer records are not exposed, the combination of AI inference access, consumption of service quotas, and potential connectivity to other Google Cloud resources creates a substantially different risk profile than developers may have anticipated when treating API keys as simple billing identifiers.

Although the behavior was initially described as functioning as designed, Google later confirmed it had collaborated with researchers to mitigate the issue. A company spokesperson stated that measures have been implemented to detect and block leaked API keys attempting to access Gemini services. There is currently no confirmed evidence that the weakness has been exploited at scale. However, a recent online post described an incident in which a reportedly stolen API key generated over $82,000 in charges within a two-day period, compared to the account’s typical monthly expenditure of approximately $180.

The situation remains under review, and further updates are expected if additional details surface.

Security experts recommend that Google Cloud users audit their projects to determine whether AI-related APIs are enabled. If such services are active and associated API keys are publicly accessible through website code or open repositories, those keys should be rotated immediately. Researchers advise prioritizing older keys, as they are more likely to have been deployed publicly under earlier guidance suggesting limited risk.

Industry analysts emphasize that API security must be continuous. Changes in how APIs operate or what data they can access may not constitute traditional software vulnerabilities, yet they can materially increase exposure. As artificial intelligence becomes more tightly integrated with cloud services, organizations must move beyond periodic testing and instead monitor behavior, detect anomalies, and actively block suspicious activity to reduce evolving risk.

Read more »
Privacy
Amazon Cloud Data cloud data security Data Privacy data sovereignty Google Cloud Microsoft Privacy

CLOUD Act Extends US Jurisdiction Over Global Cloud Data Across Microsoft, Google, and Amazon

 

That Frankfurt data center storing your business files or the Singapore server holding your personal photos may not be as secure from U.S. oversight as you think. If the provider is Microsoft, Amazon, Google, or another U.S.-based tech giant, physical geography does little to shield information once American authorities seek access. The Clarifying Lawful Overseas Use of Data (CLOUD) Act, enacted in March 2018, gives U.S. law enforcement broad authority to demand data from American companies no matter where that information is located. Many organizations and individuals who once assumed that hosting data in Europe or Asia provided protection from U.S. jurisdiction now face an overlooked vulnerability.  

The law applies to every major cloud provider headquartered in the United States, including Microsoft, Amazon, Google, Apple, Meta, and Salesforce. This means data hosted in Microsoft’s European facilities, Google’s Asian networks, or Amazon’s servers in regions worldwide can be accessed through proper legal orders. An organization running Office 365 in London or an individual storing iCloud photos in Berlin could have their data obtained by U.S. investigators with little visibility into the process. Even companies promoting themselves as “foreign hosted” may not be immune if they have American subsidiaries or offices. Jurisdiction extends to entities connected to the United States, meaning that promises of sovereignty can be undercut by corporate structure. 

The framework obligates companies to comply quickly with data requests, leaving limited room for delay. Providers may challenge orders if they conflict with local privacy protections, but the proceedings typically occur without the knowledge of the customer whose data is involved. As a result, users may never know their information has been disclosed, since notification is not required. This dynamic has raised significant concerns about transparency, privacy, and the balance of international legal obligations. 

There are alternatives for those seeking stronger guarantees of independence. Providers such as Hetzner in Germany, OVHcloud in France, and Proton in Switzerland operate strictly under European laws and maintain distance from U.S. corporate ties. These companies cannot be compelled to share data with American authorities unless they enter into agreements that extend jurisdiction. However, relying on such providers can involve trade-offs, such as limited integration with mainstream platforms or reduced global reach. Some U.S. firms have responded by offering “sovereign cloud regions” managed locally, but questions remain about whether ultimate control still rests with the parent corporation and therefore remains vulnerable to U.S. legal demands. 

The implications are clear: the choice of cloud provider is not only a technical or financial decision but a geopolitical one. In a world where information represents both power and liability, each upload is effectively a decision about which country’s laws govern your digital life. For businesses and individuals alike, data location may matter less than corporate origin, and the CLOUD Act ensures that U.S. jurisdiction extends far beyond its borders.
Read more »
Quantum- safe Encryption
Cloud cloud service providers Cyber Security Digital Signatures Google Google Cloud PQC Quantum threats Quantum- safe Encryption

Google Cloud Introduces Quantum-Safe Digital Signatures

 

As quantum computing advances, Google Cloud is taking a significant step toward securing its platform against future threats. The company has announced the introduction of quantum-safe digital signatures in its Cloud Key Management Service (KMS), currently available in preview. 

This move is part of a broader initiative to prepare for the potential risks that quantum computers pose to modern encryption systems. While fully capable quantum computers are not expected to be widely available for at least a decade, they could one day break most of today’s encryption methods in a matter of hours. This looming possibility has led to concerns over a harvest-now-decrypt-later strategy employed by cybercriminals. 

In this method, attackers steal encrypted data today, intending to decrypt it once quantum computing becomes powerful enough. To counter this risk, researchers are developing post-quantum cryptography (PQC)—encryption techniques specifically designed to withstand quantum attacks. One major security risk posed by quantum computing is the potential forgery and manipulation of digital signatures. 

Digital signatures authenticate documents and communications, ensuring they have not been tampered with. If compromised, they could allow attackers to impersonate legitimate users, forge transactions, or spread malware under trusted identities. Google Cloud recognizes the importance of addressing these concerns early and has introduced quantum-resistant digital signatures to build a more secure infrastructure. 

This initiative also aims to set an industry precedent for other cloud service providers. As part of its commitment to transparency and security, Google Cloud has announced that its quantum-related cryptographic implementations will be included in its open-source cryptographic libraries, BoringCrypto and Tink. This allows security researchers and developers to review, audit, and contribute to these implementations, ensuring their robustness against potential threats. 

The new quantum-safe digital signatures in Cloud KMS specifically implement ML-DSA-65 and SLH-DSA-SHA2-128S, two PQC algorithms that adhere to NIST (National Institute of Standards and Technology) standards. Google Cloud has also confirmed plans to integrate additional PQC algorithms into its Hardware Security Modules (HSMs), which are specialized devices designed to provide extra layers of cryptographic security.  

By rolling out these quantum-resistant digital signatures, Google Cloud is giving customers the opportunity to test PQC algorithms in Cloud KMS and provide feedback on their performance and integration. This allows businesses to prepare for a post-quantum future, ensuring their data remains secure even as computing power evolves. 

Google Cloud sees this initiative as a crucial first step toward a fully quantum-resistant cloud ecosystem, demonstrating its dedication to staying ahead of emerging cybersecurity challenges.
Read more »
Privacy
API AT&T Credentials Google Cloud Privacy

Weak Cloud Credentials Behind Most Cyber Attacks: Google Cloud Report

 



A recent Google Cloud report has found a very troubling trend: nearly half of all cloud-related attacks in late 2024 were caused by weak or missing account credentials. This is seriously endangering businesses and giving attackers easy access to sensitive systems.


What the Report Found

The Threat Horizons Report, which was produced by Google's security experts, looked into cyberattacks on cloud accounts. The study found that the primary method of access was poor credential management, such as weak passwords or lack of multi-factor authentication (MFA). These weak spots comprised nearly 50% of all incidents Google Cloud analyzed.

Another factor was screwed up cloud services, which constituted more than a third of all attacks. The report further noted a frightening trend of attacks on the application programming interfaces (APIs) and even user interfaces, which were around 20% of the incidents. There is a need to point out several areas where cloud security seems to be left wanting.


How Weak Credentials Cause Big Problems

Weak credentials do not just unlock the doors for the attackers; it lets them bring widespread destruction. For instance, in April 2024, over 160 Snowflake accounts were breached due to the poor practices regarding passwords. Some of the high-profile companies impacted included AT&T, Advance Auto Parts, and Pure Storage and involved some massive data leakages.

Attackers are also finding accounts with lots of permissions — overprivileged service accounts. These simply make it even easier for hackers to step further into a network, bringing harm to often multiple systems within an organization's network. Google concluded that more than 60 percent of all later attacker actions, once inside, involve attempts to step laterally within systems.

The report warns that a single stolen password can trigger a chain reaction. Hackers can use it to take control of apps, access critical data, and even bypass security systems like MFA. This allows them to establish trust and carry out more sophisticated attacks, such as tricking employees with fake messages.


How Businesses Can Stay Safe

To prevent such attacks, organizations should focus on proper security practices. Google Cloud suggests using multi-factor authentication, limiting excessive permissions, and fixing misconfigurations in cloud systems. These steps will limit the damage caused by stolen credentials and prevent attackers from digging deeper.

This report is a reminder that weak passwords and poor security habits are not just small mistakes; they can lead to serious consequences for businesses everywhere.


Read more »
Technology
Cloud Security Cryptojacking Cybersecurity Threats Google Cloud MFA Raccoon Stealer Ransomware Technology

TRIPLESTRENGTH Targets Cloud for Cryptojacking, On-Premises Systems for Ransomware Attacks

 

Google unveiled a financially driven threat actor, TRIPLESTRENGTH, targeting cloud environments for cryptojacking and on-premise ransomware operations.

"This actor engaged in a variety of threat activity, including cryptocurrency mining operations on hijacked cloud resources and ransomware activity," Google Cloud noted in its 11th Threat Horizons Report.

TRIPLESTRENGTH employs a three-pronged attack strategy: unauthorized cryptocurrency mining, ransomware deployment, and offering cloud platform access—spanning services like Google Cloud, AWS, Azure, Linode, OVHCloud, and Digital Ocean—to other attackers. The group's primary entry methods involve stolen credentials and cookies, often sourced from Raccoon Stealer logs. Compromised environments are used to create compute resources for mining cryptocurrency using tools like the unMiner application and the unMineable mining pool, optimized for both CPU and GPU algorithms.

Interestingly, TRIPLESTRENGTH has concentrated its ransomware efforts on on-premises systems, deploying lockers such as Phobos, RCRU64, and LokiLocker.

"In Telegram channels focused on hacking, actors linked to TRIPLESTRENGTH have posted advertisements for RCRU64 ransomware-as-a-service and also solicited partners to collaborate in ransomware and blackmail operations," Google Cloud disclosed.

One notable incident in May 2024 involved initial access through Remote Desktop Protocol (RDP), followed by lateral movement and antivirus evasion to execute ransomware across several systems. TRIPLESTRENGTH also regularly advertises access to compromised servers on Telegram, targeting hosting providers and cloud platforms.

To counteract such threats, Google has introduced multi-factor authentication (MFA) and improved logging for detecting sensitive billing actions.

"A single stolen credential can initiate a chain reaction, granting attackers access to applications and data, both on-premises and in the cloud," Google warned. 

"This access can be further exploited to compromise infrastructure through remote access services, manipulate MFA, and establish a trusted presence for subsequent social engineering attacks."
Read more »
Technology
Cloud Cloud Data Google Google Cloud Location data Technology

User Tracking: Google to Store User Data for 180 Days

User Tracking: Google Announces to Store User Data for 180 Days

Google has made a major change in its user tracking, a big leap in privacy concerns for users. Google will stop the nosy cloud storage of data it gets from tracking user location in real time. 

The privacy change

Called Google Maps Timeline, from December, Google will save user location data for a maximum of 180 days. After the duration ends, the data will be erased from Google Cloud servers. 

The new policy means Google can only save a user’s movements and whereabouts for 6 months, the user has an option to store the data on a personal device, but the cloud data will be permanently deleted from Google servers.

The new privacy change is welcomed, smartphones can balance privacy and convenience in terms of data storage, but nothing is more important than location data. 

Users can change settings that suit them best, but the majority go with default settings. The problem here arises when Google uses user data for suggesting insights (based on anonymous location data), or improving Google services like ads products.

Why important 

The Google Maps Timeline feature addresses questions about data privacy and security. The good things include:

Better privacy: By restricting the storage timeline of location data on the cloud, Google can reduce data misuse. Limiting the storage duration means less historical data is exposed to threat actors if there's a breach.

More control to users: When users have the option to retain location data on their devices, it gives them ownership over their personal data. Users can choose whether to delete their location history or keep the data.

Accountability from Google: The move is a positive sign toward building transparency and trust, showing a commitment to user privacy. 

How will it impact users?

Services: Google features that use location history data for tailored suggestions might be impacted, and users may observe changes in correct location-based suggestions and targeted ads. 

The problem in data recovery: For users who like to store their data for a longer duration, the new move can be a problem. Users will have to self-back up data if they want to keep it for more than 180 days. 

Read more »
Multi-factor authentication
Cyber Security CyberThreat Data Safety Google Cloud Google security MFA Multi-factor authentication

Google Cloud to Enforce Multi-Factor Authentication for Enhanced Security in 2025

 


As part of its commitment to protecting users' privacy, Google has announced that by the end of 2025, all Google Cloud accounts will have to implement multi-factor authentication (MFA), also called two-step verification. Considering the sensitive nature of cloud deployments and the fact that phishing and stolen credentials remain among the top attack vectors observed by Mandiant Threat Intelligence, it seems likely that Google Cloud users should now be required to perform [2 steps of verification], as Mayank Upadhyay, Google Cloud's VP of Engineering and Distinguished Engineer, told the audience. 

By the end of 2025, Google's cloud division is planning to introduce an optional multi-factor authentication (MFA) feature for all users, as part of its efforts to improve account security as a part of its mission to improve security across the company. As part of a recent announcement by the tech giant, it was announced that it will begin the transition with a phased rollout, to help users adapt more smoothly to the changes. 

The technology industry and cyber security industry have long recommended multifactor authentication as a highly secure authentication method. With an additional step of verification, multi-factor authentication (MFA) dramatically reduces the risk of unauthorized logins, data breaches, and account takeovers, regardless of whether the user's password is compromised. As hackers continue to ramp up their sophisticated attacks on cloud infrastructure and sensitive data, Google is pushing for mandatory MFA as part of a growing trend in cybersecurity. 

According to recent announcements, Google is planning on requiring multi-factor authentication (MFA) for all Cloud accounts by the end of 2025, to protect cloud accounts. MFA is supposed to strengthen security while maintaining a smooth and convenient user experience online, which is exactly what Google claims. It has been reported that 70% of Google users have started using this feature and that security consultants are urging those users who are still on the fence to switch over to MFA at once. Users as well as admins who have access to Google Cloud will be affected by the implementation of the new process. 

Generally speaking, this change will not impact Google accounts of general consumer users. In a recent announcement sent made by Mayank Upadhyay, Google Cloud's VP of Engineering and Distinguished Engineer an official announcement the company stated that they plan to have mandatory MFA implemented throughout 2025 in a phased approach, with assistance being provided to help plan the deployment process. In response to Google's announcement, the company now states that it is taking a phased approach to the mandatory 2FA requirement that will apply to Google Cloud users; here's what that means in practice. 

There will be three phases to the implementation, and the first phase begins immediately with Google encouraging users to adopt 2FA if they have not yet had the chance to install 2FA protection on their account, but currently sign in with a password. Google estimates that 70% of online users have done this. As part of the first phase of the program, which is scheduled to begin in November 2024, the aim will be to encourage the adoption of MFA. The Google Cloud console will be regularly updated with helpful reminders and information. Resources will be available to help raise awareness, plan rollout and documentation of the MFA process, as well as to conduct testing and enable MFA for users with ease. The first phase of the project is scheduled to begin in November 2024 and will play a key role in facilitating the adoption of MFA. 

There will be several notes and reminders in the Google Cloud Console, including information you'll find helpful in raising awareness, planning rollouts, conducting tests, and ensuring that MFA is enabled smoothly for users, to help raise awareness. There will be a second phase that begins early next year and, at the start of the year, Google will start requiring MFA for users who sign in to Google Cloud with a password, whether they are new or existing. Nevertheless, Google has not yet expressed a concrete date for when it is planning to deploy the 2FA technology as part of phase two, which is scheduled for "early 2025". 

It is important to note, however, that all new Google Cloud users, whether or not they already have a password, will be required to implement two-factor authentication to sign in. As of now, this is a mandatory requirement, with no ifs, no buts. As soon as the Google Cloud Console, Firebase Console and iCloud are updated with the 2FA notification, Upadhyay will warn users that to continue using those tools, they need to enrol with the 2FA service. The final phase of Google Cloud's 2FA requirement will be rolled out by the end of 2025, it has been told and will be required for all users currently using federated authentication when logging into Google Cloud by that time. 

It was confirmed in the announcement that there will be flexible options for meeting this requirement. In other words, it appears to be an option for users to enable 2FA with their primary identity provider before accessing Google Cloud itself, or to add a layer of security through Google's system, using their Google account to enable 2FA through their cloud service. A senior director of technical field operations at Obsidian Security told me that the threat landscape has rapidly become more sophisticated as a result of this increased MFA prevalence. The breach data shows that 89% of compromised accounts have MFA enabled, according to Chris Fuller, senior director of technical field operations.

Several phishing-as-a-service toolkits, including the Mamba toolkit that you can buy for $250 a month, as well as non-human identity compromises, suggest that identity compromises will continue regardless of the technology used to carry out." Google's phased rollout is designed to ease users into the new requirement, which could have been met with resistance due to perceived friction in the user experience, especially when the requirement is implemented suddenly," Patrick Tiquet, Vice President of Security and Compliance at Keeper Security, said. Tiquet further emphasized that organizations leveraging Google Cloud will need to strategically prepare for MFA implementation across their workforce. 

This preparation includes comprehensive employee training on the critical role of multi-factor authentication in safeguarding organizational data and systems. Effective MFA adoption may be supported by tools such as password managers, which can streamline the process by securely storing and automatically filling MFA codes. Proper planning and training will be essential for organizations to successfully integrate MFA and enhance security measures across their teams.
Read more »
Google Cloud
AI Models AI technology Cyber Security Data integrity data poisoning data security Generative AI Google Cloud

Securing Generative AI: Tackling Unique Risks and Challenges

 

Generative AI has introduced a new wave of technological innovation, but it also brings a set of unique challenges and risks. According to Phil Venables, Chief Information Security Officer of Google Cloud, addressing these risks requires expanding traditional cybersecurity measures. Generative AI models are prone to issues such as hallucinations—where the model produces inaccurate or nonsensical content—and the leaking of sensitive information through model outputs. These risks necessitate the development of tailored security strategies to ensure safe and reliable AI use. 

One of the primary concerns with generative AI is data integrity. Models rely heavily on vast datasets for training, and any compromise in this data can lead to significant security vulnerabilities. Venables emphasizes the importance of maintaining the provenance of training data and implementing controls to protect its integrity. Without proper safeguards, models can be manipulated through data poisoning, which can result in the production of biased or harmful outputs. Another significant risk involves prompt manipulation, where adversaries exploit vulnerabilities in the AI model to produce unintended outcomes. 

This can include injecting malicious prompts or using adversarial tactics to bypass the model’s controls. Venables highlights the necessity of robust input filtering mechanisms to prevent such manipulations. Organizations should deploy comprehensive logging and monitoring systems to detect and respond to suspicious activities in real time. In addition to securing inputs, controlling the outputs of AI models is equally critical. Venables recommends the implementation of “circuit breakers”—mechanisms that monitor and regulate model outputs to prevent harmful or unintended actions. This ensures that even if an input is manipulated, the resulting output is still within acceptable parameters. Infrastructure security also plays a vital role in safeguarding generative AI systems. 

Venables advises enterprises to adopt end-to-end security practices that cover the entire lifecycle of AI deployment, from model training to production. This includes sandboxing AI applications, enforcing the least privilege principle, and maintaining strict access controls on models, data, and infrastructure. Ultimately, securing generative AI requires a holistic approach that combines innovative security measures with traditional cybersecurity practices. 

By focusing on data integrity, robust monitoring, and comprehensive infrastructure controls, organizations can mitigate the unique risks posed by generative AI. This proactive approach ensures that AI systems are not only effective but also safe and trustworthy, enabling enterprises to fully leverage the potential of this groundbreaking technology while minimizing associated risks.
Read more »
Vulnerabilities and Exploits
Google Cloud Mandiant Investigation Patching Sensitive data Vulnerabilities and Exploits

Think You’re Safe? Cyberattackers Are Exploiting Flaws in Record Time

 


There has been unprecedented exploitation by attackers of vulnerabilities in the software, Mandiant announced. According to the newly released report of the Mandiant cybersecurity firm, after an analysis of 138 exploits published in 2023, on average, in five days an attacker already exploits a vulnerability. Because of this speed, very soon it has become paramount for organisations to make their system updates quickly. The study, published by Google Cloud bloggers, shows that this trend has greatly reduced the time taken for attackers to exploit both unknown vulnerabilities, known as zero-day, and known ones, called N-day.

Speed in the Exploitation Going Up

As indicated by Mandiant research, the time-to-exploit, which is a statistic indicating the average number of days taken by attackers to exploit a discovered vulnerability, has been reducing rapidly. During 2018, it took nearly 63 days for hackers to exploit vulnerabilities. However, in the case of 2023, hackers took merely five days for exploitation. This shows that the attackers are getting more efficient in exploiting those security vulnerabilities before the application developers could patch them satisfactorily.

Zero-Day and N-Day Vulnerabilities

The report makes a distinction between the zero-day vulnerabilities, being the undisclosed and unpatched flaws that attackers would exploit immediately, and N-day vulnerabilities, which are already known flaws that attackers aim at after patches have already been released. In the year 2023, types of vulnerabilities targeted by the attackers changed, with rates of zero-day exploitation, which rose to a ratio of 30:70 compared with N-day attacks. This trend shows that attackers now prefer zero-day exploits, which may be because they allow immediate access to systems and sensitive data before the vulnerability is known to the world.

Timing and Frequency of Exploitation

This again proves that N-day vulnerabilities are at their most vulnerable state during the first few weeks when the patch is released. Of the observed N-day vulnerabilities, 56% happened within the first month after a patch was released. Besides, 5% were attacked within just one day of the patch release while 29% attacked in the first week after release. This fast pace is something that makes the patches really important to apply to organizations as soon as possible after they are available.

Widening Scope for Attack Targets

For the past ten years, attackers have enormously widened their scope of attacks by targeting a growing list of vendors. According to the report, on this front, the count increased from 25 in the year 2018 to 56 in 2023. The widening of such a nature increases the trouble for teams, who have now encountered a significantly expanded attack surface along with the ever-increasing possibility of attacks at a number of systems and software applications.


Case Studies Exposing Different Exploits

Mandiant has published case studies on how attackers exploit vulnerabilities. For example, CVE-2023-28121 is a vulnerability in the WooCommerce Payments plugin for WordPress, which was published in March 2023. Although it had been previously secure, it became highly exploited after the technical details of how to exploit the flaw were published online. Attacks started a day after the release of a weaponized tool, peaking to 1.3 million attacks in one day. This fast growth shows how easy certain vulnerabilities can be in high demand by attackers when tools to exploit are generally available.


The case of the CVE-2023-27997 vulnerability that occurred with respect to the Secure Sockets Layer in Fortinet's FortiOS was another type that had a different timeline when it came to the attack. Even though media alert was very much all over when the vulnerability was first brought to the limelight, it took them about two or three months before executing the attack. This may probably be because of the difficulty with which the exploit needs to be carried out since there will be the use of intricate techniques to achieve it. On the other hand, the exploit for the WooCommerce plugin was quite easier where it only required the presence of an HTTP header.

Complexity of Patching Systems

While patching in due time is very essential, this is not that easy especially when updating such patches across massive systems. The CEO at Quarkslab says that Fred Raynal stated that patching two or three devices is feasible; however, patching thousands of them requires much coordination and lots of resources. Secondly, the complexity of patching in devices like a mobile phone is immense due to multiple layers which are required for updates to finally reach a user.

Some critical systems, like energy platforms or healthcare devices, have patching issues more difficult than others. System reliability and uninterrupted operation in such systems may be placed above the security updates. According to Raynal, companies in some instances even ban patching because of the risks of operational disruptions, leaving some of the devices with known vulnerabilities unpatched.

The Urgency of Timely Patching

Says Mandiant, it is such an attack timeline that organisations face the threat of attackers exploiting vulnerabilities faster than ever before. This is the report's finding while stating that it requires more than timely patching to stay ahead of attackers to secure the increasingly complex and multi-layered systems that make up more and more of the world's digital infrastructure.


Read more »
UNC
CrowdStrike Cyber Security cybercriminals Financial Threat Google Cloud Google Mandiant Mandiant Threat Intelligence UNC

Protecting Your Business from Snowflake Platform Exploitation by UNC5537

 

A recent report from Mandiant, a subsidiary of Google Cloud, has uncovered a significant cyber threat involving the exploitation of the Snowflake platform. A financially motivated threat actor, identified as UNC5537, targeted around 165 organizations' Snowflake customer instances, aiming to steal and exfiltrate data for extortion and sale. Snowflake, a widely-used cloud data platform, enables the storage and analysis of vast amounts of data. The threat actor gained access to this data by using compromised credentials, which were obtained either through infostealer malware or purchased from other cybercriminals. 

UNC5537 is known for advertising stolen data on cybercrime forums and attempting to extort victims. The sold data can be used for various malicious purposes, including cyber espionage, competitive intelligence, and financial fraud. The joint statement from Snowflake, Mandiant, and cybersecurity firm CrowdStrike clarifies that there is no evidence of a vulnerability, misconfiguration, or breach within Snowflake’s platform itself. 

Additionally, there is no indication that current or former Snowflake employees' credentials were compromised. Instead, the attackers acquired credentials from infostealer malware campaigns that infected systems not owned by Snowflake. This allowed them to access and exfiltrate data from the affected Snowflake customer accounts. Mandiant's research revealed that UNC5537 primarily used credentials stolen by various infostealer malware families, such as Vidar, Risepro, Redline, Racoon Stealer, Lumma, and Metastealer. Many of these credentials dated back to November 2020 but remained usable. The majority of credentials exploited by UNC5537 were exposed through previous infostealer malware incidents. 

The initial compromise often occurred on contractor systems used for personal activities like gaming and downloading pirated software, which are common vectors for spreading infostealers. Once obtained, the threat actor used these credentials to access Snowflake accounts and extract valuable customer data. UNC5537 also purchased credentials from cybercriminal marketplaces, often through Initial Access Brokers who specialize in selling stolen corporate access. The underground market for infostealer-obtained credentials is robust, with large lists of stolen credentials available for free or for purchase on the dark web and other platforms. 

According to Mandiant, 10% of overall intrusions in 2023 began with stolen credentials, making it the fourth most common initial intrusion vector. To protect your business from similar threats, it is crucial to implement robust cybersecurity measures. This includes regular monitoring and updating of all systems to protect against infostealer malware, enforcing strong password policies, and ensuring that all software is kept up to date with the latest security patches. Employee training on cybersecurity best practices, especially regarding the dangers of downloading pirated software and engaging in risky online behavior, is also essential. 

Moreover, consider using multi-factor authentication (MFA) to add an extra layer of security to your accounts. Regularly audit your systems for any unusual activity or unauthorized access attempts. Engage with reputable cybersecurity firms to conduct thorough security assessments and implement advanced threat detection solutions. By staying vigilant and proactive, businesses can better protect themselves from the threats posed by cybercriminals like UNC5537 and ensure the security and integrity of their data.
Read more »
OpenAI
AI Chatbot Artificial Intelligence Cyber Security Google Google Assistant Google Cloud Large Language Model OpenAI

Google Launches Next-Gen Large Language Model, PaLM 2

Google has launched its latest large language model, PaLM 2, in a bid to regain its position as a leader in artificial intelligence. PaLM 2 is an advanced language model that can understand the nuances of human language and generate responses that are both accurate and natural-sounding.

The new model is based on a transformer architecture, which is a type of deep learning neural network that excels at understanding the relationships between words and phrases in a language. PaLM 2 is trained on a massive dataset of language, which enables it to learn from a diverse range of sources and improve its accuracy and comprehension over time.

PaLM 2 has several features that set it apart from previous language models. One of these is its ability to learn from multiple sources simultaneously, which allows it to understand a broader range of language than previous models. It can also generate more diverse and natural-sounding responses, making it ideal for applications such as chatbots and virtual assistants.

Google has already begun using PaLM 2 in its products and services, such as Google Search and Google Assistant. The model has also been made available to developers through Google Cloud AI, allowing them to build more advanced applications and services that can understand and respond to human language more accurately.

The launch of PaLM 2 is significant for Google, as it comes at a time when the company is facing increased competition from other tech giants such as Microsoft and OpenAI. Both of these companies have recently launched large language models of their own, which are also based on transformer architectures.

Google hopes that PaLM 2 will help it to regain its position as a leader in AI research and development. The company has invested heavily in machine learning and natural language processing over the years, and PaLM 2 is a testament to its ongoing commitment to these fields.

In conclusion, Google's PaLM 2 is an advanced language model that has the potential to revolutionize the way we interact with technology. Its ability to understand and respond to human language more accurately and naturally is a significant step forward in the development of AI, and it will be exciting to see how developers and businesses leverage this technology to build more advanced applications and services.


Read more »
Microsoft
CISA Cloud Services Cyber Security Cyberattacks Google Cloud Microsoft

Cybersecurity and the Cloud in Modern Times

 


Due to the advent of remote work, most companies - even those in heritage industries - have had to adopt SaaS (software as a service) and other cloud tools to remain competitive and agile in the market. Several modern cloud-based platforms, including Zoom, Slack, and Salesforce have become critical to the effective collaboration of knowledge workers from their homes, which will allow them to work more efficiently. In the last few years, public cloud hosting providers like Amazon Web Services, Microsoft Azure, and Google Cloud have seen phenomenal growth and success. This is a consequence of this tailwind. As per Gartner's predictions, by 2022, $178 billion will be spent on cloud providers, up from $141 billion in 2021. 

The shift to the cloud has led to lots of challenges when it comes to cybersecurity, although public cloud providers have made it easy to use modern software tools. Cloud-first security represents a paradigm shift from traditional, on-premise security in the modern day. Before this change, customers had complete control over their environments and security. They hosted their applications in their own data centers and were responsible for controlling the environment. Customers operated their network in a "walled castle" - where they controlled and secured the network and applications themselves. 

Nevertheless, when customers consume public cloud services, they are obligated to share responsibility for security with the cloud service providers as a shared responsibility. 

If your company stores data in a cloud data center provided by Amazon Web Services, you will be responsible for configuring and managing your cybersecurity policies. This is part of your compliance program. The customer is responsible for monitoring security breaches regardless of whether they have complete control over the data in the Amazon Web Services data center. As a result, when customers adopt public clouds, they no longer have full control over their security in terms of what they do with their data. A major barrier to adopting the cloud is concern about security, which is often among the most common. 

In addition, it is more difficult to secure cloud environments than traditional environments. As a result of today's cloud computing architecture, many cloud service providers utilize what is known as microservices, a design that allows each component of an application (for example, a search bar, a recommendation page, a billing page, etc.) to be created independently. On-premise systems can support as many as ten times the amount of workloads (for example, virtual machines, servers, containers, microservices) that the cloud can support. As a result of this fragmentation and complexity, there is a tendency for access control issues to develop, as well as a higher chance of developer errors - such as leaving a sensitive password in an AWS database. This information can be exposed to the public. Simply put, there is a wider and more complex attack surface area in the cloud than there is in local computing environments. 

Embrace the cloud-first era of cybersecurity

There are not just complexities associated with the cloud, but there has also been an inversion from a top-down to a bottom-up sales model, leading to security buying decisions being made not by CISOs or CISMs, but rather by developers (Chief Information and Security Officers). 

Two reasons have contributed to this happening. Due to the cloud, applications can be developed more efficiently. Therefore, the importance of cybersecurity has become a part of the development process rather than just an afterthought in the past few years. Responsibility for creating code and product releases was traditionally assigned to developers, while the team that works with the CISO is in charge of the cybersecurity aspect. As a result, the responsibilities of each party were split. It has become so easy to update code or to release product updates every day or every week in modern companies due to the cloud. This has made it much easier for them to do so. It's common nowadays for our favorite apps to update themselves frequently. For instance Netflix, Amazon, and Uber, but not so long ago, this wasn't the norm. We had to manually patch them to get them to run smoothly. With the increased frequency of deploying revised code, cybersecurity has become a problem that developers now have to care about because of the increased frequency of application development. 

In the second place, the early adopters and the power users of the cloud are primarily digital start-ups and medium-sized businesses, which are more decentralized in their decision-making processes. Traditionally, CISOs at large enterprises have played an active role in making security decisions about the organization. A CISO, acting as the chief executive officer of the company, makes purchasing decisions on behalf of the rest of the organization. This was after rigorous proof of concept, negotiation, and cost-benefit processes. The different techniques used by start-ups and mid-scale customers to make security buying decisions are very different, and many often, they leave security decision-making to their developer team. 

As a result of this revolutionary top-down sales model, cybersecurity software is about to be built and sold in a completely different way. Developing a sales model that is suitable for developers is different from one designed for CISOs. There is no doubt that developers prefer self-serve features - they often like to try and offer their products to their customers before they have to purchase them. To achieve this goal, we need to build a self-serve and freemium sales model, so we can attract a large number of inbound, free users at the top of the funnel and build a customer base around them. In comparison with the traditional sales model used by security incumbents, this model is completely different, as the incumbents have hired huge sales teams that are responsible for outbound selling large deals to their CIOs in a sales-led approach.
Read more »
Technology
Cloud Security GCP Google Cloud Mainframe Real-Time testing Software Technology

Mainframes are Still Used in 9 Out of 10 Banks, Google Cloud Wishes to Mitigate

 



It has been announced that Google Cloud is introducing a simpler, more risk-averse way for enterprises to migrate their legacy mainframe estates to the cloud. Google Cloud's newly launched service is based on technology originally developed by Banco Santander and aims to simplify planning and execution.

As a result, customers can perform real-time testing before they transition to Google Cloud Platform as their primary system to ensure their cloud workloads are performing as expected, running securely, and meeting regulatory compliance requirements – without stopping their application or negatively impacting user experience.

In his interview with Protocol on Tuesday, Nirav Mehta told: "This is a simple concept, but it is difficult to implement - hasn't been done yet," Nirav Mehta, Google Cloud's senior director of product management for cloud infrastructure solutions and growth, said. As compared to moving mainframe applications to the cloud, this solution will substantially reduce the risk associated with doing so." 

A parallel instance of mainframe workloads is created by using virtual machines on the Google Cloud Platform (GCP) through Dual Run. As Mehta describes, a launcher/splitter is an architecture consisting of the necessary mechanisms to duplicate activity - and return the "primary" response of the system - at each interface that drives the incoming requests or triggers the scheduled workload and can handle both.

A dashboard that displays real-time monitoring shows the differences in transaction responses between the mainframe and GCP deployments that are displayed on the dashboard. The single output hub also ensures that there is a single point of contact during the roll-out period for all batch information that needs to be sent out and collected.

Once the customers are comfortable with the use of their mainframes as backups, they can retire their mainframes or use them as storage.

As long as your mainframe is the primary system that handles customer requests, it should remain the system of choice for quite some time to come. You can consider the cloud instance as nothing more than a secondary system. This will also run the same requests as the regular system, Mehta explained. As part of your monitoring process, you maintain a record of the responses coming back from both the mainframe and Google Cloud. This is to determine whether the Google Cloud instance is working equally well as the mainframe. Then at some point, you switch over to using Google Cloud as your primary source of data and the mainframe as your secondary source of data.

The Dual Run device, which is currently in the preview stage, was developed for a wide range of industries, including the financial services, health care, manufacturing, and retail industries, and the public sector as well. Approximately 90% of North America's biggest banks still use mainframes, according to Mehta, while 23 of the 25 largest U.S. retailers use mainframes as well.

"All of these companies are looking to modernize their old mainframe applications and take them to the cloud to maximize security, scalability, and cost efficiency," he said. However, because these systems are so mission-critical - and mainframes are especially unique in this regard since they've been around for so long and contain so much legacy technology - they perceive a lot of risks, so they do not bring them to the cloud."

In May, Banco Santander, a Google Cloud customer, published a report about the progress it has made in digitizing its core banking platform. It said that 80% of its IT infrastructure had been moved to the cloud using software developed in-house called Gravity, to automate the process. The technology is an exclusive license that Google Cloud has acquired, and its engineers have been working with Santander during the past six months to optimize the technology to make it more suitable for end-to-end mainframe migrations for customers in a wide variety of industries. 

Mehta explained that they only had a very limited use case for the software. The relevance of the solution to any mainframe customer has been elevated to a substantial extent thanks to the changes we have made. This is a huge deal for anyone running mainframes because it allows them to access data remotely.
Read more »
URL
API Cyber Security Google Cloud Security Researchers SSRF URL

A URL Parsing Bug Left an Internal Google Cloud Project Open to SSRF Attacks

 

According to security researcher David Schütz, a URL parsing flaw exposed an internal Google Cloud project to server-side request forgery (SSRF) attacks. The bug, which Schütz detailed in a video and blog post, might have allowed an attacker to gain access to sensitive resources and perhaps launch harmful code.

Server-side request forgery is a web security flaw that allows an attacker to force a server-side application to send HTTP requests to any domain the attacker chooses. The attacker may cause the server to connect to internal-only services within the organization's infrastructure in a conventional SSRF attack. They may also be able to force the server to connect to arbitrary external systems, exposing sensitive data such as authorization credentials. 

Unauthorized activities or access to data within the company can often arise from a successful SSRF attack, either in the vulnerable application itself or on other back-end systems with which the programme can interface. The SSRF vulnerability could allow an attacker to execute arbitrary commands in some circumstances. An SSRF vulnerability that establishes connections with external third-party systems could lead to malicious attacks that appear to come from the company that hosts the vulnerable application. 

While researching Discovery Documents, data structures that give specifications for Google API services, Schütz discovered the problem. While looking through the Discovery Documents, Schütz came upon an intriguing service named Jobs API, which had the appearance of being an internal service. The Jobs API led him to an application on the Google App Engine that acted as a proxy, allowing him to access the API through Google's public product marketing pages. The proxy acted as an intermediate between the user and the API, which meant it had an access token that could be used to launch SSRF attacks. 

Request URLs were run via a whitelist to restrict access to internal Google resources. Schütz, however, was able to fool the URL parser and bypass the whitelist, allowing him to send requests to any server he wanted. This allowed him to send requests from the proxy app to a Google Cloud VPS server. The request revealed the proxy app's access token, which he could then use to send requests to other Google Cloud projects.

“This issue feels like an industry-wide problem since different applications are parsing URLs based on different specifications,” Schütz said. “After disclosing the initial issue in the Google JS library, I have already seen this getting fixed in products from different companies as well. Even though, this issue still keeps popping up even at Google. This SSRF is a great example of it.”
Read more »
Phishing emails
Cyber Attacks Google Google Cloud Microsoft Phishing emails

Cyber Attackers Hijacked Google and Microsoft Services for Malicious Phishing Emails

 

Over recent months, the cybersecurity industry has seen a huge increase in malicious attackers exploiting the networks of Microsoft and Google to host and deliver threats through Office 365 and Azure. 

The actors who are at risk are quickly moving towards cloud-based business services during the pandemic by concealing themselves behind omnipresent, trustworthy services from Microsoft and Google to make their email phishing scams appear legitimate; and it works. 

In particular, during the first three months of the year 2021, researchers discovered that 7 million malicious e-mails were sent from Microsoft's 365, and also that 45 million were transported from Google's network. The Proofpoint team said that cyber-criminals had been able to send phishing e-mails and host attacks with Office 365, Azure, OneDrive, SharePoint, G-Suite, and Firebase. 

“The malicious message volume from these trusted cloud services exceeded that of any botnet in 2020, and the trusted reputation of these domains, including outlook.com and sharepoint.com, increases the difficulty of detection for defenders,” the report, issued on Wednesday, explained. “This authenticity perception is essential, as email recently regained its status as the top vector for ransomware; and threat actors increasingly leverage the supply chain and partner ecosystem to compromise accounts, steal credentials and siphon funds.” 

Proofpoint estimated that 95% of cloud account organizations had been attacked, and more than half of them succeeded. Additionally, more than 30% of those organizations were compromised. 

Once attackers have access to passwords, they can easily enter or exit several services and send out more, persuasive phishing emails. 

Proofpoint offered many examples of projects behind Microsoft and Google that tried to scam users to give up or deliver their details. 

Attackers exploited Gmail to host another operation throughout March, that provided them with the message of the fake benefits together with a Microsoft Excel attachment, that delivered The Trick Bank Trojan to steal credentials whenever macros were activated. 

Another Gmail-hosted February attack seeks to persuade users to use their passwords for accessing zip-on MS Word documents. Upon opening, Xorist ransomware has been delivered. 

The use of Gmail and Microsoft by attackers to give their emails a patina of credibility is part of a broader trend: threats are developing increasingly persuasive appeals. 

“Our research demonstrates that attackers are using both Microsoft and Google infrastructure to disseminate malicious messages and target people, as they leverage popular cloud-collaboration tools,” the Proofpoint report added. “When coupled with heightened ransomware, supply chain, and cloud account compromise, advanced people-centric email protection must remain a top priority for security leaders.”
Read more »
Subscribe to: Comments (Atom)