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-12

Vendor response

Received — publicly confirmed on the vendor's own domain

Our incident response

Concluded 2026-08-12

Severity

High

Traffic Light Protocol

TLP:CLEAR

Author

Daniel Wilson Kemp
Founder & CEO, Lifted Holdings LLC

Status — updated 2026-08-12: concluded on our side. On 2026-08-12 at 11:32 UTC Sand Studio published a security notice on its own domain, Security Notice Regarding Recent Phishing Incident, and told us 36 minutes later that it "is published on AirDroid's official domain and serves as our public company statement regarding the incident." That was the one thing this advisory said was missing. Every prior communication reached us through the compromised tenant itself, authenticating exactly as the phishing message did; we said on 2026-08-10 that we could not tell the vendor from the adversary on that evidence, and we declined to guess. A statement carried on a second, independently controlled surface is a different kind of evidence, and we treat it as one. We are closing our incident response. See The public notice for what it establishes, what it does not, and the two limitations we record about how it is published. No finding, indicator or conclusion in this advisory has been changed at any point in this exchange. The scope limitation in Section 10 stands exactly as written: we established that one mailbox was compromised, which is not the same statement as the vendor's, that access was limited to one mailbox. Those two remain published side by side, unmerged.

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 had received nothing beyond an automated ticket acknowledgement. That was the position when this advisory was published, and this section records the reasoning as it stood then. It has since changed: the vendor responded substantively the following day, and its response is published at Vendor response below.

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. We said we would publish any statement the vendor wished to make. The vendor has made one, and the rest of this section is it.

Vendor response — added 2026-08-10

Sand Studio responded substantively on 2026-08-07, the day after publication, and asked us on 2026-08-10 to update this advisory so the public record reflects that work. This section is that update.

The vendor's customer notice, in full — private at the time, public five days later

This was a private email, not a public disclosure. It was addressed to undisclosed-recipients:; and reached us as one of the blind-copied recipients — which means we cannot see who else received it and cannot confirm that it reached every affected party, or what fraction of them it reached.

As of 2026-08-10 we could find no public statement of any kind. We checked the AirDroid newsroom (most recent entry October 2025), the AirDroid security centre at airdroid.com/resources/security/, and public web search. None carried an advisory, incident notice or breach disclosure relating to this event. We recorded that as an observation rather than a criticism — a vendor may have sound reasons for private notification — but the difference between "notified an unknown set of recipients privately" and "disclosed publicly" is load-bearing for anyone relying on this advisory, and for any organisation trying to work out whether it was on that BCC line.

Superseded on 2026-08-12. A public notice now exists on the vendor's own domain. The paragraph above is left standing as the record of what was true when it was written, which is how every correction in this advisory is handled. See The public notice.

Recommendation 7 of Section 9 asked Sand Studio to publish a customer-facing notice. It did so about sixteen and a half hours after the send. We had asked: the same recommendation was in the technical report sent to security@airdroid.com at 17:10:24 UTC on 2026-08-06, roughly thirteen hours earlier, and in v1.0 of this advisory. We cannot tell whether the notice was prompted by that report or was already in train, and we do not claim it either way. We reproduce it unedited:

"Dear Valued Customers,

Our company discovered today that an employee's email account was accessed without authorization, resulting in unauthorized emails being sent at 06-August-2026.

If you received this email: Please do not click any links or attachments within it. Please do not reply with any personal or business information. Please do not enter any account credentials or passwords. We recommend deleting the email.

If you have already clicked any links, downloaded attachments, or entered any credentials, please change your password immediately and notify your IT department.

Sand Studio is notifying their corporate email addressees and conducting internal investigation and containment of this incident.

We apologize for any inconvenience caused and rest assured the Sand Studio team is taking all necessary actions to contain this cybersecurity incident and you will be informed of any investigation outcome when it is ready."

AirDroid Business Technical Support Team — 2026-08-07 06:31:46 UTC

What the vendor reports

The following is Sand Studio's account of its own investigation, summarised from its messages of 2026-08-07 and 2026-08-10 and published because we undertook to publish any statement it wished to make. We have not independently verified any of it. It rests on Google Workspace audit data that only Sand Studio holds — which is exactly the limitation this advisory has carried since version 1.0.

• Initial access. Earlier in July, one of its employees received an external phishing email carrying substantially the same content and lure as the message we later received. The employee clicked the link, and an unauthorised party gained access to that employee's Google Workspace mailbox.
• Scope. The unauthorised access was limited to that employee's mailbox. The vendor states it has identified no evidence of unauthorised access to other company resources, to AirDroid products, or to customer data.
• Containment. The affected mailbox was secured and additional account-security measures implemented; the vendor reports that monitoring has identified no further anomalous sign-in activity since.
• Recipient notification. It identified the recipients of the phishing messages sent from the affected mailbox and issued security warnings advising them not to click links or otherwise interact.
• Upstream notification. It alerted the organisation associated with the mailbox that sent the original phishing message to its employee, so that party could investigate and act on its own side.
• Ongoing. It continues to monitor and review records, and undertook on 2026-08-07 to update us if its investigation identifies any material change to the scope described above.

