منتظر باشید ...

نشت بانک پارسیان: از یک ادعا در دارک وب تا یک گزارش فنی

یکشنبه، 22 شهریور 1405

گاهی مسیر رسیدن یک نشت داده به دست ما، به‌اندازه خود داده‌ها پیچیده است. داستان این گزارش هم از یک ایمیل ناشناس شروع شد.

شنبه، ۲۷ مهر ۱۴۰۴

ایمیلی ناشناس دریافت کردیم که به پستی از یک فروشنده در یکی از انجمن‌های زیرزمینی دارک وب اشاره داشت؛ فروشنده‌ای که مدعی بود داده‌های مشتریان بانک پارسیان را در اختیار دارد. در همان پست انجمن، تنها چند خط داده به‌عنوان نمونه گذاشته شده بود، مقداری بسیار کم و ناکافی برای هر گونه بررسی یا تصمیم‌گیری. همان زمان تلاش کردیم مستقیماً با فروشنده ارتباط بگیریم، اما پیش از دریافت پاسخ، آدرس آن انجمن توسط مراجع قانونی توقیف و از دسترس خارج شد.

یکشنبه، ۷ تیر ۱۴۰۵

ماه‌ها بعد، همان پست فروشنده را دوباره دیدیم؛ این‌بار روی یک آدرس جدید، جایی که انجمن بازگشته بود. این‌بار با فروشنده ارتباط گرفتیم و یک نمونه واقعی و اطلاعات بیشتر برای بررسی دریافت کردیم. آنچه در ادامه می‌آید، تحلیل فنی همان نمونه است: بررسی اصالت داده، دامنه افشا، بازه زمانی استخراج، روش نفوذ ادعایی، و اعتبارسنجی انسانی نمونه‌ای تصادفی از رکوردها با روش OSINT (جمع‌آوری و تطبیق اطلاعات از منابع آزاد و عمومی).

رکوردهای نمونه
48,624
ادعای فروشنده
1,000,000
قالب فایل
JSON
تعداد فیلدهای متمایز
38
جدیدترین تاریخ داده
2024-01-04
تاریخ عرضه برای فروش
2025-06-04
اشخاص حقیقی
47,943
اشخاص حقوقی
525

§۰ خلاصه

این فایل یک پایگاه داده هویتی مشتریان بانک (CIF) است. داده‌ها با اطمینان بسیار بالا اصیل هستند. ساختار داده نشان می‌دهد که استخراج از طریق یک واسط برنامه‌نویسی (API) انجام شده است، نه از طریق تخلیه مستقیم جدول پایگاه داده، که با ادعای فروشنده درباره سامانه «پارسینس» سازگار است.

علاوه بر آزمون‌های آماری، صحت داده به‌صورت میدانی و با روش OSINT نیز روی نمونه‌ای تصادفی از رکوردها بررسی شد، به §۳ مراجعه کنید.

هیچ داده مالی، شماره حساب، موجودی، شماره کارت، یا تراکنش، در این نمونه وجود ندارد. آنچه افشا شده، هویت کامل مشتریان است.

§۱ آنچه بررسی شد

فایل با پسوند .txt در واقع مجموعه‌ای از اشیاء JSON است؛ هر رکورد در یک خط، و میان هر دو رکورد یک خط خالی. از مجموع ۹۷٬۵۵۱ خط، ۴۸٬۹۲۷ خط خالی بود و ۴۸٬۶۲۴ رکورد بدون هیچ خطای تجزیه استخراج شد.

در کل مجموعه ۳۸ فیلد متمایز دیده می‌شود، اما تنها ۵ فیلد در تمام رکوردها مشترک و حاضرند؛ همین نکته کلیدی است. تعداد فیلدهای هر رکورد بین ۵ تا ۲۸ متغیر است، و همین ناهم‌سانی در تحلیل روش استخراج داده (§۶) نقش تعیین‌کننده‌ای دارد.

این فایل، نمونه‌ای است که از فروشنده دریافت شد، نه مجموعه کامل؛ تمام آمار این گزارش تنها بر پایه همین نمونه محاسبه شده است.

