The new administration moved quickly to remove any constraints on AI development and collected $500 billion in investment pledges for an American-owned AI joint venture.

Source: Andrey Popov via Alamy Stock Photo

President Donald Trump revoked former President Joe Biden's 2023 executive order aimed at putting security guardrails around artificial intelligence (AI) systems and their potential impact to national security, giving a major boost to private sector companies like OpenAI, Oracle, and Softbank. They responded in kind with collective pledges to spend up to $600 billion on building out AI infrastructure in the US.

Biden's AI executive order required developers of AI and large language models (LLMs) like ChatGPT to develop safety standards and share results with the federal government to help prevent AI-powered cyberattacks against citizens, critical infrastructure, dangerous biological weapons, and other areas affecting US national security.

**Artificial Intelligence Private Sector Ponies Up**

Fast on the heels of that revocation, the Trump administration unveiled Project Stargate, which is intended to funnel hundreds of billions into AI infrastructure in the US. The Stargate event at the White House was attended by SoftBank CEO Masayoshi Son, who had already pledged $100 billion to the fund. OpenAI CEO Sam Altman and Oracle co-founder Larry Ellison each pledged an initial $100 billion, all of which will be used to set up a separate company committed to US AI infrastructure. Microsoft, Nvidia, and semiconductor company Arm are also involved as technology partners.

During the ceremony, Ellison said there are already data centers in Texas under construction as part of Project Stargate.

Leading AI CEOs, including Marty Sprinzen, CEO of Vantiq, were delighted by the news.

"As I sit here at the World Economic Forum in Davos, Switzerland, the atmosphere is charged with enthusiasm following President Trump's announcement of the Stargate initiative — a collaboration between OpenAI, SoftBank, and Oracle to invest up to $500 billion in artificial intelligence infrastructure," Sprinzen said in a statement.

One outlier with less enthusiasm for Project Stargate is Elon Musk, who claimed the companies don't have the cash to cover the pledges.

**Trump Administration's AI Cybersecurity Plan**

It's still not completely clear this means if or how there will be any federal oversight of AI technology or its development.

The Biden AI executive order was far from perfect, according to Max Shier, CISO at Optiv, but he still would like to see some federal oversight of AI development.

"I don't disagree with the reversal per se, as I don't think the EO that Biden signed was adequate and it had its flaws," Shier says. "However, I would hope that they replace it with one that levies more appropriate controls on the industry that are not as overbearing as the previous EO and still allows for innovation."

Shier anticipates standards developed by the National Institute for Standards and Technology (NIST) and the International Organization for Standardization (ISO) will help "provide guardrails for ethical and responsible use."

For now, the new administration is ready to leave the task of developing AI with adequate safety controls in private sector hands. Adam Kentosh at Digital.ai says he is confident they are up to the task.

"The rapid pace of AI development makes it essential to strike a balance between innovation and security. While this balance is critical, the responsibility likely falls more on individual corporations than on the federal government to ensure that industries adopt thoughtful, secure practices in AI development," Kentosh says. "By doing so, we can avoid a scenario where government intervention becomes necessary."

That might not be enough, according to Shier.

"Private enterprise should not be allowed to govern themselves or be trusted to develop under their own standards for ethical use," he stresses. "There has to be guardrails provided that don't stifle smaller companies from participating in innovation but still allow for some oversight and accountability. This is especially true in instances where public safety or national security is at risk or has the potential to cause risk."

**About the Author**

Dark Reading

Becky Bracken is a veteran multimedia journalist covering cybersecurity for Dark Reading.

Trump Overturns Biden Rules on AI Development, Security

The payment card giant MasterCard just fixed a glaring error in its domain name server settings that could have allowed anyone to intercept or divert Internet traffic for the company by registering an unused domain name. The misconfiguration persisted for nearly five years until a security researcher spent $300 to register the domain and prevent it from being grabbed by cybercriminals.

The payment card giant **MasterCard** just fixed a glaring error in its domain name server settings that could have allowed anyone to intercept or divert Internet traffic for the company by registering an unused domain name. The misconfiguration persisted for nearly five years until a security researcher spent $300 to register the domain and prevent it from being grabbed by cybercriminals.

A DNS lookup on the domain az.mastercard.com on Jan. 14, 2025 shows the mistyped domain name a22-65.akam.ne.

From June 30, 2020 until January 14, 2025, one of the core Internet servers that MasterCard uses to direct traffic for portions of the mastercard.com network was misnamed. MasterCard.com relies on five shared Domain Name System (DNS) servers at the Internet infrastructure provider **Akamai** \[DNS acts as a kind of Internet phone book, by translating website names to numeric Internet addresses that are easier for computers to manage\].

