Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #154209 > unrolled thread

SMS spoofing

Back to article view | Back to comp.mobile.android

Contents

  SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-18 10:01 +0200
    Re: SMS spoofing VanguardLH <V@nguard.LH> - 2026-06-18 03:36 -0500
      Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-18 14:04 +0200
        Re: SMS spoofing Andy Burns <usenet@andyburns.uk> - 2026-06-18 13:07 +0100
          Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-18 14:18 +0200
        Re: SMS spoofing VanguardLH <V@nguard.LH> - 2026-06-18 08:40 -0500
          Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-18 19:00 +0200
            Re: SMS spoofing AJL <noemail@none.com> - 2026-06-18 18:08 +0000
              Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-18 20:49 +0200
            Re: SMS spoofing VanguardLH <V@nguard.LH> - 2026-06-19 01:05 -0500
              Re: SMS spoofing Andy Burns <usenet@andyburns.uk> - 2026-06-19 07:46 +0100
                Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-19 12:12 +0200
                Re: SMS spoofing VanguardLH <V@nguard.LH> - 2026-06-20 03:14 -0500
                  Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-20 10:25 +0200
              Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-19 12:11 +0200
    Re: SMS spoofing Andy Burns <usenet@andyburns.uk> - 2026-06-18 10:13 +0100
      Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-18 14:05 +0200
    Re: SMS spoofing Theo <theom+news@chiark.greenend.org.uk> - 2026-06-18 11:38 +0100
      Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-18 14:10 +0200
        Re: SMS spoofing Philippe <p.naudin+nntp@free.fr> - 2026-06-18 14:48 +0200
        Re: SMS spoofing VanguardLH <V@nguard.LH> - 2026-06-18 08:57 -0500
          Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-18 19:14 +0200
    Re: SMS spoofing AJL <noemail@none.com> - 2026-06-18 15:56 +0000
    Re: SMS spoofing Jörg Lorenz <hugybear@gmx.net> - 2026-06-19 09:13 +0200
      Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-19 12:13 +0200
        Re: SMS spoofing Jörg Lorenz <hugybear@gmx.net> - 2026-06-19 14:16 +0200
          Re: SMS spoofing Theo <theom+news@chiark.greenend.org.uk> - 2026-06-19 17:22 +0100
            Re: SMS spoofing Jörg Lorenz <hugybear@gmx.net> - 2026-06-19 21:23 +0200
            Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-20 01:17 +0200
          Re: SMS spoofing "Carlos E. R." <robin_listas@es.invalid> - 2026-06-20 01:14 +0200

Page 1 of 2  [1] 2  Next page →

#154209 — SMS spoofing

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.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [next] | [standalone]

#154210

"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.

[toc] | [prev] | [next] | [standalone]

#154214

On 2026-06-18 10:36, VanguardLH wrote:
> "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.

I know.

> 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

No such setting.

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


It showed the same thing.


cer@Laicolasse:~/Videos/Star Trek TOS> host oau.ocaso.es
oau.ocaso.es has address 195.57.141.20
You have mail in /var/mail/cer
cer@Laicolasse:~/Videos/Star Trek TOS> host ocaso.es
ocaso.es has address 195.57.141.15
ocaso.es mail is handled by 10 alt4.aspmx.l.google.com.
ocaso.es mail is handled by 10 alt3.aspmx.l.google.com.
ocaso.es mail is handled by 5 alt2.aspmx.l.google.com.
ocaso.es mail is handled by 5 alt1.aspmx.l.google.com.
ocaso.es mail is handled by 1 aspmx.l.google.com.
cer@Laicolasse:~/Videos/Star Trek TOS>

cer@Laicolasse:~/Videos/Star Trek TOS> host 195.57.141.20
20.141.57.195.in-addr.arpa is an alias for 20.0.141.57.195.in-addr.arpa.
20.0.141.57.195.in-addr.arpa domain name pointer 
20.red-195-57-141.customer.static.ccgg.telefonica.net.
cer@Laicolasse:~/Videos/Star Trek TOS> host 195.57.141.15
15.141.57.195.in-addr.arpa is an alias for 15.0.141.57.195.in-addr.arpa.
15.0.141.57.195.in-addr.arpa domain name pointer 
15.red-195-57-141.customer.static.ccgg.telefonica.net.
cer@Laicolasse:~/Videos/Star Trek TOS>


The IP is almost valid, like an internal attack


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154216

Carlos E. R. 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.
You can add missing settings

[toc] | [prev] | [next] | [standalone]

#154218

On 2026-06-18 14:07, Andy Burns wrote:
> Carlos E. R. 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.
> You can add missing settings

Tried that, no change. Shows the same URL.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154220

"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.

[toc] | [prev] | [next] | [standalone]

#154223

On 2026-06-18 15:40, VanguardLH wrote:
> "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.

I had typed puni instead of puny. But that changed nothing, the url 
opened normally, and resolves to an IP that can be theirs. It is 
strange, but the message could be legitimate (and wrong).

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

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


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154225

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

[toc] | [prev] | [next] | [standalone]

#154226

On 2026-06-18 20:08, AJL wrote:
> 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.

Yes.

My ISP sends emails advising clients of best practices against scams. Do 
not trust, etc.

Then they send an SMS or an email that breaks the very rules they told 
us. I email them complaining about the practice, and they just don't answer.

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


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154230

"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.

If you used digitally-signed e-mail, anyone that gets your public key
can encrypt their message they send to you, and only you can decrypt
their message using your private key.  The x.509 and PGP schemes do not
secure who gets your public key, just that you're the only one that can
read the encrypted messages.

