Amerikaanse CISA raadt aan Remote Desktop Protocol uit te schakelen

Het Amerikaanse Cybersecurity and Infrastructure Security Agency raadt netwerkbeheerders aan het Remote Desktop Protocol volledig uit te schakelen nadat hackers het misbruikten voor spearphishingaanvallen. Dat een organisatie aanraadt RDP helemaal uit te zetten, is opvallend.

CISA waarschuwt in een advisory voor aanvallen van 'een buitenlandse threat actor'. CISA zegt dat aanvallers gerichte phishingaanvallen uitvoeren op organisaties om bestanden van netwerken te stelen. In sommige gevallen sturen de aanvallers ook malware mee om permanentere toegang tot het netwerk te krijgen. Het gaat om een aanval van Russische hackers waarvoor Microsoft eerder al waarschuwde.

De organisatie raadt om die reden onder andere aan het Remote Desktop Protocol uit te schakelen. Het RDP wordt gebruikt om op afstand toegang te krijgen tot netwerken, maar in de praktijk wordt de tool vaak misbruikt door aanvallers. "Het wordt sterk aangeraden voor organisaties om naar buiten verwijzende RDP-verbindingen naar externe netwerken te verbieden of significant te beperken", schrijft CISA. Ook zouden organisaties moeten voorkomen dat bestanden via RDP in webclients en webmaildiensten worden verstuurd. Ze moeten daarnaast voorkomen dat eindgebruikers RDP-bestanden kunnen openen of uitvoeren.

CISA raadt ook andere maatregelen aan om veilig te blijven voor de aanvallen. Dit omvat bijvoorbeeld het instellen van multifactorauthenticatie en het opzetten van endpointbeveiligingssoftware. Dat de organisatie aanraadt RDP helemaal te blokkeren, is echter het opvallendst. RDP komt al jaren steeds meer onder vuur te liggen omdat het een van de belangrijkste aanvalsmethoden voor hackers is. Toch raden maar weinig organisaties daadwerkelijk aan RDP compleet uit te schakelen. Dat CISA daar nu toch voor pleit, lijkt een kentering in de manier waarop beveiligingsorganisaties het protocol behandelen.

Reacties (68)

[poktor]

Het zou Microsoft sieren als ze 2FA zouden toevoegen aan het RDP protocol. Daarmee wordt het al een stuk veiliger.

[SunnieNL]

Als jij MFA aktief hebt op je windows domein is dat automatisch ook met RDP. Je authenticeerd op de machine waar je naar toe verbindt, als die MFA vereist zal RDP daar ook om vragen (of het remote inlogscherm tonen).

Maar dat gaat hier niet helpen. Het probleem is nu volgens mij dat jij een RDP krijgt met inloggegevens en automatische koppeling van clipboard, drives, etc naar een machine van een hacker. Zogauw je daar op komt gaat de hacker via die gekoppelde kanalen naar jouw machine om het kwaad te doen (dat is ook vrij makkelijk te automatiseren).

De enige manier is om dan uitgaande RDP naar publieke adressen te blokkeren. RDP wordt intern nog best veel gebruikt (denk aan Hulp op afstand en beheerders die verbindingen maken met servers)

[Reactie gewijzigd door SunnieNL op 1 november 2024 13:37]

[MrDaViper]

MFA kan je niet zomaar op een windows domain doen. Daar heb je ook alweer externe tools voor nodig zoals bv Silverfort, maar de kostprijs daarvan is ook al weer aardig..
Ik mag hopen dat je op je firewall sowieso uitgaande RDP blokkeert buiten naar diensten die effectief nodig en vereist zijn.

Maar in de context van CISA gaat het eigenlijk over inkomende RDP, iets waar CISA nu eigenlijk wel al een jaar of 20 te laat mee afkomt want inkomende RDP laat je - hoop ik - sowieso nooit toe.
cfr o.a. bluekeep etc..

[SunnieNL]