All of the Akamai DNS server names that MasterCard uses are supposed to end in “akam.net” but one of them was misconfigured to rely on the domain “**akam.ne**.”

This tiny but potentially critical typo was discovered recently by **Philippe Caturegli**, founder of the security consultancy Seralys. Caturegli said he guessed that nobody had yet registered the domain akam.ne, which is under the purview of the top-level domain authority for the West Africa nation of Niger.

Caturegli said it took $300 and nearly three months of waiting to secure the domain with the registry in Niger. After enabling a DNS server on akam.ne, he noticed hundreds of thousands of DNS requests hitting his server each day from locations around the globe. Apparently, MasterCard wasn’t the only organization that had fat-fingered a DNS entry to include “akam.ne,” but they were by far the largest.

Had he enabled an email server on his new domain akam.ne, Caturegli likely would have received wayward emails directed toward mastercard.com or other affected domains. If he’d abused his access, he probably could have obtained website encryption certificates (SSL/TLS certs) that were authorized to accept and relay web traffic for affected websites. He may even have been able to passively receive Microsoft Windows authentication credentials from employee computers at affected companies.

But the researcher said he didn’t attempt to do any of that. Instead, he alerted MasterCard that the domain was theirs if they wanted it, copying this author on his notifications. A few hours later, MasterCard acknowledged the mistake, but said there was never any real threat to the security of its operations.

“We have looked into the matter and there was not a risk to our systems,” a MasterCard spokesperson wrote. “This typo has now been corrected.”

Meanwhile, Caturegli received a request submitted through **Bugcrowd**, a program that offers financial rewards and recognition to security researchers who find flaws and work privately with the affected vendor to fix them. The message suggested his public disclosure of the MasterCard DNS error via a post on LinkedIn (after he’d secured the akam.ne domain) was not aligned with ethical security practices, and passed on a request from MasterCard to have the post removed.

MasterCard’s request to Caturegli, a.k.a. “Titon” on infosec.exchange.

Caturegli said while he does have an account on Bugcrowd, he has never submitted anything through the Bugcrowd program, and that he reported this issue directly to MasterCard.

“I did not disclose this issue through Bugcrowd,” Caturegli wrote in reply. “Before making any public disclosure, I ensured that the affected domain was registered to prevent exploitation, mitigating any risk to MasterCard or its customers. This action, which we took at our own expense, demonstrates our commitment to ethical security practices and responsible disclosure.”

Most organizations have at least two authoritative domain name servers, but some handle so many DNS requests that they need to spread the load over additional DNS server domains. In MasterCard’s case, that number is five, so it stands to reason that if an attacker managed to seize control over just one of those domains they would only be able to see about one-fifth of the overall DNS requests coming in.

But Caturegli said the reality is that many Internet users are relying at least to some degree on public traffic forwarders or DNS resolvers like **Cloudflare** and **Google**.

“So all we need is for one of these resolvers to query our name server and cache the result,” Caturegli said. By setting their DNS server records with a long TTL or “Time To Live” — a setting that can adjust the lifespan of data packets on a network — an attacker’s poisoned instructions for the target domain can be propagated by large cloud providers.

“With a long TTL, we may reroute a LOT more than just 1/5 of the traffic,” he said.

The researcher said he’d hoped that the credit card giant might thank him, or at least offer to cover the cost of buying the domain.

“We obviously disagree with this assessment,” Caturegli wrote in a follow-up post on LinkedIn regarding MasterCard’s public statement. “But we’ll let you judge— here are some of the DNS lookups we recorded before reporting the issue.”

Caturegli posted this screenshot of MasterCard domains that were potentially at risk from the misconfigured domain.

As the screenshot above shows, the misconfigured DNS server Caturegli found involved the MasterCard subdomain **az.mastercard.com**. It is not clear exactly how this subdomain is used by MasterCard, however their naming conventions suggest the domains correspond to production servers at Microsoft’s **Azure** cloud service. Caturegli said the domains all resolve to Internet addresses at Microsoft.

“Don’t be like Mastercard,” Caturegli concluded in his LinkedIn post. “Don’t dismiss risk, and don’t let your marketing team handle security disclosures.”

One final note: The domain akam.ne has been registered previously — in December 2016 by someone using the email address um-i-delo@yandex.ru. The Russian search giant Yandex reports this user account belongs to an “Ivan I.” from Moscow. Passive DNS records from DomainTools.com show that between 2016 and 2018 the domain was connected to an Internet server in Germany, and that the domain was left to expire in 2018.