What this changes, and what it does not

It answers the question we said only the vendor could answer — and it is not the same statement as ours. This distinction is worth being pedantic about, because the whole advisory rests on it. Our evidence established that one mailbox was under adversary control and gave us no basis to say anything about any other. That is an absence of evidence, and we were careful never to dress it up as evidence of absence. Sand Studio now asserts the positive claim we declined to make: that the unauthorised access was limited to that one mailbox. We are not treating the vendor's assertion as confirmation of ours, because ours was never a claim about the true scope — it was a statement about the limits of what we could see from outside. What has changed is that a party writing from the vendor's domain has now answered that question on the record, and the answer contradicts nothing we published. Whether that party is the vendor or the adversary is itself unresolved — see Provenance. Both statements stand here side by side; we have not merged them into one.

It addresses the exposure that drove publication without an embargo — on the vendor's account. The third of our three reasons was that the other recipients were BCC'd, could not see one another, and could be reached only by the vendor. Sand Studio states that it identified all recipients of the send and issued security warnings to them, and it published the customer notice above. Those are recommendations 5 and 7 of Section 9. This is the one claim in the vendor's account we have no way to check at all — we never held the recipient list, which is precisely why we raised the concern — and it happens to be the claim that retires our own justification for publishing without an embargo. We are not going to quietly let it do that. We record the vendor's statement, we have no evidence against it, and we note that we cannot verify it.

It changes no observation in this advisory. The header analysis in Section 5, the in-thread reply at 14:51:58, the payload analysis in Section 6 and every indicator in Section 7 are unaffected. Nothing in the vendor's account contradicts them; the vendor's own description of the initial access is consistent with the kit we documented.

It adds one thing we did not have: the chain runs at least three organisations deep. On the vendor's account, the mailbox that phished us had itself been taken over via the same lure sent from another organisation's mailbox, which Sand Studio in turn notified. That is the propagation mechanism this campaign relies on, stated by a party that sat in the middle of it: each compromised mailbox is used to phish the trusted correspondents of its owner, and every hop inherits real domain authentication and a real commercial relationship. We were one hop downstream. Whoever received that July message was one hop up. The defensive implication is that recipient notification has to travel in both directions — to the people the mailbox wrote to, and to whoever wrote to it — and Sand Studio states that it did both.

Provenance — can we tell the vendor from the adversary?

Every message in this section arrived from a domain where we have proven adversary presence, through the medium that is the subject of this advisory. One of them asked us to change a published security advisory. That deserves testing rather than assuming, so we tested it.

Version 1.3 of this section stated that we had not re-run the header authentication analysis on the vendor's messages. We have now done so, on every message received from airdroid.com between 2026-08-06 and 2026-08-10.

Every one of them passes. That establishes far less than it appears to. The phishing message at the top of that table passes the identical checks — dkim=pass header.i=@airdroid.com header.s=google, spf=pass from a Google outbound relay, dmarc=pass under p=reject. That is the central finding of this advisory, set out in Section 5: tenant authentication establishes where a message came from, not whether it is legitimate. Applied to the replies it returns the same answer it returned for the phish — sent from an authenticated session inside the airdroid.com tenant — and it cannot distinguish the vendor's security team from an adversary holding tenant access. We are not going to apply a weaker standard to a vendor's exculpatory mail than we applied to its incriminating mail.

One observation we will state and then immediately neutralise, because it invites over-reading: the phishing message left Google relay 209.85.220.65 while every subsequent message left 209.85.220.41. This is not evidence of anything. Those are addresses in Google's shared outbound pool, assigned per connection. We record it so that nobody reads significance into it later.

What the evidence does support, narrowly:

