This advisory ties together older research on a contact file handling flaw on Microsoft Windows as well as recent research discovered that uses the same methodologies.

[-] Microsoft Windows Contact file / Remote Code Execution (Resurrected 2022)  / CVE-2022-44666

[+] John Page (aka hyp3rlinx)  
[+] twitter.com/hyp3rlinx  
[+] ISR: ApparitionSec

Back in 2018 I discovered three related Windows remote code execution vulnerabilities affecting both VCF and Contact files.  
They were purchased by Trend Micro Zero Day Initiative (@thezdi) from me and received candidate identifiers ZDI-CAN-6920 and ZDI-CAN-7591.  
Microsoft as usual denied a fix and it was subsequently dropped as a zero day on January 10, 2019 in coordination with the ZDI program.

Almost five years passed, until researcher j00sean resurrected the flaws to add additional protocol vectors LDAP etc.  
Microsoft finally decided to patch and assign CVE-2022-44666 even though the vulnerabilities are exactly the same.

Old 2019 advisories:  
=====================  
1) Windows VCF RCE  
http://hyp3rlinx.altervista.org/advisories/MICROSOFT-WINDOWS-VCF-FILE-INSUFFICIENT-WARNING-REMOTE-CODE-EXECUTION.txt

2) Windows Contact HTML injection  
http://hyp3rlinx.altervista.org/advisories/MICROSOFT-WINDOWS-CONTACT-FILE-HTML-INJECTION-MAILTO-LINK-ARBITRARY-CODE-EXECUTION.txt

3) Windows Contact RCE  
http://hyp3rlinx.altervista.org/advisories/MICROSOFT-WINDOWS-CONTACT-FILE-INSUFFECIENT-UI-WARNING-WEBSITE-LINK-ARBITRARY-CODE-EXECUTION.txt

Circa 2022 updated:  
=====================  
https://github.com/j00sean/CVE-2022-44666#readme  
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-44666

Additional References:  
=======================  
https://www.zerodayinitiative.com/advisories/ZDI-19-013/  
https://www.zdnet.com/article/poc-for-windows-vcf-zero-day-published-online/  
https://thehackernews.com/2019/01/vcard-windows-hacking.html  
https://twitter.com/hyp3rlinx/status/1083528552253919232  
https://seclists.org/bugtraq/2019/Jan/43  
https://vimeo.com/312824315  
https://www.exploit-db.com/exploits/46167  
https://www.rapid7.com/db/modules/exploit/windows/fileformat/microsoft_windows_contact/

Special thanks to j00sean for his work and resurrecting this vulnerability from the dead and helping deal with M$

hyp3rlinx

Microsoft Windows Contact File Remote Code Execution

Twitter is disabling SMS-based two-factor authentication. Switch to these alternatives to keep your account safe.

The latest bizarre move of Elon Musk’s Twitter ownership weakens the security of millions of accounts. On February 17, Twitter announced plans to stop people using SMS-based two-factor authentication to secure their accounts—unless they start paying for a Twitter Blue subscription. However, there are more secure, free, and easier ways to continue protecting your Twitter account with two-factor authentication.

Two-factor authentication, also known as 2FA or multi-factor authentication, is one of the most effective ways to protect your online accounts from being hacked. When logging in to a website, app, or service, 2FA requires you to sign in using your username and password, then verify that the login is authentic using another piece of information. Most commonly, this involves entering a temporary code that’s generated or sent to you in real time.

This second piece of information helps to prove that the person logging in is actually you. While billions of passwords have been compromised online, the 2FA code is often delivered to or created by the device that’s in your pocket. Having any kind of two-factor authentication turned on is better than none. However, it isn’t entirely foolproof. For years, security researchers have warned that SMS-based two-factor authentication isn’t as secure as other 2FA options.

That’s because SIM-swapping attacks, where phone numbers are compromised by attackers, let criminals access 2FA messages and break into accounts. Put simply: Using another 2FA option, even if it is slightly less convenient, is your best option.

In its announcement, Twitter said people have 30 days to turn off SMS-based 2FA and move to another option. It said the system had been abused by “bad actors” in the past. On March 20, Twitter will “disable” using text messages for two-factor authentication—unless you pay for the privilege. People have already started seeing pop-ups telling them to “remove text message two-factor authentication” before this date. 

However, Twitter’s announcement has baffled, confused, and angered security researchers. They say removing SMS-based 2FA just for people who don’t pay for Twitter Blue doesn’t make any sense and will weaken people’s security if they do not move to another 2FA option. Here’s what you should do to keep your account secure.

Use an Authenticator App or Security Key

Instead of turning 2FA off on your Twitter account, there are two better options: authenticator apps and security keys. They both work using the same principles as SMS-based 2FA. To enable either of these alternatives you will need to visit Twitter, open its **Settings and privacy**, then **Security and account access**, **Security**, and finally **Two-factor authentication**. (Or just click here if you are logged in). Here you will get the option to use two-factor authentication via an app or using security keys.

Instead of sending your six-digit authentication code via SMS message, authenticator apps are constantly generating the codes themselves and are synced with the services you use. Authenticator apps list all the websites you have registered with them and display the codes you need to enter to log in. These codes refresh every 30 seconds. Each time you need to log in to a website or app, you visit the authenticator app after entering your username and password to get the authentication code instead of waiting for a text message. (It’s particularly helpful if your phone doesn’t have connectivity for some reason.)

There are multiple, free two-factor authentication apps to pick from, although they all offer the same essential service and can be used across platforms. The big players have their own apps:There’s Google’s Authenticator App and Microsoft Authenticator. Alternatively, various password managers that you may already use, such as 1Password, have their own authenticator services. There’s also Twilio’s Authy App. And if you have an iPhone, you can use Apple’s built-in generator. 

Each has pros and cons that you should consider before picking one. For instance, you may be heavily locked into Microsoft’s or Google’s ecosystems and want to use their apps. Google’s is relatively basic but doesn’t sync elsewhere; Microsoft’s app offers password management services. However, the Microsoft and Authy apps appear to collect more user analytics data than Google’s. Whatever app you pick, it’s possible to switch to another authenticator.

Setting up an authentication app on Twitter, and anywhere else, is simple. For Twitter, you need to visit its 2FA page. Then open your authentication app, select the option to add a new account, then scan the QR Twitter shows you. Enter the six-digit code on your app and you’re done.

