DEV Community: Daniel J

Referer-gated cloaking: why our scanner arrives with a source

Daniel J — Tue, 22 Sep 2026 13:25:04 +0000

A page can serve one thing to a visitor who arrived from an ad and something else to a visitor who arrived from nowhere. Traffic source picks the branch.

A scanner that opens the link cold states no source. It lands in the branch built for everyone the campaign did not pay for.

Cloaked delivery itself is settled ground, and our writeup on a cloaked link that showed scanners a clean page covers the foundation. That post listed a referer gate among the limits of comparing vantage points.

Our scanner can request a URL with a specified referring source and carry it through the redirect chain.

Why a cold scan lands on the clean page

A browser normally tells a site which page sent the visitor. The Referer field is an ordinary part of a web request. Whatever client makes the request supplies the value itself, and nothing authenticates it.

A source-gated page reads that self-reported value and branches on it. A visitor whose stated source matches the campaign reaches the payload. Everyone else reaches a clean page.

No page sent the automated request, so the field arrives empty. To the page's rule, an empty source is the wrong source, so the clean page is the correct output of the operator's own logic.

The verdict is accurate about that one fetch. It says nothing about what the URL serves the intended audience.

The gate works by requirement instead of detection

Fingerprinting a scanner is work. The operator has to model automation tells, and that model needs maintenance as clients change.

A source gate skips all of it. The operator requires something a checker has no reason to send, and every client that fails to send it sorts itself into the harmless branch.

The page never has to recognize a scanner to defeat one. A better client profile or a cleaner egress changes nothing about the value the page is keyed on.

Cold checkers agree with each other by design

Most public checkers fetch cold, and a cold fetch states no source. Pointed at a source-gated page, they receive the clean branch.

Their results then agree. Agreement across tools reads like confirmation while it repeats one observation several times.

That shared habit correlates the answers, so agreement can grow while the evidence behind it does not.

Source gating is delivery discipline

Campaigns buy specific traffic. An operator who pays for clicks from one channel wants the payload spent on that channel's visitors, and serving anyone else is cost with no return.

Every copy handed out is also a copy that can be collected, submitted and written into a signature. The clean branch costs nothing to give away, so the operator hands it to everyone outside the audience it paid for.

The rule lives in the campaign rather than in any one host, so replacing a domain does not require rewriting it.

Reading these gates as budget control explains behavior that looks strange otherwise. A page can ignore your client fingerprint and still serve you nothing, because it is checking where you say you came from.

What survives the redirect chain

A link rarely answers on the first hop. Clicks pass through tracking links, shorteners and intermediate pages before the destination replies.

What the destination sees depends on what survived those hops. A stated source can be carried forward, rewritten or dropped along the way, and the hop that decides what to serve is the last one.

Two checkers can disagree about the same link without either one malfunctioning. One held the context across the chain and the other lost it, so they asked the destination different questions.

Our scanner can specify a source and hold it through those hops. Where that source is the one the gate is keyed on, the destination answers the way it answers the intended visitor.

An analyst sets the source inside the engine, and choosing which source to try is a judgment call.

The verdict comes from the captured artifact

We fetch the URL from datacenter, residential and mobile networks and keep the real response body. Classification reads what that artifact is and what it does.

Counting how many engines have voted on a domain answers a different question. One domain that reputation engines rated clean served a large obfuscated payload when we fetched it, and the capture is what showed it.

Keeping the body is what makes comparison possible. The same URL fetched two ways produces two artifacts, and the pair is the finding.

Client-type cloaking inverts the usual assumption

Client-type cloaking is an evasion class we see and track, and reading it out of a capture is analyst work today.

The familiar cloak feeds real browsers the payload and automated clients a harmless page. Some hosts run it the other way around.

The file goes to an automated application client. An ordinary web browser receives a firewall block page, and a browser-based check reads that block as a dead end.

The block page is part of the delivery. It answers the observer most likely to be a checker, and it answers with something that reads as safety.

Where source control stops

Source control does not tell you which source to try. A gate keyed to a value nobody guessed returns the clean page, and the space of plausible sources is large.

Any client can state any source, which is what makes the gate cheap to build and cheap to stack. An operator who adds a second condition on top of the source check reopens the gap. The gain is that conditional delivery costs the operator more to hide.

Gates a fetch cannot open

Some branches demand what no fetch can produce:

A valid session established by a real login.
A one-time click token that has already been spent.
An authenticated context tied to a specific account.

Source control does not touch that class. A payload served once per address also defeats the confirming second look, which our earlier post covers alongside the limits around session cookies and the time of day.

Divergence starts a human read

Branching on traffic source is common outside abuse. Hotlink protection, anti-scraping rules, paywalls and partner licensing all decide on the same signal, so a split tells you the page branches and stays quiet about why.

That limit was published with the first post on this subject and it holds unchanged on the source axis. A clean result tells you which sources we tried and when. The sources we did not try stay open.

One line of that published list changes. A checker can now arrive with a source stated, and the rest of the list stands as written.

Checking a link against a source gate

Against a source-gated page, a single cold fetch returns the branch the operator built for checkers. Two fetches of one URL that differ only in the source stated is the cheapest test that gate fails.

A link that answers those two fetches two different ways has told you something a verdict cannot. A multi-egress scan at whack.sh records each fetch and the body it returned.

Mapping a whole domain fleet from one reverse IP lookup

Daniel J — Mon, 21 Sep 2026 13:00:02 +0000

One reverse IP lookup on issued.live returned 532 hostnames, effectively all first observed inside the same four-day window. The endpoint answers what else lives at an address: every hostname the resolvers have recorded answering there, each with the date that pairing was first observed. One address goes in, and a list with structure in it comes back.

Addresses and hostnames below are placeholders. The calls are real, and they run against the Pro API reference.

The inverse lookup is one request

Passive DNS tooling answers what a domain resolves to. The inverse question turns a single observation into a set, which is what moves a thread forward.

curl -sS "https://issued.live/api/v1/ip/198.51.100.24?limit=500" \
  -H "Authorization: Bearer $ISSUED_LIVE_KEY"

The key travels in the header. There is no ?key= parameter, because query strings land in access logs, proxy logs and Referer headers. A key in the URL therefore leaves the request unauthenticated and answers 401.

Each row in hosts[] carries hostname, domain for the registrable domain, ip, first_seen, last_seen and observed. The envelope carries query, addresses, count, truncated, limit, order, and next_cursor when another page exists.

Read truncated first. A limit returns up to that many rows and promises nothing about completeness. A true there means the picture in front of you is partial.

Enumerating an address completely is a cursor walk

limit defaults to 500 and tops out at 50000. Out-of-range values are clamped rather than refused, so a request for a million quietly returns 50000. Busy hosting addresses hold far more names than that.

Past the cap, the cursor is the only correct route. Send ?after= with an empty value to begin, then pass back each response's next_cursor until one arrives without it.

curl -sS "https://issued.live/api/v1/ip/198.51.100.24?after=&limit=50000" \
  -H "Authorization: Bearer $ISSUED_LIVE_KEY" > page1.ndjson

The ordering changes when the cursor appears. Without after the page sorts by last_seen descending and cannot be resumed, since a re-observed name moves between pages. With after present the sort is the table's primary key, which never changes for a given observation.

Four parameter names people reach for answer 400: page, offset, skip and cursor. All four were once accepted and ignored, which returned page one with a 200 however many times you asked for page four. Code written against that behavior read the same page in a loop.

At a limit of 5000 or above the answer streams as newline-delimited JSON, one object per line. Records always carry hostname and the trailer carries end, so the two are unambiguous. A stream that dies mid-flight has no trailer and no cursor, and that absence is the error signal.

first_seen dates the association between a name and an address

first_seen is the earliest time the resolvers saw that hostname answer with that address. It records when the name arrived at its current host. When the name was created is a separate fact, and RDAP is where that one lives.

Take a domain registered years ago whose first_seen at its current address is three weeks old. That is an aged name that moved recently. It behaves like a new one while carrying the reputation of an old one.

The gap between the two dates is a reading, and it stays a reading. Treat a change of hands as an interpretation, and never assert who holds a name.

The same field takes a server-side window, on either bound alone:

curl -sS "https://issued.live/api/v1/ip/198.51.100.24?first_seen_from=2026-09-01&first_seen_to=2026-09-05&limit=5000" \
  -H "Authorization: Bearer $ISSUED_LIVE_KEY"

RFC3339, YYYY-MM-DD HH:MM:SS, YYYY-MM-DD and unix seconds all parse, and a missing zone means UTC. A malformed or reversed window answers 400.

Copy the published reasoning into your own API: "A limit is a preference, so we clamp it and answer the question you meant. A timestamp asserts which rows you want, and substituting a different window is how you end up with a gap you cannot see."

These observations begin in August 2026. A window earlier than that comes back empty because nobody was looking yet. Check the window before concluding an address sat unused.

The hostname list has a grammar

Co-location on shared hosting proves little by itself. The timing carried the weight in that case: names that arrive together were deployed together.

The shape of the names is the second measurement. Three greps classified most of that list in a few seconds.

jq -r 'select(.hostname) | .hostname' page1.ndjson | sort -u > names.txt

grep -cE '(clk|clks|trk|trks|track)' names.txt
grep -cE '[a-z]+[0-9]{2,}\.' names.txt
grep -cE '(scrty|sec-|-secure|verify)' names.txt

Of the 532, the click and redirect abbreviations came to 163, the leetspeak variants to 15 and the security-themed lures to 37. A fourth pass over insurance and quote wording caught 27 more. One query enumerated a disposable redirect fleet, and a grep fingerprinted how it names itself.

A grammar returns a candidate set rather than a finding. Cheap names bought in bulk look alike because one script generated them, and unrelated operators land on the same conventions.

