Exfiltration Over Web Service (T1567)

מה זאת Exfiltration Over Web Service?

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

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

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

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

תסבירו לי כמו לילד בן 10

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

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

ההגדרה של MITRE מכילה את ההבחנה הזאת בשורה הראשונה שלה: תוקפים משתמשים בשירות ווב (web service) חיצוני ולגיטימי, "ולא בערוץ השליטה והבקרה העיקרי שלהם".

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

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

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

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

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

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

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

הערה אחת לגבי תאריכים. שלוש מתוך ארבע רשומות תת-הטכניקות עודכנו ב-12 במאי 2026, אבל הרשומה של Text Storage Sites עודכנה לאחרונה ב-15 באפריל 2025.

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

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

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

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

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

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

כדאי להכיר את הדוגמאות האלה, כי הן שונות זו מזו.

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

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

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

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

מה בעצם כדאי לזהות

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

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

• בווינדוס: קודי אירוע WinEventLog:Security 4663, 4670 ו-4656 לגישה לקבצים; קוד אירוע WinEventLog:Sysmon 1 ליצירת תהליכים, ו-3 ו-22 לחיבורי רשת.
• בלינוקס: auditd:EXECVE להרצת פקודות, ו-auditd:SYSCALL לקריאה מתוך תיקיות רגישות, לצד תעבורת הרשת.
• ב-macOS: הלוג המאוחד, שבו כלל הזיהוי עוקב אחרי תוכנות סנכרון ותסריטים שקוראים ל-API-ים של אחסון בענן בהקשרים לא צפויים.

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

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

ענף ה-webhook הוא אתגר זיהוי שונה לגמרי

לענף ה-webhook כמעט אין עקבות משותפים עם ענף האחסון בענן, ולכן יש לו אסטרטגיית זיהוי משלו. בווינדוס כלל הזיהוי מחפש תהליכים חריגים כמו powershell.exe, wscript.exe או mshta.exe ששולחים POST לנקודות קצה של webhook כמו Discord, Slack או webhook.site. בלינוקס הוא מחפש curl או wget ששולחים נתונים בכמות גדולה או מקודדים בבקשת POST. וב-macOS הוא מצליב פעולות קריאה מלוח הגזירה או מקבצים, ואחריהן POST דרך HTTPS, לשירות webhook.

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

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

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

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

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

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

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

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

שאלות נפוצות

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

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

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

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

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

מה כדאי לבדוק

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

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

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

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