Skip to main content
PhishEye

Revolut Data Breach and 37 Phishing Domains

Published 31 min read

Cover illustration showing a bank brand name sitting in the subdomain of a numeric domain, with sixteen hosts converging on a single network range.
Contents

In the week after the Revolut breach was reported, phishing texts carrying the bank's name began arriving. One of them pointed here:

Safety notice. Campaign hostnames are defanged as example[.]com wherever they appear in prose and in the indicator tables, and none of them is a link. The one exception is the certificate listing further down, which reproduces what the certificates literally contain and would misrepresent them if altered. Do not visit these hosts, and do not submit anything to them. Our own checks were limited to DNS lookups, TLS handshakes and HTTP response codes.

hxxps://revolut.com.93810[.]app/

Read it left to right and it looks like Revolut. Read it the way a browser does, from the registrable domain outward, and it is 93810[.]app, a five-digit domain with no connection to the bank. The brand is a subdomain.

Public reporting listed a handful of hostnames in that shape. We wanted the real count, so we attacked it two ways: we enumerated all 100,000 five-digit numbers under .app, querying revolut.com.<number>.app directly, and we ran wildcard searches against a certificate index that can match a pattern rather than a domain.

The two methods disagreed with each other, and neither was complete. Together they produced 37 Revolut phishing domains, 23 of them still live, on phishing infrastructure that has been running since 19 July 2026, almost two months before the breach was reported.

Key findings

  • 37 hostnames of the revolut.com.<digits>.app shape, of which 23 still resolve and answer as of 19 September 2026 and 14 no longer resolve at all.
  • None of them served us a page. In 235 checks from 45 vantage points across 32 countries we recorded no HTTP 200 at all, so "live" here means live infrastructure, not an observed phishing page.
  • The phishing infrastructure spans two hosting ranges under one provider. 21 live hosts sit in 186.2.175.0/24; two more sit in 185.178.208.0/24, which belongs to DDoS-Guard directly. All 24 domains we checked delegate to ns1/ns2.ddos-guard.net.
  • One registrar for every domain. All 24 were registered through NiceNIC, each for exactly one year.
  • The campaign is far older than the breach. The first hostname appeared on 19 July 2026. Twenty-nine of the 37 existed before the disclosure was reported on 12 September. The phishing did not follow the news.
  • The certificates do name the brand. Each SAN is <number>.app, revolut.com.<number>.app. The assumption we started with, that the brand stayed out of the certificate, was wrong.
  • crt.sh holds none of these certificates. For the four domains we could query cleanly, it returned zero certificates dated after 1 August 2026, including one domain for which it holds nothing at all. Two other indexes return them immediately.
  • Neither of our own methods was sufficient. Enumeration found four hosts the certificate index did not have; the certificate index found twenty that enumeration could not reach.
  • No .top counterpart. We enumerated another 100,000 candidates there and found nothing on the campaign infrastructure.
  • The shape is not exclusive to this operator, but the infrastructure is. Similar hostnames exist for PayPal, Chase, Santander and Wise. None of them resolve into either of these ranges.

How we found them, and how both methods failed

Method one: enumerate the namespace. The published hostnames gave us a shape rather than a list, and a shape is enumerable. We resolved all 100,000 candidates from revolut.com.00000.app to revolut.com.99999.app against six public resolvers, and got 9,326 answers back.

Almost all of that is noise. The answers point at 103.224.212.141, 188.114.96.6, 91.195.240.94 and similar: parking and CDN wildcards. A registered numeric domain with a wildcard DNS record answers for any subdomain you invent, including one with a bank's name on the front.

So the resolution is nearly meaningless. The discriminator is where it resolves to. Filtering 9,326 answers to a single hosting range left fifteen hostnames, and every one verified as a real campaign host.

Fifteen, not sixteen. The sweep missed revolut.com.69759[.]app, a host we already knew about and had confirmed by hand minutes earlier. Three UDP attempts failed against a busy public resolver and the name was recorded as absent. It also structurally could not see anything outside the five-digit space, and the campaign turns out to use four- and six-digit domains too.

Method two: wildcard search over certificate data. Querying MerkleMap for the pattern revolut.com.*.app returned 33 hostnames in one request, including the four-digit revolut.com.9285[.]app and six-digit entries like revolut.com.328102[.]app, and including fourteen that no longer resolve. It found in seconds what the sweep took seven minutes to approximate.