This is interesting given a comment on Caturegli’s LinkedIn post from an ex-Cloudflare employee who linked to a report he co-authored on a similar typo domain apparently registered in 2017 for organizations that may have mistyped their AWS DNS server as “**awsdns-06.ne**” instead of “**awsdns-06.net**.” DomainTools reports that this typo domain also was registered to a Yandex user (playlotto@yandex.ru), and was hosted at the same German ISP — Team Internet (AS61969).

MasterCard DNS Error Went Unnoticed for Years

The flurry of non-human identity attacks at the end of 2024 demonstrates extremely strong momentum heading into the new year. That does not bode well.

Itzik Alvas, Co-Founder & CEO, Entro Security

January 22, 2025

3 Min Read

Source: Brain light via Alamy Stock Photo

COMMENTARY

A look back at 2024's top non-human identity (NHI) attacks and their year-end explosion sends a worrying signal that 2025 is going to be a tough year for machine-to-machine identity theft.

One year ago, NHI burst onto the scene with a big warning flare, when Cloudflare disclosed that NHI mismanagement caused a massive breach, stemming from the failure to rotate an access token and account credentials exposed in the 2023 Okta compromise. 

While the attack was contained, the impact on Cloudflare was nonetheless significant. The company disclosed it had to rotate every production credential (more than 5,000 individual credentials), physically segment test and staging systems, perform forensic triages on 4,893 systems, and then reimage and reboot every machine in its global network.

As the year progressed, NHI breaches gained momentum.

In June, the New York Times made its own news when 270GB of its internal data and applications in 5,000 repositories were stolen from GitHub and published on the Web. 

How? The breach was executed using NHI when an exposed GitHub Personal Access Token, a machine-to-machine secret, allowed unauthorized access to the company's code repositories. The "All the News That's Fit to Print" outlet downplayed the story. Cybersecurity experts did not agree, however, arguing that source-code leaks can have wide-ranging implications.

**High-Profile Breach Disclosures**

The year ended with a spate of high-profile breach disclosures attributed to NHI during the fourth quarter. 

Thousands of online stores running Adobe Commerce (formerly Magento) software were hacked and infected with digital payment skimmers. The NHI attack used stolen cryptographic keys to generate an application programming interface (API) authorization token, enabling the attacker to access private customer data and insert payment skimmers into the checkout process.

AWS and Microsoft Azure machine-to-machine authentication keys found in Android and iOS apps used by millions were compromised, exposing user data and source code to security breaches. Exposing this type of credential can easily lead to unauthorized access to storage buckets and databases with sensitive user data. Apart from this, attackers could use them to manipulate or steal data.

Schneider Electric confirmed its development platform was breached after a hacker used exposed Jira credentials to steal data. The hacker gloated that the breach compromised critical data, including projects, issues and plug-ins, along with over 400,000 rows of user data, totaling more than 40GB of compressed data,

The Cybersecurity and Infrastructure Security Agency (CISA) warned that attackers were exploiting a critical missing authentication vulnerability in Palo Alto Networks Expedition, a migration tool that can help convert firewall configuration from Checkpoint, Cisco, and other vendors to PAN-OS. This security flaw enabled threat actors to remotely exploit it to reset application admin credentials on Internet-exposed Expedition servers.

A new sophisticated phishing tool targeting GitHub users was also revealed in the fourth quarter. It posed a significant threat to developers and organizations worldwide. Here's how this relates to NHIs: Bots used a compromised secret and set of permissions associated with that credential as the ingredients to make the API calls and create comments using a script.

The comments themselves convinced developers to use insecure scripts as validated solutions.

These scripts, in turn, could lead victims to phishing pages designed to steal login credentials, malware downloads, or rogue OAuth app authorization prompts granting attackers access to private repositories and data.

Finally, and bringing the year to a dramatic close, NHI was responsible for the US Treasury hack by Chinese threat actors, who gained access to "unclassified documents" after compromising the agency's networks. The attackers were able to exploit vulnerabilities in remote tech support software by misusing a leaked API key to gain unauthorized access.

The flurry of NHI attacks at the end of the year demonstrates extremely strong momentum heading into 2025. That does not bode well. 

Chief information security officers (CISOs) and security teams need to prioritize the emerging NHI threats roaring into the new year.

**About the Author**

Co-Founder & CEO, Entro Security

Itzik Alvas is co-founder and CEO at Entro Security and former healthcare organization CISO and information technology manager at Microsoft.

