APWG räknade bara under första kvartalet 2026 971 181 nätfiskeattacker — en ökning med 13,8 % jämfört med föregående kvartal. Och i januari 2026 slog Google sönder vad de kallade ett av världens största residential proxy-nätverk efter att ha upptäckt att över 550 hotgrupper skickade trafik genom det på en enda vecka. Proxies, visar det sig, finns på båda sidor i kampen mot nätfiske.
Det är just den här spänningen som de flesta artiklar om ”proxies och nätfiske” missar. De säger antingen att proxies är en sköld (köp vår proxyprodukt, så är du säker) eller att proxies är ett vapen för angripare (var rädd). Verkligheten är mer rörig — och mer intressant.
Angripare använder proxyinfrastruktur för att dölja sitt ursprung, rotera mellan betrodda IP-adresser och stjäla autentiserade sessioner — även efter MFA. Försvarare använder proxies för att undersöka misstänkta länkar på ett säkert sätt, testa hur nätfiskesidor ser ut i olika länder och filtrera skadlig trafik innan den når deras egna webbplatser. Den här guiden går igenom båda sidor och visar sedan ett konkret arbetsflöde som faktiskt går att införa. Inget fluff, inga mirakellösningar.
- Svårighetsgrad: Medel
- Tidsåtgång: Cirka 25 minuter att läsa och planera; implementationen varierar beroende på steg
- Det här behöver du: Grundläggande förståelse för organisationens webb-infrastruktur, åtkomst till DNS-inställningarna för din domän, en Chrome-webbläsare (för Thunderbit-stegen) och eventuellt ett konto hos en proxy-leverantör
Vad är nätfiske och varför bör ditt företag bry sig?
Nätfiske är en bedrägeriattack. Kriminella använder e-post, sms, falska inloggningssidor, QR-koder eller förfalskade webbplatser för att lura människor att lämna ut inloggningsuppgifter, godkänna inloggningar, installera skadlig kod eller föra över pengar.
Det handlar inte längre bara om ”ett dåligt mejl”. Modernt nätfiske använder molnhostade sidor, fejkade Microsoft 365-inloggningar, QR-koder och stöld av sessions-token.
För företag är konsekvenserna mycket konkreta. I IBM:s rapport Cost of a Data Breach 2025 anges den globala genomsnittskostnaden för ett dataintrång till 4,4 miljoner USD. FBI:s Internet Crime Report 2025 säger att IC3 tog emot ungefär 453 000 klagomål på cyberbrottslighet, med rapporterade förluster på över 17,7 miljarder USD, där business email compromise (BEC) stod för över 3 miljarder USD av detta.
Stöld av inloggningsuppgifter, bedrägliga banköverföringar, leverantörskedjeintrång och tillsynsavgifter — nätfiske påverkar allt detta.
Det som följer: hur proxies passar in i både angripar- och försvarssidan, och hur ett lager-på-lager-försvar faktiskt ser ut i praktiken.
Proxies dubbla natur: din sköld och deras vapen
En proxy är en mellanhand mellan din enhet och internet. I stället för att en webbplats ser din riktiga IP-adress ser den proxyserverns adress. Tänk på det som en postvidarebefordran: mottagaren ser brevet från vidarebefordringsadressen, inte från ditt hem.
Samma egenskap skapar problemet med dubbel användning. Säkerhetsteam använder proxies för att undersöka hot utan att exponera en företags-IP eller en analytikers arbetsstation. Angripare använder exakt samma teknik för att få skadlig trafik att se ut som om den kommer från vanliga användare, andra länder eller betrodda residential-nätverk. Barracudas analys från april 2026 förklarar det tydligt: residential-IP-adresser ser äkta ut eftersom de är kopplade till riktiga hem- eller småföretagsuppkopplingar, vilket gör att bedrägerisystem oftare missar dem.
De flesta konkurrerande artiklar tar bara upp ena sidan. Det ger läsaren en ofullständig bild — och ofullständigt skydd.
Så använder angripare proxies mot dig
Tre huvudsakliga attackvägar är viktigast för företagsförsvarare: anonymitet och IP-rotation, missbruk av residential-proxies samt kringgående av betrodda plattformar.
AiTM (Adversary-in-the-Middle) förklarat
AiTM är attacken som slår hål på antagandet ”MFA skyddar oss” (spoiler: traditionell MFA klarar den inte).
I en AiTM-attack placerar angriparen en reverse proxy mellan offret och en legitim inloggningssida — till exempel Microsoft 365. Användaren ser en inloggning som ser helt äkta ut. De skriver in sina uppgifter, genomför MFA, och den riktiga identitetsleverantören utfärdar en sessionscookie. Men eftersom all trafik passerar genom angriparens proxy fångas sessionscookien upp. Angriparen kan sedan spela upp den igen och få åtkomst till kontot — utan lösenord eller MFA-prompt.
Microsofts analys av Tycoon2FA, ett av de ledande AiTM-nätfiskepaketen, visar att operatörerna kan utge sig för att vara Microsoft 365-, Outlook-, SharePoint-, OneDrive- och Google-inloggningssidor. Paketet skapar PDF:er och QR-koder, hanterar omdirigeringskedjor och följer MFA-användning samt fångst av sessionscookies. Infrastrukturen använder kortlivade subdomäner och Cloudflare-hostad infrastruktur för att försvåra blocklistor.
Inget av detta är teoretiskt. AiTM-kit används aktivt i stor skala, och de är den främsta anledningen till att ”vi har MFA” inte är ett komplett svar på nätfiske.
Missbruk av residential-proxies och IP-rotation
Residential-proxynätverk skickar angriparnas trafik via riktiga hem-IP-adresser, vilket får nätfiskeförfrågningar att se legitima ut och hjälper dem att passera IP-baserad bedrägeridetektion. Många leverantörer verifierar inte noggrant hur deras IP-adresser används, vilket skapar en grå marknad.
Det mest konkreta exemplet: i januari 2026 slog Google Threat Intelligence Group sönder IPIDEA:s residential proxy-nätverk och minskade den tillgängliga enhetsmängden med miljontals. GTIG observerade över 550 enskilda hotgrupper som använde IPIDEA:s utgångsnoder under en enda sjudagarsperiod. Utredningen visade överlapp med botnät, missbruk av SaaS-åtkomst, password spray-attacker och globala spionageaktörer. Många proxy-SDK-implementationer saknade tydligt användarsamtycke.
FBI:s rådgivning från 2026 om residential-proxies listar nätfiske, inloggning med stulna uppgifter, brute force-attacker, kontoövertaganden, spam och C2-döljande som kriminella användningsområden.
Hosting på betrodda plattformar och kringgående av nätfiskekit
En annan kringgåendeteknik: att hosta nätfiskesidor på betrodda plattformar — SharePoint, Google Docs, Azure Blob Storage — för att åka snålskjuts på domänens goda rykte. Microsofts analys av hot mot Azure Blob Storage visar att angripare använder det för att hosta förfalskade Microsoft-inloggningssidor, vilket gör dem svårare för offren att känna igen som skadliga enbart utifrån certifikaten.
Nätfiskekit använder också egen logik för att undvika upptäckt. Cofenses analys av nätfiskekit beskriver filtrering baserad på geolokalisering, användaragent och språk, CAPTCHA, detektion av utvecklarverktyg samt omdirigeringar till legitima sidor. Om en besökare inte matchar den tänkta offerprofilen — fel land, fel webbläsare eller ser ut som en säkerhetsskanner — visas en ofarlig sida eller en 404.
Skanning från en enda företags-IP eller ett molndatacenter missar de här sidorna. Kitet är bokstavligen byggt för att gömma sig för dig.
Så använder försvarare proxies för att slå tillbaka
På försvarssidan har proxies fyra praktiska uppgifter:
-
Anonym URL- och domänskanning. Skicka misstänkta länkar genom en kontrollerad proxy så att destinationssidan ser proxy-IP:n, inte en anställds laptop eller företagets nätverk. Det minskar direkt exponering och skapar en återupprepbar process för utredning.
-
Insamling av threat intelligence. Använd roterande proxies för att crawla nätfiskeinfrastruktur, domänlistor, publika hotflöden eller nyregistrerade domäner utan att bli blockerad efter bara några få förfrågningar. (Alltid inom lagens ramar och villkoren för respektive tjänst.)
-
Geografiskt distribuerad detektion av nätfiske. Använd proxies i flera regioner för att se om en misstänkt URL beter sig annorlunda från USA, EU, APAC eller en annan målmarknad. Det fångar kit som använder geofencing eller filtrering på användaragent — samma kringgåendetekniker som nämndes ovan.
-
Drift av reverse proxy / WAF. Reverse proxies ligger framför dina egna domäner. De stoppar inte anställda från att klicka på externa nätfiskelänkar, men de skyddar dina egna webbtjänster från bottrafik, credential stuffing, skadliga payloads och missbrukande trafikmönster.
Varför MFA ensamt inte räcker mot proxy-baserat nätfiske
Jag har sett den här diskussionen upprepas i otaliga IT-forum: ”Vi har MFA, så vi är skyddade.” Systemadministratörer som faktiskt har hanterat en AiTM-incident ser helt annorlunda på saken.
Mekanismen är enkel. Offret genomför MFA i det som ser ut som ett legitimt inloggningsflöde. Den riktiga identitetsleverantören utfärdar en sessions-token. Angriparen fångar upp den token genom sin reverse proxy.
Autentiseringen lyckades — men angriparen äger nu sessionen. Ett lösenordsbyte räcker kanske inte om aktiva sessioner och angriparens ändringar i MFA fortfarande ligger kvar. Microsoft skriver uttryckligen att drabbade organisationer måste återkalla sessionscookies och rulla tillbaka angriparens MFA-ändringar, utöver vanlig incidenthantering.
SMS-koder, OTP-appar och push-godkännanden kan alla fiskas om användaren genomför dem i ett flöde som angriparen kontrollerar. MFA gjorde sitt jobb. Problemet är att angriparen tittade hela tiden.
Det som faktiskt stoppar AiTM-nätfiske
FIDO2 / passkeys. FIDO Alliance förklarar att passkeys är phishing-resistenta från början: inga lösenord att stjäla och inga inloggningsdata som kan återanvändas. Den kryptografiska nyckelparet är knutet till den legitima domänens ursprung, så en angripares proxy kan helt enkelt inte kopiera utmaningen. CISA bekräftar att FIDO och PKI är de enda brett tillgängliga, icke-proprietära MFA-metoderna som hindrar credential phishing.
Certifikatsbaserad autentisering. Mer företagsanpassat och mer komplext att införa, men lika phishing-resistent eftersom det bygger på enhetscertifikat snarare än koder som matas in av användaren.
Conditional Access-policyer. I Microsoft-miljöer kan Conditional Access kräva kompatibla enheter, betrodda platser, riskbaserade kontroller eller phishing-resistent autentiseringsstyrka — vilket minskar värdet av en stulen sessions-token även om angriparen lyckas få tag i en.
Allt detta kompletterar proxies, inte ersätter dem. Målet är lager.
Praktiska alternativ för små och medelstora företag med begränsad budget
Den uppenbara invändningen: ”Intune, MDM, hårdvarunycklar — det där är enterprise-budget.” Rätt. Här är budgetvägen:
- Webbläsarbaserade passkeys. De flesta moderna webbläsare stödjer passkeys inbyggt. Inget hårdvaruköp behövs. Börja med admin-, ekonomi- och HR-konton.
- Gratis DMARC-implementering. SPF-, DKIM- och DMARC-poster är gratis att publicera. Google Workspace och Microsoft 365 har inbyggda guider för konfiguration.
- Defensiv domänregistrering. Registrera vanliga felstavningar och liknande domäner som liknar ert varumärke. De flesta registrarer tar 10–15 USD per år och domän. Sätt DMARC reject-policy på varje sådan domän.
- Riktad utbildning. Fokusera medvetandeträningen på just AiTM-lurar: falska Microsoft 365-inloggningssidor, fejkade dokumentdelningar, QR-koder, device code-bedrägerier och ”akut lön-/leverantörs”-flöden.
Tänk på det som ”börja här, uppgradera senare”. Även en delvis implementering minskar risken kraftigt.
Vilken proxytyp fungerar bäst för att undvika nätfiske?
Olika proxytyper passar olika anti-nätfiske-behov, och att välja fel slösar pengar eller skapar blinda fläckar.
| Proxytyp | Bästa användning mot nätfiske | Fördelar | Nackdelar | Kostnadsnivå |
|---|---|---|---|---|
| Datacenter | Massskanning av URL:er, domänövervakning | Snabb, billig, hög volym | Lätt att upptäcka för mer avancerade nätfiskekit | Låg |
| Residential | Geotargeterad detektion av nätfiske, test från användarperspektiv | Ser ut som riktig användartrafik, kringgår geoblockering | Långsammare, dyrare, allvarliga etiska frågor kring ursprung | Hög |
| Roterande | Insamling av threat intelligence, långvarig övervakning | Undviker IP-blockeringar vid längre crawlsessioner | Mer komplex installation, varierande latens | Medel |
| Reverse Proxy / WAF | Skydda dina egna webbegenskaper | Filtrerar inkommande hot, botdetektion, skydd mot DDoS | Hjälper inte med upptäckt av utgående nätfiske | Medel |
En notis om etiskt ursprung. Fallet med Google/IPIDEA och FBI:s rådgivning visar tydligt att residential-proxynätverk kan byggas på komprometterade enheter, vilseledande SDK:er, dolda VPN-villkor eller skadlig kod. Innan du köper residential proxy-trafik ska du kräva transparent användarsamtycke, möjlighet att välja bort, spårbarhet och rutiner för hantering av missbruk från leverantören. Leverantörer som tidigare pekats ut i säkerhetsforskning (PacketStream, den numera nedlagda 911 Proxy) bör hanteras med extrem försiktighet.
För de flesta små och medelstora företag är det bäst att börja med datacenter-proxies för massskanning och en reverse proxy/WAF för era egna domäner. Lägg till residential-proxies bara om ni behöver geotargeterad testning och kan granska leverantören ordentligt.
Steg för steg: Så undviker du nätfiske med proxies (ett praktiskt arbetsflöde)
De flesta artiklar stannar vid teorin. Varje steg nedan innehåller ett verktygsförslag och tillräckligt med detaljer för att kunna lämnas till IT-teamet eller följas själv.
Steg 1: Bevaka nyregistrerade liknande domäner
Angripare registrerar domäner som liknar din innan de startar kampanjer: thunderb1t.com, thunderbit-login.com, thunderbit-support.net.
Att upptäcka dem tidigt är en av de mest värdefulla defensiva åtgärderna du kan göra.
Så gör du:
- Bygg en bevakningslista med ditt varumärke, produktnamn, namn på chefer och ord som hör till inloggning (t.ex. ”login”, ”portal”, ”invoice”, ”payment”).
- Fråga Certificate Transparency (CT)-loggar dagligen via crt.sh, där du kan söka certifikatposter efter domän eller organisationsnamn. CT-loggar kräver att publikt betrodda certifikat loggas, så nyutfärdade certifikat för lookalike-domäner syns där.
- Markera domäner med liten stavningsskillnad mot varumärket, misstänkta TLD:er (.xyz, .top, .click) eller ord kopplade till inloggning/betalning.
- Rendera flaggade sidor genom en proxy eller sandlåda — aldrig från en anställds webbläsare.
Thunderbit-koppling: Thunderbit:s batch extract-API kan bearbeta upp till 100 misstänkta URL:er per jobb med renderMode: "full" för att rendera nätfiskekloner som bygger tungt på JavaScript. Du definierar ett JSON Schema för den data du vill ha tillbaka — sidtitel, om ett inloggningsformulär finns, formulärets action-domän, SSL-utgivare, omdirigeringskedja, slutlig URL. CLI-alternativet passar bra i cron-baserad övervakning:
thunderbit batch extract --file suspicious-urls.txt --schema phishing-signals.json --render-mode full
För icke-tekniska användare kan Thunderbit Chrome-tillägget också användas för att snabbt skrapa och granska misstänkta sidor med bara några klick — praktiskt när du bara behöver titta igenom ett fåtal URL:er i stället för att köra ett schemalagt flöde.
Förväntat resultat: En daglig eller veckovis rapport över nyregistrerade lookalike-domäner med strukturerad metadata, redo för triage.
Testa Thunderbit för granskning av misstänkta URL:er
Steg 2: Skicka misstänkta länkar genom datacenter-proxies
Innan någon i organisationen klickar på en misstänkt länk ska den analyseras via en kontrollerad väg. Då är det proxy-IP:n som exponeras, inte medarbetarens enhet eller företagsnätverk.
Så gör du:
- För snabba kontroller, använd urlscan.io (en webb-sandlåda där du kan välja vilket land skanningen ska göras från) eller VirusTotal (skannar URL:er mot dussintals antivirusmotorer och blocklistor).
- För interna skript eller analys i större volym, dirigera förfrågningarna genom en datacenter-proxy:
curl -x http://proxy.example.com:8080 -I "https://suspicious.example"
- För aktiva nätfiskesidor, använd en engångs-VM eller en browser-sandlåda. Stäng av all inmatning av autentiseringsuppgifter. Samla in omdirigeringskedjan, sidtitel, slutdestination, formulärpostningar, skript och skärmdumpar.
- Skicka aldrig riktiga företagsuppgifter. Och var försiktig med publika scans — vissa tjänster visar inskickade URL:er om de inte är inställda som privata eller olistade.
Förväntat resultat: En säker bedömning av länkens mål, beteende och indikatorer — utan att företaget exponeras.
Steg 3: Använd geografiskt distribuerade proxies för att hitta riktade nätfiskekampanjer
Vissa nätfiskekit visar bara skadligt innehåll för besökare från ett visst land eller en viss språkinställning. Cofense visar att geolokaliseringsfilter används ofta: besökare från ”fel” region ser en ofarlig sida eller en 404, medan målgruppen får formuläret som samlar in inloggningsuppgifter.
Så gör du:
- Testa misstänkta länkar från de regioner där dina medarbetare, kunder och ekonomiteam faktiskt arbetar. Om företaget finns i USA men har ett kontor i Storbritannien, testa från båda.
- Jämför slut-URL:er, skärmdumpar, sidtitlar, formulär och HTTP-svarskoder per region.
- Rotera användaragent- och språkinställningar när du granskar QR-kods- eller mobilanpassade lurar — vissa kit filtrerar även på detta.
- Eskalera URL:er som visar ofarligt innehåll på en plats men inloggningsformulär på en annan. Det är en stark nätfiskeindikator.
Förväntat resultat: Upptäckt av geotargeterade kampanjer som skulle vara osynliga med en skanningsmetod från bara en plats.
Steg 4: Sätt upp en reverse proxy eller WAF för dina egna domäner
Nu är det dags att gå från utgående upptäckt till inkommande försvar. Reverse proxies och WAF:er ligger framför dina webbtjänster och inspekterar inkommande trafik innan den når servrarna.
Så gör du:
- Peka din domäns DNS till en leverantör av reverse proxy. Cloudflare är det mest lättillgängliga alternativet för små och medelstora företag — DNS, CDN, WAF och regler finns i samma gränssnitt. För applikationer som körs på AWS fungerar AWS WAF bra om du redan använder CloudFront, ALB eller API Gateway.
- Aktivera hanterade WAF-regler. De blockerar kända skadliga IP-adresser, filtrerar bottrafik och upptäcker mönster för credential stuffing.
- Slå på hastighetsbegränsning för inloggning, återställning av lösenord och kontaktformulär.
- Lägg till bot- eller challenge-regler för riskfyllda endpoints.
- Följ upp WAF-händelser varje vecka — sätt inte bara upp och glöm bort.
Förväntat resultat: Inkommande skadlig trafik filtreras innan den når dina servrar. Försök till credential stuffing mot inloggningssidor blockeras eller får en utmaning.
Steg 5: Automatisera och schemalägg löpande övervakning
Nätfiske är inte en engångskontroll. Nya domäner, kit och infrastrukturer dyker upp varje dag — därför behöver övervakningen ha en tydlig rytm:
- Dagligen: CT-skanning av lookalike-domäner och kö med misstänkta domäner.
- Dagligen eller varje timme (för varumärken med hög risk): Sandlådetest av URL:er för nyligen upptäckta domäner.
- Veckovis: Genomgång av DMARC-aggregatrapporter och mönster för spoofing.
- Veckovis: Granskning av WAF-händelser för credential stuffing och bot-toppar.
- Månadsvis: Kontroll av hur utrullningen av phishing-resistent MFA fortskrider.
- Kvartalsvis: Testa ekonomi- och HR-flöden mot realistiska AiTM- och BEC-scenarier.
Thunderbit-koppling: Thunderbits schemalagda scraping och CLI/API-flöden kan stödja återkommande övervakning för operativa team utan teknisk bakgrund. Det bästa användningsområdet är inte ”Thunderbit stoppar nätfiske på egen hand” — utan ”Thunderbit hjälper operationsteam att samla strukturerade signaler från misstänkta sidor och domänövervakningskällor utan att bygga en egen scraper från noll.” Resultaten kan skickas till Google Sheets eller Airtable för teamets överblick, eller till Slack via en enkel integration.
Förväntat resultat: En kontinuerlig övervakningsloop som fångar nya hot inom timmar, inte veckor.
Vad proxies inte kan fånga: säkra e-post med DMARC, SPF och DKIM
Proxy-leverantörer säger sällan detta: proxies är bara ett försvarslager, men e-postbaserat nätfiske som aldrig passerar genom en proxy kräver ett eget skydd.
Många nätfiskeattacker kommer via förfalskade e-postadresser. En proxy fångar inte upp dem.
Sätt upp SPF med hård avvisning
SPF (Sender Policy Framework) är en DNS-post som listar vilka IP-adresser som får skicka e-post för din domän. Konfigurera med -all (hard fail) i stället för ~all (soft fail) för att direkt avvisa obehöriga avsändare.
Vanlig fallgrop: att glömma alla legitima utskickstjänster — ert CRM, marknadsföringsplattform, leverantör för transaktionsmejl, helpdesk. Granska alla avsändarkällor innan du publicerar posten.
Inför DKIM-signering
DKIM (DomainKeys Identified Mail) lägger till en kryptografisk signatur i utgående mejl. Mottagaren verifierar att meddelandet inte manipulerats under transporten. Både Google Workspace och Microsoft 365 har inbyggda guider för DKIM. Det tar ungefär 15 minuter.
Tvinga DMARC till reject
DMARC (Domain-based Message Authentication, Reporting & Conformance) talar om för mottagande servrar vad de ska göra när SPF- eller DKIM-kontroller misslyckas. Det viktiga steget många organisationer hoppar över: att gå från p=none (endast övervakning) till p=reject (blockera meddelanden som inte klarar kontrollerna) efter att legitima e-postflöden verifierats.
Många organisationer låter DMARC ligga kvar på p=none för alltid — synlighet utan skydd. Det är som att installera en säkerhetskamera men aldrig låsa dörren.
Defensiv registrering av lookalike-domäner
Registrera proaktivt vanliga felstavningar och liknande domäner för ditt varumärke. Sätt DMARC reject-policy på dessa defensiva domäner så att de inte kan användas för spoofad e-post. För 10–15 USD per domän och år är detta en av de billigaste åtgärderna med störst effekt — och många småföretag förbiser det helt.
Så knyter du ihop allt: ett lager-på-lager-försvar mot nätfiske
Inget enskilt verktyg stoppar nätfiske. Det är kombinationen som gör att försvaret håller. Praktisk checklista:
Utgående skydd (utredning av hot):
- Proxy-baserad URL-skanning för misstänkta länkar
- Domänövervakning via CT-loggar och batch-utdrag
- Geografiskt distribuerad testning för regionbaserade kampanjer
Inkommande skydd (skydd av era egna resurser):
- Reverse proxy / WAF för era webbdomäner
- DMARC/SPF/DKIM för e-postautentisering
- Defensiv registrering av lookalike-domäner
Autentisering (skydd av konton):
- FIDO2 / passkeys för phishing-resistent MFA
- Conditional Access-policyer (kompatibla enheter, riskbaserade kontroller)
- Rutiner för övervakning och återkallning av sessions-token
Människor (den sista säkerhetslinjen):
- Utbildning som specifikt fokuserar på AiTM-lurar, QR-koder och BEC-scenarier
- En tydlig rapporteringskultur — gör det enkelt och icke-bestraffande att rapportera misstänkta meddelanden
- Regelbundna tester av ekonomi- och HR-flöden mot realistiska nätfiskescenarier
Det här arbetssättet följer NIST Cybersecurity Frameworks princip om försvar i djupet: flera oberoende lager, så att ett misslyckande inte innebär total kompromettering.
För team som behöver undersöka misstänkta URL:er, skrapa hotdata eller övervaka domäner i stor skala kan Thunderbits AI web scraper snabba upp arbetsflödet — Chrome-tillägg för icke-tekniska användare, API/CLI för tekniska team. Det är inte en säkerhetsprodukt i sig, men den förtjänar en plats i analytikerns verktygslåda. Du kan läsa mer om web scraping utan kod eller utforska tillvägagångssätt för AI web scraping i vår blogg.
Använd AI-web scraping för hotövervakning Get Started Free
Vanliga frågor
Hur använder angripare proxies för nätfiskeattacker?
Angripare använder residential- och roterande proxies för att dölja sin riktiga IP-adress, växla mellan betrodda adresser, kringgå IP-baserad bedrägeridetektion och sätta upp AiTM reverse proxies för att fånga autentiserade sessioner — även efter att offret genomfört MFA. Nedslaget mot IPIDEA i januari 2026 visade att över 550 hotgrupper använde ett enda residential proxy-nätverk.
Hur skyddar en reverse proxy mot nätfiske och kompromettering av webbplatser?
En reverse proxy står framför dina webbservrar och inspekterar inkommande trafik innan den når din infrastruktur. Den blockerar kända skadliga IP-adresser, filtrerar bottrafik, begränsar inloggningsförsök och upptäcker credential stuffing eller nätfiskerelaterad aktivitet. Den skyddar däremot inte anställda från att klicka på utgående nätfiskelänkar.
Kan proxies helt förhindra nätfiske?
Nej. Proxies är ett viktigt lager, men e-postbaserat nätfiske kräver DMARC/SPF/DKIM, och sessionkapning via AiTM-attacker kräver phishing-resistent MFA som FIDO2/passkeys. Ett lager-på-lager-försvar som kombinerar proxies, e-postautentisering, phishing-resistenta inloggningsmetoder och utbildning av anställda är avgörande.
Vad är AiTM-nätfiske och varför stoppar inte MFA det?
AiTM (Adversary-in-the-Middle) använder en reverse proxy mellan offret och den riktiga inloggningssidan och fångar sessions-token efter att MFA har slutförts. Traditionell MFA stoppar det inte eftersom angriparen stjäl den autentiserade sessionen, inte lösenordet. FIDO2/passkeys står emot den här attacken eftersom den kryptografiska utmaningen är bunden till den legitima domänen och inte kan spelas upp igen genom angriparens proxy.
Vilken proxytyp är bäst för att upptäcka nätfiske?
Datacenter-proxies är bäst för massskanning av URL:er (snabba och billiga). Residential-proxies är bäst för geotargeterad testning (realistiska men dyrare — kontrollera leverantörens etiska ursprung). Reverse proxies/WAF:er är bäst för att skydda dina egna webbplatser. Det starkaste upplägget använder en kombination beroende på vad du vill upptäcka eller skydda.
Testa Thunderbit för hotövervakning och AI-scraping Get Started Free
Läs mer
