Sophos noted more than 15 attacks have been reported during the past three months.

Source: True Images via Alamy Stock Photo

NEWS BRIEF

Sophos X-Ops' Managed Detection and Response (MDR) is warning of ransomware attacks using email bombing as well as imitating tech support, otherwise known as vishing, through Microsoft Office 365.

These attacks are tied to two separate threat groups, which Microsoft began investigating in response to customer incidents in November and December 2024. The threat groups are tracked as STAC5143 and STAC5777.

STAC5777 overlaps with a group previously identified by Microsoft as Storm-1811, while STAC5143 is using tactics from an old Storm-1811 playbook.

According to Sophos MDR, there have been more than 15 incidents involving these tactics in the past three months, half of them occurring just in the last two weeks.

These tactics include using Microsoft remote control tools like Quick Assist or Teams screen sharing. From there attackers take control of a victim's device and install malware, sending Teams messages or making Teams calls from a threat actor-controlled Office 365 impersonating tech support. They also send large volumes of spam emails to overwhelm Outlook mailboxes, a strategy known as email bombing.

"We believe with high confidence that both sets of adversarial activity are parts of ransomware and data theft extortion efforts," said the Sophos researchers in their report. 

The ransomware deployed by these two groups include Black Basta and Python ransomware; the researchers note that STAC5777 in particular is highly active.

Though Sophos has deployed detections for the malware included in these campaigns, it recommends organizations take further steps to prevent attacks, such as ensuring their Microsoft 365 services restrict Teams calls from outside organizations, as well as raise employee awareness of these tactics, which are not normally covered in anti-phishing trainings.

Sophos provided a list of indicators of compromise for these campaigns available for viewing on its GitHub repository.

**About the Author**

Skilled writer and editor covering cybersecurity for Dark Reading.

Email Bombing, 'Vishing' Tactics Abound in Microsoft 365 Attacks

Two separate campaigns are targeting flaws in various IoT devices globally, with the goal of compromising them and propagating malware worldwide.

Source: Aleksey Funtap via Alamy Stock Photo

Separate spinoffs of the infamous Mirai botnet are responsible for a fresh wave of distributed denial-of-service (DDoS) attacks globally. One is exploiting specific vulnerabilities in Internet of Things (IoT) devices to establish "expansive" botnet networks, while the other has been targeting organizations in North America, Europe, and Asia with DDoS attacks since the end of 2024, researchers have found.

An ongoing operation within Mirai dubbed "Murdoc\_Botnet" (which began in July and has more than 1,300 active IPs) is targeting Avtech cameras and Huawei HG532 routers, researchers from Qualys revealed in a report posted today.

The researchers uncovered more than 100 distinct sets of servers associated with the Murdoc botnet, "each tasked with deciphering its activities and establishing communication with one of the compromised IPs implicated in this ongoing campaign," Qualys lead security researcher Shilpesh Trivedi wrote in the post.

Meanwhile, a botnet that comprises malware variants derived from both Mirai and Bashlite is exploiting security flaws and weak credentials in IoT devices in DDoS attacks spanning the globe, according to separate research from Trend Micro. "The malware infiltrates the device by exploiting RCE vulnerabilities or weak passwords, then executes a download script on the infected host," the researchers said.

Related:Email Bombing, 'Vishing' Tactics Abound in Microsoft 365 Attacks

The two campaigns demonstrate the ongoing impact of Mirai, a botnet that has spawned myriad variants since its source code was leaked in 2016 and which remains a significant security threat 10+ years after first appearing on the cyberattack scene.

**Murdoc Botnet Exploits Specific Flaws**

The Murdoc botnet delivering Mirai malware uses existing exploits, including CVE-2024-7029 and CVE-2017-17215, to download next-stage payloads. The former is an Avtech camera flaw that allows for commands to be injected over the network and executed without authentication, while the latter is a remote code execution (RCE) flaw found in Huawei routers.

Most of the IP addresses associated with the Murdoc botnet campaign are found in Malaysia, followed by Thailand, Mexico, and Indonesia.

Qualys researchers discovered more than 500 samples containing ELF files and shell script files associated with the Murdoc botnet. Each shell script "is loaded onto devices such as IP cameras, Network devices, and IoT devices, and, in turn, the C2 server loads the new variant of Mirai botnet, i.e., Murdoc\_Botnet, into the devices," Trivedi wrote in the post.

