Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Beveiligingsbedrijf vindt geheugenmalware op 140 bedrijfsnetwerken

Door , 48 reacties

Beveiligingsbedrijf Kaspersky heeft zogenaamde fileless malware ontdekt op netwerken van 140 ondernemingen, waaronder banken. Deze vorm van kwaadaardige software bevindt zich alleen in het geheugen van systemen en is daardoor moeilijk te detecteren.

De malware wordt gebruikt om logingegevens van beheerders te verzamelen, schrijft Kaspersky in een analyse. Daarvoor maakt de malware gebruik van veelgebruikte tools als Meterpreter, Mimikatz en PowerShell. De PowerShell-scripts werden volgens de onderzoekers gegenereerd aan de hand van het Metasploit Framework, dat onder andere gebruikt wordt om exploits te gebruiken en te configureren. Er waren daardoor geen malwarebestanden nodig en de sporen van een aanval waren na een herstart van het systeem uitgewist.

De onderzoekers kwamen de aanvallen op het spoor toen een bank Meterpreter-code in het geheugen van een domeincontroller aantrof. Zij kwamen erachter dat door een PowerShell-script in het Windows-register de Meterpreter-payload in het geheugen van het systeem was geladen. Ook was er een kwaadaardig proces aangemaakt met het standaard-Windows-onderdeel SC. Vervolgens werd een ander standaardonderdeel, NETSH, gebruikt om verbinding te maken met een command and control-server. Om de daarvoor benodigde beheerdersrechten te verkrijgen, maakten de aanvallers gebruik van Mimikatz.

Volgens Kaspersky is het bijna onmogelijk om te zeggen wie er achter de aanvallen zit, omdat er gebruik is gemaakt van eenvoudig verkrijgbare tools en domeinen zonder whois-informatie. De getroffen ondernemingen zijn vooral gevestigd in de VS, Frankrijk, Ecuador, Kenia en in het VK. Het bedrijf zegt dat geavanceerde aanvallen met geheugenmalware steeds vaker voorkomen en dat de ontdekking aantoont dat een succesvolle aanval ook zonder malwaresamples mogelijk is.

Weergave van het infectieproces

Reacties (48)

Wijzig sortering
Standaard staat Powershell toch uitgeschakeld? Dit moet toch eerst geactiveerd worden? Beetje vreemd dat dat dan voor domain controllers gedaan wordt. Schijnbaar nogal veel gemak met group policies dan.

Of heb ik het nu mis? Dan kan maar zo ik weet er niet veel vanaf.
Powershell is standaard actief, alleen voor bepaalde scripts moet je eerst de run policy aanpassen:

As I mentioned previously, PowerShell is secure by default. The first implication of this philosophy is that PowerShell won't execute scripts until you explicitly give it permission to do so. PowerShell has four execution policies that govern how it should execute scripts:

Restricted. PowerShell won't run any scripts. This is PowerShell's default execution policy.
AllSigned. PowerShell will only run scripts that are signed with a digital signature. If you run a script signed by a publisher PowerShell hasn't seen before, PowerShell will ask whether you trust the script's publisher.
RemoteSigned. PowerShell won't run scripts downloaded from the Internet unless they have a digital signature, but scripts not downloaded from the Internet will run without prompting. If a script has a digital signature, PowerShell will prompt you before it runs a script from a publisher it hasn't seen before.
Unrestricted. PowerShell ignores digital signatures but will still prompt you before running a script downloaded from the Internet.
Powershell is standaard actief, alleen voor bepaalde scripts moet je eerst de run policy aanpassen:
De execution-policy is alleen van toepassing op scripts (.ps1). Powershell is echter vooral heel sterk als shell, en daarmee in het gebruik van (complexe) oneliners. Signing vereisen voor scripts heeft daarvoor dus geen toegevoegde waarde en biedt alleen een schijnveiligheid.
Hmm.... daarmee leer ik dan weer iets.
Op zich valt er nog wat voor te zeggen dat je dan in ieder geval niet iets uitvoert waarvan je redelijkerwijs niet weet wat het doet (in een script ploeter ik niet alle code door, en een complexe oneliner zou ik zelf opstellen, dus met grondig onderzoek naar alle switches etc.)

