هکرهای ATM: قسمت اول — مرور و تحلیل حملات

زمان مطالعه: 21 دقیقه

محققای Group-IB، از سال ۲۰۲۲، حملات مرتبط با گروه UNC2891، علیه خودپردازهای (ATM) چندین مؤسسه مالی در اندونزی رو مورد بررسی قرار دادن و اخیرا مهم ترین یافته‌ها و مشاهدات حاصل از این تحقیقات رو منتشر کردن. این گزارش رو که در 71 صفحه ارائه شده، در قالب 3 پست ارائه کردیم.

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

یافته های کلیدی:

در گذشته، گروههایی مانند Cobalt، MoneyTaker و Silence با حملات جسورانه و پیچیده، بخش مالی رو به لرزه در می آوردن. هرچند این گروهها امروزه کمتر در مرکز توجه قرار دارن، اما تهدید از بین نرفته، بلکه تغییر شکل داده. حالا بازیگرانی مانند UNC2891 موج جدیدی از مهاجمان رو تشکیل میدن: آماده‌تر، فنی‌تر و منظم‌تر. این گروه تلاش میکنه جلب توجه نکنه، اما در سکوت به نتایج قابل توجهی دست پیدا کرده و با تاکتیکهای پیشرفته و کمپینهای هدفمند، مؤسسات مالی رو هدف قرار داده.
UNC2891 طیف گسترده‌ای از بدافزارهای سفارشی رو استفاده کرده، از جمله: روت‌کیت CAKETAP، بکدور SLAPSTICK، بکدور TINYSHELL، کیلاگر WINGHOOK، پاک کننده لاگ LOGBLEACH / MIGLOGCLEANER. این ابزارها با استفاده از جعل فایلهای معتبر، لاگهای رمزگذاری‌ شده، جعل مهرزمانی و تکنیکهای مبهم سازی، برای سالها از دید سیستمهای امنیتی مخفی موندن.
در چندین مورد، مهاجمان تونستن دسترسی مخفیانه خودشون رو برای سالها حفظ کنن (اولین نشانه نفوذ به سال ۲۰۱۷ برمیگرده) و به ده‌ها سیستم دسترسی داشتن. هکرها به سرورهای سوئیچینگ ATM، سرورهای تولید، و jump hostها نفوذ کرده و با زنجیر کردن بکدورها و دستکاری باینریها، پایداری بلند مدتی ایجاد کردن.
UNC2891 خلاقیت قابل توجهی در نفوذ و حرکت جانبی از خود نشان داده، از جمله: اتصال فیزیکی یک Raspberry Pi به سوییچهای شبکه ATM، سوءاستفاده از SSH با استفاده از SLAPSTICK، استفاده از اطلاعات سرقت‌ شده از طریق WINGHOOK و برای C2، این گروه از ابزارهایی مانند iodine و OpenVPN استفاده کرده و بکدورها رو روی چندین میزبان زنجیره‌ کرده‌ تا دسترسی پایدار ایجاد کنن.
این گروه معمولا از طریق تبلیغات گوگل یا کانالهای تلگرام، عملیات پیشرفته جذب Money Mule، انجام میداد. Money Muleها تجهیزات و دستورالعملهای کارتهای کلون شده رو از طریق TeamViewer دریافت میکردن. مهاجمان قدم‌ به‌ قدم اونارو راهنمایی میکردن تا کارتهای کلون‌ شده رو داخل ATM قرار بدن و عملیات برداشت نقدی رو اجرا کنن، بدون اینکه خودشان در معرض ریسک مستقیم قرار بگیرن.

پیچیدگی انتساب حملات سایبری:

انتساب حملات سایبری همچنان یک چالش پیچیده و گاه حدسی محسوب میشه، مخصوصا زمانیکه با بازیگر تهدید پیشرفته‌ای روبرو هستیم که از OPSEC قوی، اشتراک زیرساخت و استفاده مجدد از کد استفاده میکنه. UNC2891 نمونه‌ی واضحی از همین پیچیدگی است.

UNC2891 از نظر تاکتیکها، روشها و ابزارها همپوشانی قابل توجهی با UNC1945 داره، گروهی که به اجرای کمپینهای جاسوسی بلند مدت علیه زیرساختهای مخابراتی، مخصوصا سیستمهای Oracle Solaris، معروفه. هر دو گروه در محیطهای مشابه عمل کردن، از خانواده‌های بدافزاری یکسان مانند SLAPSTICK و TinyShell استفاده کردن و تسلط بسیار بالایی بر ساختار داخلی Solaris دارن، مهارتی نادر، حتی در میان APTها.

با این حال، اختلافات کلیدی در انگیزه، نوع اهداف و ابزارهای خاص، بویژه روت‌کیت سفارشی CAKETAP، نشان میده که UNC2891 یک موجودیت کاملا مجزاست که احتمالا انگیزه‌ های مالی یا مجرمانه داره. برخلاف UNC1945 که بر جمع‌آوری اطلاعات راهبردی تمرکز داره، UNC2891 بر اهداف سودآور، همچون دسترسی به مؤسسات مالی و شبکه‌های ATM تمرکز میکنه.

نکته مهمتر این که حتی در مواردی که CAKETAP بازیابی نشده، استفاده مداوم از کلیدهای رمزنگار ی‌شده در STEELCORGI، یک بکدور ماژولار که در چندین نفوذ UNC2891 شناسایی شده، به وضوح نشان‌ دهنده یک الگوی رفتاری ثابت است. این شباهتهای کلیدی که در حوادث غیرمرتبط و طی سالهای مختلف دیده شدن، خوشه رفتاری قابل اعتمادی ایجاد میکنن که ارزیابی محققا درباره انتساب این گروه رو تقویت میکنن.

با توجه به تکرار شدن حضور شواهد کلیدی STEELCORGI در رخدادهایی که الگوی اونا با عملیات شناخته‌ شده UNC2891 سازگاره و همچنین نبود شاخصهای منحصر به‌ فرد UNC1945 مانند تونل زنی GPRS یا شناسایی اختصاصی زیرساختهای مخابراتی، محققا با اطمینان بالا ارزیابی میکنن که موارد شرح‌ داده‌ شده در این گزارش به UNC2891 نسبت داده میشه، زیرا تمامی فعالیتهای مشاهده‌ شده در سازمانهای مالی شناسایی شدن.

مرور و تحلیل حملات:

فوریه ۲۰۲۲: بانک A