§۲ اصالت داده: آیا واقعی است؟

اعتبارسنجی کد ملی: ۱۰۰٪ کدهای خوش‌ساخت معتبرند قطعی

کد ملی ایرانی دارای رقم کنترلی بر پایه باقی‌مانده بر ۱۱ است. از ۴۸٬۶۲۴ رکورد: ۴۷٬۹۱۷ کد معتبر (۹۸٫۵۵٪)، ۷۰۷ کد بدساخت، و صفر کد مردود.

یعنی هیچ کد ده‌رقمی‌ای در این مجموعه وجود ندارد که رقم کنترلی آن غلط باشد. اگر داده ساختگی بود، نرخ قبولی حدود ۹٪ (یک از یازده) می‌شد.

کد شهاب، کد ملی را در خود جای داده است تأیید متقاطع

۴۶٬۴۵۰ رکورد دارای shahabCode شانزده‌رقمی هستند. در ۹۹٫۹۷٪ موارد، ارقام هفتم تا پانزدهم کد شهاب دقیقاً برابر با نُه رقم اول کد ملی همان شخص است (پیشوند غالب 100000).

این یک آزمون سازگاری متقاطع میان دو شناسه مستقل است. جعل هم‌زمان هر دو شناسه به‌گونه‌ای که این رابطه در ۴۶ هزار رکورد برقرار بماند، عملاً ناممکن است.

کد شهاب‌ها با یک سامانه آنلاین استعلام و با کد ملی مطابقت داده شدند تأیید مستقل

علاوه بر آزمون ساختاری بالا، روی نمونه‌ای تصادفی از رکوردها، کد شهاب از طریق یک سامانه استعلام آنلاین بررسی شد. در تمام مواردی که استعلام گرفته شد، اطلاعات بازگشتی، از جمله کد ملی، دقیقاً با مقادیر موجود در همان رکورد از فایل نشت‌شده مطابقت داشت.

برخلاف آزمون تطبیق ساختاری (که فقط الگوی درونی خود داده را بررسی می‌کند)، این یک منبع تأیید کاملاً مستقل و بیرونی است؛ صحت داده تنها با آزمون‌های داخلی فایل ارزیابی نشده، بلکه با یک سامانه خارج از آن هم راستی‌آزمایی شده است.

هیچ رکورد تکراری وجود ندارد قوی

۴۸٬۶۲۴ کد ملی متمایز، ۴۸٬۶۲۴ شماره مشتری متمایز، ۴۶٬۴۵۰ کد شهاب متمایز، بدون هیچ برخوردی. این نشانه یک جدول زنده تحت قید یکتایی است.

توزیع‌های جمعیتی و مخابراتی واقع‌گرایانه‌اند پشتیبان

سهم اپراتورها (همراه اول ۷۵٫۸٪، ایرانسل ۲۲٫۹٪، رایتل ۱٫۳٪) با سهم بازار واقعی هم‌خوان است. پیش‌شماره تلفن ثابت و محل تولد هر دو تهران را در صدر نشان می‌دهند (۱۷٬۱۷۰ و ۱۴٬۴۶۳). نام پدر تنها ۴٬۰۱۹ مقدار متمایز دارد، که برای نام‌های رایج ایرانی کاملاً طبیعی است.

ارزیابی: داده اصیل است و به اشخاص واقعی و قابل شناسایی تعلق دارد. این نتیجه با اعتبارسنجی انسانی بخش §۳ نیز تأیید می‌شود.

§۳ اعتبارسنجی انسانی: تطبیق با روش OSINT

آزمون‌های آماری بخش §۲ فقط می‌توانند بگویند «این کدها ساختاری معتبر و متعلق به یک سامانه واقعی دارند». برای پاسخ به پرسش مهم‌تر، «آیا پشت این رکوردها واقعاً آدم زنده هست؟»، یک دور اعتبارسنجی انسانی هم روی نمونه‌ای تصادفی از داده انجام دادیم.

