Editor’s note: The current article is authored by Clandestine, threat researcher and threat hunter. You can find Clandestine on X. 

ANY.RUN’s Threat Intelligence (TI) Lookup is a powerful service for Open Source Intelligence (OSINT) and Threat Intelligence investigations. In this research, we shall analyze 5 specific queries, each targeting different aspects of the threat landscape, to better understand the nature of modern threats as well as defense and response strategies.  

Key Findings 

1. JA3S Fingerprinting underscores the value of behavioral indicators in hunting advanced threats allowing analysts to track Command and Control infrastructure even when attackers rotate IP addresses and domains 

2. Massive abuse of legitimate infrastructure (AWS, Google Cloud, Cloudflare, Microsoft services) complicates detection, as malicious traffic blends with legitimate services. 

3. Locally targeted phishing operations demonstrate that attackers tailor their strategies by geography. This highlights the importance of localized cyber threat intelligence. 

4. By combining sandbox detonation with TI Lookup queries, analysts uncover trojan traffic disguised within HTTPS (port 443). This methodology proves the benefit of correlating behavioral analysis with IOC-based searches. 

5. The .top domain extension serves as a thriving ecosystem for cybercrime, with randomly-generated DGA domains used for malware delivery, often leveraging WinRAR for payload extraction. 

Exploring Beyond IOCs: Malicious Pattern Case Studies  

ANY.RUN’s Threat Intelligence (TI) Lookup is a dynamic, searchable database that equips security analysts with immediate access to over 50 million Indicators of Compromise (IOCs), Behavior (IOBs), and Attack (IOAs) and threat events extracted from real-time malware sandbox analyses conducted by a global community of over 500,000 analysts and 15,000 companies.  

Tailored for threat hunting, alert triage, and incident response, it allows analysts to query the database using more than 40 parameters – including hashes, IPs, registry keys, processes, and TTPs. It supports search operators, wildcards, YARA and Suricata rules, and notifies on updates on saved searches.  

Let’s see how analysts can use it as part of their OSINT investigation. 

Case 1: Investigating Regionalized Phishing Campaigns 

Query: threatName:”Phishing” AND submissionCountry:”br” and domainName:”” 

We can start by checking for active phishing campaigns targeting organizations in our region. Even with a free plan, TI Lookup provides us with lots of sandbox analyses of the latest malicious domains and emails sent to companies in Brazil.  

We can also observe legitimate infrastructure abuse as a number of known service subdomains are linked to the campaigns along with malicious domains. Globally hosted infrastructure is leveraged to hinder takedown.  

Actionable Intelligence: Organizations in Brazil should be especially alert to emails containing links to subdomains of popular services. Security teams can use the identified domains and IPs to create proactive defense using detection and blocking rules. 

Case 2: Tracking C2 Infrastructure with JA3S 

Query: ja3s:”1af33e1657631357c73119488045302c” 

The JA3S hash is a fingerprint of how a TLS client communicates. Different malware or attack tools may have unique JA3S signatures, allowing analysts to track their Command and Control (C2) infrastructure even when IP addresses and domains change. Hash “1af33e1657631357c73119488045302c” is commonly associated with Cobalt Strike.  

What do we capture from the search results?  

• 1,000+ system events mostly involving slui.exe (System License User Interface), svchost.exe, and PowerShell.   

• Predominant communication on port 443 (HTTPS) exposes evasion techniques exploiting LOLBins. 

• Abuse of major cloud providers to host C2 infrastructure (Microsoft, GitHub, Google, Amazon, CloudFlare). 

• Techniques: Use of legitimate system tools for malicious execution. 

Actionable Intelligence: Detection of this JA3S hash on the network is a strong indicator of Cobalt Strike infection or an abuse of a similar tool. Security teams should correlate these alerts with other endpoint and network events to identify compromised systems and initiate incident response. 

TI Lookup’s “Analyses” tab contains links to sandbox analyses of malware samples featuring the hash in question. We can sort out samples tagged as “malicious” and study various attack scenarios leveraging similar TTPs:  

For example, one can view a Cerber ransomware attack and see how it abuses system tools and cloud services.  

Case 3: Hunting Trojan Traffic Camouflaged in HTTPS 

Query: destinationIPgeo:”ru” AND suricataClass:”trojan” AND destinationPort:”443″ 

This query is a classic example of threat hunting. It doesn’t look up a specific IOC but rather searches for a suspicious behavior pattern: traffic classified as trojan by the Suricata engine, destined for IPs in Russia and using port 443 (HTTPS). 

Russia is generally a suspicious communication destination, and port 443 is used to camouflage malicious traffic. The attack strategy includes threat diversity: multiple services and legitimate domains are abused; various ports are employed for communication and fallback.

 
Actionable Intelligence: This query provides a list of high-risk IPs and domains for enriching perimeter defenses. The combination of destination geolocation, threat classification, and communication port is a powerful hunting methodology. 

