SMS strano

[GioArca67]

Attendevo una spedizione e mi è arrivato un SMS che sembra sospetto, l'orario di spedizione dell'SMS è compatibile col cambio di stato della spedizione dal tracking.
Vorrei scoprire di più.
Il link inserito manda a "ateg.info" (non seguitelo ovviamente).

EDIT:
Ci sono info private

[Etemenanki]

Nel caso ti servisse ancora controllarlo, o servisse a qualcun altro fare la stessa cosa con altri link, ci sono diversi tool online che consentono di verificare se si tratta di phishing o se contengono roba pericolosa, solo per citarne alcuni, https://phishtank.org, https://safeweb.Norton.com, https://checkphish.ai, https://www.urlvoid.com, https://www.psafe.com/dfndr-lab/, eccetera ... c'e' anche una specie di checker di google, se uno e' disposto a fidarsi di un'azienda che altera i risultati in base alla quantita' di denaro che riceve, ma io di certo di loro non mi fido per nulla.

[GioArca67]

Grazie.
Ho fatto delle analisi e fra poco le metto in un altro post. Ho riscontrato un comportamento non atteso (da ignorante forse) dei DNS

[GioArca67]

Nel caso ti servisse ancora controllarlo

Non risulta su vari di quei siti.
Ma è molto strano!
Ora dettaglio meglio.

[GioArca67]

Scusate per il casino fatto, ho commesso un piccolo errore nel ricopiare il link e caso ha voluto che ottenessi comunque una risposta dal server.

Ora il primo problema, che mi sembra il più grave: DNS.
Sto usando curl.exe su win11 (curl sulla mia macchina è un alias per Invoke-WebRequest; per inciso con Invoke-WebRequest si hanno risultati diversi, presumo perché curl.exe ritorna paro paro quel che invia il server, mentre Invoke-WebRequest lo elabora, ed essendoci dei redirect probabilmente li segue prima).

Ho hatto un nslookup di ateg.info e mi ritorna indirizzi IP localizzati a LosAngeles (sia con il DNS server di default che avevo sia dopo aver messo Cloudflare, sia su internet):

Codice: Seleziona tutto

Server:  one.one.one.one
Address:  2606:4700:4700::1111

Risposta da un server non autorevole:
DNS request timed out.
    timeout was 2 seconds.
Nome:    ateg.info
Addresses:  107.179.33.11
          107.6.242.97
          107.179.33.44
          72.5.35.137
          107.179.33.21

A parte il timeout, ed il server non autorevole che risponde, non ci sarebbe nulla di strano che tutti i servizi DNS tornano gli stessi 5 IP.
La cosa strana è che se faccio curl.exe ateg.info/CODICESMS ottengo una risposta mentre se faccio curl.exe 107.179.33.11/CODICESMS ottengo un 404 da nginx (nginx.org se fai solo l'IP), stesso 404 per gli altri 4 indirizzi trovati da nslookup.
Mettendo un CODICESMS errato, con ateg.info in chiaro torna una pagina che fa un redirect su un'altra pagina (http://invalid.researchdivine.com) ma guarda, non mettendo niente torna una pagina che fa un redirect su una pagina per cancellare la registrazione (http://ateg.info/opt/out)!!
Mentre col CODICESMS corretto torna una pagina che fa un redirect su

Codice: Seleziona tutto

https://acateriorbreverse.com/61ae25d4-6d0e-4823-a2df-b14fad60a7e1?click_id=CODICESMS&var2=&var3=O64392A53F0692&avar4=&var5=18&var6=Rome%2C+Italy&var7=COGNOME&var8=NOME&var9=TELEFONO&var10=&cost=%sms_cost%'

dove COGNOME è il mio Cognome
NOME è il nome di un parente stretto
TELEFONO è il mio numero telefono

Per cui la mia domanda principale: ho un man in the middle? e come opera visto che il browser fa una richiesta di risolvere il nome di dominio e poi manda pacchetti con l'IP?
Non avrebbe senso fosse solo per me, ho ricevuto un SMS su mobile (potevo essere ovunque) ed ho operato le ricerche da rete fissa.
Idem per curl.exe: non risolve prima il nome di dominio e poi manda una richiesta con l'IP??

[GioArca67]

Proseguendo con le ricerche ho trovato che questo dominio ("acateriorbreverse.com/61ae25d4-6d0e-4823-a2df-b14fad60a7e1") è sospetto e mette un HTML/Phishing.Gentrojan

[Etemenanki]

... e mette un HTML/Phishing.Gentrojan

Gia solo per quello, da me finirebbe nel file hosts con tutti i suoi IP e dipendenze, senza neppure cercare di capire il perche' lo fa

[GioArca67]

Se faccio

Codice: Seleziona tutto

curl.exe https://acateriorbreverse.com/61ae25d4-6d0e-4823-a2df-b14fad60a7e1?click_id=CODICESMS&var2=&var3=O64392A53F0692&avar4=&var5=18&var6=Rome%2C+Italy&var7=COGNOME&var8=NOME&var9=TELEFONO&var10=&cost=%sms_cost%

con i dati originali ovviamente, non ricevo nulla...
Strano perché con Invoke-WebRequest alla fine mi tornava la pagina di google.

[angus]

Sempre se ho capito bene quello che intendi, il comportamento del "DNS" non è anomalo.

Semplificando, ammettiamo di avere un dominio che punta ad un IP (ma vale anche se gli ip fossero più di uno):
in base alla configurazione del web server avrai risposte diverse se fai

Codice: Seleziona tutto

curl dominio

oppure

Codice: Seleziona tutto

curl IP

nginx risponde a "domino" se è istruito per farlo per quel specifico dominio, ma se cerchi di raggiungerlo con l'IP (o anche con un altro dominio che punta allo stesso IP) probabilmente di risponderà con un bel 404 Not Found.
Tutto ciò è normalissimo.

Ma non solo, se nella configurazione di nginx hai, ad esempio, una direttiva che fa un redirect 301 e provi con

Codice: Seleziona tutto

curl dominio

ti risponderà con 301 Moved Permanently senza fare il redirect.
Se invece vuoi fargli seguire i redirect allora puoi farlo con

Codice: Seleziona tutto

curl -L dominio

[GioArca67]

Avevo dimenticato il name based virtual hosting, possibile con HTTP/1.1 dove nell'header della richiesta c'è anche il nome dell'host desiderato....

...devo provare con telnet a mandare una richiesta fatta apposta...