Jak Microsoft Teams + Quick Assist umożliwiły atakującym dostęp do firmowego komputera? Relacja z obsługi incydentu od naszego czytelnika.

Opiszę tu prawdziwy incydent, jaki miałem ostatnio okazję analizować. Zdarzył się w firmie poza Polską, gdzie standardowym językiem komunikacji był angielski, więc anglojęzyczni atakujący łatwiej podszyli się pod support…

Być może pamiętacie ostrzeżenia dotyczące wykorzystania Quick Assist – Microsoftowego rozwiązania do zdalnej pomocy – coś jak TeamViewer czy AnyDesk, tylko domyślnie (niestety) wbudowanego w system.
Jest ono od dłuższego czasu wykorzystywane w atakach na “pomoc techniczną”, gdzie ktoś podszywa się pod helpdesk – skala jest na tyle duża, że na podstronie Microsoftu poświęconej rozwiązaniu jest od razu link do formularza zgłaszania nadużyć…

Podobnie jak w innych aplikacjach do pomocy zdalnej, atakujący po prostu skłania użytkownika do udostępnienia mu kontroli nad komputerem przez przekazanie współdzielonego sekretu, lub – jak w Quick Assist – wklejenia hasła od atakującego.

Aby całkowicie usunąć komponent z systemu, należy zweryfikować zarówno starszą instalację w C:\Windows\System32, jak i nowszą wersję dystrybuowaną przez Microsoft Store, którą użytkownik może samodzielnie zainstalować (aplikacja występuje pod nazwą zlokalizowaną – np. „Szybka pomoc” w polskiej wersji językowej). Dodatkowo konieczne jest uniemożliwienie ponownej instalacji przez użytkownika.

W omawianej firmie administratorzy próbowali takie odinstalowanie przeprowadzić globalnie, ale jak ze wszystkimi automatami w IT – zwykle znajdą się komputery, na których coś nie zadziała zgodnie z planem…

Jaka w tym ataku rola zapowiedzianego w tytule Teamsa?

Otóż platforma ta umożliwia domyślnie otrzymywanie wiadomości i połączeń głosowych także spoza firmy – od innych użytkowników Teams.
I teraz – jeśli jest to zwykła wiadomość na czacie, to Teams przynajmniej wyświetli ostrzeżenie podobne do tego:

Jednak już w przypadku zaproszenia do czata grupowego, tego ostrzeżenia nie będzie (a przynajmniej do niedawna nie było).

Co jeszcze ważniejsze dla tego incydentu – ostrzeżenia zabraknie też w przypadku połączenia głosowego z zewnątrz…

Oczywiście Microsoft daje w ustawieniach pewne opcje – takie jak zablokowanie komunikacji zewnętrznej w ogóle lub ograniczenie jej tylko do wskazanych domen nadawców, ale nie jest to już tylko kwestia techniczna, ale i biznesowa – tu już nie będzie ostrzeżenia a tylko wybór pomiędzy allow a deny.
Nie każda firma może sobie na to pozwolić (najpewniej spowoduje to opóźnienia w komunikacji i duży narzut konfiguracyjny na IT, które potrzebne domeny musi sukcesywnie dodawać…)

Mamy już dwa główne elementy układanki, przejdźmy więc do samego incydentu:

W godzinach porannych pewien użytkownik otrzymał połączenie głosowe na Teams – źródłem jest konto itadmin@internalitincident[.]onmicrosoft[.]com (co też ładnie pokazuje, jak (nie)działają procedury antyfraudowe w MS przy tworzeniu nazw tenantów 😉)

Na skutek bardzo pechowego zbiegu okoliczności:

1. Ten użytkownik faktycznie zgłaszał akurat IT problem z siecią i spodziewał się kontaktu.
2. W firmie od niedawna pracował nowy specjalista helpdesk, którego użytkownik jeszcze nie znał (ale wiedział o jego zatrudnieniu)

Użytkownik połączenie odebrał (głównie z przyczyny 1), a atakujący celowo przedstawiali się bardzo niewyraźnie, przez co użytkownik “podstawił” sobie w głowie, że to na pewno ten nowy specjalista helpdesk (nazwijmy go „Adam X”).

Mamy tu też siłę autosugestii, bo użytkownik był post factum przekonany, że atakujący przedstawił się jako Adam X, choć nie była to raczej prawda.