But it was also incomplete. Four hosts registered on 17 September, which our sweep found and confirmed, were not in its index when we queried.

Source Found Missed
DNS enumeration of the 5-digit space 15 live hosts Everything dead, everything not 5 digits, and one live host to packet loss
Wildcard certificate search 33 hostnames including dead ones and all digit lengths Four hosts registered two days before we queried
Union 37 hostnames, 23 live Unknown, but the count is a floor
Venn diagram of two discovery methods. Wildcard certificate search returned 33 hostnames and DNS enumeration returned 16, but they agreed on only 12. Certificate search alone found 21 and enumeration alone found 4, giving a union of 37.
Figure 1. Each method missed most of what the other found. Certificate search lags new registrations; enumeration cannot see dead hosts or domains outside the five-digit space it was given.

The lesson is the table, not either row. Each method has a blind spot the other covers, and they agreed on only twelve hostnames out of thirty-seven. Twenty-one were visible to certificate search alone and four to enumeration alone. Anyone running one technique and treating the output as complete is seeing about a third of the campaign.

Which detection methods find this campaign

Method Result Why
Typosquat permutation on revolut.com Misses No generator produces 93810.app; the string has no relation to the brand
CT search anchored on the brand domain Misses revolut.com.03910[.]app is not a subdomain of revolut.com, so suffix matching never fires
crt.sh, even for the exact hostname Misses Returned zero rows for certificates that are demonstrably logged
Wildcard or substring search over certificate data Finds The brand is in the SAN; it needs a query that can match mid-hostname
Newly-registered-domain feeds Finds, if you read .app All 24 domains we checked were registered in a two-month window
Namespace enumeration plus hosting correlation Partly Finds live hosts of the right length only
Registrar and nameserver correlation Finds the cluster One registrar and one DNS provider across every domain

About this analysis

Evidence Status
Enumeration of 100,000 .app and 100,000 .top candidates Performed by us, 19 September 2026
Wildcard certificate searches Performed by us against MerkleMap, 19 September 2026
DNS resolution, HTTP status codes, TLS certificates for all 37 hostnames Verified directly, 19 September 2026, from an Egyptian IP
Response behaviour: 235 checks, 45 vantage points, 32 countries Verified via a third-party checking service, 19 September 2026
That the response is insensitive to user agent and language Verified directly across four user agents and two language headers
Registration dates, registrar, nameservers for 24 domains Verified directly via registry RDAP
IP ownership, ASN, abuse contacts for both ranges Verified directly via RIPE RDAP and route objects
crt.sh coverage comparison Measured directly, HTTP 200 responses only
SMS screenshots Supplied by the reporter
The gift-card page and the voice-scam alert Supplied, not independently inspected
Breach reporting Third-party journalism, cited below

Claims that are neither our own observation nor cited reporting are labelled as inference.

What happened in the Revolut data breach

Revolut confirmed a customer data disclosure after criminals sent fraudulent requests from a legitimate government-agency email address. The company said its own systems were not breached and customer funds were unaffected. The Guardian reported a ransom demand attached to the stolen data.

That distinction matters when you read the rest of this. This was social engineering against a data-request process, not an intrusion into banking infrastructure. A request that arrives from a genuine government domain passes every technical check an email gateway can apply, because the domain really is what it claims to be. The failure is in the verification step that happens after the mail is delivered.

Revolut has not published a field-level breakdown of what was disclosed, and we are not going to speculate. We have seen no evidence either way on identity documents, selfies or transaction histories, so treat any confident claim about specific data types, including ones circulating on social media, as unverified.

What we can speak to is what came next, which is the phishing. The rest of this report is our own measurement of that infrastructure.

What the Revolut phishing SMS looks like

The message is short, sets a deadline, and puts the brand where a hurried reader looks first.

Phishing SMS displayed under the sender name Revolut reading confirm your identity now, otherwise access to your account will be restricted, followed by a link to revolut.com.93810[.]app.
Figure 2. The lure. The sender renders as "Revolut" and the link reads revolut.com.93810[.]app. The registrable domain is 93810.app; everything to its left is a subdomain the operator controls.

The second screenshot matters more, because it shows where the message lands.

