Data Exfiltration

מהי הוצאת נתונים (exfiltration)?

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

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

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

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

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

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

הוצאת נתונים, דליפת מידע ופריצת מידע: מה ההבדל?

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

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

מהם שלבי הוצאת הנתונים?

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

ריכוז הוא השלב שמשאיר ראיות

MITRE עוקב אחרי ריכוז כטכניקה נפרדת, T1074 Data Staged: יריבים מרכזים נתונים שנאספו במיקום מרכזי לפני הוצאתם, מקומית או על מערכת מרוחקת שבשליטתם. זה משאיר ראיות כי העבודה מתבצעת על מכונות שלכם. ATT&CK מפרסם detection analytics בדיוק לזה, שמכסים ריכוז של קבצים רגישים בתיקיות זמניות או ציבוריות, דחיסה עם 7zip או WinRAR, או העתקה מרוכזת לפני הוצאת הנתונים.

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

המקרה המתועד הוא advisory משותף של CISA ו-FBI על Scattered Spider. כשהמטרה הייתה גניבת נתונים, השחקנים התקינו כלי extract, transform and load כדי להביא נתונים ממקורות מרובים למסד נתונים מרכזי אחד לפני ההוצאה, וזה תועד בטבלה של ה-advisory עצמו כ-Data Staged, T1074.

דחיסה והצפנה מגיעות קודם

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

איך מזהים הוצאת נתונים? ערוץ אחרי ערוץ

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

• ערוץ ה-C2 הקיים: טלמטריית endpoint, מחוברת לרשומות רשת.
• פרוטוקול חלופי, כולל DNS: לוגי DNS resolver.
• אחסון ענן ושירותי web: proxy, CASB ולוגי audit בענן.
• פלטפורמות SaaS: לוג ה-audit של הפלטפורמה עצמה, ובשום מקום אחר.
• דוא"ל, תחת T1114: לוגי audit של פלטפורמת הדואר.
• מדיה נתיקה תחת T1052, מדיה רשתית אחרת תחת T1011, ואיש הפנים: טלמטריית endpoint ו-DLP.

הערוץ שכבר פתוח

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

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

פרוטוקול שונה מערוץ ה-C2

הוצאת נתונים יכולה גם לרכב על פרוטוקול שאינו ערוץ ה-C2, ו-MITRE עוקב אחרי זה כ-T1048. DNS הוא המקרה המתועד ביותר: ATT&CK מתעד את נוזקת NightClub שמוסיפה נתונים לחלק ה-subdomain של בקשות DNS, ורשומות TXT, NULL ו-CNAME הן אלה שמנוצלות לרוב, כי הן מחזיקות טקסט שרירותי.

הניתוח של Kaspersky ל-ProjectSauron מראה את ה-tradeoff בשורה אחת: כלי הוצאת נתונים ב-DNS שרץ במכוון במצב bandwidth נמוך כדי להישאר מתחת לזיהוי tunnel גנרי, ולכן העביר רק metadata מערכתי. DNS tunneling הוא נושא גדול מספיק ששווה לקרוא עליו בנפרד.

ענן מאושר, שירותי web ו-SaaS

T1567.002 מכסה הוצאת נתונים לשירות אחסון ענן במקום לערוץ ה-C2 הראשי. היעדים ש-MITRE מציין כוללים את Dropbox, Google Drive, OneDrive, MEGA, Amazon S3 ו-Snowflake, עם רשומות procedure ל-Akira שמשתמשת ב-Rclone, ל-DUST של APT41 שמגיעה ל-OneDrive, ול-Storm-0501 שמשתמשת ב-Rclone וב-AzCopy. מוניטין היעד אינו בקרה שמישה כשהשירותים לגיטימיים.

גם הכלים שגרתיים באותה מידה. ReliaQuest מצאה את Rclone ב-57% מהתקריות שבדקה בין ספטמבר 2023 ליולי 2024, לפני WinSCP ו-cURL. קראו את זה ככלי שחזר והופיע בסט הנתונים ההוא, לא כשיעור נוכחי; שלושתם תוכנות שמנהלי מערכות מתקינים בכוונה.

ל-SaaS יש חתימה משלו. CISA ו-FBI מתעדים את Scattered Spider מאתרת גישת Snowflake של היעד ומריצה אלפי שאילתות מיד, ואז מוציאה נתונים לאתרים כולל MEGA ומרכזי נתונים בארה"ב. נפח השאילתות הוא האות שם, לא נפח התעבורה, והוא חי בלוג audit שאף חיישן רשת לא קורא.

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

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

• פיצול למקטעים (Chunking): תחת T1030, יריב עשוי להוציא נתונים במקטעים בגודל קבוע או להגביל גודלי packet מתחת לסף מסוים כדי לא להפעיל התראות סף על העברת נתונים ברשת. שימו לב לדיוק: זה מנטרל ספים, לא את כל ניתוח הנפח.
• קידוד בתוך ערוץ שכבר פתוח: אין חריגת נפח כשהסשן כבר היה נורמלי ל-host הזה, והתוכן נדחס והוצפן לפני שהועבר.
• יעדים שלגיטימיים מעצם התכנון (by design): העלאה גדולה לספק ענן שהעסק כבר משתמש בו לא נראית כמו הוצאת נתונים לאף בקרה שמבוססת על מוניטין.

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