A cloud and security expert with more than 17 years of experience managing and building teams of hundreds of employees for both leading global enterprise companies and early-stage startups, always at the forefront of state-of-art security solutions used by governments, top intelligence agencies, data centers, cloud providers and industrial markets. Itzik served with the IDF's elite intelligence unit.

Will 2025 See a Rise of NHI Attacks?

Despite lagging in technology adoption, African and Middle Eastern organizations are catching up, driven by smartphone acceptance and national identity systems.

Source: Ground Picture via Shutterstock

National governments and companies in the Middle East and Africa continue to push for more widely available digital identity systems to allow citizens to connect and authenticate to digital government services and commercial services.

In Morocco, the government issued more than 4.6 million electronic identity cards in 2024 and expanded its digital infrastructure with a trusted third-party authentication platform in an effort to offer new services and cut cybercrime rates. More than 7.2 million people are now enrolled in the United Arab Emirates' official digital ID, known as UAE Pass, and can authenticate to websites. And the National Bank of Egypt has adopted a single sign-on infrastructure that will allow its employees to use a variety of authentication methods, and which will eventually be rolled out to its millions of customers.

The increasing use of multifactor authentication, especially efforts tied to smartphones or biometrics, have had success in the region because — in many cases — organizations have no technical debt to overcome, says Jim Sullivan, senior vice president of strategy and compliance at BIO-Key, which provided the technology for the National Bank of Egypt, as well as the largest bank in South Africa and the government of Nigeria.

"These are greenfield opportunities — it's tremendous," he says. "There's national initiatives that are well funded that are really bringing more biometrics to the fore, more awareness of the power of this technology."

Better authentication and the use of biometrics has taken off in the Middle East and Africa due to government concerns over cybercrime and fraud and international concerns over the lack of legal identities for more than 540 million people in the region. In Africa, cyber-risk is the No. 1 concern among businesses leaders, with 61% aiming to mitigate the threat in 2025, according to PwC's "2025 Digital Trust Insights: South Africa and Africa" report. In the Middle East, cyber-risk has fallen to the second greatest concern, behind digital and technology risks and tied with inflation and macroeconomic volatility, with 42% of organizations making mitigation of the cyber risks a priority, according to PwC's "2025 Digital Trust Insights: Middle East" report.

Despite that, only 19% of companies in Africa and 12% of companies in the Middle East are prioritizing investments in identity and access management (IAM) technologies, according to the PwC reports. Most companies are prioritizing the acquisition of data protection technologies, generative AI systems, and network security in the region, with the Middle East also prioritizing the addition of cyber insurance for the business.

**Biometrics Embraced by Mideast, African Markets**

A shift to biometrics, however, could change that. The significant reliance of smartphones for Internet access and digital transactions is leading many governments and organizations to adopt biometric-based identity systems and to use biometrics as a second factor of authentication for digital services.

Digital identity platforms, such as UAE Pass in the United Arab Emirates and Nafath in Saudi Arabia, integrate with existing fingerprint and facial-recognition systems and can reduce the reliance on passwords, says Chris Murphy, a managing director with the cybersecurity practice at FTI Consulting in Dubai.

"With mobile devices serving as the primary gateway to digital services, smartphone-based biometric authentication is the most widely used method in public and private sectors," he says. "Some countries, such as the UAE and Saudi Arabia, are early adopters of passwordless authentication, leveraging AI-based facial recognition and behavioral analytics for seamless and secure identity verification."

African nations have also rolled out national identity cards based on biometrics. In South Africa, for example, customers can walk into a bank and open an account by using their fingerprint and linking it to the national ID database, which acts as the root of trust, says BIO-Key's Sullivan.

"After they verify that that person is who they say they are with the Home Affairs Ministry, they can store that fingerprint \[in the system\]," he says. "From then on, anytime they want to authenticate that user, they just touch a finger. They've just now started rolling out the ability to do that without even presenting your card for subsequent business."

**An Easy Upgrade Path**

While the links to national identity systems means biometrics make sense, companies do not need to jump feet first into biometric-based authentication, BIO-Key's Sullivan says. In many cases, enterprise customers start with a single sign-on system that then transitions to biometrics for identity or as a second factor.

"The use case is typically one where you have users that are moving around, and you don't want them to carry a phone or a token — finance, retail point-of-sale, banking, and manufacturing, where you have workforces that are roving around a manufacturing shop floor," he says. "We have to accommodate the fact that a lot of companies still use traditional technologies and don't want to just make a big-bang switch, so we we allow them to sort of start with what they're doing now ... \[and\] as they start to see the power of having a biometric option, they can evolve to that."