An SMS conversation under the sender name Revolut containing genuine Revolut login codes in Russian and English, with a phishing message in Estonian inserted between them linking to a revolut.com subdomain.
Figure 3. The phishing message arrives in the same thread as genuine Revolut login codes. Sender-ID grouping files it alongside the real ones, so thread history offers the recipient no protection.

The genuine messages in that thread are one-time login codes. The fraudulent one sits between them and reads, in Estonian, as an identity-confirmation demand.

State this plainly in customer guidance: earlier legitimate messages in a thread authenticate nothing. Sender identity in SMS is a display string, and everything sharing that string is grouped together regardless of who sent it. "Check it arrived in your existing Revolut conversation" is advice that fails against this campaign.

How these phishing domains are built

Every hostname in the campaign has the same construction: the literal string revolut.com, then a numeric label, then .app. The registrable domain is the number. The brand is a subdomain, which costs nothing to create and can be changed at will.

The digit count varies, and that detail defeated our first method:

Digits Examples Count
Four 9285 1
Five 93810, 03910, 78491 30
Six 328102, 298201, 292019, 347591, 168192, 328192 6

The consequence for permutation-based monitoring is total. A typosquat permutation engine works outward from revolut.com, producing character swaps, hyphenations and alternate TLDs: revolut-secure.com, rev0lut.com, revolut.net. It will never produce 93810.app, because that string has no relationship to the brand and no generator has a reason to consider it.

Why Certificate Transparency monitoring missed them

This is where our starting assumption broke, and it is the most useful part of the analysis.

We expected the certificates to name only the numeric domain, hiding the brand from Certificate Transparency. They do not. Read off the wire, each is a Let's Encrypt certificate whose subject common name is usually the number and whose SAN contains both names:

revolut.com.78491[.]app   CN=78491.app   SAN: 78491.app, revolut.com.78491.app    27 Aug 2026
revolut.com.64412[.]app   CN=64412.app   SAN: 64412.app, revolut.com.64412.app     3 Sep 2026
revolut.com.03910[.]app   CN=03910.app   SAN: 03910.app, revolut.com.03910.app    14 Sep 2026

A handful go further and put the brand hostname in the common name itself, such as revolut.com.168192[.]app. Either way the brand is in the certificate, every certificate is publicly logged, and two independent indexes return them on request.

Certificate Transparency works as designed here: the information was public from the day each host went up. Two separate things stopped anyone acting on it.

First, the query shape. Brand-protection CT monitoring is normally anchored on a domain: watch revolut.com, include subdomains. That matching is a suffix test, and revolut.com.03910[.]app is not a suffix match for revolut.com. It is a different registrable domain that happens to begin with those characters. We confirmed this against a CT index: a query for revolut.com with subdomains included returns 244 distinct hostnames and not one campaign host. Catching this requires pattern or substring matching across the whole SAN, which is a different and noisier query than most monitoring products offer.

Second, the index. crt.sh is the tool most practitioners reach for. We measured its coverage on the four campaign domains where it gave us a clean HTTP 200 rather than a rate-limit error:

Domain Certificates in crt.sh Dated after 1 Aug 2026 Actually issued
03910.app 5 0 14 Sep 2026
93810.app 16 0 11 Sep 2026
45392.app 8 0 6 Sep 2026
57482.app 0 0 3 Sep 2026

Zero out of four. A direct search for the exact hostname revolut.com.03910[.]app also returns nothing. MerkleMap and SSLMate both return these certificates immediately.

Inference. We did not determine why crt.sh is missing them, and we are not suggesting the operator picked a log to exploit a known gap. The practical lesson holds regardless: "I checked CT and found nothing" is only as strong as the index you checked. Querying a second source would have surfaced this campaign two months ago.

There is a sharp contrast with a campaign we wrote up last week, where a genuine wildcard certificate meant the brand-carrying hostname never entered CT at all. That was a structural blind spot in what certificates record. This one is not. Here the data was published, indexed, and simply never queried in a way that could match it.

The older certificates crt.sh does hold for these domains, including a Certum wildcard for *.03910.app from November 2024, belong to earlier registrations. Registry records show every one of these domains created between July and September 2026, so those certificates are a previous life, not this operator's.

One phishing infrastructure, not 37 incidents

Registry and network records make this one body of phishing infrastructure rather than 37 unrelated phishing domains.

