Rogue WordPress Plugin Conceals Multi-Tiered Credit Card Skimmers in Fake PNG Files

The Wordfence Threat Intelligence Team recently discovered a sophisticated malware campaign targeting WordPress e-commerce sites, specifically those using the WooCommerce plugin. This malware exhibits advanced features including custom encryption methods, fake images used to conceal malicious payloads, a robust persistence layer that allows attackers to deploy additional code on demand, all packaged as a rogue WordPress plugin.

This comprehensive malware sample was shared with us by a Wordfence user on August 21, 2025. Four malware detection signatures were developed and released after undergoing our QA process between August 27, 2025 and September 9, 2025. All paid Wordfence customers received these signatures immediately, along with paid Wordfence CLI Users. Users of the free versions of Wordfence and Wordfence CLI received the same signatures after the standard 30-day delay.

Malware Analysis

The malware presents itself as a malicious WordPress plugin, consisting of two PHP files and two PNG files. The plugin folder and the main plugin file share the same naming convention based on three random words, while the other PHP file in the malicious directory is usually named config.php. Our malware sample is called “license-user-kit” but we have identified several variants, for example:

  • jwt-log-pro
  • cron-environment-advanced
  • json-task-basic
  • access-access-pro
  • share-seo-assistant

All PHP functions and variable names are also generated randomly for each plugin copy (to improve clarity they will be renamed in the code examples). Most text strings are also obfuscated via a common function call that requires a shared key. While this method is easily reversible during source code inspection, it effectively helps bypass some content flagging.

On activation the malware hides its entry from the WordPress plugin list and table view, to minimize the risk of detection. It also records the IP address and last login time of every user with edit_posts capability (everyone with role Author and above) storing this information in a custom database option and setting a tracking cookie. This cookie ensures persistent user identification, even across session changes or after cookie deletion; as shown later in this post, this cookie will be used to prevent the delivery of skimming code to privileged users, in another attempt to avoid detection.

Login Credentials Exfiltration

The malware features a two-step process for exfiltrating login credentials. It captures usernames and passwords when a user enters them (wp_authenticate_user filter) using a cookie as storage, then waits for the actual login (wp_login action) to exfiltrate them, including basic user and website data in the request.

AJAX Backdoor Access

The malware establishes a backdoor using two distinct AJAX-based access endpoints, both employing a cookie-based authentication method that circumvents WordPress’s native authentication. The first channel enables the attacker to update the credit card skimmer’s JavaScript payload in two ways: either by setting a cookie to a specific URL for download or by transmitting a raw payload via a POST request. The second channel allows the attacker to execute arbitrary PHP code through a temporary file.

Multi-Tiered Payloads

Once installed, the malware silently monitors WooCommerce checkout pages using the is_checkout() WordPress function: when a checkout page is prepared, several different JavaScript payloads are injected into the generated page.

The JavaScript payloads are stored within fake PNG images to avoid detection. These fake image files have randomly generated filenames and variable sizes for each installation. Each file starts with a fake PNG header (‰PNG) followed by reversed JavaScript code, which has been encoded using a custom base64 variation. Three distinct fake image files are employed for this purpose:

  • A custom payload (not found in our sample) created via AJAX backdoor
  • A dynamic payload with the main form-jacking logic, updated daily
  • A fallback payload with a static backup copy of the same logic.

This multi-tiered fallback design allows the attacker to deliver multiple payloads at once, from custom additions tailored to the victim’s website to the most recent version, including a local fallback for additional safety.

The payload is designed to refresh daily, with each request including custom headers for victim fingerprinting and basic authentication.

Credit Card Skimming

Credentials exfiltration schema

The credit card skimming malware analyzed is a highly obfuscated file containing both the skimming code and helper functions. It includes features such as a 3-second timeout on page loading before skimmer activation – designed to prevent conflicts with AJAX-based checkout forms – or a fake credit card validation system that activates when card data is entered – aiming to boost user confidence in the deceptive checkout form.

We also found what seems to be a clipboard-based skimming method, though its associated exfiltration mechanism was not identified, suggesting either ongoing development or the use of other, currently undetected, exfiltration methods.

Once activated, JavaScript event listeners are attached to the checkout forms to intercept card data.

Data Exfiltration

The PHP code is designed to intercept the POST request from the checkout form, then prepare and exfiltrate the data to the attacker. To ensure stability across diverse server environments, the malware employs a variety of network request methods. It starts with a standard cURL-based attempt, followed by another request using PHP’s file_get_contents function. Subsequently, it attempts to use cURL via a system shell, and as a final redundancy measure, dispatches a plain email.

Evidence strongly suggests that the SMILODON string, found in two C&C server URLs, is linked to Magecart Group 12 threat actors.

