DNS Tunneling

טכניקת DNS tunneling מסתירה נתונים אחרים בתוך חיפושים ותשובות רגילים של Domain Name System (DNS). כך הנתונים האחרים יכולים לעבור בתוך תעבורת DNS מותרת, כשאמצעי בקרה לא מזהים או מגבילים אותם. בודקי אבטחה משתמשים בה, ותוקפים משתמשים בה כדי לשלוח פקודות למכשיר שנפרץ, או כדי להוציא נתונים גנובים מתוך רשת.

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

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

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

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

מה קורה בחיפוש DNS רגיל?

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

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

איך DNS tunneling עובדת?

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

מה התוקף צריך

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

שליטה היא התנאי, לא בעלות על דומיין רשום. DNS מאפשר לבעל דומיין להעביר אחריות על חלק ממנו, כגון תת-דומיין, לשרתים אחרים. RFC 9499 קורא לכך האצלה (delegation), ולכן מפעיל ששולט בתת-דומיין שהואצל לו עומד באותו תנאי. זה המבנה הנפוץ, ולא רשימת תנאים מחייבת לכל מימוש.

איך הנתונים יוצאים

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

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

איך ההוראות חוזרות

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

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

למה DNS tunneling יכולה לעבור ברשת?

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

• תעבורת DNS נפוצה, ויכולה להיות מותרת מוקדם: השימוש ב-DNS יכול להיות נפוץ מאוד ברשת, והתעבורה שלו יכולה להיות מותרת אפילו לפני שהמכשיר סיים להזדהות.
• המסלול הוא המסלול הרגיל: חיפוש שעובר במנהרה עובר באותו מסלול שעובר כל חיפוש אחר - מהמכשיר אל ה-resolver שלו, ומשם והלאה אל השרת שעונה בשם הדומיין.
• שמות יכולים להכיל כמעט כל דבר: יש מעט מאוד הגבלות על מה שיכולה בקשת DNS להכיל, ולמנות ה-DNS יש הרבה שדות וכותרות שבהם אפשר להסתיר נתונים.
• לוגים מוגבלים יכולים להסתיר את המטרה: הרבה לוגים של DNS מתעדים שמות דומיין ולא את תוכן התשובות, כך שקשה לראות מה היה בתשובות עצמן. עם זאת, זה לא אומר שלוגי השאילתות לא יעילים, כי השם המלא שנשלח בכל שאילתה יכול להראות תת-דומיינים מקודדים ודפוסים חשודים. Palo Alto Networks מזהירה שבלי נראות לסוגי רשומות כמו TXT, או לשאילתות תת-דומיין ארוכות באופן חריג, מנהרות נשארות לעיתים קרובות בלתי נראות.

למה DNS tunneling משמשת?

שליטה ובקרה

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

תיארה Infoblox מקרה שבו אותו עיקרון פעל באתרים נגועים ולא בתחנות עבודה. האתרים הנגועים עצמם, לא הדפדפנים של מי שגלש בהם, שלחו חיפושי DNS לשרתים שבשליטת התוקף, והתשובות אמרו לכל אתר מה לעשות. לרוב התשובה הייתה לא לעשות כלום ולהציג את האתר כרגיל. Infoblox משערת שהתוקף מגביל הפניות, בין היתר כדי להימנע מזיהוי. מיוני 2025, חלק מהתשובות הנחו אתרים נגועים להוריד תוכן משרתי C2 של נוזקת Strela Stealer. Infoblox אומרת שהיא עוקבת אחרי התוקף מאז אוגוסט 2023, ושפרסמה את הדוח הזה ב-30 בספטמבר 2025.

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

העברת נתונים אל מחוץ לרשת

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

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

שימושים לגיטימיים

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

במה DNS tunneling שונה מ-C2, מהוצאת נתונים ומניצולי DNS אחרים?

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

