Exfiltration Over Web Service (T1567)

מהי הוצאת נתונים (exfiltration) דרך שירות web?

הוצאת נתונים דרך שירות web היא מצב שבו תוקף מוציא נתונים גנובים דרך שירות חיצוני לגיטימי, כמו Google Drive, Dropbox או webhook של Discord, במקום דרך ערוץ ה-C2 שלו. MITRE ATT&CK מקטלגת את זה כ-T1567. התעבורה נבלעת ברעש כי הרשת כבר דיברה עם אותו שירות קודם.

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

הרשומה קצרה ושווה להציג אותה נקי. T1567 יושבת תחת הטקטיקה Exfiltration, חלה על ESXi, Linux, Office Suite, SaaS, Windows ו-macOS, ועודכנה לאחרונה ב-12 במאי 2026 בגרסה 1.5. יש לה ארבע תת-טכניקות, והן לא וריאציות על אותו נושא.

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

הסבירו לי כאילו אני בן 10

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

למה זו טכניקה נפרדת מהוצאת נתונים דרך C2

ההגדרה של MITRE מכילה את ההבחנה כבר בשורה הראשונה שלה: יריבים משתמשים בשירות web חיצוני לגיטימי "במקום בערוץ ה-command and control הראשי שלהם".

זה חשוב תפעולית, כי זה אומר שזיהוי שנבנה סביב C2 לא מגיע לשם. אין implant שעושה beaconing לתשתית של התוקף. יש מארח שמדבר עם Google Drive.

MITRE נותנת שלוש סיבות למה זה עובד, והן מצטברות:

• השיחה כבר קיימת. שירותי web פופולריים "עשויים לתת כיסוי משמעותי בגלל הסבירות שמארחים ברשת כבר מתקשרים איתם לפני החדירה."
• ה-firewall כבר מאשר את זה. "ייתכן שכבר קיימים כללי firewall שמתירים תעבורה לשירותים האלה."
• ה-payload כבר מוצפן. ספקים "משתמשים בדרך כלל בהצפנת SSL/TLS, ונותנים ליריבים שכבת הגנה נוספת."

הנקודה השלישית מוגזמת באופן שגרתי, אז קראו אותה במדויק. MITRE אומרת שכבת הגנה נוספת, לא חוסר נראות. TLS מסמא בדיקת payload. הוא לא מסתיר את היעד, את הנפח, את התזמון, או איזה תהליך פתח את החיבור, וכל הארבעה נשארים זמינים לזיהוי. זו גם הגבול מול ערוץ C2 כנושא בפני עצמו: אותה מטרה, תשתית אחרת, ראיות אחרות.

ארבע תת-טכניקות, ארבע בעיות זיהוי

הטיעון החזק ביותר לכך שאלה בעיות נפרדות הוא מבני: MITRE מפרסמת אסטרטגיית זיהוי נפרדת לכל אחת מהן. זה ה-framework אומר, במודל הנתונים שלו עצמו, ש-push ל-repo ו-POST ל-webhook הם לא אותו ציד.

שני דברים נובעים מזה. לארטיפקטים כמעט אין מכנה משותף: כלי העברה עם קובץ קונפיגורציה לא מתנהג בכלל כמו סקריפט שיורה POST בודד. שנית, הענף שכדאי לבדוק קודם הוא זה שהסביבה שלכם באמת מריצה. חברת תוכנה עם GitHub בכל מקום מתמודדת עם בעיה ראשונה שונה מחברה שהעובדים שלה חיים ב-OneDrive.

הערת תיארוך אחת. שלוש מתוך ארבע רשומות תת-הטכניקות רועננו ב-12 במאי 2026, אבל אתרי אחסון טקסט עודכנו לאחרונה ב-15 באפריל 2025.

איך נראית בפועל הוצאת נתונים דרך אחסון ענן

דוגמאות הנהלים של MITRE לענף אחסון הענן כוללות קמפיין מתועד, שמקוטלג כ-C0015, שבו גורמי האיום העבירו קבצים ל-MEGA באמצעות Rclone. הרשומה מתעדת את ה-invocation בפועל, והדבר השימושי הוא לא לשחזר אותו אלא לקרוא אותו.

האלמנטים הניתנים לצפייה הם אלה:

• שם התהליך של כלי העברה לגיטימי.
• פועל ה-copy.
• remote מוגדר שמסתיים בנקודתיים - כלומר המפעיל כבר הגדיר ושימר יעד.
• מסנן גיל שמגביל את האיסוף לקבצים ששונו בתוך חלון זמן.
• נתיב UNC לשיתוף קבצים כמקור.
• דגלי parallelism שמעלים את מספר ההעברות הסימולטניות.

כשקוראים את זה ככוונה ולא כמחרוזת, האלמנטים האלה אומרים הרבה. מסנן הגיל הוא החלטת scoping - מישהו החליט שכל מה שיותר ישן מכמה שנים לא שווה את רוחב הפס. מקור ה-UNC אומר שהם כבר מצאו את השיתוף ולא עבדו קובץ-קובץ. דגלי ה-parallelism אומרים שהם מיטבו לתפוקה, וזה מה שעושים כשיודעים כמה לוקחים ורוצים לסיים.

