SIEM, UBI en de hacker uit het verre Oosten

Secwatch

Gepubliceerd op 08-03-2018

---

Als een spannend jongensboek, maar dan in het echt

Hoe is het om je dagen te vullen met het vangen van boeven en ander gespuis? Niet als de veldwachter van vroeger (toen alles nu eenmaal beter was), maar hoe ziet het dagelijkse leven van een Security Analyst er uit? Hoe spannend of misschien, hoe saai is het om met een uitgebreide serie software tools, kennis en ervaring en een dosis gezond verstand vanachter je pc scherm(en) hackers van over de hele wereld buiten de netwerken van je klanten te krijgen en ze daar te houden? En hoe vertel je de bazen dat hun eigen medewerkers ook heel creatief kunnen zijn?

In dit blog nemen we een aantal waargebeurde scenario’s in beeld, die ik omwille van privacy en geheimhouding fictief behandel.
N.b.: De plaatjes/screenshots zijn echt, maar expres genomen uit voorbeelden of andere events, omwille van de privacy en herleidbaarheid.

Als beveiligingsorganisatie met een vergunning particulier recherchebureau worden ik en mijn collega’s zeer regelmatig geconfronteerd met verdachte omstandigheden in de netwerken bij onze klanten. Hoe ‘bewijs’ je met gegronde reden dat een medewerker kwaadwillend bezig is? En hoe vertaalt zich dat naar een ‘real-world business risk’? Hoe weet een hacker zich een weg te banen door alle aanwezige beveiligingslagen heen? De meeste van onze relaties hebben wel een endpoint security oplossing, zoals antivirus en een ‘Next-Gen’ of ‘UTM’ firewall. Helaas zien we (te) vaak dat deze middelen niet goed of niet optimaal zijn ingericht en aanvallers gewoon hun slag kunnen slaan.

SIEM, ofwel Security Information and Event Management, in combinatie met UBI (User Behaviour Intelligence) wordt steeds belangrijker in onze dagelijkse werkzaamheden als security analist. Wij doen ons dagelijks werk met plezier, altijd vanuit het oogpunt om onze klanten te helpen. De potentieel vele meldingen van traditionele SIEM en UBI oplossingen moeten tot een minimum beperkt worden. Je wilt je klant niet vier keer per dag confronteren met uiteenlopende ‘bedrijfskritische’ meldingen die opzichzelfstaand geen of nauwelijks business impact hebben. Daarom zorgen wij er altijd voor dat wij de klant kennen, zijn ICT-omgeving, het beleid en de cultuur.

We analyseren met intelligente tooling, die vooral kijkt naar gedrag en ‘gestapelde’ events. In de meeste gevallen zijn dit gestapelde oplossingen, zoals Rapid7 insightVM en insightIDR en/of DTEX Systems.

Usecase: Hoe gaat dit in zijn werk?

We zien bij een iedere nieuwe relatie die SECWATCH heeft ingeschakeld al binnen een aantal uren diverse meldingen binnen komen via onze tools en in onze rapportages. Zo geeft in deze case een gebruikersaccount met verhoogde domeinrechten, ineens ook verhoogde rechten aan enkele andere accounts. Er zijn geen andere verdachte omstandigheden, behoudens deze acties.

Om er achter te komen waar de oorzaak hiervan kan liggen, kijken we naar de audittrial vanuit een forensisch oogpunt en besluiten even kort te bellen met de verantwoordelijke IT-beheerder. Na een korte toelichting blijkt het een valide actie; de gebruiker had enkele accounts tijdelijk in status verhoogd voor een installatie. We geven de klant enkele tips aangaande privilege management en wijzen op de gevaren, waarna het incident en onderzoek worden afgesloten. We kiezen er strategisch voor om alleen dit incident af te sluiten en te archiveren. Zodra dezelfde acties zich nogmaals zouden voordoen, dan willen we hier namelijk wederom over genotificeerd worden.

De volgende dag heeft dezelfde omgeving enkele incidenten, achtereenvolgens binnen een bepaalde tijdspanne. Het gros zijn automatiseringsacties, niet direct te relateren aan een bepaald type gebruikersgedrag of acties. We geven in de tooling aan de betreffende accounts toe te voegen aan de ‘watch list’; we gaan deze gebruikers voorlopig nauwgezet in de gaten houden.