What lifts a candidate above coincidence is a second independent link. Co-tenancy on one certificate, a shared public key, an account-specific nameserver pair or a registration inside the same hour each qualify.

Pattern search reaches the members on other hosts

An address holds the members parked there on the day you looked. The rest of the family sits elsewhere, and the grammar is what reaches them.

Pattern search matches a naming hypothesis against the corpus, next to the data. That is the only place it can run, because there is no wordlist and the space is combinatorial.

curl -sS -g \
  "https://issued.live/api/v1/search?name=[a-z]{3,8}clk.com&ns=ns.example-dns.net&limit=500" \
  -H "Authorization: Bearer $ISSUED_LIVE_KEY"

The -g earns its place. Braces and brackets are curl's own globbing syntax, so without --globoff the pattern never reaches the API intact.

Patterns are written forwards, the way you say the name, with * for a run of characters, ? for exactly one, and a counted class such as [a-z]{3,8}. The count is required and bounded, with a ceiling of 64. An open class like [a-z]+ is refused, because an open bound is how a pattern silently becomes a full scan.

Every pattern must name a TLD, so *agent alone is refused and *agent.* means every TLD. Names are stored suffix-first, so pinning one turns the pattern into a key range. The reference measures anchored searches at 0.03 to 0.7 seconds, against 1 to 3.5 seconds for one that reads the whole key space.

The response reports anchored and key_prefix, so you can see which case you landed in.

Window mode reads the registration feed by date

Sending a time bound switches the search into window mode, which reads the registration feed by date. That is the right mode for "which names matching this grammar appeared last week". The reference measures that query at 0.094 seconds.

Cursors carry no meaning between the two modes, and the wrong one answers 400 instead of silently restarting the walk.

Every hit carries ns and cert_id, and the ns filter above is what keeps a grammar from collecting coincidences.

Batch lookup tests 500 candidates in one call

A search plus a key pivot produces a few hundred names. Looking them up one at a time is a few hundred requests against a concurrency gate. Batch lookup takes up to 500 in a single POST.

curl -sS "https://issued.live/api/v1/domains?include=timing" \
  -H "Authorization: Bearer $ISSUED_LIVE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domains":["name-one.example","name-two.example"]}'

Every input gets a row back in the order you sent it, duplicates included. The reply zips against your list without normalizing anything. Rows come back found, not_found, or rejected where the input never parsed as a registrable domain.

Those last two stay separate on purpose. A batch that dropped unparseable input would let you record a domain as absent when it was never queried.

Any include value drops the per-request cap to 100 names, each carrying up to 10 sub-entries. Sending more names than the cap truncates to it and sets truncated.

Pivot on the certificate, then on the key

A domain record publishes ssl_cert, the 32-hex cert_id, and that value is the bridge into the certificate endpoints.

curl -sS "https://issued.live/api/v1/cert/$CERT_ID" \
  -H "Authorization: Bearer $ISSUED_LIVE_KEY"

curl -sS "https://issued.live/api/v1/spki/$SPKI_SHA256?limit=500" \
  -H "Authorization: Bearer $ISSUED_LIVE_KEY"

The sans array lists the names a certificate covers, which is a link that survives a reverse proxy. spki_sha256 is a hash over the SubjectPublicKeyInfo, so two certificates carrying the same value were issued for one key pair. Often that is a renewal, and sometimes it is one operator across names that share nothing else.

Link	Strength	Why
Shared address	Weak alone	A CDN address fronts unrelated tenants at scale, so co-location proves shared hosting.
Shared nameservers	Moderate	Strong when the pair is account-specific, weak when it is a large provider's default.
Shared certificate	Strong	Names packed onto one certificate were issued together, by one party, for one deployment.
Shared key	Strongest	One key pair across certificates means one holder of one private key.

Read the coverage field on every key pivot before drawing a conclusion. Key hashes were first recorded on September 7, 2026, and certificates ingested earlier cannot be matched on one. A thin result from an older pivot therefore reads as unknown.

Certificate detail stays queryable for 14 days and then lives on in the archived daily files. A 404 for an older id reports that horizon and says nothing about whether the certificate existed.

ja4x fingerprints the issuance software a certificate authority runs. issued.live reports the value and offers no pivot on it. The value space is small enough that a match would return a large share of one CA's output.

Where the range sweep is the wrong instrument

Reverse IP has a sibling that takes a CIDR. Write the prefix slash as a hyphen, since a literal slash is a path separator and will not route.

curl -sS "https://issued.live/api/v1/range/198.51.100.0-24" \
  -H "Authorization: Bearer $ISSUED_LIVE_KEY"

A range covers at most 256 addresses, an IPv4 /24, and anything wider answers 400. On shared cloud space the surrounding /24 belongs to unrelated tenants. A sweep there returns hundreds of neighbors with nothing to do with your thread.

On dedicated hosting that trade-off inverts, and the /24 becomes the fastest way to see a whole rented block. Sweeping anything larger means iterating a /24 at a time.

Concurrency is the limit that bites

The per-minute ceiling rarely stops this work. Advanced queries are bounded by how many run at once on one key: one on Plus, two on Pro.

Reverse IP, range, pattern search, batch lookup and the provisioning feed each take a slot. Certificate, key, domain and timeline lookups take none.

Over the gate a request waits up to five seconds for a slot, then returns 503 timeout. It never queues, so a pile-up of slow queries cannot form. Branch on the retryable field and Retry-After rather than on the status number.

The timeout status stays 503 by design. This origin sits behind a CDN that replaces a 504 with its own error page, stripped of the JSON body.

Serialize a multi-block walk. The gate admits two at a time on Pro anyway, and concurrent cold range queries make each other slower.

The feeds keep the map current

A fleet enumerated on Tuesday is a snapshot. Two cursor-paged feeds turn a finished investigation into a standing one.

curl -sS "https://issued.live/api/v1/provisioning?max_hours_to_cert=6&ns=ns.example-dns.net" \
  -H "Authorization: Bearer $ISSUED_LIVE_KEY"

curl -sS "https://issued.live/api/v1/nrd?certified=1&max_hours_to_cert=1&limit=500" \
  -H "Authorization: Bearer $ISSUED_LIVE_KEY"

The provisioning feed returns domains registered, certificated and pointed at a host inside one window. Any one of those facts is ordinary. All three inside an afternoon is a domain being stood up to be used.

The hours-to-certificate bound is what keeps that query affordable. On the reference's own measurements, widening it from one hour to six multiplies the candidates in a 72-hour window by roughly 19. Widening it again to 24 hours multiplies them by another 10.

Recent windows are thin by construction, and the response says so. Published coverage figures: 36.9% of candidates carry a DNS observation inside 24 hours, 83.9% inside 72 hours and 96.1% inside a week.

Rows without one are marked not_yet_observed, which records an observation nobody has made yet. It says nothing about whether the name resolves.

The newly registered domains feed runs in ascending time order from a cursor. A consumer resumes exactly where it stopped, so a scheduled job can miss a run without losing an event. Store next_cursor on every page, including the ones where caught_up comes back true.

Sub-hour certification runs at about 1.1% of certified registrations, against 8.4% taking over a week. The tight end of that filter is a small set. max_hours_to_cert requires certified=1, and sending it alone answers 400 instead of quietly doing nothing.

What the plans cover

issued.live opened paid plans on September 19, 2026, three of them. Pattern search, batch lookup and both feeds belong to Pro at $199 a month. Pro also carries 1,200 requests a minute, two advanced queries in flight, and daily files for DNS by vantage point, certificates and address history.

The earlier steps sit lower. Reverse IP, the CIDR sweep, the pivots and the domain timeline by API run on Plus at $99 a month, with one query in flight. Basic at $39 takes the daily domain and DNS files plus the extended record and the domain timeline on the website.

Unkeyed access stays free at 1,000 requests a day per address. Billing is monthly through PayPal, and sign-in is a code sent to your email. Full plan and limit detail sits on the pricing page.

Methodology

Every endpoint, parameter, cap and error code above was checked on September 18, 2026 against the issued.live Pro API reference, last updated September 15, 2026. Plan boundaries come from the pricing page on the same date, and the performance and coverage percentages are that site's published measurements. The 532-hostname classification comes from Tuxxin investigation work, and Daniel Jones reviewed the post before publication.

issued.live paid plans are open: Basic $39, Plus $99, Pro $199

Daniel J — Sat, 19 Sep 2026 13:00:02 +0000

Paid plans are open on issued.live today: Basic at $39 a month, Plus at $99 and Pro at $199. Basic reads the extended record on the website and takes the daily files. Plus opens the keyed lookups, and Pro adds the sweeps that run across the corpus.

issued.live reads the public Certificate Transparency logs, resolves DNS from seven vantage points and loads ICANN zone files. It observes third-party infrastructure and operates none of it.

Free covers the public record for any domain with no account and no key: certificate, issuer, expiry, hosting address and current DNS. The cap is 1,000 requests a day per client address, resetting at 00:00 UTC.

Two boundaries separate the three paid plans. One runs between the website and the API. The other is how many heavy queries you may hold open at once.

Website access against API access

Basic, at $39 a month

Basic runs at 60 requests a minute with no daily cap, and carries the domains and dns daily files in csv.zst and json.zst. Every dataset has a sample row on the download catalog.

Basic also opens the extended record on the website for any domain you look up. That is certificate internals, DNS per vantage point and the full address history on the page, plus registration and expiry dates and the registrar. The domain timeline sits there too, every dated event in order.

Its keyed surface ends there. The advanced queries start at Plus.

Plus, at $99 a month

Plus runs at 300 requests a minute and moves those same answers onto your key. It suits a hunter working one lead at a time: an address, a certificate, a name.

Reverse IP and CIDR return every hostname our resolvers have recorded answering at an address or a range. Each row carries first_seen, last_seen and an observed count.

