Credential-Phishing Campaign Distributed From a Compromised AirDroid (Sand Studio) Mailbox

A two-stage credential-harvesting kit whose architecture is consistent with adversary-in-the-middle session theft, delivered by mail that raw headers confirm was sent from inside a vendor tenant publishing DMARC p=reject — with the operator answering our challenge in-thread seven minutes later. Scope: one mailbox. See Section 10, "What we did not find".

Advisory ID

LH-2026-001

Published

2026-08-06

Last updated

2026-08-06

Severity

High

Traffic Light Protocol

TLP:CLEAR

Author

Daniel Wilson Kemp
Founder & CEO, Lifted Holdings LLC

Status: vendor notified 2026-08-06 at 14:51:43 UTC; automated acknowledgement (Ticket #74851) at 14:52:29 UTC; full technical report sent to the vendor's published security address at 17:10:24 UTC. No substantive vendor response at the time of publication — a short interval, and outside Singapore business hours (SGT = UTC+8). We draw no inference from that interval. As of our last check on 2026-08-06 the attacker infrastructure was still reachable. This advisory will be updated with any vendor statement.

Section 1Summary

On 2026-08-06 at 14:06:03 UTC, Lifted Holdings LLC received a credential-phishing email sent from a Sand Studio Pte. Ltd. business-development mailbox on the airdroid.com domain. The message was addressed to undisclosed-recipients:; with our address BCC'd, carried the subject "Sand Studio Pte. Ltd. - RFQ & Investment Partnership", opened "Dear Prospective Partner", and offered a "REVIEW PROJECT" hyperlink.

The message was not spoofed. The raw message headers, obtained and parsed on 2026-08-06, carry dkim=pass header.i=@airdroid.com header.s=google, spf=pass from a Google outbound relay, and dmarc=pass (p=REJECT sp=REJECT dis=NONE), with no hop outside Google's infrastructure in the Received: chain (Section 5). Independently of any header analysis, when our founder challenged the sender in-thread, the mailbox replied 7 minutes later, quoting his text and instructing him to "log in using your email account." A spoofing sender never receives that reply.

The linked payload is a two-stage credential-harvesting kit whose architecture is consistent with adversary-in-the-middle session-token theft (moderate confidence — see Section 6): a Microsoft-branded gate on an aged, abused domain that hands the victim's email address to a Cloudflare-fronted .icu domain registered seven days before the campaign, which serves a Google sign-in clone. When we queried on 2026-08-06 the stage-2 infrastructure had no record in the public sources we checked. Indicators are published in Section 7.

Section 2Key findings

• Mail was sent from inside the vendor's Google Workspace tenant, not forged. The raw headers show dkim=pass with d=airdroid.com s=google, spf=pass from Google relay 209.85.220.65, dmarc=pass against the domain's p=reject policy, and no external hop in the Received: chain. (Confidence: confirmed by direct observation — see Section 5. What that does not establish is equally important: see Section 10.)
• The operator replied in-thread within 7 minutes. At 14:51:58 UTC the mailbox answered our 14:45:03 challenge, quoted our own words back to us, and urged us to authenticate. This establishes live human control of the mailbox and does not depend on header analysis.
• Two-stage kit whose architecture is consistent with adversary-in-the-middle (AiTM) session-token theft. Stage 1 identifies and forwards the victim; stage 2 renders an identity-provider-matched sign-in clone. Standard MFA (TOTP or push) does not defend against session-cookie relay. (Confidence: moderate — architecture observed; end-to-end relay not directly observed.)
• The infrastructure was effectively undocumented, though not unscanned. One prior public urlscan.io record for addendum-200notice-encryption-base.icu exists, dated 2026-07-31 — one day after the domain was registered and six days before the message we received — but that scan terminated on example.com and did not capture the payload. No public analysis of the kit or its indicators existed before this advisory. Public records now exist for both stages — see Third-party corroboration. Correction to v1.0, which stated zero prior scans; see Section 6. We have not surveyed commercial blocklists or vendor detection.
• Victim identity is passed in the URL fragment. Fragments are not transmitted in the HTTP request, so the victim identifier never reaches web-server, proxy or secure-web-gateway click logs. Here the fragment is appended client-side by stage 1's redirect, so it is not present in the emailed link either — a mail-security URL rewriter captures only the stage-1 URL. The effect is to keep the victim identifier out of the logs defenders normally search, and it is the precondition for pre-filling the username and fingerprinting the victim's identity provider.
• Stage 1 sits on an aged, abused legitimate domain. pulp2pack.com is roughly 2,806 days (~7.7 years) old by our lookup, sits on GreenGeeks shared hosting, and its root currently serves an unrelated Indonesian-language gambling SEO link farm. We assess it as an abused domain rather than one the actor registered for this campaign; we cannot from outside exclude re-registration of an expired domain.
• Stage 2 is gated by a Cloudflare Turnstile human-verification challenge. Re-checked 2026-08-06 19:15–19:25 UTC from two independent vantage points, the stage-2 host answers HTTP 200 with a Turnstile gate in front of the payload. A challenge of this kind obstructs automated URL analysis without blocking a human victim. Correction to v1.0: we previously reported per-IP “burn-after-view” cloaking here. That finding is withdrawn — see the correction notice in Section 6.
• This is a multi-host campaign, not a single deployment. The identical kit path /bidaccess/rfp-notification.html appears in public scan records on several unrelated hosts, the earliest dated 2026-05-05 — three months before the message we received. The actor rotates hosting across compromised sites, object storage and serverless platforms while keeping the path constant, which makes the path itself a durable hunting string.
• Brand switches between stages. Microsoft branding at stage 1, Google branding at stage 2. The stage-1 script accepts a victim address in multiple encodings and forwards it, which would permit identity-provider selection — but our request carried no victim identifier, so we cannot confirm that the served clone varies by victim.
• Staging preceded the send by about 50 minutes. The stage-1 file returned Last-Modified: Thu, 06 Aug 2026 13:15:32 GMT — written, or last modified, 50 minutes 31 seconds before the 14:06:03 UTC send, subject to the origin server's clock.
• Reporter exposure: none identified. No Lifted Holdings credentials were entered against this infrastructure and no cardholder data exposure was identified.
• Scope: one mailbox. Our evidence establishes adversary control of a single mailbox on airdroid.com and nothing beyond it. No compromise of AirDroid products, systems, customer data or user accounts is established or claimed — see Section 10.

Assessment and confidence levels

Section 3Disclosure timeline

All timestamps UTC, 2026-08-06.

Publication without an embargo, and why

We did not give Sand Studio a disclosure window before publishing, and we told the vendor so at the time. Our 17:10:24 UTC disclosure to security@airdroid.com said in terms that we were not holding for a standard embargo window, and why. We notified the vendor 45 minutes after receipt, escalated through its own published security-reporting address with the full report attached, and have received nothing beyond an automated ticket acknowledgement. We make no claim of vendor cooperation, confirmation, or response, because there has been none.

Three facts drove the decision:

• The infrastructure was reachable. As of our last check on 2026-08-06, stage 1 returned HTTP 200 and the stage-2 domain still resolved and answered over plain HTTP. Neither domain had been suspended.
• No public analysis existed for it. The stage-2 domain had a single prior urlscan.io record, dated 2026-07-31, which did not capture the payload — and no published analysis of the kit or its indicators. Until indicators are published, reputation-based controls have nothing to match on, and detection falls back on heuristics that the Turnstile gate is well placed to defeat.
• The other recipients cannot see each other. The send was BCC'd to undisclosed-recipients:;. Every other person who received that mail is unaware there are others, unaware the sender was under adversary control, and still exposed. Only the vendor can notify them individually. Publishing the indicators is the only lever we hold that reaches them.

We regard withholding live, unblocked indicators from exposed third parties as the greater harm. We offered to publish alongside Sand Studio's own advisory rather than ahead of it, offered our draft in advance, and offered to work with the vendor on timing. Those offers stand. We will publish any statement the vendor wishes to make.

Section 4Why this matters

AirDroid states that its product suite has surpassed 500 million downloads and users worldwide across all platforms. We cite the vendor's own published figure for exactly one purpose — to establish the footprint of the vendor, not the reach of this incident. AirDroid and AirDroid Business are widely deployed Android device-management products, and mobile device management holds privileged administrative authority inside customer environments. A compromised mailbox at a vendor in that position warrants prompt disclosure, which is why we reported it within 45 minutes and are publishing the indicators.

The blast radius we can actually speak to is the correspondence reach of a single mailbox: whoever was on that 14:06 UTC send, plus anyone who has ever exchanged mail with that address and would find a follow-up from it unremarkable.

Two structural factors make that reach unusually effective:

• Trust inheritance. Mail from a vendor's real domain, aligned under a p=reject policy, arrives with the full trust of an established commercial relationship. It bypasses the heuristics that catch lookalike domains, because it is not a lookalike — it is the domain.
• Privileged product context. AirDroid Business is a mobile device management platform. MDM holds administrative authority over customer endpoints. A recipient who is an MDM customer has every reason to read mail from that domain, and to act on it.

Lifted Holdings is an active AirDroid Business customer. We use it for fleet management of Android-based vending endpoints. That makes this a supply-chain security event for us and not merely inbound spam, and it is why this went to incident response rather than to a spam folder.

Section 5Email authentication analysis

The central question for any recipient is whether the sending domain was forged. The published DNS policy for airdroid.com makes that answerable.

DNS records, queried 2026-08-06

airdroid.com          MX    aspmx.l.google.com (1)
                            alt1.aspmx.l.google.com (5)
                            alt2.aspmx.l.google.com (5)
                            aspmx2.googlemail.com (10)
                            aspmx3.googlemail.com (10)
                            -> Google Workspace tenant

airdroid.com          TXT   v=spf1 include:_spf.google.com include:amazonses.com include:shops.shopify.com include:mail.zendesk.com -all
                            -> "-all" = hard fail for any unlisted source

_dmarc.airdroid.com   TXT   v=DMARC1;p=reject;rua=mailto:dmarc-reports@airdroid.com;adkim=s;aspf=r
                            -> p=reject, strict DKIM alignment, relaxed SPF alignment

What the policy implies

p=reject instructs receiving mail systems to reject messages that fail DMARC evaluation outright rather than quarantining them. adkim=s requires the DKIM signing domain (d=) to match the From: domain exactly, not merely share an organisational parent. -all in the SPF record hard-fails every source not explicitly listed.

Under that combination, a message forging @airdroid.com from outside the tenant would be expected to fail DMARC and be rejected rather than delivered. This message was delivered to the inbox. That was our initial, policy-based reading; the raw headers settle it directly.

Raw header verification — observed, not inferred

The original .eml was exported and parsed on 2026-08-06. Verbatim from the message:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@airdroid.com header.s=google header.b=Ns2xG88b;
  arc=pass (i=1);
  spf=pass (google.com: domain of debbie.hu@airdroid.com designates
            209.85.220.65 as permitted sender) smtp.mailfrom=debbie.hu@airdroid.com;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=airdroid.com

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=airdroid.com; s=google; ...
Return-Path:    <debbie.hu@airdroid.com>
Message-ID:     <CANKq_2yK8PqJwMFSenTDmmwxDEQkd_W-bDZqsprM8HU8DheW=g@mail.gmail.com>
Date:           Thu, 06 Aug 2026 22:06:03 +0800

Received: (2 hops, both internal to Google)
  from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65])
       by mx.google.com with SMTPS ... (Google Transport Security)
  by 2002:a05:6504:b8a:b0:30e:4ce7:25ab with SMTP

