Microsoft Security Intelligence Report

By Andrei Ungureanu - Last updated: Friday, May 6, 2016

Nu m-am mai uitat pe SIR de foarte mult timp, dar ultimele editii sunt super interesante si trebuie sa imi fac timp sa le citesc.

image

https://www.microsoft.com/security/sir/default.aspx

Filed in Security • Tags:

Privileged Access Management in Windows 2016 Active Directory

By Andrei Ungureanu - Last updated: Tuesday, May 3, 2016

So this PAM (Privileged Access Management) stuff is something I thought I need to write it in English since there is not so much information about it. This feature is something that Microsoft is making a big fuss on how to use it with MIM (Microsoft Identity Manager) but not on how to leverage at least part of it if you don’t have MIM.

Some info on this new technology is here:

https://technet.microsoft.com/en-us/library/dn903243.aspx

And from this link let’s look a little bit at the problems PAM is trying to solve:

A real concern for enterprises today is the uncertainty regarding resource access within an Active Directory environment. Particularly troubling is news about vulnerabilities, unauthorized privilege escalations, and other types of unauthorized access, including pass-the-hash, pass-the-ticket, spear phishing, and Kerberos compromises. All of these attack capabilities are a concern for enterprises.

Could their Active Directory environment already be compromised? If not, how long can it take an attacker to find and then compromise a Domain Admins account? After attackers achieve such access, what can stop them? How long can they lurk on the network with that access? How long can the environment be at risk before the compromise is detected? Attackers can leave backdoors (create a way that allows them to get back in but not using the normal procedures), perform data exfiltration, and carry out other exploits.

The goal of PAM is to change the timeframes in which these vulnerabilities can be exploited. Today, it’s too easy for attackers to obtain Domain Admins account credentials, and it’s too hard to discover these attacks after the fact. Along with other investments, PAM will make it harder for attackers to penetrate a network and obtain privileged account access. PAM adds protection to privileged groups that control access across a range of domain-joined computers and applications on those computers. It also adds more monitoring, more visibility, and more fine-grained controls so that organizations can see who their privileged administrators are, and what are they doing. PAM gives organizations more insight into how such administrative accounts are used in the environment.

So … here’s a quick look on how this new PAM is going to work:

– a new Active Directory forest will be created

– all privileged accounts will be created in the new forest (let’s call it a bastion Active Directory forest)

– the old production forest doesn’t require any upgrade (for now)

– a new type of trust will be created between these two forests (PIM Trust)

– shadow groups (a new type of objects available in WS 2016) will be created in the bastion forests

– each time an admin will need to execute his/her work, the account in the bastion forest will be used (and that account will have access in the production forest, without being a member of any privileged groups)

The following picture will give some more insight of the workflow:

image

And let’s get started. We have the new bastion forest. We have the trust set between these two forests and we’ll need to enable one more thing over this trust. Using NETDOM with the /ENABLEPIMTRUST option:

image

Note:My production forest is called WINDEV.NET and my bastion forest is called WINADM.NET (sorry if this is confusing, but initially I had these set for another purpose).

In the bastion forest, if we look in Active Directory Sites and Services console, we can see a new container called Shadow Principal Configuration and if we right click on it we have the option to create some new objects.

image

What we are interested in is the msDS-ShadowPrincipal (we can create these type of objects in some other parts of AD using Active Directory Users and Computers but for the scenario I am trying to show right now it doesn’t seem to produce the desired results; so let’s create this using Sites and Services).

The new object will need a name. The object will be a shadow of an existing object from the production forest. And I am trying to shadow the Server Admins group.

 

image

Find out the SID of the production group (get-adgroup should be simple enough – in the production forest).

image

Just two steps and we have the shadow created.

image

Let’s inspect the attributes of the new object:

image

image

Now let’s add members to this shadow group. The members need to be accounts from the same forest as the shadow group (the bastion forest). So, my admins we’ll get new accounts that we’ll be regular accounts in the bastion forest, but through the shadow group they’ll be able to get privileges in the production forest.

And I have such an account that I will use for this:

image

After this, the shadow group membership can be seen through the regular Active Directory Users and Computers console:

image

And now the test. I am logging on using the my “admin” account created in the bastion forest (WINADM), on a computer from the production forest (WINDEV).

Running whoami /groups will show me that in my token, I have the SID of my Server Admins group from the production forest (WINDEV).

image

