Red Teaming gadījuma izpēte: kā astoņās nedēļās nonācām līdz domēna administratoram

Galvenais īsumā

  • Astoņas nedēļas, viens uzdevums: atklāto avotu izlūkošana, ārējā perimetra pārbaude, mērķēta pikšķerēšanas kampaņa, fiziska iekļūšana trijās adresēs un iekšējā tīkla testēšana
  • No interneta redzamā daļa noturējās: atjaunināti serveri, pareizi konfigurēts ugunsmūris, strādājoša datplūsmas uzraudzība un Wi-Fi ar klienta sertifikātu un daudzfaktoru autentifikāciju
  • Mērķētā pikšķerēšanas kampaņa deva 260 derīgus kontus, nesūtot nevienu masveida vēstuli
  • Ugunsdzēsības aparātu pārbaudītāja lomā nokļuvām sanāksmju telpā, kur iekšējam tīklam pievienojām savu iekārtu ar 4G savienojumu
  • Nepareizi konfigurēts sertifikātu izsniedzējs (ESC8) atdeva domēna administratora tiesības, un astoņās nedēļās nenostrādāja neviens brīdinājums
  • Latvijā Red Teaming nav normatīvs pienākums: MK noteikumu Nr. 397 8.2. apakšnodaļa runā par ielaušanās testiem, nevis par uzbrukuma simulāciju

Vai mums tiešām vajag Red Team?

Liels uzņēmums, vairāki tūkstoši darbinieku, drošībā ieguldīts gadiem ilgi. Jautājums nebija par to, vai kļūdas vispār pastāv. Klients gribēja zināt ko citu: kas notiks tad, ja mērķi apzināti izvēlēsies apņēmīgs un labi organizēts uzbrucējs. Uz šo jautājumu atbild Red Team uzbrukuma simulācija.

Saņēmām astoņas nedēļas un ļoti maz ierobežojumu. Mērķētā pikšķerēšanas kampaņa no maldinoši līdzīga domēna deva 260 derīgus kontus. Atklāto avotu izlūkošana salika kopā cilvēkus un sistēmas. Ēkā iegājām ar sagatavotu lomu un klonētu piekļuves karti, un sanāksmju telpā palika mūsu pašu iekārta, pieslēgta iekšējam tīklam. Beigās nepareizi konfigurēts domēna sertifikātu izsniedzējs atdeva augstākās iespējamās tiesības. Cilvēku, tehnikas un fiziskās piekļuves slāņi pārtrūka katrs savā vietā, un neviens no šiem pārrāvumiem nav redzams no viena šaura tvēruma pārbaudes.

Kas ir Red Teaming?

Red Teaming jeb Red Team uzbrukuma simulācija vērtē organizāciju kopumā: gan to, kas redzams no interneta, gan to, kā cilvēki pieņem lēmumus. Atdarinām to, ko darītu motivēts uzbrucējs vai APT grupējums, kuru neierobežo ne laiks, ne budžets. Tieši tāpēc šāds darbs izceļ kļūdas, līdz kurām vienas lietotnes vai viena tīkla segmenta pārbaude nekad nenonāk.

Atšķirība no ielaušanās testēšanas nav tehnoloģiska, bet ir jautājuma līmenī. Ielaušanās tests atbild uz jautājumu, kur sistēma padodas. Red Teaming atbild uz jautājumu, vai organizācija to pamana un ko dara pirmajās stundās. Kur beidzas automatizēta pārbaude un sākas manuāls darbs, salīdzināts rakstā ievainojamību skenēšana vai ielaušanās tests.

Kā notiek šāds darbs

Sagatavošanās prasa tikpat daudz laika, cik pats uzbrukums. Strādājam pēc atzītām Red Teaming metodoloģijām: meklējam ievainojamības, novērtējam risku un pārbaudām, vai nopirktā aizsardzība strādā arī praksē. Darbu sadalījām piecos atsevišķos, bet savstarpēji saistītos posmos:

  • Atklāto avotu izlūkošana (OSINT)
  • Ārējās infrastruktūras testēšana
  • Iekšējā tīkla ielaušanās testi divos scenārijos
  • Fiziska iekļūšana trijās klienta adresēs
  • Mērķēta pikšķerēšanas kampaņa lielākajai daļai darbinieku

Kā nonācām līdz domēna administratoram

Mērķētā darbā vienmēr sākam ar ĀRĒJO TESTĒŠANU, tātad ar visu, kas sasniedzams no interneta. Rūpīgi pārskatījām tīmekļa lietotnes, VPN vārtejas, pasta serverus un pārējos pakalpojumus: meklējām novecojušas komponentes, konfigurācijas kļūdas un kļūdas kodā. Šajā daļā klients bija sagatavojies labi. Serveros bija uzliktas visas ielāpu paketes, un izmantojamu zināmu CVE nebija palicis. Ugunsmūris bija konfigurēts pareizi, un IDS un IPS sistēmas datplūsmu tiešām uzraudzīja. Arī caur Wi-Fi netikām: piekļuvei bija vajadzīgs klienta sertifikāts un daudzfaktoru autentifikācija (MFA).

