image

Microsoft waarschuwt voor malware die "verborgen" geplande taken gebruikt

woensdag 13 april 2022, 14:58 door Redactie, 5 reacties

Een groep aanvallers die verantwoordelijk was voor de grote Exchange-aanval van vorig jaar en ook andere zerodaylekken heeft gebruikt om toegang tot organisaties te krijgen, maakt gebruik van "verborgen" geplande taken om toegang tot hun slachtoffers te behouden, zo laat Microsoft weten. Volgens het techbedrijf waren het afgelopen jaar onder andere telecombedrijven, internetproviders en datadiensten het doelwit van de groep, die Hafnium wordt genoemd.

Bij slachtoffers ontdekte Microsoft een malware-exemplaar genaamd Tarrask dat via de Windows Task Scheduler taken aanmaakt om toegang tot de computer te behouden. Via de Taakplanner is het mogelijk om allerlei taken uit te voeren. De malware gebruikt dit echter als een "persistence mechanism", zo laat Microsoft weten. Zo worden bij het aanmaken van een nieuwe taak verschillende registersleutels aangemaakt.

Om detectie van deze taak te voorkomen verwijdert de malware de SD-waarde van de registersleutel. SD staat voor Security Descriptor en bepaalt welke gebruikers de betreffende taak kunnen uitvoeren. Door het verwijderen van de SD-waarde verdwijnt de taak uit de Taakplanner en de schtasks command line tool. De taak is in principe verborgen, tenzij het betreffende registerpad handmatig wordt bekeken, aldus Microsoft.

Volgens het techbedrijf laat het gebruik van de Windows Taakplanner op deze manier zien dat de Hafnium-groep een unieke kennis van het Windows-subsysteem heeft en deze expertise gebruikt om de activiteiten op besmette systemen te verbergen en toegang te behouden. "We erkennen dat geplande taken een effectieve tool voor aanvallers zijn om bepaalde taken te automatiseren om persistentie te bereiken", aldus Microsoft, dat met de nu gepubliceerde blogposting meer bewustzijn over deze techniek wil creëren. Daarnaast geeft het techbedrijf tips om de beschreven activiteiten van de Hafnium-groep te detecteren.

Image

Reacties (5)
13-04-2022, 18:38 door Anoniem
Het laat meer zien hoe vreselijk slecht ook dit stuk in elkaar zit.
Je weet niet WAT je moet laten zien, dus laat je dan maar NIKS zien. Het is zo knullig dat het wel opzet lijkt.
14-04-2022, 07:53 door Anoniem
Door Anoniem: Het laat meer zien hoe vreselijk slecht ook dit stuk in elkaar zit.
Je weet niet WAT je moet laten zien, dus laat je dan maar NIKS zien. Het is zo knullig dat het wel opzet lijkt.

tegenwoordig zie je dit wel vaak bij software, snel ontwikkelen, en alles wat verkeerd zou kunnen gaan gewoon negeren. dat doen we wel als het prototype klaar is. wat dus nooit gebeurd. software ontwikkeling, en helemaal bij een OS. moet je naar mijn idee er van uit gaan dat alles fout kan gaan en dus ook fatsoenlijke fout afhandeling maken.

is een veld er niet. dan niet negeren maar een regel tonen met een fout oid.
14-04-2022, 09:25 door Bitje-scheef
In de blogposting zelf wordt prima uitgelegd hoe het werkt.
14-04-2022, 10:05 door Anoniem
Door Bitje-scheef: In de blogposting zelf wordt prima uitgelegd hoe het werkt.
Als ik dat goed lees dan is de domheid in dit geval om een "cache" aan te leggen in de registry.
Taken zijn in principe bestanden in een specifieke directory. Dat waren ze altijd al, hoewel het format veranderd is.
Nu heb je een scheduler die al die taken in de gaten moet houden. Lastig natuurlijk om bij iedere timer tick al die
bestanden te openen, dus heeft men belangrijke informatie op een centraal punt willen verzamelen. Alleen dat had
natuurlijk niet in de registry gemoeten maar ergens in memory, binnen een proces waar aanvallers als het goed is
geen data in kunnen injecteren. Dan hoefde die scheduler alleen die files een keer te openen bij startup en was er
geen plek waar men "buitenom" bij de gecachede info kan.
Echter ik zie wel op meer plekken in de registry dit gedegenereerde gebruik. Het is niet meer hoe het was in XP enzo.
Dat maakt het ook lastig om het systeem snel te configureren via de registry ipv via de GUI.
15-04-2022, 09:10 door Anoniem
Door Anoniem:
Door Bitje-scheef: In de blogposting zelf wordt prima uitgelegd hoe het werkt.
Als ik dat goed lees dan is de domheid in dit geval om een "cache" aan te leggen in de registry.
Taken zijn in principe bestanden in een specifieke directory. Dat waren ze altijd al, hoewel het format veranderd is.

Hoe kom je daarbij? Taken zijn in principe gewoon ingangen in een tabel. Dat hoeft natuurlijk helemaal niet een bestand in een map te zijn. Het maakt niet uit hoe dat opgeslagen is, zolang ze maar kunnen worden teruggevonden.


Nu heb je een scheduler die al die taken in de gaten moet houden. Lastig natuurlijk om bij iedere timer tick al die
bestanden te openen, dus heeft men belangrijke informatie op een centraal punt willen verzamelen. Alleen dat had
natuurlijk niet in de registry gemoeten maar ergens in memory, binnen een proces waar aanvallers als het goed is
geen data in kunnen injecteren. Dan hoefde die scheduler alleen die files een keer te openen bij startup en was er
geen plek waar men "buitenom" bij de gecachede info kan.
Echter ik zie wel op meer plekken in de registry dit gedegenereerde gebruik. Het is niet meer hoe het was in XP enzo.
Dat maakt het ook lastig om het systeem snel te configureren via de registry ipv via de GUI.

Het register staat juist in het geheugen en lezen en schrijven naar registersleutels is vele malen sneller dan in bestanden op een bestandsysteem. Maar het register is hier niet het probleem. Wat ik uit het artikel begrijp, is dat de taken onzichtbaar zijn in de taakplanner, maar juist wel kunnen worden teruggevonden in de registry (als je weet waar je moet kijken).
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.