• Cisco Talos has been closely monitoring the abuse of cascading style sheets (CSS) properties to include irrelevant content (or salt) in different parts of messages, a technique known as hidden text salting. 
• This blog is a follow-up to our previous reports in January and March 2025 on CSS abuse in emails and shares highlights from a talk given at Blue Team Con 2025.
• Talos explores why hidden text salting is used, where it typically appears in emails, the types of content and techniques involved, how common content concealment (including hidden text salting) is in both spam and legitimate messages, and the impact that hidden text salting has on email security solutions.
• There is widespread use of hidden text salting in malicious emails to bypass detection. Attackers embed hidden salt in the preheader, header, attachments and body — using characters, paragraphs and comments — by manipulating text, visibility and sizing properties. Talos has observed that hidden content is far more often found in spam and other email threats than in legitimate emails, posing a substantial challenge to both basic and advanced email defense solutions that leverage machine learning.

In a legitimate context, cascading style sheets (CSS) are widely used to control the appearance and layout of content in emails. CSS allows for the styling of text, images and other elements in ways that enhance the visual appeal, readability and branding of the message.

However, Cisco Talos has observed a rise in the abuse of CSS by the addition of irrelevant content to different parts of emails – a technique known as hidden text salting – for a variety of purposes. In the following blog, we share key findings with the community. This analysis is the result of over one year (March 1, 2024 – July 31, 2025) of continuous monitoring of how adversaries employ this technique in their attacks.

Why do threat actors employ hidden text salting?

Talos has observed hidden text salting being used to evade detection directly and indirectly by influencing other components of the detection pipeline, such as email language detection.

The example in Figure 1 is a scam message that impersonates PayPal. In this case, some hidden text has been added to the email to evade detection.

When the HTML source of the above email is inspected, one can find the sentence “Great news, we’ve got your order,” which is hidden using different CSS properties.

When the “font-size” property of the above “div” (i.e., the container for hidden text) is increased from 1px to 20px, and the “line-height” is removed, the hidden text becomes visible in the top left corner.

Hidden text salting has also been used to confuse language detection procedures, thus evading possible spam filters that rely on such procedures. The example in Figure 4 shows a phishing email that impersonates the Harbor Freight brand. The language of this email is visibly English.

When the HTML source of the above email is inspected, several French words are found that are visually hidden. In this case, threat actors have used the “display” property of the “div” element to hide the French words, thus confusing the language detection module of Microsoft. The LANG field specifies the language in which the message was written, and the “X-Forefront-Antispam-Report” header contains information about the message and how it was processed. This header is added to each message by Exchange Online Protection (EOP), Microsoft’s cloud-based filtering service.

What are the most frequent parts of an email where hidden salt is added?

Cisco Talos has identified four main places where hidden salt is added in emails: the preheader, header, attachments and the email body.

The first two – and least common – places where salt has been added to email threats are the preheader and header. The preheader is a short text that appears after the subject line when an email is viewed in the inbox preview of most email clients. For example, Figure 6 displays a phishing email impersonating the Blue Cross Blue Shield organization.

When the HTML source of the above email is examined, one can identify the phrase “FOUR yummy soup recipes just for you!” in the preheader of this message. Most email templates enable threat actors to add preheader text to their emails, which allows attackers to entice readers with additional information.

In this example, the attacker has set the CSS “opacity” property to zero, making the element fully transparent and invisible. Note that this preheader text is kept hidden by relying on multiple CSS properties, including “color,” “height,” “max-height,” and “max-width.” Additionally, the “mso-hide” property is set to all to make the preheader invisible in Outlook email clients.

A third place where hidden text has been added is in attachments. One of the most popular techniques is to introduce irrelevant characters into HTML attachments to hinder the static analysis of files. Figure 8 shows an example phishing email that was sent to a Cisco customer who employed Cisco Secure Email Threat Defense (ETD).

A snippet of the HTML attachment from the above email is shown in Figure 9, in which threat actors have inserted multiple irrelevant comments between the Base64-encoded characters to complicate the URL decoding process.

The fourth and most common place where threat actors add salt is the email body. Figure 10 shows a phishing email that impersonates the Wells Fargo brand.