TI Lookup has found a number of analysis sessions demonstrating this behavior pattern.  

View an example in the Sandbox 

Case 4: Unmasking BEC Campaigns Focused on Invoices 

Query: filePath:”invoice.pdf” OR filePath:”pagamento.pdf” 

Business Email Compromise (BEC) frauds continue to be one of the most lucrative threats. This query searches for PDF files containing the words “invoice” or “pagamento” (payment) in their name, an extremely common infection vector in BEC schemes. 

The malicious files are often hosted on Amazon S3 Buckets and named to appear legitimate. Exploring such attacks delivers file hashes to use as IOCs for detection.  
 
Actionable Intelligence: Organizations should implement email attachment verification and educate employees about fake invoice risks. The IOCs should be added to block lists, and monitoring downloads from unknown S3 buckets can be effective. 

Case 5: Identifying Malicious Activity Hotspots with TLDs  

Query: domainName:”*.top” AND threatLevel:”malicious” 

Certain Top-Level Domains (TLDs) are notoriously abused by cybercriminals due to low cost and loose regulation. The .top TLD is one of these. This query searches for all domains ending in .top that have been classified as malicious. 

Such domains, mostly generated by algorithms, support a thriving ecosystem for malicious activities. They are often used for delivering payload packed in WinRAR archives. Cloudflare services are engaged for concealing true server locations.  

Actionable Intelligence: Aware of extremely high malicious activity volume, many organizations block the .top TLD completely. The appearances of .top domains in network logs should be treated as high-priority events. 
 
Alltogether, these searches provide insight into the broader threat landscape and recent query patterns, showing the diversity of investigation approaches used in threat hunting. Threat intelligence lookups can be focused on a topical threat type (for example, phishing), legitimate tools abuse, registry modifications: queries can target both IOCs and behavioral patterns.  

Lessons Learned: Security Recommendations 

Here’s how SOC teams and threat hunters can perform an effective OSINT investigation. 

For Analysts 

• Implement multi-parameter hunting queries combining JA3S fingerprints, destination geolocation, and Suricata classifications rather than relying solely on hash or domain lookups. 

• Create detection rules for the identified JA3S hash and monitor for similar TLS fingerprinting patterns indicating Cobalt Strike or similar frameworks. 

• Monitor for traffic to non-standard ports and HTTPS-based C2 activity; correlate with TI Lookup results for stronger detection. 

• Integrate sandbox detonations into investigations to validate suspicious files, uncover hidden payloads, and gather fresh IOCs. 

 For SOC and MSSP Leaders 

• Adopt proactive hunting playbooks that leverage behavior-based patterns (e.g., phishing, malicious PDFs, LOLBins) instead of relying solely on static IOCs. 

• Automate ingestion of ANY.RUN TI Feeds and Lookup results into SIEM/SOAR platforms to strengthen correlation and reduce analyst workload. 

• Establish rules and alerts around high-risk TLDs (.top, .shop, .cc) and cloud-hosted infrastructures commonly abused by attackers. 

• Adopt a Zero Trust security model: The extensive abuse of trusted infrastructure (Microsoft, Google, Amazon domains) demonstrates that brand reputation no longer guarantees safety 

 For Business Decision Makers 

• Support employee awareness campaigns, especially for financial teams, to counter phishing and BEC attempts. 

• Recognize that cloud service abuse is now the norm in modern campaigns, so budgeting for advanced detection and monitoring is critical to maintaining resilience. 

• Budget for cyber threat intelligence solutions that provide both sandboxing and lookup capabilities—the ROI comes from preventing successful breaches through proactive threat hunting rather than reactive incident response. 

Conclusion 

This investigation highlights how modern cyber threats are increasingly sophisticated, regionalized, and reliant on abusing legitimate infrastructure to evade detection. Static IOCs alone are insufficient for defense. Security teams must embrace behavior-based detection and proactive hunting strategies.  

ANY.RUN’s TI Lookup and Sandbox provide the intelligence depth and investigative flexibility needed to uncover hidden connections, expose attacker TTPs, and accelerate incident response. Organizations that combine advanced threat intelligence solutions with strong security culture and well-trained teams will be better positioned to withstand evolving threats and reduce the cost and impact of cyber incidents. 

About ANY.RUN  

Over 500,000 cybersecurity professionals and 15,000+ companies in finance, manufacturing, healthcare, and other sectors rely on ANY.RUN to streamline malware investigations worldwide.   

Speed up triage and response by detonating suspicious files in ANY.RUN’s Interactive Sandbox, observing malicious behavior in real time, and gathering insights for faster, more confident security decisions. Paired with Threat Intelligence Lookup and Threat Intelligence Feeds, it provides actionable data on cyberattacks to improve detection and deepen your understanding of evolving threats.   

Explore more ANY.RUN’s capabilities during 14-day trial→ 

The post Phishing, Cloud Abuse, and Evasion: Advanced OSINT Investigation with ANY.RUN Threat Intelligence  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

• 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