**An Expansive DDoS Campaign Targets US**

Related:DONOT Group Deploys Malicious Android Apps in India

Meanwhile, researchers at Trend Micro initially detected "large-scale" DDoS botnet attacks against Japanese organizations, including major corporations and banks, starting at the end of 2024, but then tracked the activity to a larger global campaign. Organizations in the US were most affected by the attacks, followed by companies in Bahrain, Poland, and Spain, among various other countries.

The primary devices targeted in the attacks have been wireless routers and IP cameras from well-known brands, including TP-Link and Zyxel routers, and Hikvision IP cameras. As with the Murdoc botnet activity, cyberattackers here targeted flaws in the devices to compromise them, but they also used weak passwords to gain access.

In terms of attack vector, the researchers found two different types of DDoS attacks related to the activity, they said. One type overloads the network by sending a large number of packets, while the other exhausts server resources by establishing a large number of sessions.

"In addition, we observed two or more commands used in combination, making it possible that both network overload attacks and server resource exhaustion attacks occur simultaneously," according to the post.

**How to Defend Against DDoS Cyberattacks**

Related:Russian APT Phishes Kazakh Gov't for Strategic Intel

With Mirai variants continuing to spawn new botnets for mounting new and widespread DDoS attacks, it's important that organizations can identify and protect their networks from floods of unwanted traffic, the researchers said.

Qualys researchers recommended that organizations regularly monitor the suspicious processes, events, and network traffic spawned by the execution of any untrusted binary/scripts, as well as exercise caution in executing shell scripts from unknown and untrusted sources.

Meanwhile, Trend Micro analysts recommended different mitigation efforts for the two types of DDoS attacks that they observed. For attacks that flood the network with packets, the researchers recommended organizations use a firewall or router to block specific IP addresses or protocols and restrict traffic; collaborate with communication service providers to filter DDoS traffic at the backbone or edge of the network; and strengthen router hardware to increase the number of packets that can be processed.

For attacks that exhaust resources by establishing a large number of sessions, Trend Micro recommended that organizations limit the number of requests that can be sent by a specific IP address within a certain period of time; use third-party services to separate attack traffic and process clean traffic; and perform real-time monitoring and block IP addresses with a high number of connections, among other mitigations and preventions.

**About the Author**

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Mirai Botnet Spinoffs Unleash Global Wave of DDoS Attacks

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) 

I have finalized the list of trending vulnerabilities for 2024 according to Positive Technologies. Last year, 74 vulnerabilities were classified as trending (to compare the scale, just over 40,000 were added to NVD in 2024). All trending vulnerabilities are found in Western commercial products and open source projects. This year, the vulnerabilities of domestic Russian […]

**I have finalized the list of trending vulnerabilities for 2024 according to Positive Technologies.** Last year, 74 vulnerabilities were classified as trending (to compare the scale, just over 40,000 were added to NVD in 2024).

All trending vulnerabilities are found in Western commercial products and open source projects. This year, the vulnerabilities of domestic Russian products did not reach the level of criticality required to classify them as trending.

For 55 of all trending vulnerabilities there are currently signs of exploitation in attacks, for 17 there are public exploits (but no signs of exploitation) and for the remaining 2 there is only a possibility of future exploitation.

Vulnerabilities were often added to trending ones before signs of exploitation in the wild appeared. For example, the remote code execution vulnerability in VMware vCenter (CVE-2024-38812) was added to the list of trending vulnerabilities on September 20, 3 days after the vendor’s security bulletin appeared. There were no signs of exploitation in the wild or public exploit for this vulnerability. Signs of exploitation appeared only 2 months later, on November 18.

Most of the vulnerabilities in the trending list are of the following types: Remote Code or Command Execution (24) and Elevation of Privilege (21).

4 vulnerabilities in Barracuda Email Security Gateway (CVE-2023-2868), MOVEit Transfer (CVE-2023-34362), papercut (CVE-2023-27350) and SugarCRM (CVE-2023-22952) were added in early January 2024. These vulnerabilities were massively exploited in the West in 2023, and attacks using these vulnerabilities could also tangentially affect those domestic Russian organizations where these products had not yet been taken out of service. The rest of the vulnerabilities became trending in 2024.

34 trending vulnerabilities affect Microsoft products (45%).

