חדשות סייבר יומיות - 24 באוגוסט 2026
CISA מורה על תיקון דחוף לפגיעות Zimbra שמנוצלת בפועל
קריטיתמה קרה
CISA הוסיפה פגיעות ב-Zimbra Collaboration Suite לקטלוג ה-Known Exploited Vulnerabilities (KEV) שלה, והורתה לסוכנויות הפדרליות האזרחיות בארה"ב להחיל תיקון תוך שלושה ימים.
הפגיעות CVE-2026-73570 (CVSS 8.9) היא בעיית הזרקת פקודות ברכיב ניטור ה-SNMP. כשחבילת zimbra-snmp האופציונלית מותקנת והתראות SNMP מופעלות, תוקף ללא הרשאות יכול לשלוח בקשות שנבנו במיוחד שמובילות להרצת קוד מרחוק (RCE) תחת משתמש ה-Zimbra, עקב סינון קלט לקוי.
Zimbra תיקנה את הפגיעות בגרסה 10.1.20 (יצאה ב-20 ביולי). CERT Polska דיווחה ראשונה על תקיפה ממוקדת פעילה, ו-Shadowserver זיהתה עקבות ניצול בלמעלה מ-270 סביבות.
מי מושפע
ארגונים שמריצים Zimbra Collaboration Suite (ZCS) בגרסאות שלפני 10.1.20, עם חבילת zimbra-snmp מותקנת והתראות SNMP מופעלות.
Shadowserver עוקבת אחרי למעלה מ-12,000 שרתי Zimbra שחשופים לאינטרנט. ZCS נמצאת בשימוש נרחב אצל ממשלות, עסקים וארגונים נוספים ברחבי העולם לדוא"ל ולשיתוף פעולה.
למה זה חשוב
הרצת קוד מרחוק ללא הזדהות על שרתי דוא"ל ושיתוף פעולה נותנת לתוקפים נתיב ישיר לתקשורת רגישה, לפרטי הזדהות ולרשתות פנימיות.
פגיעויות ב-Zimbra נוצלו שוב ושוב לגניבת מידע. השילוב של ניצול פעיל ואלפי סביבות חשופות לאינטרנט יוצר סיכון מיידי לחדירה רחבה, במיוחד בפריסות ממשלתיות וארגוניות שלא עודכנו.
איך אפשר היה למנוע את זה
עדכנו מיד ל-Zimbra Collaboration Suite 10.1.20 ומעלה.
אם התיקון מתעכב, השביתו את התראות ה-SNMP והסירו או הגבילו את חבילת zimbra-snmp. נטרו הפעלות מחדש בלתי צפויות של שירותי Zimbra וקבצים חדשים שנוצרו ב-/opt/zimbra/jetty/webapps/, ב-/opt/zimbra/jetty_base/webapps/ וב-/tmp/ בבעלות משתמש zimbra. תעדפו סביבות חשופות לאינטרנט והחילו בקרות רשת שמגבילות את חשיפת SNMP/SMTP.
מונחים מקצועיים רלוונטיים
- Remote code execution (RCE)
- פגיעות שמאפשרת לתוקף להריץ פקודות או תוכניות משלו על מערכת יעד דרך הרשת.
- Known Exploited Vulnerabilities (KEV) catalog
- הרשימה הסמכותית של CISA לפגיעויות שאושרו כנמצאות תחת תקיפה פעילה, ומפעילה מועדי יעד מחייבים לתיקון עבור סוכנויות פדרליות אזרחיות בארה"ב.
פגיעות קריטית באיפוס סיסמה ב-Keycloak מאפשרת השתלטות על חשבונות
קריטיתמה קרה
Red Hat ופרויקט Keycloak שחררו תיקונים לפגיעות אימות קריטית שמאפשרת לתוקף ללא הרשאות להשתלט על כל חשבון משתמש, כולל חשבונות מנהל, באמצעות כפיית איפוס סיסמה.
הפגיעות מזוהה כ-CVE-2026-18963 (CVSS 9.1) והיא אימות מצב לקוי בזרימת האימות reset-credentials (CWE-640). תוקף שולח בקשה שנבנתה במיוחד ל-endpoint של reset-credentials, והסשן קופץ ישירות לשלב עדכון הסיסמה בלי לדרוש את ה-action token הרגיל מהדוא"ל.
נכון למועד הגילוי לא דווחו ראיות לניצול בשטח ואין אקספלויט פומבי. הגרסאות המתוקנות כוללות את Keycloak upstream 26.7.2 ואת עדכוני Red Hat build of Keycloak 26.4.15 ו-26.6.6.
מי מושפע
פריסות של Keycloak upstream לפני גרסה 26.7.2, וגרסאות Red Hat build of Keycloak (RHBK) בזרמי 26.4 ו-26.6 שלפני הגרסאות המתוקנות שצוינו.
Keycloak הוא שרת ניהול זהויות וגישה (IAM) בקוד פתוח בשימוש נרחב, שמגן על האפליקציות והשירותים שמאחוריו. השתלטות מוצלחת על חשבונות מנהל עלולה להתרחב לכל מה שמסתמך עליו לאימות.
למה זה חשוב
השתלטות מלאה על חשבון בלי אינטראקציה מצד המשתמש ובלי פרטי הזדהות קודמים מערערת את אמון הליבה של פלטפורמת IAM. תוקפים ששולטים בזהויות Keycloak מקבלים גישה לאפליקציות המחוברות, לנתונים ולפונקציות ניהול.
מכיוון שהפגיעות לא דורשת הזדהות ועובדת נגד כל משתמש, רדיוס הפגיעה כולל חשבונות בעלי הרשאות גבוהות ויכול לאפשר תנועה רוחבית מהירה או חדירה מלאה לסביבה.
איך אפשר היה למנוע את זה
עדכנו מיד ל-Keycloak 26.7.2 (upstream) או לגרסאות המתוקנות המתאימות של Red Hat build of Keycloak (תמונות operator ו-container בגרסאות 26.4.15 / 26.6.6).
אם לא ניתן להחיל תיקון מיד, השביתו זמנית את פונקציית Forgot password כצעד מיטיגציה. סקרו את לוגי האימות לאיתור פעילות חריגה ב-reset-credentials, וודאו ש-MFA ובקרות סשן חזקות נאכפות על חשבונות קריטיים.
מונחים מקצועיים רלוונטיים
- Account takeover (ATO)
- מצב שבו תוקף מקבל שליטה מלאה על חשבון משתמש לגיטימי, בדרך כלל באמצעות איפוס או גניבת פרטי הזדהות.
- Authentication flow state validation
- הבדיקות בצד השרת שמוודאות שתהליך התחברות או שחזור רב-שלבי מתקדם רק כשהשלבים הקודמים הושלמו ואושרו כראוי.
UAT-10147: קבוצת תקיפה שמשתמשת ב-AI להרחבת תקיפות שרתים עם SPECTRE ו-rootkit ל-Linux
גבוההמה קרה
Cisco Talos תיארה קבוצת פשיעת סייבר דוברת סינית שמנוטרת כ-UAT-10147, שתוקפת שרתי web ב-Windows וב-Linux ברחבי העולם לצורך הונאות SEO וגניבת נתונים.
הקבוצה מנצלת בקנה מידה רחב פגיעויות שפורסמו בפומבי כדי להשיג גישה ראשונית, ואז פורסת שילוב של כלי קוד פתוח (Metasploit, ysoserial, PentestGPT, DeepAudit) ונוזקה מותאמת. היא נעזרת בכלי AI כדי לשפר אקספלויטים, לבצע אוטומציה של post-exploitation, לאמת payloads ולייצר תיעוד. בספרייה חשופה נמצאה רשימת יעדים של כ-170,000 כתובות URL.
ה-post-exploitation כולל web shells, BadIIS, Quasar RAT, Gh0stCringe, כלי הסלמת הרשאות, ו-implant חוצה פלטפורמות שלא דווח עליו בעבר בשם SPECTRE, שכולל יכולות EDR bypass, לצד rootkit ל-Linux לצורך persistence. אזורי הקורבנות העיקריים כוללים את ברזיל, בוליביה, סין, קנדה ווייטנאם, ומיקוד כבד נרשם גם כלפי ארה"ב, הודו, בריטניה, גרמניה והולנד.
מי מושפע
שרתי web ב-Windows וב-Linux החשופים לאינטרנט, במיוחד IIS וסביבות נפוצות אחרות, במגזרי החינוך, המדיה, הטכנולוגיה והגיימינג.
ארגונים עם פגיעויות ידועות שלא תוקנו או עם הקשחת שרתים חלשה חשופים. הקמפיין פועל ברחבי העולם עם ריכוז במספר מדינות באמריקות, באסיה ובאירופה.
למה זה חשוב
השילוב של סריקה המונית, ניצול פגיעויות ידועות, אוטומציה בסיוע AI ו-persistence רב-פלטפורמי (כולל rootkits ו-EDR bypass) מאפשר למפעיל רזה יחסית לפגוע במספר גדול של שרתים ביעילות.
שרתי web שנפרצו הופכים לפלטפורמות להונאות SEO, גניבת נתונים, הפצת נוזקה נוספת וגישה ארוכת טווח. מפתחים ומפעילים ניצבים בפני אובדן נתונים ישיר וגם בפני סיכון מוניטין או סיכון שרשרת אספקה במורד הזרם אם התשתית שלהם מנוצלת לרעה.
איך אפשר היה למנוע את זה
עדכנו בהקדם שרתי web ויישומים החשופים לאינטרנט; תעדפו פגיעויות RCE והסלמת הרשאות ידועות בעלות השפעה גבוהה. הגבילו או הסירו שירותים מיותרים והחילו קונפיגורציות בהרשאות מינימליות.
פרסו EDR/XDR עם זיהוי התנהגותי, נטרו משימות מתוזמנות חריגות (למשל שמות מטעים כמו "Google Chrome Start"), שימוש לרעה ב-certutil, web shells והחרגות Defender בלתי צפויות. בצעו סגמנטציה לשרתים, אכפו בקרות יוצאות חזקות וצודו אחר אינדיקטורים הקשורים ל-BadIIS, Quasar RAT, Gh0stCringe ו-implants בסגנון SPECTRE. בצעו רוטציה לפרטי הזדהות ובדקו הרשאות גישה אחרי כל חשד לחדירה.
מונחים מקצועיים רלוונטיים
- Web shell
- סקריפט זדוני קטן שמושתל על שרת web שנפרץ ומעניק לתוקף הרצת פקודות מרחוק דרך בקשות web רגילות.
- EDR bypass
- טכניקות שנוזקה משתמשת בהן כדי להתחמק מכלי endpoint detection and response או להשבית אותם, כך שפעילות זדונית לא תזוהה על ה-host.
Doubloon Dredger: גורם איום שמנצל את Notion לגניבת טוקני אימות
גבוההמה קרה
גורם איום בעל מניע כלכלי שמנוטר על ידי Sublime בשם Doubloon Dredger מנצל חשבונות Notion חינמיים, קובצי PDF זדוניים ופישינג מסוג device-code כדי לגנוב טוקני אימות של Microsoft.
התוקפים יוצרים פרסונות מנהלים מזויפות ב-Notion ושולחים התראות שיתוף מסמכים שנראות לגיטימיות ועוברות DKIM, SPF ו-DMARC. קורבנות שלוחצים מועברים דרך PDF מתווך שמכיל כפתור "Review and Sign", שמפנה לדף פישינג של EvilTokens המעוצב כאימות של Adobe Acrobat.
הדף מנפיק device code ומורה למשתמש להזין אותו בדף ההתחברות האמיתי של Microsoft, וכך התוקף משיג טוקן הרשאה וגישה לחשבון. EvilTokens, פלטפורמת phishing-as-a-service שפעילה לפחות מפברואר 2026, מספקת גם לקוח webmail בשם MailVault. בתשתית הקשורה זוהתה חפיפה עם פעילות Tycoon2FA.
מי מושפע
ארגונים שמשתמשיהם מקבלים התראות שיתוף של Notion ופועלים לפיהן, במיוחד במגזרי הייצור, התקשורת, הקמעונאות, הבריאות והלוגיסטיקה.
כל סביבת Microsoft 365 או Entra ID שעדיין מאפשרת אימות device-code חשופה. הקמפיין מסתמך על משתמשים שמשלימים את תהליך ה-device-code אחרי פיתויי הנדסה חברתית.
למה זה חשוב
פישינג מסוג device-code מניב טוקני סשן אמיתיים שיכולים לעקוף בקרות סיסמה ו-MFA מסורתיות רבות, ומעניק לתוקפים גישה ישירה לתיבות דואר ולמשאבי ענן.
ניצול ערוצי התראות SaaS מהימנים (Notion) לצד קובצי PDF בשכבות מעלה את שיעור המסירה ומפחית את חשד המשתמשים. גניבת טוקנים מאפשרת פריצת דוא"ל, הונאות business email compromise, הוצאת נתונים (exfiltration) ותנועה רוחבית נוספת בתוך סביבות Microsoft.
איך אפשר היה למנוע את זה
השביתו אימות device-code במקומות שבהם הצרכים העסקיים מאפשרים זאת, או הגבילו הנפקת טוקנים למכשירים מהימנים ולמדיניות conditional access.
הדריכו משתמשים להתייחס בזהירות להתראות שיתוף מסמכים או להנחיות "review and sign" בלתי צפויות, גם ממותגים מוכרים, ולאמת בקשות שיתוף בערוץ נפרד. נטרו הענקות device-code חריגות, הסכמות OAuth חריגות ושימוש בטוקנים ממיקומים בלתי צפויים. יישמו Phishing-resistant MFA ובדקו באופן שוטף הרשאות mail-flow ויישומי SaaS.
מונחים מקצועיים רלוונטיים
- Device code phishing
- טכניקת הנדסה חברתית שמרמה משתמש להזין קוד בדף התחברות לגיטימי, ובכך מעניקה לתוקף token אימות תקף.
- Phishing-as-a-service (PaaS)
- פלטפורמות פישינג מוכנות שנמכרות לעבריינים ומספקות אחסון, דפים, לכידת tokens ולעיתים קרובות גם גישה ל-webmail, כך שגורמים פחות מיומנים יכולים להריץ קמפיינים מתוחכמים.
חוקרים חשפו אלפי מפתחות AWS שדלפו
גבוההמה קרה
Truffle Security דיווחה שיותר מ-9,300 זוגות מפתחות גישה ל-AWS שדלפו, שאותרו בין אוגוסט 2022 לאוגוסט 2026, נותרו פעילים, כולל מאות עם הרשאות ניהול מלאות.
סורקים איתרו 64,024 זוגות מפתחות AWS ייחודיים במקורות ציבוריים כמו היסטוריית git, datasets של Hugging Face, תמונות Docker, registries של חבילות ולוגי CI. מתוך 10,616 זוגות פרטי הזדהות מלאים שעברו אימות חוזר, 88% עדיין הצליחו להתחבר. ביניהם היו 768 מפתחות ארגוניים עם הרשאות admin מלאות. המקור הבודד הגדול ביותר היה Hugging Face (8,482 מפתחות חיים ייחודיים ב-3,394 datasets ציבוריים), ורבים מהמפתחות היו בני שנים: גיל חציוני של כחמש שנים, וחלקם בני יותר מ-17 שנה. רק 13.7% מהמפתחות שניתן היה למנות עברו רוטציה.
החוקרים הודיעו לבעלים שניתן היה לזהות ולא פרסמו את חומר המפתחות. רק ב-9.5% מהחשבונות הוגדרו התראות תקציב.
מי מושפע
כל חשבון AWS שמפתחות הגישה שלו נשמרו ב-repositories ציבוריים, ב-datasets, בתמונות קונטיינר או בלוגים, ומעולם לא עברו רוטציה או בוטלו.
זה כולל חשבונות ארגוניים ואישיים; לאחד מכל שישה מפתחות שדלפו שנבדקו היו הרשאות root. ארגונים שמשבצים מפתחות ארוכי טווח בקוד, בצינורות CI או ב-artifacts משותפים נמצאים בסיכון מיוחד.
למה זה חשוב
מפתחות AWS פעילים, במיוחד כאלה עם הרשאות admin או root, מאפשרים השתלטות על חשבון: גניבה או מחיקה של נתונים, ניצול משאבים (כולל כריית מטבעות), התמדה ותנועה רוחבית לשירותים מחוברים.
מפתחות ארוכי טווח שמעולם לא עברו רוטציה ונשארים תקפים שנים הופכים דליפות היסטוריות לסיכון מתמשך. בלי התראות תקציב, ניצול יקר עלול לעבור מתחת לרדאר, וחשיפה ציבורית במגוון סוגי artifacts מגדילה את סיכויי הגילוי עבור תוקפים.
איך אפשר היה למנוע את זה
מחקו מיד מפתחות גישה מסוג root מכל חשבון (כולל חשבונות אישיים). בצעו מיפוי של מפתחות גישה ב-IAM עם "aws iam list-access-keys", אכפו מדיניות גיל מקסימלי, ובצעו רוטציה או בטלו כל מפתח שנחשף אי פעם.
התייחסו לכל סוד שנצפה בפומבי כאל סוד שנפרץ. הגדירו התראות תקציב ב-AWS (גם בספים נמוכים) כדי לזהות הוצאה בלתי צפויה כמו כריית מטבעות. העדיפו פרטי הזדהות קצרי טווח, תפקידי IAM ו-OIDC federation על פני מפתחות גישה ארוכי טווח. נטרו שיוך של מדיניות AWSCompromisedKeyQuarantine, שמעיד ש-AWS זיהתה חשיפה ציבורית. סרקו repositories, תמונות ו-datasets באופן רציף לאיתור סודות לפני שהם מגיעים לציבור.
מונחים מקצועיים רלוונטיים
- Access key
- זוג פרטי הזדהות ארוך טווח (Access Key ID ו-Secret Access Key) שתוכניות משתמשות בו לאימות מול APIs בענן.
- Secret scanning
- זיהוי אוטומטי של פרטי הזדהות, tokens ומפתחות בתוך קוד מקור, היסטוריית commits, קונטיינרים ו-artifacts אחרים, כדי למנוע חשיפה מקרית או להגיב לה.
פורסם על ידי סייבר בקצרה