"Atak się powiódł, gdyż popełniono wiele błędów" – podsumowało wyniki analizy Rządowe Centrum Bezpieczeństwa. 

Wymienia kilka przyczyn tego stanu rzeczy: utrzymywano serwis informacyjny w środowisku aplikacyjnym, które było podatne na ataki, zignorowano ostrzeżenia, iż strona KNF zawiera zatruty kod źródłowy, utrzymano komputery z nieaktualnym i podatnym oprogramowaniem, nie monitorowano ruchu sieciowego z infrastruktury zawierającej chronione informacje.

W ocenie jednostki zajmującej się cyfrowym bezpieczeństwem trudno jednoznacznie wskazać, kto dokonał ataku i dlaczego. Trudno też jednoznacznie stwierdzić, jaki był cel hakerów.

"Stopień zaawansowania oraz techniki operacyjne nie są typowe dla cyberprzestępców, którzy kierują się kryterium finansowym w swoich atakach." – uważa RCB.

Symantec jest pewny, że to grupa Lazarus kojarzona z Koreą Płn. Są też ślady wskazujące na rosyjskojęzycznych hackerów, jednak ten trop uznano jako próbę wprowadzenia w błąd.

Według analizy RCB, co potwierdza wcześniejsze ustalenia, atak zaczął się od strony Komisji Nadzoru Finansowego. Została „zatruta” – jak to określa centrum – to znaczy wykorzystując nieaktualizowaną aplikację strony umieszczono w niej dodatkowy kod, który był wykonywany na każdym komputerze odwiedzającym daną stronę. W ten sposób banki zarażały się groźnym oprogramowaniem, komunikując się ze stroną KNF. Tego typu dystrybucja nosi nazwę metody wodopoju (watering hole). 

Banki założyły bez weryfikacji, że skoro KNF opracowuje, egzekwuje oraz kontroluje standardy (w tym bezpieczeństwo) w podmiotach mu podległych, to on sam będzie bezpieczny. 

Serwis informacyjny KNF był zainfekowany od 5 października 2016 roku do 2 lutego 2017 r. W serwisie zmodyfikowano kod JavaScript, który nakłaniał każdy komputer gościa do pobrania i uruchomienia skryptu ze złośliwego serwera. Skrypt ten weryfikował czy ofiara stanowi cel jaki wyznaczył sobie atakujący, a dokładniej czy jego adres IP należy do grup adresowych, które były celem. Tutaj trzeba zauważyć, że atakujący wcześniej przeprowadził rekonesans i uzyskał informacje o swojej ofierze (instytucji finansowej, banku). 

"Atak nie był przeprowadzany metodą na chybił trafił, tylko dokładnie zaplanowany. Co więcej, przeprowadzano również weryfikacje, czy aktualnie atakowana sieć nie znajduje się na liście zakazanych sieci, aby jak najdłużej uniknąć wykrycia ataku." – informuje rządowy ośrodek.

Jeżeli ofiara nie wykryła ataku, następowało pobranie ze złośliwego serwera jednego z czterech exploitów, które wykorzystywały znane podatności we wtyczce Silverlight oraz wtyczce Flash w przeglądarce internetowej. Jak ustaliło RCB, podatności, które zostały wykorzystane w ataku, ujawniono już w 2015 r. w kwietniu 2016 roku i znane były poprawki, ale polskie instytucje nie zastosowały ich. 

Wykonanie eksploita pozwalało hakerom na uzyskanie dostępu do systemu komputera ofiary pobranie oraz automatyczne uruchomienie narzędzi służących do zbierania informacji o kontrolowanym środowisku i przekazaniu ich na serwer przestępców.  

Hakerzy mogli swobodnie penetrować polskie banki:
"Intruz praktycznie kontrolował zaatakowane środowisko, zabezpieczenia techniczne zostały przełamane lub ominięte. Złośliwy program sterowany był zdalnie przez przestępcę komendami, które między innymi pozwalały na przeglądanie zasobów komputera i sieci, komunikację z innymi zainfekowanymi komputerami, zaszyfrowanie kopii interesujących plików, po czym wysłanie ich na zdalny serwer." – ustaliło RCB.

Według ośrodka w tej chwili trudno ocenić czy była to końcowa faza ataku. Możliwe, że chodziło tylko o przygotowanie do innego ataku, np. takiego, którego skutkiem mogło być wytransferowanie pieniędzy z banków.

Wnioski RCB są następujące:

– konieczność znaczącej poprawy współpracy i wymiany informacji między instytucjami i podmiotami prywatnymi i zewnętrznymi.

– prowadzenie działań proaktywnych oraz weryfikacja zabezpieczeń.

– wdrażanie i stałe stosowanie polityk bezpieczeństwa, norm, standardów (m.in. budowanie bezpiecznych architektur, wdrażanie rozwiązań klasy Security by Design, Defense in Depth).

– przygotowanie oraz przetestowanie procedur związanych z incydentami

– w skali ogólnopolskiej powinien powstać Plan Reagowania na Incydenty Komputerowe (Incident Response Plan – IRP).

"Nie można pozostawić żadnego obszaru poza kontrolą bezpieczeństwa, gdyż nawet na pozór nieistotne miejsca w cyberprzestrzeni mogą stanowić punkt wejściowy do ataku." – konkluduje RCB,

Artykuł RCB: „Atak się powiódł” pochodzi z serwisu CRN.