מה הנתונים המדידים באמת אומרים

כאן מופיעים שני סוגי ראיות. סימולציית breach-and-attack מודדת מה בקרות עושות מול מתקפות מדומות שרצות בפרודקשן; תגובה לתקריות מודדת מה קרה בחדירות אמיתיות. לערבב ביניהם מייצר מספר שלא אומר כלום.

צד הסימולציה מספק את הנתון החד ביותר בעמוד. ב-Picus Blue Report 2026, ארגונים תיעדו בלוג 58% מהמתקפות המדומות אבל ייצרו התראות רק על 14% מהן, פחות מאחת משבע. הראיות נכתבות. הן לא מגיעות לפני השטח.

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

ציינו את מהדורת הדוח, בכל פעם

שני נתונים של Picus מסתובבים בנושא הזה, והם מגיעים מסטי נתונים שונים. תוצאות חיפוש מערבבות ביניהם.

מהדורת 2026 לא חוזרת על ה-3%. אם עמוד מצטט את שניהם בנשימה אחת, הוא מיזג שני מחקרים.

השעון שנגדו אתם באמת רצים

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

• ה-Global Threat Report 2026 של CrowdStrike מציב את זמן ה-breakout הממוצע ב-eCrime על 29 דקות ב-2025, והמהיר ביותר שנצפה הוא 27 שניות. Breakout הוא שעון התנועה הרוחבית, לא שעון הוצאת הנתונים.
• Unit 42 מדדה 72 דקות מגישה ראשונית עד הוצאת נתונים במקרים המהירים ביותר מתוך יותר מ-750 תקריות שנחקרו. מקרה מהיר ביותר, לא חציון.
• CrowdStrike מדווחת גם על חדירה אחת שבה הוצאת הנתונים התחילה בתוך ארבע דקות מהגישה הראשונית. אנקדוטה בודדת, ואסור לתכנן שום דבר סביבה כאילו היא טיפוסית.

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

כשגניבה היא כל המתקפה

המודל הישן ממקם הוצאת נתונים בתוך מתקפת כופרה, כשלב שלפני ההצפנה. CISA ו-FBI מתעדים את Scattered Spider מוציאה נתונים ומאיימת לפרסם אותם בלי לפרוס כופרה בכלל.

דוח DBIR 2026 של Verizon, שנבנה על נתוני תקריות ולא על טלמטריית מוצר של ספק, מתאר את אותו התנהגות: שחקנים "פשוט מסתמכים על סחיטה בלבד ולא מפעילים הצפנה של נתונים." Unit 42 מדדה ירידה של 15% משנה לשנה בסחיטה מבוססת הצפנה. כשהמנוף הוא העותק ולא הנעילה, שחזור מגיבוי לא מסיים את האירוע.

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

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

• המניעה לא שבורה. אותו סט נתונים של Blue Report 2026 מתעד גם התאוששות ביעילות המניעה ל-69% בסך הכול, השיא של 2024, מניעה ב-endpoint ב-83%, ומניעת הסלמת הרשאות שעולה ב-24 נקודות ל-79%, הרווח הגדול ביותר ברמת טקטיקה השנה. הכשל ספציפי לפעילות שקטה לאחר חדירה.
• נתון האחת-מתוך-עשר מודד חסימה, לא נראות. הוא אומר באיזו תדירות פעולות איסוף שקטות נעצרו, לא באיזו תדירות הן נראו. טיעון הריכוז כאן נשען על analytics מפורסמים בצד ה-host ועוד תנאי מוקדם של טלמטריה, וזה צר יותר מ"ריכוז נתפס."
• פיצול למקטעים מגביל ספים, לא ניתוח נפח. נפח נשאר אות. הוא פשוט מופעל אחרון.

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

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

שאלות נפוצות על הוצאת נתונים

מהו כלל 1-10-60, והאם הוא עדיין ה-benchmark? זה הניסוח הישן יותר של CrowdStrike: זיהוי בדקה, חקירה בעשר, הכלה בשישים. התייחסו אליו כיעד של ספק אחד, לא כתקן תעשייה. הדיווח הנוכחי של אותו ספק מוביל עם זמן breakout במקום, כך שהמדד שהמחקר שלו עצמו מדגיש כבר זז.

מהי הוצאת נתונים ב-AI? המקרה המתועד הוא EchoLeak, CVE-2025-32711, פגיעות zero-click ב-Microsoft 365 Copilot בדירוג CVSS 9.3 שמצאה Aim Security. Microsoft מתארת אותה כהזרקת פקודות AI שמאפשרת לתוקף לא מורשה לחשוף מידע דרך הרשת, עם נתונים שדולפים החוצה דרך כתובות URL של Teams ו-SharePoint ובלי אינטראקציה של משתמש. היא תוקנה בצד השרת ביוני 2025, בלי ניצול ידוע בשטח.

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

מה ללכת לבדוק

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

ארבעה מקומות, בסביבה שלכם:

1. קריאות קבצים מרוכזות ואחריהן כלי ארכוב שרץ על אותו host.
2. host אחד שקורא ממקורות רבים שהוא בדרך כלל לא נוגע בהם.
3. סשנים יוצאים מתהליכים שבדרך כלל לא מדברים עם הרשת.
4. לוגי audit בענן וב-SaaS, לפרצי שאילתות ולהורדות מרוכזות.

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

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

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