Wybrany post: Ciekawa metoda na wykonanie ruchu bocznego i atakowanie komputerów w sieci – na przykładzie bezplikowego narzędzia SCShell i DNS-Shell

W dzisiejszym artykule opiszemy nową, ciekawą metodę, za pomocą której można wykonać ruch boczny w środowisku Windows i odpalić na zdalnym komputerze ładunek (payload) podczepiając się pod istniejącą w systemie usługę. Zwróciła ona naszą uwagę, ponieważ jest nieco odmienna od tych zwykle stosowanych przez cyberprzestępców (np. narzędzia psexec.exe, powershell.exe, itp.). Stąd warto się jej przyjrzeć z uwagi na możliwości jej implementacji w przyszłych malware. Postanowiliśmy ją dla Was opisać oraz przedstawić artefakty ataku w systemie, zebrane na podstawie analizy w narzędziu SysmonView, które pomogą w wykryciu po stronie systemów bezpieczeństwa IT. Pokażemy też scenariusz ataku pokazujący jak za pomocą tej metody oraz usługi DNS możemy przejąć kontrolę nad innym serwerem/komputerem w sieci. Miłej lektury 🙂

Przejęcie poświadczeń w systemie i ich eskalacja

Przejęcie poświadczeń (sekretów) użytkownika do systemu operacyjnego to pierwszy krok ataku jaki chcą zdobyć atakujący na komputerach swych ofiar w sieci. Wykonują to najczęściej za pomocą najróżniejszych ataków phishingowych lub innych sposobów i metod kuszących użytkownika do wykonania pierwszego ruchu – odpalenia specjalistycznego kodu/ładunku, który w dalszej fazie zainstaluje/uruchomi na ich komputerze złośliwe oprogramowanie – w nomenklaturze bezpieczeństwa nazywane oficjalnie malware’m. Dopiero za jego pomocą cyberprzestępca będzie mógł przejąć pełną kontrolę nad atakowanym komputerem. Cyberprzestępcy oprócz atakowania użytkowników wykorzystują jeszcze inne metody, takie jak zero day’e (np. BlueKeep) pozwalające wykonać zdalnie akcje na systemie bez wymaganej interakcji z użytkownikiem, co pozwali im ominąć w ten sposób zabezpieczenia. Lecz te należą do niezwykle rzadkich. W zeszłym tygodniu Microsoft załatał podatność CVE-2019-1405 związaną z błędem w uprawnieniach usługi „UPnP Device Host” oraz w październiku podatność CVE-2019-1322 związaną z błędem w usłudze COM. Obie podatności pozwalały zwykłemu użytkownikowi zalogowanemu systemie Windows zdobyć uprawnienia na poziomie integralności systemu (NT AUTHORITY\SYSTEM) – w sieci można znaleźć eksploit o nazwie COMahawk, który umożliwia wykonanie eksploiatacji tych luk.
O innej, trywialnej metodzie przejęcia uprawnień systemowych związanej z oknem UAC oraz certyfikatem pisaliśmy w zeszłym tygodniu w artykule tutaj.

Zatem można się z tym zgodzić, że konto użytkownika (jego poświadczenia) jest pierwszym perymetrem, którego złamanie sekretów pozwoli cyberprzestępcy na wykonanie dalszych kroków w celu zdobycia wysoko uprawnionego dostępu do komputera. Potem pozostaje już tylko próba ataku na inne komputery w sieci (tzw. faza post-eksploitacyjna), przejmowanie na nich kolejnych kont i eksfiltracja danych itp.

Wykonanie ruchu bocznego z poziomu natywnych komend systemowych

Jak widać na podstawie powyżej opisanych, najnowszych doniesień i odkryć w świecie cyberbezpieczeństwa czasami wystarczy eksploit na znaną podatność i uzyskujemy najwyższe uprawnienia w systemie, w tym przejmujemy konto administratora! Dlatego ważne jest, aby jak najczęściej wykonywać aktualizacje w komputerze i odpowiednio zabezpieczać się implementując wyspecjalizowane oprogramowanie do ochrony. Są też inne metody przejęcia uprawnień w sieci korporacyjnej, ale nie będziemy się na nich skupiać. Możesz je znaleźć w innych naszych artykułach.

