Daarom is het verstandig niet alleen te vertrouwen op het gebruik van https als beveiliging op updateservers, er zou ook een controle moeten zijn van een signature van de updates, bijvoorbeeld in de executables of als GPG signed bestand.

Uiteraard moeten private keys niet op updateservers te vinden zijn.

Ik ga ervan uit dat veel bedrijven gewoon een up-to-date virusscanner gebruikten - die (net als bij WannaCry) kansloos zijn bij zo'n uitbraak.

Belangrijker: ik heb een sterk vermoeden dat de NotPetya malware zich ook nietsontziend verspreidde op systemen met patch MS17-010 geïnstalleerd (na WannaCry heeft elke zichzelf respecterende beheerder en manager zich hier hard voor gemaakt, en bij veel bedrijven zal deze patch heus zijn uitgerold).

Dat betekent dat NotPetya zich via PsExec en/of WMIC heeft weten te verspreiden nadat Mimikatz-achtige code wachtwoorden en/of wachtwoordhashes van admin accounts uit het geheugen van LSASS en/of vanuit de SAM database wist te peuteren: ER BESTAAT GEEN PATCH DIE DAT WEET TE VOORKOMEN!.

De enige oplossing waar Microsoft voor deze laatste verspreidingsmethode mee komt is, uit https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/:

W10 systemen, zijn naar verluidt, minder kwetsbaar voor Mimikatz-achtige aanvallen dan alle eerdere versies van Windows maar het lijkt mij wishful thinking van Microsoft als zij denkt dat door dergelijke W10 reclame elke grote organisatie onmiddellijk overstapt op W10.

De wereld heeft concrete oplossingen nodig voor oudere, zeker de nog door Microsoft ondersteunde, Windows versies. Dat kunnen zijn:
1) Backports van code in W10 voor het beter beveiligen van cached credentials;
en/of
2) Heldere instructies hoe je highly privileged cached credentials van PC's verwijdert en idem hoe beheerders exact daarna voorkomen (cyberhygiène) dat highly privileged cached credentials aan PC's worden toegevoegd.

De bedrijven die in Nederland problemen hadden (TNT, Maersk, MSD) hebben vestigingen in Oekraine. Waarschijnlijk is de besmetting daar begonnen en heeft zich door het wereldwijde netwerk verspreid.

Daarom is segmentation, firewalling en monitoring op LAN niveau nog steeds gewenst. Ook voor mimikatz en soortgelijke tools zijn er mitigatie mogelijkheden. Het goed inrichten is helaas vaak niet mogelijk door budget, werkdruk en andere beperkingen. Technisch kun je het aanvallers best moeilijk(er) maken.

Inderdaad. De (waarschijnlijk politiek gedreven) makers van NotPetya wilden vermoedelijk vooral Oekraïne treffen, maar hebben kennelijk de effectiviteit van hun malware ernstig onderschat.

Echter: niet-politiek gemotiveerde cybercriminelen zal deze onverwachte effectiviteit ook niet zijn ontgaan!

Ik verwacht op korte termijn dan ook serieuze WannaCry-achtige ransomware die niet via exploits, maar via PsExec en/of WMIC, verspreidt (en daar bestaat geen patch tegen, zoals ik hierboven schreef). En die malware zal zich zeker niet beperken tot bedrijven met vestigingen in Oekraïne...

Overigens is het een wonder dat cybercriminelen nog niet massaal op deze "band wagon" gesprongen zijn, terwijl deze techniek (waarbij van PC naar PC gehopt wordt totdat cached domain admin credentials worden aangetroffen) al heel vaak gebruikt is om een domain controller, en daarmee effectief het hele netwerk, over te nemen. Naar verluidt [1] werden systemen van de Duitse Bondsdag in 2015 ook op deze manier gehacked.

In [2] kun je lezen waarom Windows dit doet, en in [3] om welke gegevens het gaat. Daarbij wordt ook vaak het plain text wachtwoord met "reversable encryption" in het geheugen bewaard - met de sleutel ernaast (anders kan het systeem ook niks met dat versleutelde wachtwoord).

Daarnaast bewaart Windows hashes van wachtwoorden in het geheugen. Nou zul je denken: wat kun je daar nou mee? Nou, in een aantal gevallen kun je daar mee inloggen op netwerkresources; dit heet PtH (Pass-the-Hash). Zie bijv. [4] (uit 2009) voor meer info - allesbehalve nieuwe ontdekkingen dus - waar m.i. Microsoft allang meer tegen had moeten ondernemen. Meer (recentere) info vind je bijv. in [5] en in veel eerdere bijdragen in dezelfde blog.