This connection has been observed since 2021 and is further supported by the coding style and logic presented in this analysis, which aligns with the group’s known characteristics. Among others, the email address provider matches those previously associated with this threat actor, while two domains are hosted on the IP address 121.127.33[.]229 alongside other domains connected to this group’s past phishing and skimming operations.

Indicator of Compromise (IoC)

TypeValueNotes
CookiepxcelPage_c01002Logged user tracking
Cookiewp_tdataStolen WP credentials
Cookie_wdataStolen checkout data
Database optionwp_user_[md5(IP)]User tracking
C&C Requesthxxps://badping[.]info/SMILODON/index_b.php?view=WP credentials exfiltration
C&C Requesthxxps://checkerror[.]info/wp/widget_bad64.txtJavaScript payload update
C&C Requesthxxps://geterror[.]info/SMILODON/index.php?view=Checkout data exfiltration
Mailto.duraku@rambler[.]ruCheckout data exfiltration

Conclusion

Today’s blog post has unveiled a sophisticated malware campaign targeting WordPress e-commerce sites, characterized by advanced obfuscation techniques, hidden payloads within fake image files, and a resilient multi-tiered skimming infrastructure. The malware’s ability to evade detection, track administrators, exfiltrate login credentials, and deploy dynamic credit card skimmers via AJAX backdoors poses a severe threat to online businesses and their customers. The intricate design and multiple fallback mechanisms demonstrate a high level of technical expertise, ensuring persistence and effective data theft even under varying server conditions.

A comprehensive understanding of these attack vectors is essential for building strong defense strategies against such ongoing and evolving threats. Although our detection capabilities are powerful, we are continuously searching for new malware variants. In the event that Wordfence does not automatically detect these sophisticated malware variants on your site, we ask that you please submit information about the malware to samples@wordfence.com. This will allow us to expand our collection, develop new detection signatures and continue our goal of securing the web.

Source and more details: https://www.wordfence.com/blog/2025/10/rogue-wordpress-plugin-conceals-multi-tiered-credit-card-skimmers-in-fake-png-files

Attackers Actively Exploiting Critical Vulnerability in WP Freeio Plugin

On September 25th, 2025, we Wordfence a submission for a Privilege Escalation vulnerability in WP Freeio, a WordPress plugin bundled in the Freeio premium theme with more than 1,700 sales. This vulnerability makes it possible for an unauthenticated attacker to grant themselves administrative privileges by specifying user role during registration. The vendor released the patched version on October 9th, 2025, and Wordfence originally disclosed this vulnerability in the Wordfence Intelligence vulnerability database on October 10th, 2025. Their records indicate that attackers started exploiting the issue on the same day, on October 10th, 2025. The Wordfence Firewall has already blocked over 33,200 exploit attempts targeting this vulnerability.

Paid users received a firewall rule to protect against any exploits targeting this vulnerability on October 8, 2025. Sites using the free version of Wordfence will receive the same protection after the standard 30-day delay on November 7, 2025.

Considering this vulnerability is under active attack, we urge users to ensure their sites are updated with the latest patched version of WP Freeio, version 1.2.22 at the time of this writing, as soon as possible.

Source and more details: https://www.wordfence.com/blog/2025/10/attackers-actively-exploiting-critical-vulnerability-in-wp-freeio-plugin

100,000 WordPress Sites Affected by Arbitrary File Read Vulnerability in Anti-Malware Security and Brute-Force Firewall WordPress Plugin

On October 3rd, 2025, Wordfence received a submission for an Arbitrary File Read vulnerability in Anti-Malware Security and Brute-Force Firewall, a WordPress plugin with more than 100,000 active installations. This vulnerability makes it possible for an authenticated attacker with subscriber-level permissions or higher to read arbitrary files on the server, which may contain sensitive information.

Props to Dmitrii Ignatyev who discovered and responsibly reported this vulnerability through the Wordfence Bug Bounty Program. This researcher earned a bounty of $960.00 for this discovery.

Paid Wordfence users received a firewall rule to protect against any exploits targeting this vulnerability on October 14, 2025. Sites using the free version of Wordfence will receive the same protection 30 days later on November 13, 2025.

The Wordfence team was not able to find any contact information for the vendor, so they escalated the vulnerability to the WordPress.org Security Team which forwarded the report to the vendor on October 14, 2025. After that, the developer released a patch on October 15, 2025.

We urge users to update their sites with the latest patched version of Anti-Malware Security and Brute-Force Firewall, version 4.23.83 at the time of this publication, as soon as possible.

Source and more details: https://www.wordfence.com/blog/2025/10/100000-wordpress-sites-affected-by-arbitrary-file-read-vulnerability-in-anti-malware-security-and-brute-force-firewall-wordpress-plugin

Cities reverse course on automated license plate reader cameras amid privacy concerns

Cambridge, Massachusetts officials turned off 16 automated license plate reader cameras (ALPR) last week after the city council voted to pause their use following reports of the cameras’ manufacturer sharing data with immigration authorities.

