A Tisza Világ doxxing infrastruktúrájának elemzése, avagy egy kiszivárgott adatbázis utóélete
A Tisza Világ adatvédelmi incidens új fázisa: doxxing-oldalak megjelenése. Elemzés az infrastruktúráról, rendszerszintű tanulságok a digitális visszaélések visszaszorítására.
Figyelmeztetés: A vizsgált szivárogtató oldalak mindegyikét szerencsésen lekapcsolták a bejelentések után, így a bejegyzés megjelenésekor már egyik sem elérhető. Kata elemzése a vizsgált időpontokban fennálló állapotot tükrözi.
ff
2025 őszén a Tisza Világ mobilalkalmazást érintő súlyos adatvédelmi incidens következtében több hullámban került nyilvánosságra az alkalmazásba regisztrált támogatók és érdeklődők személyes adatainak jelentős része. Az adatvédelmi incidens során mintegy 200 000 felhasználó – többségük magyar állampolgár – neve, lakcíme, e-mail címe, telefonszáma jutott illetéktelen kezekbe. Ezt a jogosulatlanul megszerzett, személyes adatokat tartalmazó adathalmazt az elkövetők letölthetővé, illetve böngészhetővé tették az interneten is, bárki számára elérhető módon.
A kiszivárgott adatok strukturált formában történő nyilvános közzététele túllépett a szokványos adattárolás vagy szivárgás keretein: a megosztás szándéka és módja alapján egyértelműen a doxxing (azaz személyes adatok szándékos nyilvános kompromittálása) kategóriájába sorolható.
Jelen elemzés tárgya két olyan nyilvános webes felület infrastruktúrájának vizsgálata, melyek tartalma a fenti incidens során kiszivárgott adatokra épült – vagyis így mindkét oldal a doxxing kategóriába tartozik. Ezek közül az ismertebb a tiszavilag[.]co domain alatt működött, és időközben már elérhetetlenné vált, míg a másik, később megjelent változat jelenleg is aktív, és új szerverháttérrel, eltérő infrastrukturális jellemzőkkel üzemel.
Mivel e második oldal az elemzés készítése idején is elérhető volt, az azon közzétett jogosulatlan tartalom terjesztésének elkerülése érdekében az elemzésben sem annak domainnevét, sem IP-címét nem közöljük.
Elemzésünk kiindulópontja egy névtelenséget kérő, az incidensben áldozatként érintett webfejlesztő vizsgálata, aki mindkét doxxing oldal ügyében – nemcsak Magyarországon, hanem külföldi hatóságoknál és szolgáltatóknál is (a tiszavilag[.]co esetében a német és lengyel adatvédelmi hatóságnál; az újabb oldal esetében a német adatvédelmi hivatalnál, a GoDaddy-nél és a szolgáltatónál) – bejelentést tett GDPR-sértés miatt.
A vizsgálatunk feltárja az elkövetők által alkalmazott domain- és tárhelystratégiákat, azokat a műveleti biztonsági (OPSEC – operational security) hibákat, amelyek gyors beazonosítást és eltávolítást tettek lehetővé a tiszavilag[.]co esetében, valamint a technikai és joghatósági vonatkozásokat, amelyekkel a platform működtetői vélhetően a tartalom fenntartását próbálták biztosítani. A tanulmány külön figyelmet fordít az abuse contact (visszaélés-bejelentési kontakt) pontokon keresztül indított takedown (tartalomeltávolítási) eljárások hatékonyságának vizsgálatára, és bemutatja a kulcsszereplők – például a domainregisztrátorok, tárhelyszolgáltatók és adatvédelmi hatóságok – valószínűsíthető szolgáltatói és hatósági reakcióit.
Elemzésünk rávilágít, hogy a doxxing célú infrastruktúra – még ha előzetesen megtervezett és tudatosan rejtőzködő is – technikai hibák és gyors reagálás esetén sérülékeny maradhat. Ugyanakkor az eset második fázisa rávilágít arra is, hogy a jól integrált, tömegszolgáltatói háttérbe „beleolvadó” megoldások jelentősen megnehezíthetik az eltávolítást. Az események tanulságai túlmutatnak a konkrét ügyön: megvilágítják, hogy az adatszivárgás, a célzott visszaélés és a digitális infrastruktúra kihasználása milyen összefonódásban és milyen kihívások mentén jelenhet meg – technikai, jogi és társadalmi szinten egyaránt.
A vizsgálat kontextusa, előzmények
A 2025 őszén történt Tisza Világ mobilalkalmazást érintő adatlopáson alapuló tömeges adatszivárgás során több hullámban mintegy 200 000 felhasználó személyes adatai kerültek illetéktelen kezekbe. A nyilvánosságra került adatok – nevek, lakcímek, email címek, telefonszámok – érzékenysége, politikai asszociációja súlyos adatvédelmi aggályokat vetett fel.
A kiszivárgott adatokat először fájlformátumban kezdték terjeszteni különböző platformokon, majd hamarosan két különböző infrastruktúrára épülő doxxing weboldal is megjelent: az első (tiszavilag[.]co) interaktív térképes formában, a második (jelenleg is elérhető) oldal pedig táblázatos-kereső alapú elrendezéssel. Míg az első oldal gyorsan eltávolításra került, a második már olyan technikai környezetbe került integrálásra, amely lassabb beazonosíthatóságot és nehezebb tartalomeltávolítást tesz lehetővé.
Az előzmények, az adatszivárgás és a doxxing oldalak idővonala:
2025 Szeptember 9.: A “Tisza Világ” applikáció hivatalos indulása. Az alkalmazás gyorsan népszerűvé vált. Későbbi elemzések kimutatták, hogy a végleges, közel 200 ezer rekordot tartalmazó adatbázisban mintegy 30 ezer olyan fiók szerepelt, amelyet a szeptember 9-i nyilvános indulás előtt hoztak létre, valószínűleg belső tesztelők és önkéntesek számára.
2025. október 6.: Megjelennek az első állítások a Tisza Világ applikáció kompromittálódásáról; Az Index “brutális adatszivárgásról” számolt be, amely “közel húszezer” (18-20 ezer) felhasználót érint. A cikkben közzéteszik az akkor még aktív letöltőlinket is. A hírt átveszi, feldolgozza a mainstream média (többségében az aktív letöltőlink közvetlen megosztása nélkül). Bár az adatok széles körhöz eljutnak, ekkor még nem történik strukturált közzététel.
2025. október 31.: Az incidens eszkalálódik. A teljes (~200 ezer rekord) adatbázis ellopott tartalmának publikus elérhetőségei (különféle fájlmegosztó szolgáltatásokra feltöltve és megosztva) felkerülnek egy nemzetközi szivárogtató fórumra. Az adatcsomag „Tisza Világ app” eredetmegjelöléssel kerül közzétételre. Tartalmazza többek között a felhasználók nevét, lakcímét, telefonszámát, e-mail-címét. Ez az a hiteles, teljes adathalmaz, amelyet a későbbi doxxing oldalak felhasználtak.
2025. november 1.: A Prohardver tech fórum posztot közöl a szivárgásról, megnevezve a szivárogtató fórumot, ahol a letöltő linkek elérhetők. A posztot rövid időn belül eltávolítják. Ezután nem sokkal egyéb közösségi platformokon (pl. Reddit), politikai vonatkozású oldalak cikkeinek hozzászólásai között osztanak meg aktív letöltőlinkeket. Ezek a megosztások rövid időn belül törlésre kerülnek, de a rendelkezésre álló időablakban sokan élnek a letöltés lehetőségével.
2025. november 4.: Egy politikai szereplőhöz köthető körben ismertté válik egy interaktív webtérkép, amely a kiszivárgott adatokat mutatja (valószínűsíthető, hogy ez a tiszavilag[.]co oldal első változata). A domain még nem publikus, de a tartalom már létezik.1
2025. november 6. (08:00): A jelenleg is elérhető (második ismert) doxxing oldal domainjét regisztrálják a GoDaddy-nél.
2025. november 6. (17:08): A tiszavilag[.]co domaint regisztrálják a Spaceship, Inc.-nél.
2025. november 6. (este): A Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) közleményt ad ki, amelyben felhívja a figyelmet arra, hogy a politikai pártok adatbázisaiból nyilvánosságra került személyes és különleges adatok médiatartalmakban történő felhasználása súlyos adatvédelmi követelményeket sérthet. Bár a közlemény nem nevesíti a térképes doxxing oldalt, a sajtóbeszámolók alapján a Hatóság vélhetően már ekkor értesült a konkrét esetről is. 2
2025. november 7. (délelőtt): Az Index cikke beszámol a térképes oldal létezéséről, de nem osztja meg a linket. Megerősíti a hatósági álláspontot és adatvédelmi aggályokat részletez.
2025. november 7. (délután): A Magyar Nemzet is tesz közzé cikket és kezdetben aktív linket is megoszt az oldalhoz, majd ezt eltávolítják. A térkép így szélesebb közönséghez jut el. A mainstream média nagy része ír az incidensről, de aktív link közzététele nélkül, felhívva a figyelmet a súlyosbodó adatvédelmi incidens következményeire.
2025. november 7. (19:43–21:13): Az “anonim webfejlesztő” a jogosulatlanul közzétett adathalmazban felismerve a saját adatait, ezzel realizálva az érintettségét az áldozati oldalon, mint az adatvédelmi incidensben érintett, több irányban tesz bejelentést: a tárhelyszolgáltatóhoz (1337 Services), a domainregisztrátorhoz (Spaceship), a német adatvédelmi hatósághoz (BfDI) és a DNS-szolgáltatóhoz (Cloudflare).
2025. november 7. (késő este): Több hazai internetszolgáltató (pl. Telekom) elkezdi blokkolni a tiszavilag[.]co domaint.
2025. november 8.: A tiszavilag[.]co domain a magyar internetszolgáltatóknál elérhetetlenné válik.
2025. november 9. (reggel): A tiszavilag[.]co domain globálisan is elérhetetlenné válik – valószínűleg regisztrátori felfüggesztés miatt.
2025. november 9. (délután): Aktiválódik az új, jelenleg is elérhető doxxing oldal, immár keresőalapú interfésszel. Az “anonim webfejlesztő” itt is megtalálja a személyes adatait, és bejelentéseket tesz az érintett oldal elérhetősében intézkedni jogosult illetékeseknél (GoDaddy, Host Europe, BfDI).
2025. november 10.: A NAIH második, kapcsolódó közleményében már kifejezetten a térképes megjelenítést ítéli jogellenesnek, és hangsúlyozza: a személyes adatok ilyen formában való közzététele súlyosan sérti az adatvédelmi követelményeket. 3
A hazai médiumokban megjelent sajtóhivatkozások, valamint az anonim webfejlesztő által tett bejelentések időbélyege CET (közép-európai idő), azaz UTC+1 alapján került rögzítésre, még a többi időpont UTC szerinti.
Az idővonal alapján jól látható, hogy a doxxing oldalakhoz kapcsolódó eseménysor rendkívül gyorsan, alig egy hét alatt zajlott le:
a strukturált adatbázis nyilvános megjelenésétől (október 31.) számított néhány napon belül már aktív volt a tiszavilag[.]co domain alatt működő, interaktív térképes felület, majd az oldal lekapcsolása után szinte azonnal megjelent a keresőfelületre épülő második generációs platform is.
A válaszlépések – például a NAIH közleménye, az abuse contact pontokra történő bejelentések, illetve a magyar internetszolgáltatók szűrési intézkedései – szintén viszonylag rövid idő alatt megtörténtek. Ugyanakkor az incidens dinamikája azt mutatja, hogy az oldal üzemeltetői gyorsan alkalmazkodtak: az új domainregisztrációk és a tárhelyszolgáltató-váltások révén néhány órán belül képesek voltak második platformot indítani.
Ez a gyorsaság és reakcióképesség rávilágít arra, hogy a hasonló típusú, adatszivárgáson alapuló doxxing oldalak és dezinformációs műveletek esetén a hatósági és szolgáltatói fellépés mellett elengedhetetlen a proaktív technikai monitoring – például tanúsítvány-figyelés (CT-log), új domainnevek figyelése, vagy WHOIS-változások követése. Az infrastrukturális mintázatokból gyakran visszafejthetők a szereplők operatív döntései, ami segíti az azonosítást és a védekezési mechanizmusok kiépítését is.
A következő fejezetekben először a tiszavilag[.]co domain regisztrációs és infrastrukturális sajátosságait mutatjuk be részletesen, rávilágítva azokra a műveleti biztonsági (OPSEC) hibákra, amelyek hozzájárultak a gyors beazonosításhoz és a tartalom eltávolításához. Ezt követően áttérünk a jelenleg is elérhető, frissen aktivált platform technikai felépítése és a kevésbé látható, de összetettebb hosting-stratégiák elemzésére.
Célunk, hogy végigkövessük az infrastruktúrafejlesztés logikáját a domainnév-választástól és a DNS-konfigurációktól kezdve a hosztingplatformok megválasztásán át egészen a tartalom publikálási technikáiig – bemutatva egy politikailag motivált doxxing platform evolúcióját, működési mechanizmusait és lehetséges visszavezethetőségi pontjait.
Domain- és regisztrációs környezet: tiszavilag[.]co
A doxxing célú weboldalak életciklusában az első technikai nyom gyakran maga a domainregisztráció. A tiszavilag[.]co oldal esetében ez különösen igaz: a választott regisztrátor, a regisztráció időpontja, valamint a tanúsítvány-lábnyomok és a nyilvános CT-log (Certificate Transparency log – tanúsítvány-napló) rekordok egyaránt olyan metainformációkat tártak fel, amelyek hozzájárultak a domain gyors beazonosításához és a tartalom későbbi lekapcsolásához.
A domainregisztráció időpontja és környezete
A tiszavilag[.]co domaint 2025. november 6-án, 17:08:22 UTC időpontban jegyezték be a Spaceship, Inc. nevű regisztrátoron keresztül. A választott TLD (Top-Level Domain – legfelső szintű domain) a .co volt, amelyet gyakran használnak alternatív névformaként – például .com-os címek elfoglaltsága esetén, vagy tudatos álcázási céllal. A domain névválasztás direkt módon utal a Tisza Világ alkalmazásra, ezáltal az oldal célja már a név alapján is jól beazonosítható, szűkíthető.
A domain regisztrációjának időzítése különösen beszédes: mindössze két nappal azután történt, hogy a kiszivárgott teljes adatbázis (~200 000 rekord) jogosulatlan másolatainak letöltőlinkjei megjelentek az egyik adatszivárogtató platformon, és egy nappal azután, hogy a politikai közéletben is ismert szereplő közösségi posztban utalt egy, az érintett adatbázisban elérhető személyes adatokat felhasználó interaktív térképes megjelenítésre.
Ez az időbeli közelség nemcsak az oldal mögötti reakcióidőt jelzi, hanem azt is alátámasztja, hogy a domainregisztráció valószínűsíthetően már előkészített, szándékos lépés volt az adatbázis publikálásának támogatására.
A választott regisztrátor és OPSEC-implikációk
A regisztrátor, Spaceship, Inc., a Namecheap-hez tartozó leányvállalat, amely egyre népszerűbb azok körében, akik gyors, olcsó és viszonylag kevés regisztrációs adatot kérő domainvásárlási lehetőséget keresnek. Bár önmagában nem „bulletproof” szolgáltató, a Spaceship nem tartozik a legszigorúbban ellenőrzött vagy szorosan szabályozott regisztrátorok közé sem.
A WHOIS-rekord alapján a domainhez kapcsolódó regisztrációs információk – szokás szerint – proxy védelemmel kerültek elfedésre (Domain Proxy LLC). Ez azonban a CT-log (tanúsítvány-napló) elemzése során részben visszafejthető volt. A nyilvános CT-log alapján a domainhez 2025. november 6-án 17:17 UTC körül került kiállításra tanúsítvány a ZeroSSL szolgáltatón keresztül, ami megerősíti, hogy a domainregisztrációt követően gyakorlatilag perceken belül elindult a webes infrastruktúra kiépítése.
Ezek a tanúsítvány-lábnyomok olyan publikus adatbázisokban is elérhetők, mint pl. a Censys vagy a crt[.]sh, és mivel a kiállító CA (Certificate Authority) – jelen esetben ZeroSSL – viszonylag kevés metaadatot kér, az ilyen kombináció tipikusan olyan szereplőkre utal, akik gyors, automatizált telepítést preferálnak, nem pedig hosszú távú stabilitást.
Feltárt operatív hibák: túl gyors telepítés, nyomokat hagyó tanúsítványok
A Certificate Transparency (CT) logokban a tiszavilag[.]co domainhez kapcsolódóan két szokatlan aldomain is megjelent 2025. november 7-én: fdsa[.]tiszavilag[.]co és www.fdsa[.]tiszavilag[.]co. Ezekre a Let’s Encrypt tanúsítványkibocsátóval történt hitelesítési kérelem utal, amely vélhetően az üzemeltető kapkodó vagy kísérleti HTTPS-beállításainak nyoma volt. (Az „fdsa” karakterkombináció tipikus tesztsztringnek számít, amit gyakran használnak scriptelés vagy tanúsítványgenerálás során.)
Ha a szivárogtatók komolyan vették a feladatot akkor pedig lehet ez is:
”Federated Data Sharing Adapter”4.
De elnézve ezt az összetákolt oldalt, nem tartom valószínűnek.ff
Ezek az anomáliák megerősítik azt a feltételezést, hogy az oldal élesítése után még vélhetően zajlottak beállítási kísérletek, és az infrastruktúra még nem volt teljesen előkészítve.
Egy másik jelentős OPSEC-hiba az volt, hogy a domain regisztrációját követően nem történt semmilyen időbeli eltolás, vagy „padding” a különböző technikai lépések között: perceken belül történt meg a tanúsítványbeszerzés, a DNS-konfiguráció és az oldal élesítése. Ez a fajta „túl gyors” automatizált telepítés gyakran fordul elő azoknál az üzemeltetőknél, akik nem ismerik a visszafejthetőség kockázatait – vagy nem számolnak hosszú távú rejtve maradással.
A tiszavilag[.]co domain regisztrációs metainformációi és a tanúsítványlábnyomok tehát már önmagukban is számos OPSEC-rést tártak fel. Ugyanakkor a technikai hibák valódi súlya akkor válik nyilvánvalóvá, amikor megvizsgáljuk, hogyan lett a domain névhez tartozó infrastruktúra – annak ellenére, hogy Cloudflare-re épült – néhány óra alatt beazonosítható. A következő fejezet éppen ezt a DNS-réteget veszi górcső alá: azt a konfigurációs hiányosságot, amely a szándékos elrejtés helyett éppen hogy lelepleződéssé vált, és lehetővé tette az origin infrastruktúra gyors feltérképezését.
DNS infrastruktúra (tiszavilag[.]co): A Cloudflare szerepe és a kritikus konfigurációs hiba
A doxxing platformok esetében a technikai rejtőzködés egyik legfontosabb rétege a DNS-konfiguráció: a jól beállított tartománynév-kiszolgálás kulcsszerepet játszik az origin szerver elrejtésében, különösen, ha Cloudflare típusú proxy szolgáltatás áll a domain előtt. A tiszavilag[.]co oldalnál ugyanakkor éppen ez a védekezési vonal bizonyult átláthatónak: a DNS-beállítások hibái lehetővé tették az infrastruktúra szinte azonnali visszafejtését.
A Cloudflare szerepe: védelem vagy álcázás?
A domainhez rendelt nameserver rekordok alapján a tiszavilag[.]co a Cloudflare szolgáltatását használta, ami első ránézésre teljesen szokványos gyakorlat. A Cloudflare nemcsak DDoS-védelemre, hanem az origin IP elrejtésére is szolgál, és gyakran alkalmazzák webes proxyként azok, akik érzékeny, vagy nehezen vállalható tartalmat kívánnak hosztolni. A doxxing oldal készítői is vélhetően ilyen álcázási céllal vezették át a domain DNS-ét a Cloudflare-n – azonban hibás implementáció mellett ez a védelem könnyen formálissá válik.
A DNS-ből ugyanis azonnal lekérdezhető volt az oldalhoz tartozó A rekord, amely közvetlenül az origin IP-címet – 45.138.16.233 – adta vissza. Ez a cím a 1337 Services GmbH által működtetett AS210558-as hálózathoz tartozik és geolokáció alapján Varsóban (Lengyelország) található. Bár technikailag Németországban regisztrált szolgáltatóról van szó, az IP fizikailag nem ott található, amely további joghatósági kérdéseket is felvet.
Konfigurációs hiányosságok és OPSEC-rés
A DNS-zónaelemzés alapján nem volt sem wildcard-rekord5, sem CNAME-masking6 vagy split-horizon technika7, amelyek legalább részben leárnyékolták volna az origin infrastruktúrát. A konfiguráció egyszerű és direkt volt: az alapértelmezett A rekord közvetlenül az origin IP-re mutatott, és semmilyen logika nem akadályozta annak tömeges lekérdezhetőségét.
Ez a szintű transzparencia – különösen a Cloudflare-használat mellett – egyértelmű operatív biztonsági hiba. Ha az üzemeltetők célja valóban az origin elrejtése volt, a megvalósított DNS-réteg ezt teljes mértékben aláásta. A technikai hibát tovább erősíti, hogy a tanúsítványlogokban (CT-log) rögzített fdsa[.]tiszavilag[.]co aldomain a Cloudflare-től függetlenül is visszavezethető volt az origin IP-re – tehát több nyilvános nyomvonal is konvergált ugyanarra az endpointra.
A feltárt indormációk alapján valószínűsíthető, hogy a domain- és hosting-környezet „gyors élesítése” miatt nem történt szakszerű DNS-hardening. A konfigurációs felületre jellemző volt a default értékek meghagyása, a minimális rejtési szinttel. Ezzel nemcsak a detektálást, hanem a tartalommal szembeni beavatkozást (takedown) is megkönnyítették, hiszen a Cloudflare-n túlmutató, valós infrastruktúra viszonylag gyorsan elérhetővé vált.
A tiszavilag[.]co esetében a DNS-réteg nem védelmi vonalat, hanem gyakorlatilag egy nyitott ajtót jelentett: az origin IP-cím elrejtésére tett látszatintézkedéseket a hibás konfiguráció teljesen semmissé tette. Ez a technikai rés nem csupán a weboldal gyors beazonosításához, hanem a hozzá tartozó infrastruktúra és szolgáltató feltérképezéséhez is vezetett. A következő fejezet ennek az origin infrastruktúrának a részleteit vizsgálja meg: hogyan illeszkedett a hostingkörnyezet a „bulletproof” típusú szolgáltatói gyakorlatba, és milyen következményekkel járt ez a lekapcsolási folyamatokra nézve.
Az Origin infrastruktúra (tiszavilag[.]co): A „Bulletproof” szolgáltató szándékos választása
A doxxing platform működtetői számára kulcskérdés, hogy milyen infrastruktúrára építik fel a kiszolgálói hátteret. A cél nyilvánvaló: a tartalom technikai elérhetőségének és védelmének biztosítása a takedown (eltávolítási) kérelmekkel és a visszaélés-bejelentésekkel (abuse contact) szemben.
A tiszavilag[.]co esetében a választott infrastruktúra – a 1337 Services GmbH által üzemeltetett hálózat – a „bulletproof hosting” klasszikus jegyeit hordozza.
Az alábbiakban bemutatjuk, hogyan válik ez az origin környezet a rejtőzködés eszközévé, miközben számos nyilvános nyomvonal révén mégis gyorsan feltérképezhetővé vált.
Az origin IP-cím és hálózati hovatartozása
A domainhez tartozó DNS-bejegyzések alapján az oldal egyetlen origin IP-címe a 45.138.16.233 volt. Ez az IP-cím a 1337 Services GmbH (AS210558) német tárhelyszolgáltatóhoz tartozik, de a geolokációs lekérdezések szerint fizikailag Varsóban (Lengyelország) található szerveren üzemelt. Az ilyen kettős hovatartozás – német AS, de lengyel szerver – nem ritka a bulletproof típusú szolgáltatóknál: céljuk a technikai széttagolás és a joghatósági bizonytalanság fenntartása.
A 1337 Services GmbH ismertsége nem véletlen: több, visszaélésgyanús vagy célzott lejárató kampányt futtató oldal infrastrukturális háttereként azonosították már.
A KrebsOnSecurity által 2025 szeptemberében publikált vizsgálat például részletesen bemutatja, hogyan kerüli meg a szolgáltató az uniós szankciós mechanizmusokat és compliance-előírásokat8. A cikk a 1337 Services AS-ek és egyéb alternatív struktúrák (pl. Stark Industries) közti átfedéseket is részletezi, alátámasztva, hogy az infrastruktúra szisztematikusan törekszik az észrevétlenségre, ugyanakkor ismétlődő mintázatokat hordoz – például az abuse-tartalmak gyors migrálására, a DNS-időtartamok minimalizálására és az automatizált replikációra.
A szolgáltatóválasztás mint OPSEC-döntés
A tiszavilag[.]co technikai kiépítésében a 1337 Services GmbH bevonása nem tűnik véletlenszerű döntésnek. A regisztrátor kiválasztása (Spaceship) és a CDN-szolgáltatás (Cloudflare) mellett az origin hosting partner kiválasztása is valószínűsíthetően előre megfontolt döntés volt, amely a visszafejthetőség és a szolgáltatói együttműködés minimalizálására törekedett.
Fontos tényező, hogy a 1337 Services nem rendelkezik közvetlen ügyfélazonosítást kötelezővé tevő folyamatokkal, és abuse-kapcsolattartói (abuse contact) válaszideje gyakran jelentősen elmarad a szabványos iparági SLA-értékektől. Ez azt eredményezi, hogy egy illegális vagy jogsértő tartalom ellen irányuló fellépés (pl. domainlekapcsolás vagy IP-tartalom blokkolás) lassabb, többszintű és hatósági szinten is koordinációt igénylő folyamatként valósulhat meg.
Nyilvános visszafejthetőség: hosting információk mint bizonyító nyomok
Noha az origin IP technikailag a Cloudflare mögé került, a konfigurációs hibák és a tanúsítványlogok révén visszafejthetővé vált. A 45.138.16.233 IP WHOIS-információi, ASN lekérdezések, valamint szolgáltatói kapcsolatok alapján gyorsan összeállt a kép: az oldal a 1337 Services által kontrollált infrastruktúrán futott. Ez lehetővé tette, hogy a névtelenséget kérő, az incidensben érintett webfejlesztő már a megjelenést követő első 24 órában bejelentést tegyen a szolgáltatónál, illetve az infrastruktúrát kiszolgáló CDN-nél és német adatvédelmi hatóságnál.
Az oldal gyors elérhetetlenné válásához így nem csupán a tartalomszolgáltatók (pl. Cloudflare), hanem az origin hosting partner irányában megtett fellépések is hozzájárultak – még ha ezek nem is azonnali hatással, hanem fokozatos lefedéssel érvényesültek (pl. elsőként magyar ISP szintű blokkolás, majd globális DNS-szintű felfüggesztés).
Az origin infrastruktúra nyomvonalainak visszafejtése, valamint a bulletproof típusú hosting háttér gyors feltárása alapjaiban kérdőjelezte meg a doxxing oldal rejtve tartásának sikerességét. A szolgáltatói válaszlépések és a technikai metainformációk alapján a következőkben arra térünk ki, hogyan működött maga a webes alkalmazás: milyen technológiai eszközökkel és vizualizációs logikával építették fel, és milyen további OPSEC-hibák voltak visszafejthetők a megvalósítás szintjén.
Technikai implementáció és operatív biztonsági (OPSEC) nyomok (tiszavilag[.]co)
A tiszavilag[.]co weboldal nem csupán tartalmában, hanem technikai megvalósításában is egyértelműen a doxxing típusú kompromittáló szándékot tükrözte. Az alábbiakban a felhasználói felület működését, a vizualizációs logikát, az adatstruktúrák kezelését, valamint a detektálható műveleti biztonsági (OPSEC – operational security) hibákat mutatjuk be. Az elemzés célja, hogy rávilágítson: a site implementációja nemcsak etikai és jogi, hanem súlyos technikai kockázatokat is hordozott, különösen az átlátható adatátvitel és a minimális védelmi rétegek miatt.
Kliensoldali működés és JSON-alapú adattöltés
Az oldal központi funkciója egy interaktív térkép volt, amelyen a Tisza Világ adatszivárgásban érintett felhasználók adatai – többek között név, lakcím, irányítószám – geolokációs pontok formájában jelentek meg. A névtelenséget kérő, az incidensben áldozatként érintett webfejlesztő technikai elemzése szerint az oldal frontendje a Leaflet nevű, nyílt forráskódú JavaScript-alapú térképkönyvtárra épült, amely kliensoldali renderelést alkalmaz – ez fontos kiindulópontot biztosítot a technikai visszafejtéshez.
A technikai kivitelezés szempontjából - a Leaflet térképkönyvtár használatából adódóan - a site nem alkalmazott szerveroldali dinamikus betöltést: minden adatot egyetlen, kliensoldalon betöltődő JSON-fájl tartalmazott, amely automatikusan töltődött le a látogató böngészőjébe a térkép inicializálásakor.
Ez a megoldás minimálisra csökkenti az infrastruktúra komplexitását (nem szükséges backend API, adatbázis-hívás), viszont rendkívül súlyos OPSEC-hibát eredményez.
A JSON-fájl nemcsak a térképhez szükséges metaadatokat, hanem az összes doxxolt személy lakcímét és nevét tartalmazta – strukturált, géppel könnyen feldolgozható formában. Így az oldal minden látogatója automatikusan megkapta a teljes adattömeget, függetlenül attól, hogy rákeresett-e konkrét névre vagy helyszínre.
Ez a módszer nemcsak az érintettek magánszféráját sérti drasztikusan, de technikailag is azt eredményezte, hogy az adatbázis egy lépésben – különösebb védelmi megkerülés nélkül – letölthető és archiválható volt.
Az implementációs hibából következően a JSON-fájl közvetlen URL-en keresztül is elérhető volt, ami lehetővé tette a fej nélküli böngészők (headless crawler) vagy egyszerű parancssoros scriptek általi tömeges lekérdezést is.
Vizualizációs logika: érzékeny adattérképezés
A térkép vizuális struktúrája egyértelmű célt szolgált: az adatokat nem lista vagy keresőfelületen, hanem lakóhely alapján geolokáció szerinti elrendezésben tette elérhetővé. Az adatszivárgás kontextusában – amely a Tisza Világ alkalmazás regisztrált felhasználóit, azaz politikai érdeklődőket vagy szimpatizánsokat érintette – ez a vizualizációs stratégia direkt fenyegetettséget eredményezett.
A térkép szolgáltatta koordináták túlnyomó többsége valódi, nyilvánosan azonosítható lakcímekre mutatott. Nem csupán városi szinten volt lehetséges a szűrés, hanem utcára és házszámra lebontva is. Ezzel az oldal nem pusztán hozzáférést biztosított egy személyes adattömeghez, hanem kontextualizált, célzott fenyegetési potenciált hozott létre.
A vizualizációs megközelítés technikai megvalósítása ráadásul minimális adatvédelmi korlátokat alkalmazott.
Nem történt például:
adatredukció (obfuscation),
adatintervallumokra bontás (pl. város szintű csoportosítás),
előzetes keresés szükségessége a hozzáféréshez.
Ehelyett a nyers adatokat közvetlenül, strukturálatlanul, de célratörően jelenítette meg – ami különösen érzékeny kitettséget jelentett például a kis településeken élő érintettek esetében.
A Leaflet-alapú frontend struktúra tehát – amelyről az érintett anonim forrás számolt be – nemcsak az adatok térképi vizualizációját tette lehetővé, hanem technikailag is megkönnyítette a tömeges adatletöltést és automatizált másolást, mivel az adattartalom egyetlen JSON-fájlként töltődött be a kliensoldalon.
OPSEC-hibák és visszakövethetőség
A technikai implementáció több olyan műveleti biztonsági hibát hordozott, amelyek közvetlenül hozzájárultak a domain és a szolgáltató gyors azonosításához.
Domain-szintű tanúsítványlefedettség: Ahogyan korábban már említettük, a tanúsítványlogokban (CT-log) megjelentek nem publikált subdomain-ek is (pl. fdsa[.]tiszavilag[.]co). Ezek alapján következtethető, hogy a Let’s Encrypt vagy ZeroSSL automatikus tanúsítványkibocsátásával a szerver teljes wildcard lefedettséget állított be, amelynek látható nyomai maradtak nyilvános adatbázisokban.
Nem használt backend interfészek: A site nem rendelkezett sem autentikációval, sem háttérrendszerrel. Ez ugyan csökkenti a támadási felületet, de azt is jelenti, hogy a teljes adattartalom védtelenül és szűrés nélkül jelenik meg minden látogató számára.
Monitoring és visszajelző rendszer hiánya: Semmilyen tartalomvédelmi mechanizmus (pl. referer header szűrés, request limit) nem volt megfigyelhető. Ez azt jelenti, hogy egy automatikus letöltési kísérletre semmilyen szerveroldali válasz vagy blokkolás nem aktiválódott.
A tiszavilag[.]co technikai megvalósítása egyértelmű céllal épült: az adatok strukturált, célzott kompromittálására. Az implementáció egyszerűsége, a kliensoldali adattöltés, a hiányzó védelem és a térképes vizualizáció mind azt szolgálta, hogy az adatszivárgás ne csak információként, hanem fenyegetésként is megjelenjen. A gyors detektálást segítő OPSEC-hibák ellenére azonban a platform ideiglenesen betöltötte szerepét – és ez már elegendő volt ahhoz, hogy egy második generációs verzió, egy replikáció induljon el, új infrastruktúrával és módosított implementációval.
A következő fejezetben e doxxing tartalom replikációját, technikai adaptációját és az azt kiszolgáló eltérő infrastrukturális és operációs döntéseket vizsgáljuk meg: hogyan jelent meg a jelenleg is aktív doxxing olda, és mi teszi annak takedown-ját jóval nehezebbé.
Replikáció és evolúció: Az újabb doxxing oldal
A tiszavilag[.]co domain gyors lebukása, valamint a szolgáltatói takedown (eltávolítási) lépések hatékonysága ellenére a kompromittált adatok nem tűntek el: néhány nappal az oldal globális elérhetetlenné válása után megjelent egy új platform, amely strukturálisan ugyanazt az adathalmazt kínálta, de eltérő technikai és operatív megvalósításban. Az oldal jelenleg is elérhető, ezért domainnevét és IP-címét a jelen elemzés nem közli.
Az alábbi fejezet a replikációs technikát, a megváltozott infrastrukturális döntéseket és a detekciós nehézségek hátterét vizsgálja, külön figyelmet szentelve az Tisza Világ adatszivárgáshoz kapcsolódó első és második generációs doxxing platformok közti különbségeknek.
Domain és DNS-környezet: ismertebb szolgáltatóval, kevésbé feltűnően
A második oldal domainregisztrációját a GoDaddy szolgáltatónál jegyezték be 2025. november 6-án, 08:00 UTC időbélyeggel – azaz megelőzte a tiszavilag[.]co regisztrációját. Ez alapján feltételezhető, hogy az elkövetők már a kezdetektől több lehetséges domainnévben gondolkodtak és alternatívákat is fenntartottak arra az esetre, ha az első oldalt gyorsan lekapcsolják.
A regisztrációs adatok – WHOIS, DNS, tanúsítványlogok – alapján az új oldal jóval „szabályosabb” infrastruktúrán működik:
a GoDaddy mint regisztrátor kevésbé számít kompromittált szereplőnek,
a DNS-beállítások nem árulják el az origin IP-címet,
a Cloudflare-hez hasonló rejtő proxy-réteg nem használatos, de a hosztolás a szolgáltatón belüli tömeginfrastruktúrába simul bele.
Ez a konfiguráció nem egyértelmű elrejtésre, hanem láthatatlanná beolvadásra törekszik: a domain viselkedése és technikai paraméterei alapján nehezen különböztethető meg egy átlagos kisvállalati oldalétól.
Hosztolás: szolgáltatói háttér és szerver-stack
A szerverstack jellemzői – nginx, Plesk, tipikus szerverválaszfejlécek – azt mutatják, hogy az oldal egy tömeges shared hosting környezetben fut. Nincs dedikált IP, nincs saját ASN vagy külön origin infrastruktúra. Ez különösen megnehezíti:
a visszafejtést (mivel az IP-cím más oldalakkal is megosztott),
a szolgáltatói fellépést (hiszen a takedown azonosításhoz több manuális vizsgálat kell),
és a szolgáltatóra nehezedő nyomást is (mivel nehezebb bizonyítani a domain illegitim természetét).
A DNS-lekérdezések és CT-log tanúsítványnyomok alapján a szolgáltató európai adatközpontban hosztolja az oldalt, de a pontos lokalizáció (földrajzi és joghatósági szempontból) nem egyértelmű – és valószínűleg ez volt a cél is.
Funkcionális váltás: térkép helyett kereső és táblázat
Az új platform felhasználói felülete jelentősen eltér az elődtől. Az interaktív térképet egy keresőmező és szűrhető táblázat váltotta fel, amelyben:
a nevek és címek listás nézetben jelennek meg,
a keresés név, címrészlet vagy település szerint is működik,
és az adatok kisebb csoportokban, lapozható formában tölthetők be.
Ez az architektúra informatikai szempontból több előnyt nyújt:
nem egyszerre tölt le minden adatot, nehezítve a teljes tömegletöltést,
kevésbé feltűnő szerveraktivitást generál,
és nem alkalmaz vizualizációt, ami médiaszempontból kevésbé „megragadható”.
Ugyanakkor az oldal tartalma változatlanul ugyanabból a kiszivárgott adathalmazból dolgozik – strukturált, kereshető formában teszi elérhetővé a doxxolt személyes adatokat.
Detekciós és eltávolítási nehézségek
A webfejlesztő forrás észlelése alapján az új oldal észrevehetően stabilabb elérhetőséget mutatott, még a domain beazonosítása után is. A bejelentésekre – GoDaddy, szolgáltató, német adatvédelmi hatóság – hosszabb idő alatt és nem minden esetben történt tényleges tartalom-eltávolítás.
Ennek okai lehetnek:
a szolgáltató nem minősíti önmagában a kereshető adattartalmat „egyértelműen illegálisnak”,
a domain viselkedése (alacsony látogatottság, alacsony forgalom) nem kelt kiemelt figyelmet,
a tárhelymegosztás jogi és technikai akadályokat gördít a takedown gyors végrehajtása elé.
A Leaflet-alapú térképes struktúra hiányában a médianyomás is kisebb: nem generál vizuálisan megragadható, politikailag érzékeny szimbólumot, így a médiafigyelem és az ebből fakadó gyors reagálás is hiányzik.
Az első és második generációs oldal közti különbségek azt mutatják, hogy az elkövetők, amennyiben ugyanazok állnak mögötte, tanultak a kezdeti lebukásból: az új infrastruktúra már nem nyílt konfrontációra, hanem fokozatos láthatatlanságra épül. A domain technikai viselkedése, a szolgáltatóválasztás és az architektúra mind arra utalnak, hogy a platform hosszabb távú működésre rendezkedett be – ugyanazt az adathalmazt használva, de kevésbé detektálható módon.
A következő fejezetben azt vizsgáljuk, hogyan reagáltak a különböző szereplők – regisztrátorok, tárhelyszolgáltatók, hatóságok – a bejelentésekre, és milyen tapasztalatokat vonhatók le az érintettek oldalán a visszaélés-bejelentési folyamatok hatékonyságáról.
Bejelentési tapasztalatok és takedown-hatékonyság
A doxxing oldalak gyors felfedését követő egyik legkritikusabb szakasz a visszaélés-bejelentési és tartalomeltávolítási (takedown) folyamat. Ezek hatékonysága nemcsak a szolgáltatói hajlandóságtól, hanem az infrastruktúra komplexitásától, a bejelentés pontosságától és a joghatósági környezettől is függ. Ebben a fejezetben az elemzés során azonosított konkrét bejelentések, válaszidők és szolgáltatói reakciók mentén vizsgáljuk meg, hogyan zajlott a fellépés a tiszavilag[.]co, majd később az új, jelenleg is elérhető oldal esetében.
Az alábbi tapasztalatok alapját részben egy névtelenséget kérő, érintett webfejlesztő dokumentált bejelentései és tapasztalatai adják, kiegészítve publikus adatforrásokkal és sajtóban megjelent visszajelzésekkel.
Tiszavilag[.]co: többcsatornás, gyors reakciókat kiváltó fellépés
A tiszavilag[.]co domain ellen több irányban indult bejelentés 2025. november 7-én este, néhány órával a médiamegjelenések és a NAIH (Nemzeti Adatvédelmi és Információszabadság Hatóság) nyilatkozata után. Az alábbi címzettekhez érkezett bejelentés:
A koordinált bejelentéssorozatnak köszönhetően az oldal előbb magyar internetszolgáltatóknál (pl. Telekom) vált elérhetetlenné – vélhetően DNS-blokkolás révén –, majd 2025. november 9-én reggel globálisan is leállt. Az időzítés alapján valószínűsíthető, hogy a domainregisztrátor (Spaceship) felfüggesztette a domaint.
A második szivárogtató weboldal: lassabb és bizonytalanabb reakciólánc
A jelenleg is elérhető doxxing oldal esetében a bejelentések azonos intenzitással indultak meg, de kevesebb eredménnyel zárultak:
A különbségek oka részben technikai: a második oldal tömegszolgáltatói háttérben, shared hosting környezetben fut, így egyedi IP vagy infrastruktúra felfüggesztése jogilag és technikailag is nehezebb. Ráadásul a regisztrátor (GoDaddy) működési gyakorlata szerint a beavatkozás csak akkor történik meg, ha közvetlen, bizonyítható jogsértés áll fenn – ez a kereshető, de nem vizuális doxxing tartalom esetében vitatható értelmezéshez vezet.
Tapasztalati tanulságok és következtetések
A gyors, többcsatornás bejelentés működhet, különösen akkor, ha:
pontos IP- és domaininformációk állnak rendelkezésre,
az abuse-contact angol nyelven, strukturált formában történik,
és a tartalom vizuálisan is megragadható (pl. térkép, politikai kontextus).
A második esetnél az észrevétlenül működő domain:
kevésbé vált ki közösségi vagy hatósági figyelmet,
a szolgáltatói rendszer „belesimulás” jellege miatt nehezebb a különválasztás,
a technikailag rejtett megvalósítás ellenére továbbra is súlyosan jogsértő.
A bejelentések tapasztalataiból az rajzolódik ki, hogy a takedown-hatékonyság nem pusztán a tartalom súlyosságán, hanem a technikai megvalósítás és a joghatósági láncolat átláthatóságán múlik. A következő fejezetben azokat a kockázatokat vizsgáljuk meg, amelyek az adatszivárgásban érintett személyek számára e doxxing oldalak kapcsán hosszú távon is fennállnak – a zaklatástól a másodpéldányok újramegjelenéséig.
Az incidensben érintetteknek kitettsége
A tömeges adatlopás és a doxxing célú platformokra való publikálás nemcsak adatvédelmi jogsértést jelent, hanem az érintettek számára súlyos, gyakran hosszú távú következményekkel járó kockázatokat hordoz. A Tisza Világ adatszivárgás nyomán létrejött doxxing oldalak az érintettek személyes adatainak – pl. név, lakcím, e-mail, telefonszám – tömeges és célzott kompromittálását valósították meg. Ebben a fejezetben az érintetteket fenyegető veszélyeket három szinten vizsgáljuk: közvetlen fenyegetettség, másodlagos reprodukció, valamint reputációs és társadalmi következmények.
Közvetlen fenyegetettség: zaklatás, célzott támadás
A térképes vizualizáció (első oldal) és a kereshető személyes adattartalom (második oldal) egyaránt lehetővé tették, hogy bárki konkrét személlyel szemben:
lakcím szerinti fenyegetést tegyen közzé vagy cselekedjen,
közvetlenül kapcsolatba lépjen az érintett telefonszámán vagy e-mailjén keresztül,
online vagy offline zaklatást hajtson végre.
Bár a nyilvános zaklatásról nem jelent meg jogilag igazolt sajtóhír, az ilyen típusú kompromittálás kockázati szintje objektíven magas. Az adatok közvetlenül kapcsolódnak lakóhelyhez és elérhetőségekhez, így a fizikai elérés lehetősége nem csupán elméleti.
Az érintetti visszajelzések szerint már a domain beazonosítása előtti órákban is szűk körben elindult a célzott keresés és fenyegető kommentek megosztása, különösen közösségi médiában.
Másodlagos másolatok és tartós online jelenlét
Míg az első oldal gyors eltávolítása technikailag sikeres volt, a publikusan elérhető JSON-fájl vagy az oldalról készült mentések – archiváló szolgáltatásokkal vagy kézi letöltéssel – másodpéldányokban tovább élhetnek:
zárt fórumokon,
fájlmegosztó oldalakon,
archiválást végző web crawler adatbázisaiban.
Még ha a domain vagy IP blokkolásra is kerül, a másodlagos tartalom tovább publikálható, például:
egy újabb domainen,
Tor-hálózaton keresztül,
vagy akár social media posztként, screenshot formában.
Az első oldal esetében a JSON-fájl nyílt betöltése miatt különösen nagy eséllyel történhetett tömeges mentés. A második oldal keresőalapú struktúrája valamelyest csökkenti ezt a kockázatot, de nem zárja ki.
Reputációs kár, társadalmi következmények
A kompromittált adatbázisban található adatok alapján beazonosítható személyek – mint a Tisza Világ alkalmazás regisztrált felhasználói – politikai kontextusba kerültek a szivárgás nyilvánosságra kerülése után, függetlenül attól, hogy regisztrációjuk valódi motivációja ismert vagy bizonyítható lenne. A társadalmi és médiakörnyezet a kompromittálást nem pusztán adatvédelmi incidensként, hanem politikailag értelmezett aktusként keretezte, amely fokozott reputációs kockázatot és társadalmi stigmatizációt is generálhatott az érintettek számára.
Ez különösen problémás lehet:
munkahelyi szituációkban (pl. ha a munkáltató érzékeny adatkezelésre kötelezett),
iskolai vagy közösségi környezetben (pl. gyermekek szülei azonosíthatók),
vagy ha az érintettek kiskorúak és a regisztráció nem volt tudatos részvétel eredménye.
A reputációs kár nehezen mérhető, de a kompromittált adatbázisba való bekerülés önmagában stigmát hordozhat – különösen, ha a másolatok tartósan elérhetők maradnak.
A doxxing, az adatszivárgás és a jogi felelősségi láncok értelmezése sok esetben bizonytalan határterületeken mozog. A jelen eset is rámutat, hogy a személyes adatok tömeges kompromittálása politikai kontextusban különösen érzékeny következményekkel járhat – jogi, társadalmi és infrastrukturális szinten egyaránt. E kérdéskört külön elemzésben részletesen is körüljártuk:
Védekezési lehetőségek és ajánlások az érintettek számára
A doxxing platformokon való megjelenés az érintettek számára – különösen politikai kontextusban – súlyos és tartós következményekkel járhat. A jogsérelem nem mindig azonnal észlelhető, de a megelőző vagy reaktív lépések megtételével csökkenthetők a károk és fokozható a védelem. Az alábbiakban olyan technikai, jogi és szervezeti eszközöket mutatunk be, amelyek az érintettek rendelkezésére állnak.
Technikai önvédelem és OSINT-lábnyom csökkentése
Névfigyelés: Google Alerts vagy hasonló figyelőrendszer beállítása saját névre, e-mail-címre, telefonszámra.
Keresőmotoros láthatóság minimalizálása: Adateltávolítási kérelmek benyújtása indexáló oldalakhoz (pl. Google, Bing), különösen screenshotot tartalmazó platformoknál.
Közösségi oldalak ellenőrzése: Nyilvános profilok (Facebook, X, Instagram, LinkedIn stb.) beállításainak szigorítása, érzékeny adatok eltávolítása, kapcsolati körök auditálása.
Bizonyítékmentés és archiválás
Képernyőmentések készítése időbélyeggel: URL, dátum, releváns tartalom jól látható módon legyen dokumentálva.
Archiválás: pl. archive.is, Wayback Machine – lehetőség szerint hash-azonosítóval rögzített verzió mentése.
Metaadatok megőrzése: letöltött JSON-fájlok, webforrások és tanúsítványláncok hash-elése, időbélyegzése későbbi bizonyítás céljára.
Hatósági bejelentés és jogi lépések
Adatvédelmi bejelentés (NAIH): ha a személyes adatokat jogalap nélkül kezelik vagy közzéteszik, az érintett vizsgálatot kezdeményezhet a Nemzeti Adatvédelmi és Információszabadság Hatóságnál (https://naih.hu). Ez az út akkor javasolt, ha a közzétett adatok jogszerűségét szeretnénk vizsgáltatni, de nem kapcsolódik közvetlen fenyegetés, zaklatás.
Feljelentés (rendőrség): ha a közzétett adatokkal zaklatás, fenyegetés vagy más bűncselekmény is történik, a rendőrségnél (Btk. 219. § – személyes adattal visszaélés) tehető részletes feljelentés. Ajánlott az alátámasztó bizonyítékokat (screenshot, mentés, levelezés stb.) is csatolni.
Nemzetközi platformbejelentés: ha az adat külföldi szerveren, nemzetközi szolgáltatónál (pl. GoDaddy, Archive.org, social platformok) van, külön panasz is szükséges lehet az adott szolgáltató abuse contact (visszaélés-bejelentési kontakt) pontján keresztül. A domain- és hosting-adatok WHOIS vagy CT-log alapján visszafejthetők.
Civil jogsegély és mintaanyagok
Civil szervezetek támogatása: olyan szervezetek, mint a Magyar Helsinki Bizottság, gyakorlati segítséget nyújtanak bejelentési minták, panaszsablonok és jogi tanácsadás formájában. Például a doxxinggal kapcsolatos adatvisszaélési feljelentéshez, kifejezetten a Tisza Világ adatszivárgással kapcsolatban konkrét sablon is rendelkezésre áll: Adatvisszaélési feljelentésminta – Tisza Világ-ügy (Magyar Helsinki Bizottság)
Nemzetközi szövetségek (pl. EDRi, Access Now): határon átnyúló ügyeknél európai adatvédelmi szervezetekhez is fordulhatunk támogatásért.
CT-log és domain monitoring
CT-log figyelés: új domainaktiválás, tanúsítványbejegyzés detektálása (pl. crt.sh, censys.io).
Domain-figyelő szolgáltatások használata: a kompromittált név vagy márkanevek új domainverzióinak megfigyelésére (pl. tiszav[.]info, tiszadata[.]net stb.).
DNS-figyelés: DNS-monitoring szolgáltatások alkalmazása (pl. DNSDumpster, PassiveTotal), különösen replikáció gyanúja esetén.
Az üzemeltetői profil
A tiszavilag[.]co és a későbbi, jelenleg is elérhető doxxing platform esettörténete világosan megmutatja, hogy miként fonódhat össze egy politikailag érzékeny adatszivárgás technikai kompromittálása és annak tudatosan épített webes hasznosítása. A két oldal közötti különbségek – technikai implementáció, szolgáltatói háttér, reagálási idő – tanulságos mintázatot rajzolnak ki a doxxing típusú infrastruktúrák alkalmazkodásáról.
Az első oldal (tiszavilag[.]co): gyorsan kiugró, gyorsan lebuktatható:
A Leaflet-alapú frontend teljes adattartalmat töltött be kliensoldalon, JSON-struktúrában – ez önmagában súlyos OPSEC-hiba.
A Cloudflare CDN mögé rejtett domain néhány órán belül kiszivárogtatta az origin IP-címet a DNS- és CT-logon keresztül.
Az origin host – a 1337 Services GmbH – múltja alapján kockázatos, de nem „láthatatlan” választásnak bizonyult.
A domainregisztrátor (Spaceship) gyors válaszideje és a többrétegű bejelentés együttesen hatékony takedown-t eredményeztek.
A nyilvános térképes megjelenítés vizuálisan is növelte a hatósági és közösségi érzékenységet.
Következtetés: A technikai hibák és az infrastrukturális láthatóság együttesen gyors beazonosítást és eltávolítást tettek lehetővé.
A második oldal: belesimuló infrastruktúra, nehezebb jogérvényesítés
A domain európai regisztrátornál, jól beágyazott tömegszolgáltatói környezetben került aktiválásra.
Az oldal nem interaktív térképet, hanem szöveges keresőt és táblázatot használ – ezzel kevésbé látványos, de jogilag továbbra is problémás.
A hosting-infrastruktúra nem publikál nyílt origin IP-t, a DNS-konfiguráció „szabályosabb”, kevésbé feltűnő.
A takedown-bejelentések eredményessége lényegesen alacsonyabb; a szolgáltatói válaszreakciók elmaradtak vagy formálisak maradtak.
Következtetés: A technikai elrejtés, a kevésbé feltűnő megjelenítés és a jogi határmezsgyék együttesen jelentősen megnehezítették a beazonosítást és a tartalom eltávolítására irányuló fellépést.
Feltételezett üzemeltetői működés és szándékprofil
Noha az oldal üzemeltetőinek kiléte jelenleg nem ismert, az alábbi mintázatok valószínűsíthetők:
Tudatos adaptáció: az első oldal hibáiból tanulva egy új, robusztusabb infrastruktúra került kialakításra.
Politikai-konteós keretezéshez igazítás: a keresőalapú oldal kevésbé „vállalja fel” a közvetlen doxxing-jelleget, mégis hatékonyan újrahasznosítja a szivárgott adatokat.
Többfázisú üzemeltetés: a domainregisztráció már az első oldal aktiválása előtt megtörtént – utalva előre eltervezett infrastrukturális „backupra”.
Elemzői gondolatok
Elemzésünk egy egyedi, de messze nem elszigetelt eseten keresztül kívánt rávilágítani arra, hogy a személyes adatokkal való visszaélés – különösen politikailag érzékeny környezetben – miként válhat nemcsak adatvédelmi incidenssé, hanem társadalmi, jogi és kiberbiztonsági kihívássá is. A tiszavilag[.]co domain alatt működő első doxxing oldal gyors lebuktatása egyértelműen demonstrálja, hogy technikai és operatív hibák, valamint jól célzott, többcsatornás bejelentések együttesen hatékony takedown-t eredményezhetnek.
Azonban az újabb, jelenleg is aktív oldal példája azt mutatja: a rejtőzködőbb megoldások, az ismert szolgáltatói környezetbe való „beleolvadás” és a joghatósági láncolatok széttöredezettsége megnehezítik a fellépést. Bár az oldal formailag visszafogottabb – keresőfelülettel és táblázatos adattartalommal operál –, funkcióját tekintve továbbra is a doxxing kategóriájába sorolható, és az érintettek számára változatlanul valós, jelen idejű fenyegetést jelent.
A vizsgálat során feltárt technikai struktúra, az OPSEC-hibák láncolata, a regisztráció és hosting mögött álló döntések, valamint a bejelentési tapasztalatok együttesen olyan mintázatot rajzolnak ki, amelyből nemcsak az eset specifikus anatómiája, de egy jövőbeli, rendszerszintű megelőzési stratégia sarokpontjai is kiolvashatók.
Az elemzésben bemutatott tanulságok – legyen szó az infrastrukturális hibák kihasználásáról, a visszaélés-bejelentési csatornák működéséről, vagy az áldozatok lehetőségeiről – nem csupán a Tisza-adatszivárgásra és annak következményeire érvényesek. Az esettanulmány általánosabb érvényű kérdéseket is felvet az adatbiztonság, a platformfelelősség és a célzott nyilvánosság-építés határain túl.
Az érintettek, a vizsgálatban részt vevő szakértők és az olvasók közös érdeke, hogy az ilyen típusú digitális visszaélések ne váljanak normalizált gyakorlatokká. Ez pedig csak akkor lehetséges, ha az incidensek nemcsak felderítésre, de feldolgozásra és rendszerszintű tanulásra is kerülnek. Jelen elemzés ehhez kívánt hozzájárulni.
https://www.facebook.com/andras.racz.526/posts/a-tisza-applik%C3%A1ci%C3%B3-haszn%C3%A1l%C3%B3ir%C3%B3l-k%C3%A9sz%C3%BClt-t%C3%A9rk%C3%A9p-az-ambr%C3%B3zy-%C3%A1ron-nev%C5%B1-propagandist/1505062324105119/
https://www.naih.hu/hirek/786-kozlemeny-a-politikai-partok-adatbazisaibol-nyilvanossagra-keruelo-szemelyes-es-kueloenleges-adatok-mediaszolgaltatok-altali-felhasznalasanak-adatvedelmi-koevetelmenyeirol
https://www.naih.hu/hirek/787-koezlemeny-a-partszimpatizansok-adatainak-terkepen-keresztueli-koezzetetelenek-jogellenessegerol
Federated Data Sharing Adapter: Az FDSA egy bővítmény (plug-in), amit adatforrásokhoz lehet csatlakoztatni.
A célja, hogy az adatközlők (data contributors) egyszerűen meg tudják osztani a saját, távoli adatállományaikat
Wildcard-record: Olyan DNS-bejegyzés, amely „minden” (nem létező) aldomainevet ugyanarra az IP-re vagy szolgáltatásra irányít (például: *.példa.hu → 203.0.113.10). Így a foo.példa.hu, bar.példa.hu stb. mind ugyanoda mutat. Miért fontos? El tudja „nyelni” a véletlen/teszt aldomaineket is, és könnyebb egy CDN mögé terelni az összes forgalmat, elrejtve az eredeti szervert.
CNAME-masking: Egy aldomaint nem közvetlen IP-re, hanem egy másik névre („kanonikus névre”) mutató CNAME rekorddal oldanak fel (pl. www.példa.hu → példa.cdn-szolgáltató.net). A böngésző végül a CDN címét éri el, nem az origin IP-t. Miért fontos? A forgalom a szolgáltató rétegén megy át, ezért az eredeti (origin) infrastruktúra kevésbé látszik kifelé.
Split-horizon technika: Ugyanarra a domainre különböző DNS-válaszok érkeznek attól függően, honnan kérdezik le (belső hálózat vs. internet, vagy földrajzi hely). Például belsőn az origin IP jön vissza, kívül pedig egy CDN/előtétszerver. Miért fontos? A nyilvános nézetben elrejthető az origin, miközben a belső üzemeltetés továbbra is közvetlen elérést használ.
https://krebsonsecurity.com/2025/09/bulletproof-host-stark-industries-evades-eu-sanctions/