Pivots by certificate, SPKI or JA4X return the other names on a certificate and everything sharing a public key. The extended record and the domain timeline come by API as well, the timeline carrying gap_seconds on each event.

Plus takes the same two daily files as Basic, and runs one advanced query at a time.

Concurrency: how many sweeps run at once

Pro, at $199 a month

Pro runs at 1,200 requests a minute and adds the sweeps. Pattern search runs a name grammar across the corpus, and batch lookup answers up to 500 domains in one call. The provisioning feed and the newly registered domains feed are both cursor-paged.

Pro also takes the dns_vantage, certificates and address_history datasets as daily files, and runs two advanced queries at once.

What takes a concurrency slot

Advanced queries are bounded by how many run at once on your key: one on Plus, two on Pro. The per-minute ceiling meters the public record API instead.

Five endpoints take a slot: reverse IP, range, pattern search, batch lookup and the provisioning feed. The certificate, key, domain and newly-registered-domain endpoints are point lookups and take none. The slot is yours alone.

Why the gate sits there

The cost of a range query is the reason. A cold reverse-IP range can read hundreds of millions of rows and hold its database connection for the better part of 18 seconds. Enough of those at once would exhaust the connection pool and stall every other request on the site.

A request over the gate waits five seconds for a slot and then returns 503 timeout rather than queueing. An unbounded queue would turn one slow query into a pile-up, with every request holding a connection until they all expire together.

A range covers at most 256 addresses, an IPv4 /24, for the same reason. A CIDR expands into its individual addresses, so the address count is the query's cost.

The four plans side by side

Capability	Free	Basic	Plus	Pro
Price a month	$0	$39	$99	$199
Rate	1,000 a day per address	60 a minute	300 a minute	1,200 a minute
Public record for one domain	Yes	Yes	Yes	Yes
Extended record and timeline on the website	No	Yes	Yes	Yes
Extended record and timeline by API	No	No	Yes	Yes
Reverse IP, CIDR and the key pivots	No	No	Yes	Yes
Pattern search, batch lookup and the feeds	No	No	No	Yes
Daily files	None	domains, dns	domains, dns	all five datasets
Full weekly snapshot	No	Its datasets	Its datasets	All five
Advanced queries in flight	None	None	One	Two
Published SHA-256 checksums	Yes	Yes	Yes	Yes
Ad-free pages, sign-in and billing	No	Yes	Yes	Yes

Every paid plan includes a full weekly snapshot of the datasets it covers, for seeding a new system before the daily deltas take over. The checksums stay unkeyed on every plan, Free included, so a file you already hold can be verified without an account.

What a keyed call looks like

Authentication is a bearer token in an Authorization header. There is no key parameter on the query string, because query strings land in access logs, proxy logs and browser history.

curl -sS "https://issued.live/api/v1/range/157.240.17.0-24?limit=5000&after=" \
  -H "Authorization: Bearer YOUR_KEY"

Write the CIDR prefix slash as a hyphen. A literal slash is a path separator and will not route.

Reading the response

The limit parameter defaults to 500 and tops out at 50000, and an out-of-range value is clamped. truncated:true is what tells you rows remain.

Pagination is the after cursor. Send ?after= empty to begin, then pass back each response's next_cursor, whose absence ends the walk. page, offset, skip and cursor each answer 400, after a spell when all four were accepted and ignored.

Each hosts[] row carries the hostname, its registrable domain, the address, first_seen, last_seen and observed. Set format=ndjson to stream one object per line, which also happens automatically at a limit of 5000 or more.

Bounding the window server-side

first_seen_from and first_seen_to filter on first-observation time at the server, and either bound may be sent alone. They take RFC3339, "YYYY-MM-DD HH:MM:SS", "YYYY-MM-DD" or unix seconds, and no zone means UTC. A malformed or reversed window answers 400.

The reasoning for treating those two parameters differently is published in the Pro API reference: "A limit is a preference, so we clamp it and answer the question you meant. A timestamp asserts which rows you want, and substituting a different window is how you end up with a gap you cannot see."

Why the other limits sit where they do

The free daily cap is sized for an interactive visitor or a small script. It stops one scraper monopolizing a backend everyone shares.

The per-minute ceilings smooth bursts, and they point at the files. Paging an API for the whole corpus is slower for you and more expensive for us than one download.

File downloads run one per file per day, shared between the download page and your key, and that allowance resets at 00:00 UTC. Each file is generated once a day, and re-downloading the same one is the main way bulk access gets expensive.

If a limit blocks legitimate work, tell us. These are sized to protect the service, and we would rather adjust one than lose the use case.

Who should stay on Free

Anyone reading a handful of domains a day from a shell is served by Free. The daily cap covers an interactive visitor and most small scripts, and there is no key to manage.

Anyone asking what a certificate looked like in 2019 should use crt.sh, which answers that for nothing. Our queryable certificate window is 14 days.

Registrant contact details and long whois histories sit elsewhere too, and we collect neither. The comparison page weighs this service against AllZonefiles.io, Domains-Monitor, WhoisXML API and crt.sh, and says where each of them wins.

How long each dataset is kept

Certificate detail is queryable for 14 days and then ages out of the database. The daily certificates file that recorded it is archived permanently, and that archive starts with the files for September 17, 2026.

The 14-day window is a decision about interaction. It covers the moment a hunter first finds a name and wants SANs, SPKI, JA4X and the hashes on screen. A month-old certificate is archival research, and a file serves that better.

The window is short because of what certificates cost to store. Three 32-byte hashes come to 42% of that table at roughly 10 GiB each, and hashes resist compression, so the bill grows in a straight line with the window. A 13-month hot window was costed at about 3.6 TB and declined.

DNS change history runs 18 months, because age and value move in opposite directions in a change log. Registration data, address history and the reverse-IP index have no expiry. The about page carries the full retention table.

Billing and sign-in

Billing is monthly through PayPal. There is no password: you sign in with a code sent to your email, then manage your key and billing from the same page.

Cancel any time in PayPal and the billing page follows within minutes. Access runs to the end of the period you have paid for. The feature matrix and the subscribe buttons are on pricing.

Daniel Jones checked every price, rate, limit and capability above against issued.live's own pricing, about, compare and downloads pages on September 18, 2026. The API mechanics come from the Pro API reference, last updated September 15, 2026, and he reviewed the post before publication. More about the author.

Brevo delivered KongTuke ClickFix to 51 customer sites

Daniel J — Thu, 17 Sep 2026 12:12:30 +0000

Brevo's own delivery infrastructure served malicious JavaScript to 51 customer page domains on September 14, 2026. The injected code drew a fake Cloudflare verification panel and walked visitors through a ClickFix sequence ending in a command shell. The window ran from 16:05 to 20:12 UTC, and by the following day every loader hostname it used had stopped resolving.

Kirk of ADAMnetworks published the technical analysis. Whack.sh took part in the shared investigation.

How the attack works

Two files Brevo serves to its customers carried appended code. The SDK loader at cdn.brevo[.]com/js/sdk-loader.js went from a clean 3,442 bytes to 3,615 or 3,616. The Sibforms bundle at sibforms[.]com/forms/end-form/build/main.js went from a clean 461,411 bytes to 461,584 or 461,585. The one-byte spread is the loader hostname: a page served by cdn11 carries a longer label than one served by cdn2. If you are checking a capture against these numbers, both values are modified.

The appended code is a script tag pointing at a loader host under sendibt1[.]com. That domain is the reason this reached so far: Brevo lists it among its own technical domains, so it is a name a customer following Brevo's own integration guidance would already have allowed. This was delivery through a vendor's genuine infrastructure, and a site owner reviewing their network log would have seen nothing out of place.

The panel the code drew imitated a Cloudflare verification step. It instructed visitors to press Win+R, then Ctrl+V, then Enter. The clipboard carried a command built around conhost.exe --headless and curl, piped into cmd.exe.

What the command retrieved is unknown. Every captured request to the four download servers returned an empty HTTP 444, and a Joe Sandbox run that executed the command on Windows 10 at 18:34:33 recorded the same thing. The tokens are single use: the servers answered the victim and nobody else. Anyone who completed the paste got a payload, and it was not captured.

The panel was served in an iframe requesting fullscreen and clipboard-write permissions, and carried a proof-of-work challenge before it would render. It reported telemetry events named vclick and copy_fail, so the operators were measuring how many visitors completed the paste and how many gave up.

Built ahead of time, and torn down fast

The certificate record dates the buildout well before the attack. Kirk's analysis records a certificate for cdn.sendibt1[.]com issued on August 25, twenty days ahead, and a wildcard for *.sendibt1[.]com on September 8. Certificates for cdn9, cdn10 and cdn11 were issued on September 14 between 16:09 and 16:12 UTC, four minutes after the window opened: capacity added while the campaign was already running.

Seven loader hosts served the campaign. By September 15 all seven returned NXDOMAIN. The whole operation lasted about four hours.

A separate thread in the same research connects the operator to MintsLoader, and it is worth being precise about the distance. The four download servers share a naming scheme with hosts that a MintsLoader sample from September 9 queried. That earlier sample reached a staging host, jg2n36pxkqjfqp7[.]top, and DNS and hosting records tie that host to 97 domains across three addresses on BL Networks' AS399629, all using 15-character lowercase labels under .top. That estate hangs off the September 9 staging host, not off the sendibt1 loaders: it is the same operator by inference, on different infrastructure.

How to stay safe

Treat any instruction to copy a command and paste it into the Run box, PowerShell, or Terminal as the attack itself. A verification step that asks you to run something is a lure. Cloudflare's real challenge never asks you to paste a command.

Close the tab. Nothing is repaired by completing the step.
If you already ran it, treat the machine as compromised and change passwords from a different device.

For teams running a site that loads third-party JavaScript:

Subresource Integrity on vendor scripts turns a modified file into a blocked file. It is the direct control for this attack, and it costs an attribute. A Content-Security-Policy would not have helped here: the malicious host was a domain the vendor documents, so a correctly written policy already trusted it.
Compare your vendor bundles against known-clean byte counts. Both modified sizes above differ from clean by fewer than 200 bytes in a 461 KB file.
Watch endpoints for a shell spawned shortly after browser activity, and specifically for conhost.exe --headless.
Certificate transparency carried the first record of this infrastructure, three weeks early. Watching CT for new names under your vendors' domains is cheap, though be honest about what it buys: a new cdn subdomain on a domain the vendor already documents is routine, so August 25 would have been a row in a log rather than an alarm. Its value here is retrospective, which is how the timeline above was built.

Credit and sources

The research and the writeup are Kirk's, at ADAMnetworks, published September 16, 2026. The report thanks Daniel Jones of Tuxxin LLC, who took part using Whack.sh, and Emiliano of The Matrix Project, for their work on the infrastructure records.

ADAMnetworks report: Brevo delivers KongTuke ClickFix to customer sites
Earlier collaboration: PasteSwitch, 108 crypto-theft ads on a hijacked HBO Max Reddit account

PasteSwitch: 108 crypto-theft ads on a hijacked HBO Max Reddit account

Daniel J — Mon, 14 Sep 2026 17:55:05 +0000

Attackers hijacked the official verified HBO Max account on Reddit, u/hbomax, and used it to run 108 distinct malicious advertisements over roughly 48 hours. The ads promoted an "HBO Max for macOS" application that does not exist. Reddit administrators paused the affected ads and opened an internal investigation with their Security and Safety teams to secure the account.

One of the 108 advertisements run from the hijacked account. Screenshot via Hudson Rock.

Hudson Rock published the technical analysis, conducted jointly with Kirk of ADAMnetworks. Whack.sh took part in the shared investigation.

How the attack works

The campaign uses a technique called ClickFix. The lure page presents an installation or verification step and gives the visitor a command to copy. The visitor pastes that command into Terminal, PowerShell, or the Run box and presses enter. The command downloads and runs the payload under the visitor's own account, so the operating-system and browser warnings that gate a downloaded file never appear.

Hudson Rock and ADAMnetworks named the operation PasteSwitch after the two halves of that mechanism. The victim pastes an attacker-supplied command, and the delivery system switches among platform, campaign, payload, and monetization branches based on checks that qualify the visitor.

Three delivery branches

macOS received Swift-based counterfeit Ledger, Trezor Suite, and Exodus applications, built to harvest 12- and 24-word BIP39 recovery phrases.
Windows received a separate payload path using mshta and PowerShell.
Clipboard hijacking arrived as AnimateClipper and ZigClipper, which replace a copied cryptocurrency address with an address the attacker controls.

The clippers read their command-and-control location from Binance Smart Chain contracts used as mutable dead drops. Researchers recorded 36 mainnet changes from a single controller address between March and July 2026. Hosting the pointer on a public blockchain gives the operator a channel that survives ordinary takedowns, because the contract stays reachable and the destination can be rewritten at will.

How to stay safe

Treat any instruction to copy a command and paste it into Terminal, PowerShell, or the Run box as the attack itself. A real installer is a file you download from the vendor's own site or an official app store.

Type a vendor's address yourself rather than following an advertisement.
Enter a hardware-wallet recovery phrase only into the device. An application that asks for your 12 or 24 words is stealing them.
A verified badge carries no guarantee. This account belonged to the brand and was under attacker control for the duration of the campaign.

For teams:

Name the copy-paste-into-terminal pattern directly in security awareness material. Guidance written around email attachments leaves it uncovered.
Watch endpoints for a shell spawned shortly after browser activity, and for processes that write to the clipboard.

Credit and sources

Hudson Rock conducted this research jointly with Kirk of ADAMnetworks. Hudson Rock's report also thanks Daniel Jones of Tuxxin LLC, who took part using Whack.sh, and Emiliano of The Matrix Project.

Hudson Rock report: HBO Max ads on a compromised Reddit account exposed a massive PasteSwitch ClickFix operation
Companion report from ADAMnetworks: HBO Max ads exposed the PasteSwitch ClickFix operation

Both reports carry the complete indicator list.

Whack.sh opens a suspicious URL and reports what it serves, including cloaked multi-stage delivery like this one. Run a scan.

The malware that shows scanners a clean page

Daniel J — Fri, 11 Sep 2026 01:07:59 +0000

A cloaked link serves a clean page to scanners and malware to real visitors. Every reputation engine that checked one recent case rated it safe for months, because each engine looked from a single datacenter IP. Seeing the real behavior takes loading the same URL from several vantage points at once.

By Daniel Jones, Founder, Tuxxin LLC.

Most link checks ask one question from one place, then report what came back.

That worked when a bad link was bad for everyone. It stopped working when attackers started deciding what to show based on who appears to be asking.

I ran into a textbook case earlier in 2026. A fully authenticated Carnival Cruise Line email, booking number and all, routed real customers into malware installers and fullscreen lockers. The scanners that guard inboxes and browsers saw nothing wrong.

The investigation, the payloads and the takedown are written up in full on the research site: A real Carnival Cruise Line email was serving customers malware.

This piece covers the detection problem underneath it.

What the cloak does

The malicious landing page fingerprints the visitor and makes a per-visit decision.

Scanners, command-line tools and headless browsers fail the check and receive a harmless skeleton. Real browsers on real networks get routed to the live payload.

One link, one cloaker, four outcomes. The datacenter branch on the left is the only page any scanner reached.

The gate is cheap to run and it is templated. urlscan.io flagged the page as one of "10,000+ similar pages."

The reputation services I checked returned clean verdicts, consistent with those services having received the skeleton rather than the payload. The link then inherited full brand trust, arriving through the sender's real click-tracker from a domain that passed every email authentication check.

The sorting gate itself. A visitor who clears it and a scanner that fails it leave with different pages. Screenshot captured June 13th, 2026.

This machinery already has a name

Trinity Cyber documented the redirection layer and the payload family in November 2025, in Blurred Lines: AdTech Abuse Delivers Browser Hijackers Through the Microsoft Store. Tanner Piliego and Jared Grumbein named the redirection layer PseudoTDS and the browser-hijacker family PhantomJack.

Their victims arrived by mistyping a domain. Ours arrived through an authenticated marketing email, which is a different door into the same building.

Both names in this piece are theirs. The reason it is worth revisiting is that the machinery is still running.

A clean verdict describes one observation

A scan result is a record of what one client saw at one moment from one network. Treating it as a property of the URL is where the reasoning breaks.

That distinction stays invisible while most bad links behave the same way for everyone. It becomes the whole problem once the page starts choosing.

Under a cloak, "clean" is a true statement about the observation and a false statement about the URL. Both halves are worth holding at once, because it means a defender who checked in good faith and found nothing was reading an accurate result.

The same applies to a verdict that ages. These pages rotate what they serve between visits, so a result from last week describes a page that no longer exists.

What the scanner missed

A visitor who cleared the fingerprint check landed somewhere quite different. The Windows branch served PhantomJack as forced installers of about 148 MB, signed with three-day certificates that had already expired.

One of the payloads behind the clean page. Screenshot captured June 25th, 2026.

Automated checks rated that domain safe throughout. The divergence between the two results is the entire finding.

Two of the packages went further. They shipped a forced auto-update channel that checks on every launch, runs in the background, and accepts any version the operator offers. The manifest is quoted in full in the research writeup.

Why one vantage point cannot catch it

A cloak only has to satisfy the observer it can see.

If your check comes from a single datacenter IP running a headless browser, that is the exact profile the cloak is tuned to feed a clean page. You are the input it was built for.

The tell appears when you load the same URL from several profiles at once and compare. Datacenter, residential and mobile.

In this case the split was stark. Blank and benign from the scanner, a forced malware download from the phone. That disagreement is the signal, and no single vantage point produces it.

The page fights the analyst too

Cloaking sorts the traffic. A second layer works on whoever gets through and starts looking closely.

Opening developer tools froze the page on a debugger trap assembled at runtime, with no literal debugger token in the source for a scanner to match on. The same layer watches for console evaluation and injected extensions, and reports back to the operator.

The anti-analysis layer firing on inspection. Screenshot from Firefox developer tools, June 24th, 2026.

Both layers point the same direction. Automated collection captures the skeleton, and manual analysis is slowed down enough to make the sample expensive to pin down before it rotates.

Why an emailed link is the harder case

The prior reporting on this machinery describes victims who mistyped a domain. That victim has one thing going for them: they know they made a mistake, and the page they land on is unfamiliar.

An authenticated brand email removes every one of those cues. The sender is real, the message is expected, the booking number is correct, and the link opens from a domain the recipient has trusted for years.

That inverts where the detection burden sits. A typosquat has a suspicious human in the loop who might close the tab. Authenticated brand mail hands the whole job to whatever automated check runs before the click.

The check in this case was the one thing the cloak was built to defeat. Both halves of the pipeline were working correctly and the outcome was still malware, because each half was answering a question the other one assumed had been covered.

Email authentication proves the sender. It says nothing about where the links inside go, and a link is only as trustworthy as whoever currently owns the domain at the other end of it.

The blocklist is chasing the wrong layer

I rescanned the chain on September 10th, 2026. The hosts named in the 2025 reporting have moved on, and the build behind the Carnival link has not.

Of 12 redirect-hop domains I checked, 11 came back as dead parked pages: six lowercase letters plus .com, bulk-registered, first seen the same month, all sitting on one parking IP.

Blocking that layer buys little when a replacement costs a registration fee. The command-and-control naming carried across both reporting sets on rotated apexes, which is consistent with one operation continuing while its address list turned over.