A close inspection of the HTML source of the above email reveals how raw keywords are salted with hidden characters in multiple places within the body of the email to evade detection.

What are the most common types of content used as salt?

Cisco Talos has identified three types of content that are used as salt most frequently: characters, paragraphs and comments.

When characters are used as salt, they are most often created randomly and are inserted between keywords that may be used in signatures (as seen in Figures 11 and 12). This simple technique increases the success rate of email campaigns significantly. One method used very frequently is applying a fixed-length set of random characters between important keywords. The other method involves adding special characters, such as Zero-Width SPace (ZWSP) and Zero-Width Non-Joiner (ZWNJ), between the letters that attackers would think defense solutions may pivot on for their detection, such as brand names. The example in Figure 12 is a phishing email that impersonates the Norton LifeLock brand.

The HTML source snippet of the above email shows how threat actors have added ZWSP and ZWNJ characters between the letters of Norton LifeLock to evade detection. Although these characters are not visible to the naked eye, they are still recognized as characters or strings of characters by most email parsers.

When paragraphs are used as hidden salt, they normally contain irrelevant sentences or information that is not related to the visible content of the message. The example in Figure 14 is a spear phishing email sent to a Cisco Secure ETD customer in February 2025. The HTML attachment of this message contains a series of German phrases that do not form coherent or grammatically correct sentences, and these are made invisible to the recipient via hidden text salting.

The above email also contains the phrase “with regard” in two other languages, including Finnish and Estonian. The rendered HTML attachment is also shown in Figure 15. Note that the attacker tries to convince the recipient to click on the button and view the document by displaying a Microsoft SharePoint logo.

When the HTML source of the attachment is inspected, one can see the CSS properties employed in various ways to conceal the irrelevant German paragraphs.

Threat actors also frequently use comments as salt in emails. Particularly, they are often applied to HTML attachments to evade detection by static analysis of files. The example in Figure 17 is a spear phishing email sent to a Cisco Secure ETD customer in September 2024.

The HTML source snippet of the attachment is shown in Figure 18. In this case, several irrelevant comments are added between strings and key identifiers in the JavaScript contained in the HTML attachment. This is a clear attempt to make static analysis of the attachment more difficult and evade detection.

The HTML source snippet of the above spear phishing email’s attachment shows how comments are added to JavaScript to complicate the static analysis of the HTML attachment.

What are the most common methods for hiding salt in emails?

Several ways exist to hide salt in emails, and attackers rely on various CSS properties to add irrelevant content to different parts of emails while making it visually invisible to recipients. In this section, we cover the most popular methods we’ve observed in the wild.

Cisco Talos has identified three major categories of properties that have been abused to hide added salt in emails most frequently: text properties, visibility and display properties, and clipping and sizing properties.

Text properties in CSS allow threat actors to change the characteristics of text, including font size, color, height and width. One simple technique Talos has observed is setting the “font-size” property to a very small number, if not zero, to make text almost invisible to the naked eye. Another common method is to make the font color match its background color.

Visibility and display properties help threat actors conceal content by changing the display properties of messages. One popular approach is to set the “opacity” property to zero, making the content transparent and invisible to the recipient. Another frequent method is to set the “display” property to “none,” which removes the element (e.g., text or image) from the email without affecting the layout. Alternatively, an element’s visibility is often turned off by setting the “visibility” property to “hidden.”

CSS properties can also be used to change the size of a container element. These elements (e.g., a text box) act as containers for other elements in emails. Additionally, CSS properties can be used to clip elements in emails (e.g., clipping text into a circle or rectangle). Threat actors abuse both of these properties to hide salt in emails. One popular method Talos has observed is setting the “width” property of the container element — the area that contains salt — to zero. Another method is to force the added salt to overflow the container element (e.g., by placing large text into a circle with radius zero) and then leverage CSS properties to control the behavior when content extends beyond the container’s boundaries. For example, in one campaign, the added salt was made invisible by clipping it in a tiny rectangle and setting the “overflow” property to “hidden.”

How prevalent is content concealment in spam and ham messages?

