A former analyst working for the U.S. Central Intelligence Agency (CIA) pleaded guilty to transmitting top secret National Defense Information (NDI) to individuals who did not have the necessary authorization to receive it and attempted to cover up the activity.
Asif William Rahman, 34, of Vienna, was an employee of the CIA since 2016 and had a Top Secret security clearance with access to

Ex-CIA Analyst Pleads Guilty to Sharing Top-Secret Data with Unauthorized Parties

Introduction Microsoft engineering teams use the Security Development Lifecycle to ensure our products are built in alignment with Microsoft’s Secure Future Initiative security principles: Secure by Design, Secure by Default, and Secure Operations.
A key component of the Security Development Lifecycle is security testing, which aims to discover and mitigate security vulnerabilities before adversaries can exploit them.

**Introduction**

Microsoft engineering teams use the Security Development Lifecycle to ensure our products are built in alignment with Microsoft’s Secure Future Initiative security principles: Secure by Design, Secure by Default, and Secure Operations.

A key component of the Security Development Lifecycle is security testing, which aims to discover and mitigate security vulnerabilities before adversaries can exploit them. Most enterprises have mature solutions in place for manual processes such as code review, penetration testing, and red teaming, as well as automated processes such as Static Application Security Testing (SAST). However, they often struggle with Dynamic Application Security Testing (DAST) when it comes to securing API web services. This is because while SAST tools can easily be integrated into web services’ CI/CD pipelines by a DevSecOps team without additional work from the services’ developers, DAST tools are not as simple to orchestrate.

In this blog post, we recap a recent BlueHat talk about the journey that Microsoft’s Azure Edge & Platform organization is on, using security automation to perform DAST at scale. This effort targets thousands of internal and external API web services across Microsoft’s portfolio of 1st party services, which are applications or services that are created, owned, and managed by Microsoft itself.

**Why most enterprises have trouble scaling DAST**

DAST is a software testing process that seeks to elicit security vulnerabilities or weaknesses by exercising the software at runtime. In the context of testing web applications and web services, this typically consists of sending malformed web requests via fuzzing or other means to identify bugs based on the web server’s responses to those requests. There are many excellent commercial and open-source DAST tools available for scanning web applications, including one from Microsoft named RESTler. Whether we want to scan web servers with a single DAST tool or a dozen, the tool needs to know the web endpoints and the web server’s endpoint logic needs to process its requests. It also requires access to a web service’s API specification and valid authentication credentials; neither of which are trivial to provide at scale in a secure way without manual effort from developers.

**Web endpoint discovery**

Historically, the only input required by a DAST tool was the target web server address to scan. A DAST tool would automatically crawl the given site, starting at the home page, and follow links embedded in the HTML to discover all the site pages. In doing so, the DAST tool would discover all dynamic functionality offered by the site, in the context of pages (or more generally, URLs) that accept input from the user.

In the image above, we can see that the DAST tool begins its crawl at https://www.contoso.com/, follows a link from the homepage to https://www.contoso.com/contact.html, and discovers a contact form on that page that accepts user input via URL parameters and/or a request body. The DAST tool can now send requests to the https://www.contoso.com/contact/inquiry.asp page with malformed values trying to discover security vulnerabilities in the handling of inputs on the dynamic page.

In general, this crawling approach still works reasonably well for traditional websites but cannot be used for web services whose functionality is solely exposed via APIs. Consider the diagram below, where a mobile app communicates with the REST API web service https://api.fabrikam.com/:

In this example, the mobile app has the REST API endpoints /login, /products, /cart, and /logout hardcoded into the app. When the DAST scanner tries to open https://api.fabrikam.com/, it gets an error.

To support this scenario, a modern DAST tool typically allows users to provide a list of endpoints as input via an OpenAPI Specification (sometimes referred to as a Swagger Specification). This specification enumerates a detailed list of a web service’s API URLs, all the parameters accepted by each API, and metadata describing the expected format of each parameter. OpenAPI Specifications can be generated by packages such as NSwag and swagger-core. Using these packages requires access to both the source code and the working build environment for the given service. This requires developers to manually integrate these solutions into the web service project, which could be a good approach for smaller organizations.  

However, if an enterprise security team asked all of their company’s developers to integrate such solutions into their web service projects, they would certainly receive pushback from leadership and developers due to the massive cost of manually going through the process of updating each project’s code and build configuration.

**Automated OpenAPI Specification generation solutions that do scale (sort of)**

There are several techniques to automatically generate OpenAPI Specifications that don’t require manual per-service developer involvement.

One solution is to monitor requests sent to the target web server and extrapolate an OpenAPI Specification based on those requests in real-time. This monitoring could be performed client-side, server-side, or in-between on an API gateway, load-balancer, etc. This is a scalable, automatable solution that does not require each developer’s involvement. Depending on how long it runs, this approach can be limited in comprehensively identifying all web endpoints. For example, if no users called the /logout endpoint, then the /logout endpoint would not be included in the automatically generated OpenAPI Specification.  

Another solution is to statically analyze the source code for a web service and generate an OpenAPI Specification based on defined API endpoint routes that the automation can gleam from the source code. Microsoft internally prototyped this solution and found it to be non-trivial to reliably discover all API endpoint routes and all parameters by parsing abstract syntax trees without access to a working build environment. This solution was also unable to handle scenarios of dynamically registered API route endpoint handlers. Microsoft also internally prototyped a variation of the static analysis solution that used an LLM to derive an OpenAPI Specification from source code. We saw some promising results, but unfortunately the solution was non-deterministic.

To truly scale DAST for thousands of web services, we need to automatically, comprehensively, and deterministically generate OpenAPI Specifications. Even with such a solution in place, we still need to ensure that our DAST tools can exercise the functionality of the tested services.