Cambridge is one of several cities where the Flock Safety cameras — which are now present in thousands of cities across the country — have recently been taken offline. 

On October 14, Eugene, Oregon officials disabled 57 cameras there after the City Council voted to pause their use following an intense backlash from residents. Officials in Austin, Texas ended their contract with Flock in June amid similar public objections. In August, Evanston, Illinois deactivated 19 cameras.

The move by cities to halt their work with Flock follows reports that the company shared data from local partners with federal immigration authorities. Residents in all cities which have disabled the cameras had fought their use.

A Cambridge City Councilor, Patty Nolan, said she is concerned by reports that police in Texas used data from Flock cameras in several jurisdictions to track a woman who self-administered an abortion as part of a criminal investigation. Councilors also were alarmed by use of camera data for immigration arrests, she said.

“Flock data has been used and requisitioned by federal immigration officials for work that I don’t want us to be cooperating on,” Nolan said. “It’s not our job to do their work.”

Cambridge officials and the City Council are currently reviewing Flock’s data practices and the city’s contract with the firm and will determine soon if the city will end its contract with the ALPR manufacturer. Nolan said the vote to pause the contract was unanimous and that councilors are focused on understanding what guardrails are in place to prevent Flock from sharing data from the city with outside agencies.

She said she also has seen no evidence that use of Flock cameras reduces crime.

Police in some jurisdictions have fought to continue using the cameras. 

The police chief in Eugene told the public that the Flock cameras played a pivotal role in investigating a series of burglaries targeting Asian business owners for which officers had recently made arrests.

“The ALPR technology was a critical investigative tool in providing a turning point to help solve this case,” Eugene Police Chief Chris Skinner said in a prepared statement on October 10. “This is an example of how this technology can serve victims of crime in a more effective and efficient way.”

Evanston officials have said they decided to turn off their Flock cameras after a state audit revealed the company had shared city residents’ license plate data with federal authorities in violation of state law.

“The findings of the Illinois Secretary of State’s audit, combined with Flock’s admission that it failed to establish distinct permissions and protocols to ensure local compliance while running a pilot program with federal users, are deeply troubling,” a city of Evanston press release said.

The company reportedly later reinstalled cameras in Evanston, leading officials there to cover them in plastic bags so they would not work.

A Flock spokesperson declined to comment about the Evanston allegations.

In Denver, residents and city councilors are now fighting Mayor Mike Johnston over plans to continue the city’s contract with Flock.

Flock is not trustworthy, City Council Member-at-Large Sarah Parady said. Police officials there have said they were unaware that the company shared Denver’s data with law enforcement in outside jurisdictions, she said. Such sharing is especially concerning to Parady because many women from Texas come to Colorado to obtain legal abortions.

A spokesperson for Johnston did not immediately respond to a request for comment.

Parady said she also worries about federal immigration authorities using Flock data to seize undocumented people. Even if Flock data were not being shared with outside agencies, however, Paraday said she still opposes their use because of how Flock trains its AI to predict people’s patterns of travel.

“That kind of surveillance is not something that a human mind looking at physical images or looking at a car driving by could do by itself, and so it’s really come a very long way from the Fourth Amendment doctrine of kind of plain view searches and the idea that you don’t have any expectation that your photograph won’t be taken in public,” Parady said.

“It’s hard for me to believe that you don’t have a privacy right not to have an algorithm basically track you everywhere that you go.”

Source: https://therecord.media/cities-reverse-course-on-automated-license-plate-reader-cameras

ChatGPT Atlas Stores OAuth Tokens Unencrypted Leads to Unauthorized Access to User Accounts

A significant vulnerability in OpenAI’s newly released ChatGPT Atlas browser reveals that it stores unencrypted OAuth tokens in a SQLite database with overly permissive file settings on macOS, potentially allowing unauthorized access to user accounts.

This flaw, discovered by Pete Johnson just days after the browser’s October 21, 2025, launch, bypasses standard encryption practices used by major browsers like Chrome, leaving sensitive authentication data exposed to any process on the system.

The issue raises concerns about the privacy safeguards in AI-integrated browsing tools, especially as Atlas aims to handle tasks such as research and automation on behalf of users.

The vulnerability came to light when a non-expert user, intrigued by the browser’s data handling after installing ChatGPT Atlas, examined the cache directory at ~/Library/Caches/com.openai.atlas/.

Token Stored With 644 Permissions

Pete Johnson found a SQLite database storing functional OAuth tokens without encryption, protected only by 644 file permissions, which makes the file readable by all users and processes on the Mac.

Unlike established browsers that leverage macOS Keychain for token encryption, Atlas appears to skip this step by default, enabling straightforward extraction and reuse of the tokens via simple scripts.

ChatGPT Atlas Exposes Users Details
ChatGPT Atlas Exposes Users’ Details (Source: Pete Johnson)