Atklāto avotu izlūkošana un tās ceļā iegūtie piekļuves dati

OSINT jeb atklāto avotu izlūkošana parādīja, cik daudz salikts kopā, nepieskaroties nevienai sistēmai: organizācijas struktūra, darbinieku vārdi, IP adreses, apakšdomēni, ziņas par partneriem un līgumiem. Latvijā šis posms ir īsāks nekā daudzviet citur, jo daļa materiāla jau atrodas valsts reģistros. Uzņēmumu reģistra atvērtie dati nosauc amatpersonas un to pārstāvības tiesības, bet publisko iepirkumu nolikumi mēdz nosaukt konkrētas sistēmas, versijas un kontaktpersonas; šo ceļu sīkāk aprakstījām rakstā par [OSINT un mākslīgo intelektu](/lv/raksti/osint-un-mi-ka-uzbruceji-izmanto-publisko-informaciju). LinkedIn profilos darbavietu bija norādījuši nedaudzi, un tas liecināja, ka uzņēmums darbiniekus tiešām audzina uz atturību. Pie šāda darbinieku skaita ar to tomēr pietika. LinkedIn datus salīdzinājām ar vecām noplūdušām datubāzēm un pārbaudījām iegūtās e-pasta adreses. Pagrieziena punkts bija brīdis, kad vienas iekšējās sistēmas kļūda atklāja precīzu adrešu formātu: vards.uzvards@uznemums.lv.

FIZISKO PERIMETRU pārbaudījām vairākās adresēs. Pirmais apmeklējums bija tikai izlūkošana: ieejas, apsardzes apgaitas maršruts un laiki, kameru aklās zonas. Ēkas priekšā stāvēja ugunsdrošības iekārtu apkopes uzņēmuma automašīna, un no tā radās scenārijs. Pēc īsas sagatavošanās atgriezāmies ugunsdzēsības aparātu pārbaudītāja lomā: darba apģērbs, apkopes uzņēmuma logo, veidlapa ar rakstisku atļauju pārbaudīt aparātus un iekļūt ēkā. Iegansts nostrādāja tāpēc, ka aparātu apkope ir reāls un regulārs pienākums – šādu apmeklējumu nedēļas vidū neviens neapšauba. Loma izdevās tik labi, ka mūs bez uzraudzības atstāja sanāksmju telpā. Aiz televizora atradām paslēptu RJ45 ligzdu. Dažās minūtēs pievienojām savu iekārtu ar 4G mobilo savienojumu, noslēpām to un izgājām. Trauksmes signāls neatskanēja, un no šā brīža iekšējā tīklā bijām pastāvīgi un nemanāmi.

Sveša iekārta ar 4G savienojumu, pieslēgta klienta iekšējam tīklam
Domēna piekļuves datu iegūšana ar mērķētu pikšķerēšanas kampaņu

Tīkla piekļuve mums jau bija, taču derīga domēna konta vēl ne. Uz OSINT laikā pārbaudīto adrešu saraksta uzbūvējām šauru MĒRĶĒTU PIKŠĶERĒŠANAS KAMPAŅU: nekādu masveida sūtījumu, tikai maldinoši līdzīgs domēns (typosquatting). Vēstule solīja jaunu iekšējo apbalvojumu sistēmu, bet viltotā iekšējā portāla pieteikšanās lapa savāca paroles. Kampaņu apturējām uzreiz, tiklīdz materiāls bija rokā, lai samazinātu atklāšanas iespēju. Svaigie domēna konti pavēra ceļu dziļāk tīklā un uz nākamo posmu, proti, privilēģiju paaugstināšanu. Nevainojama latviešu valoda vairs nav pazīme, pēc kuras šādu vēstuli atšķirt no īstas; par to sīkāk rakstā par [MI pikšķerēšanu](/lv/raksti/kas-ir-mi-pikskeresana-un-ka-to-atpazit).

IEKŠĒJĀ TESTĒŠANA sastāvēja no diviem scenārijiem: nozagtas iekārtas simulācijas un iekšējā tīkla pārbaudes. Klienta domēna sertifikātu izsniedzējā (Certificate Authority, CA) atradām ievainojamību ESC8, kas ļāva pieprasīt jebkuru Active Directory sertifikātu, tostarp domēna kontrollera (DC) sertifikātu. Kļūdu apstiprinājām ar rīku Certipy, pēc tam ar Netexec moduli Coerce_Plus piespiedām domēna kontrolleri autentificēties pret mūsu pārsūtīšanas serveri un ar NTLMRelayX šo autentifikāciju pārtvērām un pārsūtījām tālāk. CA izsniedza domēna kontrollera sertifikātu, un līdz ar to mums bija domēna administratora tiesības. Active Directory domēnā augstāk vairs nav kur kāpt: tā ir pilnīga infrastruktūras pārņemšana ar piekļuvi visiem pakalpojumiem un sensitīvajiem datiem. Arī labi uzbūvētu aizsardzību var apiet, ja uzbrucējs mērķē precīzi.