Zijn die complexe oneliners dan ook nog te beveiligen voor de copy-pasters onder ons? Of is dat gewoon een gat?
Er is geen gat. Powershell code draait op de context van de uitvoerende gebruiker, en kan dus net zo veel als die gebruiker. Powershell is daarmee niet gevaarlijker dan een willekeurig batchfile, vbscript of willekeurige executable.

Het vertrouwen op signing is een schijnveiligheid; als er een vertrouwd certificaat wordt gebruikt voor het signen is het dus een valide gesigneerd script, en mag dus uitgevoerd worden indien de uitgevende CA valide is. Aangezien het geen enkel probleem is om hier een publiek certificaat voor te gebruiken en het signen een koud kunstje is, is signing alleen geschikt om te controleren of een script niet (al dan niet per ongeluk) aangepast is.
voor bepaalde scripts moet je eerst de run policy aanpassen
Als developer/consultant moest ik o.a. bij migraties wel vaker zelfgemaakte scripts draaien bij klanten op de server. Je zal je verbazen over bij hoeveel klanten je wl een verklaring moet tekenen voor goed gedrag etc., maar waar iets simpels als de execution policy gewoon Unrestricted staat. Heb hier meer dan eens een punt gemaakt; de meeste systeembeheerders zien de meerwaarde van AllSigned niet eens.

Heb het gevoel dat dit komt doordat de meesten de vrijwel onbeperkte mogelijkheden van PowerShell nog niet echt kennen.

[Reactie gewijzigd door kakanox op 8 februari 2017 14:42]

Vanmiddag kwam ik er dan wel achter dat je vanuit een script de execution policy gewoon kunt aanpassen die vanuit een url wordt uitgevoerd als je het vanuit Admin uitvoert. Lijkt me niet de bedoeling maar kan dus wel.

iwr https://url.naar.script/file.ps1 -UseBasicParsing | iex

Maak een batchscript die een powershell command met bovenstaande uitvoert en je kunt best een hoop.


Hier kwam ik achter door zelf een script te schrijven, op een webserver te plaatsen en in een virtuele machine de code uit te voeren tijdens wat experimenteren.

[Reactie gewijzigd door mrdemc op 8 februari 2017 18:18]

Vanuit admin uitvoert......

I rest my case...
Is een extra opstakel waar je bewust mee moet omgaan, maar dat is niet ongewoon bij een installatie. Als je dan iets als een execution policy inbakt dan hoort dat naar mijn idee los te staan van admin of niet. Vanuit de niet-admin shell kun je bijvoorbeeld ook niet handmatig de policy aanpassen, dan krijg je een register error (die kreeg ik in ieder geval bij een schone Windows 10 installatie), dus de optie om het binnen een sessie in te stellen is sowieso alleen voorbehouden aan de admin shell. Als een script dan dit zou kunnen zou er op z'n minst een bevestiging gevraagd moeten worden vind ik.
Het is voor admins te blokkeren door gebruik te maken van een gpo en applocker.
Ik zie steeds vaker execution policy bypasses icm powershell scripts die via het exploits worden gestart. Zie http://stackoverflow.com/a/9271786
Standaard staat Powershell toch uitgeschakeld? Dit moet toch eerst geactiveerd worden?
Draai vanuit een Command Prompt:
type HelloWorld.ps1 | PowerShell -noprofile -
Zoals aangegeven door anderen hebben de standaard PowerShell policies alleen betrekking op het direct uitvoeren van ps1 bestanden door PowerShell. Andere bronnen, zoals stdin, worden niet beperkt.

[Reactie gewijzigd door The Zep Man op 8 februari 2017 16:35]

Heel veel bedrijven schakelen WinRM in voor tooling met bijv. Ansible.
Dat maakt het kinderspel dat als je eenmaal in een domein binnen bent met voldoende permissies, om op afstand PowerShell scripts te draaien.

