Instelling in Active Directory voorkomt NotPetya-besmetting
Onderzoekers van IT-beveiliger NCC Group, het moederbedrijf van Fox-IT, hebben een relatief eenvoudige manier ontdekt om te voorkomen dat malware zichzelf verspreidt in een Windows Active Directory-netwerk.
Op verzoek van een niet nader genoemde klant ontwikkelde het bedrijf een onschuldige versie van de NotPetya ransomware, de Eternalglueworm, en verspreidde die op het netwerk van de klant. De klant wilde op deze manier de niet schadelijke malware observeren en leren hoe ze zich beter tegen gevaarlijke besmettingen kunnen beschermen, aldus The Register.
Terwijl de worm zich door het bedrijfsnetwerk verspreidde ontdekte de NCC Group een relatief eenvoudige oplossing die beschermt tegen NotPetya-besmettingen. Bij de klant werd de Active Directory zo ingesteld dat het account ‘gevoelig’ is en dus niet kan worden ‘gedelegeerd’.
Volgens een bericht op Microsoft Technet kunnen accountgegevens van een ‘gevoelig account’ niet door een vertrouwde applicatie naar andere computers of diensten op het netwerk worden doorgestuurd. “We ontdekten dat deze configuratie de verspreiding van NotPetya aanzienlijk zou hebben belemmerd”, zegt een woordvoerder van NCC tegen The Register.
NotPetya verspreidde zich in 2017 met als meest bekende slachtoffer containerbedrijf Maersk.
Een gevolg is dat dienstverleners en software leveranciers niet alles onder een serviceaccounts met vele rechten moeten draaien.
Uit de eenvoud van installatie en beheer goedkoop en snel neergezet is die trend wel doorgezet.
Het probleem speelt bij elk os. Rbac is begrijpelijk zolang men er figuren op afdelingen bij kan denken.
Met services moet je wat verder kijken.
Overigens speelde bij maersk als bekendste voorbeeld dat iedereen wist dat er wat aan beveilig moest gebeuren maar niemand op c level die verantwoirding wilde.
Een gevolg is dat dienstverleners en software leveranciers niet alles onder een serviceaccounts met vele rechten moeten draaien.
Zou het OS dat eigenlijk niet moeten beperken?
Een gevolg is dat dienstverleners en software leveranciers niet alles onder een serviceaccounts met vele rechten moeten draaien.
Zou het OS dat eigenlijk niet moeten beperken?
Het bepalen waarvoor en hoe je een service-account inricht is een geen taak voor een OS maar hoort bij de "applicatie".
Master DBA local DBA zijn al aardig ingeburgerd. Je moet dat doortrekken naar alle technieken met data / informatie.
Kom je bij een datawarehouse dan is het containeriseren al zowat oorlog veroorzakend. Met BI selfservice, Analytics en shadow ict ben je meteen de gebeten hond als je over service accounts highe privileged met minimale rechten begint.
Leveranciers geven dan rusting het advies om een shared algemeen generiek account te gebruiken. Verkoop is het doel.
De beslissers in de organisatie zijn daar blij mee, kostenbesparend. Stel je voor dat je van alles moet regelen.
De OS mensen noemen alles applicatie en bedoelen dat zij er niet mee lastig gevallen willen worden.
Het is lastig te doorbreken kringetje van naar anderen wijzen.
Een gevolg is dat dienstverleners en software leveranciers niet alles onder een serviceaccounts met vele rechten moeten draaien.
Zou het OS dat eigenlijk niet moeten beperken?
te beperken, maar het is meestal niet zo populair om daar tijd en geld in te steken voor het moment waarop het bedrijf
slachtoffer wordt.
Simpele outsourcing bedrijven gooien dit soort maatregelen en juist uit omdat het niet is waar ze standaard mee werken
en ze willen een standaard omgeving waarin hun medewerkers niet tegen onverwachte hordes aanlopen als ze bijvoorbeeld
nieuwe software installeren of problemen onderzoeken.
Dit verschuift uiteraard wel enigszins omdat ze nu met de consequenties geconfronteerd worden, maar dat soort dingen
gaat langzaam.
Als het kalf verdronken is...
Dempt men de put met 3 jaar oud zand...
- Exchange OWA of ECP, hierbij delegeert namelijk het webfrontend het account naar het exchange backend.
- SQL Reporting Services maakt ook gebruik van het delegeren van de login.
- SQL linked servers
- En nog vele andere services werken hierdoor niet meer.
Misschien kan de "Redactie" nog even een aanvulling doen in het artikel dat er ook een keerzijde is aan deze setting.
Als het kalf verdronken is...
Het is lastig te doorbreken kringetje van naar anderen wijzen.
Als het kalf verdronken is...
Achteraf... Hadden bijna alle datalekken voorkomen kunnen worden door geen Windows te gebruiken. Maar ja... Achteraf....
Als het kalf verdronken is...
Achteraf... Hadden bijna alle datalekken voorkomen kunnen worden door geen Windows te gebruiken. Maar ja... Achteraf....
https://qz.com/1480809/the-biggest-data-breaches-of-all-time-ranked/
Of jij moet toevallig informatie hebben dat deze datalekken op Windows draaide? Dit zijn volgens mij allemaal backend systems of webservers die gehacked waren. En die draaien.... Wat meestal... Juist Linux.
Dus in lijn met jouw conclusie.... Hadden bijna alle datalekken voorkomen kunnen worden door Windows te gebruiken.
trouwens, NotPetya was Ransomware en niet direct een datalek. Ransomware komt meestal wel op Windows systemen voor.
Als het kalf verdronken is...
Achteraf... Hadden bijna alle datalekken voorkomen kunnen worden door geen Windows te gebruiken. Maar ja... Achteraf....
https://qz.com/1480809/the-biggest-data-breaches-of-all-time-ranked/
Of jij moet toevallig informatie hebben dat deze datalekken op Windows draaide? Dit zijn volgens mij allemaal backend systems of webservers die gehacked waren. En die draaien.... Wat meestal... Juist Linux.
Dus in lijn met jouw conclusie.... Hadden bijna alle datalekken voorkomen kunnen worden door Windows te gebruiken.
Nee, want Windows is totaal ongeschikt voor dat soort grootschalige servertoepassingen. Dat is dus geen optie en daarom gebruiken technologiegiganten het ook niet daarvoor.
- Exchange OWA of ECP, hierbij delegeert namelijk het webfrontend het account naar het exchange backend.
- SQL Reporting Services maakt ook gebruik van het delegeren van de login.
- SQL linked servers
- En nog vele andere services werken hierdoor niet meer.
Misschien kan de "Redactie" nog even een aanvulling doen in het artikel dat er ook een keerzijde is aan deze setting.
Deze instelling moet alleen worden toegepast op beheer accounts, en dus niet voor eindegebruikers, waardoor de impact al minder wordt. Als deze services Kerberos delegation nodig hebben voor beheer, dan zou het verstandig zijn om hiervoor aparte accounts aan te maken. Mocht het een aanvaller dan lukken om het Kerberos TGT te stelen uit het geheugen, dan kunnen ze niet gek veel doen, omdat de account alleen rechten heeft tot deze specifieke services/servers.
Als dat te veel beheers last oplevert, dan zou Just In Time / Just Enough Administration(JIT/JEA) beheer een goede oplossing kunnen zijn. Waarbij je de rechten tot het beheer van deze services aanvraagt, en deze voor een bepaalde tijd geldig zijn. Hiervoor kun je kijken naar Microsoft Identity Management(MIM) in samen werking met Priviledged Access Management(PAM). MIM PAM rol je niet zomaar even uit in je netwerk, maar levert wel een aanzienlijke verbetering op voor de beveiliging van je Active Directory omgeving.
Nee, want Windows is totaal ongeschikt voor dat soort grootschalige servertoepassingen. Dat is dus geen optie en daarom gebruiken technologiegiganten het ook niet daarvoor.
Je maakt zelf de conclusie: Achteraf... Hadden bijna alle datalekken voorkomen kunnen worden door geen Windows te gebruiken. Maar ja... Achteraf....
Maar alle grote datalekken niet juist NIET van Windows af. Daarom zou het misschien juist een goede zijn om wel eens te inventariseren of juist wel Windows een beter platform had kunnen zijn. Immers alle grote datalekken komen NIET van Windows af. Dus misschien is het er juist wel geschikt voor en hadden de datalekken voorkomen kunnen worden.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?