Na enige tijd zien we de incidenten zich opstapelen en gaan we dieper graven.

De eerste melding gaat over zogenaamde ‘leaked accounts’, welke onze pentesters vaak gebruiken in externe penetratietesten en interne assessments. We zien een melding in het systeem dat diverse accounts bekend zijn in enkele gelekte gebruikersbestanden van diverse hacks, waaronder de LinkedIN, DropBox en Yahoo breaches van alweer een tijdje geleden.

We brengen per incident de mogelijk gelekte accounts in kaart. Deze accounts zijn dus bekend bij bekende, grote hacks. Zou er nog een tussen zitten met een niet gewijzigd wachtwoord? Dit gebeurt maar al te vaak en … enige tijd later zien we een aantal alerts:

De aanvaller tracht op een enkel account via brute-force binnen te komen, danwel middels password spraying te komen tot een valide login. We zien dit als ‘noisy’ gedrag, zeker voor een mogelijke gerichte aanval. Zou er een service account een verkeerd wachtwoord hebben? Of we hebben we te maken met een niet al te snuggere, mogelijk malafide actie?

Het antwoord laat niet lang op zich wachten:

Op de achtergrond begint de communicatie met onze opdrachtgever en overleggen we over de mogelijke beslissingen. Laten we ‘ze’, onder controle, even doorgaan of gaan we direct blokkeren? We besluiten om in dit specifieke geval mee te gaan kijken. Misschien leren we er nog iets van en we kunnen altijd direct ingrijpen wanneer dat nodig mocht zijn. We zien de aanvaller diverse acties opzetten en rechten toewijzen, waaronder remote access en mogelijkerwijs een reverse shell. Er wordt met een service account via een externe VPN-koppeling ingelogd.

Een nieuw, ons nog niet bekend asset, begint met pogingen om een dropper te installeren op een asset van de omgeving:

We bekijken de bewijsvoering, maar we zien nog geen verdacht dataverkeer.

Daarna zien we wel een succesvolle transactie (voorbeeld):

Omdat de omgeving van onze klant is gekoppeld met een Vulnerability Management omgeving (Rapid7 insightVM), kijken we snel op het dashboard naar het aangevallen asset om direct een overzicht te krijgen van exploitbale vulnerabilities:

Er zijn diverse kwetsbaarheden binnen deze asset, waarvoor overal publieke exploits beschikbaar zijn. Wel moet een aanvaller deze zelf ‘schrijven’ omdat een simpele metasploit module niet voorhanden is.

Niet veel later … een lateral movement, naar in dit geval een local administrator account. Local administrator accounts worden veelal ‘vergeten’ om uit te zetten en wachtwoorden worden vaak nooit herzien. Hierdoor kan een aanvaller zich proberen te verbergen en op  ‘system level’ toegang krijgen middels exploits.

Gevolgd door een privilege escalatie:

Omdat de business impact en het risico nu kritisch beginnen te worden stoppen we in overleg met onze klant het ‘experiment’. We beëindigen direct alles met mitigerende acties om verdere impact te voorkomen – we weten heel veel, maar je weet nooit alles. We gaan aan de slag met alle verzamelde events, gedetailleerde logging en gaan met systeembeheer direct over tot acties. Alle toegang wordt stopgezet, alle accounts worden gereset.

De betrokken personeelsleden worden geïnformeerd en we bespreken met de eindverantwoordelijke personen bij onze klant of zij willen overgaan tot forensische analyse, intern recherche onderzoek en aangifte. Met onze compliancy auditors schakelen we voor analyse aangaande de AVG (ook wel “GDRP”) en meldplicht, hoewel we zeer gecontroleerd te werk zijn gegaan.

Gelijktijdig aan deze ontwikkelingen bij maar één van onze klanten ervaren mijn collega’s soortgelijke, maar altijd weer net andere ontwikkelingen bij andere bedrijven en instanties. De creativiteit van hackers buiten een organisatie mag nooit worden onderschat, evenmin die van eigen medewerkers binnen de organisatie. Beide kunnen de voortgang van een bedrijf danig in verlegenheid brengen, beide vragen om een andere benadering en aanpak. Onze dagen zijn nooit hetzelfde en vervelen nooit.