Talos has observed that content concealment using CSS properties occurs much more frequently in spam messages and email threats than in legitimate emails (ham). Talos selected a few simple CSS properties that can be used to hide the added salt, including “font-size: 0,” “opacity: 0,” “display: none,” “max-width: 0,” “max-height: 0,” “color: transparent,” “visibility: hidden,” “width: 0” or “height: 0.” We then searched for these indicators in emails reclassified by Cisco Secure ETD customers. Figure 19 demonstrates the distribution of spam (including phishing and other types of email threats) and ham messages that contained any of these CSS properties between July 30 and September 1, 2025 (approximately 1 month).

Note that the above plot also includes cases where CSS properties are used to hide tracking pixels or images — a technique most often used in legitimate messages as well, such as those sent in marketing campaigns. Also, note that the use of CSS properties like the ones we discussed in the previous section are not limited to hiding content, and are sometimes used in ham emails to achieve a responsive email design. In this case, emails contain multiple layouts, and the appropriate one is displayed to recipients based on their device or screen size (see the example shown below). This indicates that the abuse of CSS properties to introduce irrelevant text (or salt) to emails is very frequently, if not always, observed in spam messages rather than in ham messages.

What is the potential impact of hidden text salting on email threat defense solutions?

The impact of hidden text salting on email defense solutions is underexplored. This section considers the potential impact of this technique on simple and advanced defense solutions, using real-world examples.

Let’s assume a threat model where adversaries have no prior knowledge about the features that are used by email defense solutions to detect different types of threats. Their goal is to target one or more employees who are working for an organization of interest and whose mailboxes are protected using a particular email defense solution.

Threat actors may guess that one or more of the features used to differentiate email threats from legitimate messages are derived from keywords extracted by directly parsing the HTML source of emails. Therefore, they may decide to add some irrelevant content to the body of messages to evade detection. The example below shows a spear phishing email that impersonates the CapitalOne brand and was sent to a target individual in January 2025. As is clear, some salt has been added to this message and has been made invisible using CSS properties in an effort to bypass detection.

Threat actors may guess that HTML tags have also been used as extra features in the detection pipeline in addition to keywords, and thus, they may decide to add a large number of HTML tags to bypass detection. The example below shows a scam message that impersonates the Costco Wholesale brand.

When the HTML source of the above email is inspected, several unnecessary HTML tags can be found in the body of the email that are made invisible and do not change the layout and appearance of the email.

In addition to features derived from keywords and the HTML source of emails, an attacker may assume that the email defense solution relies on large language models (LLMs) to extract features from emails and create a final verdict based on them. Specifically, let’s assume attackers guess that the intent and sentiment of emails are two fundamental features inferred from messages using LLMs and subsequently used in detection. The example in Figure 24 shows a phishing example that impersonates the Outlook brand and leverages hidden text salting using CSS properties to evade detection.

When examining the HTML source snippet, one notices the “Password Expiry Notice” phrase and other keywords are salted using random characters. This has been achieved using a selector, called “bdo,” defined at the beginning of the HTML document. In this selector, the “font-size” property is set to zero, which effectively hides the text by making it invisible. This selector is then applied to multiple elements throughout this HTML document.

If a small LLM model, such as GPT-4o mini, was used to determine the intent of the above message by passing the whole HTML source, the returned value would be “neutral.” From an adversarial perspective, a very small salt that is made invisible using the same selector (see the below source snippet) we saw earlier is sufficient to change the verdict of this email from “neutral” to “positive,” thereby evading detection, as shown in Figure 26.

Now, if the HTML source of the original phishing message in Figures 24 and 25 is passed to the same model, the returned sentiment would be “Request Action,” which aligns with what the recipient observes (i.e., a request for them to retain their login password). The same technique can be leveraged by attackers to include hidden salt in the body of the above email and to change the sentiment of this message from “Request Action” to “Schedule Meeting”, as shown below.

These cases are just two simple examples that show how adversaries could use hidden text salting to impact more advanced email threat detection solutions if these adversarial techniques are not well-known and new tools like LLMs are employed for defense carelessly.

Mitigations and protection