Conclusion, directly evidenced: the message was composed in the Gmail interface and sent from an authenticated session inside Sand Studio's Google Workspace tenant, through Google's own outbound relay, with a valid domain DKIM signature. It was not spoofed, not relayed, and not injected. Someone was logged into that mailbox and sent it.

The DKIM nuance, stated precisely

This distinction matters, so it is worth stating precisely.

• The valid DKIM signature on this mail is a domain-level assertion applied automatically by Google to all authenticated outbound mail for the tenant. It is not a per-mailbox credential and it is not per-message proof of a specific human's intent.
• It does not mean DKIM was "cracked", "broken", "bypassed", or that any signing key was stolen. Nothing in our evidence supports that, and we are not claiming it.
• What it proves is exactly one thing: the message originated from an authenticated sender inside the airdroid.com tenant. That is equally consistent with a stolen password, a stolen session cookie, a malicious OAuth grant, or a rogue insider. We cannot distinguish between those from outside.
• It cannot scope the incident. A domain-level signature looks identical whether one mailbox is compromised or fifty. Any reading of DKIM validity as evidence of a company-wide compromise is incorrect. See Section 10.

Collateral finding — the domain's published DMARC reporting address does not accept mail

The DMARC record above publishes an aggregate-report destination, dmarc-reports@airdroid.com, and specifies no failure-report (ruf) destination at all. When we copied that address on our 17:10:24 UTC disclosure, the message was rejected at 17:10:37 UTC by aspmx.l.google.com — the domain's own authoritative mail host — with 550 5.1.1 The email account that you tried to reach does not exist. The record was re-queried against an independent public resolver and returns the same destination, and the address is on the same domain as the record, so no external-destination authorisation is required. This is independently verifiable by any reader from public DNS plus one SMTP transaction.

