"Vulnerability Management" - nekad i sad

U pripremi ovogodišnje korisničke konferencije Qualys Security Day, prisjetio sam se dolaska Qualys-a na hrvatsko tržište, u čemu sam neposredno sudjelovao. Bilo je to 2006. godine, mrežno skeniranje je bila jedina dostupna tehnika otkrivanja ranjivosti. Tipično, predmet interesa su bili mrežni poslužitelji, uglavnom perimetarski, a pretplate su obuhvaćale ne više od stotinjak poslužitelja, ponekad i znatno manje. Tipični driver koji je stajao iza „Vulnerability Management“ procesa bio je „Compliance“, a tek su rijetki korisnici bili vizionarski motivirani pravilnom percepcijom sigurnosnih rizika. Cyber prijetnje nisu imale ono značenje koje imaju danas.

Nadležnost „infosec“ odjela za računalne ranjivosti, ako smo uopće mogli govoriti o „infosec“ odjelima krajem prvog desetljeća ovog stoljeća, bila je tek izvještavanje o detektiranim ranjivostima, a zadatak njihovog otklanjanja je preusmjeravan na IT operativu. Primjena popravaka i/ili instalacije novih verzija softvera smatrala se uskom odgovornošću specijaliziranih timova (od operative, razvoja, help-deska…), a strah od neuspješne primjene popravaka, od prekida rada aplikacija nakon primjene novog popravka ili nakon promjene konfiguracijske postavke bio je puno veći od straha uzrokovanog pojavom sigurnosnih prijetnji, pa je i postupak primjene bio znatno sporiji.

A u ovih 16 godina (zapravo, konferenciju smo planirali na donekle okruglu obljetnicu u 2021. ali zbog poznatih uvjeta je događaj odgođen), došlo je do izuzetnih promjena na području računalnih prijetnji.

Krenimo od promjena koje su utjecale na povećanje visine rizika:

• Perimetar se preselio sa stvarnog ruba mreže na unutarnji dio mreže. Sada ga čine osobna računala, ali i nove forme obrade podataka kroz kontejnere.
• Broj ranjivosti rapidno raste iz godinu u godinu, način njihove detekciji postaje sve učinkovitiji, tako da i broj detektiranih ranjivosti postaje sve veći (npr. detekcija pomoću agenata kao što je Qualys Cloud Agent) 
• Eksploatacija ranjivosti je postala ili dobro utemeljena industrijska djelatnost ili bogato sponzorirana državna agentura. Nekad dominantni hobisti tako su integrirani u sustav, uz redovite i obilne prihode, iako su poneki od njih prešli na svijetlu stranu.

Ukratko, „cyber“ prijetnje su pružile jasan razlog svog interesa za računalne ranjivosti.

Nažalost, disciplina upravljanja računalnim ranjivostima u novo-nastaloj situaciji nije pružila adekvatan odgovor, barem ne u onom ritmu kojeg su nametnule cyber prijetnje.  Nadležnost za primjenu popravaka i dalje ostaje u odjelima IT operative, uz sve njihove rezerve koje su postojale i ranije.

Promjene koje gore navodim nisu nimalo pomogle popraviti situaciju. Povećanje broja ranjivosti koje treba otkloniti samo je dodatno frustriralo timove iz IT operative. Frontalni i neselektivni pristup primjeni popravaka je pojačao uobičajenu, blago rečeno, rezervu koju IT operativa ima prema „compliance“ obavezama, kako ovi timovi primarno percipiraju proces primjene popravaka. Kombinirano s uobičajenim strahovima, to je zapravo značilo još nižu razinu učinkovitosti procesa primjene popravaka.

U isto vrijeme, „infosec“ odjeli se i dalje smatraju odgovornim u slučaju kada dođe do proboja cyber prijetnji, a s obzirom na sve veću frekvenciju cyber napada i sve veći broj ranjivosti koje ovi napadi iskorištavaju, sasvim je izvjesno da će CISO biti prva osoba čija će se glava tražiti nakon cyber incidenta.  