As explained with multiple examples, CSS provides a wide range of properties that can be abused by attackers to evade spam filters and detection engines. Therefore, two possible countermeasures are: first, to detect the presence of hidden text (or salt) in emails, and more importantly, to filter out the added salt before passing the message to downstream detection engines.

In what follows, we provide a few mitigation solutions for each domain.

Detection: One security mitigation solution is to rely on advanced filtering mechanisms that can more effectively detect hidden text salting and content concealment. These systems can examine different parts of emails to find and filter out hidden content. Alternatively, relying on features in addition to the text domain, such as the visual characteristics of emails, may also be helpful. This approach is particularly beneficial against image-based threats.

Filtering: With respect to discarding irrelevant content (or salt) that has been added to emails, at least two options are available. The first option is to perform HTML sanitization at ingestion in order to strip or escape invisible text before it reaches downstream detection engines. The second option is to deploy a filter (e.g., a prompt guard) in an email gateway or proxy to ignore any content that is visually hidden or styled to be invisible.

Safeguarding against these complex threats necessitates a comprehensive email security solution that utilizes AI-driven detection. Secure Email Threat Defense employs distinctive deep learning and machine learning models, incorporating Natural Language Processing, within its sophisticated threat detection systems.

Secure Email Threat Defense detects harmful techniques employed in attacks against your organization, extracts unmatched context for particular business risks, offers searchable threat data, and classifies threats to identify which sectors of your organization are most at risk of attack.

Begin strengthening your environment against sophisticated threats. Register now for a free trial of Email Threat Defense.

Takeaways

Talos has observed hidden text salting being used either to evade detection directly or indirectly by influencing other components of the detection pipeline, such as email language detection, which may exist and impact downstream engines. We have identified four main places where hidden salt is added in emails: the preheader, header, attachments, and the email body. Talos has identified three types of content that are most frequently used as salt: characters, paragraphs, and comments. We have also identified three major categories of properties that have been abused to hide the added salt in emails: text properties, visibility and display properties, and clipping and sizing properties. This technique is significantly more prevalent in spam messages and email threats compared to legitimate emails and can have a significant impact on both simple and advanced email threat defense solutions if appropriate countermeasures are not employed.

Cisco Talos Blog – ​Read More

To evade detection by security solutions, cybercriminals employ various techniques that mask their malicious activity. One of the methods increasingly seen in recent years in attacks on Windows systems is DLL hijacking: replacing dynamic-link libraries (DLLs) with malicious ones. And traditional security tools often don’t detect use of this technique. To solve this problem, our colleagues from the Kaspersky AI Technology Research Center developed a machine-learning model that can detect DLL hijacking with high accuracy. This model has already been implemented in the latest release of our SIEM system, the Kaspersky Unified Monitoring and Analysis Platform . In this post, we explain the challenges of detecting DLL hijacking, and how our technology addresses them.

How DLL hijacking works and why it’s hard to detect

The sudden launch of an unknown file in a Windows environment inevitably draws the attention of security tools — or is simply blocked. Essentially, DLL hijacking is an attempt to pass off a malicious file as a known and trusted one. There are several variations of DLL hijacking: one is when attackers distribute a malicious library along with legitimate software (DLL sideloading) so that the software executes it; another is when they replace standard DLLs that are called by already-installed programs on the computer; and there’s also when they manipulate system mechanisms that determine the location of the library that a process loads and executes. As a result, the malicious DLL file is launched by a legitimate process within its own address space and with its own privileges; thus the usual endpoint protection systems view this activity as looking legitimate. That’s why our experts decided to counter this threat with the use of AI technologies.

Detecting DLL hijacking with ML

AI Technology Research Center experts trained an ML model to detect DLL hijacking based on indirect information about the library and the process that called it. They identified key indicators of an attempt to manipulate a library: whether the executable file and the library are located in standard paths, whether the file was renamed, whether the library’s size and structure have changed, whether its digital signature is intact, and so on. They initially trained the model on data about dynamic link libraries’ being loaded — sourced from both internal automatic analysis systems and anonymized telemetry from the Kaspersky Security Network (KSN) voluntarily provided by our users. For labeling, our experts used data from our file reputation databases.