Stated precisely, and this is the limit of the claim: a published rua address that does not accept mail means DMARC aggregate reports — the telemetry by which a domain owner learns what is being sent as their domain — are undeliverable. It is a mail-authentication hygiene gap in the reporting path only. It is not evidence of this compromise, it is not its cause, and it should not be characterised as negligence. The domain's enforcement posture is meanwhile stronger than most: p=reject with strict alignment is stricter than the majority of domains deploy.

Independent corroboration that does not rely on headers

The 14:51:58 reply settles the spoof question on its own, with no header analysis required. That message (1) arrived in response to a challenge we sent to the vendor mailbox, (2) quoted our challenge text back to us, and (3) answered it with social engineering — an assurance that the mail was genuine plus an instruction to log in.

An attacker who merely forges a From: address never receives the reply and cannot do any of that. The message carried no divergent Reply-To, so our challenge went to the vendor mailbox itself. Independent of every header above, someone was reading and answering mail in that mailbox in real time.

Section 6Payload analysis

Delivery chain

Email (authenticated send, airdroid.com Workspace tenant)
   |  "REVIEW PROJECT" hyperlink
   v
STAGE 1 -- https://pulp2pack.com/bidaccess/rfp-notification.html
   |  hijacked legitimate domain; Microsoft-branded "identity verification" gate
   |  auto-extracts / prompts for victim email, then hands off via URL fragment
   v