Kolejnym krokiem po przejęciu kontroli nad komputerem ofiary, który wykonują cyberprzestępcy to przejęcie innych komputerów w sieci z wykorzystaniem metody zwanej ruchem bocznym (ang. Lateral movement). Części metod związanych z wykonaniem takiego ataku opisaliśmy w kilku z artykułach w kampanii CYBER KILL CHAIN np. pass-the-hash, Golden Ticket i inne.
Skuteczność użycia odpowiedniej metody w tej fazie ataku przez atakującego determinuje to, czy zostanie wykryta przez specjalistyczne oprogramowania do bezpieczeństwa, czy nie. W tym celu cyberprzestępcy, aby zmniejszyć ryzyko wykrycia najczęściej używają dostępnych w systemie operacyjnym Windows natywnych narzędzi z linii komend i języków skryptowych, tych samych, które używane są przez administratorów w swojej codziennej pracy.
Jednym z powodów, dlaczego atakujący decydują się na ich użycie jest brak konieczności wgrywania dodatkowych narzędzi i to, że niektóre z nich pozwalają na zdalnie zarządzanie innymi komputerami w sieci. Lecz będą to mogli robić pod warunkiem, że uprawnienia konta, które wcześniej przejęli pozwolą im na zalogowanie się zdalnie do innego komputera oraz wykonać określone aktywności.

Od strony monitorowania bezpieczeństwa IT wykrycie incydentu przejęcia konta z uprawnieniami administracyjnymi na jednym komputerze i użycie jego poświadczeń na drugim jest niezwykle trudne, ponieważ wymaga wiedzy na temat wykorzystania takiego konta w codziennej pracy i przydzielonych uprawnień jakie posiada to konto w infrastrukturze (tzw. kontekst działania). Zastosowanie szeregu korelacji zdarzeń, najczęściej wykonywanych w systemach SIEM nie zawsze przynosi zamierzone skutki.

Działy bezpieczeństwa w firmach najczęściej radzą sobie z takimi przypadkami wprowadzając tzw. „czarne i białe listy komend i aplikacji” (od ang. Application Whitelisting) blokowanych lub nie przed ich uruchomieniem na komputerach przez użytkownika. W tym celu mogą dodatkowo implementować specjalistyczne oprogramowanie pozwalające wykryć niepożądane ich użycie. Ale w praktyce różnie z tym bywa, niekiedy blokowanie przeszkadza w działaniu innego oprogramowania lub w pracy administratorów, ciężko tym sią zarządza w dużej firmie i tworzone są wyjątki.

Do najbardziej popularnych narzędzi linii komend umożliwiających zdalne zarządzanie komputerami (pozwalających zdalnie uruchamiać na nich polecenia) można zaliczyć:

• PsExec.exe (darmowe narzędzie z sysinternals)
• PowerShell.exe (język skryptowy Powershell),
• wmic.exe (WMI),
• winrs.exe (WinRM),
• schtasks.exe (Task scheduler),
• sc.exe

Mamy świadomość, że to zapewne nie jest cała lista, lecz w przypadku, kiedy w środowisku mamy związane ręce i bezpieczeństwo monitoruje użycie tych komend warto byłoby znaleźć inny sposób, który nam umożliwi przeprowadzenie ruchu bocznego oraz wykonanie dowolnego kodu na zdalnym komputerze.

Jaka jest alternatywa w przypadku blokowania natywnych komend?

Odpowiedź jest prosta – napisanie własnego narzędzia lub skryptu. Kod każdego programu/narzędzia wbudowanego w system operacyjny, czy skryptu w swoim działaniu finalnie wykonuje niskopoziomowe funkcje API Windows. Gdybyśmy chcieli przeprowadzić niskopoziomową blokadę wykonania funkcji API mogłoby się to źle skończyć dla systemu operacyjnego powodując jego niestabilność. Zatem ciężko się w tym przypadku chronić na poziomie funkcji API i stanowi to dużą lukę w bezpieczeństwie.

W tym momencie przechodzimy do sedna, czyli opiszemy inną metodę pozwalającą zdalne wykonać komendę, a w niej payload na innym komputerze w sieci z wykorzystaniem protokołu DCE-RPC (ang. Distributed Computing Environment Remote Procedure Call).
Na przykładzie narzędzia SCShell pokażemy jak po przejęciu konta administratora będziemy w stanie na zdalnym komputerze podczepić się pod wybraną usługę działającą w systemie Windows, odpalić dowolny ładunek (payload) i skomunikować się z innym serwerem C2.