The first model was rather inaccurate, so before adding it to the solution our experts experimented through multiple iterations, refining both the labeling of the training dataset and the features that indicate DLL hijacking. As a result, the model now detects this technique with high accuracy. On Securelist, our colleagues published a detailed article about how they developed this technology — from the initial hypothesis, through testing in Kaspersky Managed Detection and Response, and finally to the practical application in our SIEM platform.

DLL hijacking detection in Kaspersky SIEM

In the SIEM system, the model analyzes the metadata of loaded DLLs and processes that called them from the telemetry, flags suspicious cases, and then cross-checks its verdict against KSN cloud data. This not only improves the accuracy of DLL hijacking detection, but also reduces false positives. The model can operate in both the correlation subsystem and the event collection subsystem.

In the first case, it checks only the events that have already triggered correlation rules. This allows for a more precise threat assessment and faster alert generation if needed. Since not all events are checked, the volume of cloud queries doesn’t significantly impact the model’s response speed.

In the second case, the model processes all library loading events that meet certain conditions. This method consumes more resources but is invaluable for retrospective threat hunting.

In another Securelist blog post, colleagues from the Anti-Malware Research group described in detail how the DLL hijacking detection model helps Kaspersky SIEM catch targeted attacks, with real examples of early incident detection.

Most importantly, the model’s accuracy will only continue to improve as more data on threats and legitimate processes accumulates and KSN algorithms evolve.

Kaspersky official blog – ​Read More

Welcome to this week’s edition of the Threat Source newsletter, and happy Cybersecurity Awareness Month.

Like everyone under the age of 35 who has at least one father, my dad sends me advice on online safety at least once a week. Does he work in information security? No. He’s a recently retired high school audio engineering teacher, who now spends his days touring with a yacht rock cover band and building guitars. But throughout his life, he’s been a true Renaissance man. From playing trombone on a Bruce Springsteen tour to building our backyard deck, to Roth IRA advice, to the history of Bell Labs, the breadth of his knowledge astounds me. I actually called him last week to find out just how long I can drive my car before taking it to the mechanic to get the oxygen sensor fixed.

There is one area where I think I have him beat: cybersecurity. Not by a lot, but I think working in Talos has given me an edge — or, at least, access to people who can tell me how worried I should be about an issue that Facebook is having a field day with.

Still, that doesn’t stop him from sending me a steady stream of headlines and warnings. Here are just a few that my dad has sent me:

• Jan. 31, 2024: An NBC news clip of former FBI Director Christopher Wray disclosing alarming hacking threats to critical U.S. infrastructure, also mentioning the takedown of Volt Typhoon. 
• Sept. 19, 2024: An article explaining that if you’re shopping online and your credit card gets declined, you may be getting scammed. 
• May 1, 2025: A video warning that “QR codes in mystery packages could steal your identity.” 
• June 22, 2025: This video about hidden watermarks embedded in AI-generated content. Not nearly as menacing as the others (unless you’re a college student trying to coast), but it is fascinating. This article gives a deeper understanding. 

Even without deep investigation, these headlines reveal a lot about how cybersecurity anxieties are shared and amplified on social media. It’s a cycle that’s probably familiar to a lot of us: technology keeps evolving, but the impulse to protect each other never really changes. Whether you’re the IT help desk for your family or the one receiving those late-night warnings (or both), every message is a chance to share knowledge, calm fears, and help each other navigate a world that’s always shifting under our feet.

So, the next time your dad (or mom, or aunt, or grandma) sends you a link that sounds a little far-fetched, take a moment to appreciate the intent behind it. They might not always get the details right, but their concern is real. In its own way, that’s another layer of security.

Breathe in, let it out, and let’s dive in.

The one big thing 

Cisco Talos has uncovered a Chinese-speaking cybercrime group, UAT-8099, that is hacking into reputable Internet Information Services (IIS) servers in countries like India, Thailand, Vietnam, Canada, and Brazil. Their main goals are to manipulate search results for profit and steal sensitive data, such as credentials and certificates, often using advanced tools and custom malware to avoid detection. The group maintains long-term access to these servers and protects their control from other attackers.

Why do I care? 