Alternatively, instead of an authenticator app, you can use a security key. The keys are physical pieces of hardware that you either plug into your computer when logging in or connect to your phone. They’re the most secure method of 2FA as an attacker physically needs the key to log in to your account—whereas an attacker always has the possibility of trying to trick you into handing over a generated six-digit authentication code.

Once you’ve set up an authenticator app or hardware key for Twitter, you’ll also want to make a note of Twitter’s backup code for your account. The backup code can be used to log in to Twitter if you can’t access your 2FA options, such as losing your phone or security key. (The first time you set up 2FA on Twitter it will provide you with a backup code, although this can be regenerated online.) You should save this in a safe place, such as your password manager.

How to Protect Yourself from Twitter’s 2FA Crackdown

New research shows that 57 vulnerabilities that threat actors are currently using in ransomware attacks enable everything from initial access to data theft.

Many vulnerabilities that ransomware operators used in 2022 attacks were years old and paved the way for the attackers to establish persistence and move laterally in order to execute their missions.

The vulnerabilities, in products from Microsoft, Oracle, VMware, F5, SonicWall, and several other vendors, present a clear and present danger to organizations that haven't remediated them yet, a new report from Ivanti revealed this week.

**Old Vulns Still Popular**

Ivanti's report is based on an analysis of data from its own threat intelligence team and from those at Securin, Cyber Security Works, and Cyware. It offers an in-depth look at vulnerabilities that bad actors commonly exploited in ransomware attacks in 2022.

Ivanti's analysis showed that ransomware operators exploited a total of 344 unique vulnerabilities in attacks last year—an increase of 56 compared to 2021. Of this, a startling 76% of the flaws were from 2019 or before. The oldest vulnerabilities in the set were in fact three remote code execution (RCE) bugs from 2012 in Oracle's products: CVE-2012-1710 in Oracle Fusion middleware and CVE-2012-1723 and CVE-2012-4681 in the Java Runtime Environment.

Srinivas Mukkamala, Ivanti’s chief product officer, says that while the data shows ransomware operators weaponized new vulnerabilities faster than ever last year, many continued to rely on old vulnerabilities that remain unpatched on enterprise systems. 

"Older flaws being exploited is a by-product of the complexity and time-consuming nature of patches," Mukkamala says. "This is why organizations need to take a risk-based vulnerability management approach to prioritize patches so that they can remediate vulnerabilities that pose the most risk to their organization."

**The Biggest Threats**

Among the vulnerabilities that Ivanti identified as presenting the greatest danger were 57 that the company described as offering threat actors capabilities for executing their entire mission. These were vulnerabilities that allow an attacker to gain initial access, achieve persistence, escalate privileges, evade defenses, access credentials, discover assets they might be looking for, move laterally, collect data, and execute the final mission.

The three Oracle bugs from 2012 were among 25 vulnerabilities in this category that were from 2019 or older. Exploits against three of them (CVE-2017-18362, CVE-2017-6884, and CVE-2020-36195) in products from ConnectWise, Zyxel, and QNAP, respectively, are not currently being detected by scanners, Ivanti said.

A plurality (11) of the vulnerabilities in the list that offered a complete exploit chain stemmed from improper input validation. Other common causes for vulnerabilities included path traversal issues, OS command injection, out-of-bounds write errors, and SQL injection. 

**Widely Prevalent Flaws Are Most Popular**

Ransomware actors also tended to prefer flaws that exist across multiple products. One of the most popular among them was CVE-2018-3639, a type of speculative side-channel vulnerability that Intel disclosed in 2018. The vulnerability exists in 345 products from 26 vendors, Mukkamala says. Other examples include CVE-2021-4428, the infamous Log4Shell flaw, which at least six ransomware groups are currently exploiting. The flaw is among those that Ivanti found trending among threat actors as recently as December 2022. It exists in at least 176 products from 21 vendors including Oracle, Red Hat, Apache, Novell, and Amazon.

Two other vulnerabilities ransomware operators favored because of their widespread prevalence are CVE-2018-5391 in the Linux kernel and CVE-2020-1472, a critical elevation of privilege flaw in Microsoft Netlogon. At least nine ransomware gangs including those behind Babuk, CryptoMix, Conti, DarkSide, and Ryuk, have used the flaw, and it continues to trend in popularity among others as well, Ivanti said.

In total, the security found that some 118 vulnerabilities that were used in ransomware attacks last year were flaws that existed across multiple products.

"Threat actors are very interested in flaws that are present in most products," Mukkamala says.

**None on the CISA List**

Notably, 131 of the 344 flaws that ransomware attackers exploited last year are not included in the US Cybersecurity and Infrastructure Security Agency's closely followed Known Exploited Vulnerabilities (KEV) database. The database lists software flaws that threat actors are actively exploiting and which CISA assesses as being especially risky. CISA requires federal agencies to address vulnerabilities listed in the database on a priority basis and usually within two weeks or so.

"It's significant that these aren't in CISA's KEV because many organizations use the KEV to prioritize patches," Mukkamala says. That shows that while KEV is a solid resource, it doesn't provide a full view of all the vulnerabilities being used in ransomware attacks, he says.

Ivanti found that 57 vulnerabilities used in ransomware attacks last year by groups such as LockBit, Conti, and BlackCat, had low- and medium-severity scores in the national vulnerability database. The danger: this could lull organizations who use the score to prioritize patching into a false sense of security, the security vendor said.

Majority of Ransomware Attacks Last Year Exploited Old Bugs

Unknown malware presents a significant cybersecurity threat and can cause serious damage to organizations and individuals alike. When left undetected, malicious code can gain access to confidential information, corrupt data, and allow attackers to gain control of systems. Find out how to avoid these circumstances and detect unknown malicious behavior efficiently. 
Challenges of new threats'

Unknown malware presents a significant cybersecurity threat and can cause serious damage to organizations and individuals alike. When left undetected, malicious code can gain access to confidential information, corrupt data, and allow attackers to gain control of systems. Find out how to avoid these circumstances and detect unknown malicious behavior efficiently.

**Challenges of new threats' detection**

While known malware families are more predictable and can be detected more easily, unknown threats can take on a variety of forms, causing a bunch of challenges for their detection:

1.  Malware developers use polymorphism, which enables them to modify the malicious code to generate unique variants of the same malware.
2.  There is malware that is still not identified and doesn't have any rulesets for detection.
3.  Some threats can be Fully UnDetectable (FUD) for some time and challenge perimeter security.
4.  The code is often encrypted, making it difficult to detect by signature-based security solutions.
5.  Malware authors may use a "low and slow" approach, which involves sending a small amount of malicious code across a network over a long time, which makes it harder to detect and block. This can be especially damaging in corporate networks, where the lack of visibility into the environment can lead to undetected malicious activity.

**Detection of new threats**

When analyzing known malware families, researchers can take advantage of existing information about the malware, such as its behavior, payloads, and known vulnerabilities, in order to detect and respond to it.

But dealing with new threats, researchers have to start from scratch, using the following guide:

**Step 1.** Use reverse engineering to analyze the code of the malware to identify its purpose and malicious nature.

**Step 2**. Use static analysis to examine the malware's code to identify its behavior, payloads, and vulnerabilities.

**Step 3.** Use dynamic analysis to observe the behavior of the malware during execution.

**Step 4.** Use sandboxing to run the malware in an isolated environment to observe its behavior without harming the system.

**Step 5.** Use heuristics to identify potentially malicious code based on observable patterns and behaviors.

**Step 6.** Analyze the results of reverse engineering, static analysis, dynamic analysis, sandboxing, and heuristics to determine if the code is malicious.

There are plenty of tools from Process Monitor and Wireshark to ANY.RUN to help you go through the first 5 steps. But how to draw a precise conclusion, what should you pay attention to while having all this data?

The answer is simple - focus on indicators of malicious behavior.

**Monitor suspicious activities for effective detection**

Different signatures are used to detect threats. In computer security terminology, a signature is a typical footprint or pattern associated with a malicious attack on a computer network or system.

Part of these signatures is behavioral ones. It's impossible to do something in the OS and leave no tracing behind. We can identify what software or script it was via their suspicious activities.

You can run a suspicious program in a sandbox to observe the behavior of the malware and identify any malicious behavior, such as:

*   abnormal file system activity,
*   suspicious process creation and termination
*   abnormal networking activity
*   reading or modifying system files
*   access system resources
*   create new users
*   connect to remote servers
*   execute other malicious commands
*   exploit known vulnerabilities in the system

Microsoft Office is launching PowerShell – looks suspicious, right? An application adds itself to the scheduled tasks – definitely pay attention to it. A svchost process runs from the temp registry – something is definitely wrong.

You can always detect any threat by its behavior, even without signatures.

Let's prove it.

**Use case #1**

Here is a sample of the stealer. What does it do? Steals user data, cookies, wallets, etc. How can we detect it? For example, it reveals itself when the application opens the Chrome browser's Login Data file.

Stealer's suspicious behavior

The activity in the network traffic also announces the threat's malicious intentions. A legitimate application would never send credentials, OS characteristics, and other sensitive data collected locally.

In the case of traffic, malware can be detected by well-known features. Agent Tesla in some cases does not encrypt data sent from an infected system like in this sample.

Suspicious activity in the network traffic

**Use case #2**

There are not many legitimate programs that need to stop Windows Defender or other applications to protect the OS or make an exclusion for itself. Every time you encounter this kind of behavior – that's a sign of suspicious activity.

Suspicious behavior

Does the application delete shadow copies? Looks like ransomware. Does it remove shadow copies and create a TXT/HTML file with readme text in each directory? It's one more proof of it.

If the user data is encrypted in the process, we can be sure it is ransomware. Like what happened in this malicious example. Even if we do not know the family, we can identify what kind of security threat this software poses and then act accordingly and take measures to protect working stations and the organization's network.

Ransomware suspicious behavior

We can draw conclusions about almost all kinds of malware based on the behavior observed in the sandbox. Try ANY.RUN online interactive service to monitor it - you can get the first results immediately and see all malware's action in real time. Exactly what we need to catch any suspicious activities.

Write the **"HACKERNEWS2"** promo code at support@any.run using your business email address and **get 14 days of ANY.RUN premium subscription for free**!

  
**Wrapping up**

Cybercriminals can use unknown threats to extort businesses for money and launch large-scale cyberattacks. Even if the malware family is not detected - we can always conclude the threat's functionality by considering its behavior. Using this data, you can build information security to prevent any new threats. Behavior analysis enhances your ability to respond to new and unknown threats and strengthens your organization's protection without additional costs.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

How to Detect New Threats via Suspicious Activities

Established network security players like Check Point are responding to the shift to cloud-native applications, which have exposed more vulnerabilities in open source software supply chains.

When Check Point Software acquired Israeli startup Spectral a year ago, it joined the ranks of other network security providers acknowledging the growing threat of software supply chain attacks. Spectral helped fill a critical gap in CloudGuard, Check Point's unified threat protection and network security platform for public and hybrid clouds, with its code scanning and leakage detection tools.

Spectral offers infrastructure as code (IaC) scanning, code-tampering prevention, hardcoded secrets detection source controls, and CI/CD security and source code leakage detection tools. It provided the underpinning of Check Point's Cloud-Native Application Protection Platform (CNAPP), which is now part of CloudGuard, one of four core Check Point product lines.

**Understanding the Role of CNAPP**

CNAPP is gaining a lot of attention as developers shift to cloud-native application development to support new business applications and digital transformation initiatives. Gartner describes CNAPPs as "an integrated set of security and compliance capabilities designed to help secure and protect cloud-native applications across development and production."

Developers are increasingly relying on open source code and microservices from a widely distributed and often vast community to compose their containers and serverless functions. While the source code may come from an established ecosystem, it is common for some components to have roots from unknown or obsolete sources. CNAPP enables organizations to establish DevSecOps processes where software developers take the lead in discovering potential flaws in code before deploying application runtimes into production, says Melinda Marks, a senior analyst at Enterprise Strategy Group.

"This is important for preventing security issues before you deploy your applications to the cloud because once you deploy them, they're available for the hackers," Marks says.

**Agentless Scanning and Other New Features**

After integrating Spectral's tools into CloudGuard upon completing last year's acquisition, Check Point added some critical new capabilities to the CNAPP, rolled out this month, including permissions and entitlement management, agentless scanning, and deeper risk scoring of an organization's entire environment. Check Point officials underscored the company CNAPP push last week during its annual CPX 360 event in New York.