تطبیق دستی با شبکه‌های اجتماعی رایج تأیید میدانی

حدود ۱۰ تا ۲۰ رکورد کاملاً تصادفی از دل نمونه انتخاب شد، بدون ترجیح به رکوردهای «تمیزتر» یا کامل‌تر. برای هر رکورد، ترکیبی از نام و نام خانوادگی، سال تولد و بخشی از شماره همراه در شبکه‌های اجتماعی رایج جست‌وجو شد تا مشخص شود آیا فردی با همین مشخصات و نمایه منطبق پیدا می‌شود یا نه.

در تمام موارد بررسی‌شده، مشخصات هویتی رکورد، نام، سن تقریبی، و در چند مورد شهر یا حرفه، با نمایه‌های عمومی پیداشده هم‌خوانی داشت. هیچ موردی با ناهم‌خوانی آشکار یا نشانه‌ای از داده جعلی/تصادفی مشاهده نشد.

محدودیت‌های این آزمون

این روش، مکمل آزمون‌های آماری بخش §۲ است، نه جایگزین آن. یک نمونه ۱۰ تا ۲۰ رکوردی در برابر ۴۸٬۶۲۴ رکورد کل مجموعه، از نظر آماری برای برآورد دقیق نرخ خطا کافی نیست؛ ارزش آن کیفی است نه کمّی: نشان می‌دهد پشت کدهای ملی معتبر، انسان‌های واقعی و قابل‌شناسایی‌اند، نه ارقام تصادفی‌ای که فقط رقم کنترلی را پاس می‌کنند.

در جریان این بررسی، هیچ داده‌ای از نمونه منتشر یا با شخص ثالث به اشتراک گذاشته نشد و با هیچ‌یک از افراد شناسایی‌شده تماسی گرفته نشد؛ این کار صرفاً برای اعتبارسنجی داخلی اصالت داده و به‌صورت موقت انجام شد و یادداشت‌های آن پس از تکمیل تحلیل حذف شدند.

نتیجه این آزمون انسانی، یافته بخش §۲ را تقویت می‌کند: این یک مجموعه جعلی یا تولیدشده با الگوریتم نیست، رکوردهای آن به افراد واقعی، قابل‌جست‌وجو و قابل‌شناسایی در فضای عمومی اینترنت تعلق دارد.

§۴ چه چیزی افشا شده است

این یک جدول هویت مشتری (CIF) است. نکته مهم: هیچ داده مالی در آن نیست، نه شماره حساب، نه موجودی، نه شماره کارت، نه تراکنش. اما آنچه هست، از جهاتی خطرناک‌تر است، زیرا قابل تغییر نیست.

پوشش فیلدها در ۴۸٬۶۲۴ رکورد
دسته دادهتعدادپوششتوضیح
نام و نام خانوادگی48,46899.7%فارسی و معادل انگلیسی
کد ملی48,624100.0%شناسه اصلی هویت در ایران
نام پدر47,94398.6%عامل احراز هویت در بانکداری ایران
شماره شناسنامه37,23776.6%شناسه هویتی مکمل
تاریخ تولد47,94398.6%مبنای محاسبه سن و شناسایی افراد زیر سن قانونی
محل تولد و محل صدور47,94398.6%۵۸۹ و ۶۱۴ مقدار متمایز
نشانی کامل48,40699.6%۴۸٬۰۱۶ نشانی متمایز
کد پستی31,99665.8%۳۱٬۳۴۲ مورد ده‌رقمی معتبر
تلفن همراه40,88984.1%۴۰٬۶۴۳ شماره متمایز
تلفن ثابت44,20790.9%۳٬۴۳۰ مورد مقدار جانشین «۰»
کد شهاب46,45095.5%شناسه یکتای بانکی شخص
شماره مشتری (CIF)48,624100.0%شناسه داخلی بانک

۹۸٫۵٪ رکوردها مجموعه کامل احراز هویت بانکی را دارند بحرانی

