Hackergruppe hevder å ha stjålet data om FBI-ansatte gjennom PeopleSoft

Den kriminelle gruppen ShinyHunters hevder å ha brutt seg inn i systemer hos FBI ved å utnytte en sårbarhet i Oracle PeopleSoft som verken er offentlig kjent eller rettet. Gruppen sier den fikk kjøre kode på en tjener, tok seg videre inn i infrastruktur FBI selv forvalter i AWS GovCloud, og lastet ned mellom to og tre terabyte. Innholdet skal etter gruppens egen beskrivelse være person- og helseopplysninger om nåværende og tidligere ansatte, og om alle som har søkt jobb i etaten. Under innbruddet skal gruppen også ha kompromittert tjenestene FBI Criminal Justice, HR og Medlink, og etter egne ord flere tjenester. Dataene skal ifølge gruppen komme fra systemer den nådde etter det første innbruddet i PeopleSoft, blant dem FBIs eget AWS GovCloud-miljø, som ble brukt til å lagre opplysninger om ansatte og søkere. Som begrunnelse oppgir gruppen hevn for en FBI-melding om den selv, publisert 15. mai 2026, og den har gitt etaten en uke på å trekke meldingen tilbake før dataene blir lagt ut. Bilder på jobbnettstedet til FBI ble byttet ut 22. september 2026, og jobbportalen apply.fbijobs.gov viste etterpå en melding om vedlikehold.

FBI bekrefter at etaten kjenner påstandene om uautorisert aktivitet mot FBIjobs.gov, og at den gransker saken. Hvor innbruddet skjedde, er ikke fastslått: etaten sier selv at inngangen kan ha vært hos en tredjepart eller i FBIs eget miljø, og at den samarbeider med leverandørene bak portalen. 404 Media, som omtalte saken først, fikk et utdrag fra gruppen. Ifølge Infosecurity Magazine skal utdraget ha inneholdt opplysninger om 5000 FBI-ansatte, blant annet adresser, telefonnumre, fødselsdatoer og i noen tilfeller opplysninger om ektefeller. NBC News skriver at en tidligere FBI-agent bekreftet at ett av dokumentene var ekte. BleepingComputer opplyser at nettstedet ikke har kunnet bekrefte sårbarheten, bevegelsen videre inn i nettverket eller mengden stjålne data, og NBC News skriver at omfanget av påstandene ikke lot seg bekrefte. Infosecurity Magazine skriver derimot at en talsperson for FBI skal ha beskrevet nettopp den kjeden til 404 Media, altså hullet, bevegelsen til AWS GovCloud og de to til tre terabytene, mens FBIs egen uttalelse sier at inngangspunktet ennå ikke er fastslått.

Noe sårbarhetsnummer for det nye hullet finnes ikke. Varselindeksen til Oracle har ikke fått noe nytt sikkerhetsvarsel etter det som gjelder CVE-2026-35273. BleepingComputer har spurt Oracle og Mandiant om det finnes en ny PeopleSoft-sårbarhet, og skriver at saken blir oppdatert hvis svar kommer. CISA har heller ikke noen ny PeopleSoft-oppføring i katalogen over utnyttede sårbarheter. Den eneste oppføringen der er nettopp CVE-2026-35273, som Oracle varslet om 10. juni 2026 og CISA la inn to dager senere med frist 15. juni. Hullet rammer PeopleTools 8.61 og 8.62, sitter i komponenten Updates Environment Management, gir kjøring av kode over HTTP uten pålogging og har fått 9,8 av 10 på alvorlighetsskalaen. Steve Povolny i Exabeam peker på at ShinyHunters utnyttet et hull i nettopp den komponenten mot over 100 virksomheter i mai og juni, de fleste av dem universiteter, og at gruppen etterpå fortalte at det egentlige målet hadde vært en PeopleSoft-tjener hos FBI. Det forsøket mislyktes den gangen, og Povolny omtaler universitetene som tilfeldige offer for et angrep som var rettet mot etaten og ikke nådde fram. Rådene hans til dem som drifter PeopleSoft, er å bekrefte at rettingen for det forrige hullet faktisk er lagt inn, slå av Environment Management Hub eller fjerne PSEMHUB-programmet, fjerne administrasjons- og integrasjonsgrensesnittene i PeopleSoft fra internett, og lete i loggene i stedet for å vente på en deteksjonsregel som ennå ikke finnes. Han peker på uventede POST-kall i tilgangsloggen til WebLogic, ukjente filer i PSEMHUB-katalogene og utgående trafikk på port 445, og på at loggene bør lagres utenfor tjeneren, siden angriperne selv sier at de fjerner spor lokalt.

Hva det betyr for deg som drifter PeopleSoft

Har du PeopleSoft i produksjon, er det to ting du ikke bør vente på. Det ene er en bekreftelse fra FBI, som kommer når granskningen er ferdig og ikke når du trenger den. Det andre er et sårbarhetsnummer, for gruppen sier selv at den nå bruker det samme hullet mot store selskaper. Vår vurdering er at miljøet ditt bør behandles som utsatt allerede nå, uansett om påstanden om FBI holder vann. Det avgjørende er ikke hvem som ble rammet denne uken. Povolny oppgir at et hull i den samme oppdateringskomponenten ble utnyttet mot over 100 virksomheter i mai og juni, og vi mener det tallet sier mer om hvor eksponert komponenten er enn noen enkelt hendelse gjør.

Så er det spørsmålet om hva et personalsystem egentlig rommer. Povolny beskriver dette som systematisk jakt på virksomhetsplattformer med personal-, lønns-, søker- og helseopplysninger, og den beskrivelsen passer på et ganske vanlig PeopleSoft-oppsett. Ansatte og jobbsøkere har ikke valgt å ligge der, og de kan ikke bytte leverandør. Går det galt hos deg, er dette derfor ikke bare en driftssak: det er en personvernhendelse med frister, varslingsplikt og mennesker som må få beskjed. Legg også merke til at FBI selv holder åpent for at inngangen var hos en tredjepart. Har du satt bort drift eller integrasjoner rundt personalsystemet, må du stille det samme spørsmålet til leverandøren som til deg selv.

Berigo anbefaler

• Kartlegg hvilke opplysninger personalsystemet faktisk inneholder om ansatte og jobbsøkere, og hvor lenge søkerdata blir liggende etter at stillingen er besatt.
• Ta personalsystemet inn i den ordinære sårbarhetsoppfølgingen, og krev skriftlig svar på hvilken versjon som kjører, når den sist ble oppdatert og hvilke grensesnitt som er åpne utenfra.
• Still de samme spørsmålene til leverandøren som drifter eller integrerer mot systemet: hvem kan logge inn på tjeneren, hvordan blir du varslet, og hvor raskt får du svar utenfor arbeidstiden.
• Bestem nå hvem som snakker med de ansatte hvis noen påstår offentlig at personaldata fra dere er stjålet. Finn samtidig ut hvilke frister personvernregelverket setter for varsling.
• Øv på en hendelse der påstanden kommer først og bekreftelsen sent, slik at beslutningen om å koble fra, stenge tilganger og bytte nøkler, passord og tokener ikke venter på et sårbarhetsnummer.