Nee, de CISA waarschuwd juist voor naar buiten gaande RDP verbindingen, niet voor die naar binnen (waar ze inderdaad al jaren voor waarschuwen)

Het wordt sterk aangeraden voor organisaties om naar buiten verwijzende RDP-verbindingen naar externe netwerken te verbieden

Het gaat juist om de atttacks waar Microsoft eerder van de week al voor waarschuwde, waarbij een RDP bestand wordt opgestuurd en je gebruiker die er op klikt een verbinding naar buiten legt.

[MrDaViper]

klopt, ik was iets te kort door de bocht gegaan.
Maar zelfs uitgaande RDP connecties laat je niet zomaar toe. En ook daar is CISA enorm veel te laat mee want dat is iets wat je al sinds het begin van RDP al wou geblokkeerd hebben.

[dasiro]

Als je mailfilter .RDP bestanden doorlaat, dan kan je net zo goed .EXE bestanden toelaten. Waarom zou je webfilter dan nog moeite doen als je gewoon de achterdeur wagenwijd open zet?

Dit soort aanvallen is een van de simpelste die er is en toch verbaas ik me er over dat ze hier nog zo makkelijk mee binnen geraken dat zulke draconische waarschuwingen toch nog moeten worden uitgestuurd. Je zou bijna denken dat sysadmins hun titel bij een zakje chips hebben gekregen (spoiler: vaker dan gewenst is het ook effectief zo).

[Aetje]

Dat gaat nog vrij vervelend worden voor Azure Virtual Desktop gebruikers. Die moeten een verbinding gaan leggen via RDP (over HTTPS, dus uitgaand op poort 443) naar de cloud VMs. Wanneer je alle uitgaande RDP verkeer verbied kunnen je clients dus niet meer bij deze service...

[HaikoW]

MFA kan je niet zomaar op een windows domain doen. Daar heb je ook alweer externe tools voor nodig zoals bv Silverfort, maar de kostprijs daarvan is ook al weer aardig..

Silverfort doet veel meer dan alleen je eigen MFA op letterlijk alles wat via de AD authenticeert inzetten.

[MrDaViper]

Klopt. Ik haal Silverfort in deze contextr ook maar aan voor MFA op je windows domein.
Want zonder tools zoals bv Silverfort kan je op een windows domein geen MFA doen.
Maar het probleem met zulke tools is dat, zelfs al doen ze veel meer dan enkel MFA op het windows domein, 8/10 managers vinden dat het een nodeloze en veel te hoge kost is.

[joenevd]

Standaard is poort 3389 gebruikt voor het RDP protocol, dat is echter makkelijk aan te passen.
Je moet dus niet alleen RDP blokkeren, je moet alle poorten blokkeren en alleen toestaan wat wel mag.

En dan kan hij nog een stukje ingewikkelder gemaakt worden. Als je RDP namelijkcombineert met RD Gateway, gaat het over poort 443 en probeer dat maar eens te blokkeren.

[MrDaViper]

Simpel, een deftige ngfw doet dat perfect.
Ik zou hopen dat elk beetje bedrijf toch een deftige firewall heeft die application recognition gebruikt.
en sowieso blokkeer je alles inbound buiten wat je effectief nodig hebt. Elk iemand die een RDGW wil opzetten slaagt er niet in tenzij de firewall daarvoor aangepast wordt. En dat wil je zeker niet voor zulke troep

[joenevd]

Handig voor de thuiswerkers.. gelukkig zijn wij sase aan het implementeren.

[MrDaViper]

Als je bedrijf een RDPGW geimplementeerd heeft voor bv thuiswerk of zelfs maar RDP rechstreeks extern toelaat is die niet goed bezig, maar dat is mijn mening.
RDP en ook RDPGW zijn nooit veilig geweest en altijd ongewenst om vanaf buiten te benaderen (ook al wil M$ je daarnaar forceren)
Je bent beter af met een Citrix implementatie of andere tools zolang je maar session recording kunt doen.
Of je gebruikt Win365 of de microsoft solution in Azure.

[nullbyte]

