APWG registrerte 971 181 phishingangrep bare i første kvartal 2026 — en økning på 13,8 % fra kvartalet før. Og i januar 2026 slo Google til mot det de kalte ett av verdens største nettverk av residential proxyer etter å ha oppdaget at over 550 trusselgrupper sendte trafikk gjennom det i løpet av én uke. Proxyer, viser det seg, befinner seg på begge sider i kampen mot phishing.
Det er denne spenningen de fleste artikler om «proxyer og phishing» overser. De sier enten at proxyer er et skjold (kjøp proxy-produktet vårt, så er du trygg) eller at proxyer er et våpen for angripere (vær redd). Virkeligheten er mer sammensatt — og mer interessant.
Angripere bruker proxy-infrastruktur for å skjule opprinnelsen sin, rotere mellom betrodde IP-adresser og stjele autentiserte økter — selv etter MFA. Forsvarere bruker proxyer til å undersøke mistenkelige lenker trygt, teste hva phishing-sider viser i ulike land, og filtrere ondsinnet trafikk før den når egne nettsider. Denne guiden dekker begge sider, og går deretter gjennom en konkret arbeidsflyt du faktisk kan ta i bruk. Ingen svevende formuleringer, ingen mirakelløsninger.
- Vanskelighetsgrad: Middels
- Tidsbruk: Rundt 25 minutter til lesing og planlegging; gjennomføring varierer per steg
- Du trenger: Grunnleggende forståelse av virksomhetens webinfrastruktur, tilgang til DNS-innstillinger for domenet ditt, en Chrome-nettleser (for Thunderbit-stegene) og eventuelt en konto hos en proxy-leverandør
Hva er phishing, og hvorfor bør virksomheten din bry seg?
Phishing er et bedrageriangrep. Kriminelle bruker e-post, SMS, falske innloggingssider, QR-koder eller forfalskede nettsteder for å lure folk til å gi fra seg innloggingsopplysninger, godkjenne en pålogging, installere skadevare eller overføre penger.
Dette er ikke lenger bare et problem med «dårlige e-poster». Moderne phishing omfatter nettsider hostet i skyen, falske Microsoft 365-innloggingsflyter, QR-koder og tyveri av sesjonstokener.
For virksomheter er konsekvensene svært konkrete. IBMs rapport om kostnaden ved datainnbrudd i 2025 oppgir en global gjennomsnittskostnad på 4,4 millioner USD. FBI sin Internet Crime Report for 2025 sier at IC3 mottok rundt 453 000 klager på nettbasert svindel, med rapporterte tap på over 17,7 milliarder USD, hvor forretnings-e-postkompromittering (BEC) sto for over 3 milliarder av dette.
Tyveri av innloggingsdata, bankoverføringssvindel, kompromittering av leverandørkjeder, bøter fra myndighetene — phishing berører alt dette.
Det som følger: hvordan proxyer passer inn i både angreps- og forsvarsbildet, og hvordan et reelt lagdelt forsvar faktisk ser ut.
Proxyenes doble natur: ditt skjold og deres våpen
En proxy er et mellomledd mellom enheten din og internett. I stedet for at et nettsted ser din virkelige IP-adresse, ser det proxyens adresse. Tenk på det som en postvideresending: mottakeren får brevet fra videresendingsadressen, ikke fra hjemmet ditt.
Den samme egenskapen skaper problemet med dobbel bruk. Sikkerhetsteam bruker proxyer til å undersøke trusler uten å eksponere en bedrifts-IP eller en analysts arbeidsstasjon. Angripere bruker den nøyaktig samme teknologien for å få ondsinnet trafikk til å se ut som om den kommer fra vanlige brukere, andre land eller betrodde bolignettverk. Barracudas analyse fra april 2026 forklarer det enkelt: residential IP-adresser ser autentiske ut fordi de er knyttet til ekte hjemme- eller småbedriftsforbindelser, og derfor er det mindre sannsynlig at svindelsystemer flagger dem.
De fleste konkurrerende artikler dekker bare én side. Det gir leseren et ufullstendig bilde — og ufullstendig beskyttelse.
Hvordan angripere bruker proxyer mot deg
Tre angrepsveier er særlig viktige for virksomheter: anonymitet og IP-rotasjon, misbruk av residential proxyer og omgåelse via betrodde plattformer.
Hva AiTM (Adversary-in-the-Middle) phishing er
AiTM er angrepet som sprenger antagelsen om at «MFA beskytter oss» (spoiler: tradisjonell MFA overlever ikke dette).
I et AiTM-angrep legger angriperen en reverse proxy mellom offeret og en legitim innloggingsside — for eksempel Microsoft 365. Brukeren ser ut til å være i en ekte innloggingsflyt. Vedkommende skriver inn brukernavn og passord, fullfører MFA, og den ekte identitetsleverandøren utsteder en sesjonscookie. Men siden all trafikk går gjennom angriperens proxy, fanger angriperen opp denne cookien. Den kan deretter spilles av på nytt for å få tilgang til kontoen — uten behov for passord eller MFA-prompt.
Microsofts analyse av Tycoon2FA, et av de ledende AiTM-phishing-settene, viser at operatører kan etterligne innloggingssider for Microsoft 365, Outlook, SharePoint, OneDrive og Google. Settet genererer PDF-er og QR-koder, håndterer videresendingskjeder og sporer MFA-bruk og fangst av sesjonscookies. Infrastrukturen bruker kortlevde subdomener og Cloudflare-hostet infrastruktur for å gjøre blokkering vanskelig.
Dette er ikke teori. AiTM-sett brukes aktivt i stor skala, og de er hovedgrunnen til at «vi har MFA» ikke er et fullgodt svar på phishing.
Misbruk av residential proxyer og IP-rotasjon
Residential proxy-nettverk sender angripernes trafikk gjennom ekte hjemmenett-IP-adresser, slik at phishing-forespørsler ser legitime ut og glir forbi IP-basert svindelkontroll. Mange leverandører verifiserer ikke grundig hvordan IP-ene deres brukes, noe som skaper et gråmarked.
Det mest konkrete eksempelet: I januar 2026 slo Google Threat Intelligence Group ut IPIDEA-nettverket av residential proxyer, og reduserte tilgjengelig enhetsmasse med millioner. GTIG observerte over 550 ulike trusselgrupper som brukte IPIDEA-utganger i løpet av en enkelt syvdagersperiode. Etterforskningen fant overlapp med botnett, misbruk av SaaS-tilgang, password spray-angrep og globale spionasjeaktører. Mange av proxy-SDK-utrullingene manglet tydelig brukersamtykke.
FBI sin veiledning fra 2026 om residential proxyer lister phishing, innlogging med stjålne opplysninger, brute force-angrep, kontoovertakelser, spam og skjuling av C2-trafikk som kriminelle bruksområder.
Hosting på betrodde plattformer og omgåelse av phishing-sett
En annen omgåelsesteknikk er å hoste phishing-sider på betrodde plattformer — SharePoint, Google Docs, Azure Blob Storage — for å dra nytte av domenets omdømme. Microsofts analyse av trusler mot Azure Blob Storage viser hvordan angripere bruker dette til å hoste forfalskede Microsoft-påloggingssider, noe som gjør dem vanskeligere for ofrene å oppdage som skadelige bare ut fra sertifikatet.
Phishing-sett bruker også logikk for å unngå oppdagelse. Cofenses analyse av phishing-sett dokumenterer geolokaliseringsfiltrering, filtrering basert på user-agent og språk, CAPTCHA, oppdagelse av utviklerverktøy og videresending til legitime sider. Hvis en besøkende ikke matcher ønsket offerprofil — feil land, feil nettleser eller ser ut som en sikkerhetsskanner — vises en ufarlig side eller en 404-side.
Skanning fra én eneste bedrifts-IP eller et skybasert datasenter vil ikke fange opp disse sidene. Settet er bokstavelig talt laget for å skjule seg for deg.
Hvordan forsvarere bruker proxyer til å slå tilbake
På forsvarssiden har proxyer fire praktiske oppgaver:
-
Anonym URL- og domanskanning. Send mistenkelige lenker gjennom en kontrollert proxy slik at målet ser proxy-IP-en, ikke en ansattlaptop eller bedriftsnettverket. Dette reduserer direkte eksponering og gir en repeterbar etterforskningsprosess.
-
Innhenting av trusselintelligens. Bruk roterende proxyer til å hente inn data om phishing-infrastruktur, domenelister, offentlige trusselstrømmer eller nylig registrerte domener uten å bli blokkert etter få forespørsler. (Alltid innenfor lovverk og vilkår for bruk.)
-
Geo-distribuert phishingdeteksjon. Bruk proxyer i flere regioner for å se om en mistenkelig URL oppfører seg annerledes fra USA, EU, APAC eller et annet målmarked. Dette fanger opp sett som bruker geofencing eller filtrering på user-agent — de samme omgåelsesteknikkene som er beskrevet ovenfor.
-
Reverse proxy / WAF-implementering. Reverse proxyer står foran dine egne domener. De stopper ikke ansatte i å klikke på utgående phishing-lenker, men de beskytter egne nettressurser mot bottrafikk, credential stuffing, ondsinnede payloads og misbruksmønstre i trafikken.
Hvorfor MFA alene ikke holder mot phishing basert på proxyer
Jeg har sett denne diskusjonen utspille seg i dusinvis av IT-forum: «Vi har MFA, så vi er trygge.» Systemadministratorene som faktisk har håndtert et AiTM-tilfelle, har et helt annet syn.
Mekanismen er enkel. Offeret fullfører MFA i det som ser ut som en ekte innloggingsflyt. Den reelle identitetsleverandøren utsteder et sesjonstoken. Angriperen fanger dette tokenet via sin reverse proxy.
Autentiseringen lyktes — men angriperen eier nå økten. En passordendring alene er kanskje ikke nok hvis aktive økter og angriperopprettede MFA-endringer fortsatt ligger igjen. Microsoft sier eksplisitt at berørte organisasjoner må tilbakekalle sesjonscookies og rulle tilbake angriperopprettede MFA-endringer, utover standard opprydding.
SMS-koder, OTP-apper og push-godkjenninger kan alle phishes dersom brukeren fullfører dem i en angriperstyrt flyt. MFA gjorde jobben sin. Problemet er at angriperen fulgte med hele tiden.
Hva som faktisk stopper AiTM-phishing
FIDO2 / passkeys. FIDO Alliance forklarer at passkeys er phishing-resistente i design: ingen passord å stjele, ingen innloggingsdata som kan gjenbrukes. Den kryptografiske nøkkelpairen er bundet til det legitime domenets opprinnelse, så angriperens proxy kan rett og slett ikke etterligne utfordringen. CISA bekrefter at FIDO og PKI er de eneste bredt tilgjengelige, ikke-proprietære MFA-metodene som forhindrer credential phishing.
Sertifikatbasert autentisering. Passer for virksomheter, er mer kompleks å rulle ut, men er like phishing-resistent fordi den baserer seg på enhetssertifikater i stedet for koder brukeren skriver inn.
Conditional Access-policyer. I Microsoft-miljøer kan Conditional Access kreve kompatible enheter, betrodde lokasjoner, risikobaserte kontroller eller phishing-resistent autentiseringsstyrke — noe som reduserer verdien av et stjålet sesjonstoken selv om angriperen får tak i ett.
Alt dette er komplementært til proxyer, ikke erstatninger. Målet er lag.
Praktiske alternativer for SMB-er med stramt budsjett
Den åpenbare innvendingen: «Intune, MDM, fysiske sikkerhetsnøkler — det er jo bedriftsbudsjett.» Rimelig nok. Her er budsjettløpet:
- Nettleserbaserte passkeys. De fleste moderne nettlesere støtter passkeys innebygd. Ingen maskinvare må kjøpes. Start med admin-, økonomi- og HR-kontoer.
- Gratis DMARC-implementering. SPF-, DKIM- og DMARC-poster er gratis å publisere. Google Workspace og Microsoft 365 har innebygde oppsettveiledninger.
- Defensiv domeneregistrering. Registrer vanlige feilstavinger og lookalike-domener for merkevaren din. De fleste registrarer tar 10–15 USD per år per domene. Sett DMARC reject-policy på hvert av dem.
- Målrettet opplæring. Fokuser opplæringen på AiTM-agn spesielt: falske Microsoft 365-innlogginger, falske delte dokumenter, QR-koder, device code-svindel og «haster med lønn/leverandør»-flyter.
Tenk på det som «start her, oppgrader senere». Selv delvis innføring reduserer risikoen betydelig.
Hvilken proxytype fungerer best for å unngå phishing?
Ulike proxytyper passer til ulike anti-phishing-formål, og feil valg kan være bortkastede penger eller skape blinde flekker.
| Proxytype | Beste bruksområde mot phishing | Fordeler | Ulemper | Kostnadsnivå |
|---|---|---|---|---|
| Datasenter | Skanning av mange URL-er, domenemonitorering | Rask, billig, høy volumkapasitet | Oppdages lett av mer avanserte phishing-sett | Lav |
| Residential | Geo-målrettet phishingdeteksjon, testing fra brukers perspektiv | Ser ut som ekte brukertikk, omgår geo-blokkering | Tregere, dyrere, store etiske utfordringer rundt opprinnelse | Høy |
| Roterende | Innhenting av trusselintelligens, vedvarende overvåking | Unngår IP-blokkering under lange innhentingsøkter | Mer komplisert oppsett, varierende latenstid | Middels |
| Reverse Proxy / WAF | Forsvar av egne nettressurser | Filtrerer innkommende trusler, botdeteksjon, DDoS-beskyttelse | Hjelper ikke med å oppdage utgående phishing | Middels |
En merknad om etisk opprinnelse. Google/IPIDEA-saken og FBI-rådet gjør det klart at residential proxy-nettverk kan bygges på kompromitterte enheter, villedende SDK-er, skjulte VPN-vilkår eller skadevare. Før du kjøper residential proxy-trafikk, krev tydelig brukersamtykke, mulighet til å reservere seg, sporbarhet og rutiner for misbruk fra leverandøren. Leverandører som tidligere er flagget i sikkerhetsforskning (PacketStream, den nå nedlagte 911 Proxy) bør behandles med ekstrem varsomhet.
For de fleste små og mellomstore virksomheter er det beste å starte med datasenterproxyer for massiv skanning og en reverse proxy/WAF for egne domener. Legg til residential proxyer bare hvis du trenger geo-målrettet testing og kan kontrollere leverandøren grundig.
Steg for steg: Slik unngår du phishing med proxyer (en praktisk arbeidsflyt)
De fleste artikler stopper ved teorien. Hvert steg nedenfor inkluderer en verktøyanbefaling og nok detaljer til at du kan gi det videre til IT-teamet ditt eller gjøre det selv.
Steg 1: Overvåk nyregistrerte lookalike-domener
Angripere registrerer domener som ligner på dine før de starter kampanjene: thunderb1t.com, thunderbit-login.com, thunderbit-support.net.
Å fange disse tidlig er en av de mest verdifulle forsvarshandlingene som finnes.
Slik gjør du det:
- Lag en overvåkningsliste med merkenavn, produktnavn, ledernavn og ord knyttet til innlogging (for eksempel «login», «portal», «invoice», «payment»).
- Søk daglig i Certificate Transparency (CT)-logger via crt.sh, som lar deg søke i sertifikatregistre etter domene eller organisasjonsnavn. CT-logger krever at offentlig betrodde sertifikater logges, så nyutstedte sertifikater for lookalike-domener vil dukke opp der.
- Flagge domener med liten redigeringsavstand til merkevaren din, mistenkelige TLD-er (.xyz, .top, .click) eller login-/betalingsord i navnet.
- Gjengi de flaggede sidene via en proxy eller sandbox — aldri fra en ansattnettleser.
Thunderbit-kobling: Thunderbit-sin batch extract API kan behandle opptil 100 mistenkelige URL-er per jobb, med renderMode: "full" for å gjengi JavaScript-tunge phishing-kloner. Du definerer et JSON Schema for dataene du vil hente tilbake — sidetittel, om det finnes et innloggingsskjema, domene i skjemaets handling, SSL-utsteder, videresendingskjede og endelig URL. CLI-eksempelet passer godt inn i cron-basert overvåking:
thunderbit batch extract --file suspicious-urls.txt --schema phishing-signals.json --render-mode full
For ikke-tekniske brukere kan Thunderbit Chrome-utvidelsen også brukes til raskt å hente ut og vurdere mistenkelige sider med noen få klikk — nyttig når du bare trenger å se gjennom noen få URL-er i stedet for å kjøre en planlagt pipeline.
Forventet resultat: En daglig eller ukentlig rapport over nyregistrerte lookalike-domener med strukturert metadata, klar for triage.
Prøv Thunderbit for gjennomgang av mistenkelige URL-er
Steg 2: Send mistenkelige lenker gjennom datasenterproxyer
Før noen i organisasjonen klikker på en mistenkelig lenke, analyser den gjennom en kontrollert rute. Proxy-IP-en eksponeres, ikke den ansattes enhet eller bedriftsnettverk.
Slik gjør du det:
- For raske sjekker kan du bruke urlscan.io (en web-sandbox der du kan velge skanneland) eller VirusTotal (skanner URL-er mot dusinvis av antivirusprodukter og blokkeringslister).
- For interne skript eller høyere volum kan du route forespørsler gjennom en datasenterproxy:
curl -x http://proxy.example.com:8080 -I "https://suspicious.example"
- For levende phishing-sider bør du bruke en engangs-VM eller nettlesersandbox. Ikke skriv inn legitimasjon. Fang videresendingskjeden, sidetittel, endelig destinasjon, skjema-innsendinger, skript og skjermbilder.
- Send aldri ekte bedriftslegitimasjon. Og vær forsiktig med offentlige skanninger — enkelte tjenester gjør innsendte URL-er synlige med mindre de er konfigurert som private eller ikke-listede.
Forventet resultat: En trygg vurdering av lenkens destinasjon, oppførsel og indikatorer — uten eksponering av virksomheten.
Steg 3: Bruk geo-distribuerte proxyer for å fange målrettede phishingkampanjer
Noen phishing-sett viser bare ondsinnet innhold til besøkende fra et bestemt land eller med en bestemt språkinnstilling. Cofense dokumenterer at geolokaliseringsfiltrering er vanlig: besøkende fra «feil» region ser en ufarlig side eller en 404, mens målgruppen får skjemaet som samler inn legitimasjon.
Slik gjør du det:
- Test mistenkelige lenker fra de regionene der ansatte, kunder og økonomiteam faktisk jobber. Hvis selskapet ditt er basert i USA, men har et kontor i Storbritannia, test fra begge.
- Sammenlign endelige URL-er, skjermbilder, sidetitler, skjemaer og HTTP-statuskoder per region.
- Roter user-agent og språkinstillinger når du undersøker QR-kode- eller mobilrettede agn — noen sett filtrerer også på dette.
- Eskaler URL-er som viser ufarlig innhold i ett område, men innloggingsskjema i et annet. Det er et sterkt phishing-signal.
Forventet resultat: Oppdagelse av geo-målrettede kampanjer som ville vært usynlige med skanning fra kun ett sted.
Steg 4: Rull ut reverse proxy eller WAF for egne domener
Nå er det på tide å gå fra utgående deteksjon til inngående forsvar. Reverse proxyer og WAF-er står foran nettressursene dine og inspiserer innkommende trafikk før den når serverne dine.
Slik gjør du det:
- Pek domenets DNS til en reverse proxy-leverandør. Cloudflare er det mest tilgjengelige alternativet for SMB-er — DNS, CDN, WAF og regler finnes i ett grensesnitt. For applikasjoner hostet på AWS fungerer AWS WAF godt hvis du allerede bruker CloudFront, ALB eller API Gateway.
- Aktiver administrerte WAF-regler. Disse blokkerer kjente ondsinnede IP-er, filtrerer bottrafikk og oppdager mønstre for credential stuffing.
- Slå på hastighetsbegrensning for innlogging, passordtilbakestilling og kontaktskjemaer.
- Legg til bot- eller utfordringsregler for høyrisikopunkter.
- Følg med på WAF-hendelser ukentlig — ikke bare sett det opp og glem det.
Forventet resultat: Innkommende ondsinnet trafikk filtreres før den når serverne dine. Credential-stuffing-forsøk mot innloggingssidene dine blokkeres eller utfordres.
Steg 5: Automatiser og planlegg løpende overvåking
Phishing er ikke en engangsrevisjon. Nye domener, sett og infrastruktur dukker opp hver dag — derfor må overvåkingen ha en fast rytme:
- Daglig: CT-søk etter lookalike-domener og kø for mistenkelige domener.
- Daglig eller timevis (for høyrisikovaremerker): Sandkassesjekk av nylig oppdagede URL-er.
- Ukentlig: Gjennomgang av DMARC-aggregatrapporter og mønstre for spoofing.
- Ukentlig: Gjennomgang av WAF-hendelser for credential stuffing og bot-topper.
- Månedlig: Sjekk fremdriften i utrulling av phishing-resistent MFA.
- Kvartalsvis: Test økonomi- og HR-arbeidsflyter mot realistiske AiTM- og BEC-scenarier.
Thunderbit-kobling: Thunderbits planlagte scraping og CLI/API-arbeidsflyter kan støtte gjentakende overvåking for driftsteam uten tung teknisk kompetanse. Det beste bruksområdet er ikke «Thunderbit stopper phishing alene» — det er «Thunderbit hjelper driftsteam å samle strukturert signal fra mistenkelige sider og domenemonitoreringskilder uten å bygge en skreddersydd scraper fra bunnen av». Resultatene kan sendes til Google Sheets eller Airtable for synlighet i teamet, eller til Slack via en enkel integrasjon.
Forventet resultat: En kontinuerlig overvåkingssløyfe som fanger nye trusler i løpet av timer, ikke uker.
Hva proxyer ikke kan fange: sikre e-post med DMARC, SPF og DKIM
Proxy-leverandører vil ikke alltid si dette høyt: proxyer er bare ett lag i forsvaret, og e-postbasert phishing som aldri går via en proxy krever annen beskyttelse.
Mange phishingangrep kommer via forfalskede e-postadresser. En proxy stopper ikke det.
Slik setter du opp SPF med hard fail
SPF (Sender Policy Framework) er en DNS-post som lister hvilke IP-er som har lov til å sende e-post på vegne av domenet ditt. Konfigurer med -all (hard fail) i stedet for ~all (soft fail) for å avvise uautoriserte avsendere direkte.
Vanlig feil: å glemme å ta med alle legitime utsendingstjenester — CRM-systemet ditt, markedsføringsplattformen, leverandøren for transaksjons-e-post, helpdesk. Kartlegg avsendingskildene før du publiserer posten.
Rulle ut DKIM-signering
DKIM (DomainKeys Identified Mail) legger til en kryptografisk signatur i utgående e-post. Mottakeren kan verifisere at meldingen ikke er tuklet med underveis. Både Google Workspace og Microsoft 365 har innebygde veiledninger for oppsett av DKIM. Det tar omtrent 15 minutter.
Tving DMARC til å avvise
DMARC (Domain-based Message Authentication, Reporting & Conformance) forteller mottakende servere hva de skal gjøre når SPF- eller DKIM-sjekker feiler. Det viktigste steget mange organisasjoner hopper over: å gå fra p=none (kun overvåking) til p=reject (blokker meldinger som feiler) etter at legitime e-postflyter er verifisert.
Mange organisasjoner lar DMARC stå på p=none i det uendelige — synlighet uten beskyttelse. Det er som å installere et sikkerhetskamera, men aldri låse døra.
Defensiv registrering av lookalike-domener
Registrer på forhånd vanlige feilstavinger og lookalike-domener for merkevaren din. Sett DMARC reject-policy på disse defensive domenene slik at de ikke kan brukes til e-postspoofing. Til 10–15 USD per år per domene er dette et av de billigste tiltakene med størst effekt som finnes — og de fleste småbedrifter overser det helt.
Slik henger alt sammen: Et lagdelt forsvar mot phishing
Ingen enkeltverktøy stopper phishing. Det er kombinasjonen som gjør forsvaret robust. Praktisk sjekkliste:
Utgående (undersøker trusler):
- Proxy-basert URL-skanning av mistenkelige lenker
- Domenemonitorering via CT-logger og batch-ekstraksjon
- Geo-distribuert testing for kampanjer rettet mot bestemte regioner
Innkommende (beskytte egne ressurser):
- Reverse proxy / WAF for nettområdene dine
- DMARC/SPF/DKIM for e-postautentisering
- Defensiv registrering av lookalike-domener
Autentisering (beskytte kontoer):
- FIDO2 / passkeys for phishing-resistent MFA
- Conditional Access-policyer (kompatible enheter, risikobaserte kontroller)
- Rutiner for overvåking og tilbakekalling av sesjonstokener
Mennesker (det siste sikkerhetsnettet):
- Opplæring med særlig fokus på AiTM-agn, QR-koder og BEC-scenarier
- Tydelig rapporteringskultur — gjør det enkelt og uten skyld for ansatte å rapportere mistenkelige meldinger
- Regelmessig testing av økonomi- og HR-prosesser mot realistiske phishing-scenarier
Tilnærmingen følger NIST Cybersecurity Frameworks prinsipp om forsvar i dybden: flere uavhengige lag, slik at feil i ett lag ikke betyr full kompromittering.
For team som må undersøke mistenkelige URL-er, hente ut trusseldata eller overvåke domener i stor skala, kan Thunderbits AI web scraper akselerere arbeidsflyten — Chrome-utvidelse for ikke-tekniske brukere, API/CLI for tekniske team. Det er ikke et sikkerhetsprodukt i seg selv, men det fortjener en plass i verktøykassen til analytikeren. Du kan lære mer om webskraping uten koding eller utforske tilnærminger til AI web scraping i bloggen vår.
Bruk AI-webskraping til trusselovervåking Get Started Free
Ofte stilte spørsmål
Hvordan bruker angripere proxyer i phishingangrep?
Angripere bruker residential- og roterende proxyer til å skjule sin virkelige IP, rotere mellom betrodde adresser, omgå IP-basert svindelkontroll og sette opp AiTM reverse proxyer for å fange autentiserte økter — selv etter at offeret har fullført MFA. IPIDEA-nedslaget i januar 2026 viste over 550 trusselgrupper som brukte ett og samme residential proxy-nettverk.
Hvordan hindrer en reverse proxy phishing og nettsidekompromittering?
En reverse proxy står foran webserverne dine og inspiserer innkommende trafikk før den når infrastrukturen din. Den blokkerer kjente ondsinnede IP-er, filtrerer bottrafikk, setter hastighetsgrenser på innloggingsforsøk og oppdager credential stuffing eller phishing-relatert aktivitet. Den beskytter derimot ikke ansatte mot å klikke på utgående phishing-lenker.
Kan proxyer forhindre phishing fullstendig?
Nei. Proxyer er ett viktig lag, men e-postbasert phishing krever DMARC/SPF/DKIM, og kapring av økter via AiTM-angrep krever phishing-resistent MFA som FIDO2/passkeys. Et lagdelt forsvar som kombinerer proxyer, e-postautentisering, phishing-resistente innloggingsmetoder og opplæring av ansatte er avgjørende.
Hva er AiTM phishing, og hvorfor stopper ikke MFA det?
AiTM (Adversary-in-the-Middle) phishing bruker en reverse proxy mellom offeret og den ekte innloggingssiden, og fanger sesjonstokenet etter at MFA er fullført. Tradisjonell MFA stopper det ikke fordi angriperen stjeler den autentiserte økten, ikke passordet. FIDO2/passkeys motstår dette angrepet fordi den kryptografiske utfordringen er bundet til det legitime domenet og ikke kan spilles av via angriperens proxy.
Hvilken proxytype er best for phishingdeteksjon?
Datasenterproxyer er best for skanning av mange URL-er (raskt og billig). Residential proxyer er best for geo-målrettet testing (realistisk, men dyrere — kontroller leverandøren for etisk opprinnelse). Reverse proxy/WAF er best for å beskytte egne nettsteder. Den sterkeste tilnærmingen er en kombinasjon basert på hva du prøver å oppdage eller beskytte.
Prøv Thunderbit for trusselovervåking og AI-skraping Get Started Free
Les mer
