Shodan è un potente motore di ricerca creato da John Matherly come hobby. Matherly voleva tracciare qualsiasi tipo di dispositivo connesso a Internet. È così che Shodan nasce nel 2009.

L'indicizzazione di questo motore di ricerca funziona cercando le porte aperte di qualsiasi servizio o dispositivo. Ciò significa che, a differenza di qualsiasi normale motore di ricerca, non si concentra sulla ricerca nelle pagine web ma sulla raccolta dei banner dei servizi (risposta del server a una richiesta). Questi servizi includono i protocolli HTTP, HTTPS, FTP, SSH, Telnet, SNMP e SIP. Quindi, l'utente può cercare i dispositivi per regioni o aree geografiche applicando i filtri Shodan.

Cosa è possibile trovare con Shodan?

Quasi tutto! E questa è la parte spaventosa! Questo è uno dei motivi per cui vice.com lo definisce il motore di ricerca più pericoloso al mondo. Shodan è in grado di trovare da uno smartphone a un frigorifero, un sistema di telecamere di sicurezza e persino una centrale nucleare.

Shodan è uno specialista nella scansione dell'Internet delle cose:  quando esegue una ricerca più approfondita, restituisce risultati con informazioni come il tipo di dispositivo connesso a Internet, dove si trova e chi lo utilizza.

Questo motore di ricerca non ha nulla da invidiare a Google e come il suo parente più noto ha una sintassi estremamente sofisticata che consente di affinare le ricerche e trovare l’impensabile

#penetrationtesting #vulnerability #securityawareness #cybersecurityawareness #offensivesecurity #ethicalhacking #ethicalhacker #cybersecurity #infosec #infosecurity #pentest #pentester #redteam #malware #malwareanalysis #cybersecurityUP

Uno degli strumenti più utili nel processo di footprinting è NsLookup.
Nslookup è uno strumento utilizzato per interrogare i DNS al fine di ottenere informazioni utili sul target.
Un utilizzo di questo strumento può essere il seguente

1. Al prompt dei comandi, digitare nslookup, quindi premere Invio.
2. Digitare server <indirizzo IP>, dove indirizzo IP è l'indirizzo IP del proprio Server DNS, quindi premere Invio.
3. Entrati dentro la shell di NsLookkup digitare set type=mx, quindi premere Invio.
4. Digitare <nome dominio>, dove nome dominio è il nome del dominio oggetto dell'analisi, quindi premere Invio.

Viene visualizzato il record MX per il dominio che hai inserito.

Allora cosa ci dice il risultato? In questo esempio i nomi dei server e gli indirizzi IP restituiti sono per i server di posta che elaborano la posta per il dominio.

Se lo si desidera, possiamo anche utilizzare il comando set type per cercare tutti i record DNS un dominio sostituendo MX con A. E' possibile anche recuperare la start of authority per un dominio sostituendo MX con SOA.

#penetrationtesting #vulnerability #securityawareness #cybersecurityawareness #offensivesecurity #ethicalhacking #ethicalhacker #cybersecurity #infosec #infosecurity #pentest #pentester #redteam #malware #malwareanalysis #cybersecurityUP

Uno dei passi fondamentali del processo di footprinting è l'utilizzo di un motore di ricerca per scovare informazioni utili sul target
I motori di ricerca come Google e Bing possono facilmente fornire una grande quantità di informazioni che il target consapevolmente, ma anche no, ha pubblicato su internet.
Utilizzando un motore di ricerca, si possono trovare molte informazioni, alcune completamente inaspettate o qualcosa che un difensore non considera come un'informazione sensibile, come piattaforme tecnologiche, dettagli sui dipendenti, pagine di accesso, portali intranet e così via.

Una ricerca può facilmente fornire anche maggiori dettagli come nomi del personale di sicurezza, marca e tipo di firewall e protezione antivirus, e non è raro trovare diagrammi di rete e altro.

Naturalmente, il motore di ricerca più conosciuto e dominante oggi è Google che tramite un suo proprio linguaggio può diventare un vero e proprio motore di informazioni sensibili.
La creazione di queste interrogazioni sofisticate viene definito Google Hacking e non è niente di nuovo, è in circolazione da molto tempo; semplicemente non è ampiamente conosciuto dal pubblico.

Il processo prevede l'utilizzo di operatori avanzati per la messa a punto dei risultati. Le stringhe ottenute vengono chiamate Google Dorks
Gli operatori più importanti sono site: filetype: intitle: language: in combinazione con AND o OR (che è il default)
Es: se vogliamo ricercare un file excel contenente la parola password su siti della compagnia Acme.org possiamo provare:
password filetype:xls site:acme.org
Una interessantissima fonte di google dorks è exploit-db.com