Dit moet niet op een firewall worden afgedwongen maar via GPO's. Middels een Windows Policy kan RDP uitgezet worden. Onderstaande registersleutel wordt dan op 0 gezet.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

[Reactie gewijzigd door nullbyte op 3 november 2024 21:39]

[joenevd]

Dat is niet relevant voor de betreffende kwetsbaarheid.

[MrDaViper]

RDP op pc/server niveau volledig afzetten? De support & INFRA teams zullen dat leuk vinden..
Maar is idd niet relevant voor deze kwetsbaarheid en ook niet voor het artikel

[The Lord]

MFA kun je zeker wel zonder externe tools op je AD gebruiken d.m.v. certificaten.

Daarnaast kun je ook domain security policies hieraan koppelen voor outbound firewall rules. Als je echt losgaat zelfs volledige domain security toepassen.

En er is nog wel meer mogelijk om op dit vlak de beveiliging naar een heel hoog niveau te brengen.

[watabstract]

Met een ouderwets Windows Domain niet maar met Azure/Entra domain is het geen probleem meer.

[MrDaViper]

Maar je hebt nog altijd geen 2FA met een Entra-ID joined PC. Je kan andere authenticatie methodes gebruiken (PIN, HfB, ..) , maar nog geen 2FA
Maar dan heb je nog altijd je servers niet mee en ook niet de applicaties die naar een on-prem AD connecteren want daar kan je ook nog geen 2FA doen.
ALS je applicaties Entra-ID ondersteunen kan je wel 2FA forceren, maar 3/4 van de applicaties zijn daar nog niet mee mee en werken nog op ouderwetse LDAPs..

[Reactie gewijzigd door MrDaViper op 2 november 2024 11:27]

[watabstract]

Hoe moet ik dit dan interpreteren?

With the release of Windows 11, the supported scenarios and capabilities of Web sign-in are expanded.
For example, you can sign in with the Microsoft Authenticator app or with a SAML-P federated identity.

[MrDaViper]

Net zoals het er staat: je kan inloggen met de authenticator app. Maar dat is zonder dat je je wachtwoord moet invoeren en zonder dat je bv number matching moet doen.
Aka, je wil inloggen op je pc en krijgt gewoon een push melding op je telefoon dat je moet goedkeuren.

Dat is al actief in Hello for Business en doet niet meer dan dat. Jammer genoed doet dat dus nog altijd geen 2FA. (last I checked - ongeveer een maand of 5 geleden)

Maar opnieuw, zelfs al zou dat 2FA doen (wat hopelijk in de toekomst wel komt) dan is dat enkel voor desktop/laptop en niet voor alle andere services of toepassingen op het domein en zeker ook (nog) niet voor servers.

[watabstract]

Maar je moet dan neem ik aan wel een pincode invoeren of gezichtsherkenning gebruiken toch? Want dan is het wel degelijk een vorm van 2fa. Sowieso maakt een bevestiging op je telefoon het inloggen al heel veel veiliger omdat er twee devices bij het proces betrokken zijn.

[poktor]

Het gaat dus gewoon om ordinaire phishing, maar dan met een RDP-attachment. Hoort dat niet standaard op de mailserver geblokkeerd te worden?

[BytePhantomX]

De praktijk is dat het niet standaard geblokkeerd wordt en je als beheerder extra stappen moet zetten om dat wel te doen.

[Fermion]

Er bestaat een alternatief dat buiten het domein werkt: ROHOS Logon Key
Na het inloggen vraagt het om een OTP, het maakt gebruik van het Google TOTP standaard, hiervoor heb jde de gratis apps zoals Authy of beter 2Fas auth. Werkt prima op mijn W2106.

https://rohos.com/

[SunnieNL]

Het gaat erom dat de hacker natuurlijk geen MFA gaat activeren op de server waar hij jouw naar toe stuurt.
Op een server die niet van jouw organisatie is, kun jij geen MFA afdwingen.