Ukratko: „infosec“ odjeli su izloženi puno nepovoljnijim posljedicama zbog sve izglednijih proboja cyber napada, a istovremeno su lišeni mogućnosti primjene jedne od najznačajnijih preventivnih mjera: efikasnog otklanjanja ranjivosti.

Izlaz iz takve situacije treba potražiti u sljedećoj doktrini:

• „Infosec“ mora dobro poznavati cjeloviti obuhvat imovine izložene cyber prijetnjama (tradicionalni „Asset management“ procesi ne pružaju nužno adekvatnu razinu ažurnosti i detaljnosti, često su odvojeni od „infosec“ procesa, ponekad i nedostupni jer funkcioniraju po principu silosa)
• Potrebno je prioritizirati detektirane ranjivosti sukladno prisutnosti Threat Intelligence faktora, kao što su prisutnost exploita, iskorištavanje ranjivosti u evidentiranim i ostvarenim prijetnjama, kumulativni potencijal detektirane ranjivosti (CVSS ipak pokazuje manjkavosti u odnosu na dosljednu primjenu ovih zahtjeva)…
• Potrebno je prioritizirati ranjivosti s obzirom na značaj, smještaj te poslovni kontekst resursa na kojem je detektirana ranjivost…
• Dobrodošlo je pružiti polugu (alat) „infosec“ odjelu za primjenu programskih popravaka i korekcija postavki

Cilj je provući sve detektirane ranjivosti kroz ljevak prema jasno definiranim kriterijima te izvući dio ranjivosti, možda tek desetinu u odnosu na ukupni broj, na koje se IT operativa mora fokusirati. Ovo je jako liješpo ilustrirano na sljedećoj slici (prema Transitioning to a Risk-based Approach to Cybersecurity):

I ne samo to: bilo bi dobro  „infosec“ odjelu dati alat koji će im omogućiti da se sami obračunaju s ovim ranjivostima. Qualys je objavio zanimljiv podataka: analizom vremena otklanjanja detektiranih ranjivosti utvrđeno je da korisnici koji primjenjuju popravke kroz modul Qualys Patch Management (sustav integriran s  Qualys VMDR modulom), popravke primjenjuju 60% brže u odnosu na korisnike koji upotrebljavaju suatve za primjenu popravaka koji nisu integirani s Vulnerability Management modulom.

Ova doktrina nas konačno vodi do mogućnosti stvarne kvantifikacije težine računalnih ranjivosti te do kvantifikacije rizika s obzirom na stvarno stanje ranjivosti i prisutni prijetnji. Primjenom ove doktrine, „infosec“ odjel odbacuju „compliance“ ruho, te postaje kreator odluka temeljenih na realnim rizicima. 

Qualys Cloud Platform je jedan od primjera na tržištu koje ukazuje na usvajanje navedene doktrine. Ova platforma kontinuirano uključuje nove module i nove sposobnosti, a upravljanje ranjivosti na temelju rizika postaje ključan mehanizam za provedbu „workflow-a“ ojačanja informacijskih sustava. 

A sve je krenulo od običnog skeniranja mreže prije dvadesetak godina…

Nadogradnja okvira MITRE ATT&CK

 Prošlog tjedna je objavljena značajna nadogradnja – verzija 9 – okvira MITRE ATT&CK, okvira za analizu cyber napada o kojem sam ranije pisao i predstavio na redovitom mjesečnom sastanku ISACA Croatia Chapter. Osim uobičajenih dopuna ili nadogradnji tehnika i sub-tehnika te podataka o napadačkim grupama, verzija 9 uvodi taktike i tehnike napada koje se odnose na tehnologiju kontejnera te značajno nadograđuje taktike i tehnike napada koji se odnose na „Cloud“ tehnologije. No, najznačajnija novost u verziji 9 je novi pristup u opisu i obradi „Data Sources“ informacija.

