APWG registrerede alene 971.181 phishing-angreb i 1. kvartal 2026 — en stigning på 13,8 % i forhold til kvartalet før. Og i januar 2026 slog Google ned på det, de kaldte et af verdens største residential proxy-netværk, efter at have konstateret, at over 550 trusselsgrupper sendte trafik gennem det på bare én uge. Proxies viser sig altså at stå på begge sider af phishing-kampen.
Det er netop den spænding, som de fleste artikler om "proxies og phishing" overser. Enten får du at vide, at proxies er et skjold (køb vores proxy-produkt, og du er sikker), eller også at proxies er et våben for angribere (vær bange). Virkeligheden er mere rodet — og langt mere interessant.
Angribere bruger proxy-infrastruktur til at skjule deres oprindelse, skifte mellem betroede IP-adresser og stjæle autentificerede sessioner — selv efter MFA. Forsvarere bruger proxies til sikkert at undersøge mistænkelige links, teste hvordan phishing-sider ser ud i forskellige lande og filtrere skadelig trafik, før den når deres egne websites. Denne guide dækker begge sider og gennemgår derefter en konkret arbejdsgang, som du faktisk kan implementere. Ingen varm luft, ingen mirakelløsninger.
- Sværhedsgrad: Mellem
- Tidsforbrug: Ca. 25 minutter til læsning og planlægning; implementering varierer fra trin til trin
- Det skal du bruge: Grundlæggende forståelse af din organisations webinfrastruktur, adgang til DNS-indstillinger for dit domæne, en Chrome-browser (til Thunderbit-trinene) og eventuelt en konto hos en proxy-udbyder
Hvad er phishing, og hvorfor bør din virksomhed tage det alvorligt?
Phishing er en bedragerisk teknik. Kriminelle bruger e-mail, sms’er, falske login-sider, QR-koder eller forfalskede websites til at narre folk til at udlevere adgangsoplysninger, godkende et login, installere malware eller overføre penge.
Det er ikke længere bare et problem med "en dårlig e-mail". Moderne phishing involverer cloud-hostede sider, falske Microsoft 365-loginflows, QR-koder og tyveri af sessionstokens.
For virksomheder er konsekvenserne helt konkrete. IBM’s rapport om omkostninger ved databrud i 2025 sætter den gennemsnitlige globale omkostning ved et databrud til 4,4 mio. USD. FBI’s Internet Crime Report for 2025 siger, at IC3 modtog omkring 453.000 klager over cyberbaseret svindel med rapporterede tab på over 17,7 mia. USD, hvor business email compromise (BEC) stod for over 3 mia. USD af det beløb.
Tyveri af adgangsoplysninger, bankoverførselsbedrageri, kompromittering af forsyningskæden, bøder fra myndighederne — phishing kan ramme det hele.
Det følgende handler om, hvordan proxies indgår både i angreb og forsvar, og hvordan et lagdelt og realistisk forsvar faktisk ser ud.
Proxies’ dobbelte rolle: dit skjold og deres våben
En proxy er et mellemled mellem din enhed og internettet. I stedet for at et website ser din rigtige IP-adresse, ser det proxyens adresse. Tænk på det som en postvideresendelsestjeneste: modtageren får brevet fra videresendelsesadressen og ikke fra dit hjem.
Netop den egenskab skaber problemet med dobbelt anvendelse. Sikkerhedsteams bruger proxies til at undersøge trusler uden at afsløre en corporate IP eller en analysts arbejdsstation. Angribere bruger den samme teknologi til at få skadelig trafik til at se ud som om den kommer fra almindelige brugere, andre lande eller betroede residential-netværk. Barracudas analyse fra april 2026 forklarer det enkelt: residential IP-adresser ser autentiske ud, fordi de er knyttet til rigtige hjemmenetværk eller små virksomheder, og derfor er svindelsystemer mindre tilbøjelige til at markere dem.
De fleste konkurrerende artikler dækker kun den ene side. Det efterlader læserne med et ufuldstændigt billede — og dermed ufuldstændigt forsvar.
Sådan bruger angribere proxies mod dig
Tre angrebsveje er særligt vigtige for virksomheders forsvar: anonymitet og IP-rotation, misbrug af residential proxies og omgåelse via betroede platforme.
AiTM (Adversary-in-the-Middle) phishing forklaret
AiTM er angrebet, der knuser antagelsen om, at "MFA beskytter os" (spoiler: traditionel MFA overlever det ikke).
I et AiTM-angreb placerer angriberen en reverse proxy mellem offeret og en legitim login-side — f.eks. Microsoft 365. Brugeren ser noget, der ligner et ægte loginflow. Vedkommende indtaster sine oplysninger, gennemfører MFA, og den rigtige identitetsudbyder udsteder en session-cookie. Men fordi al trafik passerer gennem angriberens proxy, opsnapper angriberen cookie’en. Derefter kan den genbruges til at få adgang til kontoen — uden password eller MFA-prompt.
Microsofts analyse af Tycoon2FA, et af de førende AiTM-phishingkits, viser, at operatørerne kan efterligne login-sider for Microsoft 365, Outlook, SharePoint, OneDrive og Google. Kittet genererer PDF’er og QR-koder, håndterer redirect-kæder og holder styr på MFA-brug og opsamling af session-cookies. Infrastrukturen bruger kortlivede subdomæner og Cloudflare-hostet infrastruktur for at gøre blocklister mindre effektive.
Det her er ikke teori. AiTM-kits udnyttes aktivt i stor skala, og det er den primære grund til, at "vi har MFA" ikke er et fuldt svar på phishing.
Misbrug af residential proxies og IP-rotation
Residential proxy-netværk sender angribertrafik gennem rigtige hjemme-IP’er, så phishing-anmodninger fremstår legitime og glider forbi IP-baseret svindelkontrol. Mange udbydere verificerer ikke stramt, hvordan deres IP’er bruges, hvilket skaber et gråmarked.
Det mest konkrete eksempel: I januar 2026 slog Google Threat Intelligence Group IPIDEA’s residential proxy-netværk i stykker og reducerede den tilgængelige enhedspulje med millioner. GTIG observerede over 550 individuelle trusselsgrupper, der brugte IPIDEA’s exit-noder i en enkelt syvdagesperiode. Undersøgelsen fandt overlap med botnets, misbrug af SaaS-adgang, password-spray-angreb og globale spionageaktører. Mange proxy-SDK-udrulninger manglede tydeligt brugersamtykke.
FBI’s advisering fra 2026 om residential proxies nævner phishing, login med stjålne credentials, brute-force-angreb, konto-overtagelser, spam og C2-sløring som kriminelle anvendelser.
Hosting på betroede platforme og undvigelse i phishingkits
En anden omgåelsesmetode er at hoste phishing-sider på betroede platforme — SharePoint, Google Docs, Azure Blob Storage — for at ride med på domænets omdømme. Microsofts analyse af trusler mod Azure Blob Storage viser, at angribere bruger det til at hoste forfalskede Microsoft login-sider, som er sværere for ofre at gennemskue som ondsindede alene ud fra certifikater.
Phishingkits bruger også undvigelseslogik. Cofenses analyse af phishing-kits dokumenterer geolokationsfiltrering, filtrering efter user-agent og sprog, CAPTCHA, registrering af developer tools og redirects til legitime sider. Hvis en besøgende ikke matcher den tiltænkte offerprofil — forkert land, forkert browser eller ligner en sikkerhedsscanner — vises en ufarlig side eller en 404-side.
Scanning fra én enkelt corporate IP eller et cloud-datacenter vil overse disse sider. Kittet er bogstaveligt talt designet til at skjule sig for dig.
Sådan bruger forsvarere proxies til at slå igen
På forsvarssiden løser proxies fire praktiske opgaver:
-
Anonym URL- og domænescanning. Send mistænkelige links gennem en kontrolleret proxy, så destinationen ser proxyens IP og ikke en medarbejders laptop eller det interne netværk. Det reducerer direkte eksponering og skaber en gentagelig undersøgelsesproces.
-
Indsamling af threat intelligence. Brug roterende proxies til at crawle phishing-infrastruktur, domænelister, offentlige threat feeds eller nyligt registrerede domænekilder uden at blive blokeret efter få forespørgsler. (Altid inden for lovgivning og servicevilkår.)
-
Geo-distribueret phishing-detektion. Brug proxies i flere regioner for at se, om en mistænkelig URL opfører sig forskelligt fra USA, EU, APAC eller et andet målmarked. Det afslører kits, der bruger geofencing eller user-agent-filtrering — de samme undvigeteknikker, som beskrevet ovenfor.
-
Reverse proxy / WAF-implementering. Reverse proxies står foran dine egne domæner. De stopper ikke medarbejdere i at klikke på phishing-links udadtil, men de beskytter dine egne webproperties mod bottrafik, credential stuffing, ondsindede payloads og misbrugsprægede trafikmønstre.
Hvorfor MFA alene fejler mod proxy-baseret phishing
Jeg har set denne debat i snesevis af IT-fora: "Vi har MFA, så vi er dækket ind." De systemadministratorer, der faktisk har håndteret et AiTM-incident, ser helt anderledes på det.
Mekanismen er enkel. Offeret gennemfører MFA i noget, der ligner et ægte loginflow. Den rigtige identitetsudbyder udsteder et session-token. Angriberen opsnapper tokenet via sin reverse proxy.
Autentificeringen lykkedes — men angriberen ejer nu sessionen. En almindelig password-reset er måske ikke nok, hvis aktive sessioner og angriberens ændringer til MFA stadig er på plads. Microsoft siger det direkte: Berørte organisationer skal tilbagekalde session-cookies og rulle angriberens MFA-ændringer tilbage, ud over standardafhjælpning.
SMS-koder, OTP-apps, push-godkendelser — alt kan phishes, hvis brugeren gennemfører dem i et flow, som angriberen kontrollerer. MFA gjorde sin del af arbejdet. Problemet er, at angriberen så med hele tiden.
Hvad stopper faktisk AiTM-phishing?
FIDO2 / passkeys. FIDO Alliance forklarer, at passkeys er phishing-resistente pr. design: ingen passwords at stjæle, ingen login-data der kan genbruges. Den kryptografiske nøglepar er bundet til det legitime domænes origin, så angriberens proxy kan simpelthen ikke gengive udfordringen. CISA bekræfter, at FIDO og PKI er de eneste bredt tilgængelige ikke-proprietære MFA-metoder, der forhindrer credential phishing.
Certifikatbaseret autentificering. Enterprise-niveau og mere kompleks at implementere, men lige så phishing-resistent, fordi den bygger på enhedscertifikater frem for koder, som brugeren indtaster.
Conditional Access-politikker. I Microsoft-miljøer kan Conditional Access kræve kompatible enheder, betroede placeringer, risikobaserede kontroller eller phishing-resistent autentificeringsstyrke — hvilket mindsker værdien af et stjålet session-token, selv hvis angriberen får fat i et.
Alt dette supplerer proxies, ikke erstatter dem. Målet er lag på lag.
Praktiske budgetmuligheder for SMB’er
Den oplagte indvending er: "Intune, MDM, hardware-nøgler — det er enterprise-budget." Fair nok. Her er budgetvejen:
- Browserbaserede passkeys. De fleste moderne browsere understøtter passkeys direkte. Intet hardwarekøb nødvendigt. Start med admin-, finance- og HR-konti.
- Gratis DMARC-implementering. SPF-, DKIM- og DMARC-poster er gratis at publicere. Google Workspace og Microsoft 365 har indbyggede opsætningsvejledninger.
- Defensiv domæneregistrering. Registrér almindelige stavefejl og lookalike-domæner for dit brand. De fleste registratorer tager 10–15 USD om året pr. domæne. Sæt DMARC-reject-politik på hvert af dem.
- Målrettet træning. Fokuser medarbejdernes awareness på AiTM-lokkemad specifikt: falske Microsoft 365-login-sider, falske dokument-delinger, QR-koder, device code-svindel og "akut løn/leverandør"-flows.
Tænk på det som "start her, opgrader senere." Selv delvis implementering reducerer risikoen markant.
Hvilken proxy-type er bedst til at undgå phishing?
Forskellige proxy-typer passer til forskellige anti-phishing-formål, og den forkerte løsning kan koste penge eller skabe blinde vinkler.
| Proxytype | Bedste anti-phishing-anvendelse | Fordele | Ulemper | Omkostningsniveau |
|---|---|---|---|---|
| Datacenter | Massescanning af URL’er, domæneovervågning | Hurtig, billig, høj volumen | Kan let opdages af mere avancerede phishing-kits | Lav |
| Residential | Geo-målrettet phishing-detektion, test fra brugerperspektiv | Ligner rigtig brugstrafik, omgår geoblokeringer | Langsommere, dyrere, alvorlige etiske sourcing-problemer | Høj |
| Roterende | Indsamling af threat intelligence, løbende overvågning | Undgår IP-blokeringer under lange crawl-sessioner | Mere kompleks opsætning, varierende latenstid | Mellem |
| Reverse Proxy / WAF | Forsvar af dine egne webproperties | Filtrerer indgående trusler, bot-detektion, DDoS-beskyttelse | Hjælper ikke med at opdage outbound phishing | Mellem |
Bemærk om etisk sourcing. Google/IPIDEA-sagen og FBI’s advisering gør det klart, at residential proxy-netværk kan være bygget på kompromitterede enheder, vildledende SDK’er, skjulte VPN-vilkår eller malware. Før du køber residential proxy-trafik, så kræv gennemsigtigt brugersamtykke, mulighed for fravalg, sporbarhed og håndtering af misbrug fra udbyderen. Udbydere, som tidligere er blevet nævnt i sikkerhedsforskning (PacketStream, den nu nedlagte 911 Proxy), bør behandles med ekstrem forsigtighed.
For de fleste små og mellemstore virksomheder er det bedste udgangspunkt datacenter-proxies til massescanning og en reverse proxy/WAF til egne domæner. Tilføj kun residential proxies, hvis du har brug for geo-målrettet testning og kan vurdere udbyderen grundigt.
Trin for trin: Sådan undgår du phishing med proxies (en praktisk arbejdsgang)
De fleste artikler stopper ved teorien. Hvert trin nedenfor indeholder et værktøjsforslag og nok detaljer til, at du kan give det videre til dit IT-team eller selv følge det.
Trin 1: Overvåg nyregistrerede lookalike-domæner
Angribere registrerer domæner, der ligner dit, før de starter kampagner: thunderb1t.com, thunderbit-login.com, thunderbit-support.net.
At opdage dem tidligt er en af de mest værdifulde forsvarshandlinger, du kan foretage.
Sådan gør du:
- Lav en overvågningsliste over dine brand-termer, produktnavne, ledernavne og login-relaterede ord (f.eks. "login", "portal", "invoice", "payment").
- Forespørg dagligt Certificate Transparency (CT)-logs via crt.sh, som lader dig søge certifikatoplysninger efter domæne eller organisationsnavn. CT-logs kræver, at offentligt betroede certifikater bliver registreret, så nyligt udstedte certifikater til lookalike-domæner vil dukke op her.
- Markér domæner med lille redigeringsafstand til dit brand, mistænkelige TLD’er (.xyz, .top, .click) eller login-/betalingsord.
- Render markerede sider gennem en proxy eller sandbox — aldrig fra en medarbejders browser.
Thunderbit-vinkel: Thunderbit’s batch extract API kan behandle op til 100 mistænkelige URL’er pr. job og bruge renderMode: "full" til at gengive JavaScript-tunge phishing-kloner. Du definerer et JSON Schema for de data, du vil have retur — sidetitel, om der findes en loginformular, formularens action-domæne, SSL-udsteder, redirect-kæde og endelig URL. Den tilsvarende CLI passer fint ind i cron-baseret overvågning:
thunderbit batch extract --file suspicious-urls.txt --schema phishing-signals.json --render-mode full
For ikke-tekniske brugere kan Thunderbit Chrome-udvidelsen også bruges til hurtigt at scrape og gennemgå mistænkelige sider med få klik — nyttigt når du bare skal vurdere en håndfuld URL’er og ikke sætte en planlagt pipeline op.
Forventet resultat: En daglig eller ugentlig rapport over nyregistrerede lookalike-domæner med strukturerede metadata, klar til triagering.
Prøv Thunderbit til gennemgang af mistænkelige URL’er
Trin 2: Send mistænkelige links gennem datacenter-proxies
Før nogen i organisationen klikker på et mistænkeligt link, så analysér det via en kontrolleret rute. Proxyens IP bliver eksponeret — ikke medarbejderens enhed eller det interne netværk.
Sådan gør du:
- Til hurtige tjek kan du bruge urlscan.io (en web-sandbox, hvor du kan vælge scanningsland) eller VirusTotal (scanner URL’er mod dusinvis af antivirusprodukter og blocklister).
- Til interne scripts eller højere volumen kan du sende forespørgsler gennem en datacenter-proxy:
curl -x http://proxy.example.com:8080 -I "https://suspicious.example"
- Ved live phishing-sider bør du bruge en disposable VM eller browser-sandbox. Slå indtastning af credentials fra. Gem redirect-kæden, sidetitel, endelig destination, formularindsendelser, scripts og screenshots.
- Indsend aldrig rigtige virksomhedscredentials. Og vær forsigtig med offentlige scanninger — nogle tjenester eksponerer de indsendte URL’er, medmindre de er sat til privat eller unlisted.
Forventet resultat: En sikker vurdering af linkets destination, adfærd og indikatorer — uden eksponering af virksomheden.
Trin 3: Brug geo-distribuerede proxies til at fange målrettede phishing-kampagner
Nogle phishing-kits viser kun ondsindet indhold til besøgende fra et bestemt land eller en bestemt sprogindstilling. Cofense dokumenterer, at geolokationsfiltrering er almindeligt: besøgende fra den "forkerte" region ser en ufarlig side eller en 404, mens målgruppen får formularen til at opsamle credentials.
Sådan gør du:
- Test mistænkelige links fra de regioner, hvor dine medarbejdere, kunder og finance-teams faktisk arbejder. Hvis din virksomhed er baseret i USA med et kontor i Storbritannien, så test fra begge steder.
- Sammenlign endelige URL’er, screenshots, sidetitler, formularer og HTTP-statuskoder på tværs af regioner.
- Skift user-agent og sprogindstillinger, når du undersøger QR-kode- eller mobilmålrettede lokkemidler — nogle kits filtrerer også på det.
- Eskalér URL’er, som viser ufarligt indhold ét sted, men loginformularer et andet. Det er et stærkt phishing-signal.
Forventet resultat: Opdagelse af geo-målrettede kampagner, som ellers ville være usynlige for en scanning med én fast placering.
Trin 4: Implementér en reverse proxy eller WAF for dine egne domæner
Nu skifter vi fra outbound-detektion til inbound-forsvar. Reverse proxies og WAF’er står foran dine webproperties og inspicerer indgående trafik, før den når dine servere.
Sådan gør du:
- Peg dit domænes DNS mod en reverse proxy-udbyder. Cloudflare er den mest tilgængelige mulighed for SMB’er — DNS, CDN, WAF og regler ligger samlet ét sted. For applikationer hostet på AWS fungerer AWS WAF godt, hvis du allerede bruger CloudFront, ALB eller API Gateway.
- Slå administrerede WAF-regler til. De blokerer kendte ondsindede IP’er, filtrerer bottrafik og opdager credential-stuffing-mønstre.
- Aktivér rate limits for login, password reset og kontaktformularer.
- Tilføj bot- eller challenge-regler for endpoints med høj risiko.
- Overvåg WAF-hændelser ugentligt — sæt ikke bare tingene op og glem dem.
Forventet resultat: Indgående skadelig trafik filtreres, før den når dine servere. Credential-stuffing-forsøg mod dine login-sider bliver blokeret eller udfordret.
Trin 5: Automatisér og planlæg løbende overvågning
Phishing er ikke en engangsopgave. Nye domæner, kits og infrastrukturer dukker op hver dag — så overvågning kræver rytme:
- Dagligt: CT-scan for lookalike-domæner og køen af mistænkelige domæner.
- Dagligt eller hver time (for højrisikobrands): Sandbox-tjek af nyopdagede domæner.
- Ugentligt: Gennemgang af DMARC-aggregate reports og mønstre for spoofing.
- Ugentligt: Gennemgang af WAF-hændelser for credential stuffing og bot-spikes.
- Månedligt: Tjek af fremdriften i udrulning af phishing-resistent MFA.
- Kvartalsvist: Test finance- og HR-arbejdsgange mod realistiske AiTM- og BEC-scenarier.
Thunderbit-vinkel: Thunderbits planlagte scraping og CLI/API-arbejdsgange kan understøtte tilbagevendende overvågning for operationelle teams uden dyb teknisk kapacitet. Det bedste use case er ikke "Thunderbit forhindrer phishing alene" — det er "Thunderbit hjælper operationsteams med at indsamle strukturerede signaler fra mistænkelige sider og domæneovervågningskilder uden at bygge en specialdesignet scraper fra bunden." Resultaterne kan sendes videre til Google Sheets eller Airtable for teamoverblik eller ind i Slack via en simpel integration.
Forventet resultat: En kontinuerlig overvågningssløjfe, der fanger nye trusler inden for timer — ikke uger.
Hvad proxies ikke kan fange: sikring af e-mail med DMARC, SPF og DKIM
Proxy-udbydere vil sjældent sige det her: proxies er ét lag i forsvaret, men e-mailbaseret phishing, der aldrig rører et proxy-lag, kræver separat beskyttelse.
Mange phishing-angreb kommer via forfalskede e-mailadresser. En proxy stopper dem ikke.
Sådan sætter du SPF op med hard fail
SPF (Sender Policy Framework) er en DNS-post, der angiver, hvilke IP’er der må sende e-mail på vegne af dit domæne. Konfigurér med -all (hard fail) i stedet for ~all (soft fail), så uautoriserede afsendere afvises direkte.
Et typisk fejltrin er at glemme alle legitime afsendertjenester — dit CRM, marketingplatform, transaktionsmail-udbyder og helpdesk. Gennemgå dine afsendelseskilder, før du publicerer posten.
Implementering af DKIM-signering
DKIM (DomainKeys Identified Mail) tilføjer en kryptografisk signatur til udgående e-mails. Modtageren kan verificere, at beskeden ikke er blevet ændret undervejs. Både Google Workspace og Microsoft 365 har indbyggede vejledninger til opsætning af DKIM. Det tager omkring 15 minutter.
Håndhævelse af DMARC med reject
DMARC (Domain-based Message Authentication, Reporting & Conformance) fortæller modtagende servere, hvad de skal gøre, når SPF- eller DKIM-tjek fejler. Det afgørende skridt, som mange organisationer springer over: at gå fra p=none (kun overvågning) til p=reject (blokér fejlende beskeder), når de legitime e-mailflows er verificeret.
Mange organisationer lader DMARC stå på p=none i det uendelige — synlighed uden beskyttelse. Det er som at installere et overvågningskamera, men aldrig låse døren.
Defensiv registrering af lookalike-domæner
Registrér proaktivt almindelige stavefejl og lookalike-domæner for dit brand. Sæt DMARC reject-politik på disse defensive domæner, så de ikke kan bruges til spoofed e-mail. Til 10–15 USD om året pr. domæne er det en af de billigste og mest effektive tiltag, du kan tage — og noget som mange små virksomheder helt overser.
Sådan binder du det hele sammen: et lagdelt forsvar mod phishing
Intet enkelt værktøj stopper phishing. Det er kombinationen, der får forsvaret til at holde. Praktisk tjekliste:
Outbound (undersøgelse af trusler):
- Proxybaseret URL-scanning af mistænkelige links
- Domæneovervågning via CT-logs og batch-extraction
- Geo-distribueret testning af region-målrettede kampagner
Inbound (beskyttelse af dine egne systemer):
- Reverse proxy / WAF for dine webdomæner
- DMARC/SPF/DKIM til e-mailautentificering
- Defensiv registrering af lookalike-domæner
Autentificering (beskyttelse af konti):
- FIDO2 / passkeys til phishing-resistent MFA
- Conditional Access-politikker (kompatible enheder, risikobaserede checks)
- Rutiner til overvågning og tilbagekaldelse af sessionstokens
Mennesker (den sidste sikkerhedsnet):
- Træning målrettet AiTM-lokkemidler, QR-koder og BEC-scenarier
- En klar rapporteringskultur — gør det let og uden straf at rapportere mistænkelige beskeder
- Løbende test af finance- og HR-arbejdsgange mod realistiske phishing-scenarier
Tilgangen følger NIST Cybersecurity Frameworks princip om defense-in-depth: flere uafhængige lag, så fejl i ét lag ikke betyder total kompromittering.
For teams, der skal undersøge mistænkelige URL’er, scrape trusselsdata eller overvåge domæner i stor skala, kan Thunderbit’s AI web scraper gøre arbejdsgangen hurtigere — Chrome-udvidelse til ikke-tekniske brugere, API/CLI til tekniske teams. Det er ikke et sikkerhedsprodukt i sig selv, men det fortjener en plads i analytikerens værktøjskasse. Du kan lære mere om web scraping uden kodning eller udforske AI web scraping-tilgange på vores blog.
Brug AI web scraping til trusselsmonitorering Get Started Free
Ofte stillede spørgsmål
Hvordan bruger angribere proxies til phishing-angreb?
Angribere bruger residential og roterende proxies til at skjule deres rigtige IP, skifte mellem betroede adresser, omgå IP-baseret svindelkontrol og deploye AiTM reverse proxies til at opsnappe autentificerede sessioner — selv efter at offeret har gennemført MFA. IPIDEA-forstyrrelsen i januar 2026 viste over 550 trusselsgrupper, der brugte ét enkelt residential proxy-netværk.
Hvordan forhindrer en reverse proxy phishing og kompromittering af websites?
En reverse proxy står foran dine webservere og inspicerer indgående trafik, før den når din infrastruktur. Den blokerer kendte ondsindede IP’er, filtrerer bottrafik, sætter hastighedsbegrænsninger på loginforsøg og opdager credential stuffing eller phishing-relateret aktivitet. Den beskytter dog ikke medarbejdere mod at klikke på udgående phishing-links.
Kan proxies helt forhindre phishing?
Nej. Proxies er ét vigtigt lag, men e-mailbaseret phishing kræver DMARC/SPF/DKIM, og session hijacking via AiTM-angreb kræver phishing-resistent MFA som FIDO2/passkeys. Et lagdelt forsvar, der kombinerer proxies, e-mailautentificering, phishing-resistente loginmetoder og medarbejdertræning, er afgørende.
Hvad er AiTM phishing, og hvorfor stopper MFA det ikke?
AiTM (Adversary-in-the-Middle) phishing bruger en reverse proxy mellem offeret og den rigtige login-side og opsnapper sessionstokenet, når MFA er gennemført. Traditionel MFA stopper det ikke, fordi angriberen stjæler den autentificerede session — ikke passwordet. FIDO2/passkeys er modstandsdygtige over for dette angreb, fordi den kryptografiske udfordring er bundet til det legitime domæne og ikke kan genafspilles gennem angriberens proxy.
Hvilken proxy-type er bedst til phishing-detektion?
Datacenter-proxies er bedst til massescanning af URL’er (hurtige og billige). Residential proxies er bedst til geo-målrettet testning (realistiske, men dyrere — tjek udbyderen for etisk sourcing). Reverse proxies/WAF’er er bedst til at beskytte dine egne sites. Den stærkeste tilgang er en kombination, afhængigt af hvad du forsøger at opdage eller beskytte.
Prøv Thunderbit til trusselsmonitorering og AI scraping Get Started Free
Læs mere