Pete Johnson demonstrated this by crafting a local script that queried the database, retrieved the unencrypted tokens, and successfully accessed the OpenAI API to fetch the user’s full profile details and conversation history across sessions.

Even attempts to pull account status returned a 405 error rather than a 401 unauthorized response, confirming the tokens’ validity.

To verify the risks, the user consulted the web version of ChatGPT, which itself acknowledged that such unencrypted storage in a hypothetical browser would pose a severe security threat, potentially allowing malware or other apps to hijack sessions without detection.

This oversight persisted despite the installation process not prompting users about Keychain integration, a standard query in secure applications.

The exposure is particularly concerning given Atlas’s design as a Chromium-based AI browser that imports bookmarks, passwords, and history while enabling agentic features for premium users.

Unencrypted tokens could enable attackers to impersonate users, accessing not just ChatGPT conversations but potentially linked services if scopes overlap, echoing past OAuth leakage incidents in AI tools.

While macOS user permissions limit cross-account exploitation, intra-account risks remain high, especially on shared or compromised devices.

Cybersecurity experts have already flagged Atlas for related issues like prompt injection attacks, where malicious web content could manipulate the AI to exfiltrate data, amplifying the token flaw’s dangers.

OpenAI emphasizes privacy controls in Atlas, such as opt-out data training and memory management, but this storage misconfiguration undermines those claims.

The browser’s rapid rollout to Free, Plus, and Pro users worldwide on macOS, with Windows and mobile versions pending, heightens the urgency for patches.

Pete Johnson hesitated to release the extraction script publicly after the launch hype, but shared it privately with contacts for validation.

UK-based researcher Matt Johnson confirmed the issue on his setup, noting it extracts profiles and histories effectively within the same account.

Ken Johnson, CTO of DryRun Security, added that “In corporate environments, I would not allow Comet, Atlas, or any AI-powered browser on company devices at this time. Browser security is already difficult even for the companies that make them, and robust privacy controls require immense care. AI is new to both fronts. Granting these tools unprecedented access to personal and corporate data, combined with the inherent risks of AI systems and existing security concerns, is a time bomb.”

However, no official bug reporting mechanism exists for Atlas yet, leaving users in limbo as of October 22, 2025.

Further inquiries revealed inconsistency: some users report Keychain prompts during setup, resulting in encrypted tokens, while others, like the discoverer, do not, suggesting a rollout bug or A/B testing glitch.

OpenAI has not explicitly commented, though its security team has addressed broader AI browser risks, such as injection attacks, through red-teaming and guardrails.

Experts urge immediate updates, recommending that users monitor permissions, enable 2FA on OpenAI accounts, and avoid sensitive tasks in Atlas until the issue is resolved.

Source: https://cybersecuritynews.com/chatgpt-atlas-exposes-users/

Mass Exploit Campaign Targeting Arbitrary Plugin Installation Vulnerabilities

On September 25th, 2024, and on October 3rd, 2024, Wordfence received submissions through their Bug Bounty Program for Arbitrary Plugin Installation vulnerabilities in the GutenKit and Hunk Companion WordPress plugins, which have over 40,000 and 8,000 active installations, respectively. These vulnerabilities make it possible for unauthenticated threat actors to install and activate arbitrary plugins, which can be leveraged to achieve remote code execution. Records indicate that attackers most recently started mass exploiting the issues again on October 8th, 2025 (approximately one year later), following several earlier incidents of large-scale exploitation. The Wordfence Firewall has already blocked over 8,755,000 exploit attempts targeting these vulnerabilities.

Paid Wordfence users received firewall rules to protect against any exploits targeting these vulnerabilities on September 27, 2024 and on October 10, 2024. Sites using the free version of Wordfence received the same protection after the standard 30-day delay on October 27, 2024 and on November 9, 2024.

We urge users to update their sites to at least GutenKit version 2.1.1 and Hunk Companion version 1.9.0 as soon as possible, if they have not already done so.

Source: https://www.wordfence.com/blog/2025/10/mass-exploit-campaign-targeting-arbitrary-plugin-installation-vulnerabilities

Beware of unexpected packages showing up on your doorstep, USPS warns

[Ed. Note: Including this tip because it’s Cybersecurity Awareness Month]

Did you get a package you didn’t order? It could be a scam.

That’s the word from the U.S. Postal Service, which is reminding employees and the public to beware of brushing scams, which involves third-party sellers sending packages containing low-value items such as household goods or gadgets to people who did not order it.

The scams aim to product ratings and visibility, because the sellers use recipients’ addresses to make it appear as if they are verified purchasers so they can then pose as the recipients to leave fake, positive reviews of the products.

They can also lead to identity theft, compromised accounts and increased spam because it gives cybercriminals access to the recipient’s name, address and phone number.

“Once this personal information is online, it can be used for various crooked enterprises,” a news release said.