Teraz wchodzi drugi element: atakujący poprosili użytkownika o uruchomienie Quick Assist i wprowadzenie podanego przez nich kodu uwierzytelniającego.
Tu mamy kolejny pechowy zbieg okoliczności: akurat na tym komputerze odinstalowanie aplikacji się wcześniej nie udało – a do tego użytkownicy byli przyzwyczajeni do dostępu zdalnego z udziałem innych, podobnych rozwiązań…

Po udostępnieniu atakującym dostępu zdalnego, użytkownik zobaczył jedynie klasyczne „czarne okienka z tekstem” – co również nie wywołało wielkiego zdziwienia, bo IT często odpala skrypty podczas zdalnego supportu.

Zanim firma odkryła incydent dzięki wewnętrznemu Threat Huntingowi, minęło około godziny.
Do czasu kontaktu z lokalnym IT Security użytkownik był przekonany, że wszystko było ok – ot, normalne połączenia ze wsparciem technicznym…

Po odizolowaniu komputera od sieci, rozpoczęła się analiza logów z EDR-a, który oczywiście incydentu jako takiego nie wykrył, ale chociaż można było sprawdzić, co też atakujący kombinowali…

Na szczęście scenariusz ataku okazał się w miarę prosty:

1. Pobranie i uruchomienie zaciemnionego skryptu z domeny hXXps://khanvas[.]com/styles[.]css (mimo zgłoszenia do CERT PL, wciąż jest dostępny – dla amatorów analizy na dzień publikacji tego artykułu)
   Aktualnie, po wrzuceniu na VirusTotal, jest już wykrywany np. przez Defendera jako Trojan:Script/Wacatac.H!ml (jednak wcześniej zarówno domena jak i plik miały minimalne detekcje – 10/62 po 10 dniach, tylko część mainstreamowa)
2. Pobranie z LDAP listy komputerów (i użytkowników)
3. “Skanowanie Powershellem” – najpierw ICMP (ping) na wszystkie komputery z domeny
4. Następnie próby połączeń do udziału „Admin$” (C:\Windows) przez protokoły SMB i WebDAV na wszystkich komputerach, które odpowiedziały na ICMP.

I tu już atakującym się znudziło…
Ponieważ użytkownik nie miał ani uprawnień administratora lokalnego na swoim komputerze, ani na żadnym innym – Lateral Movement się nie udał, więc zabrali swoje zabawki i się rozłączyli (usuwając nawet kilka elementów, które miały pozwolić na utrzymanie przyszłej kontroli nad komputerem (persistence).
Z braku czasu na bardziej rozbudowane analizy, komputer zostało oczywiście wyzerowany i przeinstalowany od zera.

Co robić, jak żyć?

1. Quick Assist to zło i warto je usuwać/blokować wszystkimi sposobami
2. Użytkownicy nie powinni mieć uprawnień administratora lokalnego (a już nigdy: na głównym koncie na którym pracują)
3. Ograniczenie zewnętrznych połączeń w Teams jest warte rozważenia – ale to decyzja biznesowa
4. Blokada używania Powershella może utrudnić atakującym życie – ale ma sens głównie wtedy, gdy próby użycia są wykrywane na bieżąco.
5. Edukacja (Security Awareness) jest ważna, ale raczej nie ograniczy ryzyka konkretnego ataku do 0 – każdego da się oszukać, jeśli trafi się w dogodny moment i okoliczności, co dobitnie pokazał przypadek Troya Hunta 
6. EDR nie zablokuje magicznie każdego ataku 😉
7. Warto rozważyć postawienie w sieci prostych honeypotów (np. darmowy OpenCanary) i dodanie ich w domenie oraz DNS pod zachęcającą nazwą – metoda: “ktokolwiek dotknie: idzie alert” jest możliwa do wdrożenia nawet w sporej organizacji
8. Da się zrobić w organizacji baseline użycia Powershella (na bazie logów z EDR) i wyłapywać nieznane przypadki – wymaga to trochę tuningu, ale wbrew pozorom zadziała – nawet w sporej organizacji – dając finalnie nieznaczną liczbę alarmów false–positive. Wystarczy zacząć od wszystkich wykonań Powershella i stopniowo dodawać do wyjątków te spodziewane.

Czy będzie to rozwiązanie idealnie szczelne? Oczywiście że nie – tuning wymaga pewnych kompromisów – ale działa. To samo dotyczy wielu LOLbinsów…

~ Stanisław Jesiak aka Zerat