Most of that layer is still unmapped, and I am staying on it. What survived rotation was the delivery kit itself. The request paths, the event names and a fixed parameter prefix stayed identical across unrelated brand domains, which makes that grammar the more durable thing to detect on.

Domain reputation answers where a request went. Behavior answers what it did. Only the second one survives the operator buying new domains.

This report covers what the requests did and how the chain responded to abuse reports. The commercial terms behind it are outside what I can observe, so nothing here characterizes intent.

What multi-vantage checking does not solve

Comparing several vantage points catches a page that discriminates by network or device. Naming the limits matters as much as claiming the win.

A page that gates on a session cookie, a referrer, a one-time click token or the time of day can still show every one of your profiles the same thing. Plenty of these chains do exactly that, which is why the tokenized links in the Carnival case expired into an error page rather than replaying.

Single-serving behavior defeats a retry in the same way. Where a chain burns the payload once per address, the confirming second look comes back clean and the first result starts to read like a fluke.

It also proves divergence rather than intent. A page serving different content by geography may be a cloak or may be a licensing rule.

The result is a signal that needs a human read. It narrows the field from every link to the handful behaving inconsistently, and that is the useful part.

What to do about it

Treat a scan verdict as evidence with a timestamp and an observer attached, rather than a durable property of a URL.

Check from more than one egress when the answer matters, and compare the results instead of accepting the first one. A single agreement across profiles is worth more than any individual verdict.

Detect on behavior that survives rotation: request-path grammar, event names, parameter shapes and download prompts. Domain lists go stale by design.

Recheck anything reached from mail you did not send yourself. The FBI's IC3 published PSA I-061826-PSA on June 18th, 2026, on criminals routing victims through traffic distribution systems to malicious sites, and this threat class remains invisible to a check that looks from one place.

What surfaces it

A single-vantage check gave every defender in that chain a false all-clear for months. A multi-vantage check shows the split the first time anyone looks.

That is what whack.sh does: load a URL from several real vantage points at once and surface the divergence.

When a link behaves one way for a scanner and another way for a phone, you want to see both.

If you check links, check them from more than one place. If you would rather not build that yourself, that is what whack.sh is for.

Full technical writeup, indicators of compromise and the downloadable whitepaper are on the research site: tuxxin.com. For coordinated disclosure or the full evidence package: contact@tuxxin.com.

A real Carnival Cruise Line email was serving customers malware

Daniel J — Fri, 11 Sep 2026 01:07:57 +0000

A genuine Carnival Cruise Line booking confirmation routed customers to malware. The mail was authentic and passed SPF, DKIM and DMARC. The failure was a promotional domain Carnival had let lapse, still linked from live marketing mail, re-registered by someone else and wired into a redirection network.

Carnival re-acquired the domain on August 26th, 2026, and I verified the vector dead the next day.

The full path. A datacenter scanner only ever reached the clean parking page on the left. Real visitors reached the malware on the right.

Credit where this work starts

Trinity Cyber documented the redirection technique and the payload family in November 2025, in Blurred Lines: AdTech Abuse Delivers Browser Hijackers Through the Microsoft Store. Tanner Piliego and Jared Grumbein named the redirection layer PseudoTDS and the browser-hijacker family PhantomJack, and traced the initial redirects through the Trillion ad-tech network, formerly Trellian.

Their report describes victims reaching that machinery by mistyping a domain. This report describes the same machinery reached through an authenticated marketing email, which is the part that is new.

Both names in this article are theirs. What I add is the delivery path, a current set of indicators, and one payload behavior their report does not cover.

What I did to confirm it

On June 13th, 2026, I received a Players Club casino email from Carnival Cruise Line. It was a real booking confirmation carrying my own booking number, and all three authentication checks passed.

I clicked one of its links on my own PC, the way any recipient would, and landed on a fake-security page pushing a download. I reread the address bar and ran it again. Same result.

Then I checked it from a second computer and a different inbox belonging to another booked guest who received the same email. Same behavior, so nothing about it was specific to my account.

From there I stopped clicking blind and started capturing, from public scanners, from my own servers in different parts of the world, and from my phone. The same link behaved differently depending on where I loaded it from.

The cloak decides what you see

The landing page fingerprints the visitor and routes on the result, per visit.

Scanners, command-line tools and headless browsers fail that check and receive a benign skeleton. Real browsers on real networks reach a live payload.

The gate that sorts visitors. Screenshot from cclpromos.com, June 13th, 2026.

Point a scanner or a datacenter IP at that link and you get a clean, empty page. Load it on a phone or a home connection and it drops you into malware installers, scareware and fullscreen lockers.

The public reputation services I checked returned clean verdicts throughout. Those results are consistent with the services having received the same skeleton page my automated checks did.

When I ran the page through urlscan.io it came back flagged as one of "10,000+ similar pages," which points at a templated network rather than a one-off.

What the click bought

Here is what I observed. The domain resolved into a parked-domain monetization service. The content it returned changed with the visitor: automated clients received a compliant parking page, real browsers were handed to an advertiser, and which advertiser changed between visits.

An advertiser network sits behind that domain, and the disclosure record establishes it. I reported individual advertisers to the monetization service and those advertisers came down. Something in that chain decides which advertiser a visitor reaches.

Each removal had to be earned. The service acted on an advertiser once I had captured and handed over proof for that specific advertiser, which leaves the collection work with whoever happened to notice. Reporting a cloaked page is slow work, and doing it per advertiser is the slowest version of it.

The removals did not fix anything. Each one was replaced, the entry domain stayed live, and the email link kept routing into it until Carnival re-acquired the domain on August 26th. Removing an advertiser treats the symptom, and the timeline in the disclosure section shows it.

Why the split happens, as far as I can tell

Why the traffic splits the way it does is my reading rather than a documented fact. The behavior is consistent with parked traffic being sorted by what it is worth: traffic that passes strict quality checks goes to the buyers with the strictest policies, and traffic that fails those checks, by geography, device or automation signals, moves elsewhere.

On that reading, an automated checker resembles traffic the strict buyers accept and receives the compliant page, while a person on a phone is routed further down. It would explain why these domains test clean, and why anyone who checked one and found nothing was reading an accurate result.

The commercial terms are the part I cannot see. I have no contract, no revenue figure and no visibility into what any party knew about a specific buyer, so this report describes what the infrastructure did rather than what anyone intended by it.

What real visitors got

The page fingerprints the device and serves whatever fits it, rotating downstream domains as they get taken down. Every visit could return something different.

Between June 13th and 24th, 2026, this is what came through.

Fake-security installers for Windows

Forced .msix downloads dressed as privacy and antivirus apps, about 148 MB each. Four names rotated: SafeWatch, NetGuard, LeakGuard and PrivacyKeeper.

Each was signed with a certificate naming a bare GUID as the organization, issued by a Microsoft Marketplace CA and valid for three days. Both certificates had already expired before the packages were served.

These are PhantomJack, the browser-hijacker family Trinity Cyber named. SafeWatch, NetGuard and LeakGuard all appear in their report. PrivacyKeeper, SecuriGuard, QuickBrowse, MyConverterHub and SecuredWeb came off the same machinery and do not.

ReversingLabs classifies my SafeWatch sample as Win32.Trojan.PhantomJack, which is a vendor's read on the family rather than mine.

The package size is consistent with padding to exceed the size ceilings that antivirus engines and sandboxes apply before they will scan a file. SafeWatch is 147,724,942 bytes and PrivacyKeeper is 148,652,394 bytes, which a browser rounds to 141 MB in its download bar. I did not test any specific scanner's limit, so treat that as a reading of the size rather than a measurement.

Three payloads in 13 minutes from one link. Screenshot from Chrome download history, June 13th, 2026.

Scareware and fullscreen lockers

Several fake-antivirus landers rotated through the chain, including cloned McAfee "Run Quick Scan" pages.

A cloned McAfee lure served through the same link. Screenshot captured June 25th, 2026.

The lockers worry me more, and both of the ones I caught were absent from prior public reporting. There is no download and no install.

The page goes fullscreen, hides the cursor through the Pointer Lock API, loops a synthesized "your PC is locked" voice over a beeping alarm, and runs a fake scrolling hacker terminal. Each pushed its own scam phone number.

A browser locker imitating Windows Defender Security Center, pushing +1 (866) 315-0945. Screenshot captured June 23rd, 2026.

For a non-technical relative, that is harder to escape than an installer and likelier to work.

Different device, different attack

A Firefox search hijacker, an iOS "your iPhone has been hacked" scam, and browser push-notification hijacking all appeared, depending on the device.

The iOS variant of the same link. Screenshot captured June 13th, 2026.

Three unrelated advertisers came off that one domain inside 48 hours. The slot simply gets refilled.

PseudoJack: PhantomJack builds that keep a door open

Two of the installers arrived as .appinstaller loaders rather than plain packages. I captured both on June 20th, 2026: BelezaAI.PrivacyKeeper version 1.0.6.0 and BonitoApp.SecuredWeb version 9.0.3.0.

Both manifests carry an identical update block.

<UpdateSettings>
  <OnLaunch HoursBetweenUpdateChecks="0" />
  <AutomaticBackgroundTask />
  <ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion>
</UpdateSettings>

Three settings matter here. HoursBetweenUpdateChecks="0" checks on every launch with no delay, <AutomaticBackgroundTask /> checks even when the app is closed, and ForceUpdateFromAnyVersion accepts any version the server offers, including a downgrade.

Together they are a standing channel for the operator to push an arbitrary package at any time. A standard PhantomJack install is a one-time event. A build carrying this block keeps a door open behind it.

I track these builds as PseudoJack: PhantomJack packages that ship a forced auto-update channel. The name records lineage rather than a discovery, because the apps are already PhantomJack and the machinery is already PseudoTDS.

I proved the channel exists. I did not observe it delivering a second stage, and I did not detonate the samples, so every claim about what the installed app does comes from Trinity Cyber's analysis rather than mine.

