ostatnimi czasy wróciłem do podstaw… i tak się stało, że duża część moich obowiązków związana jest z bezpieczeństwem. bezpieczeństwo zawsze było istotnym elementem mojej pracy zawodowej, ale zawsze jako dopełniający element, a nie przewodni – czy się zarządza, czy projektuje, zawsze trzeba mieć na uwadze czy środowisko/konfiguracja spełnia odpowiednie normy. wbrew niektórym poglądom środowiska on-premises prędko nie odejdą do lamusa, choć coraz bardziej się odchudzają. a ponieważ klienci, z którymi mam ostatnio do czynienia, nie mają wyszukanych rozwiązań, wszystko trzeba robić 'po staremu’.

podrzucam zatem przydatne komendy, które pomogą w manualnej inwestygacji. przyda się zarówno przy ogólnym audycie ale i w momencie jeśli próbujemy znaleźć gdzie jakieś konto 'żyje’, gdzie jest używane.

Event Log

można przeglądać live i offline. ponieważ jednym z pierwszych kroków jest zabezpieczenie logów i powinno się ograniczać pracę w zagrożonym środowisku, poniższy przykład pokazuje jak przeglądać wyeksportowane logi w poszukiwaniu aktywności użytkownika:

• logi z DC nie są synchronizowane, każdy DC ma własne, w związku z tym trzeba wyeksportować z każdego oddzielnie. okazało się, że nie każdy to wie, więc tak na wszelki wypadek przypominam…
• okazuje, nie jest również oczywiste, że logowanie nieudanych prób logowania jest co najmniej tak samo ważne, jak logowanie udanych. nieudane próby mogą świadczyć o próbie bruteforce na kontach albo po prostu próbach nieautoryzowanego dostępu
• następnie można przeszukać korzystając z Get-WinEvent. problem z obróbka polega na tym, że zwrócony hashtable nie ma ustalonego formatu – zależnie od typu zdarzenia będzie inna ilość pól
• poniższy przykład obrazuje wyszukiwanie udanych (4624) i nieudanych (4625) zdarzeń logowania dla kont 'account01′ oraz 'account02′
• nazwy kont są bez domeny, match korzysta z regex więc dowolnie rozbudowywać i wyszukuję po atrybucie 'message’ ponieważ nazwa użytkownika przy tych zdarzeniach jest *zazwyczaj* na 6 pozycji w tablicy.. ale nie zawsze. dzięki przeszukaniu zawartości 'message’ wyłapuje się więcej

$events = Get-WinEvent -Path "C:\incident01\DC01_security.evtx" | Where-Object { ($_.ID -eq 4624 -or $_.ID -eq 4625) -and $_.message -match 'account01|account02'}
$events += Get-WinEvent -Path "C:\incident01\DC02_security.evtx" | Where-Object { ($_.ID -eq 4624 -or $_.ID -eq 4625) -and $_.message -match 'account01|account02'}
$events += Get-WinEvent -Path "C:\incident\DC03_security.evtx" | Where-Object { ($_.ID -eq 4624 -or $_.ID -eq 4625) -and $_.message -match 'account01|account02'}
$events|%{"{0},{1}" -f $($_.Properties.value -join ','),$_.TimeCreated}|Out-File C:\incident01\events_aggregated.csv

a jak ktoś korzysta z eNLib to jeszcze można sobie ułatwić życie i obejrzeć sformatowane w Excel:

&(convert-CSV2XLS c:\incident01\events_aggregated.csv)

smutną informacją będzie, że klasyczne logi Windows pokazują gdzie nastąpiło uwierzytelnienie… ale nie pokazują skąd – co w przypadku logowania sieciowego jest dużym brakiem, bo znalezienie gdzie takie konto w zasadzie jest używane bywa trudne. przydatna będzie również wiedza dotycząca właśnie typu logowania, a najważniejsze to:

• Type 2 – klasyczne logowanie lokalne
• Type 3 – non-interactive, network logon
• Type 5 – non-interactive, service logon (chyba najtrudniejszy w interpretacji)

żywe elementy systemu

jak na szybko sprawdzić czy coś nie działa w kontekście danego użytkownika?

task scheduler:

Get-ScheduledTask | select TaskName,@{L='context';E={$_.Principal.ID}}|sort context

gcim win32_service|select name,startname|sort startname

Get-Process | ForEach-Object {
    $process = $_
    $cimProcess = Get-CimInstance -ClassName Win32_Process -Filter "ProcessId = $($process.Id)"
    $owner = Invoke-CimMethod -InputObject $cimProcess -MethodName GetOwner
    [PSCustomObject]@{
        Name = $process.Name
        Id = $process.Id
        Owner = $owner.User
    }
}