Cybercriminals are evolving to target trusted infrastructure for both financial gain and deeper access to valuable data. The use of automation, custom malware, and persistence techniques in this campaign shows UAT-8099 can impact a wide range of organizations.

So now what? 

Review your environments for signs of BadIIS malware, unauthorized web shells and suspicious RDP or VPN activity on IIS servers. Also, strengthen server defenses, monitor for unusual traffic and share indicators of compromise (IOCs) within the security community to help prevent further attacks.

Top security headlines of the week 

CISA 2015 cyber threat info-sharing law lapses amid government shutdown 
Defenders have lost the information-sharing liability protection the bill provided, and the government has lost a lot of visibility into threats emerging across the private sector. (CSO) 

Cyberattack on JLR prompts £1.5B UK government intervention 
The announcement Sunday says that the support package is meant to “give certainty to its supply chain following a recent cyber-attack.” Some experts believe the bailout will encourage cybercriminals to continue targeting UK companies with weak cybersecurity. (Security Week) 

Neon pays users to record their phone calls and sells data to AI firms 
Unbelievably, this app was spotted in the No. 2 spot in Apple’s U.S. App Store’s Social Networking section. Their marketing claims to only record your side of the call unless it’s with another Neon user. (TechCrunch) 

“Klopatra” trojan makes bank transfers while you sleep 
A sophisticated new banking malware is hard to detect, capable of stealing lots of money, and infecting thousands of people in Italy and Spain, under the guise of a pirate streaming app. (Dark Reading) 

Can’t get enough Talos? 

Talos Takes: You can’t patch burnout 
October is Cybersecurity Awareness Month, but what happens when the defenders themselves are overwhelmed? In this powerful episode, Hazel and Joe Marshall get real about why protecting your well-being is just as vital as any technical defense. 

The TTP: Threat Hunter’s Cookbook 
Hear from Ryan Fetterman and Sydney Marrone from the SURGe team (now part of Cisco’s Foundation AI group), who wrote the Threat Hunter’s Cookbook: a collection of practical “recipes” security teams can pick up and apply. 

Engaging Cisco Talos Incident Response  
You’ve called Talos IR about a cyber incident — now what happens? This blog post takes you behind the scenes of a Talos IR engagement, from picking up the phone to recovery and implementation of long-term security improvements.  

Upcoming events where you can find Talos 

• Wild West Hackin’ Fest (Oct. 8 – 10) Deadwood, SD 
• DEEP Conference (Oct. 22 – 23) Petrčane, Croatia 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: d933ec4aaf7cfe2f459d64ea4af346e69177e150df1cd23aad1904f5fd41f44a  
MD5: 1f7e01a3355b52cbc92c908a61abf643  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=d933ec4aaf7cfe2f459d64ea4af346e69177e150df1cd23aad1904f5fd41f44a  
Example Filename:cleanup.bat  
Detection Name: W32.D933EC4AAF-90.SBX.TG 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
Example Filename:VID001.exe  
Detection Name: Win.Worm.Coinminer::1201 

SHA256: 41f14d86bcaf8e949160ee2731802523e0c76fea87adf00ee7fe9567c3cec610  
MD5: 85bbddc502f7b10871621fd460243fbc  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=41f14d86bcaf8e949160ee2731802523e0c76fea87adf00ee7fe9567c3cec610  
Example Filename:85bbddc502f7b10871621fd460243fbc.exe 
Detection Name: W32.41F14D86BC-100.SBX.TG 

SHA256: 3d8eeb6df4a2d777f18d0f15b19cd9666a78927013b8359c883bff423d9faaec  
MD5: 5b7948e7ca9742a33be8403b3285a1aa  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=3d8eeb6df4a2d777f18d0f15b19cd9666a78927013b8359c883bff423d9faaec  
Example Filename:onestart.exe  
Detection Name: W32.3D8EEB6DF4-95.SBX.TG 

SHA256: c0ad494457dcd9e964378760fb6aca86a23622045bca851d8f3ab49ec33978fe  
MD5: bf9672ec85283fdf002d83662f0b08b7  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=c0ad494457dcd9e964378760fb6aca86a23622045bca851d8f3ab49ec33978fe  
Example Filename:f_04b985.html  
Detection Name: W32.C0AD494457-95.SBX.TG 