Most enterprise web services require authentication, thus, to fully exercise the functionality of the web service, the DAST tool needs to provide an authentication credential. The web service also needs to grant authorization for the DAST tool to submit requests to the service. In testing environments, this would typically mean using a unique testing account per service or using a company-wide testing account and configuring the DAST tool accordingly. The former requires significant complexity in orchestrating the DAST tool’s execution per service, and the latter allows for a central point of compromise. Both approaches still require each service owner to manually make configuration changes. Similarly, with OpenAPI Specification generation, leadership and developers would likely push back on this massive cost.

**A scalable DAST solution**

As a Cloud Service Provider, Microsoft owns the IaaS and PaaS platforms on which our web services run and has the ability to generate inventories of our 1st party services and deploy custom security tooling onto those services. The Azure Edge & Platform organization, responsible for Microsoft’s edge computing and operating systems, is creating a solution to take advantage of this deployment capability by developing an agent that can be deployed to the non-production test instances of all our IaaS-based and PaaS-based web services. These non-production instances share the same code as the production instances. Performing DAST in non-production environments protects the fidelity of data in production environments. The DAST agent is one component of a larger DAST orchestration platform that obviates the need for access to web services’ build environments and the need to trouble developers with manually integrating new functionality into their services’ CI/CD pipelines. The agent has full access to the runtime state of the running web service’s process, giving it the ability to inspect memory and load new code into the running process.

**Web endpoint discovery**

A typical web server maintains a mapping of URL routes to route handlers to manage incoming requests. The agent leverages this architecture by inspecting the memory of the web server’s process at runtime to discover its route mappings and generates an OpenAPI Specification from the identified mappings.

The vast majority of web services in our organization are written in ASP.NET, which uses a request handling pipeline to process incoming requests:

Each block in the diagram above is a middleware component that is given the opportunity to process the incoming request before handing it to the next component in the pipeline (or alternatively short-circuiting the remaining middleware components).

The last middleware component in the pipeline is the Endpoint component. Per the documentation for Microsoft.AspNetCore.Builder.EndpointRoutingApplicationBuilderExtensions.UseEndpoints(), “The Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware defines a point in the middleware pipeline where routing decisions are made, and an Endpoint is associated with the HttpContext.” We examine the source code for Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware and see that it contains a field named \_endpointDataSource, which is a Microsoft.AspNetCore.Routing.EndpointDataSource object, which itself contains a property named Endpoints. Per the documentation, that Endpoints property is “a read-only collection of Endpoint instances”. Each of those Endpoint instances contains a Metadata collection that holds the details of the route endpoint.

Our solution for web endpoint discovery involves the agent automatically discovering the request handling pipeline in the web server process’s memory at runtime and following the object fields described above to find all Endpoint object instances. Automation in the agent then processes the metadata associated with each of those instances and uses Microsoft.OpenApi.Writers.OpenApiJsonWriter to dynamically generate a complete OpenAPI Specification for the web service, containing all API endpoints and their detailed parameters. That OpenAPI Specification can then be provided as input to a DAST tool to scan the target web service.

While the details above are specific to ASP.NET Core, the same approach of route discovery via runtime memory inspection could be applied to web services written in other frameworks like ASP.NET Framework, PHP, Node.js, etc.

**Authentication and authorization**

To overcome the challenges and risks of using testing accounts to allow DAST tools to send authenticated requests to web services, we can hook the Authentication and Authorization middleware components at runtime, eliminating the need for testing accounts altogether:

Our solution for authentication and authorization is a technique we call Transparent Auth. This involves inserting a new delegate before the Authentication component and before the Authorization component. Our agent does this by automatically traversing the request handling pipeline in memory and inserting new delegates at runtime.  

While the Transparent Auth details are specific to ASP.NET Core, the same approach of runtime authentication and authorization hooking could be applied to web services written in other frameworks like ASP.NET Framework, PHP, Node.js, etc.

**Authentication hook**

The hook we inject before the pipeline’s Authentication component inspects the client’s request to determine if it is from one of our orchestrated DAST tools. We use an out-of-process component to track all requests originating from the orchestrated DAST tool, and our hook communicates with that component to verify that the request was indeed one that originated from the orchestrated DAST tool. If our hook determines that the request is not from the orchestrated DAST tool then it passes the request to the original Authentication component, which processes the request as normal.

On the other hand, if the hook determines that the request is from the orchestrated DAST tool, it has some extra work to do. It can’t merely skip over the original Authentication component because this could cause problems if other middleware components try to make use of the identity associated with the request. For example, imagine a web service that responds to authenticated requests with, “Hello, <username>” – if there is no username associated with the identity of the request’s context then this functionality would throw an exception. To address this, our hook creates a new ClaimsPrincipal and associates that ClaimsPrincipal with the current request’s context. The ClaimsPrincipal is comprised of a collection of Claim objects to flesh out the identity of the mock user, with values for the mock user’s name, email address, etc.

Once the request’s context is updated with this new ClaimsPrincipal, our hook skips over the original Authentication component and calls the request delegate immediately following the original Authentication component.

**Authorization hook**

The hook that we inject before the pipeline’s Authorization component starts off similarly to the Authentication hook. It verifies the client’s request is from our orchestrated DAST too, and passes the request to the original Authorization component if it is not.

If the hook determines that the request is from the orchestrated DAST tool, it makes a couple of small updates to the request’s context that would normally be done upon successful authorization. It then skips over the original Authorization component and calls the request delegate immediately following the original Authorization component, thereby circumventing the authorization check and allowing the service’s endpoint logic to process the request.

**DAST orchestration platform architecture**

The functionality of the agent described above fits into the overall DAST orchestration platform architecture; illustrated at a high-level below.