Co to jest SCShell?

SCShell to bezplikowe narzędzie napisane w języku C oraz Python służące do wykonywania ruchu bocznego w sieci dzięki możliwości przeprowadzania kontroli zmian w lokalnych usługach Windows. SCSShell może posłużyć też jako obejście funkcji blokad aplikacji (AppLocker), ponieważ może podobną zmianę wykonać na lokalnym komputerze pod warunkiem, że uzyskamy uprawnienie lokalnego administratora. Przy okazji wprowadzania zmian w usługach potrafi uruchomiać dowolną komendę (np. ładunek payload). Kod narzędzia uruchomia zdalne polecenia wykorzystując wbudowaną w Windows, niskopoziomową funkcję API „ChangeServiceConfigA” służącą do zmiany ustawień usług. Zaletą tego narzędzia jest to, że nie wykonuje ono uwierzytelnienia po protokole SMB jak np. „PsExec.exe”, lecz komunikacja odbywa się za pomocą protokołu DCE-RPC.

Przypominamy, że komunikacja DCE-RPC nasłuchuje na portach TCP i UDP 135, które są standardowo włączone w sieciach korporacyjnych na komputerach Windows i służą do zarządzania.

Autor narzędzia planuje także wypuszczenie odpowiedniej wersji dla PowerShell i C#.

Ciekawostką w narzędziu jest to, że podczas swojego wywołania na zdalnym (lub lokalnym) komputerze ofiary nie zostawia ono żadnego pliku na jego dysku (w zależności od techniki użytej w uruchomianej w komendzie) oraz w odróżnieniu do PowerShell – nie rejestruje, ani nie tworzy na nim usług.

SCShell zamiast tworzyć usługę na zdalnym komputerze, po prostu zdalnie otwiera istniejącą usługę, modyfikuje za pomocą funkcji interfejsu API ChangeServiceConfigA jej nazwę ścieżki binarnej podczepiając pod nią dodatkową komendę (ładunek,) a następnie ją uruchamia. Po zakończeniu wykonywania ładunku ścieżka binarna usługi przywracana jest do swojej pierwotnej wartości. Oryginalna ścieżka usługi jest wyodrębniana przy użyciu niskopoziomowej funkcji QueryServiceConfigA.

Wywołanie SCShell.exe:

SCShell.exe 〈IP_komputera〉 〈nazwa_docelowej_usługi〉 〈ładunek〉 〈domena〉 〈nazwa_użytkownika〉 〈hasło〉

W parametrze IP_komputera można ustawić na lokalny adres, wtedy ładunek zostanie uruchomiony lokalnie.
W parametrze ładunek podajemy w cudzysłowie komendę z parametrami jaka ma się wykonać w momencie odpalenia usługi. Zalecane jest użycie pełnych ścieżek do plików. Jeśli użyjemy komendy z cmd.exe z przełącznikiem „/c” będziemy mieli pewność, że ładunek nie zostanie „ubity” po zatrzymaniu usługi.

Jak reagują na SCShell skanery bezpieczeństwa?

W celach testowych wrzuciliśmy dla pewności binarkę SCShell.exe na VirusTotal, aby mieć poglądowe informacje na temat liczby silników skanerów bezpieczeństwa, które o niej wiedzą 🙂 Autor narzędzia udostępnił jego kod 14 listopada 2019r.. A o to wynik (3/65).

Uwaga dla szanownych redaktorów rozpisujących się na temat bezpieczeństwa i uważających, że VirusTotal nie jest w tej kwestii niemiarodajny i krytykujących nasze podejście do problemu:

„Mamy świadomość, że w środowisku korporacyjnym i z użyciem doposażonego antywirusa w sondy HIPS/IPS, Sandboxer’a i EDR skuteczność wykrywania będzie dużo większa, ale w naszym scenariuszu nie chodzi przecież o to. Metod na przesłanie kodu, jego zaciemniania, dostarczenia na komputer jest naprawdę bardzo dużo, tak samo jak na jego uruchomienie. Poza tym zawsze w sieci może się znaleźć „słabsze ogniwo” w postaci mniej zabezpieczonego komputera lub mniej świadomego użytkownika. Czasami możemy jedynie polegać na wbudowanych narzędziach bezpieczeństwa w system Windows oraz na ograniczonym zestawie narzędzi do zapewnienia bezpieczeństwa w firmie. Suma summarum, pokazujemy tylko sposób/problem i prosimy – traktujcie go tylko i wyłącznie do celów edukacyjnych”.

