Można by pomyśleć, że najprostsza i najlepsza metoda skopiowania plików z komputera na dysk zewnętrzny, to po prostu podłączenie tego dysku do włączonego komputera i uruchomienie kopiowania z poziomu Windows. I rzeczywiście, tak bywa najprościej…
Niezauważone wejście do czyjegoś biura to dziś temat dużo trudniejszy niż np. 30 lat temu, z powodu rozwoju systemów monitoringu wizyjnego. Ulice i budynki są dziś obłożone tysiącami kamer przemysłowych, utrwalających każdy nasz ruch. Kilka lat temu pojawiło się jednak nowe, gorsze zagrożenie.
Każde biuro jest inne, a zarazem wszystkie są w pewien sposób podobne. I niemal wszystkie ewoluują: rzadko można dziś spotkać biuro raz urządzone 10-20 lat temu i działające bez zmian. Omówmy pokrótce, jakie zmiany wpływające na możliwość i efektywność ataku zaszły na przestrzeni ostatnich 15 lat.
Niewykorzystane okazje lubią się mścić – to stare powiedzenie z piłki nożnej świetnie pasuje też do niejawnych działań operacyjnych: jeśli nie wiesz, na co możesz natknąć się w miejscu akcji, masz do wyboru albo to zostawić, albo ryzykować dekonspirację przez działania ad-hoc.
Tym artykułem rozpoczynamy nowy cykl, w którym objaśnimy krok po kroku, w jaki sposób zabrać się za zaatakowanie i wyprowadzenie danych z większej firmy – ale zanim przejdziemy do konkretów, musimy sobie wyjaśnić kilka podstawowych spraw.
W ostatnim już odcinku naszego cyklu pozostało już tylko zainteresować się kwestiami finansowymi (w końcu to one są ostatecznym celem), oraz przygotować dekryptor pozwalający klientom odzyskać dane. Zaczynamy.
Ten odcinek będzie inny od wszystkich poprzednich. Odłożymy w nim na jakiś czas edytor kodu i zajmiemy się pisaniem… tekstu, w którym poinformujemy użytkownika, że jego pliki zostały zaszyfrowane. Tekstu, od którego zależy efektywność Twojego biznesu.
Dzisiaj rozwiniemy nieco wątki z części piątej, dotyczące panelu webowego. Właściwy program szyfrujący to bowiem dopiero połowa sukcesu. Na drugą połowę składa się m.in. właśnie panel umożliwiający efektywną obsługę „klienta”.
W szóstej części naszego cyklu rozpatrywaliśmy różne scenariusze dotarcia do „klienta”, zaczynając od phishingu, a kończąc na fizycznym dostępie do nośnika lub komputera naszego celu. Dwóm ostatnim metodom poświęciliśmy zresztą osobne artykuły, dzisiaj zaś skupmy się na technicznej stronie phishingu.
W poprzedniej części cyklu zakończyliśmy pracę nad częścią programu odpowiedzialną za „core business”, czyli właściwe szyfrowanie danych i odpowiednio długie unikanie wykrycia. Do programu wrócimy jeszcze w części dziewiątej, mówiąc o komunikacie dla użytkownika.
W ostatnich 2 tygodniach omówiliśmy różnice pomiędzy Amazon Web Services, Microsoft Azure i Google Cloud odnośnie zarządzania użytkownikami, uprawnieniami i kluczami dostępowymi. Oprócz trzech największych graczy jest jeszcze jeden, wprawdzie posiadający znacznie mniejszą chmurę, ale utrzymujący w niej sporo lukratywnych usług opartych na rozwiązaniach biznesowych firmy Oracle.
Kilka dni temu porównaliśmy zarządzanie użytkownikami, uprawnieniami i kluczami dostępowymi w Amazon Web Services i Microsoft Azure. Dzisiaj pora na ostatniego z trzech największych graczy w branży chmury publicznej, czyli Google Cloud.
W ostatnią środę opisaliśmy organizację zarządzania uprawnieniami w Amazon Web Services. Dziś, w drugim odcinku tego mini-cyklu, skupimy się na Microsoft Azure: jakie dane związane z logowaniem mogą być przechowywane po stronie użytkownika i w jaki sposób, oraz jakie są różnice w tym zakresie pomiędzy AWS a Azure.
Niniejszym artykułem o AWS rozpoczynamy kolejny mini-cykl artykułów, tym razem poświęcony organizacji zarządzania uprawnieniami w poszczególnych chmurach publicznych – a także temu, jakie dane związane z logowaniem mogą być przechowywane po stronie użytkownika i w jaki sposób.
A więc prototyp Twojego ransomware jest gotowy. Czas więc zająć się kampanią. Ten odcinek skupia się na tym, jak efektywnie ogarnąć dziesiątki lub setki tysięcy infekcji i tysiące wpłat od „klientów”, nie gubiąc się po drodze w wycenach okupów i poprawnie oceniając rodzaj każdego „klienta” na podstawie kluczowych danych zebranych przez Twój program.
W czwartej części cyklu rozwiniemy temat zaczęty w częściach pierwszej i trzeciej, czyli ukrywanie swoich aktywności do czasu zakończenia działań – a więc do momentu, gdy program ukończy szyfrowanie wszystkich możliwych danych i będzie gotów zaprezentować użytkownikowi stosowny komunikat.
W trzeciej części cyklu zastanowimy się, jak odnajdywać wszystkie możliwe do zaszyfrowania dane bez niepotrzebnego zwracania uwagi użytkownika, oraz jak skutecznie maksymalizować jego straty, nawet działając na bardzo powolnym komputerze.
W drugiej części cyklu poznasz zagadnienia związane z wyborem algorytmów szyfrujących, oraz technikami generowania i przekazywania kluczy – tak aby możliwe było odszyfrowanie danych.
Część programowa Funkcjonariusza Mobilnego trzeciej generacji jest zaprojektowana, aby działać na dowolnej stabilnej wersji systemu Debian, Raspbian lub Ubuntu. Ten artykuł przedstawia szczegóły i wskazuje możliwe problemy.
Funkcjonariusz Mobilny trzeciej generacji jest zaprojektowana, aby działać na dowolnej stabilnej wersji systemu Debian, Raspbian lub Ubuntu, używającej systemd do zarządzania usługami. Ten artykuł szczegółowo przedstawia listę tych systemów i testowanego sprzętu.