Er min mail hacket? Tegnene og de første skridt for jeres firmamail

En hacket firmamail er sjældent støjende. Angriberen vil ikke opdages, for værdien ligger i at kunne læse med. Microsoft kalder det Business Email Compromise og beskriver det som en af de mest udbredte angrebstyper: angriberen bruger den overtagne postkasse til at skrive til modtagere både i og uden for virksomheden, typisk med en ændret betalingsoplysning eller en falsk faktura.

Microsoft og Google lister tegn, der ligner hinanden meget:

Ofte er det første tegn en kunde eller leverandør, der ringer og spørger til en mail om nye bankoplysninger. Bag det ligger typisk en indbakkeregel, der flytter svar om fakturaer og betalinger til en mappe, ingen kigger i, så I ikke opdager, at kunderne skriver tilbage.

Microsoft har beskrevet præcis det mønster i en kampagne, der siden september 2021 havde været rettet mod over 10.000 organisationer: angriberen oprettede en regel, der flyttede alle mails fra den kunde, der skulle snydes, til mappen Arkiv og markerede dem som læst. Derefter svarede angriberen i en eksisterende betalingstråd, slettede sine egne svar fra Sendt og Slettet og tjekkede hvert par timer, om kunden havde svaret. Ifølge Microsoft gik der i nogle tilfælde kun fem minutter fra adgangen blev stjålet, til betalingssvindlen gik i gang.

Mange sager starter med "men vi har jo MFA". Der er tre almindelige grunde til, at det ikke var nok.

1. Stjålet sessionscookie (AiTM). Ved phishing med mellemmand er den falske loginside en proxy, der sender alt videre til den rigtige Microsoft- eller Google-side. Brugeren logger ind og godkender MFA på den rigtige tjeneste, men gennem angriberens server, som gemmer sessionscookien undervejs. Microsoft skriver, at det ikke er en sårbarhed i MFA: cookien autentificerer angriberen, uanset hvordan brugeren loggede ind, og i flere af sagerne havde cookien allerede en MFA-markering.

2. Ældre protokoller uden MFA. IMAP, POP, SMTP AUTH og Exchange ActiveSync med grundlæggende godkendelse spørger kun om brugernavn og adgangskode. Microsoft skriver, at over 97 procent af angreb med lækkede adgangskoder og over 99 procent af password spray-angreb bruger ældre godkendelse. Har kontoen stadig sådan en adgang åben, er MFA på weblogin ligegyldig.

3. En app med samtykke. Har brugeren givet en app lov til at læse mail, har appen sit eget token. Det overlever et skift af adgangskode og kræver ingen MFA, før det tilbagekaldes.

Hvad der faktisk hjælper, afhænger af metoden:

Det er også derfor, rækkefølgen i oprydningen betyder noget: at skifte adgangskode stopper ikke en stjålet cookie, et app-token eller en åben IMAP-adgang. Sessionerne skal tilbagekaldes, og apps og protokoller skal lukkes hver for sig.

Mange søger på "mail fra mig selv" efter at have fået en mail, hvor afsenderen er deres egen adresse. Det betyder ikke nødvendigvis, at mailen er hacket.

E-mail er bygget sådan, at afsenderadressen, I ser i mailprogrammet, ikke bliver kontrolleret i sig selv. Microsoft forklarer, at en mail har to afsendere: den tekniske afsender, der bruges mellem serverne (5321.MailFrom, også kaldet envelope sender eller Return-Path), og den viste Fra-adresse (5322.From). En svindler kan skrive en hvilken som helst Fra-adresse, også jeres egen. Det kaldes spoofing og er almindeligt i afpresningsmails, der påstår, at "vi har adgang til din konto".

Svaret står i mailens header. I Outlook finder I den under Filer → Egenskaber → Internetheadere, og i Gmail under Mere → Vis original ved siden af Svar. En forfalsket mail fra jeres egen adresse kan se sådan ud:

Return-Path: <bounce@afsender.eksempel.net>
From: Jens Hansen <jens@webshop.dk>
Reply-To: <betaling@eksempel.net>
Authentication-Results: spf=pass (sender IP is 203.0.113.25)
 smtp.mailfrom=afsender.eksempel.net; dkim=none (message not signed)
 header.d=none;dmarc=fail action=oreject header.from=webshop.dk;
 compauth=fail reason=000