No ESC8 ievainojamības līdz domēna administratora tiesībām

Rezultāti un galvenie secinājumi

  • Iegūti konti. Mērķētā pikšķerēšanas kampaņa deva 260 derīgus lietotāju kontus. Vājā vieta bija pasta filtrēšana un darbinieku sagatavotība.
  • Fiziska piekļuve. Pie ieejas mūsu cilvēku neviens neapturēja, un piekļuves karšu klonēšana notika bez jautājumiem. Ar to pietika, lai aizsargātajā zonā nonāktu sveša iekārta.
  • Privilēģiju paaugstināšana līdz domēna augšai. Nepareizi konfigurēts sertifikātu izsniedzējs (ESC8) izsniedza uzticamu sertifikātu, un tas deva pilnu kontroli pār domēnu – nepamanīti.
  • Neviens brīdinājums. Ne perimetra aizsardzība, ne IDS un IPS sistēmas, ne žurnālu vākšana nesignalizēja neko. Šis ir sarakstā dārgākais konstatējums.

Ko par to saka Latvijas regulējums

Ceturtais punkts maksā visdārgāk, un ne tikai drošības izpratnē. Nacionālās kiberdrošības likuma (turpmāk – NKDL) subjektam ir pienākums kiberincidentus ne tikai novērst, bet arī par tiem paziņot: 34. pants iedarbina pulksteni, un ziņojumu saņem kompetentā kiberincidentu novēršanas institūcija. Incidentu klasifikāciju, ziņošanas termiņus un formas nosaka MK noteikumi Nr. 397, savukārt NIS2 direktīvas 23. pants paredz trīspakāpju ķēdi: agrīnais brīdinājums, ziņojums par incidentu un gala ziņojums.

Astoņas nedēļas svešas klātbūtnes bez viena brīdinājuma šajā loģikā nozīmē vienkāršu lietu: ziņošanas termiņš nebūtu pat sācis tecēt. Ne tāpēc, ka incidenta nebūtu, bet tāpēc, ka to neviens nepamanīja. Tieši šo attālumu starp „mums ir žurnāli“ un „mēs pamanām“ Red Teaming izmēra tiešāk nekā jebkura cita pārbaude.

Pašu Red Teamingu Latvijas regulējums neprasa. MK noteikumu Nr. 397 8.2. apakšnodaļa saucas „Ielaušanās testi un drošības skenēšana“, un uzbrukuma simulācija tajā nav minēta ne reizi. Obligāti ir ielaušanās testi A klases informācijas sistēmām: pirms nodošanas ekspluatācijā un pēc tam vismaz reizi trijos gados (131.1. apakšpunkts). Uz ko šis pienākums attiecas un cik bieži tests jāatkārto, skaidrots rakstā vai ielaušanās testēšana ir obligāta.

Ikgadējs ir cits pienākums, un tieši tas Red Team darbam atstāj vietu. NKDL 25. panta piektās daļas 2. punkts liek kiberdrošības pārvaldniekam ne retāk kā reizi gadā veikt informācijas un komunikācijas tehnoloģiju drošības pārbaudi un organizēt konstatēto trūkumu novēršanu. Metodi norma nenosaka, un CERT.LV iesaka gada pārbaudes plānot pēc satura, nevis pēc kalendāra: tematiski un atbilstoši informācijas sistēmu risku analīzes rezultātiem. Organizācijai, kurai perimetrs un ielāpi jau ir kārtībā, aktuālākā tēma parasti vairs nav ievainojamību saraksts, bet gan atklāšana.

Secība tāpēc ir pretēja tai, kādā to bieži pasniedz tirgus. Red Teaming nav normatīva prasība, bet ir tas mērījums, kurš pasaka, vai pārējām prasībām iztērētā nauda kaut ko dod.

Mūsu ieteikumi

  • Fiziskā drošība un apmeklētāju kārtība. Barjeras, kas neļauj ieiet līdzi kartes īpašniekam, konsekventa personas pārbaude un pieteikts, pavadīts apmeklētājs. Reģistratūra ir tāds pats piekļuves punkts kā pieteikšanās lapa.
  • Regulāra visu virzienu pārbaude. No interneta redzamā daļa, iekšējā infrastruktūra, sertifikātu izsniedzējs un tīkla iekārtas, nevis tikai tas, kas šobrīd top izstrādē.
  • Pikšķerēšanas un sociālās inženierijas treniņš. Scenārijos balstītas darbinieku kiberdrošības apmācības vairākas reizes gadā, nevis viena prezentācija janvārī. Sociālās inženierijas pārbaude parāda arī to, kas notiek pēc tam, kad darbinieks vēstuli tomēr piesaka.
  • Iekšējo iekārtu un datplūsmas uzraudzība reāllaikā. Mērķis ir vienkāršs: nezināma iekārta un neparasta tīkla uzvedība parādās uzreiz, nevis pēc astoņām nedēļām.