Prema okviru MITRE ATT&CK, „Data Sources“ su točke ishodišta podataka na temelju kojih je moguće detektirati pojedine tehnike (i sub-tehnike) napada. U pre-v9 verzijama okvira ATT&CK ovi podaci su definirani kao nestrukturirana svojstva pojedinih tehnika i sub-tehnika, a ima ih preko 60. „Data Sources“ informacije su i u takvom obliku izuzetno korisne, osobito za stručnjake i timove koji su fokusirani na tehnike detekcije cyber napada (npr. tzv. „blue team“ grupe). Pomoću ovih informacije moguće je primijeniti dodatne konfiguracijske napore i/ili arhitekturne nadogradnje kako bi se obogatila učinkovitost telemetrijskih podataka neophodnih za detekciju napada. Ipak, iako zamišljeni s dobrom namjenom, realizacija „Data Sources“ informacija u pre-v9 verzijama je zaostajala za drugim komponentama ATT&CK okvira, upravo zbog svoje nestrukturiranosti ali i mjestimične nekonzistentnosti koja je bila rezultat izostanka dobro definiranog modela ove kategorije podataka. Tako na primjer,  „Data Sources“ podacima su označeni i „Process monitoring“ i „Process command-line parameters“ i „Process use of network“, iako se u suštini radi o različitim aspektima informacija koje se generiraju na temelju istih događaja - pokretanja i izvođenja Windows procesa. Drugi primjer je i „Windows event logs“ kao zasebna „Data Sources“ točka iako bi ovu kategoriju bilo bolje definirati kao kanal kroz koji se dostavljaju suštinski „Data Sources“ telemetrijski podaci a ne kao „Data Sources“.

U zajednici koja prati i surađuje na razvoju okvira ATT&CK pojavile su se stoga sugestije za modifikaciju „Data Sources“ informacija. 

Verzija 9 donosi ovu dobrodošlu nadogradnju. Točnije, u ovoj verziji imamo prvu fazu nadogradnje, kroz koju su definirani „Data Sources“ te „data components“ - komponente vezane za pojedini izvor, tj. specifikacija izvora iz kojih moramo prikupljati detekcije podatke, ali sada na strukturiran i normaliziran način. Za sada još uvijek nedostaju konkretni detekcijski podaci koji bi se mapirali za pojedine tehnike napada, no to se očekuje u verziji koja je planirana za listopad. 

Odnos među navedenim dijelovima ovog modela podataka su vidljivi na priloženoj slici, koju sam posudio iz teksta na službenom ATT&CK blogu.  

Također treba napomenuti da su novi „Data Sources“ podaci za sada katalogizirani kroz Github a ne kao objekt unutar ATT&CK okvira. Razlozi su opravdani razvojnim aktivnostima, a uključivanje u ravnopravne ATT&CK objekte je također planirano za listopad. No, bez obzira na prisutan “work-in-progress“ dojam, postojeće dopune mogu značajno olakšati posao svima nama koji smo fokusirani na tehnike detekcije ili na DFIR aktivnosti.

Ranjivost koju treba shvatiti ozbiljno

Prošlo je šest dana od objave podataka o veoma nezgodnoj ranjivosti na Microsoft Exchange serveru, koja zahvaća sve novije verzije ovog servera konfiguriranog tako omogućuje OWA pristup, tj. tako da omogućuju pristup elektroničkoj pošti preko Internet preglednika. Nadam se da su svi koji su takav servis omogućili za pristup iz javnog Internet prostora već primijenili popravak koji je Microsoft objavio 2. ožujka, istog dana kada je i tvrtka Volexity objavila informaciju o ovom nedostatku. Naime, tvrtka Volexity je još od početka siječnja uočila anomalije u korištenju servisa elektroničke pošte u korisnika kod kojih je upotrebi Exchange – velika količina poruka bila je eksfiltrirana na adrese koje nisu povezane s poslovanjem korisnika. Daljnja analiza problema je ukazala na prisutnost tzv. server-side request forgery (SSRF) ranjivosti koja je omogućila izvođenje proizvoljnog koda. Ukratko, mailbox odabranih osoba na mail serveru žrtve bio je kopiran na vanjske servere pod kontrolom napadača. Napadač je morao znati, ovisno od konfiguracije Exchange servera, mail adresu ciljane žrtve ili njegov Active Directory račun, što naravno nije nimalo nepremostiv zadatak. 