۴۷٬۸۸۱ رکورد هم‌زمان شامل نام، کد ملی، تاریخ تولد، نام پدر، شماره شناسنامه و نشانی هستند. در ۸۴٪ موارد شماره همراه نیز موجود است.

در نظام بانکی ایران، ترکیب «کد ملی + تاریخ تولد + نام پدر + شماره همراه» دقیقاً همان چیزی است که برای بازیابی رمز، احراز هویت تلفنی و افتتاح حساب غیرحضوری استفاده می‌شود. این نمونه عملاً پاسخ سؤالات امنیتی ده‌ها هزار مشتری را در اختیار می‌گذارد.

هیچ‌یک از این اقلام قابل تعویض نیست. رمز عبور را می‌توان در یک دقیقه عوض کرد؛ نام پدر و کد ملی را نه.

کد پستی و نشانی، خطر فیزیکی ایجاد می‌کند مهم

۳۱٬۳۴۲ کد پستی ده‌رقمی معتبر به‌همراه نشانی کامل متنی موجود است. کد پستی ایرانی تا سطح پلاک دقیق است. ترکیب آن با نام، تلفن همراه و رده سنی، امکان هدف‌گیری فیزیکی و کلاهبرداری حضوری را فراهم می‌کند، به‌ویژه برای ۱۱٬۰۳۸ مشتری بالای ۶۰ سال.

اشخاص حقوقی

۵۲۵ رکورد متعلق به شرکت‌هاست و فیلدهای متفاوتی دارد: registrationCode (شماره ثبت)، economicCode (کد اقتصادی)، employeeCount، foundationDate و occupation. ۱۵۶ رکورد نیز از نوع N با تنها ۵ فیلد است، احتمالاً رکوردهای ناقص یا مسدودشده.

§۵ زمان‌بندی: آیا داده متعلق به ۲۰۲۵ است؟

ادعای فروشنده این بود که داده‌ها متعلق به سال ۲۰۲۵ هستند؛ ماه یا روز مشخصی ذکر نشده بود، و این مجموعه اولین بار در تاریخ 2025-06-04 برای فروش عرضه شد.

هیچ مُهر زمانی در داده وجود ندارد محدودیت

این مجموعه هیچ فیلد created_at یا updated_at ندارد. تنها فیلدهای تاریخ‌دار، تاریخ تولد اشخاص و تاریخ تأسیس شرکت‌هاست. بنابراین ادعای «۲۰۲۵» را نمی‌توان از خود داده تأیید کرد، این خود نشانه‌ای است که داده از یک API آمده، نه از جدول خام.

اما یک حد پایین قابل استخراج است استنتاج

جدیدترین رکوردها: تاریخ تولد 2023-11-11 و تاریخ تأسیس شرکت 2024-01-04. هیچ مجموعه داده‌ای نمی‌تواند قدیمی‌تر از جدیدترین رکورد خود باشد.

پس استخراج قطعاً در یا پس از ژانویه ۲۰۲۴ رخ داده است. این با ادعای «۲۰۲۵» ناسازگار نیست، ولی آن را اثبات هم نمی‌کند. نبود رکوردی از سال ۲۰۲۴ به بعد در بخش اشخاص حقیقی، احتمال می‌دهد که داده به اوایل ۲۰۲۴ نزدیک‌تر باشد تا اواخر ۲۰۲۵، اما چون این فقط یک نمونه است، نمی‌توان قاطع بود.

یک حد بالا هم مشخص است استنتاج

این مجموعه در تاریخ 2025-06-04 برای فروش در یکی از بازارهای داده‌های غیرمجاز عرضه شده است. داده‌ای که برای فروش عرضه می‌شود، باید پیش از آن تاریخ استخراج شده باشد؛ پس این تاریخ یک حد بالا برای زمان وقوع نشت به‌دست می‌دهد.

با کنار هم گذاشتن این دو حد، استخراج در بازه‌ای بین ژانویه ۲۰۲۴ و ژوئن ۲۰۲۵ رخ داده است. این بازه با ادعای «۲۰۲۵» کاملاً سازگار است.