Both publisher identities are bare GUIDs, CN=31E36F3F-1F26-4209-AA73-9C18172AA2E6 and CN=11069677-9767-4ED4-9C5B-619B79B9FE6B, which are throwaway signing identities rather than vendor names.

There is precedent for the format itself. Microsoft disabled the ms-appinstaller protocol handler by default in December 2023 after tracking abuse by Storm-1113, Storm-0569 and Sangria Tempest, and reported that multiple criminals were selling a malware kit as a service built on the MSIX format and that handler. My captures deliver the file by direct download rather than through an ms-appinstaller: URI, which is consistent with that handler having been off by default since 2023.

It fought back against inspection

The landers ship an anti-analysis layer. Opening developer tools froze the page on a debugger trap built at runtime, with no literal debugger token in the source for a scanner to find.

The anti-analysis layer firing on inspection. Screenshot from Firefox developer tools, June 24th, 2026.

The same layer hooks DOM query methods and inspects the caller's stack to spot console evaluation or injected extensions. It reports back to the operator's own telemetry endpoint.

That combination explains both halves of the problem. Payloads are hard to reproduce under analysis, and automated scanners only ever capture the skeleton.

The infrastructure is still live

I rescanned the chain on September 10th, 2026. The hosts Trinity Cyber reported have moved on: results.streamio[.]site now returns clean and cint[.]browsingit[.]online is unreachable.

The build I captured is still running. get.privacykeepersite[.]com returns a phishing verdict, securi-guard-browser[.]com is live, and cablegaurdian[.]online, guardianrole[.]online, euob.northwavepoint[.]com, tratobid[.]com and kineticharbor[.]com are all still cloaking.

The naming carries across. Their command-and-control host was cint[.]browsingit[.]online; mine are cint2.scrtgrd[.]online and cinga.ngapp[.]online. Same subdomain grammar, different apexes, rotated infrastructure.

The hop layer is disposable by design. Of 12 redirect-hop domains I scanned, 11 came back as dead parked pages: six lowercase letters plus .com, bulk-registered, all first seen in the same month, all on one parking IP.

All four of my samples were unknown to MalwareBazaar and ThreatFox before I filed them on September 10th, 2026.

The rotation is why this stays open. I mapped 12 of the 33 hop domains I collected, which leaves most of that layer unexamined, and the selection logic inside the redirect itself is still unseen.

I am continuing to track this kit and the domains it moves through, and I will publish what that turns up. Researchers working the same kit, or anyone holding telemetry on the hosts listed below, can reach me at contact@tuxxin.com.

What I could and could not confirm

I resolved the recipient's full 16-year email archive server-side, at a deliberately gentle rate, and validated the resolver against the known-bad link first.

The booking confirmation from June 13th is confirmed to route live to the lapsed domain.

The broader mailstream is clean. Across 541 deduplicated casino tracker links from 2018 to 2026, and 241 emails sent after the domain takeover, none routed to it. Every archived link still live resolves to www.carnival.com.

Older booking emails from 2024 and 2025 are unverifiable. Their tracker tokens have expired and now return an error page, so their original destinations cannot be recovered either way.

The exposure window runs from November 22nd, 2024, when the domain left Carnival's control, to August 26th, 2026. The cloaker is confirmed present by March 12th, 2026, the earliest archived snapshot containing it, and the previous snapshot from July 23rd, 2025, was still benign.

Several things stay out of this report for lack of evidence. I have no victim counts, no dwell time and no install numbers.

The commercial arrangements are also outside what I can observe. I documented what the infrastructure served and how it responded to reports, and I have no contract, no revenue figure and no basis to characterize intent.

How a Carnival link ends up serving malware

The root cause is mundane, which is what makes it worth writing about.

The domain was Carnival's own Players Club casino site. The 2021 Wayback snapshot shows Carnival branding, links to carnival.com, and the same /carnivalplayersclub/ path the malicious email still pointed at.

Content ceased around August 2022 and the domain lapsed. A third party caught it in November 2024.

The rest of the sending setup checks out from outside. The sending domain sits on an enterprise registrar with locks in place and years left on it, and the authentication passed because the mail genuinely was Carnival's.

One brand domain lapsed while live marketing mail still linked to it. That is the root cause visible from the outside, and the internal reason it lapsed is Carnival's record rather than mine.

Whoever holds a domain in that position has no need to build an attack. Pointing it at a monetization service turns leftover traffic into revenue, and the visitor is handed onward from there.

Chasing advertisers one at a time achieves nothing. Every one I reported was removed, and every removal was followed by a replacement, because the domain is the asset and the advertiser is inventory.

The breach question, answered directly

Carnival disclosed a data breach in April 2026, and this infrastructure predates it. Anyone reading the timeline will notice that, so I checked rather than leave it hanging.

I found no evidence connecting the two and I assert no connection. The domain takeover in November 2024 and the cloaker in March 2026 both predate the April breach detection.

What I documented is generic, mass-scale ad-monetization abuse. A targeted intrusion has a different profile. These are two separate events.

Reporting it, and what worked

I reported it the ordinary way first, to everyone who could act on a piece of it. The email provider, the registrars and hosts of the payload domains, Cloudflare, the browser blocklists, IC3 and the FTC.

Reaching Carnival took longer. The abuse and security inboxes I wrote to on June 15th went unanswered. A staff member confirmed the issue had been flagged internally, and no further response followed.

Phone routes ended at general customer service. The hotline stood up for Carnival's earlier breach did not cover this report either.

Meanwhile the parking service removed individual advertisers, each one after I supplied evidence for it. The entry domain stayed live throughout and the email link kept routing into it.

A certified letter is what worked. On August 5th I sent a formal notice with return receipt to Carnival's General Counsel, Global CISO and registered agent.

The Deputy General Counsel engaged on August 13th and moved it to Global Cybersecurity Services. I delivered the full technical package on August 25th, holding the live malware samples back until they asked for them.

Carnival re-acquired the domain on August 26th, moved it onto their own DNS and pointed it at a real Carnival page. I ran a final multi-vantage check on August 27th and confirmed the routing was dead everywhere.

From certified letter to resolved was 22 days. Reaching the letter took seven weeks.

What I take from it

Domain hygiene is a security control. A single expired promo domain, still linked from live authenticated mail, turned a trusted brand channel into a malware delivery system.

Audit the domains your live mail links to against the domains you still own. That is a lifecycle control rather than a mail control, and no amount of email authentication substitutes for it.

Put every brand and marketing domain on auto-renew with a registry lock. Then go looking for the ones that quietly lapsed years ago.

One vantage point tells you what that vantage point sees. Anything built to cloak is built to pass exactly that test.

One last note on the reporting path, for researchers rather than for Carnival. The technical work took days. Reaching a desk that owned the problem took seven weeks and a certified letter, and that is the part worth planning for at any large organization.

Indicators of compromise

Hashes are SHA-256. The two .msix samples are on MalwareBazaar and all four are on ThreatFox.

8a9006cfaee227415eeef0d645183ca423c80b9a8181e35a57bec71468e72daa  PrivacyKeeper.msix  (148,652,394 bytes)
d66895d8da6d5eb1d8658647c80f66dce40236c06bb600f1c62a44a657f923b3  SafeWatch.msix      (147,724,942 bytes)
b8f0c82894032766293b7f6e6feaf287a366edd4886b8e665c41bc5103d512ce  PrivacyKeeper.appinstaller
8de1357454488bd0702f0f22e912b412af41d814dffdc7c76f416d75d7dc1dc6  SecuredWeb.appinstaller

MalwareBazaar holds the two packages: PrivacyKeeper.msix and SafeWatch.msix. The two .appinstaller manifests are XML rather than binaries, so MalwareBazaar dropped them in processing and only their ThreatFox entries remain. That is why the manifest block is quoted in full above: for those two, the quoted XML is the evidence.

Delivery and update hosts, defanged:

get.privacykeepersite[.]com    get.gosecuredweb[.]com     file.ngapp[.]online
file.swatchapp[.]online        cinga.ngapp[.]online       spot.swatchapp[.]online
cint2.scrtgrd[.]online         show.ngrapp[.]online       spons.lkguard[.]online
cinnabon.pkeeper[.]net         lpic.prvbrws[.]com         guardianrole[.]online
securi-guard-browser[.]com     extensionsnewtab[.]com     pkeepers[.]online
pbrowsingapp[.]online          cablegaurdian[.]online     safe-guard[.]online

Redirect layer: tratobid[.]com and jubaaa[.]com. Anti-bot and beacon layer: ob.sd559908.js.brandsmat[.]com, euob.northwavepoint[.]com, ob.buzzfighter[.]com, assets.webfervor[.]com and kineticharbor[.]com.

Domains rotate. The delivery-kit path grammar has not, which makes it the more durable signature.

/lps/security-check/
/impression?c=<campaign>&ext_name=<Brand>&cid=<id>
/downloadproxy/<campaign>/<clickid>/?ext_name=<Brand>&cid=<id>&tag=<cid>_<YYYY-MM-DD>&file=true
/event/download   /event/download_button_clicked   /event/download_xhr_completed
/event/pageload   /event/incognito_status
appData=fr2TvjWVEr+MejYst84xw...

That appData prefix is a fixed 21 characters and appears unchanged across unrelated brand domains.

Evidence and technical detail

The full findings report documents the de-cloaked redirect chain, every payload variant, the cloaking and anti-analysis techniques, the complete indicators of compromise with hashes, and the disclosure record.

Whitepaper: Carnival-cclpromos-Security-Findings.pdf (2.9 MB) SHA-256 BED672E46273F7AFF10E75310600AA4B1C7F28A795A16DC15CDB356669BF3D24
Evidence package, screenshots and sanitized HAR captures: Carnival-cclpromos-Findings-Evidence.zip (6.9 MB) SHA-256 F995FCCC77E40EA63E3A842E22796C0FEC07D548E8F05A471EEE884C3C53C3C6
Checksums, including the sealed priority hash from June 25th, 2026: Carnival-cclpromos-Findings-Evidence.sha256.txt