[Reactie gewijzigd door JapyDooge op 8 februari 2017 14:20]

Kan goed gewoon een inside job zijn.
Wat ik me nu aanvraag is, hoe kan ik dit voorkomen en hoe kan ik checken of dit niet al gebeurd is? Is er een methode om deze malware te (gaan) detecteren middels een scan of tool?
Iemand enig idee of deze malware in de toekomst standaard gedetecteerd gaat worden door virus scanners?
Tegengaan kan bij stap 1 en misschien bij stap 3 (zie diagram infectieproces).
Checken of dit gebeurt is kan zo:
To find the host used by an attacker using the technique described for remote connections and password collection, the following paths in the Windows registry should be analyzed:

HKLM\SYSTEM\ControlSet001\services\ – path will be modified after using the SC utility
HKLM\SYSTEM\ControlSet001\services\PortProxy\v4tov4\tcp – path will be modified after using the NETSH utility

In unallocated space in the Windows registry, the following artefacts might be found:

powershell.exe -nop -w hidden -e
10.10.1.12/8080
10.10.1.11/4444

Please note that these IPs are taken from the IR case in which we participated, so there could be any other IP used by an eventual attacker. These artefacts indicate the use of PowerShell scripts as a malicious service and the use of the NETSH utility for building tunnels.
Thanks, ik zag je eerdere reactie al.
Als ik het goed begrijp kan dit dus alleen worden gebruikt op Windows computers met Powershell scripts ingeschakeld. Maar veel servers gebruiken Linux, dus daar kunnen de aanvallers niets mee. En de servers die Windows gebruiken en op gevoelige locaties staan (zoals bij banken als in het artikel staat), waarom zou daar de script-execute-optie aan staan? Zelfs als hier nog geen problemen mee waren, lijkt me dat toch niet handig.
To find the host used by an attacker using the technique described for remote connections and password collection, the following paths in the Windows registry should be analyzed:

HKLM\SYSTEM\ControlSet001\services\ – path will be modified after using the SC utility
HKLM\SYSTEM\ControlSet001\services\PortProxy\v4tov4\tcp – path will be modified after using the NETSH utility

In unallocated space in the Windows registry, the following artefacts might be found:

powershell.exe -nop -w hidden -e
10.10.1.12/8080
10.10.1.11/4444

Please note that these IPs are taken from the IR case in which we participated, so there could be any other IP used by an eventual attacker. These artefacts indicate the use of PowerShell scripts as a malicious service and the use of the NETSH utility for building tunnels.
Ik denk dat er misschien een soort log-tool moet komen die veranderingen in die registerplekken bijhoudt.

[Reactie gewijzigd door nolife op 8 februari 2017 14:29]

Maar veel servers gebruiken Linux, dus daar kunnen de aanvallers niets mee.
Dat ligt er maar net aan in welke omgeving je zit.
Het bedrijf waar ik nu werk is vrijwel alle KA Windows-based, en een deel van de productie ook (C# / ASP.NET).

Daar is niets mis mee, er zijn nou eenmaal verschillende smaken - maar je kan niet zomaar aannemen dat het overal veel Linux is. ;)
Daarom zegt hij ook "veel" en niet "alle". Linux is simpelweg gewoon veel lichter en beter geoptimaliseerd voor servergebruik. Alhoewel dat ook weer aan de doeleinden ligt. Linux met alleen een CLI is natuurlijk veel lichter dan Windows met GUI. Daarom is het zo stabiel. De servers van onder andere Facebook en Google draaien ook op Linux ;).

[Reactie gewijzigd door AnonymousWP op 8 februari 2017 15:34]

Windows Server draait al vele jaren ook zonder GUI. Zoals JapyDooge al aangeeft is het een kwestie van smaak en/of management.