"We significantly enriched the platform to address many important elements of the cloud-native control environment," Check Point chief product officer Dorit Dor tells Dark Reading. Check Point also announced plans to feed all data from CloudGuard to its new Horizon Events, a unified dashboard that gathers logs from the entire Check Point ecosystem. Check Point introduced Horizon Events late last year, and an early access version is now available.

For Check Point, adding CNAPP to CloudGuard was critical. Check Point's key competitors are also on the CNAPP bandwagon. Among them, Palo Alto Networks has significantly emphasized its Prisma Cloud, which recently gained added Software Composition Analysis (SCA) and Secret Scanning capabilities. In December, Palo Alto Networks acquired supply chain security tool provider Cider Security.

**Check Point Shares CNAPP Roadmap**

Dor touted Spectral's "very strong" secret scanning capabilities. She explained that developers could plug it into their CI/CD environments and implement policies as code through open policy agents.

Dor presented the roadmap for CloudGuard, noting that Check Point is looking to implement more AI. Check Point plans to improve observability and visibility to help developers identify malicious code. Also in the pipeline, Check Point is working on allowing CloudGuard to handle the entire software bill of materials (SBOM) lifecycle, ultimately enabling and enforcing them.

Check Point is also working on enhancing how CloudGuard works with network security. "Network Security has been there for a long time; we have a very mature network security solution," Dor said. "But the challenge now is to make it speak more of the language of the developers." Check Point is addressing that by integrating network security into its AWS Security framework and offering it with the AWS network security as a service. Dor noted that Check Point recently integrated CloudGuard network security with Microsoft Azure, allowing administrators to manage their Microsoft environments.

"It's a space for continuous investment," Dor said. With a direction toward multi-cloud coverage, the goal is to enable it to "support your developers natively and to support the system administration and giving you one cloud control plane."

Check Point Boosts AppSec Focus With CNAPP Enhancements

The primary victims so far have been employees of telcos in the Middle East, who were hit with custom backdoors via the cloud, in a likely precursor to a broader attack.

A previously unknown threat actor is targeting telecommunications companies in the Middle East in what appears to be a cyber-espionage campaign similar to many that have hit telecom organizations in multiple countries in recent years.

Researchers from SentinelOne who spotted the new campaign said they're tracking it as WIP26, a designation the company uses for activity it has not been able to attribute to any specific cyberattack group.

In a report this week, they noted that they had observed WIP26 using public cloud infrastructure to deliver malware and store exfiltrated data, as well as for command-and-control (C2) purposes. The security vendor assessed that the threat actor is using the tactic — like many others do these days — to evade detection and make its activity harder to spot on compromised networks. 

"The WIP26 activity is a relevant example of threat actors continuously innovating their TTPs \[tactics, techniques and procedures\] in an attempt to stay stealthy and circumvent defenses," the company said.

**Targeted Mideast Telecom Attacks**

The attacks that SentinelOne observed usually began with WhatsApp messages directed at specific individuals within target telecom companies in the Middle East. The messages contained a link to an archive file in Dropbox that purported to contain documents on poverty-related topics pertinent to the region. But in reality, it also included a malware loader. 

Users tricked into clicking on the link ended up having two backdoors installed on their devices. SentinelOne found one of them, tracked as CMD365, using a Microsoft 365 Mail client as its C2, and the second backdoor, dubbed CMDEmber, using a Google Firebase instance for the same purpose.

The security vendor described WIP26 as using the backdoors to conduct reconnaissance, elevate privileges, deploy addition malware — and to steal the user's private browser data, information on high-value systems on the victim's network, and other data. SentinelOne assessed that a lot of the data that both backdoors have been collecting from victim systems and network suggest the attacker is prepping for a future attack. 

"The initial intrusion vector we observed involved precision targeting," SentinelOne said. "Further, the targeting of telecommunication providers in the Middle East suggests the motive behind this activity is espionage-related."

**Telecom Companies Continue to Be Favorite Espionage Targets**

WIP26 is one of many threat actors that have targeted telecom companies over the past few years. Some of the more recent examples — like a series of attacks on Australian telecom companies such as Optus, Telestra, and Dialog — were financially motivated. Security experts have pointed to those attacks as a sign of increased interest in telecom companies among cybercriminals looking to steal customer data, or to hijack mobile devices via so-called SIM swapping schemes.

More often though, cyberespionage and surveillance have been primary motivations for attacks on telecommunications providers. Security vendors have reported several campaigns where advanced persistent threat groups from countries like China, Turkey, and Iran have broken into a communication provider's network so they could spy on individuals and groups of interest to their respective governments.

One example is Operation Soft Cell, where a China-based group broke into the networks of major telecommunications companies around the world to steal call data records so they could track specific individuals. In another campaign, a threat actor tracked as Light Basin stole Mobile Subscriber Identity (IMSI) and metadata from the networks of 13 major carriers. As part of the campaign, the threat actor installed malware on the carrier networks that that allowed it to intercept calls, text messages, and call records of targeted individuals.

Novel Spy Group Targets Telecoms in 'Precision-Targeted' Cyberattacks

Talos is publishing a glimpse into the most prevalent threats we've observed between Feb. 10 and Feb. 17.

Threat Round up for February 10 to February 17

Hey 👋 there, cyber friends!
Welcome to this week's cybersecurity newsletter, where we aim to keep you informed and empowered in the ever-changing world of cyber threats.
In today's edition, we will cover some interesting developments in the cybersecurity landscape and share some insightful analysis of each to help you protect yourself against potential attacks.
1. Apple 📱 Devices Hacked with

Hey 👋 there, cyber friends!

Welcome to **this week's cybersecurity newsletter**, where we aim to keep you informed and empowered in the ever-changing world of cyber threats.

In today's edition, we will cover some interesting developments in the cybersecurity landscape and share some insightful analysis of each to help you protect yourself against potential attacks.

****1\. Apple 📱 Devices Hacked with New Zero-Day Bug - Update ASAP!****

Have you updated your Apple devices lately? If not, it's time to do so, as the tech giant just released security updates for iOS, iPadOS, macOS, and Safari. The update is to fix a zero-day vulnerability that hackers have been exploiting.