#penetrationtesting #vulnerability #securityawareness #cybersecurityawareness #offensivesecurity #ethicalhacking #ethicalhacker #cybersecurity #infosec #infosecurity #pentest #pentester #redteam #malware #malwareanalysis #cybersecurityUP

Il footprinting, o ricognizione, è un metodo per osservare e raccogliere informazioni su un potenziale bersaglio con l'intenzione di trovare un modo per attaccarlo.
Il footprinting cerca informazioni e successivamente le analizza, alla ricerca di punti deboli o potenziali vulnerabilità.
Quando si esegue, come per tutte le fasi e i processi dell'hacking etico, è necessario essere metodici. Un'attività di questo tipo condotta male può far perdere tempo o, nel peggiore dei casi, far fallire l'attacco. Inoltre, essere imprecisi può avere l'effetto indesiderato di attirare l'attenzione del difendente, contrastando così la raccolta di informazioni.
L'attaccante intelligente spende una buona parte di tempo in questa fase di raccolta e conferma delle informazioni.

1. Identificazione del target Il primo passaggio consiste nell'identificare quali sistemi o organizzazioni attaccare

2. Raccolta di informazioni Dopo che l'obiettivo è stato identificato, il passaggio successivo consiste nel raccogliere quante più informazioni possibili su di esso utilizzando strumenti come Nmap, Netcat e Whois per identificare porte e servizi aperti, nomi utente e password, informazioni sul server Web e altro ancora.

3. Analisi dei risultati Dopo che tutti i dati rilevanti sono stati raccolti, devono essere analizzati per determinare i punti più vulnerabili. Questo viene fatto identificando le vulnerabilità note su più sistemi o confrontando i risultati con exploit noti.

4. Pianificazione degli attacchi Il passaggio finale consiste nell'utilizzare le informazioni raccolte durante il footprinting per pianificare un attacco

Nella pillola precedente vi avevo parlato delle tecniche antidebugging utilizzate dai malware e vi avevo parlato dell'utilizzo della primitiva CreateToolhelp32Snapshot per ricercare un processo.
Oggi vi mostro una routine scritta in C per dimostrarvi come si può fare.
Ho commentato il codice per renderlo più leggibile.
Innanzitutto bisogna partire con un punto nel corpo del malware nel quale si esegue un if di questo tipo

if processExists("OllyDbg.exe")
     faiqualcosaltro();
else
     faidelmale();

In pratica la funzione processExists cerca in memoria il processo OllyDbg.exe (il debugger) e se lo trova al posto di comportarsi come vorrebbe fa qualcos'altro, inducendo in errore l'analista.
Il cuore di questa routine è processExists che vi metto qui sotto:

int processExists(const wstring nome_processo)
{
Int processFound=0; // processFound = 0 se il processo non viene trovato, altrimenti è 1
HANDLE Hsnapshot; // conterrà la fotografia della memoria con tutti i processi attivi
if ((Hsnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0)) == INVALID_HANDLE_VALUE)
{
throw runtime_error("CreateToolhelp32Snapshot ha fallito con il seguente errore: " + to_string(GetLastError()));
}

PROCESSENTRY32 pe; // conterrà le informazioni sul processo corrente recuperato dallo snapshot
ZeroMemory(&pe, sizeof(PROCESSENTRY32W)); // pulisco l'area di memoria a cu punta pe rimpendola di zeri
pe.dwSize = sizeof(PROCESSENTRY32W);
Process32First(Hsnapshot, &pe); // prendo il primo processo nello snapshot. Qui avrei dovuto controllare l'eventuale errore di Process32First ;-)
if (pe.szExeFile == nome_processo) // Il campo szExeFile della struttura PROCESSENTRY32 contiene il nome del processo
    {
       processFound=1;
    }
else
    {
     while (Process32Next(Hsnapshot, &pe))
        {
            if (pe.szExeFile == nome_processo)
                {
                processFound=1;
                break;
                }
        }
    }
    return processFound;
}

#webapplicationsecurity #securityprofessionals #offensivesecurity #ethicalhacking #ethicalhacker #cybersecurity #cybersecurityawareness #informationsecurity #infosec #infosecurity #security #penetrationtesting #pentesting #pentest #pentester #securityawareness #redteam #redteaming #vulnerabilities #vulnerability #vulnerabilityscanning #vulnerabilityassessment #vulnerabilitymanagement #exploit #exploits #exploitation #codereview #securityadvisor #securityaudit #securityaudits #bughunter #bughunting #bugfixed #itsecurity #itsec #riskassessment #riskmanagement #ciso #owasp #owasptop10 #malware #malwareanalysis #cybersecurityUP

