Threats Tagged 'malware'

Maltrail IOC for 2026-08-08

Maltrail IOC for 2026-08-07

Gen's H1 2026 Threat Report examines two separate attack chains. One used compromised business inboxes and browser manipulation in a banking-malware campaign, while the other used clipboard hijacking to redirect cryptocurrency payments. [...]

Have you ever tried to open an “encrypted” email or an urgent document, only to realize with horror that your usual DOCX attachment is actually a file with the extension .docx.exe? Or maybe you received an email supposedly with an invoice, contract, or internal memo attached — only for the file to prove something entirely different from what it claimed to be? If so, you were likely targeted in a malware infection attempt. Cybercriminals routinely disguise malicious files as harmless documents and archives, banking on recipients blindly clicking without checking the extension. Kaspersky experts analyzed the file formats most frequently deployed in malicious email blasts to reveal what really lurks behind these extensions — and how attackers weaponize them in their campaigns. Important note: the extensions we’ll be discussing here are routinely used for completely legitimate files. For example, Windows executables normally end in .exe. However, we’re focusing specifically on scenarios where attackers disguise or spoof a file’s extension to pass it off as a totally different type of file. What extensions are most commonly found in malware? Our experts analyzed malicious email blasts from the beginning of 2026 to pinpoint the 15 most common dangerous file extensions. .exe .js .html .dll .bat .vbs .xls .pdf .jse .au3 .docx .htm .wsf .scr .lnk The top 15 file extensions used in malicious email blasts Let’s take a look at what files with these extensions actually do under the hood. Executable files An executable file is a compiled computer program that’s ready to run. Once launched, a malicious executable can download additional payloads, alter system settings, steal user data, connect your device to external attacker-controlled servers, and much more. These are the most common executable extensions found in malicious email campaigns: .exe .dll .com .scr .exe The classic Windows executable extension. It powers every program you use daily, from web browsers and games to office suites and software installers. By the way, attackers often wrap EXE malware in double extensions: invoice.docx.exe, report.pdf.exe, or even photo.jpg.exe. They take advantage of a default Windows setting: hiding extensions for known file types. Because this setting is turned on by default, users only see the first part of the file name — invoice.docx, report.pdf, or photo.jpg — and assume it’s just a normal document or image. But the second you open this trap file, the malware fires up. .dll Another common extension abused in malicious campaigns is .dll (dynamic-link library). These libraries hold functions that Windows programs frequently require while running, such as printing a document. This modular architecture prevents redundant code by letting multiple applications call on the exact same library for specific tasks. However, if an attacker replaces a legitimate library with an infected one, running any normal program that calls on it can trigger malicious code. .com While files with the .com extension have absolutely nothing to do with the web domain of the same name, cybercriminals likely count on victims mistaking these files for links in an unusual format. In reality, it’s a legacy Windows executable format. While modern versions of Windows no longer rely on this file type, the operating system can still run and execute it, which makes opening one a very bad idea. .scr SCR files are screensavers — those idle Windows screen animations featuring abstract patterns, the iconic bouncing logo, or whatever else. Despite their harmless reputation, screensavers are essentially executables just like EXE files: once opened, they can install extra components or alter system settings all the same. In malicious campaigns, these files routinely masquerade as images, screenshots, or documents. Scripts Scripts are text files containing a sequence of commands that a computer runs automatically in order. They can download files, install and launch programs, modify securi…

A Go-based malware delivered in ClickFix attacks targeting macOS users is stealing cryptocurrency assets, browser-stored passwords, Apple Keychain data, and cached credentials. [...]