X-Forefront-Antispam-Report: CIP:203.0.113.25;CTRY:;LANG:da;SCL:5;...

Her er, hvad linjerne betyder:

Mekanismen er det, DMARC kalder alignment: det er ikke nok, at SPF eller DKIM består. Domænet, der bestod, skal også passe med domænet i From. Det er netop det, en svindler ikke kan få til at passe uden adgang til jeres DNS eller jeres mailkonto.

Sådan skelner I mellem de to:

Spoofing af jeres domæne bremses med SPF, DKIM og DMARC. Microsoft skriver, at de tre standarder arbejder sammen, og at alt mindre end dem alle giver en ringere beskyttelse. I kan selv se, hvad jeres domæne har sat op, med dig:

dig +short TXT webshop.dk | grep "v=spf1"
dig +short TXT _dmarc.webshop.dk
# DKIM i Microsoft 365 (to CNAME-poster)
dig +short CNAME selector1._domainkey.webshop.dk
dig +short CNAME selector2._domainkey.webshop.dk
# DKIM i Google Workspace (standardvælger "google")
dig +short TXT google._domainkey.webshop.dk

Et domæne, der kun sender via Microsoft 365, og som har en DMARC-politik, der afviser forfalskninger, ser typisk sådan ud:

webshop.dk.         TXT  "v=spf1 include:spf.protection.outlook.com -all"
_dmarc.webshop.dk.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@webshop.dk"

Start ikke direkte på p=reject, hvis I ikke kender alle de tjenester, der sender mail i jeres navn, fx webshoppens ordremails, nyhedsbrevet og bogføringssystemet. Start med p=none og rua-rapporter, så I kan se, hvem der sender, og stram derefter. Videresendelse er den klassiske fælde: når en mail videresendes, sender en ny server den, og så består SPF ikke længere for det oprindelige domæne. DKIM-signaturen følger derimod med, så længe indholdet ikke ændres, og derfor skal alle afsendere signere med DKIM, før I går til p=reject. Læs mere om mail- og DNS-sikkerhed.

Er I i tvivl, så behandl det som en hacket postkasse og gennemgå trinene herunder. Det koster en halv time, hvis det viser sig at være spoofing.

Rækkefølgen er vigtig. Hvis I skifter adgangskode, før angriberen er logget ud, og før videresendelsen er fjernet, fortsætter angrebet stille. Microsoft beskriver, at angribere bevidst efterlader måder at komme tilbage på, og at hvert trin skal gennemføres.

1. Rens enheden. Microsoft anbefaler at køre en fuld virusscanning, før adgangskoden skiftes. Ellers kan en keylogger opsnappe den nye.
2. Bloker eller nulstil kontoen. I en virksomhed er det administratoren, der gør det. Send aldrig den nye adgangskode til den hackede postkasse.
3. Log ud af alle sessioner. En stjålet session virker videre, selvom adgangskoden er skiftet.
4. Fjern ukendte MFA-metoder og enheder. Angribere tilføjer ofte deres egen godkendelsesapp eller telefon.
5. Dokumentér, og fjern derefter videresendelser, regler og delegeringer. Tjek både postkassens videresendelse og indbakkeregler, og gem en kopi af reglerne, før I sletter dem.
6. Fjern apps med adgang. En app, der har fået lov til at læse mail, bliver ved med at have adgang, selvom adgangskoden skiftes.
7. Slå MFA til, eller stram den. Helst med adgangsnøgler eller sikkerhedsnøgler, og bloker ældre protokoller.
8. Gennemgå loggene. Find ud af, hvornår det startede, hvad der er læst, og hvem der har fået mails.
9. Advar dem, der kan være ramt. Kunder, leverandører og kolleger.

Er det en personlig Outlook.com- eller Gmail-konto, gør I det samme, men selv. Microsofts egen vejledning til hackede konti peger på en login-hjælper, nulstilling af adgangskode og en gendannelsesformular, hvis I ikke kan logge på. Google peger på accounts.google.com/signin/recovery.

I Microsoft 365 er det en administrator, der gør arbejdet. Microsoft har en vejledning til netop kompromitterede postkasser, og den følger denne rækkefølge. Microsoft anbefaler helst at deaktivere kontoen, mens undersøgelsen står på, og ellers at nulstille adgangskoden.