הצורות המתועדות האחרות

שווה להכיר אותן כי הן נראות שונה זו מזו:

• Akira הוציאה נתוני קורבנות באמצעות Rclone.
• פעילות DUST של APT41 שלחה מידע שנאסף ל-OneDrive.
• BoomBox העלתה לתיקיות ייעודיות per-victim ב-Dropbox.
• APT28 הוציאה נתונים דרך Google Drive, כולל ב-Nearest Neighbor Campaign.
• BlackByte השתמשה בשירותי שיתוף קבצים כמו file.io ו-anonymfiles.com, וAPT41 השתמשה בשירותי Cloudflare בקמפיין אחר.

פרט אחד בהנחיות הזיהוי של MITRE מצחיק בשקט, והוא גם כל הנקודה של המאמר הזה. ה-analytic של אחסון הענן נושא רשימה ניתנת לכוונון בשם AllowedTools, שמתוארת כ-"כלים מוכרים שמשמשים באופן לגיטימי לגיבויים (rclone, gsutil)", כאשר סטיות מעוררות חשד. כלי הוצאת הנתונים נמצא ברשימת התוכנות המאושרות. ככה זה אמור להיות.

לשלמות ובלי דרמה: MITRE מתעדת עכשיו גם קמפיין, C0062, שבו יריב השתמש ב-Claude Code כדי לסכם נתונים שנאספו לפני שהוציא אותם דרך אותו שירות. זה שייך לכאן כי זה מראה את רוחב מה שנחשב שירות web, לא כי זה מפתיע.

העמוד הזה במכוון אינו סקירה של כל ערוץ שבו נתונים יכולים לצאת. זו העבודה של עמוד הוצאת הנתונים שלנו, שמכסה את תצוגת רמת הערוץ.

מה באמת לזהות

התחילו מהרצף ולא מהיעד. ה-analytics של MITRE לאחסון ענן מתארים שרשרת התנהגות: קריאות של קבצים רגישים, אחר כך דחיסה, אחר כך העלאה יוצאת. ב-Linux ה-analytic מציין את זה ישירות, ומחפש אירועים משורשרים שבהם tar או gzip רצים כדי לדחוס קבצים ואחריהם מגיעות בקשות HTTPS PUT או POST לשירותי אחסון מוכרים. ב-Windows הוא מחפש תהליכים חריגים שניגשים לקבצים מקומיים גדולים ואז מאתחלים HTTPS POSTs לדומיינים של אחסון ענן.

השדות קונקרטיים:

• Windows: קודי אירוע `WinEventLog:Security` 4663, 4670 ו-4656 לגישה לקבצים; קודי אירוע `WinEventLog:Sysmon` 1 ליצירת תהליך ו-3 ו-22 לחיבורי רשת.
• Linux: `auditd:EXECVE` להרצת פקודות ו-`auditd:SYSCALL` לקריאות של ספריות רגישות, לצד network flow.
• macOS: ה-unified log, שבו ה-analytic עוקב אחרי לקוחות סנכרון וסקריפטים שמפעילים APIs של אחסון ענן בהקשרים לא צפויים.

MITRE מציעה גם סף נפח התחלתי, וממסגרת אותו כדוגמה ולא ככלל: יותר מ-10MB בסשן בודד. התייחסו לזה כנקודת התחלה לכוונון, לא כמספר לאמץ.

ואז החלק שמחליט אם משהו מזה שורד מגע עם production. אותו analytic נושא שתי רשימות ניתנות לכוונון נוספות לצד סף הנפח: UserContext, החשבונות שמותר להם להשתמש בשירותי ענן מאושרים, ו-AllowedTools, הכלים שמשמשים באופן לגיטימי לגיבויים. שתי הרשימות האלה אינן קישוט. בליהן, כל כלל שנכתב על הטכניקה הזו קורס לרשימת דומיינים - ורשימת דומיינים לא יכולה להבדיל בין Google Drive של צוות השיווק שלכם לבין זה של פורץ, כי זה אותו Google Drive.

Webhooks הם ציד אחר לגמרי

ענף ה-webhook חולק כמעט אפס ארטיפקטים עם ענף אחסון הענן, ולכן יש לו אסטרטגיה משלו. ב-Windows ה-analytic מחפש תהליכים חריגים כמו `powershell.exe`, `wscript.exe` או `mshta.exe` ששולחים POST ל-endpoints של webhook כמו Discord, Slack או webhook.site. ב-Linux הוא מחפש `curl` או `wget` ששולחים נתונים בכמות גדולה או מקודדים ב-POST. ב-macOS הוא מקשר פעולות קריאה מ-clipboard או מקובץ שאחריהן מגיע HTTPS POST לשירות webhook.

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

האם הגבלות tenant באמת עובדות?