🔹 17 of them are Elevation of Privilege vulnerabilities in the Windows kernel and standard components.

🔹 1 Remote Code Execution vulnerability in Windows Remote Desktop Licensing Service (CVE-2024-38077).

2 trending Elevation of Privilege vulnerabilities affect Linux systems: one in nftables (CVE-2024-1086), and the second in needrestart (CVE-2024-48990).

**Other groups of vulnerabilities**

🔻 Phishing attacks: 19 (Windows components, Outlook, Exchange, Ghostscript, Roundcube)  
🔻 Network security and entry points: 13 (Palo Alto, Fortinet, Juniper, Ivanti, Check Point, Zyxel)  
🔻 Virtual infrastructure and backups: 7 (VMware, Veeam, Acronis)  
🔻 Software development: 6 (GitLab, TeamCity, Jenkins, PHP, Fluent Bit, Apache Struts)  
🔻 Collaboration tools: 3 (Atlassian Confluence, XWiki)  
🔻 CMS WordPress plugins: 3 (LiteSpeed Cache, The Events Calendar, Hunk Companion)

🗒 Full Vulristics report

🟥 Article on the official website “Vulnerable software and hardware vs. security researchers” (rus)

На русском

Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.

А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.

I have finalized the list of trending vulnerabilities for 2024 according to Positive Technologies

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

The propensity for users to enter customer data, source code, employee benefits information, financial data, and more into ChatGPT, Copilot, and others is racking up real risk for enterprises.

Source: Marcos Alvarado via Alamy Stock Photo

A wide spectrum of data is being shared by employees through generative AI (GenAI) tools, researchers have found, legitimizing many organizations' hesitancy to fully adopt AI practices.

Every time a user enters data into a prompt for ChatGPT or a similar tool, the information is ingested into the service's LLM data set as source material used to train the next generation of the algorithm. The concern is that the information could be retrieved at a later date via savvy prompts, a vulnerability, or a hack, if proper data security isn't in place for the service.

That's according to researchers at Harmonic, who analyzed thousands of prompts submitted by users into GenAI platforms such as Microsoft, Copilot, OpenAI ChatGPT, Google Gemini, Anthropic's Clause, and Perplexity. In their research, they discovered that though in many cases employee behavior in using these tools was straightforward, such as wanting to summarize a piece of text, edit a blog, or some other relatively simple task, there were a subset of requests that were much more compromising. In all, 8.5% of the analyzed GenAI prompts included sensitive data, to be exact.

**Customer Data Most Often Leaked to GenAI**

The sensitive data that employees are sharing often falls into one of five categories: customer data, employee data, legal and finance, security, and sensitive code, according to Harmonic.

Customer data holds the biggest share of sensitive data prompts, at 45.77%, according to the researchers. An example of this is when employees submit insurance claims containing customer information into a GenAI platform to save time in processing claims. Though this might be effective in making things more efficient, inputting this kind of private and highly detailed information poses a high risk of exposing customer data such as billing information, customer authentication, customer profile, payment transactions, credit cards, and more.

Employee data makes up 27% of sensitive prompts in Harmonic's study, indicating that GenAI tools are increasingly used for internal processes. This could mean performance reviews, hiring decisions, and even decisions regarding yearly bonuses. Other information that ends up being offered up for potential compromise includes employment records, personally identifiable information (PII), and payroll data.

Legal and finance information is not as frequently exposed, at 14.88%, however, when it is, it can lead to great corporate risk, according to the researchers. Unfortunately, when GenAI is used in these fields, it's for simple tasks such as spell checks, translation, or summarizing legal texts. For something so small, the consequences are incredibly high, risking a variety of data such as sales pipeline details, mergers and acquisition information, and financial data. 

Security information and security code each compose the smallest amount of leaked sensitive data, at 6.88% and 5.64%, respectively. However, though these two groups fall short compared to those previously mentioned, they are some of the fastest growing and most concerning, according to the researchers. Security data inputted into GenAI includes penetration test results, network configurations, backup plans, and more, providing exact guidelines and blueprints as to how bad actors can exploit vulnerabilities and take advantage of their victims. Code inputted into these tools could put technology companies at a competitive disadvantage, exposing vulnerabilities and allowing competitors to replicate unique functionalities.

**Balancing GenAI Cyber-Risk & Reward**