Attribute Value Applies to
Registrar NiceNIC International Group, [email protected] All 24 domains checked
Nameservers ns1.ddos-guard.net, ns2.ddos-guard.net All 24 domains checked
Registration term Exactly one year All 24 domains checked
Primary hosting range 186.2.175.0/24, IQWEB-LLC-NET, AS59692, [email protected] 21 live hosts
Secondary hosting range 185.178.208.0/24, DDOS-GUARD LTD, AS57724, RU 2 live hosts
Reverse DNS on both ranges ddos-guard.net Both ranges

DDoS-Guard is the thread that ties it together. The second range belongs to DDoS-Guard outright. The primary range is registered to a different company, IQWeb FZ-LLC, yet its reverse DNS resolves to ddos-guard.net across the whole /24 and every campaign domain delegates to DDoS-Guard nameservers. Whatever the commercial arrangement, the DNS and the mitigation layer are the same provider on both.

The primary range's records disagree with themselves on geography. The RIPE object for 186.2.175.0/24 carries country code BZ while the postal address on the same object is in Dubai and the maintainers are UAE LIR objects; Team Cymru resolves AS59692 to IQWeb FZ-LLC in AE. Treat the country field as unreliable and [email protected] as the actionable part; WHOIS and RDAP disagree often enough that it is worth reading both.

What the hosts actually serve: nothing we can find

Every host answers, holds a valid certificate, and returns either HTTP 403 or HTTP 404. None of them, anywhere we looked, returned a page.

The 403 is DDoS-Guard's own block page, an identical 1,606-byte body that reads:

It looks like that the website owner has restricted access from your current IP address. To protect their website from malicious activity, the owner or administrator may block access from specific countries, networks, or IP addresses.

It loads /.well-known/ddos-guard/geoblocked.css and /.well-known/ddos-guard/geoblocked.js, and sets __ddg9_ to the requesting client's public IP.

The filename says "geoblocked". The behaviour does not confirm it. We ran the same URLs from 45 vantage points in 32 countries through a third-party checking service, so the requests came from their infrastructure rather than ours. Two things fell out of that. First, the 403 and 404 responses do not split along national lines: in individual runs, Iran, the Netherlands, Russia, Turkey, the United States, Ukraine, Germany and Indonesia each returned both. Second, the split is not stable over time, as the table below shows.

A country-level block would be consistent within a country and consistent across an hour. This is neither. The honest reading is that the DDoS-Guard edge is filtering on something per-request, and that the geoblocked label describes the template it serves rather than a policy we have verified.

Nothing served content to anyone. We ran seven sweeps in total, 235 checks against four hosts from 45 vantage points in 32 countries, and recorded not one HTTP 200.

Summary of 235 HTTP checks on four campaign hosts from 45 vantage points in 32 countries: 108 returned 404, 97 a DDoS-Guard 403 block, 24 a 503, and none returned HTTP 200. Nodes in one city disagreed within a run.
Figure 4. Every check, every country. No vantage point we could arrange was served a page, and nodes in one city disagreed with each other inside a single run.
Host and path Checks 403 404 503 HTTP 200
revolut.com.85811[.]app/104 45 25 19 0 0
revolut.com.85811[.]app/ 45 18 26 0 0
revolut.com.85811[.]app/ invented path 45 16 28 0 0
revolut.com.03910[.]app/ 25 16 9 0 0
revolut.com.292019[.]app/ 25 14 9 0 0
revolut.com.69281[.]app/ 25 0 0 24 0
revolut.com.85811[.]app/104 repeated 25 8 17 0 0

Three things follow from that table. The root path returns 404 on nodes that get past the edge, and so does a path we invented, so the 404 is not telling us that one URL happens to be missing. revolut.com.69281[.]app, the host on DDoS-Guard's own range, returned 503 from every node, so its origin is not answering at all. And the same host and path, checked twice about an hour apart, moved from 25 blocks and 19 passes to 8 blocks and 17 passes.

The clearest evidence sits below the country level. In a single run, against a single URL, these cities returned both outcomes from different nodes:

City Country Result
Moscow Russia one node blocked, another passed
Tehran Iran one node blocked, another passed
Shiraz Iran one node blocked, another passed
Istanbul Turkey one node blocked, another passed
Jakarta Indonesia one node blocked, another passed