§۶ روش استخراج: آیا ادعای فروشنده درست است؟

ادعای فروشنده: «تزریق SQL در وب‌سایت‌های واسط متصل به APIهای داخلی بانک (سامانه پارسینس)». ساختار داده این ادعا را تا حد زیادی تأیید می‌کند، اما با یک اصلاح مهم.

داده از یک API آمده، نه از تخلیه مستقیم جدول تعیین‌کننده

چهار شاهد مستقل:

  • صفر مقدار null صریح. فیلدهای خالی به‌کلی حذف شده‌اند، نه اینکه با null پر شوند. تعداد کلیدهای هر رکورد بین ۵ تا ۲۸ متغیر است. یک نتیجه SQL همیشه ستون‌های ثابت با مقدار NULL برمی‌گرداند؛ حذف فیلد، رفتار سریال‌ساز JSON است.
  • نام فیلدها به سبک camelCase است، clientType، englishFirstName، defaultMobile. ستون‌های پایگاه داده بانکی (اوراکل) معمولاً UPPER_SNAKE_CASE هستند. این نام‌ها متعلق به لایه برنامه است.
  • فیلدهای «کد» و «عنوان» جفت شده‌اند، gender/genderTitle، birthPlace/birthPlaceTitle، nationality/nationalityTitle. تزریق SQL روی یک جدول، فقط کد را برمی‌گرداند؛ عنوان خوانا حاصل پیوند با جدول مرجع یا غنی‌سازی در لایه برنامه است.
  • ساختار رکورد چندریختی است، اشخاص حقیقی فیلد نام پدر و شماره شناسنامه دارند، اشخاص حقوقی فیلد کد اقتصادی و تعداد کارکنان. این الگوی یک DTO با زیرگونه است، نه یک جدول واحد.

شماره مشتری نشان می‌دهد استخراج رکورد‌به‌رکورد و منظم بوده است قوی

تمام شماره‌های مشتری (به‌جز یک مورد) مضرب ۱۰۰ هستند. با تقسیم بر ۱۰۰، فاصله میان رکوردهای متوالی بررسی شد: ۷۲٫۴٪ فاصله‌ها باقی‌مانده ۸ بر ۱۳ دارند، و سه فاصله پرتکرار ۸ و ۲۱ و ۳۴ هستند، یک تصاعد حسابی با گام ۱۳.

این الگو تصادفی نیست. نشان می‌دهد نمونه به‌صورت سیستماتیک (هر nاُمین رکورد) از یک مجموعه مرتب برداشته شده، که با پیمایش منظم شناسه مشتری روی یک نقطه پایانی API کاملاً سازگار است.

جمع‌بندی روش نفوذ

سناریوی سازگار با شواهد: تزریق SQL روی سایت واسط، نقطه ورود بوده است (برای به‌دست‌آوردن اعتبارنامه، توکن یا دسترسی به سرور)، اما خود رکوردها از طریق فراخوانی API داخلی و پیمایش شناسه مشتری جمع‌آوری شده‌اند. این دقیقاً همان چیزی است که فروشنده توصیف کرده، و داده آن را تأیید می‌کند؛ یعنی آنچه رخ داده، حاصل یک نفوذ عمدی است، نه یک اشتباه پیکربندی ساده.

نکته دفاعی مهم: نبود داده مالی نشان می‌دهد نقطه پایانی مورد سوءاستفاده، سرویس هویت مشتری بوده است، نه سامانه اصلی بانکداری. این دامنه را محدود می‌کند، ولی از شدت افشای هویتی نمی‌کاهد.

§۷ چه کسانی متأثر شده‌اند

میانه سنی ۴۵ سال و میانگین ۴۸٫۱ سال. نسبت جنسیتی ۳۰٬۱۸۴ مرد به ۱۷٬۷۵۹ زن (۶۳٪ به ۳۷٪).

۹۵۶ رکورد متعلق به افراد زیر ۱۸ سال است دسته ویژه