If the research shows that GenAI offers high-risk potential consequences, should businesses continue to use it? Experts say they might not have a choice.

"Organizations risk losing their competitive edge of if they expose sensitive data," said the researchers in the report. "Yet at the same time, they also risk losing out if they don't adopt GenAI and fall behind."

Stephen Kowski, field chief technology officer (CTO) at SlashNext Email Security+, agrees. "Companies that don’t adopt generative AI risk losing significant competitive advantages in efficiency, productivity, and innovation as the technology continues to reshape business operations," he said in an emailed statement to Dark Reading. "Without GenAI, businesses face higher operational costs and slower decision-making processes, while their competitors leverage AI to automate tasks, gain deeper customer insights, and accelerate product development."

Others, however, disagree that GenAI is necessary, or that an organization needs any artificial intelligence at all.

"Utilizing AI for the sake of using AI is destined to fail," said Kris Bondi, CEO and co-founder of Mimoto, in an emailed statement to Dark Reading. "Even if it gets fully implemented, if it isn't serving an established need, it will lose support when budgets are eventually cut or reappropriated."

Though Kowski believes that not incorporating GenAI is risky, success can still be achieved, he notes.

"Success without AI is still achievable if a company has a compelling value proposition and strong business model, particularly in sectors like engineering, agriculture, healthcare, or local services where non-AI solutions often have greater impact," he said.

If organizations do want to pursue incorporating GenAI tools but want to mitigate the high risks that come along with it, the researchers at Harmonic have recommendations on how to best approach this. The first is to move beyond "block strategies" and implement effective AI governance, including deploying systems to track input into GenAI tools in real time, identifying what plans are in use and ensuring that employees are using paid plans for their work and not plans that use inputted data to train systems, gaining full visibility over these tools, sensitive data classification, creating and enforcing workflows, and training employees on best practices and risks of responsible GenAI use.

Employees Enter Sensitive Data Into GenAI Prompts Far Too Often

A cybercriminal campaign linked to Russia is deploying QR codes to access the WhatsApp accounts of high-profile targets like journalists, members...

A cybercriminal campaign linked to Russia is deploying QR codes to access the WhatsApp accounts of high-profile targets like journalists, members of think tanks, and employees of non-governmental organizations (NGOs), according to new details revealed by Microsoft.

The group, which Microsoft tracks by the name “Star Blizzard,” is also referred to as Coldriver by other researchers. Last year, the group created impersonation accounts where members posed as experts in a field that their targets might be interested in—or that was somehow affiliated with the target. Once a relationship had been established, the target would receive a phishing link or a document that contained a phishing link.

But over time, that tactic became widely known, and part of the cybercriminals’ infrastructure was taken down. Now, it seems the group has changed tactics and is sending QR codes instead of malicious links to the targets that they have established an initial relationship with.

These QR codes do not take the target to a malicious website, nor will they join them to the promised WhatsApp group on “the latest non-governmental initiatives aimed at supporting Ukraine NGOs,” as is claimed in one of the cybercriminal lures.

In reality, the link in the QR code is intentionally broken. The idea is that the target will respond with a remark about the broken link. When that happens the cybercriminals send out a shortened URL to a website that displays another QR code.

_Screenshot courtesy of Microsoft_

> “I apologize for the inconvenience with the QR code. Kindly try this alternative link: US-Ukraine NGOs Group  
> It should work without any issues.

By scanning this QR code and following the instructions on the website they confirm the addition of an extra device to the WhatsApp account of the target. With that access the group can read the messages in their WhatsApp account and use existing browser plugins, particularly those designed for exporting WhatsApp messages from an account accessed via WhatsApp Web.

**How to stay safe**

These spear phishing campaigns are highly targeted and you’ll probably never see an invite to this group. But cybercriminals tend to copy ideas that work, so you may see them in another form.

There are a few simple rules that will help you avoid this kind of phishing.

*   Always hover over links before clicking them.
*   When you find a shortened URL, think about the possible reason for shortening. Was there a real need to do this or is it just meant to hide the destination?
*   When still in doubt, unshorten the URL.
*   When following instructions on a website, scrutinize whether the prompts on your device actually match the expected ones. WhatsApp will double-check whether you want to add a device to the account.
*   Double-check whether the sender is who they claim to be through another method of contact.

**We don’t just report on phone security—we provide it**

