Co system operacyjny wie o Twoich błędach – analiza logów jako źródło wiedzy dla atakującego
Cyberbezpieczeństwo

Co system operacyjny wie o Twoich błędach – analiza logów jako źródło wiedzy dla atakującego

Co system operacyjny wie o Twoich błędach – analiza logów jako źródło wiedzy dla atakującego

Dlaczego to temat „ślepej plamki”

Logi systemowe są powszechnie traktowane jako czysto techniczne: do diagnostyki, debugowania, audytu.
Problem polega na tym, że te same logi są gotowym źródłem wywiadu dla osoby atakującej.

Nie trzeba malware.
Nie trzeba exploita.
Wystarczy dostęp do logów – lokalny, z backupu, ze snapshotu VM albo po włamaniu o niskim poziomie uprawnień.


Czym naprawdę są logi systemowe?

Logi to:

  • zapis błędów, ostrzeżeń i wyjątków,
  • historia nieudanych operacji,
  • ślad po tym, co system próbował zrobić i dlaczego mu się nie udało.

Z perspektywy ataku:

błąd = informacja
informacja = przewaga


Windows – Event Viewer jako mapa środowiska

 

 

Image

Image

1. Błędy logowania (Security Log)

Event Viewer zapisuje:

  • nazwę konta,
  • typ logowania (lokalne, sieciowe, RDP),
  • nazwę hosta lub IP,
  • informację, czy hasło było błędne, czy konto nie istnieje.

Co z tego wyciąga atakujący?

  • listę prawdziwych nazw użytkowników,
  • które konta są aktywne,
  • czy RDP/SMB jest używane,
  • politykę haseł (lockout, brak lockoutu).
Czytaj  Analiza Kodu Złośliwego Oprogramowania do Kopania Kryptowalut

2. Błędy sterowników i sprzętu

Logi zawierają:

  • dokładne nazwy sterowników,
  • wersje,
  • ścieżki plików,
  • producenta sprzętu.

Efekt:

  • fingerprint systemu,
  • identyfikacja podatnych wersji driverów,
  • wskazówki do eskalacji uprawnień (stare sterowniki = klasyczny wektor).

3. Błędy aplikacji

Crash logi ujawniają:

  • dokładną wersję aplikacji,
  • moduł, który się wywalił,
  • czas działania,
  • bibliotekę DLL.

Dla atakującego:

  • lista zainstalowanego oprogramowania,
  • informacja, co działa jako usługa,
  • potencjalne punkty RCE lub DLL hijacking.

Linux – logi jako surowy wywiad systemowy

 

 

Image

Image

1. auth.log / secure

Zawiera:

  • nieudane logowania SSH,
  • nazwy użytkowników,
  • użyte metody (password, key),
  • IP źródłowe.

Wnioski dla atakującego:

  • które konta istnieją,
  • czy root ma dostęp przez SSH,
  • czy klucze są używane,
  • czy MFA w ogóle występuje.

2. syslog

W syslogu lądują:

  • błędy demonów,
  • problemy z siecią,
  • restartowane usługi.

To zdradza:

  • jakie usługi są uruchomione,
  • w jakiej kolejności startują,
  • które często się wywalają (idealne cele).

3. journalctl (systemd)

Journal to złoto:

  • pełne stack trace,
  • ścieżki binarek,
  • zmienne środowiskowe,
  • kontekst procesu.

Często więcej informacji niż administrator zdaje sobie sprawę.


Jak z samych błędów wyciąga się wiedzę o środowisku?

1. Korelacja czasowa

  • logi pokazują kiedy system jest używany,
  • kiedy admin się loguje,
  • kiedy wykonywane są backupy.

➡️ Idealne okna ataku.


2. Analiza powtarzalnych błędów

Jeśli coś się psuje regularnie:

  • wiadomo, że nikt tego nie monitoruje,
  • można to wykorzystać jako kanał boczny.

3. Ścieżki i nazwy plików

Błędy bardzo często zawierają:

  • pełne ścieżki,
  • nazwy katalogów roboczych,
  • lokalizacje danych.

To:

  • ujawnia strukturę systemu,
  • pomaga w atakach typu path traversal, symlink, DLL/LD preload.

Czy logi systemowe są niebezpieczne?

Same w sobie – nie.
Niechronione logi – jak najbardziej.

Są niebezpieczne, gdy:

  • dostęp do nich ma zwykły użytkownik,
  • trafiają do backupów bez szyfrowania,
  • są wysyłane do zewnętrznych systemów bez filtracji,
  • zawierają dane wrażliwe (nazwy kont, tokeny, ścieżki).
Czytaj  Ataki APT (Advanced Persistent Threats) z Użyciem Wirusów: Długoterminowe, ukierunkowane kampanie z wykorzystaniem niestandardowego malware

Jakie informacje zdradzają błędy systemu?

Z samych logów można ustalić:

  • architekturę systemu,
  • używane usługi i aplikacje,
  • politykę logowania,
  • poziom aktualizacji,
  • kulturę administracyjną (co się psuje i jak często).

To pełny profil środowiska, bez skanowania i exploitów.


Jak ograniczyć ryzyko?

Windows

  • ograniczyć dostęp do Event Logów,
  • regularnie czyścić stare wpisy,
  • przekazywać logi do SIEM z maskowaniem danych,
  • nie zostawiać logów na stacjach użytkowników.

Linux

  • prawa dostępu do /var/log,
  • rotacja i skracanie retencji,
  • filtrowanie journalctl,
  • usuwanie nadmiarowych komunikatów debug.

Podsumowanie

Logi są:

  • niezbędne do diagnostyki,
  • nieocenione dla atakującego,
  • często całkowicie ignorowane w modelu zagrożeń.

System operacyjny pamięta Twoje błędy.
Pytanie brzmi: kto jeszcze może je czytać?

 

Polecane wpisy
Zero Trust w systemach IoT i OT: Nowoczesne podejście do zabezpieczania urządzeń przemysłowych i inteligentnych środowisk
Zero Trust w systemach IoT i OT: Nowoczesne podejście do zabezpieczania urządzeń przemysłowych i inteligentnych środowisk

Zero Trust w systemach IoT i OT: Nowoczesne podejście do zabezpieczania urządzeń przemysłowych i inteligentnych środowisk Systemy Internetu Rzeczy (IoT) Czytaj dalej

Android pod ostrzałem: Jak legalne aplikacje i spyware zagrażają bezpieczeństwu użytkowników na niespotykaną dotąd skalę
Android pod ostrzałem: Jak legalne aplikacje i spyware zagrażają bezpieczeństwu użytkowników na niespotykaną dotąd skalę

🧨📱 Android pod ostrzałem: Jak legalne aplikacje i spyware zagrażają bezpieczeństwu użytkowników na niespotykaną dotąd skalę Jeszcze kilkanaście lat temu Czytaj dalej

Marek "Netbe" Lampart Inżynier informatyki Marek Lampart to doświadczony inżynier informatyki z ponad 25-letnim stażem w zawodzie. Specjalizuje się w systemach Windows i Linux, bezpieczeństwie IT, cyberbezpieczeństwie, administracji serwerami oraz diagnostyce i optymalizacji systemów. Na netbe.pl publikuje praktyczne poradniki, analizy i instrukcje krok po kroku, pomagając administratorom, specjalistom IT oraz zaawansowanym użytkownikom rozwiązywać realne problemy techniczne.