Nulstil og log ud. I Microsoft 365 Administration (admin.cloud.microsoft) går I til Users → Active users (Brugere → Aktive brugere), vælger brugeren og vælger Reset password (Nulstil adgangskode). Vælg derefter brugeren igen og vælg Sign out of all sessions (Log ud af alle sessioner) under fanen Account. Microsoft skriver, at brugeren bliver bedt om at logge ind igen inden for en time. Blokering af login kan ifølge Microsoft tage op til 24 timer at slå igennem, så nulstil adgangskoden for at stoppe adgangen med det samme.

Med Microsoft Graph PowerShell gøres det samme sådan. Revoke-MgUserSignInSession ugyldiggør alle refresh-tokens og browserens sessionscookies ved at sætte brugerens signInSessionsValidFromDateTime til nu:

Connect-MgGraph -Scopes "User.ReadWrite.All","User.RevokeSessions.All"
$user = Get-MgUser -Search UserPrincipalName:'jens@webshop.dk' -ConsistencyLevel Eventual
# Deaktivér kontoen under undersøgelsen
Update-MgUser -UserId $user.Id -AccountEnabled:$false
# Tilbagekald refresh-tokens og sessionscookies
Revoke-MgUserSignInSession -UserId $user.Id

Én ting er vigtig at forstå: et access token, der allerede er udstedt, lever som standard en time i Microsoft Entra ID. Tilbagekaldelsen forhindrer nye tokens, men apps, der ikke understøtter Continuous Access Evaluation, kan bruge det udstedte token, til det udløber. Derfor skal adgangskoden også nulstilles, og kontoen bør være deaktiveret, mens I rydder op.

App-adgangskoder. Microsoft fremhæver, at app-adgangskoder ikke tilbagekaldes automatisk, når adgangskoden nulstilles. De skal slettes og laves på ny.

MFA-metoder. Gennemgå brugerens godkendelsesmetoder i Microsoft Entra, og fjern telefoner og apps, I ikke kender.

Apps med samtykke. Under virksomhedsapps i Microsoft Entra kan I se, hvilke apps brugeren har givet adgang, og tilbagekalde dem. Kig især efter apps med tilladelser som Mail.Read, Mail.Send eller offline_access, som brugeren ikke kan forklare.

Administratorroller. Fjern roller, brugeren ikke skal have. Angribere giver sig selv rettigheder, hvis kontoen tillader det.

Videresendelse og regler. I Outlook på nettet og den nye Outlook ligger reglerne under Indstillinger → Mail → Regler. I den klassiske Outlook ligger de under Filer → Administrer regler og beskeder. Skjulte regler vises kun med PowerShell. Forbind til Exchange Online PowerShell, og tjek både postkassens videresendelse og alle regler:

Connect-ExchangeOnline -UserPrincipalName admin@webshop.dk
# Videresendelse på selve postkassen (SMTP-videresendelse)
Get-Mailbox -Identity jens@webshop.dk | Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward
# Alle indbakkeregler, også de skjulte
Get-InboxRule -Mailbox jens@webshop.dk -IncludeHidden | Format-List Name,Enabled,RedirectTo,ForwardTo,ForwardAsAttachmentTo,Description,Identity

Felterne betyder:

Gem reglerne i en fil som dokumentation, og fjern derefter dem, der ikke hører til. Bemærk, at Microsoft skriver, at når en indbakkeregel oprettes, ændres eller fjernes med PowerShell, fjernes Outlooks klientsideregler i postkassen:

Get-InboxRule -Mailbox jens@webshop.dk -IncludeHidden | Format-List * | Out-File regler-jens.txt
Remove-InboxRule -Mailbox jens@webshop.dk -Identity "jens\10210541742734704641"
Set-Mailbox -Identity jens@webshop.dk -ForwardingSmtpAddress $null -ForwardingAddress $null

Logge. Microsoft anbefaler at gennemgå login-loggen i Microsoft Entra, revisionsloggen fra lige før det mistænkelige startede, og Message Trace. Kommandoerne står i afsnittet om loggene herunder.

Til sidst. Er postkassen blevet brugt til at sende spam, kan den være blokeret for at sende. Den skal fjernes fra listen over begrænsede enheder i Defender-portalen.