Here’s what you can do if you or someone you know receives an unsolicited package:

  • File a report with the Postal Inspection Service;
  • Change the password for your email and any accounts containing financial data;
  • Do not engage with the sender of the package or you may inadvertently verify your address, which could lead to more unwanted packages; and
  • Do not scan any QR codes on the packages because this can install malware on your device.

The CyberSafe at USPS Blue and LiteBlue pages have more information.

Source: https://www.mlive.com/news/us-world/2025/10/beware-of-unexpected-packages-showing-up-on-your-doorstep-usps-warns.html

Jingle Thief: Inside a Cloud-Based Gift Card Fraud Campaign

[Ed. Note: This post is included due to being Cybersecurity Awareness Month, despite not being directly related to WordPress]

Executive Summary

Unit 42 (https://unit42.paloaltonetworks.com/) investigated a campaign waged by financially motivated threat actors operating out of Morocco. They refer to this campaign as Jingle Thief, due to the attackers’ modus operandi of conducting gift card fraud during festive seasons. Jingle Thief attackers use phishing and smishing to steal credentials, to compromise organizations that issue gift cards. Their operations primarily target global enterprises in the retail and consumer services sectors. Once they gain access to an organization, they pursue the type and level of access needed to issue unauthorized gift cards.

The activity related to this campaign is tracked by Unit 42 as cluster CL‑CRI‑1032. The threat actors behind the activity target organizations that primarily rely on cloud-based services and infrastructure. They then exploit Microsoft 365 capabilities to conduct reconnaissance, maintain long-term persistence and execute large-scale gift card fraud. We assess with moderate confidence that the activity cluster we track as CL-CRI-1032 overlaps with the activity of threat actors publicly tracked as Atlas Lion and STORM-0539 [PDF].

What makes the threat actor behind this activity particularly dangerous is the ability to maintain a foothold inside organizations for extended periods — sometimes over a year. During this time, they gain deep familiarity with the environment, including how to access critical infrastructure — making detection and remediation especially challenging. In April and May 2025, the threat actor behind the Jingle Thief campaign launched a wave of coordinated attacks across multiple global enterprises.

This article presents an end-to-end analysis of the Jingle Thief campaign lifecycle, based on real-world incident telemetry and detections. We provide a clear view of the methods involved in this activity, and practical guidance for mitigating identity-based threats — attacks that target user accounts and credentials — in cloud environments. As identity increasingly replaces the traditional perimeter, understanding campaigns like Jingle Thief is essential to securing modern enterprise infrastructure.

This activity was identified through behavioral anomalies detected by Cortex User Entity Behavior Analytics (UEBA) and Identity Threat Detection and Response (ITDR). Customers are better protected from this activity with the new Cortex Advanced Email Security module.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Who Is Behind the Jingle Thief Campaign?

We assess with moderate confidence that the Jingle Thief campaign was created by financially motivated Morocco-based attackers who have been active since 2021. Their operations primarily target global enterprises in the retail and consumer services sectors. Although not affiliated with a nation-state, the activity we track as CL‑CRI‑1032 includes advanced tactics, persistence and operational focus.

Unlike threat actors who rely on commodity malware or endpoint exploitation, the attackers behind CL‑CRI‑1032 operate almost exclusively in cloud environments once they obtain credentials through phishing. They exploit cloud-based infrastructure to impersonate legitimate users, gain unauthorized access to sensitive data and carry out gift card fraud at scale.

Anatomy of the Jingle Thief Campaign

In a campaign that we observed, threat actors maintained access for approximately 10 months and compromised over 60 user accounts within a single global enterprise. The activity involved the use of Microsoft 365 services, including SharePoint, OneDrive, Exchange and Entra ID. This demonstrated a high degree of adaptability and operational patience. Detecting this approach requires close observation of adversaries’ actions over an extended period. The threat actors behind the Jingle Thief campaign often align their activity with holiday periods, increasing operations during times of reduced staffing and heightened gift card spending.

Having gained initial access, the threat actors conducted reconnaissance to map the environment, moved laterally to access more sensitive areas, and identified opportunities to execute large-scale financial fraud. Figure 1 illustrates the end-to-end attack lifecycle across Microsoft 365, highlighting how the threat actors progressed from phishing-based entry to persistent access through device registration.

The final attack step of device registration creates a foothold that the threat actors exploit to issue gift cards, which they then leverage for monetary gain.

Why Gift Cards? The Prey of Choice

Gift cards are highly attractive to financially motivated actors due to their ease of redemption and rapid monetization. Threat actors resell gift cards on gray-market forums at discounted rates, enabling near-instant cash flow.

Additional factors that make gift cards attractive include:

  • Minimal personal information required for redemption
  • Difficult to trace, making fraud harder to investigate or recover
  • Accepted widely, often indistinguishable from legitimate use
  • Useful for low-risk money laundering, especially across jurisdictions
  • Frequently issued through systems with weak access controls, broad internal permissions, and limited monitoring or logging

Retail environments are particularly vulnerable to this type of attack, as gift card systems are often accessible to a wide range of internal users, such as store employees. These systems may support multiple vendors or programs, making access pathways broader and more difficult to control.

Gift card fraud combines stealth, speed and scalability, especially when paired with access to cloud environments where issuance workflows reside. To exploit these systems, the threat actors need access to internal documentation and communications. They can secure this by stealing credentials and maintaining a quiet, persistent presence within Microsoft 365 environments of targeted organizations that provide gift card services.

In the campaign we observed, the attackers made repeated access attempts against multiple gift‑card issuance applications. They tried to issue high‑value cards across different programs in order to monetize them, and possibly to use the cards as collateral in money-laundering schemes — effectively turning digital theft into untraceable cash or short-term loans. These operations were staged in a way that minimizes logging and forensic traces, reducing the chance of rapid detection.

Highly Targeted and Tailored Attacks

The threat actors behind the Jingle Thief campaign invest heavily in reconnaissance before launching attacks. They gather intelligence on each target, including branding, login portals, email templates and domain naming conventions. This allows them to craft highly convincing phishing content that appears authentic to both users and security tools.

Phishing URLs often include the organization’s name, a trusted third-party tool or software, and landing pages that closely mimic legitimate login screens. This highly customized social engineering approach increases the likelihood of compromise and highlights the actors’ use of sophisticated techniques.

Figure 2 shows a credential phishing page crafted by the threat actors to impersonate a legitimate Microsoft 365 login portal, tailored to the victim organization’s branding.

Initial Access: Phishing and Smishing for Cloud Credentials

The threat actors behind the Jingle Thief campaign typically begin their operations with tailored phishing or SMS-based smishing attacks. These messages lure victims to counterfeit Microsoft 365 login portals that mimic legitimate sign-in pages. Some lures impersonate nonprofits or non-governmental organizations (NGOs), likely to give the appearance of credibility and increase victim engagement.

Notably, many messages are delivered using self-hosted PHP mailer scripts, often sent from compromised or hijacked WordPress servers, which obscure the attackers’ origin and improve delivery.

The threat actors also employ deceptive URL formatting, such as: https://organization[.]com@malicious.cl[/]workspace

While the URL above appears to point to the legitimate organization’s domain (organization[.]com), browsers interpret everything before the @ as user credentials, and actually navigate to the domain after it (malicious.cl). This tactic helps disguise the true destination of the link and increases the likelihood of victims clicking.

After harvesting credentials in the campaign that we observed, the attackers authenticated to Microsoft 365 directly and began navigating the environment, with no malware required. Figure 3 shows a smishing attempt used to harvest credentials, captured from a malicious PHP email send log from the attackers’ infrastructure. The message originated from a Moroccan IP address, and was sent to a Verizon SMS gateway (vtext.com).

Cloud Reconnaissance: Mining SharePoint and OneDrive for Gift Card Intel

After initial access, the attackers behind Jingle Thief perform extensive reconnaissance within the Microsoft 365 environment, particularly focusing on SharePoint and OneDrive. These services frequently contain internal documentation related to business operations, financial processes and IT workflows.

The threat actors search for:

  • Gift card issuance workflows
  • Ticketing system exports or instructions
  • VPN configuration and access guides
  • Spreadsheets or internal tools used to issue or track gift cards
  • Organizational virtual machines, Citrix environments

Rather than escalating privileges, the threat actors build situational awareness by accessing readily available data on compromised users. This discreet approach helps evade detection while laying the groundwork for future fraud.

Internal Phishing for Lateral Moves

Instead of deploying malware or post-exploitation frameworks, Jingle Thief relies on internal phishing to expand their foothold within target environments. In an attempted attack against one of our customers, after compromising a user’s Microsoft 365 account, the attackers sent phishing emails from the legitimate account to personnel inside the same organization. These messages mimicked IT service notifications or ticketing updates, often leveraging information gathered from internal documentation or previous communications to appear legitimate.

Common lures:

  • Fake ServiceNow alerts: “INCIDENT REQ07672026 Has been completed”
  • IT access notifications: “ServiceNow Account Inactivity Notice”
  • Generic approval prompts: “Incident pending your review”

These emails link to fake login portals branded with the organization’s identity, leveraging internal trust to evade suspicion and spread laterally.

Figure 5 shows an internal phishing email sent from a compromised account, spoofing a ServiceNow inactivity notice to trick users into entering credentials.

Ruling the Inbox for Silent Email Exfiltration

To passively monitor internal communications, the attackers responsible for the Jingle Thief campaign often create inbox rules to automatically forward emails to attacker-controlled addresses.

They monitor:

  • Gift card approvals
  • Financial workflows
  • IT ticketing or account changes

This approach reduces the need for active attacker interaction and helps maintain stealth. Figure 6 shows an alert flagging the creation of a malicious inbox forwarding rule, which is one of the stealth tactics employed by these threat actors to monitor internal communications.

Stealthy Email Activity: Hiding in Plain Sight

To cover their tracks, the attackers actively manage mailbox folders:

  • Moving sent phishing emails immediately from Sent Items to Deleted Items
  • Moving replies from users from Inbox to Deleted Items

This ensures that victims won’t see the phishing messages or responses, delaying discovery by both victims and defenders.

The Exchange audit logs in Figure 7 show the attackers moving phishing email replies from the Inbox folder to the Deleted Items folder.

Dominating Rogue Devices for Persistence

Most of the intrusions we observed in the Jingle Thief campaign relied on stolen credentials or session tokens for temporary access. However, the actors also demonstrated techniques for establishing longer-term persistence within compromised environments.

In some intrusions, the threat actors took control of identity infrastructure by misusing legitimate user self-service and device enrollment mechanisms in Microsoft Entra ID. These tactics allowed them to maintain access even after passwords were reset or sessions were revoked.

Tactics include:

  • Registering rogue authenticator apps to bypass MFA
  • Resetting passwords via self-service flows
  • Enrolling attacker-controlled devices in Entra ID

The ultimate goal of these varied tactics – phishing, inbox control, mail exfiltration and rogue device registration – is to obtain and monetize gift cards at scale.

Tracing Jingle Thief’s Moroccan Roots

The campaign activities that we observed almost exclusively originated from IP addresses geolocated in Morocco. Across incidents, Microsoft 365 logs showed recurring device fingerprints and login behaviors associated with these IP addresses. Unlike many actors who hide behind VPNs, these threat actors often made no attempt to obscure their origin, and only sometimes used Mysterium VPN when accessing compromised accounts.

Autonomous System Number (ASN) metadata from the connections also consistently matched Moroccan telecommunications providers, including:

  • MT-MPLS
  • ASMedi
  • MAROCCONNECT

In addition to IP and ASN infrastructure, Jingle Thief reuses distinctive domain and URL structures across campaigns. These recurring patterns in domain naming and infrastructure further support attribution to a Morocco-based threat group.

Conclusion

The Jingle Thief campaign demonstrates a clear focus on major retailers’ gift-card issuance systems. The attackers targeted multiple issuance applications to generate high‑value cards, likely for resale on gray markets, or as fungible assets in money‑laundering chains. Gift-card systems are often under‑monitored and widely accessible internally, making them an attractive extension to identity‑based attacks: By compromising the right accounts, threat actors can issue and steal gift cards, while leaving almost no trace of their malicious operations.

The cluster of activity behind the Jingle Thief campaign overlaps with the activity of threat actors publicly tracked as Atlas Lion. This cluster — tracked by Unit 42 as CL-CRI-1032 — favors identity misuse over malware, and leverages trusted cloud services rather than endpoint compromise. Their campaigns highlight how attackers can operate entirely within cloud environments, abusing legitimate features for phishing, persistence and fraud.

By understanding the tactics used in the Jingle Thief campaign, defenders can better prioritize identity-based monitoring and adapt to the industry’s shift toward treating identity as the new security perimeter. Understanding user behavior, login patterns and identity misuse are increasingly essential for early detection and response.

Palo Alto Networks customers are better protected from this activity with the new Cortex Advanced Email Security module, as well as Cortex UEBA and ITDR.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 00080005045107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Moroccan Infrastructure (Attribution Signal)

  • 105.156.109[.]227
  • 105.156.234[.]139​​
  • 105.157.86[.]136
  • 105.158.226[.]49
  • 105.158.237[.]165
  • 160.176.128[.]242
  • 160.178.201[.]89
  • 160.179.102[.]157
  • 196.64.165[.]160
  • 196.65.139[.]51
  • 196.65.146[.]114
  • 196.65.172[.]48
  • 196.65.237[.]97
  • 196.74.125[.]243
  • 196.74.183[.]81
  • 196.77.47[.]232
  • 196.89.141[.]80
  • 41.141.201[.]19
  • 41.250.180[.]114
  • 41.250.190[.]104

Associated ASN Organizations (Geolocated to Morocco)

  • MT-MPLS
  • ASMedi
  • MAROCCONNECT

U.S. Infrastructure (Potential Proxy or Compromised Hosts)

  • 70.187.192[.]236
  • 72.49.91[.]23

Phishing URL Patterns

  • hxxps://*.com.ng/*[brand-name].com/home/
  • hxxps://*.[brand-name].servicenow.*/*access
  • hxxps://[brand-name].com@*.*/portal/
  • hxxps://[brand-name].com@*.*/workspace
  • hxxps://*/home
  • hxxps://*/workspace/home

Additional Resources

Source: https://unit42.paloaltonetworks.com/cloud-based-gift-card-fraud-campaign/

Unseeable prompt injections in screenshots: more vulnerabilities in Comet and other AI browsers

This is the second post in a series about security and privacy challenges in agentic browsers. This vulnerability research was conducted by Artem Chaikin (Senior Mobile Security Engineer), and was written by Artem and Shivan Kaul Sahib (VP, Privacy and Security).

Building on our previous disclosure of the Perplexity Comet vulnerability, we’ve continued our security research across the agentic browser landscape. What we’ve found confirms our initial concerns: indirect prompt injection is not an isolated issue, but a systemic challenge facing the entire category of AI-powered browsers. This post examines additional attack vectors we’ve identified and tested across different implementations.

On request, we are withholding one additional vulnerability found in another browser for now. We plan on providing more details next week.

As we’ve written before, AI-powered browsers that can take actions on your behalf are powerful yet extremely risky. If you’re signed into sensitive accounts like your bank or your email provider in your browser, simply summarizing a Reddit post could result in an attacker being able to steal money or your private data.

As always, we responsibly reported these issues to the various companies listed below so the vulnerabilities could be addressed. As we’ve previously said, a safer Web is good for everyone. The thoughtful commentary and debate about secure agentic AI that was raised by our previous blog post in this series motivated our decision to continue researching and publicizing our findings.

Prompt injection via screenshots in Perplexity Comet

Perplexity’s Comet assistant lets users take screenshots on websites and ask questions about those images. These screenshots can be used as yet another way to inject prompts that bypass traditional text-based input sanitization. Malicious instructions embedded as nearly-invisible text within the image are processed as commands rather than (untrusted) content.

How the attack works:

  • Setup: An attacker embeds malicious instructions in Web content that are hard to see for humans. In our attack, we were able to hide prompt injection instructions in images using a faint light blue text on a yellow background. This means that the malicious instructions are effectively hidden from the user.
  • Trigger: User-initiated screenshot capture of a page containing camouflaged malicious text.
  • Injection: Text recognition extracts text that’s imperceptible to human users (possibly via OCR though we can’t tell for sure since the Comet browser is not open-source). This extracted text is then passed to the LLM without distinguishing it from the user’s query.
  • Exploit: The injected commands instruct the AI to use its browser tools maliciously.

Attack demonstration:

Prompt injection via website navigation in Fellou browser

While Fellou browser demonstrated some resistance to hidden instruction attacks, it still treats visible webpage content as trusted input to its LLM. Surprisingly, we found that simply asking the browser to go to a website causes the browser to send the website’s content to their LLM.

How the attack works:

  • Setup: An attacker embeds malicious visible instructions on their website.
  • Trigger: User simply asks the AI assistant to navigate to the attacker’s webpage (explicit user-triggered summarization not required).
  • Injection: The browser passes both the user’s query and the visible page content to the LLM in a way that allows the webpage text to override or modify the user’s intent.
  • Exploit: The injected commands instruct the AI to use its browser tools maliciously.

Attack demonstration:

Disclosure timeline

Perplexity:

  • October 1, 2025: Prompt injection via screenshots issue discovered and reported to Perplexity.
  • October 2, 2025: Public disclosure notice sent to Perplexity.
  • October 21, 2025: Public disclosure of vulnerability details.

Fellou:

  • August 20, 2025: Prompt injection via website navigation issue discovered and reported to Fellou.
  • October 21, 2025: Public disclosure of vulnerability details.

Impact and implications

As noted in our previous blog post, long-standing Web security assumptions break when AI agents act on behalf of users. Agentic browser assistants can be prompt-injected by untrusted webpage content, rendering protections such as the same-origin policy irrelevant because the assistant executes with the user’s authenticated privileges. This lets simple natural-language instructions on websites (or even just a Reddit comment) trigger cross-domain actions that reach banks, healthcare provider sites, corporate systems, email hosts, and cloud storage.

A consistent theme in agentic browsing vulnerabilities

Readers will note that each of these attacks look similar. Fundamentally, they boil down to a failure to maintain clear boundaries between trusted user input and untrusted Web content when constructing LLM prompts while allowing the browser to take powerful actions on behalf of the user.

We recognize that this is a hard problem, and we have some longer-term ideas that we’re exploring in collaboration with our research and security teams to address such problems. But until we have categorical safety improvements (i.e., across the browser landscape), agentic browsing will be inherently dangerous and should be treated as such. In the meantime, browsers should isolate agentic browsing from regular browsing and initiate agentic browsing actions (opening websites, reading emails, etc.) only when the user explicitly invokes them.

In the next blog post in this series, we will talk through Brave’s plans for more securely bringing agentic browsing to our 100 million+ users.

Source: https://brave.com/blog/unseeable-prompt-injections/