Een AI-agent ging in één door Microsoft waargenomen keten in vijf minuten van het zoeken naar GitHub-geheimen tot het buitmaken van Azure Key Vault-data, meldt Microsoft Threat Intelligence.
Als een app-secret in code belandt, verdwijnt de blootstelling niet wanneer een ontwikkelaar alleen de regel verwijdert. De credential blijft geldig totdat iemand die intrekt of roteert. Krijgt de bijbehorende applicatie toegang tot cloudresources, dan kan het lek gevolgen hebben buiten de repository.
De GitHub-scan loopt door naar cloudaccounts
Microsoft zegt sinds augustus 2026 agentische tooling te zien die grote aantallen zoekopdrachten uitvoert op openbare GitHub-repositories. Sommige zoekopdrachten combineerden een organisatienaam met termen voor geheimen, cloudservices of een aanbieder van AI-diensten. ARTEX kan gevonden waarden analyseren en vervolgacties uitvoeren, waardoor er minder handmatige stappen nodig zijn.
Microsoft beschrijft naast de GitHub-zoektochten ook misbruik van geldige applicatiegegevens. Vanaf 28 oktober zag het bedrijf succesvolle aanmeldingen van service principals bij meerdere getroffen organisaties, met uiteenlopende applicatie-ID's. In sommige gevallen was een credential van een multi-tenantapplicatie bij de leverancier zelf gecompromitteerd en daarna gebruikt om toegang te krijgen tot klanttenants. Met die toegang bracht de aanvaller Azure-abonnementen, resourcegroepen, rechten en AI-modelimplementaties in kaart. Microsoft zag ook gegevens uit Key Vaults en opslagaccounts weglekken, naast toegang tot SharePoint, OneDrive en mailboxitems.
Een service principal is de identiteit waarmee een applicatie zelfstandig op Microsoft-diensten kan inloggen. De bevoegdheden van die identiteit bepalen welke resources en handelingen bereikbaar zijn. De publicatie beschrijft zowel de GitHub-scan als vervolgactiviteit via applicatiegegevens, maar zegt niet dat elke waargenomen aanmelding begon met een GitHub-secret.
In een Azure-interactie paste de agent zijn aanpak aan nadat een verzoek mislukte. Een reeks verzoeken om Key Vault-metadata op te vragen kreeg eerst een HTTP 400-fout. De eerste reeks gebruikte een versie van de Key Vault-data-API tegen Azure Resource Manager, de Azure-beheerinterface. Ongeveer 28 seconden later werden dezelfde vault-resourcepaden opnieuw bevraagd met de ARM API-versie 2023-07-01. Die aanvragen kregen HTTP 200 terug.

ARTEX duikt op in verschillende operaties
ARTEX is eerder gebruikt bij andere aanvallen, maar de meldingen beschrijven afzonderlijke operaties. Bij de ConnectWise-inbraak meldde Microsoft dat Storm-0940 ARTEX gebruikte om aanmeldpogingen bij meer dan 2.250 Microsoft 365-tenants te versnellen. Dat waren pogingen, geen 2.250 bevestigde inbraken. Microsoft zag app-aanmeldingen en Graph-activiteit in meerdere ConnectWise-omgevingen, maar publiceerde geen bevestigde telling van buitgemaakte klantdata. De nieuwe GitHub-naar-Key-Vault-keten is een andere waarneming en Microsoft noemt hier geen actor.
VAPOR PANDA zette ARTEX in elf dagen in tegen ruim 200 organisaties in minstens veertien landen, maar CrowdStrike bevestigde toegang bij negen organisaties. Dat hetzelfde raamwerk in meerdere onderzoeken opduikt, verbindt de gebeurtenissen niet aan dezelfde aanvaller.
De gedeelde IP is geen volledige toeschrijving
Microsoft verwijst naar een onderzoek van Todyl naar vergelijkbaar misbruik van applicatiegegevens vanaf 1 november. Todyl rapporteerde dat ongeveer 45 appregistraties bij achttien organisaties doelwit waren en de aanvaller via die apps 27 organisaties bereikte, waaronder klanten van MSP's. Meer dan 33 van de registraties hadden succesvol ingelogd. Todyl noemt AI-ondersteuning mogelijk, maar geeft die verklaring lage zekerheid: het onderzoek zag geautomatiseerde aanmeldingen, niet een model dat de aanval aanstuurde.
De rapporten noemen hetzelfde IP-adres, 199.19.77.84. Dat is een raakvlak in de infrastructuur, geen bewijs dat alle activiteit bij één campagne of actor hoort. Ook Homeland411 noemt het vijfminutencijfer en verwijst voor die keten rechtstreeks naar Microsofts onderzoeksbulletin. De publicatie levert dus geen onafhankelijke meting van het tijdsbestek.
Een verwijderde regel trekt de sleutel niet in
Microsoft adviseert organisaties hun eigen code op geheimen te scannen en GitHubs openbare monitoring aan te zetten. Die monitoring kan ook geheimen signaleren die in openbare repositories van anderen verschijnen. Voor Azure DevOps noemt Microsoft het scannen op geheimen en push protection, die ondersteunde secrets vóór publicatie kan tegenhouden. Daarvoor is GitHub Advanced Security for Azure DevOps of de aparte dienst GitHub Secret Protection for Azure DevOps nodig.
Wie een openbaar gemaakt geheim vindt, moet de credential intrekken of roteren en onderzoeken waar die is gebruikt. Alleen de regel uit de repository verwijderen is onvoldoende: kopieën kunnen in versiegeschiedenis, caches en andere systemen blijven staan, terwijl de sleutel geldig blijft. Controleer daarom ook aanmeldingen van service principals, toegangslogs van Key Vault en opslag, wijzigingen aan applicaties en Azure DevOps-audits. Microsoft adviseert daarnaast langlevende app-secrets waar mogelijk te vervangen door beheerde identiteiten en de rechten van applicaties te beperken.
De eerdere ARTEX-meldingen laten zien dat dezelfde tooling in afzonderlijke operaties terugkomt, terwijl Todyl geautomatiseerde aanmeldingen niet als bewijs voor een AI-model ziet. Voor organisaties verschuift de controle daarmee van de repository naar de geldigheid en reikwijdte van de applicatie-identiteit achter het secret. Een gelekte sleutel verdwijnt pas uit de aanvalsketen wanneer hij geen toegang meer verleent.
Veelgestelde vragen
AI-agents met duidelijke toegang
Ik denk mee over welke rechten een toepassing nodig heeft, ontwerp de hele aanpak en realiseer de koppelingen en automatisering. Waar het kan, lever ik self-hosted op.
Dit artikel is geproduceerd samen met het Agent Team. Meer over de redactie.
