Այս հոդվածը գրվել է մի քանի տարի առաջ Group-IB-ի մասնագետների կողմից անցկացված մի շատ հաջողված փորձության հիման վրա. տեղի ունեցավ մի պատմություն, որը կարող էր հարմարեցվել Բոլիվուդի ֆիլմերի համար: Հիմա, հավանաբար, կհետևի ընթերցողի արձագանքը. «Վայ, ևս մեկ PR հոդված, էլի սրանք են պատկերվում, ինչ լավն են, մի մոռացեք գնել պենտեստ»: Դե, մի կողմից, դա այդպես է: Այնուամենայնիվ, կան մի շարք այլ պատճառներ, թե ինչու է այս հոդվածը հայտնվել: Ուզում էի ցույց տալ, թե կոնկրետ ինչ են անում գրպանները, որքան հետաքրքիր և ոչ տրիվիալ կարող է լինել այս աշխատանքը, ինչ զվարճալի հանգամանքներ կարող են ի հայտ գալ նախագծերում, և ամենակարևորը` ցույց տալ կենդանի նյութ իրական օրինակներով:
Աշխարհում համեստության հավասարակշռությունը վերականգնելու համար որոշ ժամանակ անց կգրենք մի պենտեստի մասին, որը լավ չանցավ։ Մենք ցույց կտանք, թե ինչպես լավ մշակված գործընթացները ընկերությունում կարող են պաշտպանել մի շարք հարձակումներից, նույնիսկ լավ պատրաստված հարձակումներից, պարզապես այն պատճառով, որ այդ գործընթացները գոյություն ունեն և իրականում գործում են:
Այս հոդվածում հաճախորդի համար ամեն ինչ նույնպես ընդհանուր առմամբ գերազանց էր, առնվազն ավելի լավ, քան Ռուսաստանի Դաշնության շուկայի 95% -ը, ըստ մեր զգացմունքների, բայց կային մի շարք փոքր նրբերանգներ, որոնք ձևավորեցին իրադարձությունների երկար շղթա, որոնք նախ. հանգեցրեց աշխատանքի երկար զեկույցին, այնուհետև այս հոդվածին:
Այսպիսով, եկեք համալրենք ադիբուդի և բարի գալուստ դետեկտիվ պատմություն: Խոսք - Պավել Սուպրունյուկ, Group-IB-ի «Աուդիտ և խորհրդատվություն» բաժնի տեխնիկական ղեկավար։
Մաս 1. Պոչկին բժիշկ
2018 թ Կա հաճախորդ՝ բարձր տեխնոլոգիական ՏՏ ընկերություն, որն ինքն է սպասարկում բազմաթիվ հաճախորդների։ Ուզում է ստանալ հարցի պատասխանը. հնարավո՞ր է առանց նախնական գիտելիքների և հասանելիության, աշխատելով ինտերնետի միջոցով, ստանալ Active Directory տիրույթի ադմինիստրատորի իրավունքները: Ինձ չի հետաքրքրում որևէ սոցիալական ճարտարագիտություն (), նրանք մտադիր չեն կանխամտածված միջամտել աշխատանքին, բայց նրանք կարող են պատահաբար - վերաբեռնել տարօրինակ աշխատող սերվերը, օրինակ: Լրացուցիչ նպատակն է բացահայտել որքան հնարավոր է շատ այլ հարձակման վեկտորներ արտաքին պարագծի դեմ: Ընկերությունը պարբերաբար նման փորձարկումներ է անցկացնում, և այժմ եկել է նոր թեստավորման վերջնաժամկետը։ Պայմանները գրեթե բնորոշ են, ադեկվատ, հասկանալի։ Եկեք սկսենք.
Հաճախորդի անունը կա՝ թող լինի «Ընկերություն», գլխավոր վեբկայքով . Իհարկե, հաճախորդին այլ կերպ են անվանում, բայց այս հոդվածում ամեն ինչ անանձնական կլինի:
Ես անցկացնում եմ ցանցի հետախուզություն՝ պարզել, թե որ հասցեներն ու տիրույթները գրանցված են հաճախորդի մոտ, գծել ցանցային դիագրամ, ինչպես են ծառայությունները բաշխվում այդ հասցեներին: Ես ստանում եմ արդյունքը՝ ավելի քան 4000 կենդանի IP հասցե։ Ես նայում եմ այս ցանցերի տիրույթներին. բարեբախտաբար, ճնշող մեծամասնությունը հաճախորդի հաճախորդների համար նախատեսված ցանցեր են, և մենք դրանք պաշտոնապես հետաքրքրված չենք: Հաճախորդը նույնն է մտածում.
Մնում է մեկ ցանց՝ 256 հասցեով, որի համար այս պահին արդեն հասկացվում է տիրույթների և ենթադոմեյնների բաշխումն ըստ IP հասցեների, կա տեղեկատվություն սկանավորված նավահանգիստների մասին, ինչը նշանակում է, որ դուք կարող եք նայել ծառայությունները հետաքրքիրների համար։ Զուգահեռաբար, բոլոր տեսակի սկաներները գործարկվում են հասանելի IP հասցեներով և առանձին կայքերում։
Ծառայությունները շատ են։ Սովորաբար սա ուրախություն է հոգեհանգստի համար և արագ հաղթանակի ակնկալիք, քանի որ որքան շատ են ծառայությունները, այնքան մեծ է հարձակման դաշտը և ավելի հեշտ է գտնել արտեֆակտ: Կայքերի արագ դիտումը ցույց տվեց, որ դրանց մեծ մասը համաշխարհային խոշոր ընկերությունների հայտնի արտադրանքների վեբ ինտերֆեյսներ են, որոնք, ըստ երևույթին, ասում են, որ դրանք ողջունելի չեն: Նրանք խնդրում են օգտվողի անուն և գաղտնաբառ, թափահարում են դաշտը երկրորդ գործոնը մուտքագրելու համար, խնդրում են TLS հաճախորդի վկայական կամ ուղարկել այն Microsoft ADFS-ին: Ոմանք պարզապես անհասանելի են ինտերնետից: Ոմանց համար դուք ակնհայտորեն պետք է ունենաք հատուկ վճարովի հաճախորդ երեք աշխատավարձի համար կամ իմանաք մուտքագրելու ճշգրիտ URL-ը: Եկեք բաց թողնենք աստիճանական հուսահատության ևս մեկ շաբաթ՝ փորձելով «ճեղքել» ծրագրաշարի տարբերակները հայտնի խոցելիության համար, որոնել թաքնված բովանդակություն վեբ ուղիներում և երրորդ կողմի ծառայություններից արտահոսող հաշիվներ, ինչպիսիք են LinkedIn-ը, փորձելով նաև գուշակել դրանց օգտագործմամբ գաղտնաբառերը: որպես սեփական գրավոր կայքերի խոցելիության պեղումներ, ի դեպ, ըստ վիճակագրության, սա այսօր արտաքին հարձակման ամենախոստումնալից վեկտորն է: Ես անմիջապես կնշեմ ֆիլմի ատրճանակը, որը հետագայում կրակեց:
Այսպիսով, մենք գտանք երկու կայք, որոնք առանձնանում էին հարյուրավոր ծառայություններից: Այս կայքերը մեկ ընդհանուր բան ունեին. եթե դուք չեք զբաղվում ցանցի մանրակրկիտ հետախուզմամբ՝ ըստ տիրույթի, այլ փնտրում եք բաց նավահանգիստներ կամ թիրախավորում եք խոցելիության սկաները՝ օգտագործելով հայտնի IP տիրույթը, ապա այդ կայքերը կխուսափեն սկանավորումից և պարզապես չեն լինի: տեսանելի է առանց DNS անունը իմանալու: Միգուցե դրանք, համենայնդեպս, ավելի վաղ բաց են թողնվել, և մեր ավտոմատ գործիքները դրանցում որևէ խնդիր չեն հայտնաբերել, նույնիսկ եթե դրանք ուղղակիորեն ուղարկվել են ռեսուրս:
Ի դեպ, այն մասին, թե ընդհանրապես ինչ են գտել նախկինում գործարկված սկաներները։ Հիշեցնեմ. որոշ մարդկանց համար «pentest»-ը համարժեք է «ավտոմատ սկանավորման»: Բայց այս նախագծի սկաներները ոչինչ չասացին: Դե, առավելագույնը ցուցադրվել է միջին խոցելիությամբ (խստության առումով 3-ից 5-ը). որոշ ծառայություններում վատ TLS վկայագիր կամ հնացած գաղտնագրման ալգորիթմներ, իսկ շատ կայքերում՝ Clickjacking: Բայց դա ձեզ չի հասցնի ձեր նպատակին: Թերևս սկաներներն այստեղ ավելի օգտակար լինեին, բայց հիշեցնեմ, որ հաճախորդն ինքը կարող է գնել նման ծրագրեր և փորձարկել իրեն դրանցով, և, դատելով տխուր արդյունքներից, նա արդեն ստուգել է։
Վերադառնանք «անոմալ» կայքերին։ Առաջինը տեղական Վիքիի նման մի բան է ոչ ստանդարտ հասցեով, բայց այս հոդվածում թող լինի wiki.company[.]ru: Նա նաև անմիջապես խնդրեց մուտք և գաղտնաբառ, բայց բրաուզերում NTLM-ի միջոցով: Օգտատիրոջ համար սա ասկետիկ պատուհանի տեսք ունի, որը խնդրում է մուտքագրել օգտվողի անուն և գաղտնաբառ: Եվ սա վատ պրակտիկա է։
Մի փոքրիկ նշում. NTLM-ը պարագծային կայքերում վատ է մի շարք պատճառներով: Առաջին պատճառն այն է, որ Active Directory տիրույթի անունը բացահայտված է: Մեր օրինակում պարզվեց նաև company.ru-ն, ինչպես «արտաքին» DNS անվանումը։ Իմանալով դա, դուք կարող եք զգուշորեն պատրաստել ինչ-որ վնասակար բան, որպեսզի այն կատարվի միայն կազմակերպության տիրույթի մեքենայի վրա, և ոչ թե ինչ-որ ավազատուփում: Երկրորդ, նույնականացումը ուղղակիորեն անցնում է տիրույթի վերահսկիչի միջոցով NTLM-ի միջոցով (զարմանք, չէ՞), ցանցի «ներքին» քաղաքականության բոլոր հատկանիշներով, ներառյալ հաշիվների արգելափակումը գաղտնաբառի մուտքագրման փորձերի քանակի գերազանցումից: Եթե հարձակվողը պարզի մուտքերը, նա կփորձի գաղտնաբառեր նրանց համար: Եթե դուք կազմաձևված եք այնպես, որ արգելափակեք հաշիվները սխալ գաղտնաբառերի մուտքագրումից, այն կաշխատի և հաշիվը կարգելափակվի: Երրորդ, անհնար է երկրորդ գործոն ավելացնել նման նույնականացմանը: Եթե ընթերցողներից որևէ մեկը դեռ գիտի, թե ինչպես, խնդրում եմ տեղեկացրեք ինձ, դա իսկապես հետաքրքիր է: Չորրորդ, խոցելիություն «pas-the-hash» գրոհների նկատմամբ: ADFS-ը, ի թիվս այլ բաների, հորինվել է այս ամենից պաշտպանվելու համար։
Microsoft-ի արտադրանքի մեկ վատ հատկություն կա. նույնիսկ եթե դուք հատուկ չեք հրապարակել այդպիսի NTLM, այն կտեղադրվի լռելյայնորեն OWA-ում և Lync-ում, առնվազն:
Ի դեպ, այս հոդվածի հեղինակը մեկ անգամ նույն մեթոդով մեկ ժամում պատահաբար արգելափակել է մեկ խոշոր բանկի աշխատակիցների մոտավորապես 1000 հաշիվ, իսկ հետո մի տեսակ գունատ տեսք է ունեցել։ Բանկի ՏՏ ծառայությունները նույնպես գունատ էին, բայց ամեն ինչ լավ և ադեկվատ ավարտվեց, մեզ նույնիսկ գովաբանեցին, որ առաջինն ենք գտել այս խնդիրը և հրահրել ենք արագ և վճռական լուծում:
Երկրորդ կայքը ուներ «ակնհայտորեն ինչ-որ ազգանուն.company.ru» հասցեն: Գտել եմ Google-ի միջոցով, նման բան 10-րդ էջում: Դիզայնը XNUMX-ականների սկզբի կեսերից էր, և մի հարգարժան մարդ այն նայում էր գլխավոր էջից, մոտավորապես այսպիսին.
Այստեղ ես վերցրեցի մի կադր «Շան սիրտը», բայց հավատացեք, որ այն անորոշ նման էր, նույնիսկ գունային ձևավորումն էր նման երանգների։ Թող կայքը կոչվի preobrazhensky.company.ru.
Անձնական կայք էր... ուրոլոգի համար։ Ինձ հետաքրքրում էր, թե ինչ է անում ուրոլոգի կայքը բարձր տեխնոլոգիական ընկերության ենթադոմեյնում: Google-ի արագ ուսումնասիրությունը ցույց տվեց, որ այս բժիշկը մեր հաճախորդների իրավաբանական անձանցից մեկի համահիմնադիրն էր և նույնիսկ կանոնադրական կապիտալում մոտ 1000 ռուբլի է ներդրել: Կայքը հավանաբար ստեղծվել է շատ տարիներ առաջ, և հաճախորդի սերվերի ռեսուրսներն օգտագործվել են որպես հոսթինգ։ Կայքը վաղուց կորցրել է իր արդիականությունը, բայց ինչ-ինչ պատճառներով երկար ժամանակ մնացել է աշխատելու:
Խոցելիության առումով կայքը ինքնին ապահով էր։ Առաջ նայելով, կասեմ, որ դա ստատիկ տեղեկատվության մի ամբողջություն էր՝ պարզ html էջեր՝ երիկամների և միզապարկի տեսքով տեղադրված նկարազարդումներով։ Նման կայք «կոտրելն» անիմաստ է։
Բայց տակի վեբ սերվերն ավելի հետաքրքիր էր։ Դատելով HTTP Server վերնագրից՝ այն ուներ IIS 6.0, ինչը նշանակում է, որ որպես օպերացիոն համակարգ օգտագործում էր Windows 2003: Սկաները նախկինում պարզել էր, որ այս կոնկրետ ուրոլոգի կայքը, ի տարբերություն նույն վեբ սերվերի այլ վիրտուալ հոստերի, արձագանքել է PROPFIND հրամանին, ինչը նշանակում է, որ այն աշխատում է WebDAV-ով: Ի դեպ, սկաները վերադարձրեց այս տեղեկատվությունը Info նշանով (սկաների հաշվետվությունների լեզվով սա ամենացածր վտանգն է) - նման բաները սովորաբար պարզապես բաց են թողնում: Համակցությամբ, սա տվեց հետաքրքիր էֆեկտ, որը բացահայտվեց միայն Google-ում հերթական փորփրումից հետո՝ հազվագյուտ բուֆերային հոսող խոցելիություն՝ կապված Shadow Brokers հավաքածուի հետ, մասնավորապես CVE-2017-7269, որն արդեն ուներ պատրաստի շահագործում: Այլ կերպ ասած, խնդիրներ կլինեն, եթե ունեք Windows 2003, և WebDAV-ն աշխատում է IIS-ով: Թեև Windows 2003-ի արտադրությունը 2018 թվականին գործարկելն ինքնին խնդիր է:
Exploit-ը ավարտվեց Metasploit-ում և անմիջապես փորձարկվեց մի բեռով, որն ուղարկեց DNS հարցում վերահսկվող ծառայությանը. Burp Collaborator-ն ավանդաբար օգտագործվում է DNS հարցումները որսալու համար: Ի զարմանս ինձ, այն աշխատեց առաջին անգամ. ստացվեց DNS նոկաուտ: Այնուհետև փորձ արվեց ստեղծել հետադարձ կապ 80 պորտի միջոցով (այսինքն՝ ցանցային միացում սերվերից հարձակվողին, զոհի հոսթի վրա cmd.exe հասանելիությամբ), բայց հետո տեղի ունեցավ ֆիասկո: Կապը չհասավ, և կայքից օգտվելու երրորդ փորձից հետո բոլոր հետաքրքիր նկարների հետ միասին ընդմիշտ անհետացավ:
Սովորաբար դրան հաջորդում է նամակ՝ «հաճախորդ, արթնացիր, ամեն ինչ գցեցինք» ոճով։ Բայց մեզ ասացին, որ կայքը կապ չունի բիզնես գործընթացների հետ և այնտեղ աշխատում է առանց որևէ պատճառի, ինչպես ամբողջ սերվերը, և որ մենք կարող ենք օգտագործել այս ռեսուրսը, ինչպես ուզում ենք:
Մոտ մեկ օր անց կայքը հանկարծակի սկսեց աշխատել ինքնուրույն: WebDAV-ից IIS 6.0-ի վրա նստարան կառուցելով, ես պարզեցի, որ լռելյայն կարգավորումն է՝ վերագործարկել IIS աշխատողի գործընթացները յուրաքանչյուր 30 ժամը մեկ: Այսինքն, երբ հսկողությունը դուրս եկավ shellcode-ից, IIS-ի աշխատողի պրոցեսն ավարտվեց, այնուհետև այն վերագործարկվեց մի քանի անգամ և հետո գնաց 30 ժամ հանգստանալու:
Քանի որ tcp-ին հետադարձ կապը ձախողվեց առաջին անգամ, ես այս խնդիրը վերագրեցի փակ պորտին: Այսինքն, նա ենթադրում էր ինչ-որ տեսակի firewall-ի առկայությունը, որը թույլ չէր տալիս ելքային կապերն անցնել դրսում։ Ես սկսեցի գործարկել shellcodes, որոնք որոնում էին բազմաթիվ tcp և udp նավահանգիստներ, ոչ մի ազդեցություն չկար: Հակադարձ կապի բեռնումները http(s)-ի միջոցով Metasploit-ից չաշխատեցին - meterpreter/reverse_http(s): Հանկարծ կապ հաստատվեց նույն նավահանգստի 80-ի հետ, բայց անմիջապես դադարեցվեց: Ես դա վերագրեցի դեռևս երևակայական IPS-ի գործողությանը, որին դուր չեկավ չափիչի տրաֆիկը։ Հաշվի առնելով այն փաստը, որ մաքուր tcp կապը 80-րդ նավահանգստին չի անցել, բայց http կապն անցել է, ես եզրակացրի, որ http պրոքսի-ն ինչ-որ կերպ կազմաձևված է համակարգում:
Ես նույնիսկ փորձեցի meterpreter-ը DNS-ի միջոցով (շնորհակալություն ձեր ջանքերի համար փրկեցիք բազմաթիվ նախագծեր), հիշեցնելով առաջին հաջողությունը, բայց այն նույնիսկ չաշխատեց ստենդի վրա. shellcode-ը չափազանց ծավալուն էր այս խոցելիության համար:
Իրականում այն այսպիսի տեսք ուներ՝ 3-4 հարձակման փորձ 5 րոպեի ընթացքում, հետո սպասել 30 ժամ։ Եվ այսպես երեք շաբաթ անընդմեջ։ Ես նույնիսկ հիշեցում եմ դրել, որպեսզի ժամանակ չկորցնեմ։ Բացի այդ, տարբերություն կար թեստային և արտադրական միջավայրերի վարքագծի մեջ. այս խոցելիության համար կային երկու նմանատիպ շահագործում, մեկը Metasploit-ից, երկրորդը ինտերնետից՝ փոխարկված Shadow Brokers տարբերակից: Այսպիսով, մարտական փորձարկվեց միայն Metasploit-ը, իսկ նստարանին փորձարկվեց միայն երկրորդը, որն էլ ավելի դժվարացրեց վրիպազերծումը և ուղեղը ջարդեց:
Ի վերջո, shellcode-ը, որը http-ի միջոցով ներբեռնում էր exe ֆայլ տվյալ սերվերից և գործարկում այն թիրախային համակարգում, արդյունավետ էր: Shellcode-ը բավական փոքր էր, որպեսզի տեղավորվեր, բայց գոնե այն աշխատում էր: Քանի որ սերվերին ընդհանրապես դուր չի եկել TCP տրաֆիկը, և http(s)-ը ստուգվել է չափիչի առկայության համար, ես որոշեցի, որ ամենաարագ ճանապարհը exe ֆայլը ներբեռնելն է, որը պարունակում է DNS-meterpreter այս shellcode-ի միջոցով:
Այստեղ նորից խնդիր առաջացավ՝ exe ֆայլ ներբեռնելիս և, ինչպես ցույց տվեցին փորձերը, անկախ նրանից, թե որից, ներբեռնումն ընդհատվեց։ Կրկին իմ սերվերի և ուրոլոգի միջև անվտանգության որոշ սարքի դուր չեկավ http տրաֆիկը, որի ներսում կա exe: Թվում էր, թե «արագ» լուծումը shellcode-ի փոփոխությունն էր, որպեսզի այն արագորեն մթագնի http տրաֆիկը, որպեսզի վերացական երկուական տվյալները փոխանցվեն exe-ի փոխարեն: Ի վերջո, հարձակումը հաջողվեց, վերահսկումը ստացվեց բարակ DNS ալիքի միջոցով.
Անմիջապես պարզ դարձավ, որ ես ունեմ IIS-ի աշխատանքային հոսքի ամենահիմնական իրավունքները, որոնք ինձ թույլ են տալիս ոչինչ անել: Ահա թե ինչ տեսք ուներ Metasploit վահանակի վրա.
Բոլոր pentest մեթոդոլոգիաները կտրականապես հուշում են, որ դուք պետք է ավելացնեք իրավունքները, երբ մուտք գործեք: Ես սովորաբար դա տեղական մակարդակով չեմ անում, քանի որ հենց առաջին մուտքը դիտվում է որպես ցանցի մուտքի կետ, և նույն ցանցում մեկ այլ մեքենայի վտանգի ենթարկելը սովորաբար ավելի հեշտ և արագ է, քան գոյություն ունեցող հոսթի արտոնությունների ավելացումը: Բայց այստեղ դա այդպես չէ, քանի որ DNS ալիքը շատ նեղ է, և այն թույլ չի տա, որ տրաֆիկը մաքրվի:
Ենթադրելով, որ այս Windows 2003 սերվերը չի վերանորոգվել հայտնի MS17-010 խոցելիության համար, ես թունել եմ երթևեկությունը դեպի 445/TCP նավահանգիստ meterpreter DNS թունելի միջոցով դեպի localhost (այո, դա նույնպես հնարավոր է) և փորձում եմ գործարկել նախկինում ներբեռնված exe-ը: խոցելիությունը։ Հարձակումն աշխատում է, ես ստանում եմ երկրորդ կապը, բայց SYSTEM իրավունքներով։
Հետաքրքիր է, որ նրանք դեռ փորձում էին պաշտպանել սերվերը MS17-010-ից. այն ուներ խոցելի ցանցային ծառայություններ, որոնք անջատված էին արտաքին ինտերֆեյսի վրա: Սա պաշտպանում է ցանցի վրա հարձակումներից, բայց ներսից հարձակումը localhost-ի վրա աշխատեց, քանի որ դուք չեք կարող արագ անջատել SMB-ը localhost-ի վրա:
Հաջորդիվ բացահայտվում են նոր հետաքրքիր մանրամասներ.
- Ունենալով ՀԱՄԱԿԱՐԳԻ իրավունքներ՝ դուք կարող եք հեշտությամբ հետադարձ կապ հաստատել TCP-ի միջոցով: Ակնհայտ է, որ ուղղակի TCP-ն անջատելը խիստ խնդիր է սահմանափակ IIS օգտագործողի համար: Spoiler. IIS-ի օգտատերերի տրաֆիկը ինչ-որ կերպ փաթաթված էր տեղական ISA Proxy-ով երկու ուղղություններով: Թե կոնկրետ ինչպես է այն աշխատում, չեմ վերարտադրել։
- Ես որոշակի «DMZ»-ում եմ (և սա Active Directory տիրույթ չէ, այլ WORKGROUP) - տրամաբանական է թվում: Բայց սպասվող մասնավոր («մոխրագույն») IP հասցեի փոխարեն ես ունեմ ամբողջովին «սպիտակ» IP հասցե, ճիշտ նույնը, ինչ նախկինում հարձակվել եմ: Սա նշանակում է, որ ընկերությունն այնքան հին է IPv4 հասցեների աշխարհում, որ կարող է իրեն թույլ տալ պահպանել DMZ գոտի 128 «սպիտակ» հասցեների համար՝ առանց NAT սխեմայի, ինչպես ներկայացված է Cisco-ի 2005 թվականի ձեռնարկներում:
Քանի որ սերվերը հին է, Mimikatz-ը երաշխավորված է աշխատել անմիջապես հիշողությունից.
Ես ստանում եմ տեղական ադմինիստրատորի գաղտնաբառը, TCP-ի միջոցով անցկացնում եմ RDP տրաֆիկը և մուտք եմ գործում հարմարավետ աշխատասեղան: Քանի որ սերվերի հետ կարող էի անել այն, ինչ ուզում էի, հանեցի հակավիրուսը և պարզեցի, որ սերվերը հասանելի է ինտերնետից միայն TCP 80 և 443 պորտերի միջոցով, իսկ 443-ը զբաղված չէ: Ես ստեղծեցի OpenVPN սերվեր 443-ի վրա, ավելացնում եմ NAT գործառույթները իմ VPN տրաֆիկի համար և իմ OpenVPN-ի միջոցով ուղղակի մուտք եմ ստանում DMZ ցանց անսահմանափակ ձևով: Հատկանշական է, որ ISA-ն, ունենալով որոշ ոչ հաշմանդամ IPS գործառույթներ, արգելափակել է իմ տրաֆիկը պորտի սկանավորման միջոցով, ինչի համար այն պետք է փոխարինվեր ավելի պարզ և համապատասխանող RRAS-ով։ Այսպիսով, գրպանները երբեմն դեռ պետք է տնօրինեն ամենատարբեր բաներ:
Ուշադիր ընթերցողը կհարցնի. «Ի՞նչ կասեք երկրորդ կայքի մասին՝ NTLM վավերացմամբ վիքիի մասին, որի մասին այդքան շատ է գրվել»: Այս մասին ավելի ուշ:
Մաս 2. Դեռ չե՞ք գաղտնագրում: Ապա մենք արդեն գալիս ենք ձեզ մոտ այստեղ
Այսպիսով, կա մուտք դեպի DMZ ցանցի հատված: Դուք պետք է գնաք տիրույթի ադմինիստրատորին: Առաջին բանը, որ գալիս է մտքին, DMZ հատվածում ծառայությունների անվտանգությունն ավտոմատ կերպով ստուգելն է, հատկապես, որ դրանցից շատերն այժմ բաց են հետազոտության համար: Տիպիկ պատկեր ներթափանցման թեստի ժամանակ. արտաքին պարագիծն ավելի լավ պաշտպանված է, քան ներքին ծառայությունները, և մեծ ենթակառուցվածքի ներսում որևէ մուտք ձեռք բերելու դեպքում տիրույթում ընդլայնված իրավունքներ ստանալը շատ ավելի հեշտ է միայն այն պատճառով, որ այս տիրույթը սկսում է լինել։ գործիքներին հասանելի, և երկրորդ՝ մի քանի հազար հոսթ ունեցող ենթակառուցվածքում միշտ կլինեն մի քանի կարևոր խնդիր։
Ես լիցքավորում եմ սկաները DMZ-ի միջոցով OpenVPN թունելի միջոցով և սպասում: Ես բացում եմ հաշվետվությունը. նորից ոչ մի լուրջ բան, ըստ երևույթին, ինձնից առաջ ինչ-որ մեկն անցել է նույն մեթոդով։ Հաջորդ քայլը պետք է ուսումնասիրել, թե ինչպես են հաղորդակցվում DMZ ցանցի հյուրընկալողները: Դա անելու համար նախ գործարկեք սովորական Wireshark-ը և լսեք հեռարձակման հարցումները, հիմնականում ARP-ն: ARP փաթեթները հավաքվում էին ամբողջ օրը։ Պարզվում է, որ այս հատվածում օգտագործվում են մի քանի դարպասներ։ Սա ավելի ուշ օգտակար կլինի: Համատեղելով ARP հարցումների և պատասխանների տվյալները և նավահանգիստների սկանավորման տվյալները՝ ես գտա օգտատերերի տրաֆիկի ելքի կետերը տեղական ցանցից ի լրումն այն ծառայությունների, որոնք նախկինում հայտնի էին, ինչպիսիք են վեբը և փոստը:
Քանի որ այս պահին ես մուտք չունեի այլ համակարգեր և չունեի կորպորատիվ ծառայությունների մեկ հաշիվ, որոշվեց առնվազն որոշ հաշիվ հանել տրաֆիկից՝ օգտագործելով ARP Spoofing:
Cain&Abel-ը գործարկվել է ուրոլոգի սերվերում։ Հաշվի առնելով հայտնաբերված երթևեկության հոսքերը, ընտրվեցին մարդ-միջին հարձակման ամենախոստումնալից զույգերը, այնուհետև ցանցի որոշ տրաֆիկ ստացվեց կարճաժամկետ գործարկմամբ 5-10 րոպե, սերվերը վերագործարկելու ժամանակաչափով: սառեցման դեպքում. Ինչպես կատակում, երկու նորություն կար.
- Լավ. շատ հավատարմագրեր են բռնվել, և հարձակումն ընդհանուր առմամբ աշխատել է:
- Վատը. բոլոր հավատարմագրերը եղել են հաճախորդի սեփական հաճախորդներից: Աջակցման ծառայություններ մատուցելիս հաճախորդների մասնագետները միացել են հաճախորդների ծառայություններին, ովքեր միշտ չէ, որ կարգավորվել են երթևեկության կոդավորումը:
Արդյունքում ես ձեռք բերեցի բազմաթիվ հավատարմագրեր, որոնք անօգուտ էին նախագծի համատեքստում, բայց միանշանակ հետաքրքիր՝ որպես հարձակման վտանգի ցուցադրում։ Խոշոր ընկերությունների սահմանային երթուղիչները telnet-ով, փոխանցված վրիպազերծման http նավահանգիստները ներքին CRM բոլոր տվյալների հետ, ուղղակի մուտք դեպի RDP Windows XP-ից տեղական ցանցում և այլ խավարամտություն: Ստացվեց այսպես .
Ես նաև զվարճալի հնարավորություն եմ գտել տրաֆիկից նամակներ հավաքելու, այսպիսի մի բան. Սա պատրաստի նամակի օրինակ է, որը մեր հաճախորդից գնացել է իր հաճախորդի SMTP նավահանգիստ, կրկին առանց գաղտնագրման: Որոշ Անդրեյ խնդրում է իր անվանակցին նորից ուղարկել փաստաթղթերը, և այն վերբեռնվում է ամպային սկավառակի վրա՝ մուտքի, գաղտնաբառի և հղումով մեկ պատասխան նամակով.
Սա ևս մեկ հիշեցում է՝ գաղտնագրելու բոլոր ծառայությունները: Հայտնի չէ, թե կոնկրետ ով և երբ կկարդա և օգտագործի ձեր տվյալները՝ մատակարարը, մեկ այլ ընկերության համակարգի ադմինիստրատորը, թե՞ նման գրող: Ես լռում եմ այն մասին, որ շատ մարդիկ կարող են պարզապես գաղտնալսել չգաղտնագրված տրաֆիկը։
Չնայած թվացյալ հաջողությանը, դա մեզ չմոտեցրեց նպատակին։ Կարելի էր, իհարկե, երկար նստել ու արժեքավոր տեղեկություններ որսալ, բայց որ այնտեղ կհայտնվեր, փաստ չէ, իսկ հարձակումն ինքնին շատ ռիսկային է ցանցի ամբողջականության առումով։
Ծառայությունների մեջ հերթական ուսումնասիրությունից հետո մի հետաքրքիր միտք ծագեց. Կա նման օգտակար ծրագիր, որը կոչվում է Responder (այս անունով հեշտ է գտնել օգտագործման օրինակներ), որը հեռարձակման հարցումները «թունավորելով» կապեր է հրահրում մի շարք արձանագրությունների միջոցով, ինչպիսիք են SMB, HTTP, LDAP և այլն: տարբեր ձևերով, այնուհետև հարցնում է բոլորին, ովքեր միանում են նույնականացմանը և կարգավորում են այն այնպես, որ նույնականացումը տեղի ունենա NTLM-ի միջոցով և տուժողի համար թափանցիկ ռեժիմով: Ամենից հաճախ հարձակվողն այս կերպ հավաքում է NetNTLMv2 ձեռքսեղմումներ և դրանցից, օգտագործելով բառարան, արագ վերականգնում է օգտվողի տիրույթի գաղտնաբառերը: Այստեղ ես ուզում էի նման բան, բայց օգտատերերը նստում էին «պատի հետևում», ավելի ճիշտ, նրանք բաժանվում էին firewall-ով և մուտք էին գործում WEB Blue Coat պրոքսի կլաստերի միջոցով:
Հիշո՞ւմ եք, ես նշել էի, որ Active Directory տիրույթի անունը համընկնում է «արտաքին» տիրույթի հետ, այսինքն՝ company.ru-ն է։ Այսպիսով, Windows-ը, ավելի ճիշտ՝ Internet Explorer-ը (և Edge-ը և Chrome-ը), օգտվողին թույլ են տալիս թափանցիկ նույնականացնել HTTP-ում NTLM-ի միջոցով, եթե նրանք համարում են, որ կայքը գտնվում է ինչ-որ «Ինտրանետի գոտում»: «Ինտրանետ»-ի նշաններից մեկը «մոխրագույն» IP հասցեի կամ կարճ DNS անունի մուտքն է, այսինքն՝ առանց կետերի: Քանի որ նրանք ունեին սերվեր «սպիտակ» IP-ով և DNS անունով preobrazhensky.company.ru, և դոմեյն մեքենաները սովորաբար ստանում են Active Directory տիրույթի վերջածանցը DHCP-ի միջոցով՝ պարզեցված անվան մուտքագրման համար, նրանք պետք է գրեին URL-ը միայն հասցեի տողում: , որպեսզի նրանք գտնեն ճիշտ ճանապարհը դեպի վտանգված ուրոլոգի սերվեր՝ չմոռանալով, որ այն այժմ կոչվում է «Ինտրանետ»։ Այսինքն՝ միևնույն ժամանակ ինձ տալով օգտատիրոջ NTLM ձեռքսեղմումը՝ առանց նրա իմացության: Մնում է միայն ստիպել հաճախորդների բրաուզերներին մտածել այս սերվերի հետ կապվելու հրատապ անհրաժեշտության մասին:
Հրաշալի Intercepter-NG կոմունալը եկավ փրկության (շնորհակալություն ). Այն թույլ էր տալիս արագորեն փոխել երթևեկությունը և հիանալի աշխատեց Windows 2003-ում: Այն նույնիսկ ուներ առանձին գործառույթ՝ միայն JavaScript ֆայլերը երթևեկության հոսքում փոփոխելու համար: Նախատեսվում էր մի տեսակ զանգվածային Cross-Site Scripting:
Blue Coat պրոքսիները, որոնց միջոցով օգտատերերը մուտք էին գործում գլոբալ WEB, պարբերաբար պահում էին ստատիկ բովանդակությունը: Երթևեկությունը գաղտնալսելով՝ պարզ էր, որ նրանք աշխատում էին շուրջօրյա՝ անվերջ պահանջելով հաճախակի օգտագործվող ստատիկ՝ պիկ ժամերին բովանդակության ցուցադրումն արագացնելու համար: Բացի այդ, BlueCoat-ն ուներ կոնկրետ User-Agent, որը հստակորեն տարբերում էր այն իրական օգտագործողից:
Նախապատրաստվել է Javascript-ը, որը Intercepter-NG-ի միջոցով իրականացվում էր մեկ ժամ գիշերը Blue Coat-ի JS ֆայլերով յուրաքանչյուր պատասխանի համար։ Սցենարն արեց հետևյալը.
- Որոշվել է ընթացիկ զննարկիչը User-Agent-ի կողմից: Եթե դա Internet Explorer-ը, Edge-ը կամ Chrome-ն էր, այն շարունակում էր աշխատել:
- Սպասեցի մինչև էջի DOM-ը ձևավորվի։
- Անտեսանելի պատկեր է տեղադրվել DOM-ում՝ ձևի src հատկանիշով :8080/NNNNNN.png, որտեղ NNN-ը կամայական թվեր են, որպեսզի BlueCoat-ը այն չքեշավորի:
- Սահմանեք գլոբալ դրոշակի փոփոխական՝ ցույց տալու համար, որ ներարկումն ավարտված է, և այլևս նկարներ տեղադրելու կարիք չկա:
Զննարկիչը փորձեց բեռնել այս պատկերը. վտանգված սերվերի 8080 նավահանգստում TCP թունելը սպասում էր այն իմ նոութբուքին, որտեղ աշխատում էր նույն Responder-ը, որը պահանջում էր զննարկիչից մուտք գործել NTLM-ի միջոցով:
Դատելով Responder-ի տեղեկամատյաններից՝ մարդիկ առավոտյան գալիս էին աշխատանքի, միացնում իրենց աշխատատեղերը, այնուհետև զանգվածաբար և աննկատ սկսեցին այցելել ուրոլոգի սերվեր՝ չմոռանալով «թափել» NTLM ձեռքսեղմումները: Ամբողջ օրը ձեռքսեղմումներն անձրև էին գալիս և ակնհայտորեն նյութ էին կուտակվում գաղտնաբառերը վերականգնելու ակնհայտ հաջող հարձակման համար: Պատասխանողի տեղեկամատյաններն այսպիսի տեսք ունեին.
Օգտատերերի կողմից զանգվածային գաղտնի այցելություններ ուրոլոգի սերվեր
Դուք հավանաբար արդեն նկատել եք, որ այս ամբողջ պատմությունը կառուցված է «ամեն ինչ լավ էր, բայց հետո եղավ խայտառակություն, հետո հաղթահարում, և հետո ամեն ինչ հաջողվեց» սկզբունքով: Ուրեմն, այստեղ խայտառակություն կար. Հիսուն եզակի ձեռքսեղմումներից ոչ մեկը չբացահայտվեց: Եվ սա հաշվի է առնում այն փաստը, որ նույնիսկ մեռած պրոցեսորով նոթբուքի վրա այս NTLMv2 ձեռքսեղմումները մշակվում են վայրկյանում մի քանի հարյուր միլիոն փորձի արագությամբ։
Ես ստիպված էի զինվել գաղտնաբառի մուտացիայի տեխնիկայով, վիդեո քարտով, ավելի հաստ բառարանով ու սպասել։ Երկար ժամանակ անց բացահայտվեցին «Q11111111....1111111q» ձևի գաղտնաբառերով մի քանի աքաունթ, ինչը հուշում է, որ բոլոր օգտատերերը ժամանակին ստիպված են եղել տարբեր տառերով գաղտնաբառ հորինել, ինչը նույնպես ենթադրվում էր. լինել բարդ. Բայց դուք չեք կարող խաբել փորձառու օգտատիրոջը, և ահա թե ինչպես նա ավելի հեշտ դարձրեց իր համար հիշելը: Ընդհանուր առմամբ, վտանգվել է մոտ 5 հաշիվ, և դրանցից միայն մեկն ուներ ծառայությունների արժեքավոր իրավունքներ։
Մաս 3. Ռոսկոմնադզորը պատասխան հարված է հասցնում
Այսպիսով, ստացվեցին առաջին դոմենային հաշիվները։ Եթե երկար ընթերցումից հետո այս պահին չեք քնել, հավանաբար կհիշեք, որ ես նշեցի մի ծառայություն, որը վավերացման երկրորդ գործոն չի պահանջում. դա NTLM վավերացմամբ վիքի է: Իհարկե, առաջին բանը, որ պետք է անել, այնտեղ մտնելն էր։ Ներքին գիտելիքների բազան փորփրելը արագ արդյունք տվեց.
- Ընկերությունն ունի WiFi ցանց՝ նույնականացմամբ՝ օգտագործելով դոմենային հաշիվներ՝ տեղական ցանցին հասանելիությամբ: Տվյալների ներկայիս հավաքածուով սա արդեն հարձակման գործող վեկտոր է, բայց դուք պետք է ոտքերով գնաք գրասենյակ և գտնվեք հաճախորդի գրասենյակի տարածքում ինչ-որ տեղ:
- Ես գտա մի հրահանգ, համաձայն որի կար մի ծառայություն, որը թույլ էր տալիս... ինքնուրույն գրանցել «երկրորդ գործոնի» իսկությունը հաստատող սարք, եթե օգտատերը գտնվում է տեղական ցանցում և վստահորեն հիշում է իր տիրույթի մուտքն ու գաղտնաբառը: Այս դեպքում «ներսում» և «դրսում» որոշվում էին այս ծառայության նավահանգստի օգտատիրոջ հասանելիությամբ: Նավահանգիստը հասանելի չէր ինտերնետից, բայց բավականին հասանելի էր DMZ-ի միջոցով:
Իհարկե, վտանգված հաշվին անմիջապես ավելացվեց «երկրորդ գործոնը»՝ իմ հեռախոսի հավելվածի տեսքով: Կար մի ծրագիր, որը կարող էր կա՛մ բարձրաձայն «հաստատել»/«չհաստատել» կոճակներով հեռախոսին ուղարկելու հարցում, կա՛մ անաղմուկ ցուցադրել OTP կոդը էկրանին հետագա անկախ մուտքագրման համար: Ընդ որում, առաջին մեթոդը հրահանգներով ենթադրվում էր, որ միակ ճիշտն էր, բայց այն չաշխատեց՝ ի տարբերություն OTP մեթոդի։
«Երկրորդ գործոնը» կոտրված լինելով, ես կարողացա մուտք գործել Outlook Web Access փոստ և հեռավոր մուտք Citrix Netscaler Gateway-ում: Outlook-ում փոստում անակնկալ կար.
Այս հազվագյուտ կադրում կարող եք տեսնել, թե ինչպես է Ռոսկոմնադզորն օգնում գրոհայիններին
Սրանք Telegram-ի հայտնի «երկրպագուների» արգելափակումից հետո առաջին ամիսներն էին, երբ հազարավոր հասցեներով ամբողջ ցանցերը անխուսափելիորեն անհետացան մուտքից: Պարզ դարձավ, թե ինչու անմիջապես չաշխատեց հրում, և ինչու իմ «զոհը» ահազանգ չհնչեց, քանի որ նրանք սկսեցին օգտագործել իր հաշիվը բաց ժամերին:
Ցանկացած ոք, ով ծանոթ է Citrix Netscaler-ին, պատկերացնում է, որ այն սովորաբար իրականացվում է այնպես, որ օգտագործողին կարող է փոխանցվել միայն նկարի միջերեսը՝ փորձելով նրան չտալ երրորդ կողմի հավելվածներ գործարկելու և տվյալներ փոխանցելու գործիքներ՝ ամեն կերպ սահմանափակելով գործողությունները: ստանդարտ կառավարման պատյանների միջոցով: Իմ «զոհը», իր զբաղմունքի պատճառով, ստացել է ընդամենը 1C.
1C ինտերֆեյսը մի փոքր շրջելուց հետո ես պարզեցի, որ այնտեղ կան արտաքին մշակման մոդուլներ։ Նրանք կարող են բեռնվել ինտերֆեյսից, և դրանք կկատարվեն հաճախորդի կամ սերվերի վրա՝ կախված իրավունքներից և կարգավորումներից:
Ես խնդրեցի իմ 1C ծրագրավորող ընկերներին ստեղծել պրոցեսինգ, որը կընդունի տողը և կկատարի այն: 1C լեզվով գործընթաց սկսելը մոտավորապես այսպիսի տեսք ունի (վերցված է ինտերնետից): Համաձա՞յն եք, որ 1C լեզվի շարահյուսությունը զարմացնում է ռուսախոս մարդկանց իր ինքնաբուխությամբ։
Մշակումը կատարյալ կատարվեց, պարզվեց, որ գրողներն անվանում են «կեղև». դրա միջոցով գործարկվեց Internet Explorer-ը:
Ավելի վաղ փոստում հայտնաբերվել էր մի համակարգի հասցեն, որը թույլ է տալիս պատվիրել տարածքի տոմսեր։ Ես պատվիրեցի անցում, եթե ստիպված լինեի օգտագործել WiFi հարձակման վեկտորը:
Ինտերնետում խոսվում է այն մասին, որ հաճախորդի գրասենյակում դեռևս կար անվճար համեղ սնունդ, բայց ես դեռ նախընտրեցի հարձակումը զարգացնել հեռակա կարգով, ավելի հանգիստ է:
AppLocker-ը ակտիվացել է Citrix-ով աշխատող հավելվածի սերվերում, սակայն այն շրջանցվել է: Նույն Meterpreter-ը բեռնվել և գործարկվել է DNS-ի միջոցով, քանի որ http(s) տարբերակները չէին ուզում միանալ, և ես այդ պահին չգիտեի ներքին պրոքսի հասցեն։ Ի դեպ, այս պահից սկսած, արտաքին պենեստը ըստ էության ամբողջությամբ վերածվեց ներքինի։
Մաս 4. Օգտատերերի համար ադմինիստրատորի իրավունքները վատն են, լա՞վ:
Դոմեյն օգտագործողի նստաշրջանի վրա վերահսկողություն ձեռք բերելու ժամանակ pentester-ի առաջին խնդիրը տիրույթում իրավունքների մասին բոլոր տեղեկությունները հավաքելն է: Կա BloodHound կոմունալ ծրագիր, որը թույլ է տալիս ավտոմատ կերպով ներբեռնել օգտատերերի, համակարգիչների, անվտանգության խմբերի մասին տեղեկությունները LDAP արձանագրության միջոցով տիրույթի վերահսկիչից և SMB-ի միջոցով՝ տեղեկատվություն այն մասին, թե որ օգտատերը վերջերս է մուտք գործել, որտեղ և ով է տեղական ադմինիստրատորը:
Դոմենի ադմինիստրատորի իրավունքները բռնագրավելու տիպիկ տեխնիկան պարզեցված է թվում որպես միապաղաղ գործողությունների ցիկլ.
- Մենք գնում ենք տիրույթի համակարգիչներ, որտեղ կան տեղական ադմինիստրատորի իրավունքներ՝ հիմնված արդեն գրավված տիրույթի հաշիվների վրա:
- Մենք գործարկում ենք Mimikatz-ը և ստանում քեշավորված գաղտնաբառեր, Kerberos-ի տոմսեր և NTLM դոմենային հաշիվների հեշեր, որոնք վերջերս մուտք են գործել այս համակարգ: Կամ մենք հեռացնում ենք lsass.exe գործընթացի հիշողության պատկերը և նույնն անում ենք մեր կողմից: Սա լավ է աշխատում 2012R2/Windows 8.1-ից փոքր Windows-ի հետ՝ լռելյայն կարգավորումներով:
- Մենք որոշում ենք, թե որտեղ են վտանգված հաշիվները տեղական ադմինիստրատորի իրավունքներ: Մենք կրկնում ենք առաջին կետը. Ինչ-որ փուլում մենք ձեռք ենք բերում ադմինիստրատորի իրավունքներ ամբողջ տիրույթի համար:
«Ցիկլի վերջը», ինչպես կգրեին այստեղ 1C ծրագրավորողները:
Այսպիսով, պարզվեց, որ մեր օգտատերը տեղական ադմինիստրատոր է Windows 7-ով ընդամենը մեկ հոսթի վրա, որի անունը ներառում էր «VDI» կամ «Վիրտուալ աշխատասեղանի ենթակառուցվածք» բառը, անձնական վիրտուալ մեքենաներ: Հավանաբար, VDI ծառայության դիզայները նկատի ուներ, որ քանի որ VDI-ն օգտագործողի անձնական օպերացիոն համակարգն է, նույնիսկ եթե օգտատերը փոխում է ծրագրային միջավայրը այնպես, ինչպես ցանկանում է, հոսթը դեռ կարող է «վերաբեռնվել»: Ես էլ մտածեցի, որ ընդհանուր առմամբ գաղափարը լավն էր, գնացի այս անձնական VDI հաղորդավարի մոտ և այնտեղ բույն արեցի.
- Ես այնտեղ տեղադրեցի OpenVPN հաճախորդը, որը Ինտերնետով թունել արեց դեպի իմ սերվերը. Հաճախորդին պետք էր ստիպել անցնել նույն Blue Coat-ի միջով տիրույթի նույնականացումով, բայց OpenVPN-ն դա արեց, ինչպես ասում են, «դուրս»:
- Տեղադրվել է OpenSSH VDI-ում: Դե, իսկապես, ինչ է Windows 7-ն առանց SSH-ի:
Ահա թե ինչ տեսք ուներ այն ուղիղ եթերում. Հիշեցնեմ, որ այս ամենը պետք է արվի Citrix-ի և 1C-ի միջոցով.
Հարևան համակարգիչներ մուտք գործելը խթանելու տեխնիկաներից մեկը համապատասխանության համար տեղական ադմինիստրատորի գաղտնաբառերի ստուգումն է: Այստեղ բախտն անմիջապես սպասեց. լռելյայն տեղական ադմինիստրատորի NTLM հեշին (որին հանկարծ անվանեցին Ադմինիստրատոր) հարձակման միջոցով մոտեցվեց հարևան VDI հյուրընկալողներին, որոնցից մի քանի հարյուրը կար: Իհարկե, հարձակումն անմիջապես հարվածեց նրանց։
Ահա, որտեղ VDI-ի ադմինիստրատորները երկու անգամ կրակեցին իրենց ոտքին.
- Առաջին անգամն այն էր, երբ VDI մեքենաները չներառվեցին LAPS-ի տակ՝ ըստ էության պահպանելով նույն տեղական ադմինիստրատորի գաղտնաբառը պատկերից, որը զանգվածաբար տեղադրվել էր VDI-ում:
- Լռելյայն ադմինիստրատորը միակ տեղական հաշիվն է, որը խոցելի է «pas-the-hash» հարձակումների նկատմամբ: Նույնիսկ նույն գաղտնաբառով հնարավոր կլինի խուսափել զանգվածային փոխզիջումներից՝ ստեղծելով երկրորդ տեղական ադմինիստրատորի հաշիվ բարդ պատահական գաղտնաբառով և արգելափակելով կանխադրվածը:
Ինչու՞ կա SSH ծառայություն այդ Windows-ում: Շատ պարզ. այժմ OpenSSH սերվերը ոչ միայն տրամադրում է հարմար ինտերակտիվ հրամանի վահանակ՝ առանց օգտվողի աշխատանքին միջամտելու, այլ նաև socks5 վստահված անձի VDI-ում: Այս գուլպաների միջոցով ես միացա SMB-ի միջոցով և հավաքեցի քեշավորված հաշիվներ այս հարյուրավոր VDI մեքենաներից, այնուհետև փնտրեցի դեպի տիրույթի ադմինիստրատոր տանող ուղին՝ օգտագործելով դրանք BloodHound գրաֆիկներում: Իմ տրամադրության տակ ունենալով հարյուրավոր հյուրընկալողներ, ես բավականին արագ գտա այս ճանապարհը: Դոմենի ադմինիստրատորի իրավունքները ձեռք են բերվել:
Ահա մի նկար համացանցից, որը ցույց է տալիս նմանատիպ որոնում: Միացումները ցույց են տալիս, թե ով որտեղ է ադմինիստրատորը և ով որտեղ է մուտք գործել:
Ի դեպ, հիշեք պայմանը նախագծի սկզբից՝ «մի օգտագործեք սոցիալական ճարտարագիտություն»: Այսպիսով, ես առաջարկում եմ մտածել, թե որքանով կկտրվի այս ամբողջ Բոլիվուդը հատուկ էֆեկտներով, եթե դեռ հնարավոր լիներ օգտագործել սովորական ֆիշինգ: Բայց անձամբ ինձ համար շատ հետաքրքիր էր այս ամենն անելը։ Հուսով եմ, որ ձեզ դուր եկավ սա կարդալը: Իհարկե, ոչ բոլոր նախագիծն է այդքան ինտրիգային թվում, բայց աշխատանքն ընդհանուր առմամբ շատ դժվար է և թույլ չի տալիս, որ այն լճանա:
Հավանաբար ինչ-որ մեկի մոտ հարց կառաջանա՝ ինչպե՞ս պաշտպանվել ձեզ։ Նույնիսկ այս հոդվածը նկարագրում է բազմաթիվ տեխնիկա, որոնցից շատերի մասին Windows ադմինիստրատորները նույնիսկ չգիտեն: Այնուամենայնիվ, ես առաջարկում եմ դրանք դիտարկել կեղծ սկզբունքների և տեղեկատվական անվտանգության միջոցների տեսանկյունից.
- մի օգտագործեք հնացած ծրագրեր (հիշո՞ւմ եք Windows 2003-ը սկզբում):
- Մի միացրեք ավելորդ համակարգերը (ինչու՞ կար ուրոլոգի կայքը):
- Ինքներդ ստուգեք օգտատերերի գաղտնաբառերը ուժեղ լինելու համար (հակառակ դեպքում զինվորները... դա կանեն գրպանները)
- չունեն նույն գաղտնաբառերը տարբեր հաշիվների համար (VDI փոխզիջում)
- և այլ
Իհարկե, դա շատ դժվար է իրականացնել, բայց հաջորդ հոդվածում մենք գործնականում ցույց կտանք, որ դա միանգամայն հնարավոր է։
Source: www.habr.com