Na het weekend ligt er een mix van beheertools en vertrouwde diensten die tegen hun gebruikers worden ingezet. Er is een werkende exploit verschenen voor een lek in AnyDesk op Linux, Cisco repareert vijf kritieke fouten in Nexus-switches en vier lekken in zijn licentiebeheertool, een phishingcampagne gebruikt een openbaar Power BI-dashboard om ScreenConnect-clients te installeren, en een lege afzender omzeilt de Microsoft 365-blokkade op Direct Send.
- Werkende exploit voor pre-auth lek in AnyDesk voor Linux geeft rootrechten
- Cisco repareert vijf kritieke fouten in Nexus-switches en vier in Smart Software Manager
- Phishing via Microsoft Power BI zet ongemerkt ScreenConnect-clients neer
- Lege envelopeafzender omzeilt de Microsoft 365-blokkade op Direct Send
Werkende exploit voor pre-auth lek in AnyDesk voor Linux geeft rootrechten
| Kwetsbaarheid | Heap buffer overflow in het sessieprotocol, waardoor een ongeauthenticeerde aanvaller via een directe verbinding opdrachten als root kan uitvoeren – AnyDesk voor Linux, de publieke exploit richt zich op versie 8.0.2. Windows en macOS zijn niet getroffen |
| CVE-nummer | Nog niet toegewezen |
| Actief misbruikt | Nee, er is geen misbruik gemeld. Wel is sinds 8 oktober een werkende exploit openbaar |
| Patch beschikbaar | Ja, versie 8.0.3 uit juni 2026 bevat de fix. De huidige versie is 8.1.0 |
Hoe kan de kwetsbaarheid misbruikt worden?
Volgens The Hacker News telt de sessieverwerking van AnyDesk een lengte uit het binnenkomende pakket bij een vaste header op, zonder te controleren of die som overloopt. Een opgegeven lengte van bijna de maximale waarde levert daardoor een piepkleine geheugentoewijzing op, waarna al één byte aan data aangrenzende objecten in het geheugen beschadigt. Via een zogeheten ROP-keten wordt daarna een commando als root uitgevoerd. De exploit werkt via een directe TCP-verbinding op poort 7070 en is kansgebaseerd: bij een mislukte poging crasht de dienst. De onderzoekers stellen dat de verbinding via relayservers dezelfde codepad raakt, maar hebben dat niet volledig aangetoond. Het lek is gevonden door Rick de Jager van het V12-beveiligingsteam met een code review-engine. AnyDesk erkende het in juni, de fix werd destijds alleen als crashfix omschreven en een formeel beveiligingsbericht is er nog niet.
Wat kan het gevolg zijn?
Een remote-toegangstool die als root te kraken valt zonder inloggegevens, is een aantrekkelijk doelwit, zeker nu de exploit vrij beschikbaar is. AnyDesk zelf stelt dat het probleem beperkt is tot directe verbindingen op Linux. Voor MSP’s met Linux-servers of -werkplekken waarop AnyDesk draait, zeker als poort 7070 bereikbaar is vanaf het internet of vanuit een minder vertrouwd netwerk, is dat de situatie waarin een aanval het eenvoudigst wordt. Omdat de fix al maanden beschikbaar is, gaat het vooral om machines die nooit zijn bijgewerkt.
Wat moeten IT-beheerders nu doen?
Breng alle Linux-systemen met AnyDesk in kaart en werk ze bij naar minimaal 8.0.3, bij voorkeur naar de actuele versie. Kan dat niet direct, beperk dan de toegang tot TCP-poort 7070 tot vertrouwde adressen. Schakel directe verbindingen uit waar die niet nodig zijn en controleer of onverwachte AnyDesk-processen, crashes van de dienst of nieuwe rootprocessen zijn te zien op machines die vanaf buiten bereikbaar zijn.
Cisco repareert vijf kritieke fouten in Nexus-switches en vier in Smart Software Manager
| Kwetsbaarheid | Vijf fouten in de validatie van invoer en pakketten in NX-OS, waarmee een ongeauthenticeerde aanvaller code als root kan uitvoeren of de switch kan laten herstarten, in de onderdelen NX-API, NGOAM en MPLS OAM. Daarnaast vier lekken in de licentiebeheertool, waaronder ontbrekende authenticatie en onjuiste controle van cryptografische handtekeningen – Cisco Nexus 3000 en 9000 in standalone-modus (Nexus 7000 en Nexus 9000 in ACI-modus zijn niet getroffen) en Cisco Smart Software Manager |
| CVE-nummer | NX-OS: CVE-2026-76471, CVE-2026-76485, CVE-2026-76486, CVE-2026-76501 en CVE-2026-76465. Smart Software Manager: CVE-2026-76480, CVE-2026-76482, CVE-2026-76483 en CVE-2026-76484 |
| CVSS-score | Smart Software Manager: 10,0, 9,8, 9,1 en 8,8. Voor de NX-OS-lekken is geen score gepubliceerd |
| Actief misbruikt | Nee, Cisco kent geen misbruik of openbare aankondigingen |
| Patch beschikbaar | Ja. Voor NX-OS via de Cisco Software Checker, met tijdelijke Live Protect-beveiliging voor switches die nog niet kunnen upgraden. Smart Software Manager: release 10-202609, zonder workaround |
Wat is er aan de hand?
Cisco publiceerde op 7 oktober een reeks adviezen, die BleepingComputer een dag later samenvatte. De vijf NX-OS-fouten zitten in functies die niet allemaal standaard aanstaan: NX-API is standaard uitgeschakeld, evenals MPLS OAM, en voor sommige lekken moeten bovendien specifieke instellingen zoals SRv6 of NV Overlay actief zijn. Een aanvaller kan via geprepareerde HTTP-verzoeken, IP-pakketten of MPLS-echoverzoeken in het slechtste geval rootrechten krijgen, anders crasht het proces en herstart de switch. Cisco vond alle vijf de fouten zelf bij interne tests.
Wat kan het gevolg zijn?
Nexus-switches vormen de ruggengraat van datacenters. Rootrechten op zo’n apparaat geven een aanvaller inzicht in en invloed op al het verkeer eroverheen, terwijl een herstart die steeds terugkomt voor uitval zorgt. De beheertool voor Smart Software Manager is een ander verhaal: de vier lekken raken elke configuratie en er is geen workaround, terwijl oudere releases onder de naam Smart Software Manager helemaal geen update meer krijgen. Wie die versie draait, moet dus migreren in plaats van patchen.
Wat moeten IT-beheerders nu doen?
Controleer per Nexus 3000- of 9000-switch in standalone-modus of NX-API, NGOAM of MPLS OAM actief zijn en schakel wat niet nodig is uit. Bepaal met de Software Checker welke NX-OS-release nodig is en plan de upgrade, en gebruik tot die tijd de tijdelijke Live Protect-beveiliging. Haal Smart Software Manager naar release 10-202609 of nieuwer en migreer van niet meer ondersteunde releases naar een ondersteunde versie.
Phishing via Microsoft Power BI zet ongemerkt ScreenConnect-clients neer
| Kwetsbaarheid | Misbruik van bestaande functionaliteit: een publiek gedeeld Power BI-dashboard op een vertrouwd Microsoft-domein dient als lokaas, waarna een kwaadwillende ScreenConnect-installatie wordt binnengehaald – Windows-werkplekken van eindgebruikers, Microsoft Power BI en ConnectWise ScreenConnect (legitieme RMM-software) |
| CVE-nummer | Geen, het gaat om misbruik van legitieme diensten |
| Actief misbruikt | Ja, sinds 10 september 2026 gezien bij meerdere incidenten |
| Patch beschikbaar | Niet van toepassing, het is geen softwarefout. Wel zijn er detectie- en beperkende maatregelen |
Hoe wordt dit misbruikt?
Volgens Huntress ontvangt het slachtoffer een phishingmail in Outlook met een link naar een zogenaamd naslagdocument. Dat document is in werkelijkheid een openbaar Power BI-dashboard dat de aanvaller onder een eigen account heeft aangemaakt. Omdat de link naar een legitiem Microsoft-domein wijst, komt de mail makkelijker door filters die dat domein vertrouwen. Het dashboard toont een vervaagd formulier met een knop “Download Reference”. Die knop opent een site van de aanvaller, die de browser, het besturingssysteem, het IP-adres en de locatie van de bezoeker vastlegt en doorstuurt naar een Telegram-bot. Bezoekers die de controle niet doorstaan, worden doorverwezen, wat het onderzoek naar de campagne bemoeilijkt. Alle anderen krijgen na enkele seconden automatisch een kwaadwillend ScreenConnect-installatiebestand aangeboden.
Daarna handelen de aanvallers snel. De eerste ScreenConnect-client zet een PowerShell-script en een tweede client neer en verwijdert zichzelf dan, waarschijnlijk om detectie te ontlopen. Ook is een hulpmiddel gebruikt om de zichtbaarheid van de software te verbergen en draait een geplande taak elke twee minuten een script. Huntress vond bij een terugblik dezelfde client en configuratie op 22 andere endpoints in afzonderlijke incidenten. In één geval greep het SOC in voordat de aanval verder kwam.
Wat kan het gevolg zijn?
Een ScreenConnect-client is een volwaardige toegangspoort: wie hem controleert, kan het scherm meekijken, bestanden overzetten en commando’s uitvoeren. Doordat het om legitieme RMM-software gaat, valt de installatie voor veel beveiligingssoftware niet op, en bij een MSP lijkt het verkeer bovendien op de eigen beheertools. Meerdere RMM-clients naast elkaar maken volledig opruimen lastiger, omdat een achtergebleven client de toegang levend houdt. Voor MSP’s is dit extra gevoelig, omdat een misbruikte werkplek of beheeraccount de stap kan zijn naar andere klantomgevingen.
Wat moeten IT-beheerders nu doen?
Beperk remote-managementsoftware tot goedgekeurde instanties en laat nieuwe of onbekende ScreenConnect-installaties en verbindingen met niet-goedgekeurde instanties een melding geven. Onderzoek endpoints waarop meer dan één RMM-client staat, en kijk naar nieuwe geplande taken of scripts die bij tools voor toegang op afstand horen. Huntress noemt als sporen onder meer de geplande taak SCAutoRepairEvery2Min, het script SCAutoFix.ps1 en het bestand HideUL_x64.exe. Neem links naar downloads op vertrouwde clouddiensten, zoals Power BI, ook mee in de phishingtraining en de meldprocedure voor gebruikers.
Lege envelopeafzender omzeilt de Microsoft 365-blokkade op Direct Send
| Kwetsbaarheid | De Exchange Online-instelling RejectDirectSend controleert het domein van de envelopeafzender, maar heeft niets te toetsen als dat veld leeg is. Daardoor komen mails met een vervalst intern afzenderadres alsnog binnen – Microsoft 365 / Exchange Online met RejectDirectSend ingeschakeld |
| CVE-nummer | Geen, volgens ReliaQuest een beperking in de reikwijdte van de maatregel en geen softwarefout |
| Actief misbruikt | Ja, ReliaQuest onderzocht gevallen tussen september 2025 en augustus 2026 en verwacht dat dit de komende 6 tot 12 maanden doorgaat |
| Patch beschikbaar | Nee, er is geen fix van Microsoft bekend. Wel zijn er configuratiemaatregelen, met name IP-beperkte inkomende connectors |
Hoe wordt dit misbruikt?
Direct Send is bedoeld voor printers, scanners en applicaties die zonder authenticatie mail naar ontvangers binnen dezelfde Microsoft 365-omgeving sturen. Aanvallers gebruiken dat om phishing te versturen die lijkt te komen van een collega of de interne helpdesk. RejectDirectSend moet dat tegenhouden door te kijken naar het domein van de envelopeafzender. Volgens ReliaQuest hoeft een aanvaller dat veld alleen leeg te laten (een zogeheten null reverse path). Zonder domein slaat de controle niet aan, terwijl de zichtbare afzender in het From-veld gewoon een intern adres blijft. In de test van ReliaQuest werd hetzelfde bericht met een afzender uit het eigen domein geweigerd, terwijl de variant met lege afzender werd geaccepteerd.
Wel kan zo’n bericht in de map met ongewenste e-mail belanden. In de test kreeg het een hoge spamscore, maar andere berichten bereikten wel de inbox, onder meer doordat een vervalst adres op een lijst met toegestane afzenders stond. SC Media meldt dat 40 procent van de onderzochte mails bij senior leiders terechtkwam, gevolgd door managers en verkoopmedewerkers. De lokazen waren onder meer notificaties over gedeelde bestanden, betaalverzoeken, uitnodigingen voor inkoopprocedures en SVG-bijlagen die voor voicemailberichten doorgaan. ReliaQuest wijst erop dat lege afzenders ook legitiem voorkomen, bijvoorbeeld bij ontvangstmeldingen, waardoor ze niet zomaar volledig te blokkeren zijn.
Wat kan het gevolg zijn?
Een bericht dat van binnenuit lijkt te komen, wekt veel meer vertrouwen dan een mail van een onbekend adres. Dat maakt de aanval geschikt voor betaalfraude, het stelen van inloggegevens via valse bestandsnotificaties en het verspreiden van malware. De aanvaller heeft er geen account, lookalike-domein of eigen infrastructuur voor nodig, wat de drempel laag houdt. Omdat de blokkade alleen op de envelopeafzender let, kan een omgeving die RejectDirectSend heeft ingeschakeld ten onrechte denken dat het risico is afgedekt.
Wat moeten IT-beheerders nu doen?
Houd RejectDirectSend ingeschakeld, maar beschouw het risico daarmee niet als gesloten. Richt IP-beperkte inkomende connectors in, zodat alleen goedgekeurde apparaten en applicaties intern mogen mailen; in de test van ReliaQuest blokkeerde dat alle pogingen met een lege afzender. Controleer ook de uitzonderingen in het mailfilter, zoals toegestane afzenders en domeinen, de Tenant Allow/Block List, mailflowregels die de spamscore aanpassen en veilige afzenderlijsten van gebruikers, en haal weg wat niet te rechtvaardigen is, vooral voor directie en management. Zoek in de logging naar berichten met een lege envelopeafzender in combinatie met een intern From-adres in een geaccepteerd domein, en let op berichten die SPF, DKIM of DMARC niet doorstaan maar toch zijn afgeleverd.