Cisco Talos Blog – ​Read More

“Hi! My niece is in a contest! Can you vote for her? It means the world to her”. Messages like this are common on WhatsApp — both in groups and private chats. Many people who aren’t security-savvy will, without a second thought, click to help someone they don’t actually know — and end up losing their account. In a recent investigation we found a new phishing campaign that has already hit WhatsApp users worldwide.

Today we’ll explain how the attack works, the potential consequences for victims, and how to avoid falling for it.

How the attack works

Cybercriminals first prepare for the attack by creating convincing phishing pages purportedly hosting legitimate voting polls — in the example below for young gymnasts, though the scenario can be easily changed. The pages look genuine: they include photos of real participants, Vote buttons and counters showing how many people have voted. Likely using AI and phishing-kits, the attackers easily produce multiple language versions of the same site — we found the identical poll in English, Spanish, German, Turkish, Danish, Bulgarian, and other languages.

Stage One: The Hook. On social networks, in messengers, or by email, the scammers use social engineering to direct you to a fake voting site. The pretext can be very believable, and the message may come from a friend or relative whose account has already been compromised. The request is usually personalized — in the first message the fraudster posing as your acquaintance asks you to vote for a certain contestant because they’re their charge, friend or relative.

First you’re lured to a fake voting page

Stage Two: The Trap. When you click Vote, you’re taken to a page that asks you to quickly authenticate via WhatsApp. All you need do is enter the phone number linked to your messenger.

Next they ask for your phone number associated with WhatsApp. The scammers even pretend to care about your data and “your valuable time”

Stage Three: The Heist. The attackers exploit the one-time code login feature in WhatsApp Web. They enter the phone number you provided, and WhatsApp generates an eight-character single-use verification code. The attackers immediately display that code on the fake site with instructions: open WhatsApp, go to “Connected devices” (never mind that it’s actually “Linked devices” in WhatsApp), and enter the code. For convenience, there’s even a button to copy the code to the clipboard.

For “fast and easy authorization” (read: WhatsApp account takeover) you only need enter the code shown on the site

At the same time, WhatsApp on your phone shows a prompt to link a new device by entering the code. Clicking that opens a warning that someone is trying to connect to your account, and a field to enter the code.

Unfortunately, in their uncontrollable desire to help a complete stranger in the contest, many users don’t carefully read WhatsApp’s warning. They think, “Someone wants to link to my account? That’s so I can vote — looks fine to me” When the careless victim types the code into the app on their phone, the web session initiated by the attackers is activated.

WhatsApp warns you that someone is trying to link to your account, but many users don’t read the warning, and enter the verification code anyway

If you enter that code, the attackers gain full access to your WhatsApp, as if you had logged in yourself — for example, from a computer alongside your phone. The attackers can view all your contacts, read conversations, send and delete messages in your name, and even take full control of the account. That opens up further possibilities for fraud: somehow extracting money from your contacts using your identity, or using your account to spread the same phishing link that trapped you.

What to do if you think you’ve been hacked

If you suspect you’ve fallen for the scam and given attackers access to your WhatsApp account, the first thing to do is open the WhatsApp settings on your smartphone and go to Linked devices. There you’ll see all devices currently logged into your account. If you notice any unfamiliar devices or browsers, click on them to disconnect them from your account. Do this quickly — before the criminals can fully take over your account.

We’ve prepared a detailed guide for such cases: it explains eight signs your WhatsApp account may be hacked, and provides step-by-step instructions on how to regain access even in difficult situations. We also have a similar guide for Telegram users.

How to prevent your WhatsApp account from being hacked