The push for stronger authentication is not limited to the Middle East and Africa. Worldwide, Microsoft sees 600 million identity attacks per day, of which 99.9% could be blocked with strong identity protections, such as multifactor authentication. Yet adoption has been slow: At the beginning of 2023, for example, Microsoft found that only 28% of the company's Azure Active Directory customers had turned on strong identity protections, up from 22% in 2022. Starting in February, the company will require MFA for all user accounts accessing the Microsoft 365 admin center, according to the company.

Saudi Arabia has established strong identity standards through its National Cybersecurity Authority's Essential Cybersecurity Controls (ECC-1:2018), while the UAE has implemented similar requirements through the Information Assurance Regulation (IAR), FTI Consulting's Murphy says.

Next up: AI-augmented identity platforms, he says. AI-driven authentication solutions, including liveness detection and real-time facial recognition, will likely be part of the mix.

"As digital identity ecosystems expand," Murphy says, "AI-based authentication and real-time identity verification will become critical components of cybersecurity, ensuring both security and usability across industries."

**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.

Mandatory MFA, Biometrics Make Headway in Middle East, Africa

Torrance, United States / California, 22nd January 2025, CyberNewsWire

**Torrance, United States / California, January 22nd, 2025, CyberNewsWire**

AI SPERA, a leading Cyber Threat Intelligence (CTI) provider, has collaborated with OnTheHub, a global provider of software in education, to deliver its integrated cybersecurity solution, Criminal IP, to students and educational institutions. This strategic initiative aims to enhance cybersecurity awareness and protection in the education sector by offering internationally compliant solutions at affordable prices.

Criminal IP will now extend its reach to educational institutions worldwide, reinforcing its growing presence in the global security market. Since its launch, Criminal IP has gained users in over 150 countries and formed strategic alliances with more than 40 global cybersecurity companies, including Cisco, Snowflake, Tenable, and VirusTotal.

(Criminal IP Lite Plan on OnTheHub)

OnTheHub is a worldwide operating platform that provides software and learning materials at discounted rates to educational organizations and their members. Through this collaboration, Criminal IP and OnTheHub seek to strengthen the cybersecurity frameworks of educational organizations on the platform, aligning with the ongoing digital transformation (DT) in education, particularly regarding Learning Management Systems (LMS). Students and researchers can access Criminal IP by redeeming coupons purchased through OnTheHub on the Criminal IP website, enabling them to utilize a globally recognized CTI platform at an affordable cost.

Criminal IP offers real-time risk analysis and vulnerability insights for global IP addresses and domains. Utilizing AI and machine learning technologies, the solution scans for security threats across various ports and devices, quickly identifying malicious IPs and domains while categorizing threat levels into five distinct tiers. Additionally, organizations can leverage Criminal IP ASM to oversee and manage IT assets, and Criminal IP FDS to detect unauthorized network access attempts during login or payment processes, all provided through a user-friendly SaaS model.

In terms of compatibility, Criminal IP offers an intuitive user interface (UI) and an integrated API, facilitating seamless integration with a variety of software and security solutions. This enables users to comprehensively evaluate security risks, including threat scores for IT assets, exposure of IoT devices, and phishing domain identification. Consequently, students and researchers associated with OnTheHub’s partner institutions will gain access to high-quality threat intelligence data and a robust platform for academic activities such as threat hunting, development, and research.

> AI SPERA CEO Byung-tak Kang commented, “Through this partnership, we are excited to provide more students and educational institutions with a globally recognized security solution at a reasonable price. We hope that Criminal IP will help students and researchers prevent security threats in educational environments and ensure a safe digital space for learning.”

**About AI SPERA**

AI SPERA, renowned for its advanced solutions, has expanded internationally, with ‘Criminal IP’ as its flagship offering. Operating in more than 150 countries, ‘Criminal IP’ is backed by enterprise-grade security solutions like ‘Criminal IP ASM’ and ‘Criminal IP FDS’. Strategic partnerships with global leaders such as Cisco, VirusTotal, and Quad9 have significantly enhanced ‘Criminal IP’s capabilities. AI SPERA’s ‘Criminal IP’ has recently entered the marketplace of major US data warehousing platforms, including Amazon Web Services (AWS), Microsoft Azure, and Snowflake, expanding its global reach for threat data.

**Contact**

**Michael Sena**  
**\[email protected\]**

Criminal IP and OnTheHub Partner to Deliver Advanced Cybersecurity Solutions for Education

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**

Tag

#microsoft