Scenariusz wykorzystania SCShell

Po krótkim wstępie do tematyki możemy przejść do testów. W naszym scenariuszu pójdziemy trochę na skróty – z czystego lenistwa i nie będziemy wykonywać całej fazy eksploitacji systemu (jak to wykonać dowiesz się z linków z początku tego artykułu). Załóżmy, że na Windows 10 1903 v2 z zainstalowanym i włączonym Defenderem oraz ze wszystkimi najnowszymi aktualizacjami zdobyliśmy poświadczenia zwykłego użytkownika. Do wykonania ataku na inny komputer w sieci (serwer) będą nam jeszcze potrzebne uprawnienia użytkownika posiadającego lokalne uprawnienia administracyjne, ponieważ tylko wtedy poprawnie zadziała nam SCShell. Krok zdobycia lokalnego admina też pominiemy. Korzystając z wiedzy zaprezentowanej w artykule DNS-Shell, pokażemy jak przy użyciu SCShell odpalimy po protokole DCE-RPC ładunek na zdalnym serwerze, który umożliwi na jego komunikację po protokole DNS z innym serwerem C2 w sieci.

Specjalnie wybraliśmy atak wykorzystujący DNS, ponieważ uważamy, że jest on jeszcze rzadko monitorowany w sieciach korporacyjnych. Pomimo, że na serwerach w sieci nie powinno być połączenia z Internetem, to komunikacja po DNS jest otwarta. Więc istnieje duże prawdopodobieństwo, że dzięki temu będziemy w stanie z serwera C2 zdalnie kontrować przejęty serwer.

Ponieważ autor programu udostępnia kod źródłowy w jęz. C i Python, moglibyśmy go dodatkowo skompilować do biblioteki DLL lub przepisać na język C# lub PowerShell i użyć bez konieczności przesyłania na stację roboczą użytkownika pliku wykonywalnego – ten krok też pominęliśmy. Schemat ataku pokazuje poniższy obrazek.

Krok 1. Przygotowanie ładunku do przeprowadzenia inicjacji sesji po DNS z serwerem C2

Logujemy się na serwer C2 (Kali Linux), który będzie naszym serwerem sterowania i dowodzenia. Na podstawie artykułu DNS-Shell przygotowaliśmy zaszyfrowany w PowerShell ładunek (payload), który użyjemy do przeprowadzenia inicjacji odpalenia sesji po protokole DNS z atakowanego serwera Windows 2016 do naszego serwera C2 (172.16.215.200) w sieci.

Powyższy kod ładunku musimy przekopiować i wkleić do wywołania komendy w następnym kroku.

Krok 2. Uruchomienie kodu programu SCShell.exe na komputerze ofiary

Jesteśmy zalogowani jako zwykły użytkownik na stacji Windows 10 v1903 v2. W celu wykonania ataku na serwer Windows 2016 i wstrzyknięcia do usługi przygotowanego wcześniej przez nas ładunku wykorzystamy wbudowaną w systemy Windows usługę Xbox Accessory Management Service (XblAuthManager) i poświadczenia konta lokalnego administratora. Moglibyśmy podobną operację wykonać na lokalnym komputerze (stacji roboczej) – zawsze to jakiś sposób na obejście AppLocker’a 🙂 Nasza linijka do uruchomienia wygląda następująco:

SCShell.exe [IP_atakowanego_serwera] XblAuthManager „C:\windows\system32\cmd.exe /c C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe -e [ładunek]” . [nazwa_-lokalnego_admina] [hasło]

Na poniższym ekranie widzimy, że udało nam się z powodzeniem na serwerze podmienić parametry wywołania usługi XblAuthManager i uruchomić ładunek. W końcowej fazie wykonania programu usługa została przywrócona do poprzednich ustawień.

Krok 3. Sprawdzenie na serwerze C2 stanu połączenia z przejętym serwerem

Logujemy się na serwer C2. Jeśli cała operacja nam się powiedzie powinniśmy na nim zobaczyć zdalny wiersz poleceń z serwera Windows 2016 (DC.kapitan.hack), w którym możemy wykonać dowolną komendę.