No, to nije bilo sve. Ujedno su bile iskorištene i neke druge do tada nepoznate ranjivosti koje su omogućile daljnju eskalaciju inicijalnog proboja. U toj drugoj fazi napadač uspijeva doći u posjed dodatnih informacija o radu Active Directory sustava (u najgorem scenariju, to su podaci o domenskim računima i podacima za autentikaciju). Također, napadač uspijeva kreirati „webshell“ okolinu na Exchange serveru, tj. specifični „backdoor“ program koji mu omogućuje izvođenje proizvoljnih programa na kompromitiranom Exchange serveru. U kombinaciji s podacima s AD sustava, to predstavlja idealnu podlogu za daljnje lateralno kretanje po mreži žrtve.

Ovaj scenarij zvuči izuzetno jednostavan, što se i pokazalo u praksi. Naravno, značajan trud je uložen u otkrivanje ranjivosti i u razvoj exploita, no operativna provedba je bila praktički automatizirana i zato su forenzičke analize provedene nakon objave ranjivosti pokazale oko 30.000 žrtava (to su zadnje informacije dostupne u trenutku pisanja ovog teksta). Ova brojka obuhvaća one servere kod kojih su pronađeni tragovi djelovanja exploita, tek trebamo saznati koliko je korisnika zapravo bilo izloženo i krajnjem djelovanju, tj. krađi mail poruka ili daljnjim aktivnostima napadača na internoj mreži.

Iza napada, kako je objavljeno, stoji kineska cyber-obavještajna grupa Hafnium. Ova se grupa do sada uglavnom bavila preuzimanjem podataka s različitih istraživačkih institucija, sveučilišnih ustanova i instituta raznih profila. Također, registrirano je i djelovanje nekih drugih kineskih grupa za koje nije utvrđeno jesu li u organizacijski ili poslovno povezane. Identificiran je jako veliki broj žrtava među institucijama i agencijama američke vlade, no i među brojnim tvrtkama.

Donekle olakšavajuću okolnost predstavlja činjenica da su mnoge velike korporacije uveliko migrirale na cloud verziju Exchange-a, tj. na mail servis koji pruža Microsoft, a koji nije zahvaćen recentnom ranjivosti koju ovdje opisujem.

No, mjesta za opuštanje nema, čak i ako ste primijenili popravak. Obavezno morate provjeriti jeste li možda prethodno ipak bili kompromitirani. Prema veoma detaljnom upozorenju i uputama za forenzičku analizu koje je uputila važna agencija američke vlade - Cybersecurity and Infrastructure Security Agency (CISA), prava bi se analiza morala temeljiti na pouzdanom forenzičkom postupku i trijaži podataka o incidentu kroz koju bi se trebali pretražiti točke interesa te verificirati prisutnost/odsutnost karakterističnih indikatora kompromisa. Tek jednostavan uvid u sadržaj IIS foldera i vizualno pretraživanje karakterističnih podataka nije dovoljno. Također, i Microsoft je objavio skripte za otkrivanje dijela kompromitiranih podataka.

Bojim se da ovime priča oko Exchange problema nije ni približno gotova, što ponajviše temeljim na činjenici da forenzičke istrage još nisu završene te da prave informacije o opsegu ovo napada tek slijede. Nekoliko je i suštinskih razloga koji idu u prilog ovoj tvrdnji:

• Tek trebamo saznati kada jesu li ovi napadi registrirani i prije siječnja 2021. i jesu li do sada možda iza napada stajale i neke druge cyber grupe koje su birale puno diskretniju taktiku napada.
• Iako se trenutno spominje 30.000 žrtava, radi se o uglavnom američkim žrtvama. Tek moramo saznati koliko su zahvaćene tvrtke/organizacije iz drugih dijelova svijeta.
• Ranjivost je postala dostupna javnosti prošlog tjedna. Iako su se pojavili Proof-of-Concept verzije napada, novi maliciozni „exploit-i“ u trenutku pisanja ovog teksta još nisu dostupni, no samo je pitanje vremena kada će se pojaviti.
• Ranjivosti koje opisujemo u ovom tekstu imaju potencijal za iskorištavanje u slijednom lancu događaja na automatizirani način te mogu poslužiti za razvoj scenarija ransomware napada.
• Tek trebamo saznati kolika je dinamika primjene popravaka, no ako za ilustraciju uzmemo neke druge slučajeve iz bliže povijesti, poznato je da neke organizacije mogu biti veoma lijene u primjeni popravaka (vidi primjer tvrtke Equifax i epohalno neuspješan popravak Struts ranjivosti).