Powershell is erg krachtig en je kan daarmee alles (en meer) wat je de GUI kan. Policies zijn erg belangrijk maar beheerder maken het zichzelf graag makkelijk door admin accounts overal voor te gebruiken en systemen open te zetten want tsja je wil toch niet elke keer apart toestemming moeten geven voor elke onderdeel binnen je server om iets te veranderen. Ligt vooral aan het verleden van MS waar alles mogelijk was en je nu overal toestemming voor moet geven. Linux heeft een andere geschiedenis en betrap mezelf er altijd op hoe vaak ik SElinux vergeet en compleet uit zet.

Wel erg zorgwekkend dat men nu geen echte malware samples meer hoeft te gebruiken, genuine code uitvoeren blijkt al genoeg te zijn. Beveiliging op register aanpassingen zijn nu nog belangrijker.
Ja, er is inderdaad ook een Core versie van Windows Server, dat weet ik. Maar Linux is een stuk stabieler wat dat betreft (en veiliger). Waarom denk je dat al die miljardenbedrijven Linux gebruiken?
Bron?
Das is dus niet waar, het ligt er compleet aan wat voor toepassing jou ICT heeft. Wij gebruiken veel domaincontrollers en exchange server, voornamelijk linux voor webhosting omdat webservers vaak sneller zijn maar ASP.NET draait daar weer niet op. Het is maar net welke toepassingen je nodig hebt.
Het ligt er inderdaad aan voor welke toepassingen je het gebruikt.

Hier mijn bron: http://www.pcworld.com/ar..._windows_for_servers.html :).
Ja, als dat continu checkt op veranderingen en vervolgens de internetverbinding reset (ik noem maar wat), kan dat misschien wel uitkomst bieden voor de bestandsloze aanval
OK in mixed omgevingen word dit een probleem, powershell is al beschikbaar voor Linux en welke beheerder wil nou niet One shell to rule them al
wat ik in het verhaal mis maar in het plaatje wel duidelijk wordt is dat er al ergens een vulnerabiltiy beschikbaar moet zijn voordat dit kan starten.
verder lijkt met het ook niet moeilijk om dergelijke virussen te verwijderen.
na het patchen van de software zou een herstart van de machine voldoende moeten zijn, er zijn namelijk geen files die gebruikt kunnen worden om weer te starten.

wel kan deze malware natuurlijk patchen verhelpen. overigins vind ik nog steeds dat een goede virusscanner dit soort zaken ook moet onderscheppen.
Een virusscanner zou alleen maar malware kunnen detecteren als het in de database is opgenomen. Als het een nieuw soort malware is wat niet wordt herkend, is het natuurlijk lastig om op te sporen, omdat het nog niet in de database staat. Ik De bedrijven die dus virusscanners maken, lopen dus altijd achter de feiten aan. Ik ga er dan ook vanuit dat Kaspersky dit in z'n database zal opnemen.
De tijd dat malwarescanners alleen vertrouwden op een database met signatures ligt toch wel een flinke tijd achter ons.

De meeste gebruiken ook een soort heuristiek om verdachte handelingen te blokkeren. Er zijn nou eenmaal handelingen denkbaar die zelden of nooit legitiem gebruikt zullen worden maar wel door malware. Als een malwarescanner daar op let kan hij zonder dat hij vantevoren wist van dat specifieke stuk malware toch een hoop schade of verspreiding voorkomen.

[Reactie gewijzigd door Maurits van Baerle op 8 februari 2017 15:57]

Dat is ook waar, maar natuurlijk is er nog steeds een database met daarin signatures. Daarom kunnen er ook false positives optreden, omdat keygenerators (als voorbeeld) zich ook verdacht kunnen gedragen terwijl die niet schadelijk zijn (de legits dan).
Ik heb er voorlopig aleen vluchtig naar kunnen kijken maar volgens mij wordt de payload rechtstreeks vanaf het internet het geheugen ingeladen en wordt het daar actief.

