Direct naar de inhoud
AI-agenten security

AI in bankaanvallen en PoeLLM: wat je moet weten

AI in bankaanvallen

AI in bankaanvallen staat weer nadrukkelijk op de kaart. In Zuid-Korea onderzoekt men cyberincidenten bij banken, terwijl andere meldingen laten zien hoe aanvallers ondertussen hun infrastructuur uitbreiden met malware die via open-source omgevingen werkt. Voeg daar supply chain-acties op GitHub aan toe, plus klassieke datadiefstalroutes zoals credential stuffing, en het plaatje wordt duidelijk: aanvallen worden veelzijdiger en sneller.

In dit artikel zetten we de belangrijkste ontwikkelingen op een rij, zodat je kunt inschatten welke risico’s relevant zijn voor je eigen omgeving—van ontwikkelplatformen tot operationele systemen.

AI in bankaanvallen: aanwijzingen uit Zuid-Korea

Volgens uitspraken van de Zuid-Koreaanse president zijn er signalen dat AI mogelijk is gebruikt bij recente hacks van banken. Deze aanvallen leidden volgens de berichten tot blootstelling van persoonsgegevens van klanten. De autoriteiten hebben nog niet publiek gemaakt welke AI-tools precies zijn ingezet, en hoe groot de impact is geweest.

Wat de berichtgeving extra interessant maakt, is dat securityonderzoekers in de aanvalsinfrastructuur aanwijzingen hebben gevonden die passen bij het gebruik van generatieve AI-werkstromen. Er werd bijvoorbeeld melding gemaakt van session histories, configuratiebestanden en geheugengegevens die gekoppeld zijn aan AI-achtige tooling. Op basis daarvan vermoedt een onderzoeksbureau met “matige” zekerheid dat een financieel gemotiveerde actor—met Chinese taalkennis—achter de aanvallen zou kunnen zitten.

Wat betekent dit praktisch voor organisaties?

Zelfs als het om “aanwijzingen” gaat en niet om een volledig bewezen technologisch recept, is de les helder. Controleer waar AI-activiteiten in jouw keten kunnen landen: van test- en ontwikkelomgevingen tot tooling die wordt gebruikt voor troubleshooting, documentatie of het opstellen van scripts. Denk ook aan toegangsbeheer rond werkstations en omgevingen waar logs, configuraties en werkbestanden samenkomen.

PoeLLM: malware die een GitHub-gedicht gebruikt voor C&C

Naast de bankfocus is er een duidelijke malware-ontwikkeling: PoeLLM. Een beschrijving van deze dreiging geeft aan dat de malware actief is sinds ten minste april 2026. Het richt zich op blootgestelde AI- en open-source services en zou worden ingezet om cryptovaluta te minen én om een botnet verder uit te bouwen.

Wat PoeLLM onderscheidt, is de manier waarop de command-and-control (C&C) werking wordt bepaald. Geïnfecteerde systemen halen vier trefwoorden uit een gedicht dat op GitHub staat. Die woorden worden vervolgens omgezet naar het IP-adres van de actuele C&C-server. Daardoor kan de beheerder de C&C wisselen door het gedicht aan te passen, zonder dat er direct een klassieke malware-update nodig is.

Verder wordt in de beschrijving vermeld dat het gedicht meerdere keren is bijgewerkt (elf maal), wat kan wijzen op een iteratief beheer van de infrastructuur. Ook wordt genoemd dat de beheerder mogelijk Italiaanssprekend is, op basis van taalcontext rond de gebruikte content.

Kwetsbaarheid in de keten: blootgestelde services

Het risico zit niet alleen in de malware zelf, maar vooral in het feit dat doelwitten online beschikbaar zijn. Organisaties die AI-omgevingen of open-source componenten draaien (bijvoorbeeld tools voor agentische workflows, hosting of modellen) moeten daarom nagaan welke endpoints echt publiek nodig zijn.

Als je wilt zien hoe dit soort “exposed” infrastructuur zich vertaalt naar aanvalstechnieken, sluit ook ons stuk over pre-baked firmware malware aan op het bredere thema van misbruik van supply- en runtime-voorverpakte omgevingen. De context is anders, maar de onderliggende fout—onvoldoende afscherming—komt terug.

GhostAction breidt geheimdiefstal uit naar honderden GitHub-repos

Een andere opvallende ontwikkeling is GhostAction, een supply chain-campagne die zich richt op het stelen van secrets. GitGuardian rapporteert dat een workflow met een geheim-diefstalfunctie is doorgeduwd naar 772 publieke GitHub-repositories in een periode van ongeveer een maand (van eind augustus tot eind september). Die repos horen bij 373 gebruikers of organisaties.

De campagne zou op zoek zijn gegaan naar circa 2.577 verschillende secrets. Denk hierbij aan SSH-sleutels en credentials voor cloudomgevingen en databases (zoals waarden gerelateerd aan Azure, AWS en database-accounts). Opvallend is dat de aanvallers, naast een nieuwe exfiltration server, een eerder gebruikt playbook zouden hebben hergebruikt.

Belangrijk voor de interpretatie: volgens de aangeleverde data lijkt de campagne niet “echt” gestopt, maar eerder doorgegaan of opnieuw opgedoken.

Waarom dit doorwerkt in real life

Secret theft werkt vaak als een domino-effect. Zodra sleutels of tokens in handen zijn van aanvallers, kunnen ze zich later toegang verschaffen tot registries, cloud resources of interne systemen. Bovendien kan het exfiltreren van credentials samengaan met latere payloads, zonder dat je organisatie direct doorheeft dat het eerste signaal op GitHub is ontstaan.

