Accesso desktop remoto di Windows 7 a utilman o stickykeys?

2

Qualcuno è a conoscenza di una procedura di Windows 7 in cui l'utente malintenzionato può accedere in remoto al computer host tramite RDP sulla porta 3389 e implementare l'exploit utilman e / o stickykey?

Afaik l'exploit utilman era un attacco locale. Non ero a conoscenza che potesse essere implementato in remoto.

-

I fatti:

  • La macchina host è un server, sempre attivo, che esegue 7 ultimate

  • La macchina host aveva una password numerica di 9 cifre che non era tra le prime 1000 peggiori password, ma era nella top 10000 list.

  • La macchina host aveva la porta 3389 aperta e la RDC era abilitata.

  • Il primo tentativo di RDC si è verificato la notte precedente e la macchina host era sulla schermata di blocco tutta la notte.

-

L'attacco è stato notato quando l'utente è entrato in lavoro e ha notato che il server era nella schermata di blocco. L'utente ha immediatamente tentato di sbloccare il computer tramite utilman > osk.exe e ha avuto esito positivo. Alcuni secondi dopo la macchina host è stata messa nella schermata di accesso. L'utente ha tentato di sbloccare tramite utilman ma questa volta è apparso un messaggio che diceva "Inserisci la password per il file crittografato: C: \ Windows \ wpmsvc.exe" L'utente è riuscito ad accedere dopo aver collegato una tastiera fisica e ha immediatamente disattivato la scheda di rete. p>

Un numero di file sono stati creati al momento dell'incidente, nonché un nuovo account amministratore.

I file che sono stati creati sono i seguenti:

Dopoavercontrollatoiregistrideglieventi,èstatoconfermatocheilnuovoaccountutenteèstatocreatoinquestomomento,nonprima,nonostanteiltentativodiconnessionedellanotteprecedente.(Unaltroragazzolonotòmentrestavalasciandoilprecedentemaloconfermòmanonsapevachequestoeraanormale,equindinonlosegnalò.IlragazzoAMsapevacomunquechequestamacchinadovevaesseresempreconnessaesbloccata)

DopoaveresaminatoilfileRDPWrap.inièstatoconfermatochel'autoredell'attaccostavatentandodiconsentirepiùconnessionisimultaneealdesktopremoto.Presumibilmenteperessereingradodiconnettersisenzabloccareloschermo.

PerprimacosahointuitochesitrattavadiunattaccoowormautomaticochecercaininternetporteaperteRDP.L'hopresuppostoperchésembrachel'attaccorichiedessel'avviodell'utentefacendoclicsulpulsanteUtilitàutente(ladatael'oradellacreazionedelnuovoaccountutenteeral'oradell'incidente).C'erasolounaccountsulcomputerhostprimadell'incidenteesoloduedopo(l'amministratoreeradisabilitato)quindihopensatochel'attaccantenonfosseingradodiaccedereall'accountprincipale(sefossepossibilechel'utilmannonfossenecessario,giusto?)

DopoavervistoiloghonotatocomunqueuneventID25"Servizi Desktop remoto: riconnessione della sessione riuscita:" con un IP russo, oltre a due ore prima.

E sotto i servizi terminal - registri di gestione connessione remota vedo centinaia di utenti casuali in eventID 1149 "Servizi Desktop remoto: autenticazione utente riuscita:" tutti da IP europei e con nomi che indicano che provengono da calcoli aziendali e di punti vendita da imprese casuali, che coprono i giorni precedenti.

Capisco come sia stato fatto per la maggior parte, con l'eccezione di come è stato possibile passare da un altro utente a un altro file in remoto su RDC (senza un login attivo) per avviare l'hack.

E se fossero in grado di accedere sotto l'account principale e solo utente (perché altrimenti sarebbe andato a bloccare la schermata a meno che non ci fosse un login di successo?), allora perché hanno dovuto fare l'exploit utilman per creare un altro account? Non potrebbero semplicemente crearlo nel modo normale?

Qualche idea?

btw, sono riuscito a trovare solo un riferimento a questo metodo, in particolare le pagine 20-26 di questa guida in formato PDF cinese che non riesco a leggere completamente.

link

    
posta Rahman 25.03.2016 - 03:27
fonte

0 risposte

Leggi altre domande sui tag