Combine these with time limited group membership and you will make a big change in your Active Directory security. Please note that for now this is beta software. Do not use it in production environments.

For now I am still waiting for the official product documentation …

Filed in Active Directory • Tags: , , ,

Windows Server 2016 TP5

By Andrei Ungureanu - Last updated: Thursday, April 28, 2016

Tocmai ce s-a lansat WS2016 TP5, probabil ultimul technical preview inainte de RTM. Poate fi downloadat de aici:

https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Documentatia e cam subtire in acest moment. Tot ce am putut gasi este in link-ul de mai jos:

https://technet.microsoft.com/en-us/library/dn765472(v=ws.12).aspx

Filed in Windows Server • Tags:

Delprof2 – User Profile Deletion Tool

By Andrei Ungureanu - Last updated: Sunday, April 24, 2016

Pe vremuri exista un tool oferit de Microsoft numit Delfprof ce ajuta in stergerea profilelor inactive. Din pacate tool-ul nu mai poate fi folosit pe sistemele de operare mai noi.

In schimb exista un tool third party numit Delprof2 oferit de HedgeKlein ce ruleaza pana la Windows 8 (inca nu am avazut nimic legat de Windows 10).

https://helgeklein.com/free-tools/delprof2-user-profile-deletion-tool/

Tool-ul e util si atunci cand ACL-urile impiedica accesarea profilelor. Nu si atunci cand profilul e “in use”.

Poate fi folosit si remote si doar pentru a face o evaluare a profilelor de pe un anumit sistem.

Filed in Windows Client • Tags:

NTDS.DIT Forensincs

By Andrei Ungureanu - Last updated: Monday, April 18, 2016

M-am gandit sa partajez aici cateva materiale despre atacurile offline asupra bazei de date Active Directory, NTDS.DIT. Nu le vad ca pe hacking, ci mai mult educationale. Contin multe informatii nedocumentate ce va ajuta sa intelegeti cum functioneaza Active Directory si va deschid ochii asupra atacurilor existente.

http://ntdsxtract.com/downloads/ntdsxtract/ntds_forensics.pdf

http://www.dataforensics.org/microsoft-active-directory/

http://moyix.blogspot.ro/2008/02/syskey-and-sam.html

PS: acum cred ca e clar de ce accesul fizic la un DC cu discul necriptat este o grozavie.

Filed in Active Directory, Security • Tags: ,

Temporary Group Membership in Windows Server 2016

By Andrei Ungureanu - Last updated: Saturday, April 16, 2016

Microsoft nu a uitat complet de Active Directory si in versiunea ce vine cu Windows Server 2016 sunt cateva imbunatatiri subtile. Oricum am fost obisnuiti ca pe partea de AD, schimbarile sa fie foarte subtile si greu de observat pentru adminul neexperimentat.

Una din noutati se numeste Temporary Group Membership si vine cumva mai mult pentru a face Privileged Access Management prin Microsoft Identity Manager insa poate fi folosita si standalone, fara MIM.

Dar sa revenim strict la subiect, Temporary Group Membership face exact ce spune si numele. Adauga membri intr-un grup, pe o perioada determinata. Exemplu: cineva iti cere access intr-un grup pentru a efectua anumite taskuri, sa zicem Domain Admins, cererea ii este aprobata si ai permisiunea sa ii dai acces dar doar pentru 3 zile. Cu aceasta optiune in place poti adauga userul in grup si seta un Time to Live de 3 zile. Cand timpul va expira, userul va fi scos din grup automat fara a fi nevoie de interventia administratorului.

Noile functionalitati ce vin cu versiunea 2016 se activeaza separat si odata activate nu se mai poate face rollback. Cam la fel cum a fost si pana acum (gen AD Recycle Bin).

image

Activarea se face folosind comanda powershell Enable-ADOptionalFeature.

Enable-adoptionalfeature “Privileged access management feature” –scope forestorconfigurationset –target "mslab.net".

Daca dorim sa verificam prezenta functionalitatii intr-un forest existent putem folosi Get-AdOptionalFeature:

image

Odata activata functionalitatea, folosim optiunea –MemberTimeToLive a comenzii Add-ADGroupMember. Comanda va seta un TTL pe link-ul ce defineste membrul in grup. Prima data va trebui sa definim acel TTL folosind New-TimeSpan:

$ttl = New-TimeSpan -Minutes 5

Add-ADGroupMember -Identity "Domain Admins" -Members aungureanu -MemberTimeToLive $ttl