הגבלת tenant היא הבקרה שהתחום ממליץ עליה הכי הרבה לטכניקה הזו, והיא בקרה טובה. הרעיון הוא להגדיר proxy או secure web gateway שיאכוף גבולות tenant ארגוניים, כך שעובדים יוכלו להגיע ל-Google Drive או OneDrive של הארגון עצמו, בעוד שהעברות לחשבונות אישיים באותה פלטפורמה ייחסמו.

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

המגבלות שלה ספציפיות באותה מידה. היא מטפלת בענף השירותים המאושרים ולא עושה כלום ל-code repository, לאתר paste או ל-webhook. היא תלויה בכך שה-proxy בכלל רואה את התעבורה, מה שמוציא מהתמונה כל דבר מחוץ לנתיב הארגוני. והיא בקרת גבול, לא בקרת תוכן: היא שולטת לאן נתונים רשאים ללכת, אף פעם לא מה הם הנתונים.

איפה הטיעון הזה נעצר

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

• שורת פקודה מתועדת היא קמפיין אחד, לא חתימה. האלמנטים של C0015 שימושיים להבנה, ושבירים ככלל. מפעילים משנים flags, משנים שמות לבינאריים ומכוונים ל-remotes שונים. MITRE בנתה את ה-analytic שלה סביב baselines ניתנים לכוונון ולא סביב מחרוזת קבועה בדיוק מהסיבה הזו, וזו הצורה העמידה.
• הבקרות המומלצות בתחום הן מוצקות. מניעת דליפת מידע (DLP), הגבלות tenant וניטור API של ענן הן עצות טובות. המאמר הזה מחדד איך ליישם אותן; הוא לא מחליף אותן.
• לנקודת ההצפנה יש תקרה. "שכבת הגנה נוספת" אינה חוסר נראות, והתייחסות ל-TLS כמבוי סתום היא הדרך שבה צוותים משכנעים את עצמם לוותר על זיהויים שהיו עובדים.
• למקורות יש מגבלות, מפורשות ולא מוסתרות. כלי Eviction Strategies של CISA נושא רשומה לטכניקה הזו, אבל תוכן אמצעי הנגד שלו לא מוצג בעמוד כפי שהוא מוגש, ולכן המאמר הזה לא מאפיין מה הוא ממליץ. ושום נתון שכיחות לא מופיע בשום מקום למעלה, כי אף אחד לא קיים בצורה שניתן לצטט. נתון הכלים היחיד שכן קיים - Rclone מופיע ב-57% מהתקריות במאגר הנתונים של ספק אחד - מכסה את ספטמבר 2023 עד יולי 2024 והוא הכלי שחזר והופיע בנתונים האלה, לא שיעור נוכחי.

שאלות נפוצות

מה זה T1567.002? תת-טכניקת אחסון הענן: הוצאת נתונים לשירות כמו Dropbox, Google Drive, OneDrive או MEGA במקום דרך ערוץ ה-C2. היא חלה על ESXi, Linux, Windows ו-macOS, ושווה לציין כי מקרה ה-hypervisor לעתים קרובות נשכח.

במה זה שונה מ-T1041, T1048 ו-T1537? T1041 היא הוצאת נתונים דרך ערוץ ה-C2 הקיים. T1048 היא הוצאת נתונים דרך פרוטוקול חלופי, כמו DNS. T1537 היא העברת נתונים לחשבון ענן אחר שבשליטתכם. T1567 היא זו שבה היעד הוא שירות web צד-שלישי לגיטימי שהרשת שלכם כבר מדברת איתו.

איך נראית הוצאת נתונים ב-Rclone בלוגים? כלי העברה שרץ עם פועל copy ועם remote שמור, קורא משיתוף קבצים, עם מסננים ו-parallelism מוגדרים. חפשו בטלמטריית יצירת תהליכים והרצת פקודות, ואז קשרו לסשן היוצא.

באיזה ענף כדאי לזהות קודם? זה שהסביבה שלכם מריצה. אם העובדים שלכם חיים ב-OneDrive, התחילו מאחסון ענן. אם אתם חברת תוכנה, code repositories ייצרו גם את הסיכון וגם את הרעש.

האם צריך לחסום את השירותים האלה? כמעט בוודאות לא, והניסיון הוא הדרך שבה זיהויים מכבים. הגרסה העובדת היא להחליט אילו tenants ואילו כלים מורשים, ואז להתריע על הסטייה.

מה ללכת לבדוק

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

שתי בדיקות, לכל ענף שתואם את הסביבה שלכם:

1. האם הטלמטריה שלכם תראה את השרשרת? לא את ההעלאה לבד, אלא את הרצף: קריאות של קבצים רגישים, אחר כך דחיסה, אחר כך ה-POST היוצא. אם יש לכם רק את הצעד האחרון, יש לכם רשימת דומיינים.
2. האם יש baseline להשוות מולו? כתוב: אילו tenants הם שלכם, ואילו כלי העברה מאושרים. ה-analytic של MITRE עצמה מניח ששתי הרשימות קיימות.

לרוב הארגונים יש את הראשונה ולא את השנייה. השנייה היא זו שהופכת כלל רועש לכלל עובד.