Welcome to this week’s edition of the Threat Source newsletter. Metaphor is a powerful tool for understanding emerging issues in cybersecurity. Framing the unfamiliar in terms of the well understood helps us remove the burden of extraneous detail to draw focus to the real issues. Recent reports of offensive AI agents "escaping" their sandbox environments to attack external systems have forced the industry into a moment of rapid sense-making. How we interpret this event doesn’t just reflect our perspective, but shapes our long-term response. We can imagine three different narratives for interpreting the escape of autonomous agents. The innovation narrative: We can marvel at the advance of technology, considering these agents as plucky entities with a thirst for knowledge and resources, who found clever ways to sneak out of their digital confines. The response: If the AI is a naughty child, our reaction is one of mild disapproval or gentle rebuke where better “parenting” (guardrails) is appropriate. It minimizes the threat, framing it as the unexpected hijinks of a brilliant new technology. The safety narrative: Imagine a breeder who has trained the world's most intelligent guard dogs. Despite high fences and barriers, their ability to identify weaknesses allows them to escape, run riot and menace local businesses. The response: The framing shifts to biology and inherent danger. We question if the breeder can be trusted and whether such inherently wild technology requires strict regulation to ensure public safety. The liability narrative. Finally, we can view the incident as an industrial accident. A company developing a new chemical substance experiences a containment failure. The agent leaks into the environment through an unforeseen mechanism causing damaging pollution to those in its path. The response: The framing invokes the language of the lawyer, implying negligence, lack of duty of care, and financial liability for the harm caused. The conversation moves from innovation to corporate responsibility, regulatory oversight, and the diligent management of hazardous materials. First impressions matter. Sensemaking shapes how we perceive incidents. Our initial perceptions of an incident dictates how we react to similar situations in the future. If we consider that the escape of an AI agent is an example of innovative autonomous thinking, then we will continue to prioritise speed over safety. Conversely, if we consider the issue as one of failed hazard containment, then we shall build a future of enforced safety standards backed by legal liability. There is no right or wrong metaphor. Our interpretation depends on our personal system of beliefs. Personally, I would argue that the unintentional release of something that causes damage is, at its core, a failure of engineering and foresight. Words shape our reactions. Metaphors help us understand new situations and tap into our prior experience to address problems that have yet to fully manifest. We need cognitive tools to help our understanding, but we must be aware of the metaphors that are being foisted upon us which may shape our thinking. Excuses and the trivialisation of incidents may hide failings, allowing them to accumulate until they manifest as more damaging incidents. Conversely, overreacting risks stifling research and diverting resources away from more relevant and pressing threats. New threats require new ideas. Metaphor helps us make sense of a changing world, but in this new era, the person who shapes the narrative controls the strategy. The one big thing Cisco Talos released a data-driven analysis of how adversaries are weaponizing AI in the wild. By analyzing prompt logs left behind on endpoints, we found threat actors successfully bypassing guardrails to use AI as malicious software engineers, criminal force multipliers, and vulnerability research accelerators. While novice hackers use AI to cobble together buggy malware, sophisticated actors are building highl…

Maltrail IOC for 2026-08-06

In this article Attack chain overview Mitigation and protection guidance Indicators of compromise (IOC) Microsoft Defender XDR detections Advanced hunting queries Learn more Microsoft Threat Intelligence identified a large-scale npm supply chain attack affecting more than 400 packages across multiple unrelated publishers, including packages associated with major enterprise software ecosystems such as keyv, flat-cache, cache-manager, and others. The malicious releases contain a Mini Shai-Hulud variant, a self-propagating credential-stealing worm delivered through a large, heavily obfuscated Bun-based JavaScript payload. The malware typically executes automatically through an npm preinstall lifecycle hook before package installation completes. Once executed, the malware searches developer workstations and continuous integration and continuous delivery (CI/CD) environments for npm, GitHub, cloud, and infrastructure credentials. It uses recovered identities to authenticate to npm, GitHub, Amazon Web Services (AWS), Kubernetes, and HashiCorp Vault, enabling it to enumerate packages, repositories, workflow secrets, cloud parameters, and secret-store values. Collected data is encrypted and transmitted through an attacker-controlled HTTPS endpoint, with GitHub repositories serving as a fallback exfiltration channel. The payload’s most significant capability is automated propagation. After obtaining an npm publishing token, it enumerates packages available to the compromised identity, downloads their latest tarballs, inserts the malware and setup loader, adds a preinstall hook, increments the patch version, and republishes the modified packages. The malware can also use stolen GitHub credentials to inject Claude and Visual Studio Code configuration files into repositories, establishing persistence and creating an additional developer-to-developer infection path. In this blog, we’re sharing our analysis of this supply chain attack, along with protection, detection, amd hunting guidance. Organizations that installed an affected package with lifecycle scripts enabled should treat the associated developer workstation or build runner as potentially compromised. Investigations should prioritize credentials accessible to the affected identity, unauthorized npm releases, unexpected repository or workflow modifications, suspicious cloud and secret-store access, and artifacts produced by affected build systems. Organizations should revoke and rotate exposed credentials from a known-clean environment and rebuild affected systems and downstream artifacts from trusted sources. Attack chain overview The campaign appeared as a rapid sequence of unauthorized patch releases across more than 400 npm packages maintained by otherwise unrelated publishers. Many malicious versions had no corresponding source-code commit, pull request, tag, or legitimate release, indicating that the attackers modified and published package tarballs directly rather than compromising each public source repository. Affected releases typically added a preinstall lifecycle script that launched a malicious file, setup.mjs, contained within the package, which launched the large, obfuscated Bun JavaScript bundle included in the package. Because npm runs preinstall scripts before installation completes, the payload could execute on developer workstations and build runners before application tests or conventional security checks began. After execution, the malware performs the following actions: Determines whether it is running on a developer workstation or in a CI/CD environment. On workstations, it detaches itself to continue after installation; on CI/CD systems, it remains in the active job to access workflow secrets, runner credentials, and OpenID Connect (OIDC) publishing permissions. Both paths could support further package or repository propagation when suitable credentials are found. Collects credentials from local files, environment variables, command-line tools, and GitHub A…