image

Iar din aces moment, userul nou adaugat are fix timpul definit ca memberTimeToLive pentru a isi efectua taskurile. In momentul in care timpul a expirat, userul este automat scos din grup si mai mult decat atat, tichetul Kerberos va fi si el expirat (in momentul emiterii tichetului de catre KDC acesta va seta lifetime-ul ca fiind TTL-ul cel mai mic de pe link-urile ce au aceasta optiune activata; iar fiecare DC va verifica tabela cu link-urile ce urmeaza sa expire si le va sterge atunci cand TTL-ul va ajunge la zero)

Putem sa verificam apartenenta la grup si timpul ramas folosind Get-ADGroup:

image

Dupa cum vedeti forward link-ul din grup are acum un nou format cu <TTL=40> in fata DN-ului. TTL-ul de acolo reprezinta timpul ramas in secunde, in cazul nostru 40.

In event viewer se va putea vedea in afara de momentul in care a fost adaugat userul in grup si “Expiration time”:

image

Deocamdata nu a gasit nici un eveniment prin care sa monitorizez ca userul a fost scos din grup.

Dar considerand ca ca produsul este inca beta, mai sunt de asteptat schimbari legate de aceste noi functionalitati.

Filed in Uncategorized

Encrypting credentials with Powershell

By Andrei Ungureanu - Last updated: Thursday, March 31, 2016

Rasfoind cateva site-uri am citit despre cum poti sa stochezi criptat credentiale ce pot fi refolosite mai departe in scripturi. Metodele folosite sunt interesante si sunt utile in unele cazuri:

http://www.adminarsenal.com/admin-arsenal-blog/secure-password-with-powershell-encrypting-credentials-part-1/

http://www.adminarsenal.com/admin-arsenal-blog/secure-password-with-powershell-encrypting-credentials-part-2/

Filed in Scripting • Tags: ,

Kerberos Token Bloat, Again

By Andrei Ungureanu - Last updated: Sunday, March 27, 2016

Am mai scris si o sa mai scriu probabil despre subiectul asta pentru ca pe masura ce trece timpul sunt sigur ca o sa vad tot mai multe astfel de cazuri (asta daca nu migreaza toata lumea pe Windows 10 si Windows 2012R2 sau mai mare).

Ca definitie, Kerberos Token Bloat se refera la scenariul cand token-ul Kerberos este prea mare, si de aici tot felul de probleme de autentificare. Pe vremuri primele simptome au fost legate de MTU si de faptul ca token-ul devenea fragmentat. Dar problema asta a fost depasita si s-a ajuns la o limitare numita MaxTokenSize ce defineste un buffer pentru tichetele Kerberos pe care le poate accepta un sistem Windows. Valoare initiala a pornit de la 8000 bytes (W2K) si a crescut la 12000 in Windows7/2008R2 iar incepand cu Windows 2012 este de 48000 bytes.

48000 este o valoare destul de mare, asa ca sistemele ce au MaxTokenSize setata asa nu vor suferi de Kerberos Token Bloat. In schimb daca inca esti pe 12000, ai sansa sa fii afectat de asa ceva. Dar hai sa vedem si cum.

Pai in ticketul ala Kerberos, o mare parte din informatie este reprezentata de acel PAC (Privilege Attribute Certificate) care ghiciti ce contine. Lista cu toate grupurile din care face parte userul (sub forma de SID bineinteles). Si nu numai grupurile ce apar in memberOf ci si “nested groups” (grupurile ce fac parte din grupurile din care face parte userul, etc), mai exact atributul tokenGroups (un atribut calculat atunci cand este accesat). Si cand sunt prea multe grupuri, automat si dimensiunea tichetului Kerberos o sa creasca.

Nota: exista o limita hardcoded de 1010 grupuri.

Iar daca se mai intampla ca obiectele din Active Directory sa mai contina si SIDHistory, automat informatia se dubleaza.

Cand banuiti o astfel de problema, puteti folosi scriptul de mai jos pentru a face o estimare a dimensiunii tokenului Kerberos pentru un anumit user:

https://gallery.technet.microsoft.com/scriptcenter/Check-for-MaxTokenSize-520e51e5

Si in functie de asta puteti sa reanalizati grupurile din care face parte userul (daca sunt nested, cateodata poate fi un chin) sau sa mariti dimensiunea MaxTokenSize.