Continuo il discorso della pillola precedente sulle tecniche di #antidebugging utilizzate dai #malware.
La volta scorsa vi ho parlato del campo #BeingDebugged all'interno della #PEB, oggi vi parlerò di un'altra tecnica.
Oltre a controllare questo campo nella PEB, i malware utilizzano la tecnica della scansione dei processi in memoria per identificare un #debugger in esecuzione.
Questo può essere fatto in due modi:
1) Utilizza la funzione #CreateToolhelp32Snapshot per fare uno screenshot della memoria, e poi ricercare il processo incriminato tramite #Process32first() e #Process32Next()
2) Al posto di cercare il processo in memoria, cerca se esiste una finestra attiva relativa la processo incriminato tramite #FindWindow()
Nella prossima pillola vi mostrerò il codice C da utilizzare nel primo caso ;-)

#appsec #appsecurity #webappsec #webapplicationsecurity #webapplications #securityprofessionals #offensivesecurity #ethicalhacking #ethicalhacker #cybersecurity #cybersecurityawareness #informationsecurity #infosec #infosecurity #security #penetrationtesting #pentesting #pentest #pentester #securityresearch #securityawareness #redteam #redteaming #redteamthinking #vulnerabilities #vulnerability #vulnerabilityscanning #vulnerabilityassessment #vulnerabilitymanagement #exploit #exploits #exploitation #securecoding #securitycompany #securityindustry #securityanalyst #codereview #securityadvisor #securityaudit #securityaudits #bughunter #bughunting #bugfixed #itsecurity #itsec #riskassessment #riskmanagement #ciso #owasp #owasptop10 #malware #malwareanalysis

La  #malwareAnalysis prevede lo studio del #malware e dei suoi comportamenti.
Questo può essere fatto in modalità statica (senza eseguire il malware) o dinamica (eseguendo il malware in ambiente controllato).
L'analisi dinamica avanzata prevede di eseguire un malware all'interno di un #debugger (es. #OllyDbg) in modo da poter seguire, istruzione per istruzione (parlo di istruzioni #Assembler), il suo comportamento.
Ma i malware, per evitare di essere studiati, spesso utilizzano tecniche definite di #AntiDebugging, ovvero tecniche che alterano il suo comportamento in caso si accorga di essere eseguito all'interno di questi strumenti.
Ma come fa a rendersene conto?
Le tecniche sono molte, una di queste prevede di andare a controllare il campo Beingdebugged all'interno della #PEB del proprio processo.
Infatti, quando un processo viene eseguito all'interno di un debugger, il campo #BingDebugged viene impostato ad 1 altrimenti è 0.
Tipicamente le istruzioni che si possono trovare in malware che eseguono questo controllo, prevedono di saltare all'indirizzo della PEB che si trova in fs:[30h] e da lì ci si sposta di 2 byte. Un esempio di istruzioni potrebbe essere

mov eax, fs[30h] // carico in eax l'indirizzo della peb
mov ebx, [eax+2] // carico in ebx il flab BeingDebugged
test ebx, ebx // testo se il campo BeingDebugged è 1
jz NoDebuggerDetected // a questo indirizzo si esegue il codice alternativo

Le Yara Rules sono un vero e proprio linguaggio, ideato da Victor Alvarez di #VirusTotal per identificare un malware.
Prima della sua nascita i #malwareAnalyst non avevano una struttura sintattica rinosciuta per descrivere un malware, quindi ognuno lo descriveva a modo suo ;-)
Ogni regola è suddivisa in tre parti:
1) Meta: questa parte serve solo a definire l'autore, la data di creazione etc... e non è fondamentale
2) Strings: contiene l'insieme di stringhe che un'analisi statica del malware potrebbe fornire
3) Condition: contiene una serie di condizioni, definite quasi come delle espressioni regolari, che rapportano tra di loro le stringhe
Un esempio potrebbe essere: $Stringa1 and $Stringa2 che sta a significare che il malware descritto contiene entrambe le stringhe
Esistono poi tutta una serie di moduli che aggiungono potenza a questo linguaggio.
Ad esempio il modulo PE consente di accedere direttamente a tutte le sezioni PE del malware (nel caso in cui sia un eseguibile windows).
Una regola che utilizza il modulo PE potrebbe essere pe.imports("Wininet.dll","InternetConnectA") che indica che il malware importa la funzione InternetConnectA da Wininet.dll

#cybersecurity #cybersecurityup #malware #malwareanalysis #hacker #ethicalHacking