In dit geval krijg jiij een RDP bestand dat verbinding maakt met een server van een hacker. Dan kun je MFA actief hebben op je omgeving, maar dat gaat je niet beveiligen tegen deze aanval.

Het is anders als jij server van jezelf aan het publiek internet gaat hangen en verbindingen van clients buiten de deur naar die server gaat toestaan. Zou ik nog steeds niet doen, maar dan helpt MFA wel op die server (een heel klein beetje)

[DealExtreme2]

Dit gaat over heel iets anders; over het misbruiken van een uitgaande RDP verbinding voor het mappen van network en local drives en resources.

Je maakt een RDP bestandje dat connect op poort 443 van de aanvaller's RDP proxy met hierin username/password opgeslagen - de verbinding wordt gemaakt. Bovendien heb je in de rdp settings map all network drives. Nu kan de server van de aanvaller bij jouw lokale drives.

Het heeft dus met UITGAANDE rdp verbindingen te maken; niet met inkomende. Hoe je RDP 'helemaal' kan uitzetten, ik zou het niet weten. Het runnen van mstsc verbieden?

[poktor]

Het blijkt dat er phishing mails rondgaan met hierin RDP bestanden als attachment. Lijkt mij eenvoudig te blokkeren op de mailserver. Gewoon de RDP-extensie als attachment verbieden.

[SunnieNL]

Daarmee los je natuurlijk niet het onderliggende probleem op dat je toestaat RDP verbindingen naar buiten op het publieke internet te maken.

Dat RDP bestand kan ik nog steeds in een zipfile duwen en dan zal er vast nog wel iemand het uitpakken en alsnog op het RDP bestand klikken.

Dus beste wat je kan doen:
- RDP alleen toestaan naar je interne IP reeksen (mocht je het nodig hebben) via firewalls op de client
- RDP naar buiten op je uitgaande router dichtzetten op de standaard poort
- Mail filteren en die RDP bestanden sowieso blokkeren (snap ook niet dat Microsoft dat niet default doet op Exchange en dat je dat moet uitzetten als beheerder als je dat niet wilt)
- mstsc.exe volledig blokkeren om te draaien op het moment dat je geen RDP gebruikt intern (bv. via applocker policy)

Beste beveiliging is in lagen. Valt er één laag, dan heb je tenminste nog een protectie van een andere laag.

[Reactie gewijzigd door SunnieNL op 1 november 2024 14:32]

[wow7]

Verwijderen:
mstsc /uninstall /noPromptBeforeRestart

[mbovenka]

Ik mag hopen dat je dat zelf al doet als je iets als RDP/Citrix/VMWare Horizon/vul-maar-in vanaf buiten bereikbaar maakt.

[The-Source]

De aanval die plaatst vind is niet op de zelf beschikbaar gesteld rdp. Maar dat je een cliënt/ gebruiker naar een specifieke rdp server laat connecteren en door het profiel wat in het rdp bestand zit wordt dus gegevens gestolen en toegang verkregen op de cliënt

[biteMark]

https://learn.microsoft.c...top-services/rds-plan-mfa
Goed, RDS gaat eens stapje verder dan RDP, maar daarmee is het wel mogelijk.

[Reactie gewijzigd door biteMark op 1 november 2024 13:36]

[Anonymoussaurus]

Dat kan al:

• https://learn.microsoft.c...top-services/rds-plan-mfa
• https://www.watchguard.co...oint/logon-app_about.html
• https://www.watchguard.co...al-Desktop_authpoint.html

[Reactie gewijzigd door Anonymoussaurus op 1 november 2024 13:48]

[DigitalExorcist]

2FA in de vorm van smartcards bestaat toch al een poosje op RDP?

[walteij]

Hoe wil je dat doen met kerberos authenticatie?

De oplossingen die @Anonymoussaurus aanvoert, maken allemaal gebruik van een RD gateway (achtige) oplossing.

[Reactie gewijzigd door walteij op 1 november 2024 13:53]

[Odder thing]

