Exfiltration Over Web Service (T1567)

טכניקת exfiltration over web service היא שיטת תקיפה המתועדת ב-MITRE ATT&CK תחת הקוד T1567. בטכניקה הזו תוקף שולח נתונים גנובים דרך שירות אונליין קיים ולגיטימי, כגון אחסון בענן או מאגר קוד, ולא דרך ערוץ הבקרה הראשי שלו. הספק מפעיל את השירות, והתוקף מנצל אותו לרעה, כך שההעלאה יכולה להיראות שגרתית.

טכניקת exfiltration over web service מופיעה בדרך כלל במיפוי לפי MITRE ATT&CK, מאגר ידע ציבורי על שיטות תקיפה, או בדוח אירוע. המונח "Web service" מתייחס כאן לשירות אונליין רגיל, מהסוג שסביבת הקורבן כבר עשויה לתקשר איתו. מה שמגדיר את הטכניקה הוא התפקיד שהשירות מבצע: הוא מוציא את הנתונים הגנובים, ולא מי הבעלים של השרת.

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

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

איך exfiltration over web service עובדת

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

דרך אחת היא קו שכבר יש לתוקף. נוזקה במחשב שנפרץ שומרת על קשר עם שרת שהתוקף שולט בו, כדי לקבל ממנו הוראות ולשלוח לו תוצאות בחזרה. הקו הזה הוא ערוץ ה-C2 (command and control, C2), וגם הנתונים הגנובים יכולים לעבור בו, באותו סוג תעבורה שבו עוברות ההוראות.

מה שמייחד את הדרך הזו

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

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

המסגרת MITRE מחלקת את הטכניקה לארבע תת-טכניקות, אחת לכל סוג של יעד:

• אחסון בענן - Cloud storage (T1567.002): שירותים שמאפשרים למשתמשים לאחסן, לערוך ולאחזר קבצים דרך האינטרנט. MITRE נותנת את Dropbox ו-Google Docs כדוגמאות.
• מאגר קוד - Code repository (T1567.001): שירות שמפתחים שומרים בו קוד מקור, ולעיתים קרובות ניגשים אליו דרך API, הממשק שתוכנות משתמשות בו כדי לתקשר עם שירות.
• אתר לאחסון טקסט - Text storage site (T1567.003): אתר כמו Pastebin, שמפתחים משתמשים בו באופן נפוץ כדי לשתף קוד ומידע אחר. MITRE מציינת שתכונות בתשלום ואפשרויות הצפנה עשויות לאפשר לתוקפים לאחסן נתונים בצורה מאובטחת יותר.
• ה-Webhook (T1567.004): ה-webhook הוא דרך שבה שירות אחד דוחף נתונים לשירות אחר באינטרנט, בלי שהמקבל צריך לבקש אותם שוב ושוב. שירותים ציבוריים כמו Discord ו-Slack מאפשרים ללקוחות ליצור webhook endpoints. MITRE מתארת שני שימושים: הראשון הוא חיבור סביבה שבבעלות התוקף לשירות שהקורבן משתמש בו, כך שהשירות שולח נתונים אל ה-endpoint באופן אוטומטי ונתונים יוצאים שוב ושוב. השני הוא שליחת הנתונים שהתוקף אסף ישירות אל ה-endpoint. מכיוון ששירות אחד שולח נתונים לשירות אחר, הדרך הזו יכולה לפעול גם בין שירותי ענן, ולא רק ממכשיר.

למה קשה להבחין בתעבורה הזו מתעבורה רגילה?

המסגרת MITRE מונה שלושה תנאים שבעקבותיהם קשה להבחין בין העברה לשירות רגיל לבין שימוש יומיומי בו:

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

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

מה מקרים מתועדים מראים?

תולעת שהשתמשה במאגר קוד וב-webhook (קמפיין, ספטמבר 2025)