در فوریه 2022، محققای Group-IB برای انجام آنالیزهای فارنزیکی روی سرورهای ATM مشکوک به هک در بانک A در اندونزی، مامور میشن. بررسی اولیه نشان دهنده دستکاری داده های ارسال شده از سرور ATM بوده. بر همین اساس محققا آنالیز عمیق تری انجام دادن تا علت این دستکاری رو متوجه بشن. نتایجی که از این بررسی ها بدست اومده:

تسلط مهاجم بر محیط لینوکس: مهاجم سطح بسیار بالایی از تخصص در سیستم‌ عامل لینوکس داشته و برای مدت طولانی بدون شناسایی‌ شدن در محیط باقی مونده.
تاکتیکهای مخفی‌کاری: مهاجم رفتار بسیار مخفی کارانه‌ای داشته و از تکنیکهایی مانند پاکسازی لاگها، مبهم‌ سازی فایلها و ادغام کردن فعالیت خودش با محیط سیستم، شناسایی رو سخت‌تر کرده. چندین خانواده بدافزاری مختلف در شبکه مشاهده شده که هرکدام نقش متفاوتی داشتن.
قدیمی‌ ترین نشانه نفوذ: قدیمی ترین شواهد نفوذ، بر اساس لاگهای احراز هویت یکی از بدافزارهای مورد استفاده، به نوامبر ۲۰۱۷ برمیگرده.
نامشخص بودن مسیر اولیه نفوذ: مسیر اولیه ورود مهاجم مشخص نشده، چون نخستین نشانه‌های نفوذ به 5 سال پیش برمیگرده و امکان بازسازی کامل خط زمانی حمله وجود نداشته.
سرقت اطلاعات و حرکت جانبی: شواهد نشان میده مهاجم با استفاده از ابزارهای سرقت اعتبارنامه و یک کیلاگر، از اکانهای کاربری معتبر برای حرکت جانبی بین سرورها استفاده کرده.
C2 از طریق زنجیره‌ کردن دسترسیها: مهاجم اتصال C2 به سرور ATM رو از طریق زنجیره‌ کردن چندین بکدور روی میزبانهای مختلف برقرار کرده.
پایداری از طریق تغییر در باینریها: مهاجم باینریهای نرم‌افزاری رو تغییر داده تا پایداری بلند مدت، روی میزبانهای آلوده داشته باشه.
کشف روت‌کیت CAKETAP: پس از کشف دستکاری داده‌های ATM، آنالیز حافظه سرورهای ATM انجام و وجود یک روت‌کیت سطح کرنل بنام CAKETAP مشخص شد. این روت‌کیت با نام ماژول ipstat نصب شده و داده‌های ارسال‌ شده از سرور ATM رو رهگیری و با مجموعه‌ای از شرایط مقایسه میکرد. در صورت تطابق، داده قبل از خروج از سرور تغییر داده میشد.
دامنه نفوذ: در مجموع بیش از ۳۰ سیستم داخلی آلوده شده بودن، از جمله: سرورهای تولید (Production Servers)، Jump Hosts، سرورهای سوئیچینگ ATM

تحلیل فوریه 2022: بانک A در اندونزی

در این مورد، مهاجم برای پایداری روی میزبانهای آلوده، اقدام به تغییر باینریهای نرم‌افزاری کرده. برای مثال، فایل usr/bin/ssh طوری دستکاری شده بود که علاوه بر عملکرد عادی خودش، کتابخانه اشتراکی usr/lib/x86_64-linux-gnu/selinux.so.1 رو هم لوود میکرد. کتابخانه‌ای که در واقع بعنوان کیلاگر WINGHOOK عمل میکنه. در نتیجه، WINGHOOK برای تمامی نشست های ورودی SSH روی میزبان اجرا میشد.

هکرها همچنین باینری سرویس atd رو که بعنوان daemon در لینوکس برای پردازش وظایف زمان‌ بندی‌ شده بکار میره (معمولا وظایفی که یکبار اجرا میشن و با دستورات at یا batch ثبت میشن)، تغییر داده بودن تا در پس‌ زمینه اجرا بشه و به این ترتیب، پایداری دسترسی بکدور TINYSHELL رو تضمین کنه.

علاوه بر تغییر باینریها، ماژول PAM (Pluggable Authentication Module) مورد استفاده در شرکت قربانی هم دستکاری شده بود. در این حادثه، ماژول PAM با یک کتابخانه اشتراکی مخرب با عنوان SLAPSTICK جایگزین شده بود.

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

مهاجم برای حذف ردپا از دو ابزار پیشرفته استفاده کرده بود: LOGBLEACH و MIGLOGCLEANER. این ابزارها امکان پاک کردن تمام لاگها یا تنها بخشهای انتخابی رو بر اساس پارامترهای خاص داشتن. نمونه‌های LOGBLEACH در مسیرهای زیر پیدا شدن:

/dev/shm/b
/lib64/liblbch-2.4.so.2.5.6
/usr/lib/libmig.so.1
/usr/lib64/liblbch-2.4.so.2.5.6
/usr/share/i18n/pulse-shm-1489710120

/dev/shm/b

/lib64/liblbch-2.4.so.2.5.6

/usr/lib/libmig.so.1

/usr/lib64/liblbch-2.4.so.2.5.6

/usr/share/i18n/pulse-shm-1489710120

dev/shm یک فایل‌ سیستم موقتی داخل RAM هستش. وقتی فایلی از اون حذف بشه، بطور کامل غیر قابل بازیابی میشه.

در زیر شواهد اجرای LOGBLEACH در تاریخچه Bash یکی از سرورها قابل مشاهده است:

/lib64/liblbch-2.4.so.2.5.6 -a -C -y
/lib64/liblbch-2.4.so.2.5.6 -i %IP% -z 999 -C -y

1 2	/lib64/liblbch-2.4.so.2.5.6 -a -C -y /lib64/liblbch-2.4.so.2.5.6 -i %IP% -z 999 -C -y

شرح پارامترها:

-a : autopilot mode
-C : perform cleaning
-y : always say “yes” when prompted
-i : filter by IP
-z : time range of 999 seconds

-a : autopilot mode

-C : perform cleaning

-y : always say “yes” when prompted

-i : filter by IP

-z : time range of 999 seconds

مهاجم برای نام بدافزارها، از نامهایی شبیه به کتابخانه‌ ها یا فایلهای قانونی سیستم استفاده کرده تا شناسایی نشن. در شکل زیر نمونه ای از این موارد رو مشاهده میکنید.

مهاجم برای سخت تر کردن فرایند شناسایی و آنالیز، از روشهای پیشرفته ای استفاده کرده از جمله:

رمزگذاری پبلودها و رشته‌ها
تکنکهای ضد دیباگ و ضد آنالیز
رمزگذاری وابسته به محیط
رمزگذاری لاگهای SLAPSTICK و WINGHOOK

اگرچه امکان نسبت دادن قطعی تکنیک Timestomping به تمامی بدافزارهای شناسایی‌ شده وجود نداشته، اما در مورد فایل pam_unix.so آلوده‌ شده (بدافزار SLAPSTICK) روی یکی از سرورهای آلوده، این موضوع تأیید شده. Timestomping یک تکنیک مخرب در امنیت سایبری است که مهاجم با استفاده از اون زمانهای اصلی یک فایل (Create / Modify / Access time) رو دستکاری میکنه. تحلیل لاگ SLAPSTICK روی اون سرور نشان داد که اولین ورودی لاگ، مربوط به فعالیتهای اخیر بوده، در حالیکه متادیتای فایل دستکاری‌ شده تاریخ ۱۵ اکتبر ۲۰۱۲ رو نشان میداد. این عدم تطابق، نشانه ی واضحی از تغییر عمدی مهر زمانی (Timestamp) فایل هستش.

SLAPSTICK دارای یک پسورد هاردکد شده (پسورد جادویی) بود که به مهاجم اجازه میداد بدون داشتن حساب کاربری معتبر، به میزبان دسترسی پیدا کنه. هنگام احراز هویت، اگه پسورد وارد شده با این رشته شروع میشد، SLAPSTICK کاربر رو با موفقیت احراز هویت میکرد و یکی از سه فرمان از پیش تعریف‌ شده رو اجرا میکرد.

Command #rm will removes specified file
Command #sh will execute remote commands using the existing command line interpreter
Command #tcp will initiate a TCP connection with the provided server and forwards received data to STDIN (acting as a TCPProxy).

Command #rm will removes specified file

Command #sh will execute remote commands using the existing command line interpreter

Command #tcp will initiate a TCP connection with the provided server and forwards received data to STDIN (acting as a TCPProxy).

مهاجمان باینریهاش رو که بصورت ASCII با uuencode انکد شده بودن، از طریق کنسول SSH به میزبانهای آلوده منتقل کردن. uuencode یک فرمت و ابزار قدیمی برای تبدیل فایلهای باینری به متن ASCII است تا بشه اونارو در کانالهایی ارسال کرد که فقط متن ساده رو پشتیبانی میکنن، مثل ایمیلهای قدیمی، گروههای خبری Usenet و ترمینالهای قدیمی. تحلیل لاگهای دیکد شده نشان داد که اونا ماژول اکسپلویت Dirty COW (با شناسه CVE-2016-5195) رو به یکی از سرورها منتقل کردن. این فایل در مسیر dev/shm/gconf-root قرار داده شده و با یک اسکریپت ساده Perl دیکد میشد. فایل Dirty COW انکد شده با نام milk.ue و اسکریپت دیکد کننده با نام ude منتقل شده بودن. پس از دیکد milk.ue، فایل به صورت m.gz فشرده شده و پس از استخراج، با نام Milk_redhat ظاهر میشد. هیچ مدرکی مبنی بر اجرای Milk_redhat در این سیستم پیدا نکردن.

محققا همچنین مشاهده کردن که هکرها، فایلهای زیر رو هم به یکی از سرورهای آلوده انتقال دادن:

LOGBLEACH (b.ue → b.gz → lin64_bleach)
SLAPSTICK Installer (p.ue → p.gz → PamX-0.42-Linux.x86_64_)
Bash Script (uu1.ue → run.gz → NOTES)

محققا یک اسکریپت Bash (uu1.ue → run.gz → NOTES) شناسایی کردن که یک اسکریپت Perl، برای uuencode تولید کرده و اطلاعات سیستمی رو از میزبان جمع‌آوری میکرد. اطلاعات جمع‌ آوری‌ شده شامل موارد زیر بودن:

HOSTNAME
USER LOGON
NETWORK INFORMATION
NETSTAT
ARP
/etc/hosts
/etc/passwd
/etc/shadow
/etc/security/passwd
/etc/sudoers
/usr/local/etc/sudoers
CRONTAB
HISTORY FILES
WTMP
System log
FIREWALL
TOMCAT USERS
ORACLE HOSTS
SSH KNOWN HOSTS
LIST HOMES FOLDER
HOST STORAGE
LDAP
/etc/ntp.conf
/etc/mail/sendmail.cf
/etc/resolv*

HOSTNAME

USER LOGON

NETWORK INFORMATION

NETSTAT

ARP

/etc/hosts

/etc/passwd

/etc/shadow

/etc/security/passwd

/etc/sudoers

/usr/local/etc/sudoers

CRONTAB

HISTORY FILES

WTMP

System log

FIREWALL

TOMCAT USERS

ORACLE HOSTS

SSH KNOWN HOSTS

LIST HOMES FOLDER

HOST STORAGE

LDAP

/etc/ntp.conf

/etc/mail/sendmail.cf

/etc/resolv*

کد اسکریپت Bash رو در زیر مشاهده میکنید:

echo 'print "begin 644 $ARGV[0]\n";' > ue
echo 'print pack ("u", $bloc) while read (STDIN, $bloc, 45);' >>ue
echo 'print "`\n";' >> ue
echo 'print "end\n";' >> ue
echo 'exit 0;' >> ue

echo 'print "begin 644 $ARGV[0]\n";' > ue

echo 'print pack ("u", $bloc) while read (STDIN, $bloc, 45);' >>ue

echo 'print "`\n";' >> ue

echo 'print "end\n";' >> ue

echo 'exit 0;' >> ue

کد اسکریپت پرل uu-decode بصورت زیر هستش:

while ( < > ) {
  if (/^begin [0-7][0-7][0-7] ([^\n ]+)$/) {
    open(OUTPUT, ">$1") || die "Cannot create $1\n";
    binmode OUTPUT;
    while ( < > ) {
      last
      if / ^ end$ / ;
      $block = unpack("u", $_);
      print OUTPUT $block;
    }
    close OUTPUT;
  }
}
exit 0;