Microsoft’s security extension deployment mechanism deploys the agent onto 1st-party Microsoft web servers. The agent then injects an OpenAPI Specification Generator Module and a Transparent Auth Module into each of the web service processes running on the web server. The OpenAPI Specification Generator Module generates the OpenAPI Specification for the web service and passes it to the DAST Proxy process, which was launched by the agent. The DAST Proxy starts a remote Confidential Container, sends the OpenAPI Specification to the container, and runs orchestrated DAST tools in the container based on the supplied OpenAPI Specification.

We use Confidential Containers for several reasons. First, their Trusted Execution Environments ensure that if an attacker were to compromise Azure’s Container Instances service, they wouldn’t be able to tamper with the code or data in our containers. Confidential Containers also enable the agent to verify the attestation report of the container with which it’s communicating to ensure that the container was built from the official DAST container image and that the security policy applied to the container is the official DAST container security policy. We use one container per target web service, and each container operates in its own pod, ensuring the DAST containers can’t communicate with each other. Each pod is firewalled to prevent outbound connections and to ensure that inbound connections are only allowed from the agent that launched the pod’s container. This confluence of protections work together to prevent an attacker from circumventing authentication or authorization checks, impersonating one of our orchestrated DAST tools, or discovering DAST scan results.

The DAST Proxy proxies requests from the DAST Tools to the target Web Service Process. The Transparent Auth Module intercepts each request and validates the request with the DAST Proxy. If the DAST Proxy confirms that the request is from an orchestrated DAST Tool then the Transparent Auth Module skips the standard authentication and authorization checks and allows the endpoint components to process the request. The DAST Proxy then proxies the web service’s responses back to the DAST Tools. Once the DAST Tools complete their scans, the DAST Proxy collects the results and sends the security findings to a centrally managed bug tracking system. Those centrally collected security findings can then be handled by the service owner, their security assurance team, and any associated risk management teams.

**Conclusion and looking ahead**

In the coming months, Microsoft’s Azure Edge & Platform organization will continue to develop and roll out the agent to 1st-party services. We will also explore leveraging the agentic architecture to support more advanced DAST-related concepts such as code coverage monitoring and associating DAST security findings to the vulnerable code blocks. We’re excited about opportunities to converge and deduplicate findings across multiple DAST tools and to use AI to identify false-positives and determine risk confidence.

In conclusion, this work underscores Microsoft’s dedication to securing our services and safeguarding our customers’ data, highlighting our security leadership in the hyperscaler space. We hope that it inspires security professionals outside of Microsoft to adopt similar strategies to secure their own services at scale.

_Jason Geffner  
Principal Security Architect_

Scaling Dynamic Application Security Testing (DAST) 

FortiGate firewall leak exposes 15,000+ configurations, impacting organizations globally. The actor behind the leak is Belsen Group. Learn…

FortiGate firewall leak exposes 15,000+ configurations, impacting organizations globally. The actor behind the leak is Belsen Group. Learn how to mitigate risks and protect your systems.

A new leak from a threat actor group dubbed Belsen Group or (Belsen\_Group) has exposed configurations from over 15,000 **FortiGate firewalls**, threatening organizations that use these devices, as it could allow attackers to gain access to sensitive systems and bypass defences. The US, UK, Poland, and Belgium have the highest number of victims, followed by France, Spain, Malaysia, Netherlands, Thailand, and Saudi Arabia.

Research by CloudSEK’s contextual AI digital risk platform XVigil **reveals** that in 2022, the Belsen Group breached a zero-day vulnerability, leaking over 15,000 Fortigate firewall configurations. The leaked information includes usernames, passwords (some in plain text), device management digital certificates, and all firewall rules. This data gives attackers a treasure trove of information that they can exploit. 

Belsen Group on Breach Forums and its dark web leak site (Screenshot Hackread.com)

Exposed usernames and passwords, especially those in plain text, can be used by attackers to directly access sensitive systems on your network. Even if you patched the vulnerability (**CVE-2022-40684)** in 2022, it is crucial to check for signs of compromise since this was a zero-day exploit. Leaked firewall configurations reveal your internal network structure, potentially allowing attackers to identify weaknesses and bypass security measures.

Breached digital certificates could allow unauthorized access to devices or impersonation during secure communications. What’s even more concerning is that organizations that patched the vulnerability after the initial disclosure in 2022 might still be at risk if attackers gained access before the patch was applied.

****Belsen Group’s Motives and History****

While the Belsen Group appears to be new on the hacking forum scene, the leaked data suggests they’ve been around for at least three years. Researchers believe they were likely part of a group that exploited a zero-day vulnerability (CVE-2022-40684) in FortiGate firewalls in 2022. After potentially using or selling the access gained through the exploit, they’ve now resorted to leaking the data in 2025.

To mitigate risks arising from such leaks, it is essential to update all device and VPN credentials, especially those listed in the leaked data, and implement strong passwords. Audit and reconfigure firewalls to identify vulnerabilities and tighten access controls. Rotate compromised digital certificates to ensure secure communication.

Additionally, determine the timeline for patching CVE-2022-40684 in your organization, conduct forensic analysis on compromised devices, and monitor your network for unusual activity. These steps will help protect your network and reduce potential risks.

CloudSEK has created a useful resource for organizations to check if any network is part of the exposed IPs after analysing data, which is available **here**.

1.  **UNC5820 Exploits FortiManager Zero-Day Vulnerability**
2.  **CISA and Fortinet Warns of New FortiOS Zero-Day Flaws**
3.  **Hackers Exploiting 0-day Vulnerability in Fortinet Products**
4.  **Hackers leak login credentials of vulnerable Fortinet SSL VPNs**
5.  **Hackers dump login credentials of Fortinet VPN users in plain-text**

Belsen Group Leaks 15,000+ FortiGate Firewall Configurations

Feeling creative? Have something to say about cybersecurity? Submit your caption and our panel of experts will reward the winner with a $25 gift card.