Ukoliko vam bude zatrebala pomoć oko forenzičke analize stanja potencijalnog kompromitiranog servera, pogledajte našu ponudu forenzičkih usluga i javite nam se.

Model zrelosti upravljanja računalnim ranjivostima

 U tekstu koji sam objavio prije, sada već, nešto više od dvije godine (Digitalna transformacija procesa upravljanja ranjivostima) pisao sam o potrebi promjene paradigme procesa upravljanja računalnim ranjivostima. Trend napuštanja tehnike mrežnog skeniranja kao najčešće metode otkrivanja ranjivosti bio je već tada izražen, a razvoj tehnologije i upravljačkih procesa koji su slijedili potvrdili su najave iz teksta.

Dapače, stvari su krenule i korak dalje. Ne samo da su senzori za detekciju ranjivosti – namjenski servisi koji se izvode na samim računalima, postali izvor jednako relevantan kao i rezultati mrežnih skeniranja, a sve češće i značajniji, nego su sustavi za prikupljanje i analizu ranjivosti prerasli ulogu daljinskog upravljača za pokretanje skenova i alata za generiranje izvještaja. 

Kao ilustraciju dajem primjer sustava Qualys, koji je postao bogata analitička platforma u kojoj se bogati telemetrijski podaci sa senzora različitih profila i izvora slijevaju u svojevrsni „data lake“. Normalizirani, obogaćeni i indeksirani podaci o ranjivostima pružaju svojim korisnicima neposrednu i djelotvornu informaciju, bez obzira radi li se o izvještavanju odgovornih osoba, alarmiranju sigurnosnih timova ili pokretanju nužnih remedijacijskih aktivnosti.

Mogućnosti koje pružaju nove funkcije sustava Qualys dobile su nedavno i dobrog pratitelja. Američka organizacija SANS, čije djelovanje ne treba posebno predstavljati kolegama koji rade na području informacijske sigurnosti, objavila je sredinom prošle godine svoj edukativni  poster „CISO Mind Map“ u koje središnje mjesto „Vulnerability Management Maturity Model“. To je detaljna tablica u kojoj su glavne faze procesa upravljanja računalnim ranjivostima opisane s obzirom na stupanj realizacije, pri čemu je zrelost programa klasificirana u pet razina – od „Initial“ do „Optimizing“.  Na svoje će doći ne samo ljubitelji „Maturity Model“ klasifikacija, nego i svako od vas koji pokušava uvesti program upravljanja ranjivostima u svoju organizaciju.

U nastavku prilažem samu tablicu da dokument možete preuzeti na ovom mjestu:

Dokument koji možete preuzeti je tek poster na kojem tablica s „Vulnerability Management Maturity“ modelom zauzima vidljivo mjesto, no svakako nedostaju još neke dodatne upute (ovo nije zamjerka SANS-u, već naprosto činjenica da je dokument podsjetnik ili ako hoćete poziv na pohađanje seminara koje SANS održava na temu procesa upravljanja informacijskom sigurnosti). Stoga bi tu još trebalo dodati da ranjivosti na koje se model odnosi nisu samo bugovi u operativnom sustavu ili u gotovim programskim paketima, već i ranjivosti na aplikativnim sustavima te konfiguracijske manjkavosti. 

Kako krenuti u primjenu ovog modela? Za početak identificirajte gdje se zapravo nalazite unutar ovog modela. Nije isključeno da će se vaša razina zrelosti razlikovati u ovisnosti od faza procesa (imamo pet faza: Prepare, Identify, Analyze, Communicate i Treat). Budite objektivni i realni. Radi te za vlastiti napredak a ne za regulatorno ili revizijsko izvješće. Kada utvrdite svoju razinu zrelosti, postavite cilj kojem želite težiti. Neka to bude u koracima koje realno možete i napraviti.