Ziņojumā katram konstatējumam pievienojām reproducēšanas soļus, ietekmes aprakstu konkrētajā vidē un novēršanas secību. Pēc labojumiem konstatējumus pārbaudījām atkārtoti un rakstiski fiksējām, kuri ir slēgti; tieši šis dokuments ievainojamību sarakstu pārvērš paveiktā darbā.

Kiberdrošība nav iekārtu jautājums. To kopā veido cilvēki, procesi un rīki, un uzbrucējs ieiet tur, kur pretestība ir vismazākā. Tāpēc pārbaudi, secinājumus un labošanu ir vērts atkārtot. Red Team uzbrukuma simulācija no visa tā mēra vienu lietu, toties precīzi: cik ilgā laikā organizācija pamana, ka kāds jau ir iekšā. Ja noderētu otrs skatījums uz to, ko pamana jūsu aizsardzība, aicinām pieteikties bezmaksas konsultācijai.

HAXORIS ir Slovākijā reģistrēts uzņēmums, un Latvijā tam nav ne biroja, ne pārstāvniecības. Neveicam NKDL 44. pantā noteikto atbilstības auditu, jo to veic neatkarīgs kiberdrošības auditors. Piedāvājam tehnisku drošības testēšanu un gatavības novērtēšanu.

Red Teaming – biežāk uzdotie jautājumi

01

Ar ko Red Teaming atšķiras no ielaušanās testa?

Ielaušanās tests dziļi pārbauda fiksētu tvērumu – vienu lietotni, vienu tīklu, vienu mākoņvidi – un atbild uz jautājumu, kur sistēma padodas. Red Team uzbrukuma simulācija mēra organizāciju kopumā, tostarp cilvēku un fizisko slāni, un atbild uz jautājumu, vai uzbrukumu vispār pamana un ko ar to iesāk. Viens otru neaizstāj: bez ielaušanās testiem Red Teaming ir dārgs veids, kā atrast jau zināmas kļūdas.

02

Cik ilgi notiek Red Team uzbrukuma simulācija?

To izšķir tvērums. Šeit aprakstītais darbs ilga astoņas nedēļas, jo sastāvēja no pieciem posmiem un prasīja fizisku iekļūšanu trijās adresēs. Šaurāks, uz vienu scenāriju būvēts uzdevums aizņem dažas nedēļas. Precīzu termiņu nosaucam pēc tam, kad tvērums un noteikumi ir rakstiski saskaņoti.

03

Vai Red Teaming Latvijā ir obligāts?

Nē. Ne Nacionālās kiberdrošības likums, ne Ministru kabineta noteikumi Nr. 397 uzbrukuma simulāciju kā atsevišķu pienākumu nepazīst. Obligāti ir ielaušanās testi A klases informācijas sistēmām: pirms nodošanas ekspluatācijā un pēc tam vismaz reizi trijos gados (MK noteikumu Nr. 397 131.1. apakšpunkts). Ikgadējs ir cits pienākums – NKDL 25. panta piektās daļas 2. punkts liek kiberdrošības pārvaldniekam ne retāk kā reizi gadā veikt IKT drošības pārbaudi, taču metodi norma nenosaka. Šis raksts ir informatīvs materiāls, nevis juridiska konsultācija.

04

Vai fiziska iekļūšana un pikšķerēšana ietilpst tvērumā?

Tikai tad, ja tas rakstiski ierakstīts līgumā. Tvērumu, atļautās metodes, adreses un laika logu aprakstām iepriekš, un klienta pusē daži informēti cilvēki visu laiku zina, ka notiek pārbaude. Fiziskai iekļūšanai ņemam līdzi rakstisku atļauju gadījumam, ja komandu aptur apsardze.

05

Vai testa laikā kāda sistēma var apstāties?

Mērķis ir pierādīt piekļuvi, nevis nodarīt zaudējumus. Postošas darbības neveicam, kritiskajās sistēmās strādājam saskaņotā laika logā, un noteikumus fiksējam rakstiski pirms darba sākuma. Ja kāda sistēma tomēr uzvedas negaidīti, nekavējoties informējam klienta kontaktpersonu.

Pārbaudīsim, ko jūsu aizsardzība pamana no reāla uzbrukuma

Pieteikties bezmaksas konsultācijai