STAGE 2 -- https://addendum-200notice-encryption-base.icu/?b4f61f2a#<victim-email>
           Cloudflare-fronted; Turnstile-gated; Google sign-in clone; credential capture
           inferred from the rendered form (submission endpoint not observed);
           architecture also consistent with post-MFA session-cookie relay
           (moderate confidence; not observed end to end)

Stage 1 — pulp2pack.com/bidaccess/rfp-notification.html

Retrieval and hosting

http_code   200
remote_ip   23.106.55.199
size        21039 bytes
last-modified: Thu, 06 Aug 2026 13:15:32 GMT

23.106.55.199   PTR sgpr200.websitehostserver.net
                AS59253  LEASEWEB SINGAPORE PTE. LTD.  (SG)
nameservers     ns1.greengeeks.net / ns2.greengeeks.net   (GreenGeeks shared hosting)

We assess the domain as abused rather than attacker-registered. pulp2pack.com is approximately 2,806 days old (~7.7 years) by our lookup on 2026-08-06. Its root currently serves an Indonesian-language slot-gambling SEO link farm, and urlscan.io holds a record for an unrelated Indian print-shop site at sunriseprintstore.in.pulp2pack.com dated 2025-12-14. An aged domain simultaneously serving unrelated spam verticals and a phishing path is characteristic of a compromised shared-hosting account reused as free infrastructure — though from outside we cannot exclude re-registration of an expired domain, which would make it attacker-controlled instead. On the evidence we have, our assessment is that the domain's owner is also a victim of this activity. We make no claim about the domain's registrant, about other sites on the same host, or about GreenGeeks. Defenders should treat the specific path as malicious and the domain as an abused third party.

Behaviour, from static analysis of the single inline script

Because Lifted Holdings was BCC'd on a generic blast rather than sent a personalised link, no email address was embedded in our URL, and the page fell through to prompting for one manually. Recipients who received a personalised link would have been carried through without ever typing their address.

Stage 2 — addendum-200notice-encryption-base.icu

Stage-2 reachability, two vantage points — 2026-08-06