Cybersecurity risks should never spread beyond a headline. Keep threats off your mobile devices by downloading Malwarebytes for iOS, and Malwarebytes for Android today.

 WhatsApp spear phishing campaign uses QR codes to add device 

Cybersecurity researchers have detailed a new adversary-in-the-middle (AitM) phishing kit that's capable of Microsoft 365 accounts with an aim to steal credentials and two-factor authentication (2FA) codes since at least October 2024.
The nascent phishing kit has been dubbed Sneaky 2FA by French cybersecurity company Sekoia, which detected it in the wild in December. Nearly 100 domains hosting

New 'Sneaky 2FA' Phishing Kit Targets Microsoft 365 Accounts with 2FA Code Bypass

Silverfort has discovered that a misconfiguration can bypass an Active Directory Group Policy designed to disable NTLMv1, allowing…

Silverfort has discovered that a misconfiguration can bypass an Active Directory Group Policy designed to disable NTLMv1, allowing NTLMv1 authentications to persist. Microsoft announced the full decommission of NTLMv1 from Windows 2025.

Unified Identity Security company Silverfort has discovered a security vulnerability involving a misconfiguration in Active Directory. This vulnerability allows NTLMv1 authentication to persist despite attempts to disable it through Group Policy.

NTLMv1 is an outdated authentication protocol with known security weaknesses, making it a prime target for attackers. The flaw, discovered by senior security researcher Dor Segal, exposed that even teams implementing this policy remain exposed to NTLMv1 authentications.

The vulnerability arises from a flaw in the implementation of the Group Policy. While the policy aims to block NTLMv1, certain on-premises applications can bypass this restriction by specifically requesting NTLMv1 authentication. This bypass creates a false sense of security for organizations that believe they have effectively disabled NTLMv1. Attackers can exploit this vulnerability to intercept NTLMv1 traffic, crack user credentials, and gain unauthorized system access.

Attackers can exploit NTLMv1’s weaknesses to move laterally or escalate privileges, exposing organizations to significant risk.

 “It is important to note that Windows clients with LMCompatibilityLevel 3 and above will not generate NTLMv1 if requested. However, non-Windows clients are not protected. If an application requests an NTLMv1 message from a non-Windows client, the Domain Controller may approve the authentication and generate a session key,” researchers noted in a blog post.

Silverfort’s research highlights the security weaknesses of NTLMv1, such as its susceptibility to relay attacks and the limitations of the Group Policy mechanism in completely preventing its use. By understanding the technical intricacies of NTLMv1 and the limitations of existing mitigation strategies, organizations can better assess their risk exposure and implement effective security measures.

Although Microsoft has acknowledged the issue and announced plans to completely remove NTLMv1 support in future versions of Windows, organizations still need to take proactive measures to mitigate the risk. These measures include enabling audit logs for NTLM authentication, identifying applications that utilize NTLMv1, and implementing modern authentication methods such as SSO or Kerberos to replace NTLMv1.

1.  NTLM Credential Theft in Python Apps Threaten Windows
2.  Hackers Exploit Jupyter Servers for Illegal Sports Streaming
3.  7-Zip Exploit Code Traced to AI-Generated Misinterpretation
4.  Critical Windows Zero-Day Alert: No Patch Available for Users
5.  Fabrice Malware on PyPI Stealing AWS Credentials for 3 Years

Top/Featured Image via FreePik

Researchers Warn of NTLMv1 Bypass in Active Directory Policy

A highly targeted cyber-intelligence campaign adds fuel to the increasingly complex relationship between the two former Soviet states.

Source: Daniren via Alamy Stock Photo

A suspected Russia-nexus threat actor has been executing convincing spear phishing attacks against diplomatic entities in Kazakhstan.

UAC-0063, active since at least 2021, was first documented by Ukraine's Computer Emergency Response Team (CERT-UA) in 2023. With medium confidence, CERT-UA tied it to APT28 (aka Fancy Bear, Forest Blizzard, Strontium, Sofacy), from the General Staff Main Intelligence Directorate (GRU) Military Unit 26165. APT28 is best known for its high-profile attacks against Western governments: the Democratic National Committee (DNC) hack of 2016, campaigns against parliamentary bodies in Germany, Norway, and the Netherlands, and much more.