This vulnerability, tracked as CVE-2023-23529, is related to a type confusion bug in the WebKit browser engine. What does this mean? Well, it means that if you visit a website with malicious code, the bug can be activated, leading to arbitrary code execution. In other words, hackers can take control of your device and access all your data.

It's scary to think that simply visiting a website could lead to a security breach. This is why it's essential to keep your devices updated with the latest security patches.

****2\. Don't Be the Next Victim: ESXiArgs Ransomware 💥 Strikes 500+ New European Targets****

In a recent discovery by cybersecurity firm Censys, more than 500 hosts have fallen victim to the ESXiArgs ransomware strain. Most of these compromised hosts are located in France, Germany, the Netherlands, the U.K., and Ukraine. What's particularly concerning is that Censys found two hosts with ransom notes dating back to mid-October 2022, shortly after ESXi versions 6.5 and 6.7 reached their end of life.

This means that the attackers behind ESXiArgs have been active for several months, and were able to gain a foothold in these hosts during a time when they were no longer receiving security updates or patches. It also shows that ransomware attacks can take a while to gain traction, and can often go undetected for months before they are discovered.

What's even more alarming is that the ransom notes on the two hosts were updated on January 31, 2023, with a revised version that matches the ones used in the current wave of attacks. This suggests that the attackers have been refining their tactics and improving their ransomware strain to make it more effective.

Ransomware attacks like ESXiArgs can be devastating for organizations, causing data loss, financial losses, and reputational damage. It's important for organizations to stay vigilant and ensure that their systems are always up to date with the latest security patches and updates.

Additionally, having a solid backup and disaster recovery plan can help organizations quickly recover from an attack and minimize its impact.

****3\. DDoS Attack Breaks Record - 71 Million 😮 Requests Per Second!****

Cloudflare, a web infrastructure company, has reported that they have successfully stopped a massive distributed denial-of-service (DDoS) attack. This attack, which peaked at over 71 million requests per second, is the largest HTTP DDoS attack that has been recorded so far, breaking the previous record of 46 million requests per second.

The attack was so large that Cloudflare has dubbed it a "hyper-volumetric" DDoS attack. The attack was targeted at websites that were secured by Cloudflare's platform, and it is believed that the attack originated from a botnet that was made up of more than 30,000 IP addresses from various cloud providers.

This attack is a reminder that DDoS attacks remain a significant threat to websites and online services, and it is crucial for companies to have robust security measures in place to protect against such attacks.

  
**Subscribe to our Daily Newsletters**

We hope you've been enjoying our weekly cybersecurity newsletter as much as we love making it informative and easy to understand. But, we also understand the importance of staying on top of the latest threats and vulnerabilities that can harm your digital life.

That's why we highly recommend subscribing to our daily news updates via email. You'll receive the latest cybersecurity news, insights, resources, offers and analysis straight to your inbox every day.

It's free – Subscribe Now!

****4\. Microsoft 🖥️ Releases Urgent Patches - Update Your Windows ASAP!****

Microsoft has been busy this week, releasing security updates to fix a whopping 75 vulnerabilities in its products. That's a lot of potential ways for cybercriminals to wreak havoc on our devices and systems!

Three of the flaws have already been exploited in the wild, so it's crucial that users update their software as soon as possible. In total, nine of the vulnerabilities are rated as Critical, which means they could allow attackers to take over a device remotely.

But wait, there's more! 37 of the flaws are what are known as remote code execution (RCE) vulnerabilities. These are particularly dangerous because they allow attackers to execute code on a victim's device without any interaction or permission.

So, if you're using any Microsoft products, it's best to update them as soon as possible.

****5\. Linux 🐧 and IoT Devices Under Attack by V3G4 Mirai Botnet****

A new variant of the infamous Mirai botnet has been spotted wreaking havoc in the world of Linux and IoT devices. This new version, dubbed V3G4 by the experts at Palo Alto Networks Unit 42, is making use of 13 security vulnerabilities to spread itself far and wide.

As we know, the Mirai botnet has a notorious history, having been responsible for several high-profile attacks in the past. This new variant only serves to underscore the importance of keeping our devices and systems up to date with the latest security patches and measures.

****6\. Your Favorite Apps Could be Carrying a Dangerous Virus - 🚨 Stay Alert!****

Cybercriminals have launched a new type of attack targeting Chinese-speaking individuals in Southeast and East Asia. Using rogue Google Ads, they are tricking people looking for popular applications like Google Chrome, WhatsApp, and Skype and directing them to fake websites that download malware onto their machines.

The attacks are particularly insidious because they use seemingly legitimate Google Ads to lure in victims. The malware being downloaded is a remote access trojan called FatalRAT, which gives the attackers complete control over the infected machine.

Security researchers are urging people to be cautious when downloading applications, especially from unfamiliar websites.

  
**The Hacker News / Upcoming Webinars**

Are you tired of falling victim to file-based threats and not knowing how to protect your sensitive data? Or are you struggling to keep up with the ever-evolving security challenges of SaaS applications?

Well, have no fear because we have two exciting webinars coming up that will help you bust some common myths and tackle the top security challenges of 2023!

*   Our first webinar, "**A MythBusting Special: 9 Myths about File-based Threats**", will help you separate fact from fiction when it comes to file-based threats. You'll learn the truth about what they are, how they work, and most importantly, how to prevent them from infiltrating your systems.
*   And if you're a fan of SaaS applications but find yourself grappling with security issues, then our second webinar, "**How to Tackle the Top SaaS Security Challenges of 2023**", is the one for you! Our experts will walk you through the most pressing security challenges of 2023, and provide practical tips to help you stay ahead of the game.

Both of these webinars are free and packed with valuable information that you won't want to miss. **So, don't wait - sign up now and join us for an informative and engaging cybersecurity discussion!**

Well folks, that's all for this week's cybersecurity newsletter.

As always, remember that cybersecurity is not just a one-time event or a quick fix. Whether it's using strong passwords, regularly updating your software, or staying aware of phishing scams, every small action can make a big difference in safeguarding your online security.  
So keep those firewalls up, keep those updates coming, and let's continue to stay curious, stay vigilant, and stay safe in the ever-changing digital landscape.