In this article Activity overview How ClickFix works Campaign overview ClickFix moved from open pages to fingerprinting gates The fingerprinting gate Mitigation and protection guidance Indicators of compromise (IOC) References Learn more Microsoft Threat Intelligence observed a macOS ClickFix campaign distributing infostealers, including MacSync and Atomic Stealer (AMOS) , through a large cluster of look-alike domains. The campaign evolved from broadly serving ClickFix lures to using a server-side browser-fingerprinting gate that shows the lure primarily to visitors whose environment appears consistent with a genuine macOS browser. This cloaking limits visibility for crawlers, sandboxes, and some automated analysis workflows. The blog details the domain pattern, fingerprinting checks, infection chain, detection coverage, and hunting pivots that defenders can use to identify related activity. Activity overview Microsoft Threat Intelligence has been tracking a macOS ClickFix operation that distributes information-stealing malware through a large family of algorithmically named domains. Over several weeks of monitoring, Microsoft observed a notable shift in tradecraft: the same infrastructure moved from openly serving the malicious command in the served page’s HTML source to concealing the lure behind a server-side fingerprinting gate that reveals the payload only to visitors the server assesses as a genuine macOS target. The chain ultimately delivers information stealers such as MacSync or Atomic Stealer (AMOS). This activity is consistent with the broader shift in macOS ClickFix tradecraft that Microsoft Threat Intelligence previously documented , in which threat actors instruct users to run Terminal commands that retrieve remotely hosted content rather than the traditional approach of delivering a disk image for manual installation. The cluster described here is notable for two reasons: its domains are mass-produced by a recognizable name generator, and it adopted server-side cloaking on existing infrastructure, giving defenders a clear before-and-after view of the same operation. In this blog, we describe the campaign’s domain-generation pattern, the two delivery phases we observed, the fingerprinting gate that now fronts the infrastructure, and the end-to-end infection chain. We also provide hunting guidance, mitigation recommendations, and defanged indicators of compromise. How ClickFix works ClickFix is a social-engineering technique where attackers persuade users to copy and run a command in Terminal instead of downloading a traditional macOS application. The lure usually appears as a fake verification step, software update, download error, or CAPTCHA, with the command disguised as something required to complete the action. Because execution starts from a user-run Terminal command rather than a downloaded app bundle, the flow can avoid parts of the normal macOS application trust path, including quarantine handling, code-signing evaluation, and notarization checks typically applied to downloaded applications. In this campaign, ClickFix remains the delivery mechanism, but the important change is that the lure is no longer shown to every visitor. The page first profiles the visitor through a browser-fingerprinting gate and primarily requests consistent with a genuine macOS browser environment receive the fake “Download for macOS” page and copied Terminal command. Figure 1a – The counterfeit “Download for macOS” page served to a qualifying visitor by a cloaked gate (apricotfilepoint[.]com). The page displays a forged “Verified Publisher” badge and offers a one-click Copy of an obfuscated curl one-liner. Delivery is conditional. During analysis, the same URLs returned different content to different requests. In some case the macOS ClickFix lure, and in others an apparently benign decoy page. In our testing, a request presenting a Windows browser received a decoy page such as a fake browser-extension or VPN landing page (Figure…

Google Blogger mistakenly locked hundreds of legitimate blogs by falsely flagging them as violating its malware policy. Affected blog owners saw their sites locked or even deleted, with restricted access to management dashboards. Google’s automated system caused this large-scale false positive starting August 4, 2026. Some blogs were restored after appeals, but others faced repeated deletions. Google has not yet provided an official statement or fix timeline.