Jako ciekawostkę dodamy, że na przejętym serwerze mamy najwyższe uprawnienia na poziomie SYSTEM. Stanowi to poważne zagrożenie!

Dla zainteresowanych poniżej zamieszczamy nagranie z całego scenariusza. Miłego oglądania.

Analiza od strony bezpieczeństwa, czyli co możemy zaobserwować po stronie systemu?

W tym momencie warto pokazać, czy jesteśmy w stanie w jakiś sposób wykryć ten typ ataku w sieci korporacyjnej? Bez zastosowania specjalistycznych narzędzi byłoby nam ciężko dowiedzieć się co się zadziało po stronie systemu operacyjnego. Nawet jeśli odpowiednio skonfigurowalibyśmy natywną politykę audytu na Windows dostalibyśmy jedynie szczątkowe informacje w logach Security. Do celów analizy problemu na serwerze i stacji roboczej, z której odpalamy SCShell uruchomiliśmy i skonfigurowaliśmy darmowe narzędzie – SysMon w wersji 10. Następnie sprawdziliśmy, co był w stanie powiedzieć nam o poszczególnych krokach naszego scenariusza. W analizie wspomogą nas także dwa narzędzia: ProcessHacker oraz SysmonView.

1. Uruchomienie SCShell na komputerze

Analizując logi Sysmon ze stacji roboczej Windows 10 w narzędziu SysMonView widzimy, że proces „cmd.exe” uruchomił proces potomny „SCShell.exe” z całą linią parametrów i zaszyfrowanym payload’em (CommandLine).

2. Wykonanie payload na serwerze Windows

Od strony serwera Windows 2016 widzimy w logach Sysmon modyfikację parametrów usługi XblAuthManager. Ponieważ SCShell wykonuje zmiany w konfiguracji usługi (parametrach jej uruchomienia) możemy to zaobserwować w informacji o zmianie klucza rejestru „HKLM\System\CurrentControlSet\Services\XblAuthManager\ImagePath” i wpisaniu w nim wartości zawierającej komendę uruchamiającą ładunek (Details).

Następnie widać, że z poziomu procesu „services.exe” uruchamiany jest proces „cmd.exe” z ładunkiem. Wszystko się zgadza, ponieważ na stacji roboczej SCShell zdalnie zarządza usługą „XblAuthManager” na serwerze DC.kapitan.hack, w której zmienił parametry jej wywołania i uruchomił ją z parametrem zawierającym złośliwy ładunek.

Linia komend cmd.exe wywołuje polecenie PowerShell, który dekoduje payload. W celu analizy uruchomionego kodu PowerShell musielibyśmy zajrzeć do logów PowerShell w systemie. Pominęliśmy ten krok.
W Sysmon widzimy także komunikację DNS po protokole UDP 53 i zapytania, jakie są wykonywane z serwerem C2 (172.16.215.200) przy użyciu „nslookup.exe”

Widzimy także cykliczne zapytania DNS i komunikację z serwerem C2.

Od strony procesów widocznych w ProcessHacker możemy zdiagnozować, że odpalony został proces „powershell.exe” i z niego odpalany jest „nslookup.exe” w celu wykonywania zapytań do serwera C2.

Ciekawostką jest, że proces „cmd.exe” i podrzędny proces „powershell.exe” uruchomił się na uprawnieniach użytkownika „NT AUTHORITY\SYSTEM” (odziedziczył je po usłudze XblAuthManager)!

Podsumowanie

Opisywany przypadek ataku nie należy do łatwych do wykrycia w infrastrukturze IT, jeśli nie posiadamy wdrożonych odpowiednich narzędzi do ochrony. Kod użytego narzędzia wykorzystuje niskopoziomowe funkcje API Windows, dlatego może być trudny do zablokowania, bo może to spowodować niestabilność w pracy systemu. Innym zagrożeniem jakie powoduje ten atak to eskalacja uprawnień do SYSTEM wykorzystywanych przez atakowaną usługę na docelowym systemie. Oznacza to, że kod programu może wykonać szereg innych aktywności np. wyczyszczenia logów, zatrzymania usług antywirusa, „ubicia” procesów, dzięki którym realizowany jest monitoring bezpieczeństwa.