And above all, remember that cybersecurity is a community effort. We appreciate your readership and feedback and are always here to answer your questions and address your concerns. Please let us know if you have any suggestions for topics you'd like us to cover in future newsletters.

Thank you for joining us on this cybersecurity journey, and we look forward to sharing more insights and updates with you in the weeks ahead. Until next time, stay cyber-secure!

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

⚡Top Cybersecurity News Stories This Week — Cybersecurity Newsletter

The Raccoon attack is a timing attack on DHE ciphersuites inherit in the TLS specification. To mitigate this vulnerability, Firefox disabled support for DHE ciphersuites.

Raccoon is a timing vulnerability in the TLS **specification** that affects HTTPS and other services that rely on SSL and TLS. These protocols allow everyone on the Internet to browse the web, use email, shop online, and send instant messages without third-parties being able to read the communication.

Raccoon allows attackers under certain conditions to break the encryption and read sensitive communications. The vulnerability is really hard to exploit and relies on very precise timing measurements and on a specific server configuration to be exploitable.

**Attack Overview**

Diffie-Hellman (DH) key exchange is a well-established method for exchanging keys in TLS connections. When using Diffie-Hellman, both TLS peers generate private keys at random (a and b) and compute their public keys: ga mod p and gb mod p. These public keys are sent in the TLS KeyExchange messages. Once both keys are received, both the client and server can compute a shared key _gab mod p_ - called _premaster secret_ - which is used to derive all TLS session keys with a specific _key derivation function_.

Our Raccoon attack exploits a TLS specification side channel; TLS 1.2 (and all previous versions) prescribes that all leading zero bytes in the premaster secret are stripped before used in further computations. Since the resulting premaster secret is used as an input into the key derivation function, which is based on hash functions with different timing profiles, precise timing measurements may enable an attacker to construct an oracle from a TLS server. This oracle tells the attacker whether a computed premaster secret starts with zero or not. For example, the attacker could eavesdrop ga sent by the client, resend it to the server, and determine whether the resulting premaster secret starts with zero or not.

Learning one byte from a premaster secret would not help the attacker much. However, here the attack gets interesting. Imagine the attacker intercepted a ClientKeyExchange message containing the value ga. The attacker can now construct values related to ga and send them to the server in distinct TLS handshakes. More concretely, the attacker constructs values gri\*ga, which lead to premaster secrets gri\*b\*gab. Based on the server timing behavior, the attacker can find values leading to premaster secrets starting with zero. In the end, this helps the attacker to construct a set of equations and use a solver for the Hidden Number Problem (HNP) to compute the original premaster secret established between the client and the server.

**Full Technical Paper (last update: 11.2.2021)**

Raccoon Attack: Finding and Exploiting Most-Significant-Bit-Oracles in TLS-DH(E). Robert Merget, Marcus Brinkmann, Nimrod Aviram, Juraj Somorovsky, Johannes Mittmann, and Jörg Schwenk.

**FAQ****I am an admin, should I drop everything and fix this?**

Probably not. Raccoon is a complex timing attack and it is very hard to exploit. It requires a lot of stars to align to decrypt a real-world TLS session. There are, however, exceptions.

**What can the attackers gain?**

In the case the (rare) circumstances are met, Raccoon allows an attacker to decrypt the connection between users and the server. This typically includes, but is not limited to, usernames and passwords, credit card numbers, emails, instant messages, and sensitive documents.

**Who is vulnerable?**

The attack generally targets the Diffie-Hellman key exchange in TLS 1.2 and below. There are two prerequisites for the attack:

*   The server reuses public DH keys in the TLS handshake. This is the case if the server is configured to use static TLS-DH cipher suites, or if the server uses ephemeral cipher suites (TLS-DHE) and reuses ephemeral keys for multiple connections. Luckily, this was already considered bad practice before the attack, as it does not provide forward secrecy.
*   The attacker can execute precise timing measurements, which allow him/her to find out whether the first byte of the DH shared secret starts with zero or not.

**So how practical is the attack?**

That is an excellent question that probably does not have a satisfying answer. Cryptographic(!) attacks against TLS generally tend to be not used a lot by real-world attackers as far as we know. The attacker needs particular circumstances for the Raccoon attack to work. He needs to be close to the target server to perform high precision timing measurements. He needs the victim connection to use DH(E) and the server to reuse ephemeral keys. And finally, the attacker needs to observe the original connection. For a real attacker, this is a lot to ask for. However, in comparison to what an attacker would need to do to break modern cryptographic primitives like AES, the attack does not look complex anymore. But still, a real-world attacker will probably use other attack vectors that are simpler and more reliable than this attack.

**Is my website vulnerable?**

It might be. You can check this using tools like:

*   www.ssllabs.com, your server might be vulnerable if "DH public server param (Ys) reuse" says "yes".
*   We will release our own tool very soon.

**Is my browser/client vulnerable?**

The vulnerability is not really a client-side vulnerability. The client can do nothing about this, except not to support DH(E) cipher suites. Modern browsers should not support these cipher suites anymore. As far as we know, Firefox was the last major browser that supported DHE, and dropped support for it in Firefox 78 in June 2020 (by now, most clients should run at least that version, if not later versions). You can check if your browser still supports DH(E) here, but to reiterate, there is nothing practical clients can or should do about the attack.

**Does Raccoon allow you to steal the private key?**

No, you have to perform the attack for each individual connection you want to attack.

**Is TLS 1.3 also affected?**

No. In TLS 1.3, the leading zero bytes are preserved for DHE cipher suites (as well as for ECDHE ones) and keys should not be reused. However, there exists a variant of TLS 1.3, which explicitly allows key reuse (or even encourages it), called ETS or eTLS. If ephemeral keys get reused in either variant, they could lead to micro-architectural side channels, which could be exploited, although leading zero bytes are preserved. We recommend not using these variants.

**Is ECDH also affected?**

Generally no. In TLS, the PMS's leading zero bytes are preserved in all versions of TLS for ECDH. So a secure, leak-free implementation should be possible. In other protocols, this might not be the case. To the best of our knowledge, even if side channels were present, the best currently known algorithms still require a lot more known bits to work for ECDH than what is possible to get with Raccoon. We still want to point out that the ECDH variant of the HNP has not been studied as extensively as the traditional HNP. Therefore, it cannot be guaranteed that future improvements to these algorithms might also make these attacks work for ECDH.