Two machines in Moscow, the same second, the same URL, different answers. Whatever the edge is deciding on, it is not the country the request came from.

From our own address the result is equally flat. The response is byte-identical across iPhone, Android, desktop Chrome and plain curl user agents, and with Accept-Language set to Estonian and to Russian. Only the source address changes anything.

Disclosure about our vantage point. Our own requests originate from an Egyptian IP, so every 403 we recorded directly means 403 from Egypt. We tried to re-test through residential exits in Estonia and Russia, the two languages in the SMS thread, but the proxy available to us could not establish HTTPS tunnels from our network at all, failing equally against a control host. The 26-country sweep is what replaced it.

So what is this infrastructure doing? It is registered, certificated, put behind a commercial DDoS provider, and actively expanded, with four domains added on 17 September. Yet it served no content to any observer we could arrange. We can think of three explanations and cannot separate them: it is staged ahead of a sending burst, it is gated behind something in the original SMS link that we do not hold in un-redacted form, or it has already been burned and the hosting has not been torn down. We report the measurement rather than pick one.

For anyone reproducing this. A 403 or 404 here is not evidence that a host is gone or that a report was actioned. The domains remain registered, the certificates remain valid, and the nameservers still answer. Judge these hosts by their registration and DNS, not by what they return to you.

The timeline: the phishing predates the breach

Placing first-seen dates against the public reporting produces the finding we did not expect.

Date Domains Running total
19 Jul 2026 9285.app 1
20 Jul 2026 48654.app, 49565.app 3
23 to 27 Jul 2026 328102.app, 298201.app, 39451.app, 75684.app 7
5 Aug 2026 78381.app, 78431.app, 85910.app 10
13 Aug 2026 43981.app, 49018.app, 69281.app 13
22 Aug 2026 292019.app, 347591.app 15
27 Aug 2026 48291.app, 78491.app 17
31 Aug 2026 168192.app, 328192.app 19
3 to 7 Sep 2026 57482, 64412, 29401, 38291, 45392, 74311, 79201, 85811 27
11 Sep 2026 61510.app, 93810.app 29
12 Sep 2026 Breach first reported publicly
14 Sep 2026 03910, 54810, 69011, 69759 33
17 Sep 2026 48182, 50912, 55810, 79019 37
Cumulative chart of 37 Revolut phishing hostnames first seen between 19 July and 17 September 2026. A marker at 12 September, when the breach was reported, sits at 29; only eight hostnames follow it.
Figure 5. The campaign was already two months old when the breach was reported. Twenty-nine of the 37 hostnames predate 12 September, which rules out the news as its cause.

Twenty-nine of the 37 hostnames existed before anyone reported the disclosure, the earliest by almost two months. The tidy narrative, that criminals read the news and spun up a Revolut campaign, is not what the data shows.

Inference, and we want to be careful here. A campaign predating the reporting does not show that the operator had the breached data, and it does not connect them to the breach at all. Revolut-branded smishing is constant background activity. What the dates rule out is causation by the news coverage. The acceleration after 12 September is real but modest: eight new hostnames in the five days after the report, against a run rate that was already producing two to four a week since July.

Turnover, and why hostname takedowns lose

Fourteen of the 37 are already dead, including 93810[.]app, the host named in the SMS. That message was captured and reported, and by the time anyone could act on the hostname it had stopped resolving, while twenty-three siblings kept running.

Cluster Checked Status
revolut.com.<digits>.app 37 hostnames 23 live, 14 NXDOMAIN
revolut.com.<digits>.top 100,000 enumerated Nothing on campaign infrastructure
chatwithrevolut.com plus m, www, mail, webmail 6 All NXDOMAIN
transactionrevolut.com plus m, www 3 All NXDOMAIN
informationrevolut.com 1 NXDOMAIN
news-revolut.com and www 2 Live, HTTP 200, Namecheap 66.29.148.123
admin.chat-revolut.com 1 Live, HTTP 200, Cloudflare 172.67.140.198
urbanrevolut.com 1 Live, HTTP 200, Cloudflare 162.159.143.30

We ran the same 100,000-candidate enumeration against .top on the theory that the operator might be rotating TLDs. Nothing came back on either campaign range. The .top answers that did resolve, 7,816 of them, are parking and CDN wildcards.