Oczywiście, aby mógł się zadziać cały atak musi zajść szereg wcześniejszych kroków pozwalających na finalne uruchomienie programu w środowisku (faza eskploitacji i wykonania).
Poniżej zamieściliśmy klika porad, które pozwolą nam wykryć przypadek opisywany powyżej oraz zminimalizować ryzyka przed wystąpieniem tego typu ataku.

Jak sobie radzić z problemem?

Powyższy przykład działania SCShell to tylko jeden z wielu opisujących na Kapitanie Hack’u problemów we współczesnym świecie cyberbezpieczeństwa. Techniki ataków non stop ewaluują. W sieci korporacyjnej możemy jednak użyć konfiguracji, które pozwolą nam zminimalizować ryzyka przed wystąpieniem tego typu atakami oraz pozwolą nam je wykryć:

1. Wprowadzenie segmentacji sieci (logiczna i fizyczna). Dobrze posegmentowana sieć pozwoli nam lepiej kontrolować to co się w niej dzieje i przede wszystkim uniknąć niechciane przeskoki/ruch boczny na inne serwery. Obserwacja punktów styku i blokady przejść będą na pewno wskazane.
2. Wdrożenie LAPS lub dobrego rozwiązania do ochrony kont uprzywilejowanych (zarządzania hasłami lokalnych administratorów na komputerach) – jeśli w jakiś sposób dojdzie do przechwycenia przez cyberprzestępcę uprawnień administracyjnych (nawet tych lokalnych) nie dopuścimy w sieci, aby z niego mógł zalogować się na to samo hasło użytkownika do innych komputerów
3. Monitorowanie zmian konfiguracji usług na systemach.
4. Wdrożenie systemu Multifactor Authentication lub Certyfikatów PKI do zabezpieczenia logowania użytkowników.
5. Monitorowanie Active Directory pod względem zagrożeń oraz nietypowych zmian.
6. Wykonywanie cyklicznego audytu uprawnień i testów penetracyjnych.
7. Ciągłe aktualizowanie szczepionek antywirusa oraz systemu operacyjnego.
8. Hardening (zabezpieczenie) stacji roboczych i serwerów zgodnie z najlepszymi praktykami np. .CIS Security Standard.
9. Wprowadzenie Zero Trust Security – bezpiecznych warstw zarządzania serwerami i PAW (Privileged Access Workstations).
10. Zastosowanie systemu, który będzie mógł kontrolować przydziałem uprawnień dla użytkowników uprzywilejowanych w taki sposób, aby użytkownik uprzywilejowany był uprzywilejowany TYLKO w określonym czasie pracy, po którym powinny mu być odbierane uprawnienia.
11. Pozbycie się na komputerach uprawnień administracyjnych dla pracujących na nich użytkowników.
12. Użycie dobrego antywirusa z sondą HIPS/IPS oraz modułem EDR lub rozważyć zaimplementowanie darmowego Sysmon w odpowiedniej konfiguracji.
13. Monitorowanie logów i wdrożenie systemu SIEM.
14. Obserwacja sieci pod kątem ruchu bocznego kont – najlepiej wykorzystać do tego system z uczeniem maszynowym, które będą w stanie rozpoznać pierwsze zalogowanie się użytkownika w systemie oraz ruch boczny (przemieszczanie się konta pomiędzy różnymi komputerami w sieci).
15. Zwrócenie uwagi na kontekst zalogowanego użytkownika w ruchu bocznym np. czy jest to użytkownik z lokalnymi albo domenowymi uprawnieniami administracyjnymi.
16. Monitorowanie pakietów w sieci i wykrywanie anomalii.
17. Rozważyć możliwość wyłączenie UAC – Na podstawie ostatnio wykrytej luki CVE-2019-1388 (problem z consent.exe/UAC i certyfikatem i przechwycenie uprawnień SYSTEM), to co teraz stwierdzimy może być ironią, ale osobiście uważamy, że wyłączenie ochrony UAC na komputerach i serwerach oraz ograniczenie uprawnień administracyjnych spowoduje, że komputery będą mniej narażone na tego typu ataki.

Zachęcamy do dyskusji, udostępniania i dzielenia się z nami opinią na portalu LinkedIn oraz Facebook.

Artykuł sponsorowany przez Veracomp – Exclusive Networks Poland SA i Tenable – właściciela oprogramowania Tenable.ad.