מדוע ארכיונים עם פענוח עצמי עדיין נחשבים לשיטת העברת תוכנות זדוניות מועדפת
תוקפים לא צריכים אפס ימים כאשר מפתחים עדיין פותחים קבצים שרירותיים מבלי להכניס אותם ל-sandbox. ארכיון המפענח את עצמו נותר אחת משיטות העברת התוכנות הזדוניות היעילות ביותר משום שהוא מנצל בדיוק את זה: אמון המפתחים בקוד פנימי, בתוצרי בנייה ובכלי צד שלישי.
שונה standard קבצי ZIP, ארכיון המפענח את עצמו, מבצע את תהליך הפריצה כתוכנית. טריק פשוט זה עוקף את רוב הסורקים הסטטיים והמבוססי חתימות, במיוחד כאשר הם מחופשים למתקין או עדכון לגיטימיים. לאחר ההפעלה, הארכיון יכול לפרוק סוסים טרויאניים, תוכנות ריגול או לוגר הקשות ישירות לחלקים רגישים של סביבת הפיתוח שלך.
למה תוקפים אוהבים פענוח עצמי של ארכיונים?
- הם מבצעים את עבודתם בשקט.
- הם אינם מסתמכים על אינטראקציה של המשתמש מעבר לביצוע הראשוני.
- הם מנצלים את אותם גבולות אמון שאתה מסתמך עליהם: סקריפטים פנימיים, CI/CD שלבים וכלי פיתוח.
לעתים קרובות תראו ארכיונים המפענחים את עצמם, המוטמעים בערכות SDK מזויפות, חבילות קוד פתוח שנפגעו, או אפילו כקבצים מצורפים סוררים הטוענים שהם אופטימיזצי בנייה או כלים פנימיים. ארכיונים אלה הם אחת משיטות העברת התוכנות הזדוניות העקשניות ביותר בטבע, מכיוון שהם משתלבים בזרימות עבודה יומיומיות של מפתחים. במקרים רבים, הם משמיעים בשקט רישום הקשות שמתעד הכל, החל מאישורים ועד פקודות רגישות, מבלי להפעיל התראות.
ממטען להתמדה: מה באמת קורה לאחר הביצוע
ברגע שארכיון המפענח את עצמו פועל, הוא לא רק משליך קובץ בינארי ונעלם. הוא קובר את עצמו במערכות על ידי ניצול מדיניות ביצוע או הרשאות משתמש שגויות. גישה פופולרית היא להחדיר לוגר הקשות מקשים או טרויאני אחורי לתהליכים באזור המשתמש או לסקריפטים של אתחול המערכת.
לדוגמה, SDA עשוי לפרוק טרויאן גישה מרחוק (RAT) שמתקין את עצמו כשירות או משנה .bashrc, .zshrc, או פרופילי PowerShell. ייתכן שהוא גם יתערב במשימות מתוזמנות או ישתמש בכלים מקוריים כמו משימות or השיקה לאתחל מחדש בעת אתחול מחדש.
מפתחי אינדיקטורים נפוצים של פשרה (IoCs) צריכים לשים לב אליהם:
- ביצוע בלתי צפוי של קבצי EXE או ELF באמצעות ממשק שורת פקודה (CLI) מ- / Tmp, % AppData%, או דומה.
- תעבורת רשת חריגה מיד לאחר הפעלת כלים לא ידועים.
- סקריפטי בנייה או בדיקה שונו עם שלבים חשודים לאחר הביצוע.
מטענים אלה ממשיכים להתקיים מעצם התכנון ורק לעתים רחוקות מסומנים על ידי EDR מסורתי בסביבות פיתוח, במיוחד כאשר הם מוסווים כתלות מפתח. ברגע שלוג הקשות פעיל, הוא יכול ללכוד בשקט הכל, החל מתעודות מפתח ועד סודות ייצור.
היכן מפתחים מתמודדים עם הסיכונים הגדולים ביותר ב CI/CD Pipelines
הנה המקום שבו הדברים נהיים מסוכנים באמת: CI/CD pipelines.
ארכיונים המפענחים את עצמם הופכים למסוכנים במיוחד כאשר הם פוגעים CI/CD כי הם משתלבים. הם יכולים להיות מוסווים כ:
- כלי SDK או ממשק שורת פקודה (CLI) שעברו קומפילציה מראש נבדקו במאגרים.
- תלויות בנייה שנמשכו ממקורות לא מאומתים.
- כלים פנימיים המשותפים דרך סלאק או דוא"ל, לאחר מכן commitאו בשימוש בתסריטים.
נקודות סיכון חמות
- בניית סוכני עיבוד: אם SDA מבוצע כאן, הוא יכול לשנות משתני סביבה, אישורים או אפילו להזריק אותו למשימות עוקבות.
- מטמוני תלותתוכנה זדונית ב-SDA שמגיעה למטמון שלך הופכת לסיכון בשרשרת האספקה. כל משימה שמושכת מהמטמון הנגוע יורשת את המטען.
- מאגרי חפציםאם מורעלים ב-SDAs, הם משמשים כשיטות להפצת תוכנות זדוניות המגיעות לסביבות במורד הזרם, כולל staging וייצור.
CI/CD הוא מהיר ואוטומטי. משמעות הדבר היא שארכיון אחד המפענח את עצמו יכול לזרום בשקט דרך סביבות מרובות לפני שמישהו ישים לב. גרוע מכך, אם המטען כולל לוגר הקשות מקשים, הוא יכול leak secretנעשה שימוש בשלבים שונים מבלי להתגלות אי פעם.
חסימת ביצוע שקט באמצעות בקרות DevSecOps
מניעת ביצוע של ארכיונים המפענחים את עצמם אינה מסובכת, אך היא דורשת שינוי בברירות המחדל.
בקרות שעובדות וממוקדות במפתחים:
- השבתת מדיניות ביצוע מסוכנת: חסימה של היכולת להריץ קבצים ניתנים להרצה מנתיבים זמניים או לא ידועים. משמעות הדבר היא הגדרת מדיניות ביצוע קבצים מתאימה בסוכני בנייה.
- אכיפת אימות ארטיפקט: השתמשו בסכומי בדיקה קריפטוגרפיים או בחתימה בכל הכלים הפנימיים, ערכות ה-SDK והקבצים הבינאריים. אימות כל ארטיפקט לפני שהוא נוגע ב... pipeline.
- קבצי בינארי של Sandbox firstrun: במיוחד עבור כלים שהורדו או נוספו לאחרונה. השתמשו במכונות וירטואליות מבודדות למטרה זו.
- צג pipeline התנהגות: סמן והתראה על התנהגות ביצוע חריגה כמו תעבורה יוצאת לאחר בנייה, או תהליכי ממשק שורת פקודה (CRI) שלא הוגדרו במערכת שלך pipeline תצורה.
חזק תנוחת DevSecOps מניח שכל כלי יכול להיפגע. אם שלך CI/CD לא יכול לזהות ארכיון מפענח עצמי שחומק דרכו, הוא יפספס הרבה יותר גרוע. שיטות העברת תוכנות זדוניות מתפתחות, אך הרצת קבצים בינאריים סוררים בסביבות בנייה נותרה סיכון מרכזי. לשלב גילוי עם מניעה.
מעבר לגילוי: כיצד Xygeni מסייעת לעקוב אחר נתיבי משלוח של תוכנות זדוניות
גילוי לוגר הקשות מקלדת לאחר מעשה מאוחר מדי. זה המקום שבו כלים כמו קסיגני עניין.
Xygeni מספק תובנות בזמן אמת לגבי מה שמבוצע במערכת שלך pipeline, בין אם מדובר בארכיון המפענח את עצמו או בקובץ בינארי סורר שמתחזה לעוזר בנייה. כוחו טמון ב:
- מיפוי האופן שבו שיטות העברת תוכנות זדוניות עוברות pipelines.
- מעקב אחר מקורם של ארכיונים זדוניים המפענחים את עצמם.
- חסימת ביצוע על סמך אינדיקטורים התנהגותיים, לא רק חתימות.
בעזרת Xygeni, ניתן לקשר אירועים כמו: "artifact unusual in build job #42" → "CLI executed unexpected binary" → "keystroke logger beacon detected on pointpoint".
עקיבות זו היא קריטית כשאתם מנסים לאבטח CI/CD זרימות עבודה נגד שיטות נסתרות להפצת תוכנות זדוניות.
קו ההגנה האחרון: עצרו את פענוח הארכיונים העצמי לפני שהם יפוצצו אתכם Pipeline
פענוח עצמי של ארכיונים אינו רק טריק ישן. הם נותרים אחת משיטות ההפצה המסוכנות ביותר והלא מזוהות כראוי, המכוונות למפתחים ו... pipelines.
אם אתה מפתח שכותב או מאבטח קוד, עליך:
- התייחס לכל קובץ בינארי כלא מהימן, אפילו בתוך שלך pipeline.
- אכוף אימות ו-sandbox עבור כל הארכיטקטים של צד שלישי.
- צג pipeline התנהגות כאילו הייתה תעבורת ייצור.
וחשוב מכל, שקלו כלים כמו Xygeni שהם מעבר לסריקה, כלים שעוקבים, מתחקים וחוסמים ארכיונים זדוניים המפענחים את עצמם לפני שהם משגרים לוגר הקשות מקלדת למערכת שלכם. CI/CD ערימה. הזז שמאלה, אבל סרוק עמוק יותר. ולעולם אל תמעיט בערכו של ארכיון קטן שיכול להכניס סיכון משמעותי באמצעות שיטות שקטות להפצת תוכנות זדוניות.