Check a download against the hash above before opening it.

sha256sum Carnival-cclpromos-Security-Findings.pdf
Get-FileHash Carnival-cclpromos-Security-Findings.pdf -Algorithm SHA256

The first line is Linux and macOS, the second is PowerShell.

For context on the technique, the FBI's IC3 published PSA I-061826-PSA on June 18th, 2026, warning about criminals redirecting users through malicious traffic distribution systems. I make no claim that my report prompted it. A federal advisory takes far longer than a few days to prepare, so I note it only as independent confirmation that this attack class was active and recognized in the same window.

All malicious domains in this report are defanged. The original findings were documented and cryptographically hashed on June 25th, 2026, and that timestamp hash is published with the evidence package for verification.

This report is the original work of Tuxxin LLC, published under Creative Commons Attribution-NoDerivatives 4.0. Media and researchers may quote and republish it with attribution to Daniel Jones, Tuxxin LLC. For the full evidence package or coordinated disclosure: contact@tuxxin.com.

Capture any site in light or dark theme

Daniel J — Wed, 09 Sep 2026 19:19:46 +0000

Webshot now sets the color scheme the target page renders in. Pick Auto, Light or Dark in the capture form, or send a theme parameter to the API.

Chrome reports prefers-color-scheme: light by default. A site that follows the visitor's system setting could only be captured in its light form, whatever it looks like to the people using it. overwatch.earth, issued.live and whack.sh all work that way.

Using it from the form

A Theme control sits next to Format. Auto is the default and sends no override, so captures you make today match the ones you made last week.

Using it from the API

Add theme to the request body:

curl -X POST https://webshot.site/api/capture \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://overwatch.earth","mode":"desktop_viewport","theme":"dark"}' \
  --output shot.jpg

Accepted values are system, light and dark. Anything else returns HTTP 400 with the accepted list, so a typo fails loudly rather than returning the wrong theme.

When the override is applied

The scheme is set before the page loads. A theme script that reads the preference once during startup, which is how a site avoids a flash of the wrong colors, sees the requested scheme on its first paint.

Credit cost is unchanged.

overwatch.earth rebuild adds feed pages, discussions, and passwordless comments

Daniel J — Wed, 09 Sep 2026 13:00:03 +0000

overwatch.earth now opens on a website. Earlier versions loaded straight into the 3D globe. The front page lists all 34 live feeds grouped by theme, and every feed has its own page covering the data behind it, where it comes from, and a globe focused on that feed alone.

The globe is one click away and still needs no account.

Every feed has its own page

The 34 feeds are grouped into four themes:

Transit (6): aircraft, ships, Amtrak trains, military aircraft, public transit, airports.
Environmental (14): earthquakes, wildfires, live clouds, satellite imagery, lightning, disaster alerts, natural events, aurora, ocean buoys, air quality, weather alerts, EMSC seismic, fireballs, volcanoes.
Digital (5): submarine cables, internet outages, data centers, IODA outages, internet events.
Curiosity (9): Wikipedia pulse, global news, satellites and the ISS, rocket launches, biodiversity, webcams, Starlink, the Deep Space Network, rare birds.

Each feed page names its upstream provider, and every layer is attributed on the data sources page.

Discussions on every feed

Each map carries a comments drawer, so a conversation attaches to the feed it belongs to. The discussion page collects what people post across all 34 feeds and ranks it by recent activity.

Commenting takes an email and a username

Enter an email address and pick a username. overwatch.earth emails a pin code from noreply@tuxxin.com, and entering that code signs you in. You choose whether to stay signed in for 30 days or keep the session temporary.

Every sign-in works this way, so the site stores no passwords. There is nothing to reuse across sites, nothing to leak in a dump, and no reset flow to phish.

Suggest a feed

The contact form accepts data source submissions. It asks for the source name, a URL or link to its API docs, and a note about what it covers. Send one through Suggest a data source.

What comes next

More feeds are queued for release. Work has also started on a multi-tenant system that will let people build their own globes from their own data.

overwatch.earth is free to read, runs on open public data sources, and requires no login.

Rebuilding Houston's Courier: New Site, Driver Portal, and a Dispatch System in Progress

Daniel J — Thu, 03 Sep 2026 15:38:30 +0000

Houston's Courier has been moving freight and time-critical deliveries around the Gulf Coast for decades. Their website had not kept up. This is what we rebuilt, what we surfaced, what we added, and what is still on the bench.

Starting with the part customers see

The old site was nearly a decade old. It had a mobile layout — it just did not work properly, with errors throughout that got worse the smaller the screen got. Underneath that, the site was thin where it counted: very little SEO foundation and effectively no structured data, so search engines had to guess at what the business did, where it operated, and what services it offered.

The service list had also fallen behind. Not because the company changed direction — Houston's Courier does what it has always done — but because it kept adding capabilities and the website never caught up. Work they were actively selling simply was not on the site.

The new site is a ground-up replacement: same-day delivery leads, the catalog reflects everything the company actually offers in 2026, structured data describes the business properly, and the client login sits on the homepage instead of behind a hostname nobody could remember.

One service the site was hiding, and one that is coming

A courier already sends a bonded, uniformed, background-checked person to a customer's door with a package. That position turns out to be worth more than a single delivery.

Mobile notary — already offered, never advertised. This is not a new service line; Houston's Courier has been doing it. It was nowhere on the old website. Documents that need a notary are frequently the same documents that need a courier, so one visit covers both — and the company was earning none of the search traffic for it, because as far as Google was concerned the service did not exist.
Electronic ID verification for age-restricted deliveries (18+ and 21+) — built, not yet launched. Alcohol, tobacco, vape, and certain pharmacy items carry a legal obligation to verify age at handoff. This is a genuinely new capability rather than an unadvertised one, and it ships with the new dispatch system described below — it is not orderable today.

Those two are worth separating clearly, because they are different kinds of work. One was a marketing failure with an easy fix — the service existed, the website just never said so. The other required building something that did not exist, and it launches when the new system does.

The driver portal, where the compliance actually happens

"We verify ID" is a claim. The driver portal is the evidence. Drivers work from a portal built for a phone in one hand and a package in the other:

Barcode scanning off the air bill. The driver scans rather than types. That kills transposed tracking numbers, which are the single most common cause of a package that is physically fine and administratively lost.
Photo delivery confirmation. A timestamped photo at the drop point, attached to the stop. "It was left at the side door" stops being a memory and becomes a record.
Electronic ID verification at handoff, over a secure network. Launching with the new system: the age check is performed and captured electronically at the point of delivery and transmitted over an encrypted connection — not written on a signature sheet, not photographed and emailed, and not reconstructed from memory weeks later when someone asks for proof.

The through-line is that each of these replaces something a driver used to remember with something the system holds, securely. That matters most on the day a client disputes a delivery: the answer is a record retrieved in seconds, rather than a phone call to a driver who has made two hundred stops since.

Dispatch: replacing the system, not skinning it

The largest piece of this engagement is roughly two-thirds built, and it is worth being precise about what it replaces.

Dispatch, driver management, and the customer portal all lived inside one integrated legacy application on manage.houstonscourier.com. That coupling is the problem. Every change to how dispatchers work risked the customer-facing side, and every change a customer noticed had to be regression-tested against dispatch. Nothing could be improved in isolation.

The replacement is a standalone system with three separate surfaces:

Admin and dispatcher — order intake, assignment, and the live board dispatchers work from all day.
Driver — the portal above: scanning, photo confirmation, electronic ID capture.
Client — and this one goes into the new website rather than beside it. Customers place and track orders on the same domain they landed on, not on a subdomain that looks and behaves like different software, because it was.

Three things ship with it:

A suite of new security controls across all three surfaces. A system holding delivery addresses, signed proof-of-delivery, and age-verification records is holding sensitive data, and the legacy application was not designed with that in mind.
A far easier experience end to end — from submitting an order to paying the invoice. The old flow worked if you already knew it. The new one does not require that.
Continuous route optimization using the current Google Maps platform APIs, re-optimizing as the day changes rather than planning once in the morning and hoping. Traffic in Houston does not hold still, and neither should the route.

Splitting one application into three surfaces on a shared core costs more up front than restyling the old one. It buys the ability to change a dispatcher's workflow on a Tuesday without touching anything a customer can see.

No AI in the workflow. That is a decision, not an omission.

It is worth stating plainly, because in 2026 the default assumption runs the other way: no AI touches the day-to-day operation of Houston's Courier. Every delivery ticket, every email, every phone call, and every delivery is handled by a real person.

The software's job here is to remove clerical work and to remember things accurately — scan instead of type, capture instead of recall, re-optimize a route as conditions change. The judgment calls stay with the dispatchers and drivers who know the accounts, the buildings, and which receiving dock actually opens at 7am.

For a same-day courier that is not nostalgia, it is the product. When a delivery is time-critical and something goes wrong, the customer wants a person who can fix it — not a queue.

What the search numbers did

A rebuild is a genuine risk to organic search. New URLs, new structure, and a decade of accumulated signals to carry across — sites lose traffic doing this. Six months on, compared against the six months before:

Impressions: 153K → 273K, up 78%
Clicks: 3.05K → 3.84K, up 26%

Worth reading those two together rather than separately. Impressions grew faster than clicks, which means the site now surfaces for a far wider set of queries — including broader, higher-funnel searches that were previously out of reach entirely and that convert at a lower rate by nature. Average click-through moved from about 2.0% to about 1.4% as a result. That is the arithmetic of a site appearing in a great many more places, not a site getting worse at earning the click, and the number that pays the bills — actual visits from search — is up by roughly 790 a month.