[1] (Duitstalig) https://www.univention.de/2015/06/bundestags-hack-moegliche-hintergruende-und-verteidigungsmethoden/
[2] https://technet.microsoft.com/en-us/library/2009.07.windowsconfidential.aspx
[3] https://technet.microsoft.com/en-us/library/hh994565(v=ws.11).aspx
[4] (PDF) http://www.sans.org/reading-room/whitepapers/testing/crack-pass-hash_33219
[5] https://passing-the-hash.blogspot.com/2016/

Dus het was in essentie een cyberaanval op Oekraïne (door wie-o-wie) en de wereldwijde infecties (zelfs in Rusland) zijn gewoon collateral damage.

Onzin..... Er hoeft ook geen patch hiervoor te komen. Maar je infra structuur gewoon goed inregelen.

1: Cached credentials je uitzetten of op 1 zetten.
2: Via LAPS kan je ieder local admin wachtwoord uniek maken.
3: Goede delegation of control in de AD inregelen, zodat een ServiceDesk/Server medewerker overal local admin is.
4: Beheer accounts wachtwoorden periodiek laten veranderen.
5: Windows Firewall kan je dicht zetten, zodat er alleen verbinding mogelijk is vanaf bepaalde (management) ipranges.
6: Patches natuurlijk installeren op je machines.
7: RDP heeft tegenwoordig

Met de eerste 2 configuraties, was de impact al aanzienlijk kleiner geweest en is vrij gemakkelijk te implementeren.

Een probleem voor de getroffen bedrijven is dat men eigenlijk het hele domein weer dient op te bouwen van scratch. Er bestaat de mogelijkheid dat aanvallers een golden ticket hebben en dus feitelijk de complete AD geinfiltreerd hebben,
Zie hier b.v. hoe exploitatie op Kerberos niveau gedaan kan worden:
https://leonjza.github.io/blog/2016/01/09/kerberos-kerberoast-and-golden-tickets/

In 2012 is het cybercriminelen gelukt om in te breken bij Adobe en ergens in de build straat malware te injecteren, waardoor deze, aan het einde van de build straat, automatisch digitaal werd ondertekend. Zie https://www.security.nl/posting/38210/Hackers+signeren+malware+met+Adobe+certificaat.

Dan is de praktijk dat een rechtmatige interactieve gebruiker niet meer kan inloggen als er geen DC beschikbaar is, wat sowieso het geval is zodra hij op een domeingekoppelde notebook buiten het pand probeert in te loggen (maar ook onwenselijk kan zijn als er echt even geen DC beschikbaar is).
Zie https://blogs.technet.microsoft.com/instan/2011/12/06/cached-logons-and-cachedlogonscount/ (bron: de reactie op https://www.bleepingcomputer.com/forums/t/529350/preventing-admin-cached-credentials-in-win7-with-group-policy/page-2#entry3799188).

Als dat geen probleem is, zou dit best een redelijke maatregel kunnen zijn om diefstal van cached admin credentials op PC's te verhinderen.

Dank voor deze tip! Meer info voor andere lezers: https://technet.microsoft.com/en-us/mt227395.aspx of Google naar: LAPS passwords

Wat bedoel je hier precies mee (anders dan LAPS)?

Wellicht dat LAPS dit mooi voor je oplost, maar als je dat zonder tooling doet word je gek. En bovendien voorkomt het dit type malware niet: als deze actief wordt op een werkplek PC en admin rechten weet te verkrijgen, en op die PC is een net-gewijzigd wachtwoord (of hash daarvan) van een domain admin beschikbaar waar je ook mee kunt inloggen op een DC, ben je meteen het haasje.

Werkplek-PC's zullen netwerkshares van servers moeten kunnen benaderen. Als malware op zo'n werkplek-PC een beheercredentials aantreft waarmee met beheerprivileges op die server(s) kan inloggen, helpt geen enkele firewall hiertegen.

Natuurlijk kun je met een lokale firewall op werkplek PC's inkomende verbindingen op de TCP poorten 139 en 445 blokkeren, maar dan kun je m.i. beter de server service op werkplek-PC's uitzetten. Dan blijft veel SMB functionaliteit gewoon werken, alleen kan de PC geen mappen en printers meer delen (iets dat je toch niet wilt in een veilig bedrijfsnetwerk). Met alleen deze maatregel voorkom je besmetting van alle werkplek PC's via zowel PsExec/WMIC traversal alsook via service service exploits zoals MS17-010 (ik vermoed dat de met NotPetya besmette bedrijven nu vooral handjes tekort komen door de vele onbruikbare werkplek PC's).

Maar daarvan hadden we net vastgesteld dat patches dit type aanval (credential capture via MimiKatz-achtige tools en remote exec via PsExec/WMIC) niet gaan tegenhouden.

?