• The 02:30:21 message carries no evidential weight, and we do not treat it as vendor communication. It came from the compromised mailbox itself — the same mailbox that sent the phishing message and, twelve hours earlier, answered our challenge with social engineering. A reassuring “this was not me, we are investigating” sent to the one recipient who is loudly reporting the incident is exactly what an adversary in that mailbox would have reason to send. It is also exactly what the real account holder would send. Nothing available to us distinguishes the two, and we decline to guess.
• The substantive responses came from three other mailboxes. security@, biz-tech@ and success@ are not the compromised mailbox. For those messages to be the adversary's work, the adversary would have to hold several mailboxes in that tenant — which would directly contradict the vendor's own account that access was limited to one. So either the responses are genuine, or the incident is materially larger than the party writing them says it is. We cannot presently tell which, and we will not present the first as established.
• Two of those addresses had never written to us before. security@ and biz-tech@ appear in our correspondence for the first time during this incident. For security@ that is unremarkable and expected — it is the address published on the vendor's own security page, and we had only just filed a security report to it. To biz-tech@ we have found no public reference on the pages we checked. We note this as a fact and not an accusation: a long correspondence history would prove an address is real, not that a particular message from it is.
• No message in this section had been confirmed out of band when this analysis was written on 2026-08-10. There had been no voice call, no signed statement, no postal confirmation, and nothing published on the vendor's own website — no channel of any kind independent of the email system this advisory is about. We said we regarded a voice confirmation as the obvious next step. What resolved it was a different independent channel: on 2026-08-12 the vendor published on its own domain. We never obtained the voice confirmation, and we are not implying that we did. See The public notice.

The public notice — 2026-08-12

Five days and 21 hours after the send, Sand Studio published a security notice on airdroid.com. It is the first statement about this incident to reach us on a surface the compromised mailbox does not control, and it is the reason this advisory is now closed on our side.

We asked for it in those terms. On 2026-08-11 at 11:36:34 UTC, after four days of correspondence conducted entirely through the affected tenant, we wrote:

"I'd like you guys to follow standard security procedure and issue a release from a known company operated domain… A blind bcc email from the compromised workspace domain does not show resolution or customer disclosure… We can't alleviate a breach of a workspace account using the same email domain that was breached. My security team advises we are still treating as 'potentially compromised and not resolved'. Mostly due to the lack of public disclosure from an uncompromised source."

The notice was published 23 hours 55 minutes later. Unlike the customer notice of 2026-08-07, we are able to say when it appeared without relying on anyone's account of it: the page carries Last-Modified: Wed, 12 Aug 2026 11:32:13 GMT. The vendor's security team sent us the URL 36 minutes after that, describing it as its "public company statement regarding the incident."

What it adds to what we already had

Most of the notice restates the account the vendor gave us privately on 2026-08-07. Four things in it are new or newly on the record:

• Sessions and authorisations were revoked. "Within approximately two hours of the unauthorized phishing emails being sent, access to the affected account was secured, the account password was reset, and all active sessions and account authorizations were revoked." That is recommendation 1 of Section 9, which the private response had not addressed and which we had explicitly declined to record as done. It is now stated. It remains the vendor's statement about its own environment; we cannot verify it.
• The initial access vector was itself a phishing mail from another compromised organisation. "the employee had previously received a phishing email sent from an account associated with another organization and presented as a legitimate business communication." This is the same pattern, one hop upstream. The vendor is a downstream victim of the technique whose downstream victims we were writing about — and the chain is what makes this class of campaign self-propagating, because each compromised mailbox arrives at the next one carrying real authentication and a real relationship.
• They notified the upstream organisation. The response list includes "contacting the organization associated with the mailbox from which the original phishing message was received and advising them to investigate their potentially compromised account." That is the same action we took toward them, taken by them toward whoever is above them.
• The vendor commits to updating the notice. "If our continuing review identifies any material change to the scope or impact described in this notice, we will provide an appropriate update." A public undertaking on a public page is checkable in a way that a private one is not.

What it does not do

• It carries almost no indicators. One subject line, and nothing else: no URLs, domains, IP addresses, hashes or subject-line variants. A defender reading only the vendor's notice cannot hunt for this campaign in their own environment. That is what Section 7 of this advisory is for, and it is one reason we are leaving every indicator published.
• It gives no recipient count. The notice says identified recipients were warned; it does not say how many, so no one reading it can tell whether they were on that list.
• It does not address mailbox persistence specifically. Revoking sessions and account authorisations covers OAuth grants and app passwords on a plain reading. Forwarding rules and delegated access are a different mechanism, they survive a password reset, and they are not mentioned. Recommendation 2 therefore stays open on our list.
• It does not change the scope position. The notice asserts, again, that access was limited to one mailbox. That is the vendor's positive claim, not our finding; Section 10 still says what we could and could not see from outside, and we have not merged the two.

Two limitations in how it is published

We record these because we record this kind of thing about ourselves, and it would be inconsistent to soften it for someone else. Both are facts about the page, checked directly, not inferences about intent.

• The page asks search engines not to index it. It carries <meta name="robots" content="noindex, nofollow, noarchive, nosnippet, noimageindex">.
• Nothing links to it. It does not appear in any of the thirteen sitemaps referenced by airdroid.com/sitemap.xml, all of which we checked, and it is not linked from the Security Center at airdroid.com/resources/security/, which is the page we checked on 2026-08-10 and the page we asked them to use. Its URL is a 32-character hexadecimal string.