تاریخ‌های تولد در این مجموعه معتبرند: تنها یک مقدار غیرممکن در کل مجموعه دیده شد، و تولدهای اخیر روندی طبیعی و نزولی دارند (۷۱ مورد در ۲۰۱۵ تا ۸ مورد در ۲۰۲۳). این‌ها حساب‌های واقعی کودکان‌اند، که در بانکداری ایران رایج است.

داده کودکان در همه نظام‌های حفاظت داده بالاترین سطح حساسیت را دارد. اگر نسبت ۲٪ در کل مجموعه ادعاشده ۱٬۰۰۰٬۰۰۰ رکوردی پابرجا باشد، حدود ۱۹٬۷۰۰ کودک برآورد می‌شود.

تمرکز جغرافیایی: تهران با ۱۴٬۴۶۳ محل تولد و ۱۷٬۱۷۰ پیش‌شماره تلفن، به‌روشنی غالب است؛ سپس اصفهان، مشهد، شیراز، تبریز و کرج.

§۸ توصیه‌ها

تلاش برای اطلاع‌رسانی به بانک

پیش از انتشار این گزارش، تلاش کردیم بانک پارسیان را از طریق ایمیل عمومی و دیگر راه‌های ارتباطی بانک مطلع کنیم؛ این کانال‌ها یا در دسترس نبودند یا پاسخی دریافت نشد. با وجود اینکه خبر این نشت در رسانه‌ها و پایگاه‌های خبری مختلف نیز بازتاب یافت، تا لحظه انتشار این گزارش، بانک پارسیان هیچ اطلاعیه یا واکنشی نشان نداده و مسئولیتی نپذیرفته است.

برای بانک

  • سایت‌های واسط متصل به پارسینس را فهرست و ممیزی کنید. نقطه ورود ادعایی همین‌جاست؛ هر واسطی که به API داخلی وصل است باید بازبینی شود.
  • روی نقاط پایانی هویت، محدودیت نرخ و سقف حجم بگذارید. پیمایش سیستماتیک ده‌ها هزار شماره مشتری باید هشدار تولید کند؛ اینکه نکرده، خلأ اصلی پایش است.
  • لاگ فراخوانی API را برای الگوی پیمایش متوالی CIF بررسی کنید، به‌ویژه از ژانویه ۲۰۲۴ به بعد (حد پایین §۵).
  • احراز هویت مبتنی بر «نام پدر و کد ملی» را کنار بگذارید. این عوامل دیگر محرمانه نیستند و نباید مبنای بازیابی رمز یا تأیید تلفنی باشند. این فوری‌ترین اقدام دفاعی است.
  • دسترسی واسط‌ها را به حداقل میدان لازم محدود کنید، یک سایت واسط نیازی به نام پدر و شماره شناسنامه ندارد.
  • به مشتریان و مرجع نظارتی اطلاع دهید.

برای مشتریان

  • هر تماسی که با ذکر نام، کد ملی یا نام پدر شما را «تأیید هویت» می‌کند، مشکوک بدانید؛ این داده‌ها دیگر محرمانه نیستند.
  • احراز هویت دومرحله‌ای مبتنی بر اپلیکیشن را فعال کنید؛ شماره‌های همراه موجود در این نشت، خطر جابه‌جایی سیم‌کارت را واقعی می‌کند.
  • مشتریان سالمند در معرض بیشترین خطر کلاهبرداری تلفنی‌اند، ۱۱٬۰۳۸ نفر از این نمونه بالای ۶۰ سال دارند.

تحلیل روی هر ۴۸٬۶۲۴ رکورد نمونه انجام شد. هیچ زیرساخت زنده‌ای فراخوانی نشد و هیچ آزمون نفوذی صورت نگرفت. علاوه بر آزمون‌های آماری، بخش کوچکی از رکوردها به‌صورت میدانی و با روش OSINT نیز اعتبارسنجی شد (§۳). یافته‌ها توصیف‌کننده نمونه‌اند؛ تعمیم‌ها به‌صراحت برچسب خورده‌اند.