UAC-0063, specifically, has used cyber operations to collect intelligence from government entities, nongovernmental organizations (NGOs), academic institutions, and energy and defense organizations in Eastern Europe — most notably Ukraine — as well as Central Asia, including Kazakhstan, Kyrgyzstan, Tajikistan, and other countries in the vicinity, including Israel and India.

Its latest ongoing campaign, which, in a blog post, researchers from Sekoia date back to at least 2022, may fold into a broader effort by Vladimir Putin's government to gain strategic insights into, and advantage over, a former Soviet state that has sought to broaden its diplomatic horizons in recent years.

**Phishing Kazakh Diplomats**

On Oct. 16, 2024 — one month after it'd been deployed in the wild — researchers spotted a diplomatic document uploaded to VirusTotal. It appeared to be a legitimate draft of a joint declaration between the chancellor of Germany and heads of Central Asian countries.

"The first step, when you open this document, is that it asks you to enable macros," recalls Amaury Garçon, cyber threat intelligence (CTI) analyst at Sekoia Threat Detection & Research (TDR), adding that the document was obscured by "shapes" at first sight. "Some phishing documents look really ugly or have a bad shape \[at first\] — they prompt the user to enable macros, because if you don't enable macros you can't write text in the document, can't move images, etc.," he notes.

Clicking "enable" would trigger various malicious, unseen commands on a target device. While the user was made privy to the full, unadulterated lure document, in the background their security settings would be downgraded so as to remove the need for future "enable macros" prompts. Next a second, blank document was created and opened by a hidden instance of Microsoft Word. The Visual Basic (VB) code associated with this hidden document — now enabled by default, of course — dropped and executed a malicious HTML application (HTA) containing a backdoor named "HatVibe."

The purpose of HatVibe is to receive and execute code from a remote server. Though Sekoia couldn't identify the payloads associated with this phishing campaign, CERT-UA has previously observed HatVibe downloading and executing a more complex Python backdoor named "CherrySpy."

**What This Means for Kazakhstan and Russia**

Six weeks after researchers spotted the first VirusTotal upload associated with this campaign, on Nov. 27, Putin went on a two-day state visit to the country he deemed Russia's "true ally," Kazakhstan. He and Kazakhstan's president, Kassym-Jomart Tokayev, used the opportunity afforded by the Collective Security Treaty Organization (CSTO) summit to discuss various areas for economic partnership — particularly around the energy sector — and signed agreements over energy, education, and transportation.

"Central Asia is a real point of interest for Russian influence," Maxime Arquillière, senior CTI analyst at Sekoia TDR explains. "We know that Kazakhstan is a close ally, but since the beginning of the Ukraine war, Kazakhstan has distanced itself a little bit from Russia, trying to develop new connections with both Western states and also China."

Kazakhstan's centrality in the Asian continent positions it nicely as a trade bridge between China and Europe, particularly while Ukraine and Russia are consumed by war. And as Sekoia notes in its blog, the country's gradually broadening geopolitical ties are evident in recent agreements with Mongolia and Afghanistan's new Taliban government, and, most notably, its balanced position on the war in Ukraine — supporting Ukraine's right to territorial integrity without outright condemning Russia's invasion.

This latest cyber campaign, then, fits neatly into Russia's broader initiatives with regard to its Central Asian neighbor. Sekoia identified 11 lure documents in all, each one legitimate and likely having originated with Kazakhstan's Ministry of Foreign Affairs, pertaining to diplomatic business between Kazakhstan and potential partner nations.

Exactly how the threat actor obtained these documents is not known. They include, for example:

*   Letters from Kazakhstan's embassies in Afghanistan and Belgium, regarding diplomatic and economic developments.
    
*   A draft of a joint statement between Germany and Central Asian states, following a Sept. 16, 2024, summit in Astana.
    
*   Administrative reports and briefings on the Kazakh president's visits to Mongolia and New York.
    

"It's really coherent with the \[need for\] Russian intelligence to conduct this kind of cyber espionage, to know about the strategic interests between Kazakhstan and European states," Arquillière says.

**About the Author**

Nate Nelson is a writer based in New York City. He formerly worked as a reporter at Threatpost, and wrote "Malicious Life," an award-winning Top 20 tech podcast on Apple and Spotify. Outside of Dark Reading, he also co-hosts "The Industrial Security Podcast."

Tag

#microsoft