This is the operational point. A takedown process keyed to individual hostnames is chasing something with a shelf life of weeks against an operator registering replacements faster than reports clear. The registrar, the nameservers and the two ranges outlive every hostname inside them, and they are what a report should name.

Is this one operator or a common technique?

Both, and the distinction matters for attribution.

The shape is in wide use. Wildcard searches return 54 hostnames of the paypal.com.<label>.app form, 18 for Chase, 8 for Santander and 6 for Wise, some going back to 2018. Brand-as-subdomain against financial services is not new, and the same index shows revolut.com.<domain> abuse running since at least 2021, including a transaction3dsecure family across seven TLDs.

But none of those other-brand hostnames resolve into 186.2.175.0/24 or 185.178.208.0/24. We resolved all 87 of them and checked. The technique is shared; this infrastructure is not. On the evidence we have, this is a Revolut-focused operation rather than a multi-brand kit, and we found nothing linking it to the historical clusters.

The same trick on somebody else's platform

One hostname in the supplied list does not follow the pattern. revolut.base44[.]app resolves to 216.24.57.18, attributed to Render, and answers HTTP 200. The apex base44.app returns 404, the signature of a platform giving each application its own subdomain.

According to the screenshot supplied to us, the page presents a Revolut-branded "Complete Your Registration" flow offering a £500 gift card for an email address and completing "3-5 sponsored deals". We did not inspect the page ourselves.

Inference. This reads as affiliate or survey fraud rather than credential harvesting, and brand overlap alone is not enough to attribute it to the same operator.

It belongs here because it is the same structural move on a legitimate platform. There is no registrar to report to, no registration to age, and no suspicious hosting to correlate: the hostname inherits the platform's reputation entirely. The abuse contact is the platform.

Fake Revolut fraud-team calls

Alongside the SMS wave, community reports describe voice phishing callers impersonating Revolut over Google Meet from ordinary Gmail addresses.

A Google Meet contact card showing a generic Gmail address with a Revolut card photograph as the profile picture, offering audio and video call buttons.
Figure 6. A reported scam caller. The only Revolut element is the profile photograph; the account is a consumer Gmail address. Supplied as a community report and not independently verified.

The branding on this Revolut scam is one profile picture of a card. Everything else is a free consumer account, which is the tell: a bank's outbound calling does not come from a Gmail address on a consumer video product.

Revolut's own fraud and scam guidance is the useful test, and the signal it leads with is the one this campaign depends on: "Do you feel rushed? Scammers often create a sense of urgency." Its advice for a suspected incident is to act inside the app, changing your passcode and reporting through in-app support, rather than responding on whatever channel reached you.

How to detect this class of campaign

Query certificate data by pattern, not by domain. The single highest-value change. If your monitoring watches revolut.com and its subdomains it cannot match revolut.com.03910[.]app. You need a rule that fires on the brand appearing anywhere in a SAN, and you need to accept the false positives that come with it.

Use more than one certificate index. crt.sh returning nothing for four of four campaign domains is not a hypothetical. Cross-check before concluding that nothing is there.

Combine enumeration with pattern search, and expect both to be short. Our two methods agreed on only twelve of thirty-seven hostnames. Run both, take the union, and treat the result as a floor.

Alert on the shape, not the brand list. A phishing domain whose leftmost labels spell a known brand and whose registrable domain is a numeric or random string under a generic TLD is worth flagging on structure alone. That rule catches the next campaign as well as this one, and it does not care how many digits the operator uses.

Pivot on registrar and nameserver. Continuous domain monitoring makes this cheap: one registrar and one DNS provider across every domain we checked. Those two fields cluster the campaign more reliably than anything in the hostname, and they survive the rotation.

Read the 403 body, then test whether the label is true. The body usually names a mechanism, and here DDoS-Guard's template is called geoblocked. Checking it from 32 countries showed responses varying between nodes in one city and within an hour, which is not what a national block looks like. Treat the label as a hypothesis, test it from several vantage points, and record where you tested from.

Indicators of compromise

These indicators of compromise are defanged. Every host below resolves and presents a valid Let's Encrypt certificate whose SAN contains the hostname shown. All returned 403 or 404 to us, never page content. Confidence is High throughout except where noted.

Live on `186.2.175.0/24`, 19 September 2026