I Google Workspace er det også administratoren, der skal handle. Googles vejledning til kompromitterede konti starter med at suspendere brugeren midlertidigt. Det nulstiller login-cookies og OAuth-tokens og logger dermed brugeren ud overalt.

Brugerens sikkerhedsindstillinger. I Google Administrationskonsollen går I til Menu → Directory → Users, vælger brugeren og klikker Security. Herfra kan I:

• nulstille Sign-in cookies, så brugeren logges ud. Google skriver, at Gmail-sessioner kan tage op til en time om at slutte
• tilbagekalde Application-specific passwords
• fjerne apps under Connected applications
• rette Recovery information, så gendannelsesmail og telefon er jeres

Undersøg. Google peger på admin-revisionsloggen (hvis brugeren er administrator), brugerens logins de seneste seks måneder, e-mail-logsøgning for at se, hvad der er sendt og modtaget, og log for OAuth, Drive, grupper og kalender. Kig også efter mobile enheder, der har adgang til arbejdsdata, og fjern dem, I ikke kender.

I Administrationskonsollen ligger Gmail-hændelserne under Menu → Reporting → Audit and investigation → Gmail log events. Har I en udgave med sikkerhedsundersøgelsesværktøjet (fx Enterprise Standard eller Plus), kan I også bruge Menu → Security → Security center → Investigation tool og vælge Gmail log events som datakilde. Her kan I filtrere på blandt andet IP-adresse, From (Envelope), From (Header address), Subject og OAuth project ID, og dermed se, om mails er sendt eller læst fra en IP-adresse, I ikke kender.

I Gmail. Brugeren skal gennemgå Indstillinger → Se alle indstillinger. Videresendelse ligger under fanen Videresendelse og POP/IMAP, og filtre under Filtre og blokerede adresser. Google lister disse Gmail-indstillinger som dem, en angriber typisk ændrer: delegering af mail, automatisk videresendelse, planlagte mails, navn, autosvar, afsenderadresse, blokerede adresser, IMAP- eller POP-adgang, filtre og etiketter.

For den enkelte Google-konto. På myaccount.google.com kan brugeren gennemgå seneste sikkerhedshændelser og vælge "Nej, det var ikke mig", se enheder under myaccount.google.com/device-activity og fjerne apps med adgang under myaccount.google.com/permissions.

Genåbn kontoen. Ophæv suspenderingen, giv en midlertidig adgangskode, og kræv totrinsbekræftelse. Google anbefaler sikkerhedsnøgler frem for koder.

Oprydningen stopper angrebet. Loggene fortæller, hvad der skete, og det skal I bruge til at vurdere, hvem der skal advares, og om der er tale om et brud på persondatasikkerheden. Brug et tidsvindue, der starter i god tid før det første mistænkelige tegn.

Login-loggen i Microsoft Entra. I portalen ligger den under Entra ID → Monitoring & health → Sign-in logs. Husk også fanen med ikke-interaktive logins, for det er her, genbrug af tokens ofte ses. Med Graph PowerShell kan I trække én brugers logins ud. Det kræver tilladelsen AuditLog.Read.All, og Microsoft skriver, at download af login-loggen via API kræver en Microsoft Entra ID P1- eller P2-licens:

Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'jens@webshop.dk' and createdDateTime ge 2026-10-01T00:00:00Z" -All |
  Select-Object CreatedDateTime,IpAddress,ClientAppUsed,AppDisplayName,
    @{n='Land';e={$_.Location.CountryOrRegion}},@{n='Fejlkode';e={$_.Status.ErrorCode}} |
  Sort-Object CreatedDateTime | Format-Table -AutoSize

Det, I kigger efter:

Revisionsloggen. Search-UnifiedAuditLog i Exchange Online PowerShell søger i den samlede revisionslog. Microsoft har meldt ud, at de ældre cmdlets Search-MailboxAuditLog og New-MailboxAuditLogSearch udfases, og peger på Search-UnifiedAuditLog i stedet. Datoer er i UTC:

$start = (Get-Date).AddDays(-30).ToUniversalTime()
$end = (Get-Date).ToUniversalTime()
$ops = "New-InboxRule","Set-InboxRule","UpdateInboxRules","Add-MailboxPermission","SendAs"
$r = Search-UnifiedAuditLog -StartDate $start -EndDate $end -UserIds jens@webshop.dk -Operations $ops -SessionCommand ReturnLargeSet -ResultSize 5000
$r | Sort-Object CreationDate | Format-Table CreationDate,Operations,UserIds
# Detaljer for én hændelse, fx reglens indhold og klientens IP
$r[0].AuditData | ConvertFrom-Json | Format-List