בהתראה שלה מ-23 בספטמבר 2025, CISA תיארה תולעת שמשכפלת את עצמה, הידועה בציבור בשם Shai-Hulud. התולעת פגעה ביותר מ-500 חבילות ב-npm, מאגר חבילות קוד בשפת JavaScript. הנוזקה שלה סרקה לאיתור פרטי הזדהות רגישים, כולל טוקני גישה (access tokens) של GitHub. לאחר מכן היא שלחה אותם ל-endpoint שבשליטת התוקף, והעלתה אותם למאגר קוד ציבורי. MITRE מתעדת שהמאגר נוצר בתוך חשבונו הפרוץ של המפתח עצמו. לכן הנתונים הגנובים נמצאו בחשבון האישי של המפתח בשירות לאחסון קוד, ומכיוון שהמאגר היה ציבורי, כל אחד יכול היה לקרוא אותם. MITRE מתעדת גם שנתונים סודיים הגיעו ל-webhook באתר webhook.site. ההתראה של CISA ממליצה לחסום חיבורים יוצאים לדומיינים של webhook.site, ולערוך ביקורת על webhooks שמוגדרים במאגרי קוד.

התקן חומת אש ששלח הודעות ל-Slack (דוח אירוע, דצמבר 2025)

הדוח של CERT Polska מינואר 2026 סוקר את המתקפות מ-29 בדצמבר 2025, ומתאר מתקפה על חברה יצרנית. התוקף חדר לרשת דרך התקן היקפי מבית Fortinet, והוסיף לו שני סקריפטים: אחד שמכוון לפרטי ההזדהות, והשני להגדרות האבטחה. להתקן יש תכונה מובנית לשליחת התראות לערוץ Slack מוגדר מראש. התוקף השתמש בה כדי לשלוח את הפלט של הסקריפטים לערוץ Slack שבשליטת התוקף. CERT Polska ממפה את המקרה הזה לתת-הטכניקה של webhook. כאן השולח היה התקן רשת, לא מחשב של משתמש, והיעד היה שירות שיתוף פעולה.

במה exfiltration over web service שונה מטכניקות הוצאת נתונים אחרות?

המסגרת ATT&CK מבדילה בין ארבע טכניקות קשורות, כל אחת לפי מאפיין מגדיר אחד.

הפרוטוקול DNS הוא אחד הפרוטוקולים שמפרטת MITRE תחת T1048.

טכניקה בשם דומה, T1102 Web Service, משתייכת לטקטיקת ה-C2, ולא להוצאת נתונים. היא משתמשת בשירות לגיטימי כדי להעביר נתונים אל מערכת שנפרצה וממנה.

מה מגינים יכולים לעשות, ואיפה הגבול של כל בקרה?

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

להגביל לאילו שירותים חיצוניים אפשר להגיע

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

להגביל אילו חשבונות אפשר להשתמש בהם בשירות

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

• הגנה במישור האימות (Authentication plane protection): חוסמת התחברות של חשבונות חיצוניים. פרוקסי ארגוני שמוסיף את ה-header מעניק רק את ההגנה הזו.
• הגנה במישור הנתונים (Data plane protection): מכסה מתקפות שעוקפות את ההתחברות, כגון גישה אנונימית או טוקן גישה, תעודה דיגיטלית שמוכיחה התחברות ומיובאת ממקום אחר. ההגנה הזו דורשת אכיפה מסוג אחר, כמו הניהול ש-Microsoft מפעילה על התקני Windows.

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

לבדוק מה שנשלח

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

הגדרות ה-Endpoint DLP של Microsoft מדגימות את הטווח:

• בקרת אפליקציות: התכונה Endpoint DLP יכולה להגביל אילו אפליקציות יכולות לגשת לקובץ מוגן.
• בקרת העלאות מדפדפן: ההגבלה שלה על העלאות לפי דומיין השירות חלה על העלאות שנעשות דרך Microsoft Edge, או דרך Chrome או Firefox כשמותקן בהם התוסף של Microsoft.

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

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

לעקוב אחרי ההתנהגות סביב ההעלאה

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

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

שני מקומות נוספים לבדוק:

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

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