The practical consequence is that the notice is publicly reachable but not publicly discoverable. Anyone who has the URL can read it, with no account and no authentication — that is what makes it a public statement, and it is why we treat it as one. But a customer who received the phishing mail and goes looking for an explanation will not find this page through a search engine, through the vendor's security index, or through its sitemap. They would have to be sent the link. The link above is followable and this advisory is indexed, so from today one discoverable path to it exists.

What it establishes about provenance, precisely

The question the subsection above left open was whether we were corresponding with the vendor or with an adversary holding tenant access. Header authentication could not answer it, because the phishing message passes the same checks. Publication on airdroid.com answers it on different evidence: the website is a separate control plane from the Google Workspace mailbox, with separate credentials; the notice is hosted where the vendor's own staff and customers can see it, under the vendor's name; and the notice is consistent in every material respect with what the mailboxes told us.

We are not claiming proof, and the distinction still matters. We have not confirmed anything by voice, and we never obtained the out-of-band call we said we intended to seek. What we have is corroboration across two independently controlled surfaces instead of one, which is a materially different evidential position from the one we were in on 2026-08-10, and enough to resolve the question to our satisfaction. We are stating the standard we applied rather than implying a stronger one.

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 written when we had no visibility into what Sand Studio had already done. These are the standard containment steps for this class of incident, published so that any organisation facing the same pattern has them too.

Updated 2026-08-12. The vendor has since reported carrying out work covering most of these. On its own account it secured the affected mailbox and applied additional account-security measures, established the initial access vector from its audit data (3), notified all identified recipients of the send (5), and published a customer-facing notice (7) — privately on 2026-08-07 and then publicly on its own domain on 2026-08-12. Its public notice states that "all active sessions and account authorizations were revoked" within approximately two hours, which addresses (1); v1.3 and v1.4 of this advisory recorded (1) as unaddressed, which was correct on the evidence then available. (2) stays open: revoking sessions and authorisations does not remove mailbox forwarding rules or delegated access, which survive a password reset, and no statement we have mentions them. See Vendor response. We have not verified this work and are not in a position to; we record what the vendor states. The list is left standing unedited, because its value is now to the next organisation that finds itself here.

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.5   2026-08-12 15:45 UTC   Public notice; advisory concluded on our side. Sand Studio
                                published a security notice on airdroid.com at 11:32:13 UTC,
                                23h55m after we declined to accept mail from the affected tenant
                                as disclosure and asked for a statement on a company-operated
                                surface. Retrieved and verified it directly (HTTP 200,
                                Last-Modified header), recorded what it adds - sessions and
                                authorisations revoked, the upstream phishing mail that started
                                it, notification of that upstream organisation - and what it does
                                not do: no indicators, no recipient count, no mention of
                                forwarding rules or delegated access. Recorded that the page is
                                noindex and is absent from the sitemaps and the Security Center
                                index, so it is publicly reachable but not publicly discoverable.
                                Resolved the provenance question on the basis of corroboration
                                across a second, independently controlled surface, while stating
                                that no voice confirmation was ever obtained. No finding,
                                indicator or conclusion was changed; Section 10 is untouched.
v1.4   2026-08-10 14:10 UTC   Provenance. Ran header authentication on every message received
                                from airdroid.com during the incident window. All pass - and so
                                does the phishing message, which is the point: tenant
                                authentication cannot separate the vendor from an adversary
                                holding tenant access. Corrected v1.3, which described the
                                2026-08-07 02:30 message as coming from "the recovered mailbox";
                                it came from the COMPROMISED mailbox and is not attributable to
                                the account holder. Recorded that the vendor's customer notice was
                                a private BCC, not a public disclosure, and that no public
                                statement exists on the vendor's newsroom or security page as of
                                this date. Recorded that no message has been confirmed out of
                                band. No finding, indicator or conclusion was changed at the
                                vendor's request, then or now.
v1.3   2026-08-10 09:00 UTC   Vendor response. Added a "Vendor response" subsection to Section 3: the disclosure
                                timeline from 2026-08-07, Sand Studio's customer-facing security
                                notice quoted in full, and the vendor's account of its
                                investigation, containment, recipient notification and upstream
                                notification. Updated the status line, Section 9 and Section 10,
                                and the two paragraphs of Section 3 that stated no substantive
                                vendor response had been received - true at publication,
                                superseded on 2026-08-07. Corrected the elapsed time from our
                                disclosure to that response (18h13m, not 21h17m, which is
                                measured from the send). No observation, indicator or finding in
                                this advisory was changed.
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.