Søg også uden filter på Operations i det første tidsvindue. Microsoft anbefaler ikke at filtrere på bestemte aktiviteter i den første søgning, så I ikke overser noget, I ikke vidste, I skulle lede efter.

Sendte mails. Get-MessageTraceV2 viser, hvad postkassen har sendt. Den kan søge 90 dage tilbage, men højst 10 dage pr. søgning, og den returnerer op til 5.000 resultater. Datoformatet følger computerens regionale indstillinger:

Get-MessageTraceV2 -SenderAddress jens@webshop.dk -StartDate "10/12/2026" -EndDate "10/21/2026" -ResultSize 5000 | Format-Table

Bloker ekstern videresendelse fremover. Når oprydningen er færdig, kan I lukke for automatisk videresendelse til eksterne adresser i hele organisationen. Det slår også eksisterende regler og postkassevideresendelser til eksterne adresser fra, og afsenderen får en bounce med koden 5.7.520:

Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode Off

Microsoft anbefaler at vælge On eller Off i stedet for standardværdien Automatic, fordi Automatic opfører sig forskelligt fra organisation til organisation.

Bloker ældre godkendelse. I Microsoft Entra-administration går I til Entra ID → Conditional Access → Policies → New policy, vælger alle brugere (med undtagelse af en nødadgangskonto), alle ressourcer, under Conditions → Client apps kun Exchange ActiveSync clients og Other clients, og Grant → Block access. Microsoft anbefaler at starte i Report-only og slå politikken til, når I har set, hvem den rammer. Uden licens til Conditional Access gør security defaults det samme.

Google Workspace via Reports API. De samme spørgsmål kan stilles til Google. Hændelsen email_forwarding_out_of_domain logges, når en bruger slår videresendelse til en adresse uden for domænet til, og authorize i token-loggen viser, hvilke apps der har fået OAuth-adgang og med hvilke scopes:

# Hvem har slået videresendelse uden for domænet til
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://admin.googleapis.com/admin/reports/v1/activity/users/all/applications/login?eventName=email_forwarding_out_of_domain"
# Hvilke apps brugeren har givet adgang
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://admin.googleapis.com/admin/reports/v1/activity/users/jens@webshop.dk/applications/token?eventName=authorize"

Kig også efter login-hændelserne suspicious_login, login_success med is_suspicious sat til true, og user_signed_out_due_to_suspicious_session_cookie, som Google logger, når en bruger bliver logget ud på grund af en mistænkelig sessionscookie.

Det dyreste ved en hacket firmamail er ofte ikke postkassen. Det er den faktura, en kunde betaler til en forkert konto, fordi mailen kom fra jeres rigtige adresse eller fra en, der ligner. Angriberen har læst med og ved, hvem der skal betale hvad, og hvornår.

Send en advarsel fra en kanal, I ved er ren, så snart I har sikret kontoen. Brug ikke den hackede postkasse, før den er ryddet op. Advarslen skal være kort og konkret:

Vi har haft uautoriseret adgang til en af vores mailkonti. Hvis I har fået en mail fra os om nye bankoplysninger eller en ændret betaling efter den [dato], så betal ikke, men ring til os på vores kendte nummer. Vores bankoplysninger er ikke ændret.

Gør det samme over for jeres leverandører og bed dem bekræfte ændringer i jeres egne betalingsoplysninger telefonisk.

Brug Message Trace eller e-mail-logsøgningen til at lave listen over modtagere, så advarslen går til dem, der faktisk har fået mails i perioden, og ikke kun til de største kunder. Angriberen bruger ofte også et domæne, der ligner jeres, fx med et ekstra bogstav, så bed modtagerne kigge på adressen efter @, og ikke kun på navnet.

Er der allerede betalt til en forkert konto, så kontakt jeres bank med det samme. Jo hurtigere banken får besked, jo større er chancen for at stoppe overførslen. Skriv ned, hvilke mails der er sendt, til hvem og hvornår. Det står i Message Trace i Microsoft 365 og i e-mail-logsøgningen i Google Workspace.

