Yesterday I received an SMS from my home insurance company saying that
they had registered my claim, go and see it at this link. The URL seems
the real one, at least visually.
But I had not put any claim, and the site asked for my login/pass. I suspected.
Today I entered the insurance site from my records. No claims listed. I
saw a chat (computer trouble) and I asked. They said it is probably
phising, delete it. Phone the insurance to ask if I have some pending
claim if in doubt.
So, the thing is they impersonated the sender. I don't know what is
wrong in the URL. I have the suspicion that RCS, as it works with certificates, could avoid or signal these troubles.
If you a curious, this is the SMS:
«Se ha dado de alta su siniestro 01202600362123, si lo desea realice su seguimiento en https://oau.ocaso.es/qmVki-fOZ»
www.ocaso.es is the real, actual URL.
www.ocaso.es is the real, actual URL.
«Se ha dado de alta su siniestro 01202600362123, si lo desea realice su seguimiento en https://oau.ocaso.es/qmVki-fOZ»
www.ocaso.es is the real, actual URL.
"Carlos E. R." <robin_listas@es.invalid> wrote:
Yesterday I received an SMS from my home insurance company saying that
they had registered my claim, go and see it at this link. The URL seems
the real one, at least visually.
But I had not put any claim, and the site asked for my login/pass. I
suspected.
Today I entered the insurance site from my records. No claims listed. I
saw a chat (computer trouble) and I asked. They said it is probably
phising, delete it. Phone the insurance to ask if I have some pending
claim if in doubt.
So, the thing is they impersonated the sender. I don't know what is
wrong in the URL. I have the suspicion that RCS, as it works with
certificates, could avoid or signal these troubles.
If you a curious, this is the SMS:
«Se ha dado de alta su siniestro 01202600362123, si lo desea realice su
seguimiento en https://oau.ocaso.es/qmVki-fOZ»
www.ocaso.es is the real, actual URL.
The URL may look correct to your eyes, but it could by using IDN (Internationalized Domain Name) encoding, like UTF-8, which allows more
than the ASCII charset in a URL. With the IDN charset, there are lots
of look-alike characters facilitating a homograph attack. IDN URLs are valid, but too often used by scammers to make a URL look like it's
pointing to a legit domain.
https://en.wikipedia.org/wiki/Internationalized_domain_name
https://en.wikipedia.org/wiki/Punycode
Chrome and Edge (a Chromium derivative) will show the punycode version
of an IDN URL to prevent homograph attacks. In Firefox, you have to
edit a punycode setting in about:config:
network.IDN_show_punycode = true
Sometimes Firefox will show the punycode version of an IDN URL,
sometimes not.
https://wiki.mozilla.org/IDN_Display_Algorithm
When I used Firefox, I didn't want a guessing game on the URLs. In set
the punycode option in about:config to always show punycode. I'm in the
uSA, and there is no place I visit that would need to use UTF-8, or
anything other than ASCII, in its URLs even when visiting sites in other countries. However, you're in Spain, I think, and IDNs are more common
in other countries.
Or they used the old trick of look-alike ASCII characters, like 1 (one)
and l (el) looking similar, especially when inside a string.
When you copy & paste the suspicious URL, we see what you see, not that actual encoding of an IDN URL.
You mention you got the URL in an SMS text. I don't recall any SMS or
e-mail app showing punycode instead of IDN, except with e-mail you might
be able to look at the raw source. So, the only way you could tell it
was a phishing website using IDNs would be to click on the URL to see
what the address bar shows in the web browser.
Carlos E. R. wrote:
www.ocaso.es is the real, actual URL.
I don't know whether RCS can 'hide' the URL like html can, e.g.
<a href='http://scam.site'>
http://good.site
where the good.site is for display purposes only
VanguardLH wrote:You can add missing settings
Chrome and Edge (a Chromium derivative) will show the punycode version
of an IDN URL to prevent homograph attacks. In Firefox, you have to
edit a punycode setting in about:config:
network.IDN_show_punycode = true
No such setting.
Carlos E. R. <robin_listas@es.invalid> wrote:
«Se ha dado de alta su siniestro 01202600362123, si lo desea realice su
seguimiento en https://oau.ocaso.es/qmVki-fOZ»
www.ocaso.es is the real, actual URL.
The shortcode is interesting - I wonder if it's a redirector that's been hacked in some way. ie in a similar way that https://bit.ly/abc123 could be a
redirect to https://evil.site/, anyone who controls the redirector can forward links to their chosen site. That part of their website
may be less well defended than the part that deals with money. Maybe it has since been fixed to redirect back to the right place?
Although for me it redirects to: https://clientes.ocaso.es/#/login?utm_source=giso&utm_medium=sms&utm_campaign=alta-siniestro
The utm_ parts are typically a referrer codes used in tracking, for
example commissions for advertising. 'alta-siniestro' is 'claim registration' and utm_medium=sms, so it sounds like a genuine link.
Or perhaps somebody in operations had fat fingers and sent SMSes to the
wrong people?
Carlos E. R. wrote:
VanguardLH wrote:You can add missing settings
Chrome and Edge (a Chromium derivative) will show the punycode version
of an IDN URL to prevent homograph attacks. In Firefox, you have to
edit a punycode setting in about:config:
network.IDN_show_punycode = true
No such setting.
On 2026-06-18 12:38, Theo wrote:
Carlos E. R. <robin_listas@es.invalid> wrote:
«Se ha dado de alta su siniestro 01202600362123, si lo desea realice su >> seguimiento en https://oau.ocaso.es/qmVki-fOZ»
www.ocaso.es is the real, actual URL.
The shortcode is interesting - I wonder if it's a redirector that's been hacked in some way. ie in a similar way that https://bit.ly/abc123 could be a
redirect to https://evil.site/, anyone who controls the redirector can forward links to their chosen site. That part of their website
may be less well defended than the part that deals with money. Maybe it has
since been fixed to redirect back to the right place?
Although for me it redirects to: https://clientes.ocaso.es/#/login?utm_source=giso&utm_medium=sms&utm_campaign=alta-siniestro
The utm_ parts are typically a referrer codes used in tracking, for
example commissions for advertising. 'alta-siniestro' is 'claim registration' and utm_medium=sms, so it sounds like a genuine link.
Or perhaps somebody in operations had fat fingers and sent SMSes to the wrong people?
There is an extra data point. I logged to www.ocaso.es from my boomarked link, logged in normally, and then opened the suspect site on another
tab. In this situation, the second tab, if genuine, should recognize
that I'm already logged in, and proceed. But instead it asked for my
login credentials.
VanguardLH wrote:
Chrome and Edge (a Chromium derivative) will show the punycode version
of an IDN URL to prevent homograph attacks. In Firefox, you have to
edit a punycode setting in about:config:
network.IDN_show_punycode = true
No such setting.
On 2026-06-18 12:38, Theo wrote:
Carlos E. R. <robin_listas@es.invalid> wrote:
«Se ha dado de alta su siniestro 01202600362123, si lo desea realice su >>> seguimiento en https://oau.ocaso.es/qmVki-fOZ»
www.ocaso.es is the real, actual URL.
The shortcode is interesting - I wonder if it's a redirector that's been
hacked in some way. ie in a similar way that https://bit.ly/abc123 could be a
redirect to https://evil.site/, anyone who controls the redirector can
forward links to their chosen site. That part of their website
may be less well defended than the part that deals with money. Maybe it has >> since been fixed to redirect back to the right place?
Although for me it redirects to:
https://clientes.ocaso.es/#/login?utm_source=giso&utm_medium=sms&utm_campaign=alta-siniestro
The utm_ parts are typically a referrer codes used in tracking, for
example commissions for advertising. 'alta-siniestro' is 'claim
registration' and utm_medium=sms, so it sounds like a genuine link.
Or perhaps somebody in operations had fat fingers and sent SMSes to the
wrong people?
There is an extra data point. I logged to www.ocaso.es from my boomarked link, logged in normally, and then opened the suspect site on another
tab. In this situation, the second tab, if genuine, should recognize
that I'm already logged in, and proceed. But instead it asked for my
login credentials.
Yesterday I received an SMS from my home insurance company saying that
they had registered my claim, go and see it at this link. The URL seems
the real one, at least visually.
But I had not put any claim, and the site asked for my login/pass. I >suspected.
Today I entered the insurance site from my records. No claims listed. I
saw a chat (computer trouble) and I asked. They said it is probably
phising, delete it. Phone the insurance to ask if I have some pending
claim if in doubt.
So, the thing is they impersonated the sender. I don't know what is
wrong in the URL. I have the suspicion that RCS, as it works with >certificates, could avoid or signal these troubles.
"Carlos E. R." <robin_listas@es.invalid> wrote:
VanguardLH wrote:
Chrome and Edge (a Chromium derivative) will show the punycode version
of an IDN URL to prevent homograph attacks. In Firefox, you have to
edit a punycode setting in about:config:
network.IDN_show_punycode = true
No such setting.
A setting not defined results in using its default setting. If you want
to change its setting, but it is not currently defined, you have to
create it to give it a different setting.
https://kb.mozillazine.org/Network.IDN_show_punycode
I suggested IDNs could be used for phishing, but that's not the only way
to fake URLs.
The company may have no one there knowledgeable about their website.--
Could be a hiccup on their end that generated a bogus message. I've
gotten those from my health plan. An e-mail tells me an appointment got cancelled, but when I check at the website the appointment is still
listed. Then later I get another e-mail telling me the cancellation
notice was erroneous, and to ignore it. When I called the clinic, they
said the appointment was still scheduled, and had no idea why I got the cancellation notice. Same for my pharmacy: when there is a problem with their website, the pharmacy store has no clue about their website, no
one there can help, and they don't know who to contact. Some joker for
their website made a change which caused the fuck up, but most times it
isn't caught.
Sometimes they get accounts wrong. The SMS text you showed only
mentioned a claim number. No other identifying patient info, like
account number, or your name. I've gotten texts from my car dealer
saying they're done with the lube job, and to come pick up my vehicle,
except I never dropped off my vehicle at their shop. It's still still sitting in my garage. They sent the text to the wrong phone number. I
got someone else's notice.
"Carlos E. R." <robin_listas@es.invalid> wrote:
On 2026-06-18 12:38, Theo wrote:
Carlos E. R. <robin_listas@es.invalid> wrote:
«Se ha dado de alta su siniestro 01202600362123, si lo desea realice su >>>> seguimiento en https://oau.ocaso.es/qmVki-fOZ»
www.ocaso.es is the real, actual URL.
The shortcode is interesting - I wonder if it's a redirector that's been >>> hacked in some way. ie in a similar way that https://bit.ly/abc123 could be a
redirect to https://evil.site/, anyone who controls the redirector can
forward links to their chosen site. That part of their website
may be less well defended than the part that deals with money. Maybe it has
since been fixed to redirect back to the right place?
Although for me it redirects to:
https://clientes.ocaso.es/#/login?utm_source=giso&utm_medium=sms&utm_campaign=alta-siniestro
The utm_ parts are typically a referrer codes used in tracking, for
example commissions for advertising. 'alta-siniestro' is 'claim
registration' and utm_medium=sms, so it sounds like a genuine link.
Or perhaps somebody in operations had fat fingers and sent SMSes to the
wrong people?
There is an extra data point. I logged to www.ocaso.es from my boomarked
link, logged in normally, and then opened the suspect site on another
tab. In this situation, the second tab, if genuine, should recognize
that I'm already logged in, and proceed. But instead it asked for my
login credentials.
Another tab seeing you have the same session ID should not request
another login if the webdev did the proper coding.
As I recall for Firefox to see the session ID, hit F12 -> Storage ->
Cookies. You could check if the session ID is the same for both tabs. Session cookies are reusable at the same domain. I don't know if that
is true for subdomains (www versus oau).
Firefox can purge cookies on
its exit, but you aren't exiting. An add-on that putzes with cookies,
like expire them instead of the web browser doing that, could interfere
with using session cookies.
If you use Private Browsing, a new session ID gets generated. That's
how you can use Private Browsing to log in multiple times to a website.
Did you open 1 tab only in Firefox, navigate to the website, login, open
a 2nd tab in Firefox, and check if you are prompted to login again?
Did you disable all add-ons in Firefox? If you still get a login prompt--
in every tab you open to a website where you already logged in, and
disabling add-ons did not help, use a fresh Firefox profile to eliminate
all add-ons, all about:config tweaks, userchrome.css, or anything else
you've done under your normal profile to modify Firefox. With a fresh Firefox profile, test if a 2nd tab still asks for a login when you have already logged in using the 1st tab.
My main question is if companies switching to sending RCS instead of SMS >would avoid impersonating the sender, because RCS uses certificates. On
the other hand, one certificate exchange per client in the database...
On 6/18/26 10:00 AM, Carlos E. R. wrote:
My main question is if companies switching to sending RCS instead of
SMS would avoid impersonating the sender, because RCS uses
certificates. On the other hand, one certificate exchange per client
in the database...
Just recently I got a voice message from American Express. It went to VM because I had DND on. It sounded like a live person who gave her first name and wanted to verify a large charge. She requested a call back and gave a phone number. Being the suspicious person that I am I used the number on
the back of my card which was different. It turned out that the call was legitimate as was the charge in question.
But IMO how dumb of AMEX to use a system like that. Anybody could call, say they were AMEX, and give any number to call back and if successful scam you good.
BTW the charge was US$15K (for a new roof) so I can perhaps see why they questioned it. But I pay off the card every month so no extra cost for me
and in this case the card cashback feature paid handsomely...
My main question is if companies switching to sending RCS instead of SMS would avoid impersonating the sender, because RCS uses certificates. On
the other hand, one certificate exchange per client in the database...
At this point, I don't think you got phished. I think your dental
provider had a hiccup in their accounting system
www.ocaso.es is the real, actual URL.
"Carlos E. R." <robin_listas@es.invalid> wrote:
My main question is if companies switching to sending RCS instead of SMS
would avoid impersonating the sender, because RCS uses certificates. On
the other hand, one certificate exchange per client in the database...
From what I've found about RCS, yes, it uses encryption to secure the messages. That's just encryption, not identification. I've heard about
RCS spam for quite a while. I doubt spammers want to be exposed.
At this point, I don't think you got phished. I think your dental
provider had a hiccup in their accounting system, or someone there
entered the wrong account in the notice you got. The text you got only mentions a claim number, not your name, account number, or any other identifying information of your business with them. Adding identifying
info in a text would make it larger, and they may be restricting their
texts to the old 160-character limit of SMS.
Was the bogus message sent using RCS, or just SMS?
RCS messages should
show Encrypted with a padlock icon at the top. Some will show RCS
messages in a differently colored bubble. Some show a shield icon with
a checkmark. Apple's iMessage shows a "<padlock> Encrypted" at the top
of an RCS message. How to differentiate SMS from RCS depends on which messaging app you use.
<Aside - Read Receipts>
VanguardLH wrote:
At this point, I don't think you got phished. I think your dental
provider had a hiccup in their accounting system
Dental? I though it was an insurance company ...
On 18.06.26 10:01, Carlos E. R. wrote:
www.ocaso.es is the real, actual URL.
I hope not: It even has no SSL-encryption.
On 2026-06-19 09:13, Jörg Lorenz wrote:
On 18.06.26 10:01, Carlos E. R. wrote:Yes, it has. It is https.
www.ocaso.es is the real, actual URL.
I hope not: It even has no SSL-encryption.
On 19.06.26 12:13, Carlos E. R. wrote:
On 2026-06-19 09:13, Jörg Lorenz wrote:
On 18.06.26 10:01, Carlos E. R. wrote:Yes, it has. It is https.
www.ocaso.es is the real, actual URL.
I hope not: It even has no SSL-encryption.
Check you own link by hovering witht the cursor.
Jörg Lorenz <hugybear@gmx.net> wrote:
On 19.06.26 12:13, Carlos E. R. wrote:
On 2026-06-19 09:13, Jörg Lorenz wrote:
On 18.06.26 10:01, Carlos E. R. wrote:Yes, it has. It is https.
www.ocaso.es is the real, actual URL.
I hope not: It even has no SSL-encryption.
Check you own link by hovering witht the cursor.
There was no link, there was just the string www.ocaso.es:
00000600 0a 0a 77 77 77 2e 6f 63 61 73 6f 2e 65 73 20 69 |..www.ocaso.es i|
00000610 73 20 74 68 65 20 72 65 61 6c 2c 20 61 63 74 75 |s the real, actu|
00000620 61 6c 20 55 52 4c 2e 0a 0a 2d 2d 20 0a 43 68 65 |al URL...-- .Che|
00000630 65 72 73 2c 0a 20 20 20 20 20 20 20 20 43 61 72 |ers,. Car|
00000640 6c 6f 73 20 45 2e 52 2e 0a 20 20 20 20 20 20 20 |los E.R.. |
Usenet is plain text, so there is no markup behind the scenes. If the OP didn't write http:// then it wasn't there.
On 19.06.26 12:13, Carlos E. R. wrote:
On 2026-06-19 09:13, Jörg Lorenz wrote:
On 18.06.26 10:01, Carlos E. R. wrote:Yes, it has. It is https.
www.ocaso.es is the real, actual URL.
I hope not: It even has no SSL-encryption.
Check you own link by hovering witht the cursor.
Jörg Lorenz <hugybear@gmx.net> wrote:
On 19.06.26 12:13, Carlos E. R. wrote:
On 2026-06-19 09:13, Jörg Lorenz wrote:
On 18.06.26 10:01, Carlos E. R. wrote:Yes, it has. It is https.
www.ocaso.es is the real, actual URL.
I hope not: It even has no SSL-encryption.
Check you own link by hovering witht the cursor.
There was no link, there was just the string www.ocaso.es:
00000600 0a 0a 77 77 77 2e 6f 63 61 73 6f 2e 65 73 20 69 |..www.ocaso.es i|
00000610 73 20 74 68 65 20 72 65 61 6c 2c 20 61 63 74 75 |s the real, actu|
00000620 61 6c 20 55 52 4c 2e 0a 0a 2d 2d 20 0a 43 68 65 |al URL...-- .Che|
00000630 65 72 73 2c 0a 20 20 20 20 20 20 20 20 43 61 72 |ers,. Car|
00000640 6c 6f 73 20 45 2e 52 2e 0a 20 20 20 20 20 20 20 |los E.R.. |
Usenet is plain text, so there is no markup behind the scenes. If the OP didn't write http:// then it wasn't there.
If your client decided to turn that www... string into a http:// link that your (client's) problem. Arguably it should turn it into an https:// link nowadays.
VanguardLH wrote:
At this point, I don't think you got phished. I think your dental
provider had a hiccup in their accounting system
Dental? I though it was an insurance company ...
Andy Burns <usenet@andyburns.uk> wrote:
VanguardLH wrote:
At this point, I don't think you got phished. I think your dental
provider had a hiccup in their accounting system
Dental? I though it was an insurance company ...
An insurance company of WHAT? Could be health insurance, dental
insurance, car insurance, life insurance, etc. "Insurance" does specify
what type of insurance, and many insurers cover many types of coverage.
At https://www.ocaso.es/inicio (their home page), that navbar at the top
has the following entries (translated to English):
Home Deaths Life Health Savings and Investment Other Insurance
When I went digging there, somehow I ended up landing at https://www.ocaso.es/servicios/servicio-dental. So, his dentist's
office billed his dental insurer, and the dental insurer billed him.
Or, it could've been any of the other types of insurance covered by
Ocaso. Whether it was some service by someone Carlos uses that
incorrectly billed Ocaso, or Ocaso's hiccup by sending notice to the
wrong insured is something Carlos or Ocaso have to figure out. However, Carlos mention he logged in somehow differently, and did see a claim
there. The claim at Ocaso should show who submitted it. That Carlos
might remember he did have service there, or it somewhere he never had service.
Carlos said elsewhere:--
"The insurance claim was true, just assigned to the wrong ID. It was legitimate, but they have a bad software system. This was explained on another message here."
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,124 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 23:46:00 |
| Calls: | 14,394 |
| Calls today: | 3 |
| Files: | 186,389 |
| D/L today: |
5,548 files (1,400M bytes) |
| Messages: | 2,544,979 |
| Posted today: | 1 |