Domino’s reset accounts na credential stuffing

Niet elk incident is supply chain of AI-gedreven. Domino’s meldde een beperkte groep klanten dat hun accounts zijn benaderd door een onbevoegde derde via credential stuffing. Daarbij gebruiken aanvallers e-mail- en wachtwoordcombinaties die uit eerdere, losstaande datalekken afkomstig zijn.

Domino’s stelt dat de eigen systemen niet zijn gecompromitteerd en dat er geen betaalgegevens worden opgeslagen. Wat er wel is gebeurd: de getroffen accounts zijn opnieuw ingesteld met nieuwe toegang. Dat wijst erop dat de nadruk lag op het beperken van de gevolgen voor gebruikers, ook al is de bron van de gelekte combinaties elders ontstaan.

Wat je hiervan kunt meenemen

Credential stuffing reduceer je niet alleen met “goede wachtwoorden”. Denk aan rate limiting, detectie van loginpatronen, en het afdwingen van extra authenticatiestappen waar dat kan. Door gebruikerssessies en wachtwoordbeleid te koppelen aan risicosignalen voorkom je dat gelekte combinaties automatisch veranderen in toegang.

CISA houdt cyber-retention programma voorlopig door

Op beleidsniveau is er ook nieuws. CISA houdt het Cybersecurity Retention Incentive-programma voorlopig in stand tot en met fiscaal 2027. Het programma kan oplopen tot maximaal 25% van het basissalaris, maar er komen strakkere criteria.

Zo moeten medewerkers onder nieuwe voorwaarden minimaal een beoordeling hebben van “exceeds expectations” en ten minste 51% van hun tijd besteden aan cybergerelateerde werkzaamheden binnen een van drie functiereeksen. Buiten die reeksen kunnen mensen mogelijk een aanvraag doen als ze 75% of meer van hun tijd in cybertaken stoppen, waarna een beoordelingscommissie meekijkt.

Deze aanpassing is het gevolg van bevindingen dat het programma eerder mogelijk te breed en niet voldoende doelgericht werd toegepast.

OT cybersecurity: voorstel voor CISA-richtlijn (alleen voor federal OT)

Daarnaast is er een voorstel vanuit de Operational Technology Cybersecurity Coalition (OTCC) voor een CISA BOD die uitsluitend gericht is op operationele technologie (OT) bij federale civiele instanties. Die instanties zouden afhankelijk zijn van duizenden faciliteiten die vallen onder beheer van de GSA, met technische systemen zoals HVAC, stroombeheer, toegangscontrole en gebouwgebonden automatisering.

In de voorgestelde richtlijn wil men onder andere dat agentschappen een senior verantwoordelijke aanwijzen voor OT-security, bestaande relevante eisen toepassen en prioriteit geven aan CISA’s Cybersecurity Performance Goals.

Waarom OT nu belangrijker wordt

OT-omgevingen hebben vaak een andere ritmiek dan IT. Lifecycle, change windows en legacycomponenten zorgen ervoor dat patching en monitoring uitdagender zijn. Juist daarom kan een duidelijke verantwoordelijke rol—en een vertaling van performance goals naar OT—helpen om versnippering te verminderen.

Exposed monitoring tools: Nvidia DCGM Exporter en datalek-achtig dataverlies

Tot slot is er melding van een kwetsbaarheid in een GPU-monitoringtool: Nvidia DCGM Exporter. Onderzoekers beschrijven een hoog-severity issue waarbij aanvallers zonder authenticatie endpoints kunnen overspoelen met requests. Dat kan leiden tot resource-uitputting en zelfs een crash van de service, met mogelijke impact op AI-workloads die op dezelfde host draaien.

Bovendien rapporteerden onderzoekers dat zij in internet-scans tussen maart en mei 2026 ongeveer 2.100 hosts zagen die de exporter on-authenticated exposure boden. Daarmee werden telemetry-gegevens van meer dan 12.000 GPU’s mogelijk gelekt.

Nvidia zou de kwetsbaarheid hebben verholpen, met advies om te upgraden naar versie 4.8.2 of later. Voor organisaties betekent dit in de praktijk: controleer niet alleen of je kwetsbaar bent, maar ook of je monitoringcomponenten überhaupt publiek toegankelijk zijn.

Conclusie: van AI-aanwijzingen tot supply chain en blootgestelde endpoints

De rode draad in al deze meldingen is dat aanvallers technieken combineren en zich aanpassen. De berichtgeving rond AI in bankaanvallen laat zien dat AI kan worden ingezet in de aanvalsketen of in ondersteunende workflows. PoeLLM toont vervolgens hoe malware zich dynamisch kan laten sturen via content op GitHub. GhostAction benadrukt hoe snel secrets via CI/CD en GitHub Actions kunnen worden misbruikt, terwijl credential stuffing bewijst dat “klassieke” toegang nog altijd effectief kan zijn als detectie en bescherming tekortschieten.

Wil je je risico verkleinen? Focus dan op drie pijlers: beperk publieke exposure van AI- en monitoringservices, maak je supply chain en secretsbeheer strak, en versterk authenticatie en detectie tegen hergebruik van gelekte inloggegevens.

Bron: https://www.securityweek.com/in-other-news-ai-used-in-korean-bank-breaches-poem-guided-botnet-empire-admin-gets-40-years/