• Never take part in dubious contests or votes — especially if they require messenger authentication. Legitimate polls don’t ask for access to your personal accounts.
• Don’t click suspicious links in messages — even if they seem to come from friends or relatives. Their accounts may have been hacked.
• Never enter personal data on unfamiliar websites — especially those reached via messages or social media links. Always check the URL carefully.
• Don’t ignore browser warnings about unsafe sites, and use Kaspersky Premium on all your devices (both smartphones and computers). Our protection scans links and webpages, blocks phishing and malicious resources, and works in all popular mobile and desktop browsers.
• Enable two-factor verification in your WhatsApp settings. This makes a six-digit PIN code necessary to log in on a new device, making attackers’ job harder even if your number is compromised. However, this doesn’t protect against the attack described above — the one-time code shown to you is, in WhatsApp’s view, already the “second factor”. That’s why the PIN isn’t requested during this login method.
• Use passkeys instead of traditional passwords wherever possible. WhatsApp already supports passkeys for account verification.
• Protect mobile devices from phishing — these are the main targets of messenger attacks. Three-level protection technology detects malicious links and blocks dangerous websites. At the first level, Notification Protection detects and automatically removes malicious links from app notifications, leaving only safe text. Next, Safe Messaging blocks harmful links in SMSs and messenger messages (WhatsApp, Viber, Telegram) before the user clicks them. Finally, Safe Browsing blocks malicious URLs in popular mobile browsers.
• Configure privacy and security on both your smartphone and computer with Privacy Checker — Kaspersky’s free service that gives detailed guides for privacy settings in many popular apps, services, and operating systems.
• Set up WhatsApp and Telegram accounts for maximum protection against hijacking using our step-by-step guide.
• Regularly check the list of connected devices in messengers’ settings. Both WhatsApp and Telegram have sections showing all active sessions, and you can disconnect suspicious ones. In Telegram, you can even enable automatic termination of inactive sessions.
• Only use official versions of messengers downloaded from official app stores (such as Google Play, App Store, or Galaxy Store). Modified versions can contain malware.
• Be extra cautious with desktop versions of messengers — especially on work computers.

How else do attackers target messengers, and how to counter them?

• How to protect WhatsApp and Telegram against hijacking in 2025
• Telegram scams with bots, gifts, and crypto
• Is it the boss — or is it a fraudster? Scams disguised as urgent orders from top brass
• Spyware messengers on Google Play
• What makes a messaging app secure?

Kaspersky official blog – ​Read More

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed five vulnerabilities in Nvidia and one in Adobe Acrobat.

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, all in adherence to Cisco’s third-party vulnerability disclosure policy.    

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.     

Nvidia vulnerabilities

Discovered by Dimitrios Tatsis of Cisco Talos.

Nvidia is a large technology company developing graphics cards, chip systems, and applications for AI and high performance computing. Talos has found 5 vulnerabilities in the CUDA Toolkit, a development environment for developing GPU-accelerated applications.

TALOS-2025-2155 (CVE-2025-23339) is an arbitrary code execution vulnerability in the DWARF parsing functionality of NVIDIA cuobjdump 12.8.55. A specially crafted fatbin file can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.

TALOS-2025-2169 (CVE-2025-23338) is an improper array index validation vulnerability in the symbol table parsing functionality of NVIDIA nvdisasm 12.8.90. A specially crafted ELF file can lead to an out-of-bounds write. An attacker can provide a malicious file to trigger this vulnerability.

TALOS-2025-2172 (CVE-2025-23340) is an out-of-bounds write vulnerability in the RELA section parsing functionality of NVIDIA nvdisasm 12.8.90. A specially crafted ELF file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

TALOS-2025-2191 (CVE-2025-23271), a heap-based buffer overflow vulnerability, and TALOS-2025-2204 (CVE-2025-23308), an out-of-bounds write vulnerability, exist in the REL section header parsing functionality of NVIDIA nvdisasm 12.8.90. Specially crafted ELF files can lead to arbitrary code execution. An attacker can provide a malicious file to trigger these vulnerabilities.

Adobe use-after-free vulnerability

Discovered by KPC of Cisco Talos.

Adobe Acrobat Reader is one of the most popular PDF reading software currently available.

Talos discovered TALOS-2025-2222 (CVE-2025-54257), a use-after-free vulnerability in the page property functionality of Adobe Acrobat Reader 2025.001.20531. Specially crafted Javascript code inside a malicious PDF document can trigger reuse of a previously freed object, which can lead to memory corruption and could result in arbitrary code execution. An attacker needs to trick the user into opening the malicious file to trigger this vulnerability.

Cisco Talos Blog – ​Read More