Nou liever niet. Als je 2FA nodig hebt om je eigen systemen 'veilig' te houden dan doe je iets verkeerd. Nog even en dan heb je een QR nodig + een sms en daarboven op mail bevestiging. Neen dank u.

[SilentDecode]

Mee eens. Goed plan.

Voor deze reden heb ik een gratis accountje bij DUO (wat nog niet van Cisco was toen ik het nam, maar inmiddels wel een aantal jaren) waarbij ik MFA kan forceren op een RDP verbinding. Het nadeel hiervan is dat er dan al een verbinding tot stand is gebracht met de server, want je zit al op het inlogscherm.

Het is wel beter dan niks.

[ToolBee]

Ik weet sinds WinXP al niet beter dan dat deze service moet worden uitgezet.
Net zoals NetBIOS (tcp). Daar zaten toen ook al waarschuwingen bij. Als normale thuisgebruiker zul je ze ook niet missen.

[wildhagen]

Ook zouden organisaties moeten voorkomen dat bestanden via RDP in webclients en webmaildiensten worden verstuurd.

Zouden er serieus nog organisaties zijn die dit soort extensies niet blokkeren als attachment? Dat is ongeveer net zoiets als een .exe of .vbs extensie toestaan als bijlage in een mail. Dat kon nog in 2000 (en zelfs toen was dat al twijfelachtig....) maar anno 2024 is dat toch wel een hele dikke no-no....

Idem voor dit:

"Het wordt sterk aangeraden voor organisaties om naar buiten verwijzende RDP-verbindingen naar externe netwerken te verbieden of significant te beperken", schrijft CISA.

Dit is ook geen best practice, om RDP naar buiten toe (of van buiten naar binnen) voor algemeen gebruik toe te staan, en dan druk ik me nog zacht uit. Dat is ook al jaren heel erg afgeraden. Als je dan toch RDP toe moet staan, doe het dan alleen voor een selecte groep van mensen, en dan alleen van/naar specifieke (lees: vertrouwde) IP-adressen. En liefst niet via de standaard poort 3389, indien mogelijk.

Dus op zich zijn de adviezen van CISA volkomen terecht, maar ik mag toch hopen dat organisaties die hun security tenminste nog een béétje serieus nemen deze acties al een hele tijd in place hebben staan.

[poktor]

Dit inderdaad. RDP naar buiten toe was 20 jaar geleden al een dikke no-no. Als je dat deed, draaide de firewall overuren door alle aanvallen op poort 3389.

[_JGC_]

Dat is RDP naar binnen toe. Naar buiten toe is als je vanuit je eigen netwerk verbinding maakt naar een server buiten het netwerk.

Maargoed, net zoals ik OpenVPN heb draaien op poort 443 TCP wat prima dwars door een bedrijfsfirewall gaat, kan je RDP op elke gewenste poort zetten, desnoods via een RDS gateway.

[DigitalExorcist]

Dan heb je het over *inkomend* RDP, niet uitgaand

[SunnieNL]

Gezien het feit dat de CISA zaken op de KEV lijst heeft staan die al maanden een patch hebben en dat je als je scant op die vulnerabilities, 1000-den machines op internet vind zonder die patches, zijn er genoeg organisaties die ook deze RDP beginselen vast niet hebben doorgevoerd.

[BytePhantomX]

Heb jij een definitieve lijst met extensies die je moet blokkeren? En zo ja, stond RDP daar dan al op?
Tot deze meldingen had ik geen idee dat RDP zo misbruikt werd en zag ik er geen enkel risico in. Waarom zou je dan het rondmailen van een RDP bestandje moeten verbieden.

Als we zo gaan beginnen, dan zou ik pdf extensies ook moeten verbieden, die worden vaker gebruikt in malware campagnes. Of .zip bestanden.

Beetje stellig om te zeggen dat dit een dikke no-no is anno 2024.