Three details establish the mechanism. The cleartext “HTTP 200” from the original vantage was a security vendor’s block page classifying the domain as phishing — not content from the attacker’s host at all. No such product is installed on the workstation, so the interception is upstream on that network path. And TCP reachability to both Cloudflare addresses on port 443 is fine, with unrelated Cloudflare-fronted sites loading normally — the reset keys on the hostname in the TLS SNI, which is the signature of an in-path filter rather than an origin behaviour.

What stage 2 actually does is present a Cloudflare Turnstile human-verification challenge in front of the payload. That still obstructs automated analysis — a crawler gets the challenge, a human victim clicks through it — but it is a different mechanism from per-IP blocking, and it is directly observed rather than inferred.

Practical consequence for responders: a “the link is dead / it doesn’t load for me” result is not evidence that a user was safe — and it may say more about your egress filtering than about the attacker. Assume the victim saw live content even where your own retrieval fails.

Related deployments of the same kit

Public scan records show the identical kit path /bidaccess/rfp-notification.html on unrelated hosts, the earliest three months before the message we received. The actor rotates hosting — compromised sites, object storage, serverless platforms — while keeping the path constant. Status column re-checked 2026-08-06 19:23 UTC.

Hunting implication: block the hosts, but hunt the path. The URL path has survived at least three months and multiple hosting providers, which makes it a far more durable detection than any single domain in Section 7.

Identity-provider fingerprinting

The kit rendered Microsoft branding at stage 1 and Google branding at stage 2. Together with the email-extraction and encoding-tolerance logic — which accepts a victim address in multiple encodings and forwards it — this would permit a kit to resolve the victim's email domain to an identity provider and serve the matching login clone. We cannot confirm that behaviour. Because Lifted Holdings was BCC'd on a generic blast, our request carried no victim identifier, so the Google clone we saw may equally be the kit's default page rather than a fingerprint-selected one. Both airdroid.com and liftedholdings.com are Google Workspace domains. Defenders should not assume the brand they see is the brand another recipient saw — an organisation that uses neither Microsoft nor Google is not thereby out of scope, and a Microsoft-branded gate is not evidence that Microsoft credentials were the target.

MITRE ATT&CK mapping

Section 7Indicators of compromise

All indicators below are provided as copyable plaintext for direct ingestion into blocklists, SIEM watchlists, and hunt queries. Observed 2026-08-06 unless otherwise stated. Machine-readable copies: CSV · STIX 2.1.

All indicators, one per line

Copy-paste ready. Annotations follow in the categorised blocks below — read them before you act on this list.

pulp2pack.com
addendum-200notice-encryption-base.icu
https://pulp2pack.com/bidaccess/rfp-notification.html
https://addendum-200notice-encryption-base.icu/?b4f61f2a
23.106.55.199
104.21.86.28
172.67.214.97
sgpr200.websitehostserver.net
ns1.greengeeks.net
ns2.greengeeks.net
lennon.ns.cloudflare.com
ophelia.ns.cloudflare.com
debbie.hu@airdroid.com
b4f61f2a
/bidaccess/rfp-notification.html
aaf1470747fcb7bad9197fa92c2f5b028f1132ef0396646308623eb4059a86d2

Email indicators

debbie.hu@airdroid.com                    compromised sender mailbox (Google Workspace;
                                          headers show dkim=pass d=airdroid.com s=google,
                                          spf=pass, dmarc=pass, no external Received hop;
                                          account holder is a VICTIM, not the actor)
Subject: Sand Studio Pte. Ltd. - RFQ & Investment Partnership
To:      undisclosed-recipients:;         bulk send; recipients BCC'd
Salutation: "Dear Prospective Partner"
Lure:    "REVIEW PROJECT" hyperlink; RFQ / investment-partnership pretext
Send:    2026-08-06 14:06:03 UTC
Operator reply text (2026-08-06 14:51:58 UTC):
  "This email serves as confirmation that it is from our company and contains a
   project proposal for your review. Please log in using your email account to
   access and review the document."

URL indicators

https://pulp2pack.com/bidaccess/rfp-notification.html            stage 1
https://addendum-200notice-encryption-base.icu/?b4f61f2a         stage 2
https://addendum-200notice-encryption-base.icu/?b4f61f2a#<victim-email>
                                                                 stage 2, fragment handoff