Mai jos gasiti cateva articole foarte bune despre cum sa modificati MaxTokenSize pe diverse versiuni de Windows. Doar incepand cu Windows 2012 gasiti setarea by default in GPO:

https://support.microsoft.com/en-us/kb/938118

http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-and-kerberos-token-bloat.aspx

Nota: Setarile astea trebuie facute pe toate sistemele ce fac parte din conversatia Kerberos (adica vor trebui aplicate si pe DC-uri, servere si statii).

Chiar si cu NTDSUTIL puteti obtine informatii utile (gen toate SID-urile din token-ul unui user):

image

image

Iata si alte cateva resurse ce pot fi de folos in astfel de situatii:

https://support.microsoft.com/en-us/kb/328889

https://support.microsoft.com/en-us/kb/327825

https://www.sans.org/reading-room/whitepapers/authentication/kerberos-token-size-dos-33714

https://support.microsoft.com/en-us/kb/301916

Filed in Active Directory • Tags: ,

LAPS.E

By Andrei Ungureanu - Last updated: Tuesday, March 15, 2016

In caz ca Local Administrator Password Solution, solutia descrisa de mine aici nu va multumeste pentru ca informatia stocata in Active Directory nu este criptata, exista si un proiect open source ce vine si cu aceasta posibilitate. Solutia se numeste LAPS.E si mai multe informatii gasiti in link-urile de mai jos:

http://www.laps-e.net/index.php

https://github.com/jformacek/laps-e

https://code.msdn.microsoft.com/solution-for-management-of-ae44e789

PS: LAPS-ul oferit de Microsoft este bazat tot pe codul de mai sus. Pentru cei ce au nevoie sa ruleze CSE-ul pe XP in solutia oferita de MS, e nevoie sa il luati din varianta open source LAPS.E.

Filed in Active Directory, Windows Client, Windows Server • Tags:

Local Administrator Password Solution aka LAPS

By Andrei Ungureanu - Last updated: Friday, March 11, 2016

Eu am spus de multe ori ca cea mai buna solutie pentru protejarea conturilor locale (si de acolo a intregii infrastructuri) este parola unica pe fiecare cont local. Cu un sistem centralizat si bine securizat in care sa stochezi aceste parole, devine floare la ureche. Insa pana de curand, cam tot ce vazusem era destul de complicat, greu de folosit si foarte putina lume incerca asa ceva iar unii chiar nu auzisera.

Exista si o varianta scriptata dar si acolo foarte putini se avantau pentru ca le parea ceva destul de complicat. Asa ca stateau cu aceeasi parola pe contul de administrator si bineinteles expusi atacurilor de tip PTH.

Dar anul trecut Microsoft a pus la dispozitie un tool (LAPS) pentru gestionarea parolelor pentru contul de administrator local. Tool-ul se ocupa cu generarea parolei unice a contului de administrator pe statie si stocarea ei in Active Directory (locul unde vor fi stocate aceste parole).

Nota: LAPS era disponibil si pana acum clientilor ce aveau contracte de suport de tip Premier.

Pentru moment o sa incerc in mare sa fac un rezumat al componentelor ce fac parte din aceasta solutie pentru a fi mai usor de inteles. Solutia este baza pe pe Group Policy. Astfel fiecare computer administrat prin LAPS va avea nevoie de un nou CSE (Client Side Extension) ce se va ocupa de schimbarile de parola. Iar parolele vor fi stocate in Active Directory. Deci vom avea asa:

– un CSE ce se instaleaza pe client (este un DLL ce se va instala dintr-un MSI)

– un ADM ce va fi necesar pe statia de management pentru a administra setarile din GPO

– script pentru extinderea schemei AD ca sa poata stoca noile parole

– tooluri pentru a vizualiza parola din AD

Prima data trebuie sa downloadati solutia de aici:

https://www.microsoft.com/en-us/download/details.aspx?id=46899

In download gasiti urmatoarele fisiere:

 

image

Vom avea nevoie de un sistem de management, asa ca vom instala versiunea x64 pe sistemul nostru de management (in cazul meu este chiar un domain controller pentru ca este un mediu de test; altfel nu as recomanda).

image

By default, MSI-ul instaleaza doar AdmPwd GPO Extension (acel CSE sau extensie GPO de care va spuneam mai devreme). Dar pentru sistemul de management vom avea nevoie sa selectam toate componentele, exact ca mai jos:

image

image