Dit is ook geen best practice, om RDP naar buiten toe (of van buiten naar binnen) voor algemeen gebruik toe te staan, en dan druk ik me nog zacht uit. Dat is ook al jaren heel erg afgeraden. Als je dan toch RDP toe moet staan, doe het dan alleen voor een selecte groep van mensen, en dan alleen van/naar specifieke (lees: vertrouwde) IP-adressen. En liefst niet via de standaard poort 3389, indien mogelijk.

Naar buiten toe zal het voor de meeste organisaties wel dicht staan. Maar dat wordt dicht gezet op de firewalls. Ik ken niet veel organisaties die op werkplek niveau ook dit soort reeksen dicht zet. Die poorten dichtzetten heeft dus vaak ook alleen nut als mensen op kantoor werken en niet als mensen thuis werken.

En afwijken van de standaard poort is ook security through obscurity. Een keertje goed scannen en ze zijn zo gevonden.

[Reactie gewijzigd door BytePhantomX op 1 november 2024 16:29]

[Stetsed]

Ik zit dus door het rapport te lezen, maar het gaat niet zozeer over het RDP-protocol uit te schalen, maar het communiceren van dit protocol te limiteren, met een grotere nadruk op attachments en files van externe netwerken.

Uit het rapport kan ik bijvoorbeeld "It is strongly advised that organizations forbid or significantly restrict outbound RDP connections to external or public networks." vinden, dit is niet specifiek het limiteren van het RDP protocol, maar is eigenlijk "Doe wat je met andere protocols zou doen en ga ervan uit dat dit ook gewoon malicieus kan zijn zelfs als het extern bound is."

Ook zie ik verder in het rapport dat het blijkt dat deze attacks eigenlijk gewoon normale phishing attacks waren, maar dan met een andere file extensie. Dus het gaat niet over "Het RDP-protocol", maar meer over phishing in generaal en dit rapport is dan dat er exploits zijn met RDP-files dus let daar effe op(Is hoe ik het lees).

Ik moet ook zeggen dat ik het niet eens ben met @Triblade_8472 's comment, dit is niet het open hebben van interne management verbindingen naar buiten, maar exploits binnen RDP-implementatie/gebruik(zover ik kan vinden), dat het toestaat dat een kwaadwillige persoon een RDP file kan sturen(zelfde manier waarop ze een .exe zouden sturen), en dat deze dan eigenlijk kan functioneren als een reverse shell.

Het ding is ook dat RDP niet een eigen protocol type is, het runt gewoon op TCP/IP. Dus veel kleine bedrijven die zijn echt *snooze* op dat soort gebied, en ja, je kunt gewoon die hele poort naar externe connecties blokkeren, maar dan doe je een leuke:443, of een leuke :(Andere Random Port). En dan moet je een vorm van packet inspection gaan doen, wat de complexiteit omhoog werkt.

Ik denk dat eigenlijk dit hele rapport neerkomt(Dat zijn de meeste punten ook): Gebruik goede MFA, geef je mensen training op phishing attacks, en filter de e-mails beter(Zelfs als het niet meteen executable is kan het gevaarlijk zijn)

[Reactie gewijzigd door Stetsed op 1 november 2024 13:45]

[walteij]

En toch he.... Ben ik als ervaren sysadmin helemaal voor het tot het uiterste minimum beperken van RDP gebruik. Remote management wordt steeds beter/makkelijker via WMI en PowerShell.
Windows Server Core zoveel mogelijk installeren en gaan met die banaan, scheelt je resources en attack surface.