Kada krenete u implementaciju onda ćete vidjeti da se izvješća, preporuke, dojave i odluke na bogatoj bazi podataka i na vašoj sposobnosti da iz takve baze izvučete sve djelotvorne informacije i polazišta za daljnje akcije. Dobro, ne mislim baš na vašu osobnu sposobnost, već na svojstva sustava unutar kojeg su prikupljeni podaci o ranjivostima. A tu sada dolazimo na funkcije sustava Qualys koji će vam omogućiti unaprjeđenje procesa upravljanja ranjivostima do najviših razina zrelosti predviđenih ovim modelom. 

SolarWinds hack - zbog čega se moramo zabrinuti (nastavak)?

U prethodnom tekstu sam se opisao kontekst pojave SolarWinds hacka (SUNBURST prema FireEye ili Solarigate prema Microsoft) i njegov utjecaj na informacijsku sigurnost, a kako sam najavio, u ovom se tekstu bavim tehničkim detaljima.

Odmah za početak, ova analiza ne uključuje detalje o inicijalnom proboju u tvrtku SolarWinds, s obzirom da za sada nisu objavljeni konačni zaključci analize niti načini kompromitacije aplikacije Orion, no svakako možemo zaključiti da je napadač imao dobru poziciju u procesu razvoja i upravljanja promjenama ove aplikacije.

Moja analiza je bazirana na izvješćima koja su objavila tvrtke Microsoft, FireEye, PaloAlto Networks te agencija Cybersecurity and Infrastructure Security Agency (CISA) američke vlade.

Dakle, krećemo od točke kada je tvrtka korisnik sustava SolarWinds Orion (i buduća žrtva kompromitacije ovog softvera) preuzela nadogradnju objavljenu krajem ožujka ove godine. Nadogradnja, ekstenzije msp, bila je uredno potpisana certifikatom tvrtke SolarWinds i među  komprimiranim modulima je uključivala i modul SolarWinds.Orion.Core.BusinessLayer.dll.

Nakon instalacije nadogradnje, novi moduli, uključujući i prije spomenuti su bili pokrenuti u produkcijskom radu. 

Modul SolarWinds.Orion.Core.BusinessLayer.dll je .NET program koji je standardni dio aplikacije Orion, sa svojim redovitim funkcijama. No, unutar ove funkcije je lukavo smješten poziv za izvođenje backdoor modula: predviđeno je paralelno izvođenje s glavnim programskim modulom, ničim narušavajući očekivane funkcije, a za izvođenje je odabrana metoda koja se redovito pokreće, čime je osigurana persistencija, tj. kontinuirani rad nakon svakog pokretanja aplikacije.

Backdoor kod je u potpunosti sadržan u klasi OrionImprovementBusinessLayer. Tijekom inicijalizacije, maliciozni program provjerava je li istekao rok od 12 do 14 dana od inicijalnog pokretanja (provjerava vrijeme zadnjeg upisa) – dakle predviđene je dvotjedni period mirovanja od inicijalne kontaminacije te provjerava postoje li neki drugi unaprijed predviđeni uvjeti uslijed kojih planirano obustavlja rad (npr. malware prekida izvođenje ako se nalazi u domeni koja uključuje stringove „solarwinds“ odnosno „test“ ili se na sustavu izvode neki procesi karakteristični za sigurnosne programe).

Ukoliko je „zrak čist“, „backdoor“ započinje stvarni život. Namjera mu je povezati se kontrolnim (C2) serverom, prijaviti svoju dostupnost, preuzeti instrukcije sa C2 servera, izvesti ih na mreži žrtve i vratiti rezultate nazad na C2. Dakle, radi se o uobičajenom slijedu akcija kakve izvode „backdoor“ programi. No, vrag je u detaljima. 

Inicijalni C2 server je smješten unutar domene avsvmcloud[.]com, pri čemu je stvarni URL nadopunjen s pseudo-random i random nazivima generiranim iz jedinstvenih parametara vezanih za samu žrtvu. Također, prije povezivanja s C2 serverom, generira se i URI lokacija izborom unaprijed pre-definiranih vrijednosti na način koji neće izazvati sumnju ako bi netko pratio metapodatke o povezivanjima. 