Dank voor de LAPS tip (ga ik verder naar kijken), maar de meerwaarde van de andere maatregelen zie ik niet zo.

Wat niet erg helpt is dat bedrijven op dringend verzoek steeds vaker de broncode van hun belanrijke software gaan delen.

Vroeger, in de Windows 9x tijd, werden openstaande shares gebruikt voor (Internet) netwerkwormen. Dat waren vaak batch files. Er is geen reden waarom dat niet zou lukken in een bedrijfsomgeving, zodra je ingelogd bent op het netwerk heb je toegang tot shares van servers. Daarna is het nog een kwestie van executables laten uitvoeren op werkstations. Het concept is dus helemaal niet zo nieuw en je hebt misschien niet eens exploits nodig om het succesvol te laten zijn. Je hebt wel een infectiebron nodig zoals medoc, dat kennelijk geen veilige update methode had. Daarmee zijn we weer on topic.

Dit is een ietwat vage beschrijving van de update wijze:
https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/

Het lijkt er op dat de medoc updater opgedragen wordt random executables uit te voeren. Als daar geen bestandsintegriteitscontrole aan vooraf gaat, met name bij het downloaden van die bestanden, is dat een ernstig lek. Het is waarschijnlijk dat medoc niet de enige is die hiermee de fout ingaat.

Optie 1: Staat uit bij ons, je hebt sowieso niks aan je werkplek zonder Active Directory.

Optie 2: Dit is een prima oplossing, voor het local administrator account. Wij laten deze om de 2 dagen veranderen voor werkstations, en om de 5 dagen op servers. Daarbij hebben wij de back ported patch uit 2014 geïnstalleerd[1], waarbij local admins/users niet kunnen verbinden over het netwerk naar een andere machine.

Optie 3: Dit is zeer riskant, als malware de credentials te pakken krijgt van een ServiceDesk/Server beheerder, kan de malware alsnog overal bij. Als er bij ons beheer gedaan moet worden op een werkstation, dan moet de medewerker het wachtwoord uit LAPS op vragen voor dit werkstation. Geen enkel admin account kan aanmelden op het werkstation.

Optie 4: Veranderen bij ons om de 42 dagen. Hoewel ik liever zou zien, dat mensen een password zin gebruiken met minimaal 5 woorden met spaties,, en het wachtwoord 1x per jaar veranderd. Dit om te voorkomen dat mensen makkelijke wachtwoorden gebruiken, zoals, en wie kent ze niet? Zomer2017!, Juni2017! etc. Of zelfs simpelweg maar ergens gaan opschrijven.
Wij maken gebruik van 3 verschillende accounts. 1 normaal account. 2 server admin account. 3. domain admin account. Normale accounts kunnen niet op servers aanmelden. server admin accounts niet op werkplekken en domain controllers. domain admin accounts alleen op domain controllers, en op PAW [2] (privileged access workstations).

Optie 5: Firewall staat bij ons overal aan op de werkstations, met uitzonderingen op ip en port, voor management software. De PAW bijna staat volledig dicht, daar draait enkel system center agent op, voor patches en windows defender updates. De system center server, zit bij ons op dezelfde beveiliging laag als een domain controller. Firewall staat nog niet aan op de servers, dat project ga ik binnenkort starten.

Optie 6: Doen wij met System Center Configuration Manager, werkt prima. Wsus is gratis en werkt ook.

Optie 7: RDP staan wij alleen toe naar servers, vanaf de PAW ip adressen. In de patch [2] zijn ook RDP beveiligings instellingen back ported.

Optie 8: SMBv1 uitzetten! 30 jaar oud protocol, en onveilig [3]

[1]https://technet.microsoft.com/en-us/library/security/2871997.aspx
[2]https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations
[3]https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

@Anoniem 07:13: dank voor jouw beschrijving van een veilige in de praktijk bewezen werkbare oplossing, helemaal TOP!

Voor een laptop is dit inderdaad wat lastiger. Voor overige machines zou dit geen probleem moeten zijn. Het staat bij ons ook zo geconfigureerd. En ik wil nog eens testen door laptops op 1 te zetten. Dit zou wel eens voldoende kunnen zijn, maar icm met service accounts, zou dit ook wel eens voor problemen kunnen zorgen. Een oplossing zou eventueel zijn, DirectAccess zodat je altijd verbinding hebt met het netwerk.
Maar voor een groot gedeelte zou dit wel geïmplementeerd kunnen worden, zonder enige risico.

Het is zelfs een advies vanuit de security guidelines die er zijn voor Windows.

Werkt goed, maar heeft 1 nadeel........ Het wachtwoord wordt weg geschreven in het Computer AD object als text met een ACL er overheen. Dat het enige nadeel.