Un nou modul powershell va fi instalat iar mai jos puteti vedea noile comenzi.

image

Iar una dintre ele este Update-AdmPwdADSSchema, comanda ce va face update-ul de schema cu noile atribute pentru stocarea parolei. Nu trebuie sa va mai spun ca aveti nevoie de Schema Admins ca sa efectuati acest update.

image

Odata ce am extins schema mai este ceva de setat legat de aceste atribute. By default userii normali din AD au dreptul sa citeasca foarte multe atribute. De aceea acum va trebui sa verificam si sa restrictionam daca este necesar accesul la aceste atribute. Accesul se va face prin “All extended rights” si avem la dispozitie chiar si un cmdlet prin care putem verifica cine are drepturi pe acest atribut pe un anumit OU:

image

Daca totusi avem useri sau grupuri ce nu trebuie sa aiba acces, atunci va trebui sa ne conectam cu ADSIEdit, properties pe OU, mers pe tab-ul Security, Advanced:

image

Selectat user/grupul, Edit si debifat “All extended rights” .

image

Bun, acum ca ne-am asigurat ca in afara de domain admins nu are nimeni drepturi, e timpul sa dam si cateva drepturi. Odata o sa facem un grup nou numit PasswordRecovery (puteti alege orice nume doriti) si ii vom da drepturi sa citeasca parolele folosind Set-AdmPwdReadPasswordPermission:

image

Nota: Putem avea grupuri diferite ce pot citi parolele de pe OU-uri diferite. De exemplu putem avea OU cu servere, unde doar anumiti admini vor avea acces la parole.

Dar pe aceste atribute si computer account-urile vor avea nevoie de drepturi ca sa poata updata parola si vom folosi Set-AdmPwdComputerSelfPermission:

image

Acum ca am terminat cu setat drepturile in AD, hai sa vedem cum facem deployment la acel GPO CSE pe statii. Si solutia pe care o propun acum este tot GPO. Bineinteles ca exista si alte variante, dar momentam lucram cu ce avem builtin. Deci vom face in GPO nou ce se va aplica pe OU-ul nostru cu statii (in cazul meu, acel Test1) si vom folosi functia de deploy software din Group Policy:

image

Selectam pe rand ambele MSI-uri ce au venit in solutie, setam ca deployment Assigned:

image

NOTA: Fisierele trebuie sa fie accesibile de catre statii. Eu le-am pus in NETLOGON pentru ca locatia accesibila si este replicata pe toate DC-urile.

Iar la MSI-ul pe 32 de biti trebuie sa mergem in advanced si sa debifam “Make this 32-bit X86 application available to Win64 machines” (pentru ca avem separat versiune pe 64 de biti).

image

image

Dupa ce setam politica, si cateva reboot-uri pe statii, o sa putem vedea ca LAPS s-a instalat in Programs and Features:

image

Iar acum ultimul pas din configurare, este setarea GPO-ului ce va trimite “instructiuni” CSE-ului de pe client. Putem face asta in acelasi GPO ce l-am folosit pentru instalarea pachetelor MSI sau in altul. In exemplul meu, o sa ma folosesc de acelasi GPO. Pe statia de management, in Administrative Templates putem vedea acum o noua rubrica, LAPS:

image

image

Urmatoarea setare o sa o las pe Not Configured, pentru ca intentia mea este sa controlez contul Administrator builtin. Acum depinde de cum gestionati statiile si daca ati facut enable la cont in imagine sau ati mers pe varianta cu un alt cont local:

image

Iar optiunea de mai jos se explica singura; cand CSE-ul va detecta ca parola a expirat va initia imediat schimbarea.

image

Si ultima optiune dar nu lipsta de importanta este “Enable local admin password management”. Fara aceasta optiune activa, CSE-ul nu va face nimic.

image

Dupa ce am salvat politica si a fost preluata de una din statiile pe care am instalat si CSE-ul putem vedea deja update-urile in AD. O varianta ar fi prin orice editor de atribute avem la indemana:

image

Nota: Password Expiration date-ul il putem converti cu w32tm /ntte:

image

Sau mai putem vizualiza parola si cu unul din tool-urile ce se instaleaza pe statia de management:

image

image

Sau din powershell cu Get-AdmPwdPassword:

image

Si gata, puteti uita de bataia de cap produsa de mentenanta conturilor locale.  GPO & AD will take care of that :)

Filed in Active Directory, Windows Client, Windows Server • Tags: ,