Domain indicators

pulp2pack.com                             ABUSED legitimate domain (~2806 days /
                                          ~7.7 years old by our lookup); GreenGeeks
                                          shared hosting. Assessed as an abused third
                                          party, not attacker-registered. Block the
                                          /bidaccess/ path; weigh an apex block against
                                          your own environment.
addendum-200notice-encryption-base.icu    attacker-registered 2026-07-30, Namecheap,
                                          Cloudflare-fronted
sunriseprintstore.in.pulp2pack.com        unrelated third-party site recorded on the
                                          same abused domain (urlscan.io, 2025-12-14).
                                          Listed as context for the abuse assessment
                                          only - NO allegation is made against that
                                          site or its operator.

IP addresses and ASNs

23.106.55.199    AS59253  LEASEWEB SINGAPORE PTE. LTD. (SG)   stage-1 origin
                          PTR sgpr200.websitehostserver.net
104.21.86.28     AS13335  Cloudflare, Inc.                    stage-2 edge (anycast)
172.67.214.97    AS13335  Cloudflare, Inc.                    stage-2 edge (anycast)

Nameservers:
  ns1.greengeeks.net / ns2.greengeeks.net            stage-1 hosting
  lennon.ns.cloudflare.com / ophelia.ns.cloudflare.com   stage-2

NOTE: the Cloudflare addresses are shared anycast edge IPs. Do NOT block them
outright - block the hostname. The stage-2 origin remains concealed.

Kit artefacts and hunt strings

Campaign ID:        b4f61f2a
URI path:           /bidaccess/rfp-notification.html
Path fragment:      /bidaccess/
Handoff pattern:    <stage2>/?<campaign-id>#<victim-email>
Victim encodings:   plaintext | base64 (atob) | hex
Staging timestamp:  Last-Modified: Thu, 06 Aug 2026 13:15:32 GMT
Payload size:       21039 bytes (stage-1 HTML)

Stage-1 HTML file hashes (rfp-notification.html, 21039 bytes):
  SHA-256  aaf1470747fcb7bad9197fa92c2f5b028f1132ef0396646308623eb4059a86d2
  SHA-1    288e5594263d3ce728cb7d5cc56d8ddd47a860f8
  MD5      e7e20d67542713dd23f0fd287b649779

HIGH-FIDELITY STRING (misspelling, verbatim):
  (c) 2026 Microsoft Corportation
  Corportation

Fake progress strings (fire at 600 / 1200 / 1800 / 2400 ms):
  Checking browser compliance
  Verifying encryption protocols
  Validating user identity

Obfuscated identifiers (randomised, 7 chars):
  q3n7r9v   u8t4m2w   h8p3w6n   k2q8h5t   m5v8r2k   r5h9x3w   r4v7m9t

Abused genuine Microsoft asset (loaded by stage 1 for authenticity):
  https://aadcdn.msauth.net/shared/1.0/content/images/backgrounds/4_eae2dd7eb3a55636dc2d74f4fa4c386e.svg

Stage-2 clone artefact:
  base64-encoded continue= parameter wrapping a genuine
  accounts.google.com/v3/signin/identifier path

Note on the aadcdn.msauth.net asset: that host is legitimate Microsoft infrastructure and must not be blocked. It is listed because a request for that specific background SVG originating from a page that is not on a Microsoft login domain is a useful referer-based hunt pivot.

Section 8Detection & hunting guidance

Block first

• Block addendum-200notice-encryption-base.icu (all subdomains) at DNS, egress proxy, and mail-security URL rewriting.
• Block the URL https://pulp2pack.com/bidaccess/rfp-notification.html and the path prefix /bidaccess/ on that host. Consider whether a full-domain block on pulp2pack.com is proportionate for your environment — it is a hijacked legitimate domain.
• Block 23.106.55.199 at egress. Do not block the Cloudflare anycast addresses.

Hunt inbound mail

• Search all inbound mail from airdroid.com since 2026-07-30 — the stage-2 registration date, not our receipt date. The campaign may predate our sample.
• Search for the subject string, the "Dear Prospective Partner" salutation, and the RFQ / investment-partnership pretext.
• Prioritise messages addressed to undisclosed-recipients:; from any known-good vendor domain — legitimate business correspondence from an account manager rarely takes that shape.