Fremover bør en ændring af bankoplysninger altid bekræftes over telefonen på et nummer, I har i forvejen, aldrig på et nummer fra mailen.

Persondata. En postkasse indeholder næsten altid personoplysninger om kunder, ansatte og leverandører. Har en uvedkommende haft adgang, er det et brud på persondatasikkerheden. Datatilsynet skriver, at bruddet skal anmeldes uden unødig forsinkelse og om muligt inden for 72 timer, medmindre det er usandsynligt, at det medfører en risiko for personers rettigheder. Anmeldelsen sker via Virk.dk. Fristen tæller fra, I blev opmærksomme på bruddet, og den gælder også i weekender. Loggene fra afsnittet ovenfor, især MailItemsAccessed og login-loggen, er jeres grundlag for at beskrive, hvad der er sket, og hvor mange der er berørt. Læs mere om databrud og GDPR.

Politiet. Politiet opfordrer til at anmelde hacking hurtigst muligt, fordi digitale spor ofte bliver overskrevet eller slettet. Virksomheder kan ringe 114 på hverdage kl. 7 til 20 og blive stillet videre til medarbejdere med viden om cyberangreb. Anmeldelse sker via politi.dk.

Cyberhotline. Digitaliseringsstyrelsens Cyberhotline på 33 37 00 37 rådgiver både borgere og virksomheder om digital svindel og angreb. Den har åbent kl. 8 til 20 på hverdage og kl. 10 til 16 i weekender og på helligdage.

Mailudbyderen. Kan I slet ikke komme ind, er det Microsoft eller Google, der skal give adgangen tilbage. I Microsoft 365 og Google Workspace sker det via en anden administrator i virksomheden. Har I kun én administrator, og er det den konto, der er hacket, går vejen gennem udbyderens support.

De samme fejl forlænger de fleste sager:

• Adgangskoden skiftes, men intet andet. Videresendelsen og sessionerne kører videre, og angriberen læser stadig med.
• Kun indbakkereglerne i Outlook tjekkes. Videresendelse kan også ligge på selve postkassen, og nogle regler er skjulte og vises kun med Get-InboxRule -IncludeHidden.
• Apps glemmes. En app med adgang til mail overlever et skift af adgangskode.
• App-adgangskoder glemmes. I Microsoft 365 tilbagekaldes de ikke automatisk.
• Ældre protokoller står åbne. IMAP eller POP med kun adgangskode omgår MFA fuldstændig.
• Den nye adgangskode sendes til den hackede postkasse. Microsoft advarer direkte mod det.
• Kunderne advares ikke. Så er det kunderne, der opdager det, når de har betalt.
• Man sletter beviserne. Slet ikke de falske mails i Sendt eller reglerne, før I har dokumenteret dem. I skal bruge dem til politiet, banken og Datatilsynet.
• MFA via sms på alle konti, også administratorerne. Det er bedre end ingenting, men Microsoft anbefaler phishing-resistent MFA til administratorer, fordi en kode fra sms eller app kan opsnappes af en AiTM-proxy.

Med det samme

• Enheden scannet for malware
• Kontoen deaktiveret eller adgangskoden nulstillet af en administrator
• Brugeren logget ud af alle sessioner (Revoke-MgUserSignInSession eller Sign-in cookies → Reset)
• Ukendte MFA-metoder, enheder og app-adgangskoder fjernet
• Videresendelse på postkassen og alle indbakkeregler gennemgået, også skjulte, og gemt som dokumentation
• Delegeringer og apps med adgang fjernet

Samme dag

• Login- og revisionslog gennemgået fra før det startede, også ikke-interaktive logins
• Sendte mails i perioden fundet via Message Trace eller e-mail-logsøgning
• Kunder og leverandører advaret fra en ren kanal
• Banken kontaktet, hvis der er betalt til en forkert konto
• Vurderet om bruddet skal anmeldes til Datatilsynet inden for 72 timer
• Politianmeldelse overvejet

Bagefter

• MFA krævet for alle, helst adgangsnøgler eller sikkerhedsnøgler
• Ældre godkendelse blokeret
• SPF, DKIM og DMARC sat op for domænet og tjekket med dig
• Ekstern automatisk videresendelse slået fra som standard (AutoForwardingMode Off)
• Mindst to administratorer, som ikke bruges til daglig mail
• Fast regel om at bekræfte nye bankoplysninger over telefonen