Echter, het lijkt het Windows Registry te gebruiken voor "opslag" (en dat is niet vluchtig) dus het zou me niets verbazen als hij op een of andere manier de payload gewoon opnieuw laad vanaf het internet na een herstart.
Onder XP had Microsoft een Windows Defender (laatste versie 1.1.1593.0) die wijzigingen in het register op bepaalde kritische plekken in de gaten hield en goedkeuring vroeg aan de gebruiker alvorens te committen.
Werkte perfect, maar is weer verdwenen uit Windows Defender bij Vista en Win7.
Was zeker te lastig voor huis en tuin gebruikers.
"Programma XYZ.exe probeert registry key HKLM\PROG\KRITISCHE_SETTING aan te passen, wilt u dit toestaan?"

Bij 'Nee' werkt het programmaatje niet. Bij 'Ja' wel. Wat denk je dat Sjonnie-de-Eindgebruiker kiest? En de tweede keer?
Voor doorsnee eindegebruikers idd geen oplossing zo. Maar voor servers zou Defender deze optie best wel mogen her-introduceren.
Probleem is dat de gemiddelde 'Sjonnie' niet even vlug kijkt wat het programma in vredesnaam is - zelfs als ze helemaal zelf de PC ingericht hebben. Als ik een programma niet herken kijk ik altijd even vlug wat de online file libraries (of van Microsoft, of van AV-fabrikanten, of van anderen) erover zeggen. Als het onderdeel is van een programma welke ik zeker weet dat ik het heb, sta ik het toe... anders gewoon nee.
Als je de sporen kan uitwissen door het systeem te herstarten lijkt het mij slim om dit af en toe te doen. Of zijn er nog simpelere mogelijkheden?
Nee, dat vat je verkeerd op ben ik bang. Je kan de sporen van de malware wissen. Niet de malware zelf. De malware zit verstopt in het register, en de sporen zitten in het RAM, totdat je natuurlijk de computer uitzet, want RAM is volatile memory.
Ja, dat snap ik. Het is natuurlijk niet opgeslagen op het RAM geheugen. :)
Dus het meta sploit framework maakt een PowerShell-script in het Windows-register aan?
is dat het in korte lijnen ?
De aanvaller dringt binnen op een of andere manier, tools worden gebruikt om kwaadaardige code in het register te verstoppen, die code kan gebruikt worden voor bijvoorbeeld een remote verbinding, aanvallers doen wat ze willen, rebooten en *poef* bijna alle proof is foetsie.
Maar een beetje netwerk design met een goede firewall moet hier al veel van tegen kunnen gaan.

Bijvoorbeeld, waarom moeten "alle" server in het netwerk het internet op kunnen? Windows updates kunnen ook vanuit WSUS of iets dergelijks worden geregeld. Systemen waarbij het internet wel noodzakelijk is kunnen nog achter een firewall met restricted policies zodat er goed gefilterd kan worden op valide inkomend en uitgaand verkeer.

Ik snap dat dat voor veel beheerders "vervelend" is, maar het is wel een stuk veiliger.
Hitman Alert en/of Sophos InterceptX .. uitstekend in staat om aanvallen die alleen in het geheugen terrechtkomen te mitigreren.
Omdat er al geruime tijd offensive Powershell attack tools bestaan is het goed om te overwegen om via o.a. policies, restricties binnen je Active Directory forest te implementeren. Dit kan bijvoorbeeld via:

• Limiting Constrained Language Mode
• Powershell v5 i.c.m. Applocker, via allow mode (whitelisting) en constrained mode
• Alle Powershell activiteit loggen/auditten via GPO Module Logging en Script Block Logging
• Filter en zoek in de Powershell eventlog op bekende "code snippets" zoals:

“System.Reflection.AssemblyName”
“System.Reflection.Emit.AssemblyBuilderAccess “
“System.Runtime.InteropServices.MarshalAsAttribute”
“TOKEN_PRIVILEGES”
“SE_PRIVILEGE_ENABLED“

Het bovenstaande wordt bijvoorbeeld gegenereerd door Mimikatz.

[Reactie gewijzigd door SaturN op 8 februari 2017 20:30]

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*