# Google Workspace / Gmail investigation search
from:airdroid.com after:2026/07/29
from:airdroid.com "Prospective Partner"
"pulp2pack.com" OR "addendum-200notice-encryption-base"

# Generic mail-gateway / SIEM predicates
sender_domain = "airdroid.com" AND received >= 2026-07-30
subject CONTAINS "RFQ & Investment Partnership"
body_url CONTAINS "/bidaccess/"
body_url CONTAINS ".icu/?b4f61f2a"

Hunt web traffic

• Proxy, SWG, and DNS logs: search for /bidaccess/, for the .icu apex, and for the campaign ID b4f61f2a appearing as a bare query string.
• Pivot on referer: any request to the aadcdn.msauth.net background SVG above with a referer that is not a Microsoft login domain.

If a user interacted

Assume session-cookie theft, not merely password theft. This is the difference between a contained incident and a persistent one:

1. Revoke all active sessions for the account. A password reset alone does not evict a stolen session cookie — the attacker stays signed in through it.
2. Revoke third-party OAuth grants and app passwords. These survive both password resets and session revocation, and are the most common quiet persistence mechanism after an AiTM compromise.
3. Re-enrol MFA factors and reset the password — in that order, after revocation, not instead of it.
4. Audit for attacker persistence in the mailbox: forwarding rules, filters that mark mail read or move it to obscure folders, delegated access, and mail-send-as entries.
5. Pull the sign-in audit log for the account — source IPs, ASNs, and user agents — and reconcile against known devices.
6. Check for outbound sends you did not author, particularly to external contacts, and particularly BCC'd bulk sends.

Third-party corroboration and current detection coverage

The indicators below are now filed with public threat-intelligence services, so nothing in this advisory rests on our assertion alone. Verified 2026-08-06 21:21 UTC.

The urlscan stage-1 scan followed the redirect and resolved to the stage-2 domain in a single capture, which is the cleanest available demonstration of the automatic hand-off described in Section 6.

One further observation about coverage. The VirusTotal record for stage 1 already existed when we went to file, timestamped 2026-08-06 14:11:10 UTC — five minutes after the campaign was sent — sitting at 1 / 92. We did not create it. Another recipient's mail security almost certainly did, which is independent evidence that the send reached a wider distribution than us and that at least one other organisation's tooling saw it immediately. Our reanalysis at 20:56 UTC moved it to 5 / 92.

Section 9Recommendations

For organisations that may have received this mail

1. Apply the blocks and run the hunts in Section 8. Start with mail from airdroid.com since 2026-07-30.
2. Apply the rule that should apply to mail from any supplier: treat unexpected mail from any vendor that requests a login or credential entry as suspect until you have confirmed it through a channel that is not email — a phone call to your account representative, or the supplier's support portal. Where you have a current commercial relationship with Sand Studio / AirDroid, that rule applies to their mail as it applies to everyone else's, and the indicators below let you check this campaign specifically.
3. Do not use in-thread replies to verify a suspicious message. If the mailbox is under adversary control, you are asking the attacker whether the attacker is real; we received exactly that answer within 7 minutes.
4. Move externally-facing and business-development accounts to phishing-resistant MFA (FIDO2 security keys or passkeys). This is the control that actually breaks AiTM relay — TOTP and push approval do not.
5. Where your gateway supports it, enable full-URL capture including fragments, or ensure endpoint browser-history collection is available to your responders. See the caveat in Section 8.
6. Review your vendor-risk process for the specific case of authenticated mail from a trusted vendor domain. Lookalike-domain detection does not cover it, because there is no lookalike.

For Sand Studio Pte. Ltd.

Offered constructively, and with an explicit caveat: we have no visibility into what Sand Studio has already done. The vendor may have completed some or all of these steps before this advisory was published; nothing below should be read as a statement that it has not. These are the standard containment steps for this class of incident, published so that any organisation facing the same pattern has them too. We remain available to assist and will publish any statement the vendor wishes to make.