A good share of that is the unglamorous work: real structured data, a service catalog that lists the services, and pages for offerings like mobile notary that were previously invisible to search entirely.

Still to come

The dispatch and portal build is about two-thirds done. The remaining third is the part that has to be right rather than fast: cutting live operations off the legacy system without dropping an order mid-flight, and moving the client portal into the new site so customers stop seeing two different pieces of software.

Age-restricted delivery goes live at the same time, with its own service page — there is no point advertising a capability before the system that performs it is carrying real traffic.

We will write that up when it ships, including whatever goes wrong on the way.

Houston's Courier is a Tuxxin LLC client. If you are running a business on software a decade past its service life — and you can usually tell, because everyone has a workaround for it — get in touch.

Is curl | bash Safe? What qsa.sh Does Instead

Daniel J — Thu, 03 Sep 2026 12:52:57 +0000

You have seen the pattern in a hundred install docs:

curl https://example.com/install.sh | bash

It is convenient. It is also the single most-argued line in DevOps. Before you paste it into a root shell, it is worth being precise about what it actually does — and about what curl qsa.sh does not do, because the two look similar and are not the same thing at all.

What `curl <url> | bash` actually does

The pipe does exactly what it says. curl fetches whatever bytes the server sends, and bash executes them as a shell script — on your machine, with your privileges, right now. There is no preview, no diff, no confirmation step. Whatever the server returns is the program that runs.

That is not a hypothetical. It is arbitrary local code execution by design. The risk is not that the pattern is broken; it is that it works perfectly and hands full trust to a remote party. Specifically:

You cannot see what you ran. By the time the script executes, you have already run it. Auditing after the fact is not auditing.
Trust extends to the whole chain. You are trusting the domain, its TLS, its DNS, the CDN in front of it, and anyone who can compromise any of those. A server can also detect a piped shell (no TTY) and serve different bytes than it shows in a browser — this has been demonstrated publicly.
Failure modes get worse. A truncated download can leave a half-run script. sudo curl ... | bash runs remote code as root.

To be fair — and this matters — curl | bash is not automatically malicious. Downloading a release binary, an apt package, or a container image is also "run code you didn't read." The pattern's real sins are that it skips the checkpoint where you could have looked, and that it re-fetches live every time, so a good script today can become a bad script tomorrow with nothing pinned.

The safer way to run an install script

If you are going to run one, split fetch from execute so there is a moment to look:

curl -fsSL https://example.com/install.sh -o install.sh
less install.sh          # actually read it
sha256sum install.sh     # compare to a published checksum, if any
bash install.sh

Not glamorous. But now there is a checkpoint, and you are running a known artifact instead of a live stream. Prefer signed packages or checksummed binaries when the project offers them.

Why `curl qsa.sh` is a different animal

Here is the part people conflate. curl qsa.sh is not curl qsa.sh | bash. There is no pipe into a shell, and there is nothing on our end that expects one.

curl qsa.sh makes an HTTP request and streams text back to your terminal. That text is a scan report. Your shell prints it, the same way it would print a README. No script is downloaded to be executed, no code runs on your machine, and adding | bash would accomplish nothing useful because the output is a human-readable report, not a program.

The work happens on our side, not yours:

The scan runs from qsa.sh's own real, attributable scanner IP (reverse-DNS scanner.qsa.sh) — an outside-in view, exactly what an external attacker sees.
It scans only the public IP you are connecting from. There is no target field; you cannot aim it at anyone else. Your IP is shown with a countdown before anything starts.
The engine is the same open-source tooling you could run yourself: naabu for port discovery, nmap -sV --script vulners for service/version and CVE matching, then nuclei for templated checks (current engine versions). No black box.
Zero retention: results stream to your terminal and are gone. No stored scan output, no stored IPs, no user-agents, no history.

So the trust question inverts. With curl <url> | bash, the remote server runs code on your machine. With curl qsa.sh, your machine runs nothing — it just displays what our scanner found looking at your public IP from the outside.

Side by side

	`curl <url> \| bash`	`curl qsa.sh`
What comes back	A shell script	A text report
What runs it	Your shell, on your host	Nothing — it is printed
Where code executes	Your machine, your privileges	Our scanner, server-side
What it can touch	Your filesystem, your creds	Only your public IP, from outside
Retained	Whatever the script writes	Nothing

A fair caveat, because this is a security site

You should still know who you are talking to. curl qsa.sh streams text and runs nothing locally — that is true whether you trust us or not, because the output never touches your shell as code. But the report itself comes from us, so treat qsa.sh like any external scanner: it is a starting point, an attacker's-eye view of your exposed surface, not a full audit.

One practical note: plain curl qsa.sh is HTTP. To encrypt the request and response in transit, use curl https://qsa.sh. Same scan, same report — just protected on the wire. On a network you do not control, prefer the https:// form.

The short version

curl <url> | bash is not evil, but it is arbitrary local code execution with no checkpoint — read it, checksum it, or use a signed package first. curl qsa.sh is not that pattern: it prints a report, runs no local code, and does its scanning from our own IP against only your public IP.

Run it and read the output:

curl https://qsa.sh

See how it works, what we do and don't retain, or what the paid tiers add.

OAuth Consent Phishing: The Attack a Password Change Does Not Fix

Daniel J — Thu, 03 Sep 2026 08:07:27 +0000

The FBI's Internet Crime Complaint Center published PSA I-090126 on September 1, 2026, and it describes an attack that quietly defeats the two things most people rely on: changing your password, and having multi-factor authentication turned on.

Neither one helps here. That is not a flaw in either — it is that this attack never touches your password at all.

What consent phishing actually is

You have almost certainly done the legitimate version of this. You sign into some service with “Continue with Google,” a permission screen appears listing what the app wants — read your email, see your files, post on your behalf — and you click Allow. That grant is an OAuth token. It is how a scheduling tool reads your calendar without ever knowing your password.

Consent phishing is the same flow with a hostile app at the end of it. The attacker registers a real application with a real provider, requests broad permissions, and sends you a link. You land on a genuine login page — the actual Google or Microsoft one, correct domain, valid certificate — and authenticate normally. Then the permission screen appears, and if you approve it, the attacker holds a token that reads your mail and files whenever it likes.

The IC3 is blunt about the consequence. The access “can only be revoked by the victim invalidating the token in their application security settings; not by changing the password.”

Why your usual response does nothing

Think about what you would do if you suspected an account compromise. Change the password. Check MFA is on. Sign out other sessions, maybe.

None of that revokes an OAuth grant.

Changing your password does not invalidate the token. The token was never derived from your password.
MFA does not stop it. You completed MFA yourself, correctly, on the real login page. The attacker never needed to defeat it — you satisfied it and then handed over a key on the next screen.
There is no suspicious login to spot. The app is calling an API with a valid token, not signing in from a strange country. Your login history looks clean.
Nothing expires on a useful timescale. A refresh token can stay valid for months or longer, renewing itself quietly.

That last point is the one worth sitting with. This is not a break-in you notice and clean up. It is a key you handed out, filed under a permission screen you closed and forgot — genuinely out of sight, out of mind.

Who is being targeted

The PSA names prominent individuals, their family members, and personal acquaintances, approached through ordinary commercial messaging apps rather than email. The pretexts impersonate government officials, media figures, and event coordinators, and the ask is mundane: review this document, verify your identity, confirm attendance.

Family and acquaintances are in that list deliberately. If you are hard to reach directly, the people around you are the way in.

Go audit your grants — this is the useful part

Whether or not you have been targeted, this is worth twenty minutes. Most people have not looked at these lists in years, and find things they no longer recognize: a trial from four jobs ago, a plugin that asked for far more than it needed, a “free analyzer” that still reads everything.

Google — myaccount.google.com/connections. Sort by access level. Anything holding Gmail or Drive read access deserves a hard second look.
Microsoft / Entra — myapps.microsoft.com, then My Account → Privacy → Apps and services.
LinkedIn — Settings → Data Privacy → Permitted services.
GitHub — Authorized OAuth Apps, and check Installed GitHub Apps separately — they are two different lists and people routinely check only one.
Dropbox, Slack, Zoom, Meta — all keep an equivalent connected-apps page.

Revoke anything you do not actively use. Revocation is instant and free; if you break something you still need, you reauthorize it in a click. That asymmetry is the whole argument for being aggressive here.

What good scrutiny looks like

The moment that matters is the permission screen, and it is over in about two seconds. Slow it down:

Read the scopes, not the app name. The name is chosen by whoever registered the app and can be anything. The permissions are the truth. A PDF viewer does not need to send mail as you.
Ask why this needs an account at all. Reviewing a document rarely requires read/write access to your entire mailbox.
Verify the sender out of band. Not by replying to the message — through a number or address you already had.
Treat urgency as the tell. A deadline attached to a permission request is doing a job.

If you think you clicked Allow

Revoke the grant first, on the provider's connected-apps page. Do this before anything else — until the token is gone, the access continues.
Then change the password and re-check MFA. In that order; the reverse accomplishes nothing on its own.
Check mailbox rules and forwarding. A common follow-up is a quiet auto-forward or a rule that files security alerts straight into the trash.
Review sent mail. Access is frequently used to phish your contacts from your real address.
Report it — your local FBI field office, or ic3.gov.

The honest tension

Worth saying plainly: OAuth consent is not the problem. It is a genuine improvement over the thing it replaced, which was typing your actual password into third-party sites and hoping. Every grant that reads your calendar without knowing your password is that design working.

The weakness is that one screen carries an enormous amount of meaning and gets about two seconds of attention, and that what it hands over is durable in a way people do not expect. A password is something you can change. A consent grant is something you have to remember you gave.

So put it on the calendar. Once or twice a year, open those pages and prune. It takes twenty minutes and it is the only maintenance that actually closes this class of access.