Voor de GUI gebruikers kun je Windows Admin Center en Remote Management Tools installeren op een management server (of nog beter PAW's). WMI beperk je dan dus ook zodat het alleen vanaf die systemen en niets meer.

Configuratiebestanden zet je in een repo voor de betreffende applicatie en als je deze hebt aangepast, trap je een workflow af om de bijgewerkte bestanden op de server te updaten.

[Stetsed]

"En toch he.... Ben ik als ervaren sysadmin helemaal voor het tot het uiterste minimum beperken van RDP gebruik."

Ik ben het helemaal met je eens, ik gebruik persoonlijk in mijn homelab en voor werk helemaal geen RDP. SSH bestaat altijd nog . Maar soms moet je een remote desktop hebben en dat heb je gelijk er zijn opties zoals WAC en RM. Het probleem is dat deze brief niet gaat over inbound connecties, die zijn makelijk, het gaat over outbound connecties.

Voor inbound ben ik helemaal met je eens, hell je zet het op een VLAN en een subnet(als je physieke hardware hebt), of een private LAN als je in een cloud provider zit, en die heeft geen externe connectiviteit, maar je hebt dan 1 host die dat well heeft en deze gebruik je dan als jumphost en dan weet je waar je zwakte punt zit. Maar dit is met inbound, niet met outbound.

Dan kan je makelijk een port block erop zetten, maar ja dan zegt die rdp file gewoon "Hey, het is port 443 niet port (default)", en toch komt hij erdoor. En hier is eigenlijk weinig tegen te doen behalve als je een vorm van packet inspectie gaat toepassen maar voor kleine bedrijven is dit vaak gewoon "Moeite".

[walteij]

RDP outbound moet je gewoon net zo hard verbannen als RDP inbound .

Remote management gebruikt ook random RPC ports in het hogere segment, als je die outbound ook blokkeert is er weinig aan de hand.
En ssh werkt tegenwoordig ook prima onder linux, net als een Enter-PSSession in powershell mocht je direct op de machine iets willen doen.

In een cloud omgeving kun je altijd nog een bastion netwerk gaan gebruiken en toegang tot dat netwerk nog eens beperken via conditional access.

[InjecTioN]

Precies!

En als je dan toch SSH open hebt staan, dan heb je direct de mogelijkheid om public key authentication in te stellen en password authentication uit te schakelen. Mooi fail2ban erop, ciphers en andere versleutelingen zo strict als mogelijk, etc.

Met behulp van SSH kan je dan zelfs alsnog gebruik maken van RDP via een SSH tunnel:

ssh -L 8888:192.168.20.103:3389 [e-mail] -p 1234

Vervolgens verbind je met de RDP client met 127.0.0.1:8888, en dan zit je via de SSH tunnel op de juiste machine, terwijl je geen RDP verkeer toestaat op de WAN verbinding.

[Fermion]

Waarom kan RDP dit niet op een meer simpelere manier. Je hebt RDP gateways, maar dat verder een integratie met je DC en PKI infra…. Dit maakt voor de meeste omgevingen te ingewikkeld. Ik ben blij met het advies, ik hoop dat MS zich ertoe beweegt voor een veiligere oplossing waarvan je ook minder afhankelijk bent van andere systemen.

[walteij]

Omdat RDP een verouderd protocol is, uit de tijd dat we elkaar op het internet nog enigszins vertrouwden.
Net als SMTP (waar tig extra's voor nodig zijn om het veilig(er) te maken), DNS en andere protocollen.

[WillySis]

Wij (klein bedrijf) hebben onze ITC voor het grootste deel geoutsorced. In de praktijk werken we via remote desktop op virtuele machines bij een provider. Wel heel vervelend als je die functie moet uitschakelen.
We hebben zelf maar een halve ITC-er (ik, zij de gek) die ook nog eens drie à vier maanden per jaar aan de andere kant van de aardbol zit. Zelf alle ITC beheren zit er echt niet in.

[Stetsed]

Het gaat hier ook niet specifiek over het uitzetten van het RDP protocol, zoals ik had genoemd in mijn comment is dit een reactie op een fishing campange waar RDP files werden gebruikt als payload om(van wat ik begrijp) een vorm van reverse shell te krijgen. De recommendaties komen eigenlijk voor het grootste deel op de standaard dingen neer, alleen zeggen ze ook dat het slim is om extern bound RDP connecties te blacklisten(met een whitelist voor bijvoorbeeld het IP van je cloud-service provider die vaak publiek is).

[Z!oN]

Misschien heeft de autheur een andere bericht gelezen, maar volgens mij staat in het CISA advies om uitgaande RDP verbindingen te blokkeren. en niet zo zeer om RDP als geheel uit te schakelen, omdat RDP gebruikt kan worden om credentials te bemachtigen..

[Triblade_8472]

"Het wordt sterk aangeraden voor organisaties om naar buiten verwijzende RDP-verbindingen naar externe netwerken te verbieden of significant te beperken"

Ja joh. Dat is ook in Nederland groot in 't nieuws geweest.

Wie haalt het dan ook in z'n hoofd om management verbindingen, extern te open te hebben...? Als je dat doet dien je toch echt op 't matje geroepen te worden hoor.

[SunnieNL]

Een management verbinding extern open hebben is een naar binnen verwijzende rdp verbinding in mijn ogen. Het verkeer komt dan van buiten naar binnen de management server op.

De CISA draait het nu om. Het adviseert om geen client verbindingen van binnen naar buiten (het publieke internet op) toe te staan. Ik denk dat er maar weinig bedrijven zijn die vanaf de client een uitgaande RDP verbinding blokkeren. Client RDP wordt immers ook gebruikt voor Hulp of afstand of door de beheerder om verbinding te maken met zijn interne servers. Wat CISA nu zegt is dat je dat interne verkeer van de client naar een server best mag toestaan, maar dat je verbindingen van client naar internet toe toch wel het beste kan blokkeren.

Ik zou gewoon zelf een stapje verder gaan. Blokkeer mstsc.exe gewoon voor elke gebruiker die RDP sowieso niet nodig heeft.

[MarcelG]

Het gaat enkel om uitgaande RDP verbindingen naar niet vertrouwde omgevingen, dus naar de RDP host van de aanvaller.

Die RDP host heeft - als jij verbindt met clipboard redirection en (local) drives redirection aan (en dat staat in die RDP file) - toegang met jouw rechten op al je geconnecte drives en clipboard.
Simpel scriptje om alle wallet.dat en KDBX bestanden te kopiëren of je clipboard uit te lezen elke 5 seconde, en klaar.
Deze attack vector is al jaren bekend.

Ik vraag me overigens af hoe MFA deze vector afsluit; de aanvaller bepaalt hoe je moet inloggen, niet de organisatie van het slachtoffer. Dus MFA gaat hier niets in betekenen.

Deze vector geldt overigens ook voor Citrix (ICA files) alhoewel je daar als ik me niet vergis in elk geval een waarschuwing krijgt als de remote host gebruik wil maken van de drive mapping en het clipboard. Maar die klikken veel mensen toch gewoon weg.

Kunst is om het target zo lang mogelijk aan het lijntje te houden, zodat je extractie-script z'n werk kan doen.

[Reactie gewijzigd door MarcelG op 1 november 2024 16:04]

[FrostyPeet]

Maar deze truc is toch zo oud als de weg naar Kralingen?

Drie jaar geleden zag ik al Youtube video's waarin (bejaarde) Amerikanen werden opgebeld door "Microsoft" en dan een uitgaande Remote Desktop tool moesten gebruiken. Toen Teamviewer waarschuwingen gaf voor inkomende verzoeken van "bekende" oplichterslanden pasten de afpersers hun tactiek aan naar uitgaande verbindingen of een ander tooltje.

Dacht dat ondertussen alle uitgaande RDP achtige verbindingen allang verboden waren bij bedrijven, of het moet in een VPN omgeving zijn.

[Dark Angel 58]

Verenig de landen daadwerkelijk dan was een waarschuwing niet nodig, omdat we daarna geen vijanden meer hebben.

[eettjjuuhh]

Ja en dan kunnen alle wapens ook de wereld uit… sweet dreams!

[Dark Angel 58]

Wapens zijn altijd nodig voor verkenning in de ruimte
Hoe wil je meteorieten die een planeet of kolonie bedriegen verslaan? Met de handen?

[ctrl-tab]

Rdp open voor de buitenwereld.. vragen om problemen. zo blijkt.