1. Revoke all active sessions for the affected mailbox in addition to resetting credentials. A password reset alone does not evict a stolen session cookie.
2. Audit that mailbox for persistence: forwarding rules, filters, delegated access, app passwords, send-as entries, and third-party OAuth grants.
3. Pull the Google Workspace login audit log for the account — source IPs, ASNs, user agents, token grants — and establish the initial access vector. Only you can determine the true scope; we cannot, and we have not claimed to.
4. Check whether other tenant mailboxes show the same access pattern.
5. Identify and directly notify every recipient of the 2026-08-06 14:06:03 UTC send. They were BCC'd, they cannot see one another, and you are the only party able to reach them.
6. Enforce phishing-resistant MFA (FIDO2 / passkeys) on business-development and other externally-facing mailboxes.
7. Publish a customer-facing notice. Partners are receiving mail that passes your domain's authentication policy; only you can authoritatively tell them what is and is not legitimate.

Section 11Analyst comment

"I challenged that mailbox at 14:45. Seven minutes later someone quoted my own words back at me and told me to go log in. A spoofing attacker never sees that message. Whoever wrote back was sitting in the mailbox, reading mail as it arrived."

Daniel Wilson Kemp — Founder & CEO, Lifted Holdings LLC

"The headers are unambiguous about one thing and silent about everything else. They prove the mail was sent from an authenticated session inside that tenant. They cannot tell you how the session was obtained, and they cannot tell one compromised mailbox from fifty. Anyone reading a DKIM pass as evidence of a company-wide breach is reading something that is not there."

Daniel Wilson Kemp — Founder & CEO, Lifted Holdings LLC

"If one of your people clicked this, resetting the password is not containment. The session cookie is what the attacker wants, and it survives a reset. Revoke the sessions and the OAuth grants first, then reset the password. In that order."

Daniel Wilson Kemp — Founder & CEO, Lifted Holdings LLC

"The victim's address is handed forward after the hash, so it never reaches a server log. If you hunt only on the URLs your proxy recorded, you will undercount who was targeted."

Daniel Wilson Kemp — Founder & CEO, Lifted Holdings LLC

"We proved one compromised mailbox. Not a breached company, not a breached product, not one affected end user. I would rather publish a narrow claim I can defend line by line than a wide one that falls apart the first time a reporter checks it."

Daniel Wilson Kemp — Founder & CEO, Lifted Holdings LLC

"We pay for AirDroid Business. That is exactly why this went to incident response at 15:09 UTC instead of into the spam folder. A vendor's mailbox is part of my attack surface whether I like it or not."

Daniel Wilson Kemp — Founder & CEO, Lifted Holdings LLC

Section 12About Lifted Holdings & contact

Lifted Holdings LLC is a payments and technology company based in Tennessee, operating across merchant payments and connected-device platforms (liftedholdings.com, liftedpayments.com, agevend.com). Lifted Holdings is an active AirDroid Business customer, using the platform for fleet management of Android-based vending endpoints — which is why this incident was handled as vendor-supply-chain risk rather than as inbound spam.

The discovery, investigation, payload analysis, and this advisory are the work of Daniel Wilson Kemp, Founder & Chief Executive Officer, Lifted Holdings LLC. He is available for technical follow-up and for verification of any indicator published here.

Author & contact

Daniel Wilson Kemp
Founder & CEO, Lifted Holdings LLC

Email

will@liftedholdings.com

Telephone

855-678-5142

Web

liftedholdings.com
liftedpayments.com
agevend.com

Security reporting

/.well-known/security.txt
Disclosure policy

Canonical advisory URL

https://liftedholdings.com/security/advisories/2026-001-airdroid-bec-phishing

Revision history

v1.2   2026-08-06 21:25 UTC   Added third-party corroboration (public urlscan.io scans for
                                both stages, VirusTotal 5/92) and the Google Safe Browsing
                                coverage gap. Noted that a VirusTotal record already existed
                                five minutes after the send, filed by another party.
v1.1   2026-08-06 19:48 UTC   Correction. Withdrew the stage-2 per-IP cloaking finding after
                                re-testing from a second egress showed the resets were in-path
                                filtering on our own network, not attacker behaviour. Replaced
                                with the directly observed Cloudflare Turnstile gate. Corrected
                                the urlscan.io novelty claim (one prior record exists, dated
                                2026-07-31, which did not capture the payload). Added related
                                deployments of the same kit path on unrelated hosts.
v1.0   2026-08-06 19:12 UTC   Initial publication.