Hostname Resolves to First seen
revolut.com.292019[.]app 186.2.175.166 22 Aug 2026
revolut.com.347591[.]app 186.2.175.174 22 Aug 2026
revolut.com.78491[.]app 186.2.175.140 27 Aug 2026
revolut.com.168192[.]app 186.2.175.218 31 Aug 2026
revolut.com.328192[.]app 186.2.175.243 31 Aug 2026
revolut.com.57482[.]app 186.2.175.210 3 Sep 2026
revolut.com.64412[.]app 186.2.175.194 3 Sep 2026
revolut.com.29401[.]app 186.2.175.250 5 Sep 2026
revolut.com.45392[.]app 186.2.175.253 6 Sep 2026
revolut.com.74311[.]app 186.2.175.137 6 Sep 2026
revolut.com.79201[.]app 186.2.175.167 7 Sep 2026
revolut.com.85811[.]app 186.2.175.222 7 Sep 2026
revolut.com.61510[.]app 186.2.175.248 11 Sep 2026
revolut.com.03910[.]app 186.2.175.249 14 Sep 2026
revolut.com.54810[.]app 186.2.175.156 14 Sep 2026
revolut.com.69011[.]app 186.2.175.242 14 Sep 2026
revolut.com.69759[.]app 186.2.175.253 14 Sep 2026
revolut.com.48182[.]app 186.2.175.133 17 Sep 2026
revolut.com.50912[.]app 186.2.175.149 17 Sep 2026
revolut.com.55810[.]app 186.2.175.133 17 Sep 2026
revolut.com.79019[.]app 186.2.175.182 17 Sep 2026

Live on `185.178.208.0/24`

Hostname Resolves to First seen Note
revolut.com.69281[.]app 185.178.208.152 13 Aug 2026 TLS handshake failed at time of test
revolut.com.43981[.]app 185.178.208.155 13 Aug 2026 TLS handshake failed at time of test

Retired, no longer resolving

Hostname First seen
revolut.com.9285[.]app 19 Jul 2026
revolut.com.48654[.]app, revolut.com.49565[.]app 20 Jul 2026
revolut.com.328102[.]app 23 Jul 2026
revolut.com.298201[.]app 24 Jul 2026
revolut.com.39451[.]app, revolut.com.75684[.]app 27 Jul 2026
revolut.com.78381[.]app, revolut.com.78431[.]app, revolut.com.85910[.]app 5 Aug 2026
revolut.com.49018[.]app 13 Aug 2026
revolut.com.48291[.]app 27 Aug 2026
revolut.com.38291[.]app 5 Sep 2026
revolut.com.93810[.]app 11 Sep 2026, named in the SMS lure

Infrastructure

Indicator Type Source
186.2.175.0/24 Primary hosting range Directly resolved
AS59692, IQWeb FZ-LLC, [email protected] Announcing AS and abuse contact RIPE RDAP, Team Cymru
185.178.208.0/24 Secondary hosting range Directly resolved
AS57724, DDOS-GUARD LTD, RU Announcing AS RIPE whois, Team Cymru
ns1.ddos-guard.net, ns2.ddos-guard.net Nameservers, all 24 domains checked Registry RDAP
NiceNIC International Group, [email protected] Registrar, all 24 domains checked Registry RDAP

Adjacent, unrelated hosting

Indicator Status Source
chatwithrevolut[.]com, transactionrevolut[.]com, informationrevolut[.]com and their subdomains Retired, NXDOMAIN Directly resolved
news-revolut[.]com, urbanrevolut[.]com, admin.chat-revolut[.]com Live, HTTP 200 Directly resolved
revolut.base44[.]app Live on a legitimate platform, different monetisation Resolved, HTTP 200

What Revolut customers should do

If you received the message. Do not follow the link. Open the Revolut app directly and check your account there. The app is the only channel that authenticates itself to you.

If you followed it and entered something. Treat the credential as disclosed. Change it in the app, review recent activity and card permissions, and report it through in-app support. If you supplied a one-time code, say so explicitly, because a disclosed code means an attempted transaction rather than merely an exposed password.

If someone called you. A caller on Google Meet from a Gmail address is not the bank. Hang up, then open the app and use in-app support to check whether anyone from Revolut was trying to reach you. Revolut's guidance on reporting fraud runs entirely through the app, which is the point: the app is the one channel an impersonator cannot stand in front of.