What motivates you? What will change how you do security? Send us a cybersecurity-related caption to describe the above scene and our favorite entry will win its wordsmith a $25 gift card.

Here are four convenient ways to submit your ideas before the Feb. 12 deadline:

*   Via social media: Bluesky, LinkedIn, Facebook, and X. (If you win, we'll respond to you on the same platform, requesting your email address.)
    

**Last Month's Winner**

Shout out — and a $25 gift card — to Paul Mauriks, ICT security specialist, technology solutions, at the Department of Justice and Community Safety in Victoria, Australia for sending us the winning caption for last month's "Sneaking Around" cartoon. Some noteworthy contenders included "I guarantee you there are no backdoors to our network," "Finally found a way to get rid of all that old IT gea.," and "‘Yeah, asset disposal by ‘Back Door Inc.’ I’ll do the supplier assessment thing on Monday…’" Congrats to Paul, and a big thank you to all who participated.

**About the Author**

Cartoonist

John Klossner has been drawing technology cartoons for more than 15 years. His work regularly appears in Computerworld and Federal Computer Week. His illustrations and cartoons have also been published in The New Yorker, Barron's, and The Wall Street Journal.

Name That Toon: Incentives

WriteFreely through 0.15.1, when MySQL is used, allows local users to discover credentials by reading config.ini.

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.

Attack complexity: More severe for the least complex attacks.

Privileges required: More severe if no privileges are required.

User interaction: More severe when no user interaction is required.

Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.

Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.

Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.

Availability: More severe when the loss of impacted component availability is highest.

GHSA-3qc3-mx6x-267h: Insecure default config access in WriteFreely

The US Department of Commerce will prohibit the import of components for connected vehicles from China or Russia, as the US continues to ban technology it sees as potential national security threats.

Source: Hsyn20 via Shutterstock

Smart-vehicle makers are facing supply chain disruption as the US Department of Commerce plans to enforce new regulations banning the import of connected-vehicle technology from China and Russia over cybersecurity fears.

The Commerce Department pursued new regulations after President Biden declared a national emergency over concerns that the United States had become overreliant on China for information and communications technology and services (ICTS). The rule mandates that companies and their suppliers eliminate hardware or software imported from China or Russia in their vehicle connectivity system (VCS) or in their automated driving system (ADS).

It aims to address two concerns: vulnerabilities that would allow a nation-state or criminal organization to implant a backdoor in automotive hardware or software; and the collection of data on US drivers through diagnostic features and other mechanisms, says Yoav Levy, CEO and co-founder of automotive cybersecurity provider Upstream.

"The threat is definitely real," he says. "There are many cases where cars could be hacked — including the safety elements within the cars — and there were many cases where data was stolen or leaked. ... But so far, we haven't seen something like that on a huge scale."

Related:Leveraging Behavioral Insights to Counter LLM-Enabled Hacking

The concerns come as software-defined vehicles (SDVs) shake up the automotive market, while also potentially increasing the cyberattack surface area of automobiles. In the past, vehicle makers created a variety of platforms for their different models, and the number of processors — known as electronic control units (ECUs) — quickly climbed. While the post-pandemic chip shortage slowed the shift to new platforms, manufacturers now aim to quickly reduce the number of ECUs and other hardware needed for the VCS and ADS systems. While current models, for example, can have as many as 130 ECUs, Rivian has already reduced the number of ECUs to seven in its second generation R1 vehicles.

**Wielding the Cyber-Ban Hammer**

Rivian aside, most automobiles have a wide variety of components sourced from China, raising concerns that the United States' reliance on the technologies could allow future compromises.

Banning technology from China and sanctioning Russia is nothing new, says Ivan Novikov, CEO at API security firm Wallarm. The US government has already raised cybersecurity concerns over telecommunications equipment from Huawei, Chinese-made cargo equipment at US seaports, home routers made by Chinese manufacturer TP-Link, and popular social media app TikTok.

Related:Strategic Approaches to Threat Detection, Investigation & Response

"This is kind of the next logical step," he says.

The new commerce regulations will prohibit any "transactions involving VCS hardware and covered software designed, developed, manufactured, or supplied" by people or organizations linked to China or Russia, according to a 213-page final rule, which will be put into effect after months of comments.

Yet, many implementation details remain unclear, Novikov says.

"The open question here is who will enforce the regulations, because the usual enforcement of security requirements and crash \[safety\] tests is under the Department of Transportation," he says. "It's unclear how these two agencies can work together, and how this final DoT requirements or restrictions or controls can work."

**Securing Supply Chains & the Economy?**

The impact on the supply chain will be significant, experts say. The first tier of OEMs — large US and international companies — are not the problem. Their products, however, often come from suppliers that source their own components from Chinese companies, says Alex Oyler, director for North America at industry consultancy SBD Automotive.

It's just one more way that the supply chain is currently undergoing changes, he says. Many carmakers are looking to rewrite their relationships with providers as they move to software-defined vehicles.

Related:Trusted Apps Sneak a Bug Into the UEFI Boot Process

"We're in a bit of a different phase of software-defined vehicle in the sense that OEMs are actually starting to become a lot more prescriptive in the specification of the components that they're sourcing," Oyler says. "It's more of what's called a build-to-print relationship, where they provide not the functional requirements, but requirements for the component architecture — we want this processor, we need this memory, we need this GPU."

The shift to other sources of supply will take years, with the Biden administration allowing carmakers a grace period to comply with the regulations: Software components can no longer be sourced from China and Russia starting with 2027 car models, while by 2030 car models must contain no hardware from prohibited sources.

Making such changes will not be easy, says Upstream's Levy.

"It's not that easy to replace a supplier," he says. "There are financial implications with the supply chain — maybe it's going to be more expensive, or there may be some changes to software that they would need to do for the for the new supplier — an adjustment to the architecture. ... It really depends on what they are actually going to replace."

**About the Author**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

US Ban on Automotive Components Could Curb Supply Chain

New hands-on testing results show that most devices are unable to catch phishing emails, texts, or calls, leaving users at risk.

Source: Thomas Bethge via Alamy Stock Photo

Highlights:

*   Consumer survey shows that the most common security issues are phishing attacks, such as text or emails seeking personal information, as well as malware and physical theft. 
    

*   Hands-on device testing shows that Samsung S24 offers the best anti-phishing protection, while the Google Pixel 9 Pro leads in many other areas. 
    

*   The iPhone 16 Pro and other premium Android smartphones from Honor, Xiaomi, and OnePlus lack security features and protections. 
    

COMMENTARY  
New research from Omdia shows that the security capabilities on several of the latest consumer smartphones, including top devices from Apple, Google, and Samsung, fail to detect several types of common phishing attacks.

As part of the fourth-annual Omdia Mobile Device Security Scorecard, Omdia surveyed 1,572 consumers across 13 major countries in the Americas, Asia and Oceania, and Europe, in October 2024. This survey covered the demographics of smartphone users, their security concerns and attitudes, their perception of the most common security threats, and the key smartphone purchasing drivers.

Consumers reported that the most common security issue they encountered was phishing scams and attacks (texts, emails or calls which use false pretenses to try to get the target to give away valuable personal information), with 24% reporting to have experienced phishing. 

Omdia also asked consumers to rate how important various security features were, with anti-phishing having the largest net-importance rating. In fact, over the four years Omdia has conducted its Mobile Device Security Scorecard research, anti-phishing has been rising in importance. This is no surprise, as phishing not only becomes more common, but also as consumers become more familiar with the attacks and the potential for personal information theft or financial loss. 

The next most common security issue was malware and viruses. The third most common was physical theft, such as pickpocketing, mugging or snatching. 

**Mobile Device Security Testing Results**

For each of these security issues, Omdia tested leading premium smartphones to determine availability and effectiveness of security features and capabilities. Google's Pixel 9 Pro and Samsung's Galaxy S24 both scored highly, ahead of Apple's iPhone 16 Pro and other leading Android-based devices, including the OnePlus 12, Xiaomi 14, and Honor Magic 6 Pro.

Despite the importance consumers place on phishing prevention on mobile devices, the anti-phishing features failed to some degree on every device Omdia tested. No device caught all the attempted phishing texts, calls, and emails initiated as part of the testing.  

Several of the devices did catch simulated spam calls: All Android devices from Google, Xiaomi, OnePlus, Honor, and Samsung, which have voice call protection, flagged suspected spam calls before the recipient could answer the call. The iPhone 16 Pro, however, did not have the same protections and did not catch the simulated spam call. 

Text messages with malicious short links were sent from an unknown number and sender ID, but these were not successfully caught by the test devices. Simulated phishing emails were sent from both Gmail and Google's Mail Delivery subsystem, but no device caught the phishing emails from Gmail; the messages were only identified as spam when sent from Google's SMTP. 

Despite not all phishing texts and emails being caught, once malicious links were opened on the devices, those that use Google Safe Browsing protections successfully blocked the link from opening. A warning screen was raised, forcing the user to bypass it to proceed.

Yet not all Android devices performed similarly: Samsung Internet blocked most links except the more sophisticated custom URLs, while the Xiaomi Mii and OnePlus Internet browsers failed to warn the user even when loading known malicious links. 

In previous years' testing, smartphones have been able to detect and successfully block or warn against the attempted phish. However, the difference year-on-year showcases the ever-changing nature of threats.

**Lack of Mobile Security Impacts Consumer Trust**

The lack of effective security protections on mobile devices, particularly against the growing threat of phishing attacks, is eroding consumer trust.

When Omdia asked consumers if their trust following a security issue increased (due to how well the issue was handled) or decreased, 73% reported they had reduced trust in the smartphone brand and operating system developer. 

Despite some manufacturers' efforts to ensure the latest mobile device security protections are in place, Omdia notes that it is difficult to protect against 100% of phishing attempts. This highlights the severity of the issue and potential impact to consumers.

That said, Omdia asserts that smartphone manufacturers can (demonstrated by the more advanced phishing protection capabilities on the market) and should have more effective baseline phishing protection in place — such as voice call protection, and all Android devices making use of Google’s Safe Browsing protections. 

Omdia sees the value in the phishing protection features implemented by the leading smartphone vendors, and how this can help to protect consumers — at least in most instances, based on Omdia's latest round of testing.

However, these features need to be paired with awareness activity from manufacturers, as well as the wider industry, to help consumers be vigilant and prepared for the instance when a security threat evades a protection mechanism. Such awareness adds an important additional layer of protection against the rising number of scams targeting consumers through their mobile devices.

**About the Authors**

Principal Analyst, IoT Cybersecurity, Omdia

Hollie works as a Principal Analyst within the Omdia team, providing insight into the fascinating and fast-moving domain of IoT Cybersecurity.

Hollie has a range of experience in research. She began her career in the legal sector, writing and researching for expert witness reports on the labour market. She then moved into product testing, with a consumer protection focus. In this role she was responsible for managing comparative tests of various tech products, as well as regular testing and investigative work into the security of these products.

She has published various articles for Which?, the UK's largest consumer organisation and one of the largest subscription magazines, and Computing magazine.

Senior Analyst, Smartphones, Omdia

Aaron West provides expertise and analysis of the smartphone market, joining Omdia in 2022. His areas of reporting include the active smartphone installed base, eSIM development, mmWave 5G, sustainability, and the foldable smartphone market.

Aaron has a range of research and publishing experience. He graduated with a degree in theoretical physics before moving into consumer product testing, with a focus on sustainability and the environment.

In this role, he was responsible for research project management, including comparative testing of technology products and consumer surveys. He also reported on the energy efficiency and longevity of home appliances, as well as the product lifecycle and obsolescence of smartphones.

Phishing Attacks Are the Most Common Smartphone Security Issue for Consumers

Security researcher discovers a non-password-protected database containing over 240,000 records belonging to US-based FinTech bill payment platform Willow…

Security researcher discovers a non-password-protected database containing over 240,000 records belonging to US-based FinTech bill payment platform Willow Pays. The exposed data includes names, emails, credit limits, and internal billing details.

Cybersecurity researcher Jeremiah Fowler recently discovered and reported a publicly accessible database containing over 240,000 records belonging to Willow Pays, a bill payment software company based in Chicago, IL. This database, lacking any password protection or encryption, contained sensitive information such as user names, email addresses, credit limits, and internal billing details.

For your information, Willow Pays is a service that allows users to finance bills and other expenses over four weeks. Customers upload their bills and personal information, and Willow Pays approves or denies the request before facilitating payments.

According to Fowler’s investigation published by Website Planet, this publicly exposed database contained 241,970 records, including “bills, mailing lists, account inconsistencies, repayment schedules, screenshots, settings, and snapshots,” the report read.

The records included names, email addresses, credit limits, and other internal information and a single spreadsheet document contained around 56,864 individuals’ details, who could be active customers, prospects, or blocked accounts.

The extent of any actual data compromise is yet unknown, however, Fowler believes that the exposed information could be exploited by criminals. This could include phishing attacks leveraging real billing data to deceive users, or using the information to gain unauthorized access to other accounts.

Fowler sent a responsible disclosure notice to Willow Pays, which promptly restricted the database from public access. The owner or management of the database is unknown, and the duration of exposure before discovery or if anyone else gained access is unknown.  

This incident highlights the increasing threat of cyberattacks on financial institutions, with Verizon reporting that 95% of data breaches are now financially motivated. Hackread.com recently reported that Czech cybersecurity startup Wultra has raised €3 million to develop post-quantum authentication technology to protect banks and fintech against quantum threats. The investment comes amid this growing global concern over the vulnerability of traditional security methods.

Given the persistent nature of this threat, security experts emphasize the need for financial software providers to implement effective cybersecurity measures, including encrypting sensitive data, regular security audits, and adopting multi-factor authentication. To stay protected from financial fraud online, check out this fraud prevention guide from Hackread.com.

1.  **Israeli fintech firms hit by Cardinal RAT malware**
2.  **Fuel Industry Software Provider Exposes SSNs, PII Data**
3.  **Hackers Exploit Revolut’s Payment System, Stealing $20M**
4.  **Builder.ai Database Exposes 1.29 TB of Unsecured Records**
5.  **Millions of US Voter Data Exposed in 13 Misconfigured Databases**

Fintech Bill Pay Platform “Willow Pays” Exposes Over 240,000 Records

Sneaky 2FA: New Phishing-as-a-Service targets Microsoft 365, leveraging sophisticated evasion techniques and a Telegram-based platform to steal credentials.…

Sneaky 2FA: New Phishing-as-a-Service targets Microsoft 365, leveraging sophisticated evasion techniques and a Telegram-based platform to steal credentials.

In December 2024, during routine threat hunting activities, Sekoia.io uncovered a new Adversary-in-the-Middle (AiTM) phishing kit specifically targeting Microsoft 365 accounts. This phishing kit, dubbed Sneaky 2FA, has been circulating since at least October 2024, with potential compromises identified through Sekoia.io telemetry.

Further probing revealed that Sneaky 2FA is being offered as a Phishing-as-a-Service (PhaaS) by the cybercrime service “Sneaky Log,” which operates through a fully-featured bot on Telegram.

The modus operandi of the entire campaign includes customers receiving access to a licensed and obfuscated source code version, allowing them to independently deploy phishing pages, typically hosted on compromised infrastructure, frequently involving WordPress websites and other domains controlled by the attackers.

Sneaky 2FA’s on Telegram and blurred background images that it uses (Via Sekoia)

In addition, the Sneaky 2FA phishing kit incorporates elements from the W3LL Panel OV6, another AiTM phishing kit previously reported by Group-IB. This connection suggests a possible lineage and development within the cybercriminal infrastructure.

****Characteristics of Sneaky 2FA****

According to Sekoia’s report, the Sneaky 2FA phishing kit employs several techniques to evade detection and enhance its success. It utilizes URL patterns, such as “mysilverfox.commy/00/#victimexamplecom,” to automatically prefill the phishing page with the victim’s email address.

These phishing URLs are generated using 150 alphanumeric characters, followed by the path /index, /verify, and /validate. This pattern offers opportunities for tracking. Most customers deploy the server in a dedicated repository, named /auth/ by default.

To further enhance its stealth, Sneaky 2FA integrates anti-bot and anti-analysis features. Cloudflare Turnstile pages are employed to differentiate human users from bots. These pages often present seemingly benign content before loading the actual challenge. Additionally, the phishing kit incorporates anti-debugging techniques to hinder analysis using web browser developer tools.  

The phishing pages themselves utilize a variety of obfuscation methods, including HTML and JavaScript code obfuscation, the embedding of text as images, and the inclusion of junk data within the HTML code. These techniques aim to make phishing pages more difficult to detect by security tools.

****Sneaky Log’s Operations****

The Sneaky Log service operates through a sophisticated Telegram bot that allows customers to purchase the phishing kit, manage subscriptions, and receive support. The bot offers a user-friendly interface and supports multiple cryptocurrency payment options, including Bitcoin, Ethereum, and Tether.  

Analysis of cryptocurrency transactions revealed potential money laundering activities, with users instructed to pay a 10% premium and subsequent transfers occurring between various addresses.

****Detection and Tracking Opportunities****

Detecting Sneaky 2FA attacks can be achieved by analysing authentication logs for anomalies. The phishing kit utilizes inconsistent User-Agent strings for different stages of the authentication process, which can be identified as “impossible device shifts” and flagged as suspicious activity.  Furthermore, the analysis of phishing page URLs, including patterns and domain registrations, can help track and identify campaigns associated with Sneaky 2FA.

Sneaky 2FA is a growing threat in Microsoft 365 phishing attacks, offering sophisticated features and a user-friendly PhaaS platform. To mitigate risks, organizations must continuously monitor and share threat intelligence apart from improving cybersecurity measures.

Stephen Kowski, Field CTO at Pleasanton, Calif.-based SlashNext Email Security+ commented on this urging Microsoft 365 to remain alert. _“_This kit’s ‘sneaky’ aspects include its sophisticated ability to populate victim email addresses automatically, its evasion of detection through Cloudflare Turnstile challenges, and its clever redirection of security tools to Wikipedia pages._“_

_“_The kit is a full-featured PhaaS platform with real-time credential and session cookie theft capabilities, making it particularly dangerous for Microsoft 365 environments,_“_ Stephen warned. _“_Protection requires phishing-resistant authentication methods like FIDO2/WebAuthn, real-time URL scanning at the time of click that completely bypasses Cloudflare Turnstile protection and proactive detection of newly registered phishing domains before they become active threats._“_

1.  **Malware Bypasses MS Defender, 2FA to Steal $24K in Crypto**
2.  **Rockstar 2FA Phishing-as-a-Service Kit Hits MS 365 Accounts**
3.  **Dark Web Anti-Bot Services Let Phishers Bypass Google’s Red Page**
4.  **New Telekopye Scam Toolkit Targeting Booking.com and Airbnb Users**
5.  **Malware Exploits Avast Anti-Rootkit Driver to Disable Security Software**

Telegram-Based “Sneaky 2FA” Phishing Kit Targets Microsoft 365 Accounts

Confidential Containers (CoCo) are containers deployed within an isolated hardware enclave protecting data and code (data in use) from privileged users such as cloud administrators. Red Hat OpenShift confidential containers are available from OpenShift sandboxed containers 1.7.0 as a tech-preview on Azure cloud and as a tech-preview on Azure Red Hat OpenShift.In this article we introduce confidential containers on bare metal which is now available as a preview using Assisted Installer for OpenShift. We cover a number of use cases for CoCo bare metal, explain how it works with different trusted

Confidential Containers **(CoCo)** are containers deployed within an isolated hardware enclave protecting data and code (data in use) from privileged users such as cloud administrators. Red Hat OpenShift confidential containers are available from OpenShift sandboxed containers 1.7.0 as a tech-preview on Azure cloud and as a tech-preview on Azure Red Hat OpenShift.

In this article we introduce confidential **containers on bare metal** which is now available as a preview using Assisted Installer for OpenShift. We cover a number of use cases for CoCo bare metal, explain how it works with different trusted execution environment (TEE) technologies (Intel TDX and AMD SEV-SNP) and third party attestation services such as Intel Trust Authority (ITA). We provide a high level overview of how this solution is deployed today, using an on-premises environment as an example. Additionally we briefly discuss the future roadmap and known issues in this preview release. 

We finish up with a demonstration of deploying CoCo bare metal and using it with Red Hat OpenShift AI.

**OpenShift confidential containers for bare metal **

The OpenShift confidential containers solution is based on deploying 2 operators:

*   OpenShift sandboxed containers operator—based on the Kata Containers open source project running pods inside virtual machines (VMs) for isolation workloads. This operator has been enhanced to also support the CNCF Confidential Containers (CoCo) open source project when deployed in environments that support **TEE** infrastructure such as Intel TDX and AMD SEV-SNP. For simplicity we refer to this operator in diagrams as “**OpenShift confidential containers**.”
*   Confidential compute attestation operator—based on the Trustee project (also part of the CNCF CoCo open source project) providing remote attestation capability. It’s responsible for performing the attestation operations and delivering secrets after successful attestation. A key point for this operator is to be deployed in a **trusted environment**

For additional details on the building blocks each operator consists of, their interaction and the key problems they solve (workload secret, signed container image, encrypted container image), we recommend reading Exploring the OpenShift confidential containers solution and Use cases and ecosystem for OpenShift confidential containers.

In this article our starting point is the following diagram showing the overall OpenShift confidential containers deployed for secrets retrieval by the workload use case: 

CoCo integrates TEE infrastructure with the cloud-native world. A TEE is at the heart of a confidential computing solution. TEEs are isolated environments with enhanced security (e.g. runtime memory encryption, integrity protection), provided by confidential computing-capable hardware. A special **virtual machine (VM)** called a **confidential virtual machine (CVM)** that executes inside the TEE is the foundation for OpenShift CoCo solution.

For CoCo bare metal, our focus is around TEEs provided by Intel TDX and AMD SEV-SNP.

The primary driver for CoCo bare metal solution has been for on-prem environments.

**CoCo bare metal business use cases for on-prem environments**

Whether to use CoCo on-prem or CoCo public cloud depends on the **area of trust to be established:**

*   **Public cloud is useful when a zone of trust between two or more partners in an untrusted area is required**
*   **On-prem is useful when increased isolation from other services is required**— deploying a workload which must be run inside of a company's trusted environment in order to give partners a safe haven. In this case, the company deploying the workload provides the servers and the host systems. Therefore, this environment usually consists of bare metal installations. The purpose here is to provide an extra level of security to either partners or (internal/external) customers within an on-prem datacenter

Let's look at some actual CoCo on-prem business use cases.

**IP protection / IP integrity**

Let's say a supplier is interested in providing a service to a customer. This service includes running workloads in the customer’s environment, and these workloads include proprietary business logic the supplier owns (its secret sauce).

By using confidential containers, the supplier can run its workloads in the customer’s on-prem environment and still protect its business logic from the customer even though the customer has full control of the on-prem environment. And with the use of a confidential container and its use of a CVM allows for further isolation of that workload from the rest of the datacenter infrastructure.

**Total tenant isolation / Service provider**

From talking to several public organizations, we've found that consolidating OpenShift services on a central infrastructure helps solve several problems. This includes reducing the number of administrators and providing dynamic load balancing between the tenants with higher utilization. This does, however, reduce the isolation between the different tenants, which many organizations are not comfortable with. Such organizations require a strict separation between the OpenShift tenants to better prevent data leaks.

With confidential computing we are able to deploy all OpenShift services shared between tenants as confidential objects, helping prevent unauthorized tenants or users from obtaining the confidential data in use. This makes it possible for additional organizations to move to these consolidated services.

Aside from public organizations, specialized service providers (focusing on specific industries such as financial services) are also interested in a similar solution. We have seen use cases where a specialized service provider acts like a public cloud provider for their clients. In order to do this, they need to provide an environment to their customers while maintaining the isolation of each customer and adhering to regulations and laws.

**Advanced use cases**

We are seeing traction on two additional use cases for CoCo on public cloud and CoCo on-prem: **support for confidential GPUs** and **secure cloud-bursting deployments**.

For additional information on those use cases we recommend reading our previous articles on secure cloud bursting and CoCo with confidential GPUs for AI workloads.

**CoCo and third party attestation solutions**

As we are concentrating on deploying the solution in an on-prem bare metal environment, the importance of remote attestation remains. The confidential compute attestation operator provides the remote attestation functionality. It has built-in support for Intel TDX and AMD SEV-SNP TEEs. Additionally, it can work with external third-party attestation services.

**Working with external attestation services**

The confidential compute attestation operator can also use external attestation services (AS) supported by Trustee as shown in the following diagram: 

As you can see, instead of Trustee providing the attestation service, it’s relying on an external attestation service. 

The value that the confidential compute attestation operator brings for such deployments is the abstraction of third-party attestation services from OpenShift confidential containers. The same interfaces are used between the Trustee agent and key broker service (KBS) regardless of the backend attestation service being used.

**Intel Trust Authority for OpenShift attestation **

The Trustee project supports Intel Trust Authority (ITA) providing attestation services for Intel TDX, AMD SEV-SNP and accelerated compute infrastructure such as those provided by NVIDIA. The confidential compute attestation operator now provides support for using ITA in OpenShift clusters: 

The following diagram shows how the different components we’ve described come together when using Intel TDX and ITA: 

It should be noted that similar to Trustee working with external attestation servers, it can work with external key managers as explained in this article. 

**Deploying CoCo bare metal**

The CoCo bare metal deployment relies on the following parts:

*   Assisted Installer for OpenShift—used for deploying OpenShift along with the **OpenShift sandboxed containers (OSC)** operator which includes OpenShift confidential containers support
*   Attestation operator install helper—helper script to install and configure confidential compute attestation operator
*   Confidential container install helper—helper script for setting up CoCo on bare metal OpenShift worker nodes using the OSC operator

**Assisted installer for installing OSC**

Assisted installer for OpenShift is a user-friendly installation solution offered on the Red Hat Hybrid Cloud Console. We leverage it for deploying OSC on bare metal servers. 

The following diagram shows how to choose the OpenShift sandboxed containers operator via Assisted installer:

**Attestation operator install helper**

In the general case, there are a number of deployment considerations that should be addressed when deciding where to deploy the attestation operator:

*   How do you bootstrap, verify and trust the TEE in an untrusted environment?
*   What are the components of your trusted environment?
*   What are the workload (pod) requirements when deployed in the TEE environment?

These questions relate to the topic of **Trusted Computing Base (TCB)** which includes hardware, firmware and software components for the CoCo solution and should be constructed when deploying the OpenShift CoCo solution. For additional details on this topic, we recommend reading Deployment considerations for Red Hat OpenShift Confidential Containers solution.

For simplicity, when testing and experimenting, we recommend installing this operator on the same bare metal deployment where your OpenShift cluster has been installed.

The install helper script takes care of deploying and configuring the confidential compute attestation operator.

**Confidential container install helper**

Once your OSC operator and confidential compute attestation operator have been installed, this script will take care everything else you require, including:

*   Deploying on Intel TDX machines
*   Deploying on AMD SEV-SNP machines
*   Etc

**Future releases and consolidation on assisted installer**

As the CoCo bare metal releases progress, we expect to gradually move all additional steps described here (confidential compute attestation operator and CoCo helper script) into an assisted installer to help simplify deployment.

**Current limitations**

*   Self-signed certificate authority (CA) certificates for the container registry are not supported, so the container registry must use public CA signed certificates. This is important if you are using private registries. Container registries like quay.io, ghcr.io, hub.docker.com, etc. use public CA signed certificates and we recommend using any of these container registries for this release
*   There is no support for encrypted container images while signed container images are supported
*   Container image double pull—the container image is downloaded and executed inside the confidential VM that executes inside the TEE. Currently, this container image is also downloaded on the worker node

**Demo: CoCo bare metal and Red Hat OpenShift AI**

**Wrap up**

In this article we introduced the confidential containers bare metal solution and some of the use cases it addresses, specifically for on-prem environments. We’ve also provided a short overview of how it’s deployed in practice and have shown a video of using the CoCo bare metal for deploying OpenShift AI workloads. In upcoming articles we will provide hands-on instructions for trying out confidential containers on bare metal.

Tag

#auth