Na koncu, generira se i šalje JSON dokument s parametrima relevantnim za ostvarivanje komunikacijskog kanala.

(Važno je napomenuti: Ova adresa je iskorištena i kao slabost SUNBURST malwarea, odnosno kao „kill-switch“ poluga. Nakon ovog otkrića, Microsoft je blokirao domenu avsvmcloud[.]com, no, ipak, 8 mjeseci prekasno)

Kada je komunikacijski kanal između „backdoor“ programa i C2 servera potvrđen, započinje kontinuirana komunikacija kroz koju operateri koji rade na C2 serveru dostavljaju „backdoor“ programu niz naloga za izvođenje karakterističnih aktivnosti – od prikupljanja osnovnih informacija o operativnom sustavu, mreži datotekama, registry podacima pa do izvođenja specifičnih naredbi.

No, treba naglasiti da je operacija bila sve samo ne rutinska i predvidljiva. U analiziranim slučajevima su otkrivene i mnoge specifičnosti – od dodatnih C2 servera putem kojih su dolazili nalozi za akcije, do iskorištavanja specifičnih ranjivosti ili pokretanja novih malicioznih programa prikladnijih za lateralno kretanje. Opisat će neke od ovih specifičnosti u nastavku. 

Novi C2 serveri: Kada SUNBURST/Solarigate backdoor program pokrene aktivnosti lateralnog kretanja i druge aktivnosti u naprednoj fazi napada, onda se otvara komunikacijski kanal prema alternativnim C2 serverima. Često puta, radi se o domenama koje su registrirane nekoliko godina ranije, u međuvremenu su istekle ali nisu brisane. Na taj način napadač želi ostaviti dojam komunikacije sa domenom pouzdane dugogodišnje reputacije. I korak dalje: zabilježeno je da su napadači komunicirali sa žrtvom preko lokalnog VPS servera, smještenog u istoj zemlji gdje je i žrtva, čime napadač dodatno nastoji pojačati reputaciju. 

TEARDROP dropper: Kako sam spomenuo, u drugoj fazi napada (koja se obično naziva „post-compromise“ aktivnost) su korišteni dodatni „payload“ moduli. SUNBURST uobičajeno koristi PowerShell skripte, no tvrtka FireEye je izdvojila i specifično kreirani „payload“ modul kojeg je nazvala TEARDROP. Radi se o inventivno importiranom programskom kodu (preko lažne  jpg datoteke nad kojom je primijenjena tehnika steganografije) koji su pokreće u radnoj memoriji kao „file-less malware“ a u suštini izvodi backdoor modul komercijalnog programa za penetracijska testiranja Cobalt Strike, naravno opremljenog tehnikama za osiguranje persistencije, prikupljana autentikacijskih podataka i lateralnog kretanja, ali i prilagođenog novom gazdi.

Privilegirane ovlasti: Polazeći od činjenice da sustav Orion ima nadzorne zadaće nad ključnim komponentama informatičke infrastrukture, napadači su zauzeli nekoliko uporišta za dohvat podataka o korisničkim računima, uključujući i mogućnost lateralnog kretanja s privilegiranim ovlastima i prijave na ključne resurse (npr. AD server) s visoko privilegiranim ovlastima. Takve privilegije su omogućile i praktičnu implementaciju tehnike napada poznatu pod imenom „Golden SAML“. Ova tehnika je poznata od 2017. godine ali je ovo prvi zabilježeni slučaj u stvarnom incidentu. U SUNBURST scenarijima, napadači su time ostvarili mogućnost pristupa resursima koji prihvaćaju SAML autentikaciju (tipično „cloud“ resursi), a koji se može naknadno iskorištavati i izvan  konteksta SUNBURST napada.

Svaka tema obuhvaćena ovim tekstom otvara nova područja, a osnovna tema - slučaj SUNBURST/Solarigate – daleko je od toga da je možemo smatrati apsolviranom, ni na tehničkoj niti na političkoj razini.