How to identify a fake Revolut text. Four checks that work against this campaign:

  1. Read the address backwards. Find the last two labels before the first single slash. In revolut.com.93810[.]app/ that is 93810.app, and that is the site you are on. Everything to its left is decoration the sender chose.
  2. Ignore the thread. A scam text lands beside genuine login codes under the same sender name, as Figure 3 shows. Position in a conversation proves nothing.
  3. Ignore the padlock. Every host in this report has a valid certificate. It encrypts the connection; it does not vouch for the owner.
  4. Distrust the deadline. "Confirm now or access will be restricted" is the whole mechanism, and urgency is the first signal on Revolut's own scam checklist. Open the app instead of acting on the message.

If you handle security awareness. Figure 3 is the training material. Retire any advice that tells people to trust a message because it appeared in an existing thread.

How PhishEye helps

Finding these hostnames took several signals working together, and no single one was enough. Pattern matching over certificate data caught the brand where it sits left of the registrable domain. Namespace enumeration caught four hosts the certificate index had not yet indexed. Correlation on registrar, nameserver and hosting separated 23 real hosts from 9,326 parking wildcards, and liveness checking told us which of the 37 were still serving. That combination is how PhishEye's brand protection monitoring works, and our takedown service handles the registrar, network and platform escalation that has to follow.

Frequently asked questions

What happened in the Revolut data breach? Criminals obtained customer data by sending fraudulent requests from a legitimate government-agency email address. Revolut said its systems were not breached and funds were unaffected, and The Guardian reported an associated ransom demand.

Was Revolut hacked? Revolut confirmed a data disclosure caused by fraudulent requests sent from a legitimate government-agency email address, and said its systems and customer funds were unaffected. That is a failure in request validation rather than an intrusion into banking systems.

I received a suspicious Revolut SMS. What should I do? Do not tap the link. Open the Revolut app directly and check your account there. You can report the message through in-app support. If you want to verify the link first, read it backwards to the last two labels before the first slash, which is the real site.

What should I do if I already clicked a Revolut phishing link and entered details? Treat whatever you typed as disclosed. Change it in the app, review recent activity and card permissions, and report it through in-app support. If you entered a one-time code, say so explicitly, because that means someone was attempting a transaction at that moment rather than simply collecting a password.

Did the phishing campaign use the breached data? Not established, and the timeline argues against the simple version. Twenty-nine of the 37 hostnames existed before the disclosure was reported, the earliest by almost two months. We found nothing connecting these operators to the breach.

Why did Certificate Transparency monitoring not catch this? It could have. The brand is in every certificate's SAN and the certificates are logged. Two things got in the way: brand monitoring usually matches a domain and its subdomains, which cannot match revolut.com.03910[.]app, and crt.sh does not return these certificates at all.

Is crt.sh unreliable? It is an enormously useful free service and we use it constantly. The finding is narrower: it returned no post-August 2026 certificates for four of four campaign domains we could test cleanly, while two other indexes returned them at once. A negative result from any single index should not be read as "no certificate exists".

Is .app a dangerous TLD? No. .app is on the HSTS preload list as a whole TLD, which is a security benefit. What matters is that the registrable domains are meaningless numeric strings, which is cheap and forgettable by design, and that one registrar sold all of them.

Did you actually see a phishing page? No, and we want to be clear about that. Across 235 checks from 45 vantage points in 32 countries we recorded only 403, 404 and 503 responses, never content. The hosts are live infrastructure with valid certificates; whether any is currently serving a phishing page is something our measurements cannot establish.

Is the campaign geo-blocked? DDoS-Guard serves a template it calls geoblocked, but we could not confirm country-level filtering. The 403 and 404 responses vary between nodes in the same country and shift within an hour, which a national block would not do.

Is the padlock meaningful? It confirms the connection is encrypted and that the certificate matches the hostname. It says nothing about who is on the other end. Every live host in this report has a valid certificate.

Is base44.app malicious? No. It appears to be a platform giving applications their own subdomains, and one application on it carries Revolut branding. Platforms like that are abused routinely, and the right response is a report to the platform rather than treating the platform as hostile.

References

Primary and technical sources

Reporting

← Back to blog