while ( < > ) {

if (/^begin [0-7][0-7][0-7] ([^\n ]+)$/) {

open(OUTPUT, ">$1") || die "Cannot create $1\n";

binmode OUTPUT;

while ( < > ) {

last

if / ^ end$ / ;

$block = unpack("u", $_);

print OUTPUT $block;

}

close OUTPUT;

}

exit 0;

فایلهای انکد شده به مسیرهای dev/shm/gconf-root (حافظه ی اشتراکی) و var/tmp/gconf-root کپی شده بودن. بعد از دیکد و اجرای فایلهای مخرب، مهاجم اونارو با دستور rm -rf حذف کرده بود.

rm -rf *
rm -rf /var/tmp/gconf-root

1 2	rm -rf * rm -rf /var/tmp/gconf-root

مهاجم، SSH رو طوری پیکربندی کرده بود که کلیدهای عمومی سروری که مهاجم به اون وصل میشه رو در فایل known_hosts ذخیره نکنه و در نتیجه هیچ مدرک فارنزیکی روی سیستمهای آلوده باقی نمونه. این ویژگی بصورت پیش‌ فرض هم برای ssh و هم scp فعال شده بود:

alias ssh="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"

alias scp="scp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"

alias ssh="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"

alias scp="scp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"

همانطور که قبلا گفته شد، ماژولهای PAM جایگزین شده و به SLAPSTICK تبدیل شده بودن. مهاجم ماژول اصلی PAM یعنی pam_unix.so رو به pam_unix,so تغییر داده بود. یکی از قابلیتهای SLAPSTICK این بود که تمام داده‌های احراز هویت عبوری از PAM رو ضبط و اونارو در فایلی رمزگذاری‌ شده در مسیر var/tmp/.font-unix ذخیره میکرد. داده‌های ذخیره شده در این فایل عبارتند از: تاریخ پروتکل، نام کاربری، پسورد، مبدا، میزبان، وضعیت احراز هویت.

در این مرحله مهمه که بدونیم، کیلاگر WINGHOOK هم روی چندین سرور کشف شد که برای سرقت اعتبارنامه‌ها استفاده میشد. طبق نمونه‌ های بدست‌ آمده، WINGHOOK داده‌ها رو ثبت و در فایل رمزگذاری‌ شده‌ای در مسیر var/tmp/.zmanDwJ2Og ذخیره میکرد. گرچه نام فایلها در سرورها متفاوت بود، اما الگوی ثابتشون، وجود نامی مشابه zmanDwJ2Og. بود. نمونه‌های WINGHOOK در مسیرهای زیر روی سرورها کشف شدن:

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

Iodine و OpenVPN هم روی سرورها کشف شده. Iodine ابزاری است که ترافیک IPv4 رو داخل پروتکل DNS تونل میکنه و به مهاجم امکان میده فایروالها و محصولات امنیتی شبکه رو دور بزنه و بدون شناسایی دسترسی بگیره. اسکریپتهای Iodine و OpenVPN در مسیر etc/init.d ذخیره شده بودن و در update-rc.d ثبت شده بودن تا بصورت خودکار با راه‌اندازی سیستم اجرا بشن. ابزارها رو در مسیرهای زیر پیدا کردن:

پس از کشف اولیه ی دستکاری داده‌های ATM، دامپ حافظه ی سرورهای ATM بررسی شد. نتایج نشان داد که یک روت‌‌کیت کرنل به نام CAKETAP نصب شده که تحت نام ماژول ipstat لوود میشه. CAKETAP داده‌های ارسال‌ شده از سرور ATM رو رهگیری کرده، اونارو با شرایط از پیش تعریف‌ شده تطبیق میده، اگه شرایط درست باشن، داده رو قبل از ارسال تغییر میده.

بصورت کلی منطق این هک به این صورت بوده که:

هکرها کارتهای جعلی تولید کرده بودن تا بدون داشتن PIN واقعی بتونن از ATM پول برداشت کنن.
برای اجرای این حمله، یک روت‌کیت کرنلی بنام CAKETAP روی سرور ATM نصب کرده بودن.
وقتی کارت وارد ATM میشه، دستگاه یک پیام “تأیید PIN” تولید و ارسال میکنه.کارتهای جعلی طوری طراحی شدن که این پیام شامل یک نشانگر مخفی باشه. این نشانگر با یک الگوریتم اختصاصی و بر اساس شماره کارت (PAN) و چند فیلد داینامیک محاسبه میشد و فقط کارتهای جعلی میتونستن اون رو تولید کنن.
روت‌کیت CAKETAP تمام پیامهای تأیید PIN رو بررسی میکرد. اگه پیام حاوی این نشانگر مخفی بود، CAKETAP تشخیص میداد که کارت جعلی است و PAN مربوط به اون رو در حافظه ذخیره میکرد تا در مراحل بعدی استفاده بشه.
اگه کارت واقعی بود، CAKETAP در روند دخالت نمیکرد و پیام تأیید PIN بدون تغییر به سیستم بانکی ارسال میشد.
اما اگه کارت جعلی بود، مرحله اصلی حمله فعال میشد. CAKETAP پیام تأیید PIN جعلی رو با یک پیام واقعی که قبلا از یک تراکنش معتبر ضبط کرده بود، جایگزین میکرد.این پیام واقعی قبلا توسط سیستم بانکی تأیید شده بود.
در نتیجه، سیستم بانکی پیام رو معتبر تشخیص میداد، فرآیند تأیید PIN با موفقیت انجام میشد و مهاجم میتونست بدون داشتن PIN واقعی، برداشت وجه انجام بده، بدون اینکه هشدار یا نشانه‌ای از تقلب ایجاد بشه.

CAKETAP برای مخفی کاری، شواهد نصب خودش در کرنل رو حذف و فایل ماژول کرنلی ipstat رو در مسیر sys مخفی میکنه. آنالیز نمونه ی CAKETAP نشان داد که یک روش ساده برای تشخیص اون وجود داره: اجرای دستور زیر:

mkdir path_to_any_directory/.caahGss187S

1	mkdir path_to_any_directory/.caahGss187S

خروجی مقدار فعلی هوک sys_write رو تولید میکنه که نشان دهنده تعداد دفعاتی است که CAKETAP داده‌های خروجی رو تغییر داده.

در جریان بررسی، یک نسخه از SUN4ME، که توسط STEELCORGI پک شده بود، در مسیر زیر دیده شده:

 /lib64/libs4m.so.1.2.3

1	/lib64/libs4m.so.1.2.3

SUN4ME ابزاری است برای ریکان داخلی، حرکت جانبی، اکسپلویت، تعامل با میزبانهای آلوده.

نوامبر 2023: بانک B در اندونزی

در نوامبر 2023، محققای Group-IB پس از اینکه تیم IT یک مؤسسه مالی در اندونزی متوجه احتمال هک شدن یک سرور داخلی شد، برای انجام آنالیز فارنزیکی فراخوانده شدن. در بررسی اولیه، وجود دو ابزار مخرب SLAPSTICK و STEELCORGI روی این سرور کشف شد. این کشف باعث شد تحقیقات گسترده‌تری روی چندین میزبان در زیرساخت بانکی سازمان انجام بشه تا میزان و وسعت نفوذ مشخص بشه.

تسلط مهاجم بر محیط لینوکس: TTPهای استفاده‌ شده نشان میده مهاجم مهارت بسیار بالایی در محیطهای لینوکسی داره و تونسته برای مدت طولانی بدون شناسایی باقی بمونه. مهاجم از روشهای مخفی کاری مختلف مانند: پاکسازی لاگها، مبهم کردن فایلها و ادغام فعالیتهاشون با رفتار طبیعی سیستم، برای جلوگیری از کشف شدن استفاده کرده.
استقرار چندین خانواده ی بدافزار: محققای Group-IB چندین خانواده‌ ی بدافزار مختلف در شبکه کشف کردن که هر کدام کاربرد جداگانه‌ای داشتن. بررسی لاگهای احراز هویت یکی از این بدافزارها نشان داد اولین نشانه‌ی نفوذ به ۲۹ سپتامبر ۲۰۱۹ برمیگرده. با استفاده از رولهای تشخیص ویژه، محققا چندین میزبان رو اسکن و تأیید کردن که ۲۱ سیستم هک آلوده شدن.
C2: اتصالهای C2 به اینترنت از طریق چهار سرور شناسایی شد که با استفاده از آدرسهای Dynamic DNS در ارتباط بودن. این ارتباطها از طریق بکدور TINYSHELL برقرار شده بود. Dynamic DNS سرویسی که اجازه میده یک دامنه (مثل example.ddns.net) به یک IP که مدام تغییر می‌کند وصل شود.
حرکت جانبی با پسوردهای منحصر به فرد: مهاجم برای حرکت جانبی در شبکه، از SSH با رمزهای خاصی استفاده کرده. هر رمز برای هر سرور متفاوت بوده و مخصوص همان هدف طراحی شده بوده.
نقطه ورود اولیه: نقطه ورود اولیه مهاجم مشخص نشد. چون اولین نشانه هک بیش از ۴ سال قبل اتفاق افتاده و لاگها یا داده‌های لازم برای تحلیل دقیق در دسترس نبودن.
استقرار WebShell: محققا تعداد زیادی Web Shell در سرورهای وب مختلف پیدا کردن. احتمالا مهاجم از یک آسیب‌پذیری در وب‌ اپلیکیشنها استفاده کرده و Web Shellها رو مستقیما روی سرورها آپلود کرده.

تحلیل نوامبر ۲۰۲۳:بانک B در اندونزی

در جریان تحقیقات این پرونده، محققای Group-IB کشف کردن که مهاجم از باینریهای مختلفی برای لوود بدافزار یا اجرای اون در سیستمهای آلوده استفاده کرده:

باینری atd تغییر یافته بود تا بعنوان TINYSHELL عمل کنه. در حالت عادی، atd یک سرویس پس‌ زمینه‌ی پیش‌فرض برای ابزار at در لینوکس است. اما در نسخه‌ی تغییر‌یافته، این فایل وظیفه‌ی ایجاد پایداری برای بکدور TINYSHELL رو بر عهده داشت. علاوه بر این دستکاری، ماژول PAM سازمان هدف هم تغییر داده شده بود. ماژول PAM با یک کتابخانه‌ی مخرب بنام SLAPSTICK جایگزین شده بود و فایل اصلی pam_unix.so به pam_unix,so تغییر نام یافته بود.

مهاجم از تکنیکهای مختلفی برای فرار از شناسایی و سخت کردن آنالیز بدافزار استفاده کرده بود. بدافزار LOGBLEACH در یکی از نقاط پایانی از طریق هشدارهای سیستم EDR شناسایی شد. محققا بدافزار LOGBLEACH رو در مسیر/dev/shm با نام bbb پیدا کردن. این مسیر یک فضای ذخیره‌سازی موقت در لینوکس است. برای مخفی ماندن بیشتر، بدافزار از تکنیکهایی مانند مبهم‌ کردن، رمزگذاری رشته ها و پیلودها، مکانیزمهای ضد دیباگ و وابستگی به شرایط محیط، استفاده کرده بود.

همچنین، لاگهایی که توسط بدافزار SLAPSTICK تولید می‌شدن، رمزگذاری شده و در مسیر var/tmp/.font-unix ذخیره می‌شدن.

مهاجم برای فایلهای مخرب خودش از نامهایی استفاده میکرد که شبیه فایلهای سیستمی پیش‌فرض لینوکس بودن:

محققا کشف کردن که مهاجم از SLAPSTICK (نسخه تغییر‌یافته ماژول PAM) برای دور زدن بررسیهای PAM استفاده کرده. این بکدور شامل یک رمز عبور جادویی بود که داخلش هاردکد شده بود. همانطور که قبلا گفته شد، ماژول PAM در میزبانهای آلوده با SLAPSTICK جایگزین شده و فایل pam_unix.so اصلی به pam_unix,so تغییر نام داده شده بود. SLAPSTICK قادر بود تمام داده‌های احراز هویت که از PAM عبور میکرد رو شنود و ذخیره کنه. بعدش این داده‌ها رو بصورت رمزگذاری‌ شده داخل فایل var/tmp/.font-unix نگهداری میکرد.

تله‌متری EDR یکی از نقاط پایانی نشان داد مهاجم دستوری اجرا کرده که این لاگهای رمزگذاری‌ شده رو از حالت مبهم خارج و می خونده:

"cat .font-unix_ | tr '[&.?/S-ZM-RG-LA-Fs-zm-rg-la-f4-90-3]' '[/:.A-Za-z0-9]'"

1	"cat .font-unix_ \| tr '[&.?/S-ZM-RG-LA-Fs-zm-rg-la-f4-90-3]' '[/:.A-Za-z0-9]'"

این تکنیک به مهاجم اجازه میداد بدون داشتن حساب کاربری معتبر وارد سیستم بشه. اگه مقدار فیلد پسورد با اون مقدار مشخص (رمز جادویی) شروع میشد، SLAPSTICK کاربر رو با موفقیت احراز هویت میکرد.

محققا همچنین یک باینری رمزگذاری‌ شده با STEELCORGI پیدا کردن که پس از رمزگشایی، بدافزار SUN4ME از داخلش استخراج شده. بر اساس تحقیقات هوش تهدید Group-IB، این بدافزار توسط مهاجم برای ریکان داخلی، حرکت جانبی، اکسپلویت و تعامل با میزبانهای آلوده استفاده میشد.

برای حفظ دسترسی به شبکه‌های ایزوله، مهاجم TINYSHELL رو روی سرورهای متعدد نصب کرده بود و اون رو طوری پیکربندی کرده بود که به یک سرور دیگه در داخل شبکه متصل بشه. تحلیل پیکربندی TINYSHELL روی سرورهای آلوده نشان داد که اتصال C2 از طریق آدرسهای Dynamic DNS به اینترنت برقرار میشده. این روش باعث میشه IP واقعی سرور C2 مخفی بمونه و مهاجم بتونه در صورت بلاک شدن، IP رو به راحتی تغییر بده.

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

جولای 2024: بازگشت به بانک A در اندونزی

در جولای ۲۰۲۴، محققای Group-IB بار دیگه برای واکنش به حادثه (Incident Response) در همان سازمان مالی در اندونزی که قبلا در فوریه ۲۰۲۲ هدف قرار گرفته بود، وارد عمل شدن. این مأموریت شامل پاسخ‌ به یک حمله از سوی یک گروه APT با انگیزه مالی بود. بر اساس داده‌هایی که در جریان این مأموریت تحلیل شد، محققا خلاصه زیر رو ارائه کردن:

دسترسی اولیه: مهاجم از طریق یک Raspberry Pi تونسته دسترسی اولیه به شبکه هدف رو بدست بیاره.
روش نفوذ: روش دقیق نفوذ مشخص نشد، زیرا مهاجم قابلیت لاگ دستورات رو در Raspberry Pi غیرفعال کرده بود.
اولین نشانه نفوذ: بر اساس لاگهای موجود، اولین نشانه از نفوذ مربوط به ۴ فوریه ۲۰۲۴ بود.
حرکت جانبی: حرکت جانبی با استفاده از پروتکل SSH و بدافزار SLAPSTICK (با رمز جادویی) انجام شده.
استفاده از SUN4ME: مشاهده شد که مهاجم از ابزار SUN4ME برای ریکان شبکه و حذف لاگها استفاده کرده. این ابزار در حملات قبلی مهاجم به همان مؤسسه مالی استفاده نشده بود.

تحلیل جولای 2024 : بانک A در اندونزی

در این مورد، تیم امنیتی بانک یک دستگاه Raspberry Pi رو کشف کرد که به یکی از سوئیچهای پشت یک دستگاه خودپرداز متصل شده بود و مستقیما به شبکه ی ATM، دسترسی داشت. بر اساس ایمیجی که از این Raspberry Pi بدست اومده، مشخص شد که این دستگاه توسط سرور DHCP سه آدرس IP متفاوت دریافت کرده. تحلیلها نشان داد اولین تلاش Raspberry Pi برای اتصال به شبکه هدف در ۴ فوریه ۲۰۲۴ انجام شده.

محققا دستورات اجرا شده توسط مهاجم، که Wazuh اونارو لاگ کرده و این لاگها در ELK ذخیره شدن و همچنین تمام فایلهای جمع‌ آوری‌ شده‌ی bash_history رو بررسی کردن، که نمونه هایی از اون رو در زیر مشاهده میکنید:

scp -t /tmp
snap
snap bleach -a -z 9999 -C -y
snap bleach -i [redacted_ip] -0 -C -y
snap -t1 [redacted_ip]/24 22
ping -c 1 [redacted_ip]
snap -t1 [redacted_ip] tcpf
/usr/bin/python /usr/lib/command-not-found -- snap
./snap
ssh [redacted_ip]
ssh [redacted_ip] -l egik bash
/usr/bin/python /usr/lib/command-not-found -- -t1
ss -t1 [redacted_ip]/24 22
ssh administrator@[redacted_ip]
snap bleach
snap bleach -n [redacted] -z 999999 -C -y
rm -f snap

scp -t /tmp

snap

snap bleach -a -z 9999 -C -y

snap bleach -i [redacted_ip] -0 -C -y

snap -t1 [redacted_ip]/24 22

ping -c 1 [redacted_ip]

snap -t1 [redacted_ip] tcpf

/usr/bin/python /usr/lib/command-not-found -- snap

./snap

ssh [redacted_ip]

ssh [redacted_ip] -l egik bash

/usr/bin/python /usr/lib/command-not-found -- -t1

ss -t1 [redacted_ip]/24 22

ssh administrator@[redacted_ip]

snap bleach

snap bleach -n [redacted] -z 999999 -C -y

rm -f snap

همچنین دستورات زیر در فایل bash_history کاربر root در میزبان آلوده مشاهده شده:

cd /tmp;alias s=snap
s bleach -a -z 999 -C -y
w
ls -altr
s nc110
./snap
export PATH='.:/:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/:/usr/
local/bin:/usr/local/sbin:/opt/X11/bin'
export MCARCH_=[redacted_decryption_key]
./snap nc110
s bleach -i [redacted_ip] -0 -C -y
ping -c 1 [redacted_ip]
ssh [redacted_ip]
ssh [redacted_ip] -l egik bash
s -t1 [redacted_ip]/24 22
ss -t1 [redacted_ip]/24 22
ssh administrator@[redacted_ip]
s bleach
s bleach -n [redacted] -z 999999 -C -y
rm -f snap

cd /tmp;alias s=snap

s bleach -a -z 999 -C -y

ls -altr

s nc110

./snap

export PATH='.:/:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/:/usr/

local/bin:/usr/local/sbin:/opt/X11/bin'

export MCARCH_=[redacted_decryption_key]

./snap nc110

s bleach -i [redacted_ip] -0 -C -y

ping -c 1 [redacted_ip]

ssh [redacted_ip]

ssh [redacted_ip] -l egik bash

s -t1 [redacted_ip]/24 22

ss -t1 [redacted_ip]/24 22

ssh administrator@[redacted_ip]

s bleach

s bleach -n [redacted] -z 999999 -C -y

rm -f snap

بطور خلاصه، فعالیتهای زیر توسط مهاجم در طول این نشست روی میزبان آلوده مشاهده شده:

انتقال ابزارها به سایر میزبانها
ایجاد متغیر محیطی برای آنپک کردن STEELCORGI
پاکسازی لاگها و تاریخچه‌ی دستورات
حذف لاگهایی که شامل ورودی [redacted_ip] بودن
کشف سیستمهای راه دور
تلاش برای SSH به سایر میزبانها
حذف باینری snap

مهاجم فایل اصلی PAM رو با کتابخانه‌ی اشتراکی مخرب SLAPSTICK جایگزین کرده. فایل اصلی pam_unix به pam_unix.so تغییر نام داده شده. ماژولهای PAM در سرورهای مختلف تغییر یافته بودن. در یکی از میزبانها، دیده شد که مهاجم برای حفظ پایداری از TINYSHELL و از طریق ایجاد یک اسکریپت init و یک سرویس استفاده کرده. این کار باعث میشد TINYSHELL بصورت خودکار هنگام بوت سیستم‌ عامل اجرا بشه.

محققان یک تکنیک مستند سازی‌ نشده رو شناسایی کردن که مهاجم برای مخفی کردن پروسس ها از ابزارهای نمایش لیست اتصالات و پروسسها، مانند ‌netstat و ss، استفاده کرده بود. در جریان بررسیها مشخص شد که میزبان آلوده (host1) حتی بعد از جدا شدن Raspberry Pi از سوئیچ، همچنان اتصالات فعال به اون برقرار میکرد. به همین دلیل، محققا بررسی کردن که کدام پروسس به پورت 929 در Raspberry Pi اتصال ایجاد میکنه. در این مرحله مشخص شد که مهاجم از یک تکنیک مستند سازی‌ نشده برای مخفی کردن پروسس ها از لیستهای استاندارد استفاده کرده. این تکنیک بعدها بطور کامل در یک پست وبلاگی توضیح داده شد.

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

شکل زیر خروجی دستور netstat از host1 است.

بر اساس خروجی netstat و ss که به‌ مدت ۶۰۰ ثانیه اجرا شدن، مشخص شد که میزبان نه‌ تنها به Raspberry Pi متصل میشه، بلکه ارتباطی هم با میزبان دیگه ای (HOST2) برقرار میکنه که بعدا بعنوان یک سرور ایمیل شناسایی شد. نکته مهم اینکه برنامه‌هایی که مسئول این اتصالات بودن قابل شناسایی نبودن. همچنین خروجی ps هم هیچ پروسس مشکوکی رو نشان نمیداد.

با این حال، بعد از تحلیل حافظه‌ی dump میزبان host1، دو پروسس مشکوک کشف شد: tmp/lightdm و var/snap/.snapd/lightdm.

با اینکه LightDM یک Display Manager معتبر است، مهاجم TINYSHELL رو با نام lightdm مستقر و با آرگومان lightdm –session 11 19 اجرا کرده بود.

این دو پروسس در مسیرهای غیرمعمول قرار داشتن، از جمله مسیرهایی که قبلا هم توسط مهاجم استفاده شده بودن (مثل var/snap/.snapd/snap). مهندسی معکوس نشان داد که هر دو پروسس نسخه‌ی TINYSHELL هستن و هر دو به فایل پیکربندی conf. اشاره داشتن.

شکل زیر PID پروسس TINYSHELL رو نشون میده.

در تحلیل عمیقتر حافظه مشخص شد، مهاجم یک دایرکتوری مجازی روی فایل‌ سیستم proc مانت کرده و بطور خاص دایرکتوری مربوط به پروسس TINYSHELL رو در مسیر proc مخفی کرده تا ابزارهای نمایش لیست پروسس ها، اون رو نمایش ندن.

tmpfs on /proc/8239 type tmpfs (rw,nosuid,nodev)
/dev/vda1 on /proc/8914 type ext4 (rw,relatime,errors=remountro,data=ordered)

1 2	tmpfs on /proc/8239 type tmpfs (rw,nosuid,nodev) /dev/vda1 on /proc/8914 type ext4 (rw,relatime,errors=remountro,data=ordered)

مهاجم همچنین باینری SUN4ME رو با نام جعلی snap مخفی کرده بود. باینری snap اصلی معمولا در مسیر usr/bin/snap قرار داره.

برای پاک کردن لاگهای لینوکس، مهاجم از LOGBLEACH (که بخشی از SUN4ME است) استفاده کرده بود که خودش رو بجای باینری snap جا زده بود. نسخه‌ی مخرب snap در میزبان آلوده اصلی بازیابی نشد، اما روی host1 در مسیر var/snap/.snapd/snap پیدا شد. این باینری رمزگذاری‌ شده با STEELCORGI بود و پس از رمزگشایی مشخص شد همان SUN4ME است.

بر اساس اطلاعات تهدید عمومی، این مهاجم معروفه که از SUN4ME برای ریکان داخلی، حرکت جانبی، اکسپلویت و تعامل با میزبانهای آلوده استفاده میکنه. همچنین مشاهده شد که مهاجم از SLAPSTICK استفاده کرده؛ بدافزاری که از تکنیک “رمز جادویی” برای حرکت جانبی استفاده میکنه. در یکی از موارد، مهاجم با استفاده از اکانت کاربری معتبر [redacted_username1] از Raspberry Pi یک اتصال SSH به host1 برقرار کرده بود.

در یک مورد دیگه، مشاهده شده که مهاجم از حساب کاربری [redacted_username2] هم برای انتقال ابزارها و ایجاد یک اتصال SSH از host3 به میزبان آلوده استفاده کرده.

بر اساس تحلیل دستورات استخراج‌ شده از ELK، مشخص شد مهاجم دستور زیر رو اجرا کرده:

scp -t /tmp

1	scp -t /tmp

این همان روشی است که در حملات پیشین هم مشاهده شده بود، جاییکه مهاجم از SCP برای انتقال فایل استفاده میکرد. اجرای این دستور باعث میشه میزبان آلوده در حالت انتظار قرار بگیره تا فایلهایی که از طریق پروتکل SSH منتقل میشن رو دریافت کرده و اونارو در مسیر tmp ذخیره کنه.

شباهتهای نمونه‌های STEELCORGI بین موارد مختلف

همانطور که قبلا اشاره شد، محققا در چند حادثه‌ی متفاوت دخیل بودن، اما تمرکزشون روی دو حادثه‌ی جداگانه در دو سازمان مالی مختلف بود که بیش از یک سال فاصله زمانی داشتن. مورد جالب توجه زمانی بود که در پاسخ به حادثه‌ای در یک بانک در اواخر سال ۲۰۲۳ (بانک B)، دوباره با بدافزار STEELCORGI مواجه شدن.

با بررسی بیشتر مشخص شد که پیلود این بدافزار، با استفاده از متغیرهای محیطی رمزگذاری شده؛ مشابه همان چیزی که یک سال قبل در حادثه‌ی دیگه ای (در اواخر ۲۰۲۲ – سازمان A) مشاهده کرده بودن. با توجه به تجربه‌ی قبلی، انتظار نمیرفت کلیدهای رمزگشایی مورد استفاده در کمپین اول، دوباره قابل‌ استفاده باشن. اما پس از بررسی دقیق پیکربندی STEELCORGI مورد استفاده در بانک B، متوجه شدن که کلید رمزگشایی دقیقا با کلید مورد استفاده در بانک A تطابق داره.

نکته‌ی جالب تر اینکه در هر دو حادثه از یک نام متغیر محیطی یکسان برای رمزگشایی پیلود استفاده شده بود. این متغیر محیطی برای بانک A بصورت اختصاصی ساخته شده بود و بطور منطقی نباید در زیرساخت بانک B وجود داشته باشه. این موضوع دو احتمال رو مطرح میکنه:

مهاجمان به اشتباه پیلود اشتباهی رو در بانک B مستقر کرده‌.
توانایی رمزگذاری مجدد پیلود رو نداره و احتمالا خودشان توسعه‌ دهنده‌ی اصلی این کد نیستن.

Money Mules: روند برداشت پول

یکی از مهمترین پرسشها اینِ که مهاجمان چگونه تونستن پول رو از بانک برداشت کنن، چطوری Money Mules رو جذب کردن، چه کسی اونارو مدیریت میکرد و فرایند عملیاتی چگونه انجام میشد. در این بخش به این موضوعات پرداخته شده.

جذب Money Mules و شیوه های ارتباطی:

طبق تحقیقات محققا، Money Muleها از طریق تبلیغات عادی گوگل برای جستجوی کار در خارج از کشور جذب میشدن. در یک مورد دیگه، یک Money Mule هنگام تعطیلات در آسیا، از طریق تلگرام پیشنهاد کار دریافت کرده بود. در تمام این موارد، فرد ناشناس، که از این پس به اون “هماهنگ‌ کننده” میگیم، از قربانی میخواست برای ادامه‌ی گفتگو به مسنجر Wickr Me بیاد.

نحوه ارتباط هماهنگ‌ کننده با Money Muleها:

استخدام کننده در Viber ارتباط رو شروع میکنه و از طریق Privnote، یک سرویس آنلاین برای ارسال یادداشتهایی که بعد از مدتی نابود میشن، اطلاعات تماس Wickr Me مربوط به Money Mule رو با هماهنگ کننده به اشتراک میذاره. در ادامه هماهنگ کننده برای ارتباطات بیشتر و هماهنگی وظایف از طریق Wickr Me ارتباط برقرار میکنه.

تکثیر کارت بانکی:

بعد از اینکه Money Muleها موافقت میکردن با هماهنگ‌ کننده همکاری کنن، دستورالعملهای بیشتری دریافت میکردن مثلا خرید لپ‌ تاپ دست‌ دوم از بازار الکترونیک. برخی هم جلسه حضوری داشتن. مهم ترین بخش کار، یعنی تجهیزات کلون‌ کردن کارت و خود کارتها، به Money Muleها تحویل داده میشد. براساس اعترافات افراد دستگیر شده، این تجهیزات توسط شخصی با ظاهر ناشناس، مردی با کلاه و ماسک که اسمش رو نمیگفت و به زبان فرد دستگیر شده صحبت میکرد، تحویل داده میشد. به Money Muleها دستور داده شده بود:

فقط از TeamViewer برای دسترسی از راه دور استفاده کنن.
اینترنت رو فقط از دیتای موبایل خودشون فعال کنن.

هکرها نمیخواستن Money Muleها بیش از حد لازم از عملیات مطلع بشن. وظایف اونا ساده بود:

پذیرفتن اتصال TeamViewer
قرار دادن یا خارج کردن کارتها طبق دستور مهاجمان

دامپ کارتها و فایلهای مرتبط در مسیرهای نامعمول و غیر استاندارد روی لپ‌ تاپهای Money Muleها ذخیره میشد تا سطح آگاهی اونا محدود بمونه.

شکل زیر نحوه ی تعامل Money Muleها و بازیگران تهدید رو نمایش میده.

در جریان نشستهای TeamViewer، هماهنگ‌ کننده از یک ابزار به نام writer.exe استفاده میکرد.

این برنامه یک اپلیکیشن Windows مبتنی بر NET Core 3.1. است که بعنوان یک Wrapper برای کار با ShellGPShell 1.4.4 عمل میکنه. GPShell یک مفسر اسکریپت متن‌ باز است که برای تعامل با کارتهای هوشمند (Java Card) مطابق با استاندارد GlobalPlatform استفاده میشه و قابلیت بازنویسی داده‌های کارت رو داره. برای دسترسی به برنامه، رمزی استفاده میشد که بصورت ۵ هش MD5 در فایل license ذخیره شده بود.

شکل زیر نحوه ی کار writer.exe رو نشان میده.

شکل زیر دستورات GPShell هنگام خوندن کارتها رو نشان میده.

شکل زیر هم نمونه‌ای از دستورات GPShel مورد استفاده برای خوندن کارتهای ATM رو نشان میده.

فرآیند نقد کردن از ATM:

Money Muleها نقش بسیار مهمی در عملیات داشتن. یکی از وظایف اصلی اونا این بود که، به ATMهای مختلف مراجعه کنن، از اونا عکسهایی با جزییات بالا تهیه کنن. این عکسها به مهاجمان کمک میکرد تا دستگاهها رو بهتر تحلیل کرده و عملیات برداشت پول رو دقیقتر برنامه‌ریزی کنن.

پس از اینکه مهاجمان کارتهای قربانیان رو کلون میکردن، Money Muleها موظف بودن به دستگاههای ATM که انتخاب شده بود برگردن و کارهای مشخص‌ شده رو انجام بدن. با هدایت مهاجم، معمولا از طریق تماس صوتی یا تصویری، Money Muleها گام به گام عملیات رو انجام میدادن. فرایند شامل:

وارد کردن کارت کلون‌ شده
وارد کردن داده‌های خاص
خارج کردن کارت
تکرار چرخه بصورت سیستماتیک

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

با استفاده از Money Muleها بعنوان واسطه، مهاجم میتونست، از فاصله‌ای امن عمل کنه و ریسک شناسایی رو به حداقل و سود غیرقانونی رو به حداکثر برسونه.