Hvordan kan jeg se, om min mail er hacket? Kig efter ukendte logins, regler eller videresendelser, mails i Sendt, I ikke har skrevet, og kontakter, der får mærkelige mails fra jer. I Microsoft 365 og Google Workspace kan administratoren se login-loggen.

Jeg har fået en mail fra mig selv. Er jeg hacket? Ikke nødvendigvis. Ligger mailen ikke i jeres Sendt-mappe, og viser headeren dmarc=fail og en fremmed server i smtp.mailfrom, er afsenderen typisk forfalsket. Det løses med SPF, DKIM og DMARC.

Er det nok at skifte adgangskode? Nej. Sessioner, videresendelser, regler, apps og app-adgangskoder kan alle overleve et skift af adgangskode.

Hvor hurtigt bliver angriberen logget ud? I Microsoft 365 inden for en time efter "Log ud af alle sessioner" ifølge Microsoft. Revoke-MgUserSignInSession tilbagekalder refresh-tokens og sessionscookies med det samme, men et allerede udstedt access token kan leve op til en time, medmindre appen understøtter Continuous Access Evaluation. I Google Workspace kan Gmail-sessioner tage op til en time om at slutte efter nulstilling af login-cookies.

Skal vi anmelde det til Datatilsynet? Hvis der er personoplysninger i postkassen, og det ikke er usandsynligt, at bruddet medfører en risiko for de berørte, skal det anmeldes inden for 72 timer via Virk.dk.

For en webshop er mailen nøglen til resten. Den er login til shopsystemet, betalingsløsningen, Meta, Google Ads, domænet og hostingen. Kan en angriber læse mailen, kan de nulstille adgangskoden til alt det andet. Derfor skal de konti, der administrerer shoppen, have den stærkeste beskyttelse, ikke den svageste. Gennemgå også, om angriberen har bestilt nulstilling af adgangskoder i perioden, for de mails ligger i postkassen og viser, hvilke systemer der skal sikres bagefter.

Den anden risiko er kunderne. En webshop sender ordrebekræftelser, fakturaer og kundeservicesvar hver dag, og kunderne er vant til at stole på mails fra jer. Det gør en overtaget postkasse eller et domæne uden DMARC til et godt værktøj for svindlere. Husk, at webshoppens egne ordremails også skal bestå SPF og DKIM for jeres domæne, før DMARC kan strammes til p=reject.

Er jeres firmamail hacket, hjælper vi med at lukke sessionerne, fjerne videresendelser, regler og apps, gennemgå loggene, slå MFA til og få mailen sikret inden for 24 timer. Læs mere om hjælp til en hacket Microsoft 365-konto og en hacket Google Workspace-konto.

Kilder

• Microsoft: Respond to a compromised email account
• Microsoft: Prevent user sign-in and block access
• Microsoft: Revoke user access in an emergency
• Microsoft: Revoke-MgUserSignInSession
• Microsoft: Get-MgAuditLogSignIn
• Microsoft: signIn resource type
• Microsoft: Connect to Exchange Online PowerShell
• Microsoft: Get-InboxRule
• Microsoft: Remove-InboxRule
• Microsoft: Set-Mailbox
• Microsoft: Search-UnifiedAuditLog
• Microsoft: Audited activities
• Microsoft: Get-MessageTraceV2
• Microsoft: Control external email forwarding
• Microsoft: Set-HostedOutboundSpamFilterPolicy
• Microsoft: Block legacy authentication
• Microsoft: AiTM-phishing og BEC
• Microsoft: Anti-spam message headers
• Microsoft: DKIM i Microsoft 365
• Microsoft: Use inbox rules in Outlook
• Microsoft: Recover a hacked Microsoft account
• Microsoft: How email authentication works
• RFC 7489: DMARC
• Google: Identify and secure compromised accounts
• Google: Manage a user's security settings
• Google: Gmail log events
• Google: Login audit activity events
• Google: OAuth token audit activity events
• Google: Set up DKIM
• Gmail: Trace an email with its full headers
• Google: Secure a hacked Google Account
• Gmail: Automatic forwarding
• Datatilsynet: Anmeld sikkerhedsbrud
• Politiet: Forebyg hacking
• Cyberhotline