Verdict state recorded . Verdicts change. If you re-check today and see a different result, that is expected and does not contradict this record — cite the timestamp, not the state. Version 1.0. Re-checks are logged in Section 12 with their timestamps, including checks where nothing changed.
Five commercial engines had already classified the URL as phishing or malicious, and a sixth as suspicious. The reputation feed that drives the red warning screen in Chrome, Firefox and Safari had not — 7 hours 49 minutes after distribution, when we checked. This is one URL pair on one day, recorded with timestamps, and it is not a benchmark. What it changes is what a defender should assume.
A conservative verdict here is defensible, and we argue that case at length in Section 4. Stage 1 sat on shared hosting under a legitimate domain nearly eight years old, and it is a page that submits nothing — a genuinely hard classification problem, where a wrong call takes unrelated innocent sites down with it. This advisory is about what a defender should assume, not about anyone's judgement.
Reproducible by any reader. Every observation below rests on public artefacts — a VirusTotal URL report and two urlscan.io captures. Nothing here requires access to our mailbox, our network or our tooling. The permalinks, and the stage-1 URL itself in defanged form, are in Section 8, along with a second instrument — Google's own Safe Browsing status lookup — that you can use to check independently of the one we used. Verdicts change; ours are timestamped so that yours can be compared against them rather than confused with them.
At 14:06:03 UTC on 2026-08-06 a credential-phishing campaign was sent from a compromised third-party vendor mailbox to a BCC'd distribution list. Seven hours and forty-nine minutes later, at , we re-checked the stage-1 URL — the first hop of a two-stage credential-harvesting chain — and the Google Safe Browsing verdict on its VirusTotal report still read clean. Safe Browsing is the reputation feed behind the red interstitial in Chrome, Firefox and Safari.
At that same moment six engines on the same report had already classified the URL: Emsisoft, Fortinet and LevelBlue as phishing; Netcraft and Webroot as malicious; SOCRadar as suspicious. Fifty-four minutes earlier we had submitted both stages to Google Safe Browsing and received "Submission was successful" for each — an interval from which we draw no inference at all; a report is a request, not a command. The page was live and byte-identical to the original at our 20:16 UTC check, and still serving at the 21:21 UTC urlscan capture. While the URL was absent from that blocklist, the blocklist-driven red interstitial had nothing to fire on: a recipient who clicked reached the page.
This advisory records that one observation, with timestamps, against public sources any reader can re-check. It is one URL pair on one day: not a benchmark, not a measurement of anyone's median time-to-coverage, and not a claim that Safe Browsing is failing. It is a reason to stop treating the browser interstitial as a control you can lean on for a URL that is hours or days old.
Read this before quoting any other part of this advisory
What the evidence supports. When we checked, 7 hours 49 minutes after distribution, the live stage-1 URL of a two-stage credential-harvesting chain — a URL that five commercial engines classified as phishing or malicious and a sixth as suspicious — carried a clean Google Safe Browsing verdict, and therefore had nothing for the blocklist-driven interstitial in Chrome, Firefox or Safari to fire on. That is a single, timestamped, publicly verifiable observation, and it is the whole of the claim.
What we measured, precisely — the instrument and the sampling
Our verdict observations are read from the VirusTotal URL report, including its Google Safe Browsing engine row. That row is VirusTotal's integration with the Safe Browsing lookup; it is not a query we issued to Google directly, and we did not load the page in a browser. We state that plainly because it is exactly the kind of detail that matters when a reader reproduces the check with a different instrument — see Section 8, which points you at Google's own status lookup.
On sampling: we hold verdict observations at 20:56:34 (a reanalysis we forced, 6 h 50 min after the send) and at 21:55:04 (a re-check, 7 h 49 min after the send). We do not hold observations at every point in between, so we say "clean when we checked" rather than "clean throughout". Where a figure depends on whether a verdict was freshly computed or rendered from the last analysis, we give both timestamps rather than the more favourable one.
What we are not claiming, and what should not be inferred
And the counterpoint, before you read any further
A conservative verdict here is defensible and we think it is largely correct. Stage 1 sat on shared hosting under a legitimate domain roughly 7.7 years old, and — as Section 4 sets out — it is a page that submits nothing, contains no password field, and hotlinks a genuine Microsoft asset. That is a materially harder classification problem than "a fake login page was left up for eight hours", and getting it wrong at host granularity puts a red screen in front of unrelated, innocent co-hosted sites. We are not arguing that anyone made a bad call. We are arguing about what a defender should assume while the call is being made.
The verdict may change at any time
A reader who opens the VirusTotal report or the Safe Browsing status page tomorrow may see a completely different result — including a Safe Browsing detection. That would not contradict this record. Reputation verdicts are time-varying by design; this advisory documents the state of a specific URL at specific UTC timestamps and makes no assertion about any other moment. If you cite this work, cite the timestamp with it.
All times UTC, 2026-08-06. Infrastructure detail for both stages is in LH-2026-001; this advisory concerns coverage, not the kit.
| Time (UTC) | Event | Evidence source |
|---|---|---|
| 13:15:32 | Stage-1 payload staged on the abused host — about 50 minutes before the send. | HTTP Last-Modified response header |
| 14:06:03 | Campaign sent from a compromised third-party vendor mailbox to a BCC'd distribution list. | Raw .eml |
| 14:11:10 | A VirusTotal URL report already exists, at 1/92. We did not file it — at that point we had not yet examined the link. It appears roughly five minutes after the send. We assess another recipient's mail security detonating the URL as much the most likely origin, given the timing relative to a bulk send; the report carries no submitter identity and we do not claim one. (Wider distribution is separately established: the message was a bulk BCC send, documented in LH-2026-001.) | VirusTotal report timestamp |
| 20:52 | We locate the pre-existing report. | Browser capture |
| 20:56:34 | We force a reanalysis. Score moves to 5/92; the Google Safe Browsing row on the report reads clean. This is the last verdict state we can show was freshly computed rather than rendered from a prior analysis — 6 h 50 min after the send. | VirusTotal report view |
| 21:01 | We report stage 1 to Google Safe Browsing. | "Submission was successful" |
| 21:04 | We report stage 2 to Google Safe Browsing. | "Submission was successful" |
| 21:18 | Stage 1 submitted to urlscan.io as a public scan. Verdict "Potentially Malicious"; brand attribution Microsoft (Consumer) assigned by urlscan independently of us. The single scan followed the redirect into stage 2. | urlscan permalink |
| 21:21 | Stage 2 submitted directly. The capture shows the Cloudflare Turnstile gate now sitting in front of it. | urlscan permalink |
| 21:55:04 | Re-checked: still 5/92. The Google Safe Browsing row still reads CLEAN. Elapsed since the send: 7 h 49 min. Elapsed since our Safe Browsing report: 54 min — an interval from which we draw no inference. Our record does not show a second forced reanalysis at this point, so we treat this as the report as displayed rather than as a freshly computed verdict; the last state we can show was freshly computed is the 20:56:34 row above. | Screenshot vt-evidence-2155utc.png, viewport capture at 21:55:04 (VirusTotal report view, including its Google Safe Browsing engine row) |
Copy this block verbatim if you are quoting the finding; it is the state of the report at that instant and nothing more.
Stage-1 URL — VirusTotal, 2026-08-06 21:55:04 UTC Score: 5 / 92 Emsisoft ................. Phishing Fortinet ................. Phishing LevelBlue ................ Phishing Netcraft ................. Malicious Webroot .................. Malicious SOCRadar ................. Suspicious Google Safe Browsing ..... CLEAN Elapsed since the campaign was sent ....... 7 h 49 min Elapsed since our Safe Browsing report .... 54 min (we draw no inference from this) Last freshly-computed verdict state ....... 20:56:34 UTC (6 h 50 min after the send)
The report's headline score read 5/92 while six engines carried a non-clean verdict, one of them "suspicious". We reproduce both figures exactly as displayed rather than reconciling them or picking the more striking one. We do not know why the score is 5 while six rows are non-clean — the most likely explanation is that "suspicious" is not counted in the score — and we would rather report both than guess.
What instrument this is. Both readings above come from the VirusTotal URL report, including its Google Safe Browsing engine row. That row is VirusTotal's integration with the Safe Browsing lookup, not a query we issued to Google directly, and not an in-browser test. A reader checking Google's own Safe Browsing status page (Section 8) is querying a different endpoint and may see a different answer for reasons that have nothing to do with this advisory. We record the feed verdict; that is what we can show.
Why Safe Browsing specifically matters here. Google Safe Browsing is the reputation feed behind the full-page red interstitial in Chrome, Firefox and Safari. (Apple proxies the lookups for Safari; Chrome's default Standard Protection consults a periodically synced local list rather than the feed live — which adds its own propagation lag in both directions, and which we did not measure.) The other verdicts on that report are real and useful, but they surface inside security products a defender has to own, deploy and be licensed for. Safe Browsing is the layer that reaches the user who has nothing else — the small business, the sole trader, the recipient whose organisation runs no security stack at all.
We should be precise about the boundary of the claim that follows from this. While the URL is absent from that list, the blocklist-driven red interstitial does not fire, and a recipient who clicks reaches the page. That is a claim about the blocklist, which is what we measured. Browsers carry other protective layers we did not test — client-side heuristics, real-time lookups under Chrome's Enhanced Protection, password-reuse warnings on submission — and any of those may behave differently. What we can say is that the layer most defenders picture when they say "the browser will warn them" had nothing to warn with.
We want to state the strongest version of the other side, because we think it is largely correct.
A conservative verdict here is defensible. Stage 1 was not hosted on attacker-registered infrastructure. It sat on a path under a legitimate domain roughly 7.7 years old, on shared hosting, which the actor was abusing. Blocking there is not a free action. Precise blocking is technically available — Safe Browsing list entries can target a specific host-and-path prefix rather than a whole host — so the constraint is not granularity, it is confidence. And a wrong call made at host granularity puts the red interstitial in front of every unrelated, innocent site co-hosted under the same name, whose owners did nothing wrong and have no practical route to appeal quickly.
There is a second constraint, and it cuts against us. Stage 1 is not itself a credential-capture page. It posts nothing, contains no password field, and hotlinks a genuine Microsoft CDN asset — it prompts for an email address, then forwards to stage 2 on a 3.5-second timer. Stage 2, where credentials are actually taken, sits behind Cloudflare with its origin concealed and, when we captured it, a Turnstile challenge in front of it. A classifier evaluating the stage-1 URL in isolation is looking at an aged, legitimate, shared-hosting domain serving a page with no login form on it, whose next hop is actively hostile to automated evaluation. That is a materially harder problem than "a fake Microsoft login page was left up for eight hours", and we would rather state it that way than let the easier version stand.
Any service operating at that scale is making a continuous trade between two error types, and it is making it across hundreds of millions of URLs without a human in the loop. A service that blocks aggressively on aged, shared, abused domains generates collateral damage that is invisible in exactly this kind of writeup — nobody publishes an advisory about the small business whose site went behind a red screen for a day. It is entirely possible that the same conservatism that left this URL clean through the window we measured prevents far more harm than it caused here.
There is also a second latency that has nothing to do with anyone's judgement. Firefox and Safari consume the Safe Browsing update API against a locally cached list, and Chrome's default Standard Protection does the same; even once an entry is added centrally, clients only see it at their next refresh. So there are two clocks running — list-add and client-propagation — and neither of them is instant. We did not measure either.
It is also worth saying that reporting into any of these feeds is a request, not a command, and 54 minutes is a short interval by any reasonable standard for human or model review. We draw no inference at all from the fact that our own submission had not landed. We report because it is the right thing to do, not because we expect same-hour action.
So the useful question is not "why so slow". The useful question is what a defender should therefore assume — and the answer follows directly from the trade-offs above rather than from any criticism of them. If conservative treatment of aged, shared, abused infrastructure is the correct engineering decision, then aged, shared, abused infrastructure is precisely where browser-level protection will be least present at hour one. That is a permanent structural property, not a bug awaiting a fix, and it should be designed around rather than complained about.
A window in which the browser's blocklist layer stays quiet — quiet at both points we sampled it, 6 h 50 min and 7 h 49 min after the send — would matter less if the rest of the defensive stack saw the event clearly. In this campaign, three properties of the kit mean it does not.
Stage 1 appends the victim's email address to the stage-2 URL as a fragment — everything after the #. Fragments are not transmitted in the HTTP request. They never reach the origin server, and they are routinely absent from proxy, secure-web-gateway and mail-security URL-rewriter records, which capture the request line. The practical effect during an investigation is that the field identifying which of your users was targeted is missing from precisely the logs an analyst reaches for first. The stage-1 URL will be in your proxy logs; the identity handed to stage 2 will not be.
There is a second consequence. Passing the address forward would let stage 2 pre-fill the username and select a sign-in clone matching the victim's identity provider before rendering anything — the standard precondition for an adversary-in-the-middle session-token relay. We did not observe that selection happen; see the confidence note below.
The same kit path, /bidaccess/rfp-notification.html, appears on more than one unrelated host. We confirmed a second live deployment serving a hash-verified identical kit, and a third that had already been removed. The earliest public record of that path is 2026-05-05 — three months before the message we received.
We are not naming the additional hosts in this advisory. They are abused third parties, most likely compromised shared-hosting accounts, and their owners are victims of this campaign rather than participants in it. The operationally relevant point stands without the names: the host rotates and the path does not. Host-based indicators from any single sighting age out in days. The path is the durable artefact.
The kit's architecture is consistent with an adversary-in-the-middle relay: the attacker proxies the genuine login, the victim completes the real multi-factor challenge, and the attacker captures the resulting post-authentication session cookie. A stolen session cookie is a valid, already-authenticated credential; presenting it does not trigger another MFA prompt. TOTP codes and push approvals do not defend against this, and a password reset alone does not evict it.
We assess this at moderate confidence and want to be exact about the basis. We read the architecture out of the stage-1 script — the fragment handoff, the campaign identifier carried between stages, the encoding tolerance of a mass-mailer that personalises links — and we observed a Google sign-in clone at stage 2 behind a Microsoft-branded stage 1. That pairing is consistent with the kit selecting a sign-in clone matching the victim's identity provider, but it does not by itself demonstrate it: both candidate domains happen to be Google Workspace tenants, so no case arose that would have discriminated the hypothesis. We did not observe an end-to-end relay, no Lifted Holdings credentials were ever entered against this infrastructure, and our own copy carried no embedded address — we were BCC'd on a bulk send — so we never saw the handoff execute. Nobody should read this section as an observed MFA bypass. It is an architectural assessment, and it is the assumption we would plan an incident response around.
Stack those three properties against a blocklist layer that was still quiet 7 h 49 min after the send and the shape of the problem is clear: during the window where the user gets no red screen, the artefact that identifies the targeted user is missing from server-side logs, the host-based indicator you would pivot on is disposable, and the control most organisations believe is their last line does not cover the outcome that actually matters.
/bidaccess/rfp-notification.html irrespective of hostname. That path has been stable across unrelated hosts since at least 2026-05-05; individual hosts have not been.A secondary finding, recorded because the pattern is more interesting than any of its instances. In the course of this single investigation we hit two published reporting addresses that did not accept mail — and came within one commit of publishing a third of our own that would have done the same.
| Address | Published where | Result |
|---|---|---|
| A third-party domain's own DMARC rua= destination | Published in that domain's DNS as its sole DMARC reporting address | 550 5.1.1 from the authoritative mail host |
| reportphishing@microsoft.com | Widely cited as Microsoft's phishing reporting address | Bounced — Address not found |
| security@liftedholdings.com | Would have been ours — never published | Never existed; caught before publication, so nothing was ever sent to it |
Two notes on that table. We do not name the DMARC domain: this advisory makes no claim about that party, the pattern is the finding rather than the instance, and attaching a defect to a named company here would be gratuitous. And on the Microsoft row — Microsoft plainly does have a working reporting channel. Its current published route for an unsafe site is the WDSI "Report unsafe site" web form, which is live and is where a report should go. The finding concerns the legacy address only. The finding is not that the channel is missing; it is that a widely cited legacy address bounces silently instead of redirecting.
The third row is the point, and it is the reason this section exists. While preparing to publish an advisory that criticises other organisations' reporting paths, we were about to print a security contact address on our own site that had never been created and would have bounced anything sent to it. We caught it before this page shipped. That was not diligence; it was luck plus one more review pass. Had we published it, the first person to responsibly report something to Lifted Holdings would have received a bounce, and we would not have known.
So we are not framing this as carelessness by anybody — the third row is ours. The mechanism is the same in all three cases and it is structural: published reporting endpoints rot silently. A mailbox is decommissioned, a team reorganises, an address is retired in favour of a web form — and the DNS record, the documentation page, the third-party knowledge-base article and the decade of forum posts pointing at the old address all keep pointing at it. No monitoring watches an address for not receiving mail. Nothing alerts. The failure is only ever discovered by the one person who most needed the channel to work, at the moment they needed it, and they usually just give up.
Two concrete consequences worth separating out. First, a DMARC rua= destination that does not accept mail means the domain owner is not receiving the aggregate reports that describe who is sending as their domain — which is, in general, among the more plausible ways an organisation learns that something is wrong with its own sending. That is a reporting-path hygiene gap, verifiable by anyone from public DNS plus an SMTP response; it is unrelated to how any mailbox was compromised, it is not evidence of a compromise and not its cause, and we do not present it as either. Second, a retired public phishing-report address silently discards reports from exactly the people motivated enough to send one. Where a vendor has moved to a web form, that is a perfectly reasonable choice — but the old address needs to bounce with a pointer, or better, keep accepting mail and auto-reply with the new route.
The recommendation is unglamorous and applies to every organisation reading this, ourselves emphatically included: put a scheduled, automated test-send against every reporting address you publish — your security@, your abuse@, the address in your security.txt, and the rua= and ruf= destinations in your DMARC record — and alert on a bounce or on silence. It is an hour of work. The alternative is finding out the way all three of these were found out.
Every artefact behind this advisory is public. Nothing below requires our access, our tooling or our word.
VirusTotal — stage-1 URL report https://www.virustotal.com/gui/url/06daf10f519182b215a33d11c0fd6fd75c8c7940f05157ca9edd6c4bf987504c urlscan.io — stage 1, including the redirect into stage 2 https://urlscan.io/result/019fd8f1-589d-74b9-9443-b0390c5aa8ce/ urlscan.io — stage 2, showing the Cloudflare Turnstile gate https://urlscan.io/result/019fd8f3-870c-76a8-ab27-31fd0f4befab/ Google Safe Browsing — site status lookup (a different instrument to ours) https://transparencyreport.google.com/safe-browsing/search
The URL under test, defanged so that it is not clickable:
hxxps://pulp2pack[.]com/bidaccess/rfp-notification[.]html
Re-fang the scheme and the dots to paste it into a status lookup. Do not visit it in a normal browser. We print it because the observation cannot be reproduced without it and because it is already in the public record via LH-2026-001 and the linked third-party captures. The host is an abused legitimate domain: its owner is a victim of this campaign, not a participant in it, and nothing in this advisory should be read as a criticism of them.
How to check the load-bearing claim. Open the VirusTotal report and read the per-engine verdicts, including the Google Safe Browsing row — that row is the instrument our record is taken from. Then, if you want a second and independent instrument, paste the URL above into Google's own Safe Browsing site-status lookup. Note that our 21:55:04 record is the Safe Browsing row on the VirusTotal report, not this lookup, so the two can disagree for reasons that have nothing to do with this advisory. Compare what you see to the block in Section 3, and note your own timestamp alongside it.
Expect a different answer, and treat that as normal. If Safe Browsing now returns a detection, the correct reading is that coverage arrived at some point after 21:55:04 UTC on 2026-08-06 — not that this record was wrong. If the VirusTotal score has moved, likewise. Reputation data is a time series and this advisory is a single sample from it, taken at a stated instant, for the purpose of describing what a user was and was not protected by during a specific window. We would rather publish a finding that ages visibly than one that cannot be checked.
One safety note for anyone reproducing this: the URLs in the linked reports are live credential-harvesting infrastructure. Read the third-party captures rather than visiting the pages, and if you must visit them, do it from an isolated environment and never enter a credential.
"A clean verdict is not a safety signal. It can mean the list hasn't seen it, or has seen it and is waiting for more signal — from the outside you can't tell which, and you shouldn't guess. We watched a URL that five engines were already calling phishing sit at clean on the list that drives the red screen in Chrome, Firefox and Safari, seven hours and forty-nine minutes after the mail went out. If your security model has a line in it that reads 'and the browser will warn them', that line had nothing behind it at the moment we checked."
Daniel Wilson Kemp — Founder & Chief Executive Officer, Lifted Holdings LLC
"I don't think Google did anything wrong here, and I'd rather say that plainly than let the headline do the work. Blocklisting a seven-year-old shared-hosting domain takes innocent sites down with it, and the page in question submits nothing and has no login form on it — being careful about that is a defensible engineering call, probably the right one. The mistake isn't theirs. The mistake is ours, collectively, for treating a backstop as a control. That file was written to disk fifty-one minutes before the email went out. On a URL that fresh the backstop hasn't arrived yet, and it was never promised to."
Daniel Wilson Kemp — Founder & Chief Executive Officer, Lifted Holdings LLC
"Two published reporting addresses bounced in one investigation, and the third was going to be ours — we caught it one commit before it shipped. That's the finding, and it isn't that anyone is careless. Nobody tests a reporting address until they need it in anger, and by then the person who needed it has already given up and gone away."
Daniel Wilson Kemp — Founder & Chief Executive Officer, Lifted Holdings LLC
Roughly ninety minutes after publishing LH-2026-001 we published a correction against ourselves. Version 1.0 reported per-IP "burn-after-view" cloaking at stage 2, on the basis of reproducible connection resets. A re-check from a second network vantage point showed the host answering normally: the resets were an in-path phishing filter on our own egress, not attacker behaviour. We withdrew the finding, marked it WITHDRAWN in the assessment table rather than quietly editing it out, and replaced it with what the second vantage point actually showed.
We mention it here for one reason. This advisory asks you to accept a measurement we took, about a system we do not operate, on the strength of our care in taking it. The relevant evidence for that is not an assurance; it is what we did the last time our own published finding turned out to be an artefact of our own network. Hence the emphasis throughout on timestamps, on public permalinks, and on Section 2. If this observation turns out to be wrong or incomplete, we would like to hear about it, and this page will say so.
Lifted Holdings LLC is a payments software company based in Tennessee, USA. We build and operate the commerce systems behind our own products, and we publish security advisories on incidents we investigate first-hand — with our evidence, our uncertainty, and our limits attached.
This advisory was researched and written by Daniel Wilson Kemp, Founder & Chief Executive Officer.
Our interest, stated plainly. Lifted Holdings sells payments and retail software — point of sale, payment processing, vending and signage. We do not sell an anti-phishing product, a browser security product, a threat-intelligence feed or a detection engine, and we compete with none of the organisations named or implied in this advisory. There is no product this finding sells. We were a recipient of this campaign; this writeup began as our own incident response, and we publish it because a small company that documents what it found is easier to take seriously the next time it reports something.
| Author | Daniel Wilson Kemp, Founder & Chief Executive Officer, Lifted Holdings LLC |
|---|---|
| will@liftedholdings.com | |
| Telephone | +1-855-678-5142 |
| Location | Tennessee, USA |
| Advisory index | liftedholdings.com/security/advisories/ |
Corrections and challenges are welcome and will be published on this page with a dated note, in the same way LH-2026-001 carries its own. If you can show that any timestamp, verdict or inference here is wrong, please write to the address above — we would rather be corrected in public than be quietly wrong.
Press and research use. This advisory is TLP:CLEAR and may be redistributed without restriction. We ask one thing of anyone quoting it: carry the timestamp and carry Section 2. The observation is one URL pair on one day, and it stops being useful the moment it is presented as a verdict on a vendor.
This advisory documents a verdict that is expected to change. Every re-check is recorded below with its timestamp — including the checks where nothing changed, because a "no change at [time]" line is evidence too. The original text is never rewritten in place; updates are appended.
| Version | Date (UTC) | Change |
|---|---|---|
| 1.0 | 2026-08-06 | Initial publication. Verdict state recorded at : VirusTotal 5/92, Google Safe Browsing row clean. |
Scheduled re-checks: +24 hours, +72 hours and +7 days from publication, on the same URLs with the same instruments. Each will be added as a row here regardless of the result.
Advisory LH-2026-002 · Version 1.0 · Published 2026-08-06 · TLP:CLEAR ·
liftedholdings.com/security/advisories/2026-002-browser-protection-gap
© 2026 Lifted Holdings LLC. All timestamps UTC.