• שליטה ובקרה: המטרה היא לשלוט במכשירים שנפרצו, ו-DNS tunneling היא דרך אחת להעביר את התעבורה הזו.
• הוצאת נתונים: המטרה היא להוציא נתונים, ו-DNS tunneling היא מסלול אחד לכך. בטכניקת Exfiltration Over Web Service הנתונים עוברים לשירות אונליין לגיטימי במקום זאת, ואילו ב-DNS tunneling הם עוברים לשרת שהתוקף מפעיל.
• טכניקת Protocol tunneling: הרעיון הכללי הוא עטיפה של תעבורה של פרוטוקול אחד בתוך פרוטוקול אחר, ו-MITRE מסמנת אותה כ-T1572. MITRE מסמנת שליטה ובקרה שמבוססת על DNS כ-T1071.004. מיפוי הוצאת הנתונים תלוי בערוץ, כפי שהוסבר למעלה, בחלק שעוסק בהוצאת נתונים.
• השימוש ב-DNS לאיתור שרת: טכניקות כמו אלגוריתמים ליצירת דומיינים ו-fast flux משנות את השמות או הכתובות שאליהם פונה הנוזקה, כך שהיא יכולה להגיע לשרת שלה. אף אחת מהשתיים אינה DNS tunneling כשלעצמה, כי אף אחת מהן לא מעבירה נתונים אחרים בתוך הודעות ה-DNS. אבל שתיהן יכולות להופיע לצד DNS tunneling וטכניקות אחרות באותו קמפיין.

ה-DNS שמוצפן הוא שכבה אחרת

שתי דרכים לשלוח הודעות DNS בתוך חיבורים מוצפנים הן DNS over HTTPS (DoH) ו-DNS over TLS (DoT). הן נוגעות לאופן שבו ההודעות עוברות. DNS tunneling נוגעת לנתונים שמועברים בתוך ההודעות, לכן מנהרה יכולה להשתמש בכל אחת מהדרכים האלה. Unit 42 מתארת כלי שמפעיל מנהרת DNS ויכול להשתמש ב-DoH וב-DoT כדי לספק פרטיות ולהתחמק מזיהוי.

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

איך מגינים מאתרים את DNS tunneling ומגבילים אותה?

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

נתבו את החיפושים דרך resolver שבשליטתכם

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

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

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

שירותי DNS מוצפן מאושרים נשארים מותרים. Palo Alto Networks נותנת את אותה עצה לגבי DoH: התירו רק resolvers שאתם מנהלים או מפקחים עליהם.

המגבלה היא המכשירים שעוקפים את הדרישה הזו, וגם הנראות שאובדת כש-DNS מוצפן. CISA מזהירה שהצפנת DNS יכולה להכביד על כלי רשת שתלויים ביכולת לראות DNS לא מוצפן. לכן היא מבקשת מהסוכנויות נראות דומה ממקורות מבוססי נקודות קצה. Palo Alto Networks מוסיפה שמכשירים ששולחים DoH יכולים לעקוף אמצעי הגנה ארגוניים.

סרבו לתרגם לכתובת דומיינים ידועים כזדוניים

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

המגבלה היא במילה "ידוע". דומיין שעדיין לא זוהה כזדוני לא מכוסה. Infoblox מדווחת שבמקרה מ-2025 שתואר למעלה, קרן Shadowserver ביצעה sinkhole לדומיין ה-C2 של התוקף, כך שהשאילתות של האתרים הנגועים הגיעו אל הקרן במקום זאת. לדבריה, התוקף הקים דומיין C2 חדש בתוך שעות.

הסתכלו על דפוס החיפושים

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

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

לשיטת הזיהוי הזו יש שלוש מגבלות:

• כל אות יכול להיות תמים: לכל אחד מהאותות יכולה להיות סיבה תמימה. Palo Alto Networks אומרת שחלק מהפעילות שנראית כמו DNS tunneling מגיעה משירותים לגיטימיים כמו שירותי VPN לצרכנים.
• מנהרה יכולה להיות איטית: beaconing, הבדיקה החזרתית והקבועה שמכשיר שולח לשרת שלו, יכולה להיות קשה לאיתור כשהיא מתרחשת לעתים נדירות, כי זה מסתיר אותה בתוך תעבורת DNS רגילה.
• תוקפים יכולים לתכנן פעילות שעוקפת אות המבוסס על נפח: Kaspersky דיווחה על התוסף להוצאת נתונים על גבי DNS של ערכת הכלים ProjectSauron, שנחשפה בשנת 2016. לדברי Kaspersky, התוסף פעל במצב רוחב פס נמוך כדי להימנע מזיהוי רשתי גנרי של מנהרות DNS.