Dit artikel is het eerste deel van een serie over de analyse van Sysmon-bedreigingen. Alle andere delen van de serie:
Deel 1. Introductie tot Sysmon-loganalyse (we zijn hier)
Deel 2. Gebruik van gegevens uit Sysmon-evenementen voor het identificeren van bedreigingen
Deel 3. Diepgaande analyse van Sysmon-bedreigingen met behulp van grafen
Als je je bezighoudt met informatiebeveiliging, kom je ongetwijfeld vaak in situaties waarin je deal met aanvallen. Als je al een geoefend oog hebt, kun je ongebruikelijke activiteiten zoeken in "ruwe" onbewerkte logs - bijvoorbeeld een PowerShell-script dat is uitgevoerd met de of een VBS-script dat zich voordoet als een Word-bestand, gewoon door de laatste activiteiten in het Windows-register te bladeren. Maar dit is echt een grote hoofdpijn. Gelukkig heeft Microsoft Sysmon ontwikkeld, dat de analyse van aanvallen veel eenvoudiger maakt.
Wil je de basisideeƫn begrijpen achter de bedreigingen die in het Sysmon-log worden weergegeven? Download onze gids en je zult beseffen hoe insiders onopgemerkt andere medewerkers in de gaten kunnen houden. Het belangrijkste probleem bij het werken met het Windows-register is het gebrek aan informatie over ouderprocessen, dat wil zeggen, je kunt de hiƫrarchie van processen niet begrijpen. In de Sysmon-logs zijn daarentegen wel de identificatie van het ouderproces, de naam daarvan en de uitgevoerde opdrachtregel opgenomen. Bedankt, Microsoft.
In het eerste deel van onze serie kijken we naar wat we kunnen doen met de basisinformatie van Sysmon. In het tweede deel maken we volledig gebruik van de informatie over ouderprocessen om complexere overeenstemmingsstructuren te creƫren, die bekend staan als bedreigingsgrafen. In het derde deel bekijken we een eenvoudig algoritme dat de bedreigingsgraf doorzoekt naar ongebruikelijke activiteiten door de "gewicht" van de graf te analyseren. En als beloning wacht je aan het einde een nette (en begrijpelijke) kansmethode voor het detecteren van bedreigingen.
Deel 1: Introductie tot Sysmon-loganalyse
Wat helpt om de complexiteit van het gebeurtenissenlogboek te begrijpen? Uiteindelijk ā SIEM. Het normaliseert gebeurtenissen en vereenvoudigt de daaropvolgende analyse. Maar we hoeven niet meteen zo ver te gaan, in ieder geval niet in het begin. In het begin zal het voldoende zijn om de uitstekende gratis tool Sysmon uit te proberen. En het is verrassend eenvoudig om mee te werken. Goed gedaan, Microsoft!
Wat zijn de mogelijkheden van Sysmon?
Kort samengevat ā nuttige en leesbare informatie over processen (zie afbeeldingen hieronder). Je ontdekt veel nuttige details die niet in het Windows-gebeurtenislogboek staan, maar het belangrijkste zijn de volgende velden:
- Proces-ID (in decimale vorm, niet hex!)
- Ouderproces-ID
- De opdrachtregel van het proces
- De opdrachtregel van het ouderproces
- Hash van het afbeeldingsbestand
- Bestandsafbeeldingen
Sysmon wordt tegelijkertijd geĆÆnstalleerd als stuurprogramma en als dienst - meer informatie Het belangrijkste voordeel ervan is de mogelijkheid om logs van several bronnen te analyseren, informatie te correleren en de resulterende waarden in Ć©Ć©n gebeurtenissenlogboek te plaatsen, dat zich bevindt op het pad Microsoft -> Windows -> Sysmon -> Operationeel. In mijn eigen onderzoeken naar Windows-logs, die me de haren te berge lieten rijzen, moest ik constant schakelen tussen bijvoorbeeld de map met PowerShell-logs en de map 'Beveiliging', terwijl ik door de gebeurtenissenlogs bladerde in een heroĆÆsche poging om waarden tussen hen te correleren. Dit is beslist geen gemakkelijke taak, en zoals ik later besefte, had ik beter meteen aspirin kunnen inslaan.
Sysmon maakt echter een kwalitatieve sprong voorwaarts, door nuttige (of zoals leveranciers het graag noemen ā effectiviteit) informatie te verstrekken om te helpen bij het begrijpen van de fundamentele processen. Bijvoorbeeld, ik startte een verborgen sessie , die het bewegen van een slimme insider binnen het netwerk simuleert. Dit is wat je in het Windows-gebeurtenislogboek zult zien:
In het Windows-logboek is er enige informatie over het proces zichtbaar, maar die is nauwelijks nuttig. Bovendien zijn de proces-ID's in hexadecimale vorm???
Bij een professionele IT-specialist met begrip van de basisprincipes van hacken zou de opdrachtregel argwaan wekken. Het gebruik van cmd.exe om vervolgens een andere opdracht uit te voeren met de uitvoer omgeleid naar een bestand met een vreemde naam, lijkt duidelijk op de handelingen van software voor controle en beheer : op deze manier wordt een pseudo-shell aangemaakt met behulp van WMI-services.
Laten we nu eens kijken naar de equivalente invoer uit Sysmon, waarbij we letten op hoeveel extra informatie deze ons geeft:
De mogelijkheden van Sysmon in Ć©Ć©n screenshot: gedetailleerde informatie over het proces in leesbare vorm
Je ziet niet alleen de opdrachtregel, maar ook de bestandsnaam, het pad naar de uitvoerbare applicatie, wat Windows hierover weet (āWindows Command Processorā), de identiteitscode van het bovenliggende proces, de opdrachtregel van de ouder, die de cmd-shell heeft gestart, evenals de echte bestandsnaam van het bovenliggende proces. Alles op Ć©Ć©n plek, eindelijk!
Uit de Sysmon-log kunnen we concluderen dat deze verdachte opdrachtregel, die we in de 'ruwe' logs zagen, waarschijnlijk niet het resultaat is van normaal personeel. Integendeel, het is waarschijnlijk gegenereerd door een C2-achtige proces ā wmiexec, zoals ik eerder al noemde ā en was rechtstreeks voortgebracht door het WMI-serviceproces (WmiPrvSe). Nu hebben we een indicator dat een externe aanvaller of insider de bedrijfsinfrastructuur aan het testen is.
Hier is Get-Sysmonlogs
Het is natuurlijk geweldig wanneer Sysmon logs op Ć©Ć©n plek heeft. Maar het zou waarschijnlijk nog beter zijn als we toegang konden krijgen tot individuele logvelden op een programmeerbare manier ā bijvoorbeeld via PowerShell-commando's. In dit geval zou je een klein PowerShell-script kunnen schrijven dat het zoeken naar potentiĆ«le bedreigingen automatiseert!
Ik was niet de eerste die met dit idee kwam. En gelukkig is er al uitgelegd in verschillende forumposts en GitHub hoe je PowerShell kunt gebruiken voor het parseren van Sysmon-logs. In mijn geval wilde ik de noodzaak vermijden om afzonderlijke regels parsing-script voor elk Sysmon-veld te schrijven. Daarom heb ik gebruikgemaakt van het principe van de luie man en, naar mijn mening, iets interessants bedacht.
Een eerste belangrijk punt is de mogelijkheid van het commando om Sysmon-logs te lezen, de benodigde gebeurtenissen te filteren en het resultaat op te slaan in een PS-variabele, zoals hier:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Als je zelf de werking van het team wilt controleren, kun je via de weergave van de inhoud in het eerste element van de array $events, $events[0].Message, een reeks tekstregels verkrijgen met een heel eenvoudig formaat: de naam van het Sysmon-veld, een dubbele punt en dan de waarde zelf.
Hoera! Sysmon-logoutput in een JSON-formaat.
Denk je aan hetzelfde als ik? Met een beetje meer moeite kun je de output converteren naar een geformatteerde JSON-string en deze vervolgens rechtstreeks in een PS-object laden met behulp van een krachtige opdracht. .
Ik zal de PowerShell-code voor de conversie laten zien ā het is heel eenvoudig ā in het volgende deel. Maar laten we nu eens kijken wat mijn nieuwe team, genaamd get-sysmonlogs, dat ik als PS-module heb geĆÆnstalleerd, kan doen.
In plaats van dieper in te gaan op de analyse van Sysmon-logs via de onhandige interface van het gebeurtenislogboek, kunnen we moeiteloos incrementele activiteiten rechtstreeks vanuit de PowerShell-sessie zoeken, evenals de PS-opdracht gebruiken. (alias ā "?") om de resultaten van de weergave te verkorten:
Een lijst van cmd-shells die zijn uitgevoerd via WMI. Goedkoop dreigingsanalyse met onze eigen Get-Sysmonlogs-opdracht.
Verbazingwekkend! Ik heb een Sysmon-logpoller gemaakt, alsof het een database is. In ons artikel over werd opgemerkt dat deze functie wordt uitgevoerd door de geweldige tool die daarin wordt beschreven, hoewel het formeel via een echte SQL-achtige interface is. Ja, EQL is elegant, maar we zullen het in het derde deel behandelen.
Sysmon en grafanalyse
Laten we abstraheren en nadenken over wat we net hebben gemaakt. In wezen hebben we nu een database van Windows-gebeurtenissen, toegankelijk via PowerShell. Zoals ik eerder opmerkte, zijn er verbindingen of relaties tussen de records ā via ParentProcessId ā zodat we de volledige hiĆ«rarchie van processen kunnen verkrijgen.
Als je de serie weet je dat hackers het leuk vinden om complexe meerfasige aanvallen te creƫren, waarbij elk proces zijn kleine rol speelt en de basis legt voor de volgende stap. Dergelijke dingen zijn extreem moeilijk te vangen alleen uit de 'ruwe' log.
Maar met mijn Get-Sysmonlogs-opdracht en de extra datastructuur die we verderop in de tekst zullen bespreken (natuurlijk is dit een grafiek), zullen we een praktische manier hebben om bedreigingen te detecteren ā waarvoor slechts de juiste zoekopdracht over de knooppunten vereist is.
Zoals altijd in onze DYI blogprojecten, hoe meer je werkt aan de analyse van bedreigingsdetails op kleine schaal, hoe beter je je bewust wordt van hoe complex het detecteren van bedreigingen op organisatorisch niveau is. En dat besef is uiterst belangrijk.
We zullen de eerste interessante complicaties tegenkomen in het tweede deel van het artikel, waar we Sysmon-gebeurtenissen met elkaar zullen verbinden in veel complexere structuren.
Bron: habr.com
