De gebruikerswerkplek is het meest kwetsbare punt van de infrastructuur als het gaat om informatiebeveiliging. Gebruikers ontvangen mogelijk een brief in hun zakelijke e-mail die afkomstig lijkt te zijn van een veilige bron, maar met een link naar een geïnfecteerde site. Misschien downloadt iemand vanaf een onbekende locatie een hulpprogramma dat nuttig is voor zijn werk. Ja, er zijn tientallen gevallen te bedenken waarin malware via gebruikers interne bedrijfsbronnen kan infiltreren. Daarom vereisen werkstations meer aandacht, en in dit artikel zullen we u vertellen waar en welke gebeurtenissen u moet ondernemen om aanvallen te monitoren.
Om een aanval in een zo vroeg mogelijk stadium te detecteren, beschikt WIndows over drie nuttige gebeurtenisbronnen: het beveiligingsgebeurtenislogboek, het systeembewakingslogboek en de Power Shell-logboeken.
Logboek voor beveiligingsgebeurtenissen
Dit is de belangrijkste opslaglocatie voor systeembeveiligingslogboeken. Dit omvat gebeurtenissen van inloggen/uitloggen van gebruikers, toegang tot objecten, beleidswijzigingen en andere beveiligingsgerelateerde activiteiten. Natuurlijk, als het juiste beleid is geconfigureerd.
Opsomming van gebruikers en groepen (gebeurtenissen 4798 en 4799). Helemaal aan het begin van een aanval doorzoekt malware vaak lokale gebruikersaccounts en lokale groepen op een werkstation om inloggegevens te vinden voor zijn duistere handelingen. Deze gebeurtenissen helpen bij het detecteren van kwaadaardige code voordat deze verder gaat en zich met behulp van de verzamelde gegevens naar andere systemen verspreidt.
Aanmaak van een lokaal account en wijzigingen in lokale groepen (gebeurtenissen 4720, 4722-4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 en 5377). De aanval kan bijvoorbeeld ook beginnen door een nieuwe gebruiker toe te voegen aan de lokale beheerdersgroep.
Inlogpogingen met een lokaal account (gebeurtenis 4624). Respectabele gebruikers loggen in met een domeinaccount, en het identificeren van een login onder een lokaal account kan het begin van een aanval betekenen. Gebeurtenis 4624 omvat ook aanmeldingen onder een domeinaccount, dus bij het verwerken van gebeurtenissen moet u gebeurtenissen filteren waarbij het domein verschilt van de naam van het werkstation.
Een poging om in te loggen met het opgegeven account (gebeurtenis 4648). Dit gebeurt wanneer het proces in de modus "uitvoeren als" wordt uitgevoerd. Dit zou niet mogen gebeuren tijdens de normale werking van systemen, dus dergelijke gebeurtenissen moeten onder controle worden gehouden.
Vergrendelen/ontgrendelen van het werkstation (gebeurtenissen 4800-4803). De categorie verdachte gebeurtenissen omvat alle acties die hebben plaatsgevonden op een vergrendeld werkstation.
Wijzigingen in de firewallconfiguratie (gebeurtenissen 4944-4958). Het is duidelijk dat bij het installeren van nieuwe software de configuratie-instellingen van de firewall kunnen veranderen, wat valse positieven zal veroorzaken. In de meeste gevallen is het niet nodig om dergelijke veranderingen te controleren, maar het kan zeker geen kwaad om ervan op de hoogte te zijn.
Plug'n'play-apparaten aansluiten (gebeurtenis 6416 en alleen voor WIndows 10). Het is belangrijk om dit in de gaten te houden als gebruikers normaal gesproken geen nieuwe apparaten op de werkplek aansluiten, maar dit opeens wel doen.
Windows bevat 9 auditcategorieën en 50 subcategorieën voor verfijning. De minimale set subcategorieën die moet worden ingeschakeld in de instellingen:
Aan-/afmelden
- Inloggen;
- Uitloggen;
- Accountblokkering;
- Andere aanmeldings-/afmeldingsgebeurtenissen.
Account Management
- Beheer van gebruikersaccounts;
- Beheer van beveiligingsgroepen.
Beleidswijziging
- Wijziging van het auditbeleid;
- Wijziging authenticatiebeleid;
- Wijziging autorisatiebeleid.
Systeemmonitor (Sysmon)
Sysmon is een in Windows ingebouwd hulpprogramma dat gebeurtenissen in het systeemlogboek kan vastleggen. Meestal moet je het apart installeren.
Deze zelfde gebeurtenissen zijn in principe terug te vinden in het beveiligingslogboek (door het gewenste auditbeleid in te schakelen), maar Sysmon geeft meer details. Welke gebeurtenissen kunnen van Sysmon worden overgenomen?
Procescreatie (gebeurtenis-ID 1). Het systeembeveiligingsgebeurtenislogboek kan u ook vertellen wanneer een *.exe is gestart en zelfs de naam en het opstartpad ervan tonen. Maar in tegenstelling tot Sysmon kan het de applicatie-hash niet weergeven. Schadelijke software kan zelfs onschadelijk notepad.exe worden genoemd, maar het is de hash die dit aan het licht brengt.
Netwerkverbindingen (gebeurtenis-ID 3). Het is duidelijk dat er veel netwerkverbindingen zijn, en het is onmogelijk om ze allemaal bij te houden. Maar het is belangrijk om te bedenken dat Sysmon, in tegenstelling tot Security Log, een netwerkverbinding kan binden aan de ProcessID- en ProcessGUID-velden, en de poort- en IP-adressen van de bron en de bestemming toont.
Wijzigingen in het systeemregister (gebeurtenis-ID 12-14). De eenvoudigste manier om uzelf aan autorun toe te voegen, is door u in het register te registreren. Security Log kan dit doen, maar Sysmon laat zien wie de wijzigingen heeft aangebracht, wanneer en van waar, proces-ID en de vorige sleutelwaarde.
Bestanden maken (gebeurtenis-ID 11). Sysmon toont, in tegenstelling tot Security Log, niet alleen de locatie van het bestand, maar ook de naam ervan. Het is duidelijk dat je niet alles kunt bijhouden, maar je kunt wel bepaalde mappen controleren.
En wat staat er nu niet in het Security Log-beleid, maar wel in Sysmon:
Wijziging van de tijd voor het maken van bestanden (gebeurtenis-ID 2). Sommige malware kan de aanmaakdatum van een bestand vervalsen om het te verbergen voor rapporten over recentelijk gemaakte bestanden.
Stuurprogramma's en dynamische bibliotheken laden (gebeurtenis-ID's 6-7). Bewaken van het laden van DLL's en apparaatstuurprogramma's in het geheugen, controleren van de digitale handtekening en de geldigheid ervan.
Maak een thread in een lopend proces (gebeurtenis-ID 8). Eén type aanval dat ook gemonitord moet worden.
RawAccessRead-gebeurtenissen (gebeurtenis-ID 9). Schijfleesbewerkingen met behulp van “.”. In de overgrote meerderheid van de gevallen moet dergelijke activiteit als abnormaal worden beschouwd.
Maak een benoemde bestandsstroom (gebeurtenis-ID 15). Er wordt een gebeurtenis vastgelegd wanneer een benoemde bestandsstroom wordt gemaakt die gebeurtenissen uitzendt met een hash van de inhoud van het bestand.
Een benoemde pijp en verbinding maken (gebeurtenis-ID 17-18). Het volgen van kwaadaardige code die communiceert met andere componenten via de benoemde pipe.
WMI-activiteit (gebeurtenis-ID 19). Registratie van gebeurtenissen die worden gegenereerd bij toegang tot het systeem via het WMI-protocol.
Om Sysmon zelf te beschermen, moet u gebeurtenissen monitoren met ID 4 (Sysmon stoppen en starten) en ID 16 (Sysmon-configuratiewijzigingen).
Power Shell-logboeken
Power Shell is een krachtig hulpmiddel voor het beheren van de Windows-infrastructuur, dus de kans is groot dat een aanvaller hiervoor zal kiezen. Er zijn twee bronnen die u kunt gebruiken om Power Shell-gebeurtenisgegevens te verkrijgen: Windows PowerShell-logboek en Microsoft-WindowsPowerShell/Operationeel logboek.
Windows PowerShell-logboek
Gegevensprovider geladen (gebeurtenis-ID 600). PowerShell-providers zijn programma's die een gegevensbron bieden die PowerShell kan bekijken en beheren. Ingebouwde providers kunnen bijvoorbeeld Windows-omgevingsvariabelen of het systeemregister zijn. De opkomst van nieuwe leveranciers moet worden gemonitord om kwaadwillige activiteiten tijdig te kunnen detecteren. Als u bijvoorbeeld WSMan tussen de providers ziet verschijnen, is er een externe PowerShell-sessie gestart.
Microsoft-WindowsPowerShell/Operationeel logboek (of MicrosoftWindows-PowerShellCore/Operationeel in PowerShell 6)
Moduleregistratie (gebeurtenis-ID 4103). Gebeurtenissen slaan informatie op over elke uitgevoerde opdracht en de parameters waarmee deze is aangeroepen.
Logboekregistratie voor scriptblokkering (gebeurtenis-ID 4104). Logboekregistratie voor scriptblokkering toont elk blok PowerShell-code dat wordt uitgevoerd. Zelfs als een aanvaller de opdracht probeert te verbergen, toont dit gebeurtenistype de PowerShell-opdracht die daadwerkelijk is uitgevoerd. Dit gebeurtenistype kan ook enkele API-aanroepen op laag niveau registreren. Deze gebeurtenissen worden meestal geregistreerd als uitgebreid, maar als een verdachte opdracht of script wordt gebruikt in een codeblok, wordt dit geregistreerd als een waarschuwingsernst.
Houd er rekening mee dat zodra de tool is geconfigureerd om deze gebeurtenissen te verzamelen en te analyseren, er extra tijd voor foutopsporing nodig zal zijn om het aantal valse positieven te verminderen.
Vertel ons in de reacties welke logs u verzamelt voor informatiebeveiligingsaudits en welke tools u hiervoor gebruikt. Een van onze aandachtsgebieden zijn oplossingen voor het auditen van informatiebeveiligingsgebeurtenissen. Om het probleem van het verzamelen en analyseren van logbestanden op te lossen, kunnen we voorstellen om dit nader te bekijken , dat opgeslagen gegevens kan comprimeren met een verhouding van 20:1, en één geïnstalleerd exemplaar ervan kan tot 60000 gebeurtenissen per seconde uit 10000 bronnen verwerken.
Bron: www.habr.com