https://www.enea.com/insights/unmasking-the-security-challenges-of-rich-communication-services/
https://www.darkreading.com/threat-intelligence/lucid-phishing-exploits-imessage-android-rcs
https://censys.com/blog/lucid-phishing-platform-drives-toll-scam-campaigns/

RCS is just a modified messaging platform to which spammers, scammer,
and phishers will adapt.  Encryption is not identification.

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>

With RCS, the sender can request read receipts.  Similar to how they
work with e-mail.  I always disable responding to read receipt request
in my e-mail clients.  None of the sender's business if I read their
e-mail, or not.  Well, did you check read receipts is disabled in
whatever messaging app you use?  It might be called "Send read receipts:
Let others know you've read their message".  I'm using Samsung's bundled
Messages app on my Samsung Galaxy A56 phone, and just checked.  Yep,
read receipts was enabled, so I disabled it.  If that was a phisher's
message, and you have read receipts enabled, you reading their text told
them their message successfully reached you, and you read their message
making you a valuable contact to hit again.  If using Google's Messages
app, see:

https://support.google.com/messages/answer/7189714
"Let others know you've read their messages"

If read receipts is enabled, you might see a single checkmark on your
sent message showing it got delivered.  Two checkmarks mean your sent
message got delivered and read.  If the recipient has read receipts
disabled, they'll still probably be the one checkmark noting delivery.
Delivery only isn't of value to spammers, but delivery and read status
are important as the spammer knows the recipient read their RCS spam
message.

https://www.cnet.com/tech/read-receipts-can-be-a-privacy-risk-on-iphone-or-android-heres-how-to-turn-them-off/

Read reciepts have the same privacy issue whether for e-mail or RCS.  My
attitude is to hide from the sender when I read their e-mail or RCS
message.  None of their business.  Other users might want read receipts
enabled, because those users are more social addicts than I (and they
probably do social sites aka sites for the socially needy whereas I
avoid them).

</Aside - Read Receipts>

[toc] | [prev] | [next] | [standalone]

#154231

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

[toc] | [prev] | [next] | [standalone]

#154235

On 2026-06-19 08:46, Andy Burns 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 ...

It is an insurance company. Someone posted another example with a 
clinic. :-)

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154255

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."

[toc] | [prev] | [next] | [standalone]

#154256

On 2026-06-20 10:14, VanguardLH wrote:
> 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.

Does it mater? :-o


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

Home insurance. No dentist involved anywhere. Actually, someone 
requesting DIY help, which is covered.

> 
> 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."


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154234

On 2026-06-19 08:05, VanguardLH wrote:
> "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.
> 

I have not seen any spam on RCS.

There are certificates exchanged on each pair of people, it is the basis 
of the system discussed in the thread "Android will detect calls with 
spoofed numbers by sending a real-time RCS message to the legitimate owner"

It is not about encryption but identification, signatures.

...

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

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.


> Was the bogus message sent using RCS, or just SMS?

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>

I leave read receipts active on WhatsApp. I don't care if they see I 
have read and not replied. I prefer to know that a message has been read.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154211

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
</a>

where the good.site is for display purposes only

[toc] | [prev] | [next] | [standalone]

#154215

On 2026-06-18 11:13, Andy Burns wrote:
> 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.

RCS can validate the sender. It uses certificates. That is the question.

> 
> <a href='http://scam.site'>
>    http://good.site
> </a>
> 
> where the good.site is for display purposes only
> 
> 


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154213

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?

Theo

[toc] | [prev] | [next] | [standalone]

#154217

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.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154219

Le jeu. 18 juin 2026 14:10:31, Carlos E. R. a écrit:

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

I would bet on a mapping error in ocaso.es website :
oau.ocaso.es redirect (301) to www.ocaso.es/oau and the link fails (404). 
Certificate is OK all the way.

$ LANG=C wget -S https://oau.ocaso.es/
--2026-06-18 14:45:01--  https://oau.ocaso.es/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving oau.ocaso.es (oau.ocaso.es)... 195.57.141.20
Connecting to oau.ocaso.es (oau.ocaso.es)|195.57.141.20|:443... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 301 Moved permanently
  Location: https://www.ocaso.es/oau/
  Connection: close
  Cache-Control: no-cache
  Pragma: no-cache
Location: https://www.ocaso.es/oau/ [following]
--2026-06-18 14:45:02--  https://www.ocaso.es/oau/
Resolving www.ocaso.es (www.ocaso.es)... 195.57.141.15
Connecting to www.ocaso.es (www.ocaso.es)|195.57.141.15|:443... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 404 Not Found
  Date: Thu, 18 Jun 2026 12:45:02 GMT
  Access-Control-Allow-Origin: (null)
  X-Powered-By: Servlet/3.1
  Server-Timing: intid;desc=b796964c12a7552a
  X-Forwarded-For: 93.21.215.230
  X-INSTANA-T: b796964c12a7552a
  X-INSTANA-S: b796964c12a7552a
  X-INSTANA-L: 1
  Vary: Origin,Accept-Encoding,User-Agent,Access-Control-Request-Method,Access-Control-Request-Headers
  Connection: keep-alive, Keep-Alive
  Access-Control-Allow-Headers: routing-view
  Keep-Alive: timeout=5, max=100
  Transfer-Encoding: chunked
  Content-Type: application/json
  Content-Language: en-US
  Set-Cookie: NSC_ESNS=09da8f2d-e84e-1a33-9678-46216656fcf3_2404176474_2584865657_00000000004459953722; Path=/; Expires=Thu, 18-Jun-2026 12:45:17 GMT
2026-06-18 14:45:02 ERROR 404: Not Found.

-- 
Philippe

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.mobile.android

csiph-web