**Is DTLS affected?**

Yes.

**So is this really only a timing vulnerability?**

Sadly no. A bug in your software can also make this attack possible without timing measurements. We performed a large-scale Internet scan to analyze a large variety of TLS servers and found - surprise - several devices showing different behavior resulting from the first byte of the premaster secret. So far, we were able to identify and report one of them: an older version of F5 BIG-IP. You should probably check that you are not running a vulnerable configuration (see CVE-2020-5929) since this allows mounting a direct attack without complex timing measurements. If you are running a vulnerable configuration, you should probably patch now. Note that, also in the case of the vulnerable F5 BIG-IP, the attack is only practical if the server reuses DH public keys. We recommend not dismissing the ability of the attacker to measure precise timing, and instead move away from DHE for clients and avoid key reuse for servers.

**How common is DHE key reuse?**

We performed a measurement across the Alexa Top 100k websites on the Internet. 3.33% of those servers reused their ephemeral DH keys at least once. Springall et al. found that 4.4% of the Alexa Top 1M reused DH keys, as of 2016.

**Since when does the vulnerability exist?**

The vulnerability was undiscovered for more than 20 years (at least since SSLv3, published in 1996). The flaw was fixed for TLS 1.3 in draft-14, thanks to David Benjamin from Google who flagged this issue.

**Why wasn't this discovered earlier?**

The attack combines a lot of details of the involved primitives. The Hidden Number Problem (HNP), which we ultimately use to exploit the timing side channel, has never been used to exploit its original target (the Diffie-Hellman Key Exchange). That is because no one knew a technique to get the most significant bits of a Diffie-Hellman shared secret. Since then, the HNP was mostly used in other settings like DSA or ECDSA, and the knowledge that it also works for DH got forgotten. The fact that the leading zeros in the TLS-DH(E) premaster secrets are stripped is also a TLS detail that probably only a few people knew of.

**Why does TLS-DH(E) strip leading zero bytes in the first place?**

We found the answer to this question in an old Bugzilla entry. It seems like SSL 3 was supposed to implement PKCS#3, which mandates that leading zero bits of the PMS are preserved. But implementors misunderstood the wording in the spec of SSL 3:

> _A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre\_master\_secret \[...\]._

Instead, leading zero bytes were stripped. By the time this was discovered, the damage was already done. For TLS 1.0, it was then intentionally changed to remove leading zero bytes, probably to avoid further confusion. When elliptic curves were later added to the standard, they explicitly mentioned that the leading zeros of the PMS have to be preserved, resulting in the current situation where they are preserved for ECDH but not for DH.

**Why is the attack called "Raccoon"?**

Raccoon is not an acronym. Raccoons are just cute animals, and it is well past time that an attack will be named after them :)

**How have vendors responded to this vulnerability?**

*   F5 assigned the issue CVE-2020-5929. In particular, several F5 products allow executing a special version of the attack, without the need for precise timing measurements. F5 recommends their customers to patch the products or to enforce usage of fresh ephemeral keys. Please refer to the F5 Security Advisory.
*   OpenSSL assigned the issue CVE-2020-1968. OpenSSL does use fresh DH keys per default since version 1.0.2f (which made SSL\_OP\_SINGLE\_DH\_USE default as a response to CVE-2016-0701). Therefore, the attack mainly affects OpenSSL 1.0.2 when a DH certificate is in use, which is rare. OpenSSL 1.1.1 never reuses a DH secret and does not implement any "static" DH ciphersuites. To mitigate the attack, the developers moved all remaining DH cipher suites into the "weak-ssl-ciphers" list. In addition, motivated by this research, the developers also activated the fresh generation of EC ephemeral keys in OpenSSL 1.0.2w. Please refer to the OpenSSL Security Advisory.
*   Mozilla assigned the issue CVE-2020-12413. It has been solved by disabling DH and DHE cipher suites in Firefox (which was already planned before the Raccoon disclosure).
*   Microsoft assigned the issue CVE-2020-1596. Please refer to the Microsoft Security Response Center portal.

BearSSL and BoringSSL are not affected because they do not support DH(E) cipher suites. GnuTLS, Wolfssl, Botan, Mbed TLS and s2n do not support static DH cipher suites. Their DHE cipher suites never reuse ephemeral keys.

**I thought there was a security proof for TLS-DH(E) (here and here). Why wasn't this covered by the proof?**

A problem with a lot of current cryptographic proof techniques is that they are often **not designed to model side channels** (within the protocol). They will assume that all operations are always executed in constant time, although this might be impossible to achieve in practice. Additionally, they do not model the encoding of secrets within the primitives. These details get lost in the proven model of the protocol. To prove that TLS-DH(E) is secure, the PRF-ODH assumption had to be introduced, and the proof relied on this assumption to hold for TLS. In theory, this assumption is still fine for TLS, but for all practical means, the assumption does not hold in real TLS implementations.

**How is this attack related to other TLS attacks?**

Many of you would probably remember Bleichenbacher's attack (see also ROBOT for practical exploits). This adaptive chosen-ciphertext attack exploits server behavior differences by processing RSA PKCS#1 v1.5 messages. It allows the attacker to decrypt the premaster secret after a few thousands of connections. From the attacker model perspective, the Raccoon attack is very similar to Bleichenbacher's attack; the attacker also needs to send several modified ClientKeyExchange messages to the server, observe its responses, and perform some cryptographic computations to reveal the premaster secret. In contrast to Bleichenbacher's attack, Raccoon targets the DH key exchange.

Lucky 13 is another cool attack you might have in mind when reading the description of the Raccoon attack. In Lucky 13, AlFardan and Paterson exploited different timing behaviors of HMACs computed over different TLS record lengths. This allowed them to distinguish valid from invalid paddings and apply CBC padding oracle attacks. The attack works in a BEAST attack scenario and allows the attacker to decrypt TLS records. In contrast, our Raccoon attack exploits the timing behavior difference resulting from the HMAC computations over premaster secrets of different lengths. It reveals the premaster secret and thus decrypts the whole connection based on a single eavesdropped ClientKeyExchange message. Our Raccoon attack was inspired by the Lucky 13 side channel.

**What about other protocols?**