Zorgen dat je een AD groep hebt voor een service desktop medewerken, server beheerder, exchange beheerders enz enz.
Daarmee kan je er voor zorgen dat een SD medewerken geen admin rechten heeft op een server. En een Exchange beheerder heeft alle benodigde rechten voor standaard Exchange beheer, maar geen extra rechten op een desktop of Windows server.
Je zou bijvoorbeeld 4 accounts kunnen hebben (gaat erg ver), 1 normaal account, 1 domain admin account, 1 server beheer account, 1 werkstation beheers accounts.

LAPS lost dit helaas niet op, en het is ook geen fijne maatregel. Ik heb 4 type accounts, en moet iedere 30 dagen mijn wachtwoorden veranderen. En die moeten >10 tekens zijn.

Correct. Maar met goede DOC (delegation of control) kan je dit nog steeds afschermen. En veel servers hoeven niet altijd op SMB te benaderd worden, of de cliënt start altijd de verbinding. Inrechten kost veel effort, maar het is wel een mogelijkheid (in een greenfield).

Correct, maar het is een standaard iets. Voor dit virus had het waarschijnlijk weinig uitgemaakt, maar in toekomstige nieuwe virussen zal dit weer een standaard advies zijn wat niet opgevolgd is.

RDP heeft tegenwoordig ook bepaalde beveiliging waardoor tokens niet overgenomen kunnen worden. Maar nog de achtergrond informatie niet meer vinden. Dit had er uit gemoeten, omdat ik er niet voldoende vanaf weet om er iets over te roepen.

[/quote]Het zijn mogelijkheden om de security op een hoger niveau te brengen, maar je moet goed een impact analyse uitvoeren of het ook werkelijk kan. Optie 1 is bijvoorbeeld heel goed mogelijk op een vaste machine, en kan je impact aanzienlijk beperken, of het haalbaar is, dat zal je, net als voor de overige punten, moeten bekijken in jouw omgeving.....

De perfecte al om vattende oplossing bestaat helaas niet.....

Geen probleem, ik help graag waar ik dat kan. Ik was nog een optie vergeten, en dat is applicatie whitelisting. Met bijvoorbeeld Microsoft AppLocker, heb je wel de enterprise versie nodig van het os.[1]

Ik vrees dat AppLocker het opstarten van wmic.exe niet blokkeert, en ook weet ik niet hoe groot het risico is om "vreemde" executables in C:\Windows\ te blokkeren (PsExec.exe is digitaal ondertekend), noch of dit überhaupt mogelijk is.

Bovendien kun je met SYSTEM priviliges AppLocker vast wel bypassen, maar in troep-via-mail situaties kan het je vast wel redden.

Tikkie off-topic maar gerelateerd aan AppLocker: welke malloot bij Microsoft zou bedacht hebben dat executables onder C:\Users\ een goed idee is? (C:\Users\<user >\AppData\Local\Microsoft\OneDrive\OneDrive.exe)

Ik heb regels gemaakt in een GPO welke applicaties mogen worden opgestart, de rest wordt simpel weg gewoon niet uitgevoerd.De applicaties die wel mogen worden opgestart, zijn met het volledige path + certificaat toegevoegd. Het is dus redelijk makkelijk te doen, Microsoft ondertekende executables niet te laten uitvoeren. Je kan AppLocker in een learning modus draaien, waarbij wordt aangegeven wat wel en niet gestart kan worden op het moment dat je de regels enforced.Zo heb ik alleen het nodige op de whitelist gezet, de rest wordt allemaal geblokkeerd.

Als malware system privileges heeft weten te bemachtigen, dan is het inderdaad al aardig game over. Dan moet iemand dus al iets hebben kunnen uitvoeren dat in de whitelist staat, waar een exploit in zit voor het lokale systeem. Als je het principe volgt wat ik al aangaf, met verschillende tier's zullen ze op werkplekken nooit admin credentials vinden, en dus nooit een hogere tier kunnen bereiken, met gestolen credentials.
Er zijn inderdaad AppLocker bypasses, maar dan moet iemand wel weten wat hij aan het doen is. SubTee[1] heeft er al eens over geschreven.

Ik probeer het ze zo moeilijk mogelijk te maken om 'binnen' te komen, zodat ze naar de buren gaan ;)

[1]http://subt0x10.blogspot.nl

@Anoniem 18:30: dat klinkt heel goed (is vast een boel werk geweest, en nog steeds bij wijzigingen).

Ik ben alleen bang dat dit soort cyberhygiènemaatregelen maar bij heel weinig organisaties worden genomen. Bij velen ontbreken tijd, kennis, middelen en managementdrive op dit gebied en is men al blij als er niet te veel ICT storingen zijn.