Przejdź do treści
PL EN
IDENTITY SECURITY / AD · ENTRA

Testy penetracyjne Active Directory i Entra ID

Łączymy relacje zaufania, delegacje i błędne uprawnienia w ścieżki ataku prowadzące do systemów krytycznych.

Ocena nie kończy się na liście słabych haseł i ustawień GPO. Analizujemy, co może osiągnąć przejęte konto, stacja robocza lub aplikacja oraz które relacje dają napastnikowi kolejny krok.

Omów pentest tożsamości Zobacz publiczne materiały
AD · ENTRA ID
Tożsamość hybrydowa
ATTACK PATHS
Analiza relacji
SAFE PoC
Kontrolowana walidacja
HARDENING
Plan redukcji ryzyka
01 / KONTEKST DECYZJI

Kiedy wykonać test tożsamości

  • 01Przed migracją, konsolidacją domen lub wdrożeniem Entra ID.
  • 02Po przejęciu konta, incydencie albo istotnej zmianie administracyjnej.
  • 03Przed audytem zgodności, cyberubezpieczeniem lub testem odporności.
  • 04Gdy zespół widzi pojedyncze błędy, ale nie zna pełnych ścieżek do zasobów krytycznych.
02 / POWIERZCHNIA TESTU

Zakres techniczny

01

Active Directory

Oceniamy uprawnienia, delegacje i konfigurację domeny.

  • ACL, grupy uprzywilejowane i tiering
  • Kerberos, SPN, delegacje i RBCD
  • GPO, AD CS, konta usług i sekrety
02

Entra ID i Microsoft 365

Sprawdzamy tożsamość chmurową oraz granice administracyjne.

  • Role, aplikacje, consent i service principals
  • Conditional Access, MFA i metody odzyskiwania
  • Synchronizacja oraz relacje hybrydowe
03

Odporność operacyjna

Łączymy podatności z wykrywaniem i możliwością reakcji.

  • Ścieżki lateral movement
  • Ekspozycja poświadczeń i stacji administracyjnych
  • Telemetria, alerty i bezpieczne warianty walidacji
03 / REALIZACJA

Jak ograniczamy ryzyko testu

  1. BR / 01

    Cele i crown jewels

    Wskazujemy konta, systemy oraz ścieżki, których przejęcie ma największy wpływ biznesowy.

  2. BR / 02

    Analiza relacji

    Zbieramy zatwierdzone dane i budujemy graf efektywnych uprawnień, zaufania oraz delegacji.

  3. BR / 03

    Bezpieczna walidacja

    Nie eskalujemy do Domain Admin tylko dla efektu. Używamy minimalnego dowodu, symulacji i dedykowanych kont testowych.

  4. BR / 04

    Plan redukcji ścieżek

    Priorytetyzujemy naprawy według skrócenia realnych dróg ataku, nie liczby pojedynczych ustawień.

04 / STANDARD DOWODU

Konto usługi jako pomost do uprzywilejowanej administracji

MODEL ŚCIEŻKI / BEZ DANYCH KLIENTA

Raport pokazuje pełny łańcuch zależności zamiast czterech niepowiązanych ostrzeżeń.

Model ilustruje sposób analizy. Nie opisuje konkretnej infrastruktury klienta.

E-1

Nadmierne ACL umożliwia zmianę właściwości konta usługi

E-2

Konto ma delegację do systemu o wyższym poziomie zaufania

E-3

Brakuje separacji stacji i poświadczeń administratora

E-4

Naprawa usuwa relację, ogranicza delegację i dodaje detekcję

05 / REZULTAT

Rezultat

01
Mapa najważniejszych ścieżek ataku
Element pakietu
02
Lista potwierdzonych błędów uprawnień i konfiguracji
Element pakietu
03
Dowody bez utrwalania dostępu i ingerencji w dane
Element pakietu
04
Plan hardeningu AD/Entra z kolejnością zmian
Element pakietu
05
Warsztat z administratorami oraz retest
Element pakietu
06 / PYTANIA

Najczęstsze pytania

← Wszystkie usługi
01Czy pentest AD wymaga konta domenowego?+

Zależy od celu. Najczęściej używamy konta o niskich uprawnieniach, aby sprawdzić realistyczny scenariusz przejętego użytkownika. Możliwy jest też wariant assumed breach.

02Czy test zakłóci pracę domeny?+

Zakres wyklucza destrukcyjne działania. Operacje podwyższonego ryzyka wymagają odrębnej zgody i są wykonywane na dedykowanych zasobach lub zastępowane bezpiecznym dowodem.

03Czy obejmujecie Entra ID?+

Tak. Dla środowisk hybrydowych oceniamy zarówno AD, Entra ID, aplikacje, synchronizację, jak i relacje między obiema warstwami.

BR / NEXT STEP

Chcesz poznać realne ścieżki do kont uprzywilejowanych?

Ustalimy punkt startowy, zasoby krytyczne i bezpieczny sposób walidacji.

Omów pentest tożsamości
NDA · jasny zakres · bezpośrednia komunikacja