As you may imagine, there are many protocols using DH key exchange. For example, we can confirm that SSH does also strip leading zero bits. However, according to Springall et. al SSH does a better job at avoiding key reuse than TLS did, and therefore the attack is not exploitable in SSH.

XML Encryption and IPsec preserve leading zero bytes.

JSON Web Encryption only offers ECDH key agreement. The established shared secret should be processed as described in the NIST Special Publication 800-56A. This document recommends to preserve leading zero bytes, see Appendix C.1 and C.2.

There are many other protocols using DH key exchange. Their analysis is often hard since the documents do not provide information how to handle established shared secrets so that source code analysis or manual tests are necessary. It would also be interesting to see whether similar Raccoon-styled attacks would be applicable to the newest post quantum schemes.

**So is a protocol, which preserves leading zero bytes in the DH shared secret, completely secure against this attack?**

Our main attack relies on the TLS specification problem resulting from the stripped zeros. Executing a key derivation function over premaster secrets of different lengths leads to different timing behaviors. This is the side channel that showed to perform well in our measurements.

However, it is very likely that even if the shared secret preserves leading zero bytes, there could arise different side channels allowing the attacker to mount such an attack. Implementing a constant-time computation is very challenging; the side channel can arrise from the underlying big number library implementation or aligning shared secret to the modulus length. While such side channels are not as significant as the side channel described in our paper, a stronger attacker could still use powerful techniques like micro-architectural attacks to find out whether computed shared secrets start with zero or not.

**Is this vulnerability really serious enough to deserve a name, a logo and a web page?**

It is a vulnerability in the TLS specification, so we think...yes. In addition, it was fun to create them :)

**How can I contact you?**

You can contact us via mail or twitter:

*   Robert Merget, Ruhr University Bochum, @ic0nz1, \[email protected\]
*   Marcus Brinkmann, Ruhr University Bochum, @lambdafu, \[email protected\]
*   Nimrod Aviram, Tel Aviv University, @NimrodAviram, \[email protected\]
*   Juraj Somorovsky, Paderborn University, @jurajsomorovsky, \[email protected\]
*   Johannes Mittmann, Bundesamt für Sicherheit in der Informationstechnik (BSI)
*   Jörg Schwenk, Ruhr University Bochum, @JoergSchwenk, \[email protected\]

CVE-2020-12413: Raccoon Attack

Incorrect calculation in microcode keying mechanism for some 3rd Generation Intel(R) Xeon(R) Scalable Processors may allow a privileged user to potentially enable information disclosure via local access.

**Select Your Region**

Sign In to access restricted content

**Using Intel.com Search**

You can easily search the entire Intel.com site in several ways.

*   Brand Name: **Core i9**
*   Document Number: **123456**
*   Code Name: **Alder Lake**
*   Special Operators: **“Ice Lake”, Ice AND Lake, Ice OR Lake, Ice\***

**Quick Links**

You can also try the quick links below to see results for most popular searches.

*   Product Information
*   Support
*   Drivers & Software

**Recent Searches**

Sign In to access restricted content

**Advanced Search**

**Only search in**

Title Description Content ID

Sign in to access restricted content.

The browser version you are using is not recommended for this site.  
Please consider upgrading to the latest version of your browser by clicking one of the following links.

*   Safari
*   Chrome
*   Edge
*   Firefox

**3rd Generation Intel® Xeon® Scalable Processors Advisory**

**Summary: **

A potential security vulnerability in some 3rd Generation Intel® Xeon® Scalable Processors may allow information disclosure.  Intel is releasing firmware updates to mitigate this potential vulnerability.

**Vulnerability Details:**

CVEID: CVE-2022-33972

Description: Incorrect calculation in microcode keying mechanism for some 3rd Generation Intel(R) Xeon(R) Scalable Processors may allow a privileged user to potentially enable information disclosure via local access.

CVSS Base Score: 6.1 Medium

CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N

**Affected Products:**

**Product Collection**

**Vertical Segment**

**CPU ID**

**Platform ID**

3rd Gen Intel® Xeon® Scalable processor family

Server

606A6

0x87

**Recommendations:  
**

Intel recommends that users of affected 3rd Generation Intel® Xeon® Scalable Processors update to the latest version of firmware provided by the system manufacturer that addresses these issues. 

Intel has released microcode updates for the affected Intel® Processors that are currently supported on the public github repository. Please see details below on access to the microcode: 

GitHub\*: Public Github: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files

Details on the microcode loading points can be found at:

https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/loading-microcode-os.html

This CVE requires a Microcode Security Version Number (SVN) update. To address this vulnerability, a SGX TCB recovery is planned, refer here for more information on the SGX TCB recovery process.  

**Acknowledgements:**

Intel would like to thank Microsoft for reporting this issue.

Intel, and nearly the entire technology industry, follows a disclosure practice called Coordinated Disclosure, under which a cybersecurity vulnerability is generally publicly disclosed only after mitigations are available.

**Revision History**

Revision

Date

Description

1.0

02/14/2023

Initial Release

**Legal Notices and Disclaimers**

Intel provides these materials as-is, with no express or implied warranties.

All products, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice.

Intel products and services described may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Intel products that have met their End of Servicing Updates may no longer receive functional and security updates. For additional details on support and servicing, please see this help article. 

Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at http://intel.com.

Some results have been estimated or simulated using internal Intel analysis or architecture simulation or modeling, and provided to you for informational purposes. Any differences in your system hardware, software or configuration may affect your actual performance.

Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

\*Other names and brands may be claimed as the property of others.  

Copyright © Intel Corporation 2022

**Report a Vulnerability**

If you have information about a security issue or vulnerability with an **Intel branded product or technology**, please send an e-mail to secure@intel.com. Encrypt sensitive information using our PGP public key.

Please provide as much information as possible, including:

*   The products and versions affected
*   Detailed description of the vulnerability
*   Information on known exploits

A member of the Intel Product Security Team will review your e-mail and contact you to collaborate on resolving the issue. For more information on how Intel works to resolve security issues, see:

*   Vulnerability handling guidelines

For issues related to Intel's external web presence (Intel.com and related subdomains), please contact Intel's External Security Research team.

**Need product support?**

If you...

*   Have questions about the security features of an Intel product
*   Require technical support
*   Want product updates or patches

  
Please visit Support & Downloads.

*   Report a Vulnerability
*   Product Support

Tag

#microsoft