Cyber & Code
624 subscribers
6 photos
14 videos
22 files
148 links
הודעה חשובה!!!
⚠️ כללי אצבע ואזהרות
 
1. 🛡 שימוש חוקי בלבד: כל פוסט/קוד שנעלה פה הוא רק לשימוש חוקי/למטרות למידה בלבד אם תשתמשו בזה בשביל דברים זדוניים זו אשמתכם!
 
2. 🕵️‍♂️ מטרות לגיטימיות: השתמשו בטכניקות אלה לצורך מחקר, לימוד או שיפור אבטחה בלבד. 
Download Telegram
☣️ אנטומיה של נוזקה (חלק 3): ניתוח דינאמי ☣️
בפוסט הקודם (חלק 2) עשינו ניתוח סטטי. בחנו את ה"שרטוטים" של הנוזקה 📜, הסתכלנו על המחרוזות (strings) ועל טבלת הייבוא (Imports) כדי לנחש מה היא מתכננת לעשות.
אבל מה קורה כשהתוקף חכם? 🧠 מה קורה כשהקובץ "דחוס" (Packed) או "מעורפל" (Obfuscated)? הניתוח הסטטי יראה לנו ג'יבריש. הקובץ נראה תמים, כי הקוד הזדוני האמיתי חבוי ומוצפן בתוכו.
כדי לנצח את זה, אנחנו חייבים לתת לנוזקה לרוץ. אנחנו חייבים לתת לה "לפתוח" את עצמה ולחשוף את כוונותיה האמיתיות. ברוכים הבאים לעולם ה-ניתוח הדינאמי (Dynamic Analysis).

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

🏗️ אבן היסוד: ארגז החול (Sandbox)
איך מריצים וירוס בלי להדביק את המחשב שלנו? התשובה היא Sandbox.
וירטואליזציה (VM): אנחנו משתמשים בתוכנה כמו VirtualBox (חינמית) או VMware כדי ליצור "מחשב בתוך מחשב". המחשב הווירטואלי הזה (ה"אורח") מבודד לחלוטין מהמחשב האמיתי שלנו (ה"מארח").

בידוד רשת: 🌐 זו נקודה קריטית! אנחנו לא רוצים שהנוזקה תצא מה-VM ותתקוף מכשירים אחרים ברשת שלנו. לכן, מגדירים את הרשת של ה-VM למצב "Host-Only" (שיראה רק את המחשב המארח) או משתמשים ב-VLAN מבודד. אפשר גם להשתמש בכלים שמדמים חיבור אינטרנט מזויף (כמו INetSim).

תמונת מצב (Snapshot): 📸 השלב החשוב ביותר! לפני שאנחנו מפעילים את הנוזקה, אנחנו לוקחים "תמונת מצב" (Snapshot) של המערכת הווירטואלית. זה כמו "שמירת משחק".

הפעלה (Detonation): 💥 מריצים את הקובץ החשוד! נותנים לו לעשות את הנזק שלו.
שחזור: 🔄 אחרי שסיימנו לאסוף נתונים, אנחנו פשוט "משחזרים" את ה-Snapshot, והמערכת חוזרת למצב הנקי והבתולי שלה תוך שניות, כאילו כלום לא קרה.

🕵️‍♂️ מה אנחנו מחפשים?
בזמן שהנוזקה רצה, אנחנו מנטרים 4 דברים עיקריים:
שינויים במערכת הקבצים: האם נוצרו קבצים חדשים? נמחקו קבצים? שונו שמות של קבצים? (רמז לכופרה).
שינויים ברישום (Registry): האם נוצרו מפתחות חדשים? במיוחד מפתחות שקשורים ל-Persistence (הפעלה אוטומטית עם המחשב).
פעילות תהליכים (Process): האם הנוזקה הריצה תהליכים חדשים? האם היא "הזריקה" (injected) קוד לתוך תהליך לגיטימי (כמו svchost.exe) כדי להסתתר?
פעילות רשת (Network): 🌍 זה הגביע הקדוש. לאן היא מנסה להתחבר? האם היא עושה שאילתות DNS? האם היא שולחת מידע לכתובת IP חשודה?

🛠️ פרקטיקה: הכלים של המנתח הדינאמי
אז המעבדה שלנו (ה-VM) מוכנה. הפעלנו את הנוזקה. איך אנחנו "צופים" בה? אנחנו מפעילים את כלי הניטור לפני הרצת הנוזקה.
י1. Process Monitor (ProcMon)
זהו הכלי החשוב ביותר לניטור על המחשב המארח (Host). הוא שייך לחבילת Sysinternals האגדית של מיקרוסופט.
מה הוא עושה? ProcMon רושם כל פעולה שמתבצעת במערכת, ברמת ה-Kernel. הוא מציג לוג מפורט של כל גישה לקובץ, כל קריאה/כתיבה לרישום, וכל יצירת תהליך.
איך משתמשים בו?
מפעילים את ProcMon.
מגדירים פילטר (Filter) שיראה לנו רק פעולות של הנוזקה (לפי שם הקובץ שלה, למשל suspicious.exe).
מריצים את הנוזקה (suspicious.exe).
צופים בלוג בזמן אמת. 🌊 זה ייצר אלפי שורות לוג, אבל שם נמצא המידע
.
מה נחפש בלוג?
יRegSetValue לנתיב ...CurrentVersion\Run ⬅️ זיהינו ניסיון התמדה (Persistence)!
יCreateFile בנתיב C:\Users\Admin\AppData\Local\Temp\evil.dll ⬅️ זיהינו שהנוזקה "מטילה" (Dropping) קובץ נוסף!
יProcess Create לתהליך vssadmin.exe delete shadows /all ⬅️ פעולת כופרה קלאסית! מחיקת גיבויי צל (Shadow Copies) כדי למנוע שחזור.
תהליך explorer.exe (שתמיד רץ) פתאום מבצע CreateFile לקובץ מוזר ⬅️ רמז להזרקת קוד (Process Injection)!

י2. Wireshark
זהו הכלי החשוב ביותר לניטור פעילות הרשת.
מה הוא עושה? Wireshark הוא "רחרחן" (Sniffer) רשת. הוא לוכד ומציג כל פאקט (Packet) בודד שנכנס ויוצא מכרטיס הרשת של ה-VM.
איך משתמשים בו?
מפעילים את Wireshark ב-VM (או במחשב המארח, תלוי איך הגדרנו את הרשת).
בוחרים את כרטיס הרשת ולוחצים "Start".
מריצים את הנוזקה.
עוצרים את הלכידה ומנתחים.
מה נחפש בלכידה?
שאילתות DNS: 🗣️ הדבר הראשון שהנוזקה תעשה זה לנסות למצוא את "הבית" שלה. נחפש שאילתות לדומיינים מוזרים (למשל asj29fkd91.ru או updates.microsoft.security.com שימו לב לטעות!). זהו מחוון פריצה (IOC) קריטי כתובת הC2 (Command & Control).
4🔥4
תקשורת IP ישירה: 📞 חיבורים ישירים לכתובות IP חשודות, במיוחד בפורטים לא סטנדרטיים (כמו 4444, 6666, או 8080).
פרוטוקולים חשודים: האם היא משתמשת ב-IRC? ב-FTP? האם היא שולחת מידע ב-HTTP POST (שעלול להכיל מידע שנגנב, אולי בקידוד Base64)?
"ביקון" (Beaconing): 🛰️ האם אנחנו רואים פאקט קטן שנשלח לאותו IP כל 5 דקות בדיוק? זהו "ביקון" – הנוזקה מדווחת לשרת ה-C2 שהיא "בחיים" ומחכה לפקודות.

⛔️ המגבלה: נוזקות מודעות-סביבה (Sandbox-Aware)
תוקפים יודעים שאנחנו עושים את זה. לכן, נוזקות מתוחכמות ינסו לזהות שהן רצות בתוך VM.
איך? הן יחפשו קבצים של VMware (vmtoolsd.exe), יבדקו כתובות MAC של כרטיסי רשת וירטואליים, או יבדקו אם יש רק מעבד אחד ומעט זיכרון RAM (סימן ל-VM).
מה הן עושות? אם הן מזהות VM, הן פשוט... לא עושות כלום. 🚫 הן ייכבו, או ירוצו כתהליך תמים, כדי לגרום לאנליסט לחשוב שהקובץ נקי.

📝 סיכום ביניים:
ניתוח דינאמי הוא קפיצת מדרגה. הרצנו את הפצצה 💣, שרדנו כדי לספר, ויש לנו אוצר של מידע: כתובות IP לחסום בפיירוול, קבצים חדשים לחקור, ומפתחות רישום למחוק.
אבל מה קורה כשהנוזקה מתוחכמת מדי? מה אם היא מזהה את ה-Sandbox? מה אם אנחנו רוצים להבין את הלוגיקה הפנימית שלה ברמת הקוד?
כאן, גם הניתוח הדינאמי לא מספיק. אנחנו צריכים לפתוח את מכסה המנוע ולהסתכל . אנחנו צריכים... לקרוא אסמבלי.

בפוסט הבא בסדרה (חלק 4): 🤯 מבוא ל-Reverse Engineering – הצצה ראשונה לעולם המורכב של פירוק קבצים בינאריים עם כלים כמו Ghidra.
שאלות? הארות? ספרו לי בתגובות! 👇
הצטרפו לערוץ @CYBERSECURITYCODING
6🔥3
☣️ אנטומיה של נוזקה (חלק 4): מבוא ל-Reverse Engineering קריאת שפת מכונה ☣️
בפוסטים הקודמים בסדרה:
הכרנו את האויבים (וירוס, תולעת וכו').
עשינו ניתוח סטטי (קראנו מחרוזות ו-Imports בלי להריץ).
עשינו ניתוח דינאמי (הפעלנו את הנוזקה ב-Sandbox וצפינו בה).
אבל מה קורה כשהניתוח הדינאמי נכשל? מה אם הנוזקה מזהה את ה-Sandbox ופשוט... נכבית? מה אם אנחנו חייבים להבין את הלוגיקה הפנימית שלה? למשל, איך עובד אלגוריתם ההצפנה של הכופרה (אולי יש בו פגם?) או איך בדיוק היא יוצרת קשר עם שרת ה-C2 שלה?
כאן אנחנו נכנסים לתחום העמוק והמאיים ביותר: הנדסה הפוכה (Reverse Engineering - RE).

📖 רקע תיאורטי: מה זה בכלל RE?
הנדסה הפוכה היא תהליך של פירוק תוכנה גמורה (קובץ בינארי, .exe) כדי להבין את המבנה, העיצוב והלוגיקה שלה בלי לקבל גישה לקוד המקור המקורי (קוד ה-C++ או ה-Python שהמפתח כתב).
האנלוגיה הפשוטה: דמיינו שאתם מקבלים עוגה. אין לכם את המתכון. המשימה שלכם היא לטעום אותה, להריח, לפרק אותה שכבה אחר שכבה, ולנסות לשחזר את המתכון המדויק ואת טכניקת האפייה. זה RE.
🧠 למה זה כל כך קשה?
כשמתכנת כותב קוד, הוא משתמש בשפה "עילית" (כמו C++, Python, C#). כשהוא מוכן, הוא מקמפל (Compile) את הקוד. הקומפיילר הופך את הקוד הפשוט והקריא (כמו int age = 30;) לסדרה ארוכה ומסובכת של הוראות שהמעבד (CPU) מבין.
ההוראות האלו נקראות קוד מכונה (Machine Code) – רצפים של 0 ו-1.
שפת סף (Assembly):
כדי שבני אדם יוכלו איכשהו לקרוא קוד מכונה, יצרו את Assembly. זוהי ייצוג טקסטואלי, אחד-לאחד כמעט, של קוד המכונה. זה נראה ככה:
יMOV EAX, 0x5 (תרגום: "הכנס את המספר 5 לתוך אוגר (Register) בשם EAX").
זה עדיין קשה מאוד לקריאה!

🔧 מפרקים (Disassemblers) ומפענחים (Decompilers)
כאן נכנסים הכלים הכבדים:
מפרק (Disassembler): כלי שלוקח את קוד המכונה (010101) והופך אותו בחזרה ל-Assembly (MOV EAX, 0x5). זהו תרגום מדויק.
מפענח (Decompiler): כלי שלוקח את ה-Assembly ומנסה לשחזר ממנו קוד "עילי" (כמו C). התוצאה היא לא הקוד המקורי, אלא "פסאודו-קוד" (Pseudo-code), אבל היא קריאה וברורה פי מיליון יותר מאסמבלי.
המטרה שלנו: אנחנו לא מנסים לשחזר את התוכנה. אנחנו מנסים להבין את הלוגיקה שלה. למצוא את הפונקציה שגונבת סיסמאות, את הפונקציה שיוצרת קשר עם התוקף, ואת הפונקציה שמצפינה קבצים.

🛠️ פרקטיקה: הכירו את Ghidra
עד לפני כמה שנים, הכלי הסטנדרטי בתעשייה היה IDA Pro כלי מדהים שעולה אלפי דולרים. ואז, ב-2019, ה-NSA (כן, הסוכנות לביטחון לאומי של ארה"ב) פשוט שחררה את הכלי הפנימי שלה בחינם לציבור: Ghidra.
יGhidra היא חבילת RE מפלצתית, והדבר החשוב ביותר בה: יש לה Decompiler פנטסטי ומובנה.

יworkflow בסיסי של אנליסט עם Ghidra:
נניח שטענו את ה-suspicious.exe שלנו לתוך Ghidra.
ניתוח אוטומטי: Ghidra תרוץ על הקובץ במשך כמה דקות ותנתח אותו אוטומטית. היא תזהה פונקציות, תבנה גרפים ותנסה להבין את המבנה.
חיפוש ה-main: בדיוק כמו בתכנות, כל תוכנה צריכה להתחיל איפשהו. אנחנו מחפשים את הפונקציה הראשית (לרוב main או WinMain).
הצצה ל-Decompiler: אנחנו לוחצים על הפונקציה main ובחלון ה-Decompiler מימין, במקום אסמבלי מפחיד, אנחנו רואים משהו שנראה כמו קוד C:

void main(void) {
int local_10;
local_10 = FUN_00401234("config.dat");

if (local_10 == 0{
FUN_00405678("Failed to load config!");
} else
{ FUN_00409ABC(local_10);
}
}


פענוח הלוגיקה: אנחנו עדיין לא יודעים מה הפונקציות האלה עושות, אבל אנחנו מבינים את הזרימה. התוכנה מנסה לטעון קובץ בשם config.dat. אם היא מצליחה, היא קוראת לפונקציה FUN_00409ABC. אם היא נכשלת, היא קוראת לפונקציה FUN_00405678.
"לחפור" פנימה (Pivoting):
אנחנו חושדים ש-FUN_00401234 היא פונקציית "טעינת קובץ". נלחץ עליה.
יGhidra קופצת לפונקציה החדשה. אנחנו מסתכלים ב-Decompiler שלה ורואים שהיא קוראת לפונקציות Windows מוכרות כמו CreateFileA ו-ReadFile. אישרנו!
העבודה האמיתית מתחילה: אנחנו חוזרים ל-main ומשנים את שם הפונקציה (Right Click -> Rename Label) מ-FUN_00401234 לשם משמעותי כמו load_config_file.
חוזר חלילה: אנחנו חוזרים על התהליך. נכנסים ל-FUN_00409ABC (שאותה נשנה ל-process_config_data). אנחנו עשויים לגלות שבתוכה מסתתרת פונקציה נוספת שקוראת ל-socket ו-connect. אנחנו נשנה את שמה ל-connect_to_C2.
התוצאה הסופית: אחרי שעות (או ימים!) של עבודה, הקוד המפחיד והלא ברור הופך למשהו עם שמות פונקציות ומשתנים הגיוניים, שחושף את הלוגיקה המלאה של הנוזקה.
7🔥3
☠️ מה התוקף עושה? (Anti-Reversing)
תוקפים שונאים RE. הם משתמשים בטכניקות Anti-RE כדי להקשות עלינו:
יAnti-Disassembly: הוספת קוד "זבל" שגורם ל-Ghidra להציג אסמבלי שגוי.
יAnti-Debugging/VM: קוד שבודק אם הוא רץ בתוך VM או אם Ghidra מחובר אליו, ואם כן – משנה את ההתנהגות שלו.
עירפול (Obfuscation) כבד: הפיכת קוד פשוט (a = b + c) למפלצת מתמטית של 50 שורות שעושה אותו הדבר, רק כדי לבלבל את ה-Decompiler.

📝 סיכום הסדרה:
וזהו! 🏁 סיימנו את סדרת "אנטומיה של נוזקה".
התחלנו ברמה הגבוהה ביותר (סוגי נוזקות), עברנו לניתוח סטטי (בדיקה שטחית), המשכנו לניתוח דינאמי (צפייה בהתנהגות), וסיימנו ברמה הנמוכה והעמוקה ביותר הנדסה הפוכה (קריאת המוח של הנוזקה).
יRE הוא לא קסם, זו עבודת נמלים קשה וסיזיפית. זה כמו לפתור פאזל של 10,000 חלקים בלי לדעת מה התמונה הסופית. אבל כלים כמו Ghidra הפכו את התחום הזה לנגיש מתמיד.
מקווה שהסדרה הזו פתחה לכם את הראש והראתה לכם את העומק המדהים של תחום הסייבר.
מה הלאה? רוצים שנדבר על כלי תקיפה ספציפיים? אולי על פרוטוקולי רשת? ספרו לי בתגובות! 👇
הצטרפו לערוץ @CYBERSECURITYCODING
9
🕵️‍♂️ חלק 1: OpSec - תורת הלחימה של הדיגיטל 🕵️‍♂️
כולנו אוהבים לדבר על הכלים הנוצצים: האקספלויט החדש, הסקריפט המתוחכם, או הפקודה שמשיגה גישה. אבל בתחום הסייבר, יש אמת אחת שגדולה יותר מכל כלי טכני: לא משנה כמה אתה מוכשר, אם תשאיר עקבות, יתפסו אותך.
היום אנחנו מתחילים סדרה בת שני חלקים על הנושא הקריטי ביותר בעולם התקיפה וההגנה: OpSec (Operations Security), או בעברית: אבטחת מבצעים.
לפני שנצלול לעומק, חשוב לי להדגיש.

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

🧠 רקע תיאורטי: מה זה OpSec?
יOpSec הוא לא כלי או תוכנה; זוהי תפיסת עולם ותהליך חשיבה שיטתי שפותח במקור בצבא ארה"ב במהלך מלחמת וייטנאם. הצבא האמריקאי הבין שהאויב מצליח לצפות את צעדיהם לא בגלל מרגלים, אלא בגלל חיבור נקודות (Connecting the Dots) מפיסות מידע לא מסווגות שנאספו ממקורות גלויים (למשל, שיחות חיילים בבר, הזמנות ציוד, תנועת ספינות).
העיקרון של OpSec הוא פשוט: לזהות אילו פיסות מידע עלולות לדלוף, להבין איך האויב יכול להשתמש בהן נגדך, ולנקוט בצעדים כדי למנוע את הדליפה הזו.
בסייבר, OpSec הוא התהליך של ניתוק מוחלט בין הזהות האמיתית שלך (מי אתה, איפה אתה גר, ה-IP שלך) לבין הפעולות הדיגיטליות שלך.
זה לחשוב כמו הבלש 🕵️‍♂️ שמנסה לתפוס אותך, ולשאול בכל רגע נתון: "איזו ראיה אני משאיר מאחור?" ו-"איך פיסת המידע התמימה הזו יכולה להפליל אותי?".
חמשת עקרונות ה-OpSec (בהרחבה)
תהליך OpSec מקצועי מורכב מחמישה שלבים קבועים:

1. זיהוי מידע רגיש (מה אני מנסה להגן עליו?)
זה לא רק "הזהות שלי". זה כל דבר שיכול לשמש כ-IoC (Indicator of Compromise) "מחוון לפריצה".
זהות אישית: שם, כתובת IP אמיתית, כתובת MAC, הרגלי גלישה, חשבונות אישיים.
תשתיות תקיפה: כתובות ה-IP של שרתי ה-VPS שלך, הדומיינים שרכשת, שמות שרתי ה-C2.
כלים וטכניקות (TTPs): הנוזקה שכתבת, הסקריפטים שלך, הפקודות הספציפיות שאתה משתמש בהן. אם אתה משתמש באותם כלים בכל תקיפה, יצרת "חתימה" שניתן לקשר אליך.
מטרות וכוונות: מי היעד שלך? מה אתה מנסה להשיג?

2. זיהוי האיומים (מי מחפש אותי?)
חשוב להבין מי האויב שלך ומה היכולות שלו:
צוות כחול (Blue Team) / SOC של הארגון: הם רואים את הלוגים הפנימיים. הם יזהו את ה-IP שלך סורק אותם, את הנוזקה שלך רצה על תחנה, ואת התעבורה שיוצאת לשרת ה-C2 שלך.
חוקרי אבטחה וחברות Malware Analysis (כמו Mandiant, CrowdStrike): אם הנוזקה שלך נתפסת, הם יבצעו לה הנדסה הפוכה (Reverse Engineering), יפרקו אותה לגורמים, יחלצו את ה-IPs והדומיינים, ויפרסמו דוח מפורט עליך ועל הכלים שלך.
רשויות אכיפת חוק (FBI, יחידות סייבר): יש להם יכולות משפטיות. הם יכולים להוציא צווים לספקי VPN, ספקי VPS, ורשמי דומיינים כדי לקבל את פרטי התשלום והזהות האמיתית שלך.

3. ניתוח פגיעויות (איך אני יכול להיתפס?)
כאן בוחנים את החולשות שלך.
כישלון טכני: נפילה של ה-VPN שלך שגורמת לחיבור ישיר מה-IP הביתי שלך לשרת התקיפה (אפילו לשנייה אחת, זה נרשם בלוגים!).
טעות אנוש: שימוש חוזר בסיסמה. שימוש באותו כינוי (Nickname) בפורום האקרים ובחשבון הטוויטר האישי שלך.
עקבות פיננסיים: רכישת VPS או דומיין עם כרטיס האשראי האישי שלך.
דפוסים (Patterns): תקיפה רק בשעות הלילה של אזור זמן ספציפי (חושף איפה אתה גר), שימוש באותן שגיאות כתיב בקוד שלך או בפישינג.
דוגמה קלאסית: הקטור מונסגור ("Sabu") מקבוצת LulzSec, נתפס ב-2011 כי פעם אחת פעם אחת בלבד הוא התחבר לשרת IRC של הקבוצה ללא ה-VPN שלו. ה-IP הביתי שלו נרשם, וה-FBI היה אצלו בדלת תוך זמן קצר.

4. הערכת סיכונים (מה הסיכוי ומה המחיר?)
לא כל המבצעים שווים. צריך להעריך מה רמת הסיכון שאתה מוכן לקחת:
פנטסטינג חוקי (עם חוזה): סיכון נמוך מאוד. יש לך חוזה חתום. ה-OpSec כאן נועד בעיקר כדי לא "להישרף" מול הצוות הכחול ולהצליח במשימה.
תקיפת Black Hat על אתר קטן: סיכון בינוני.
תקיפת תשתית ממשלתית או בנק: סיכון מקסימלי. אתה מתעסק עם גופים שיש להם משאבים בלתי מוגבלים לצוד אותך. ההשלכות המשפטיות הן עצומות.
5👏1
5. יישום אמצעי נגד (מה עושים בנידון?)
זהו השלב המעשי, שיהיה המוקד של הפוסט הבא שלנו. זה כולל:
שימוש ב-VPN, Tor, ושרשורי פרוקסי.
בניית תשתיות C2 מופרדות ושימוש ב-Redirectors.
שימוש במכונות וירטואליות מבודדות.
תשלום אנונימי בקריפטו.
ועוד...

🛡️ השלכות אבטחת מידע: למה זה קריטי לשני הצדדים?
לתוקף (Red Team / Black Hat):
יOpSec הוא אורך החיים שלך. זה ההבדל בין Script Kiddie שנתפס אחרי שבוע לבין קבוצת APT (Advanced Persistent Threat) שיושבת ברשת של יעד (כמו ממשלה או חברה גדולה) במשך שנים, גונבת מידע בשקט, ומשיגה את מטרותיה מבלי שאף אחד יידע שהיא שם. OpSec גרוע מוביל ל"שריפה" מהירה של הכלים, התשתיות והמוניטין שלך.
למגן (Blue Team / Threat Hunters):
הבנת OpSec היא הנשק הכי חזק שלכם! אתם לא מחפשים רק וירוס; אתם צדים את האדם שמאחורי המקלדת.
ציד איומים (Threat Hunting): במקום לחכות להתראה מהאנטי-וירוס, אתם מחפשים את הטעויות ב-OpSec של התוקף.
חיבור נקודות: האם מצאתם דומיין C2? בדקו מי רשם אותו. האם הוא השתמש ב-Whois Privacy? בדקו אם יש עוד דומיינים שנרשמו באותה שיטה ובאותו יום. מצאתם IP? סרקו אותו לפורטים אחרים אולי התוקף שכח לסגור פורט ניהול שחושף מידע?
ניתוח TTPs: האם התוקף משתמש תמיד באותה פקודת PowerShell? אתם יכולים לבנות חוק זיהוי (YARA/Sigma) שמחפש ספציפית את ה"חתימה" הזו ברשת שלכם.

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

בפוסט הבא (חלק 2), נצלול לעומק הפרקטיקה: איך בונים מאפס סביבת תקיפה עם OpSec חזק החל מבחירת ה-VPN, דרך בניית מכונות וירטואליות מבודדות, ועד להקמת תשתיות C2 עם Redirectors כדי להגן על השרתים האמיתיים שלכם.
הישארו מעודכנים, והכי חשוב הישארו בצד החוקי.
שאלות? הערות? שתפו אותי! 👇
הצטרפו לערוץ @CYBERSECURITYCODING
5👍2🔥1👏1
🛠️ חלק 2: OpSec - בניית סביבת תקיפה (המדריך המעשי) 🛠️
בפוסט הקודם (חלק 1), דיברנו על ה"למה" ועל ה"מה" מהי תפיסת ה-OpSec ומדוע היא קריטית. היום אנחנו צוללים ל"איך". איך בפועל בונים סביבה שמפרידה אתכם מהפעולות שלכם ומקשה על זיהוי וייחוס (Attribution).
אזהרה: המדריך הזה הוא המשך ישיר לחלק 1, והאזהרה משם תקפה גם כאן במלוא עוצמתה.

💻 שלב 1: מכונת העבודה - בידוד מוחלט
הכלל הראשון והבלתי ניתן לעבירה: לעולם אל תפעל מהמחשב האישי שלך. המחשב הביתי שלך מלא ב"דנ"א דיגיטלי": חשבונות, היסטוריית גלישה, כתובת MAC, קבצים אישיים.
וירטואליזציה (VMs) היא חובה:
כלים: השתמשו ב-VirtualBox (חינמי) או VMware .
למה? הוירטואליזציה יוצרת "ארגז חול" (Sandbox) מבודד. אם משהו משתבש, אם המכונה נחשפת או נפרצת היא אינה משפיעה על המחשב המארח (Host) שלכם.
תצורה:
מערכת הפעלה "נקייה": אל תתקינו ישר את Kali Linux. קאלי היא נהדרת, אבל היא "רועשת" ויש לה טביעת אצבע ברורה שכלים כמו EDR מזהים בקלות. התחילו עם התקנה מינימלית של הפצה יציבה (כמו Debian או Ubuntu Server) והתקינו רק את הכלים שאתם צריכים ספציפית למבצע.
רשת: הגדירו את הרשת של ה-VM במצב NAT או Host-Only. לעולם לא Bridged, שחושף את ה-MAC של ה-VM (ולפעמים שלכם) לרשת החיצונית.

יVPN בתוך ה-VM: הפעילו VPN בתוך המכונה הוירטואלית, בנוסף ל-VPN (אם יש) על המחשב המארח. זוהי שכבת בידוד נוספת.
מערכות ייעודיות (אופציונלי למתקדמים):
יTails OS: מערכת הפעלה שרצה מ-USB, לא משאירה עקבות על המחשב, ומנתבת את כל התעבורה דרך רשת Tor. מצוינת לשלב המחקר ורכישת התשתיות.
יWhonix: פתרון VM מתקדם המורכב משתי מכונות (Workstation ו-Gateway) שמכריח את כל התעבורה לעבור דרך Tor, ומגן מפני דליפות IP ו-DNS.

🌐 שלב 2: אנונימיות ברשת (תשלומים וגישה)
לפני שאתם בכלל רוכשים שרת, אתם צריכים דרך אנונימית לגשת ולשלם.
יVPN (Virtual Private Network):
לא כל VPN נולד שווה: חפשו ספקים עם מדיניות "No-Logs" מוכחת (שעמדה במבחן משפטי).
תשלום: שלמו באמצעות מטבעות קריפטוגרפיים 🪙, רצוי מטבעות ממוקדי פרטיות כמו Monero (XMR) שהם כמעט בלתי ניתנים למעקב, בניגוד לביטקוין.
טכניקה: השתמשו ב-Multi-hop VPN (שרשור VPN) – התעבורה עוברת דרך 2 שרתים או יותר, מה שמקשה עוד יותר על המעקב.
רשת Tor (The Onion Router):
השתמשו בדפדפן Tor כדי להירשם לשירותים (ספקי VPS, אימייל).
זכרו: Tor מספק אנונימיות, לא בהכרח אבטחה. אל תתחברו לחשבונות אישיים דרך Tor.

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

🛡️ שלב 3: בניית תשתית C2 חסינה (Resilient Infrastructure)
זהו לב ה-OpSec המעשי. שרת ה-C2 (Command and Control) הוא "המוח" שלכם, השרת שאליו הנוזקות ששתלתם מתקשרות חזרה. אסור שהוא ייחשף.
הטעות הנפוצה: הנוזקה מתחברת ישירות ל-IP של שרת ה-C2.
[Victim] ---> [Your C2 Server (IP: 1.2.3.4)]
הבעיה: ברגע שצוות ההגנה מנתח את הנוזקה, הוא מוצא את ה-IP 1.2.3.4, חוסם אותו ב-Firewall, מדווח עליו... והשרת שלכם "שרוף". כל המבצע נגמר. 👎
הפתרון המקצועי: Redirectors (מתווכים)
אנחנו בונים "בובות קש". שרת ה-C2 האמיתי לעולם לא נחשף לאינטרנט הציבורי בצורה ישירה.
הארכיטקטורה הנכונה:
[Victim] ---> [Redirector 1 (VPS זול)] ---> [Your "Real" C2 Server (מוסתר)]
מהו Redirector?
שרת VPS זול מאוד (ב-5$ לחודש) שכל תפקידו הוא להעביר תעבורה. זה "בשר תותחים" שנועד "להישרף".

איך מיישמים?
טכניקה 1 (פשוט): socat או iptables
מגדירים כלל פשוט ב-Redirector שמעביר את כל התעבורה שמגיעה לפורט 443 (לדוגמה) הלאה ל-IP של שרת ה-C2 האמיתי שלכם.
טכניקה 2 (מתקדם): Reverse Proxy (Nginx / Apache)
זו השיטה העדיפה. אתם מגדירים את Nginx כך שהוא בודק כל בקשה נכנסת.
אם הבקשה נראית לגיטימית (למשל, יש לה User-Agent ספציפי או מגיעה מדומיין מסוים) ⬅️ היא מועברת ל-C2 האמיתי.
אם הבקשה לא תואמת (למשל, חוקר אבטחה סקרן שמנסה לגלוש ל-IP) ⬅️ היא מועברת לאתר תמים (כמו https://www.google.com/search?q=google.com) או מקבלת דף 404.
היתרון העצום:
כשהצוות הכחול חוקר, הוא מוצא רק את ה-IP של ה-Redirector.
הם חוסמים אותו.
אתם? פשוט מוחקים את ה-VPS הזול, מקימים אחד חדש תוך 2 דקות, מעדכנים את הדומיין, והמבצע ממשיך כאילו כלום לא קרה. שרת ה-C2 האמיתי שלכם נשאר נקי ומוגן.
1🔥1
📝 סיכום: להיות רוח רפאים
בניית סביבה עם OpSec חזק היא לא אירוע חד-פעמי, אלא תהליך מתמשך של בניית שכבות הגנה:
בידוד אישי: VM נקי + VPN/Tor.
אנונימיות פיננסית: תשלום בקריפטו וחשבונות אנונימיים.
בידוד תשתיתי: שימוש ב-Redirectors כדי להגן על שרתי הליבה (C2).
כל שכבה כזו נועדה לעכב, לבלבל, ולבזבז את הזמן והמשאבים של מי שמנסה לצוד אתכם. OpSec הוא מה שמבדיל בין רעש חובבני לפעולה שקטה ומדויקת.
הישארו בצד החוקי, ולמדו את הטכניקות האלה כדי להיות מגנים טובים יותר.
שאלות על הפרקטיקה? רעיונות נוספים? שתפו אותי! 👇
הצטרפו לערוץ @CYBERSECURITYCODING
3🔥2
ארגון OWASP פרסם טיוטה חדשה ל־OWASP Top 10 2025 רשימת עשר הפגיעויות הכי נפוצות באפליקציות Web.

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

בגרסה של 2025 יש כמה חידושים חשובים:

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

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

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

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

🔗 לאתר OWASP

https://t.me/CyberUpdatesIL/1965

#OWASP #OWASPTop10 #AppSec #SecureCoding #DevSecOps #WebSecurity #SoftwareSecurity #Developers
1
🚨 חברי קבוצת CyberSecurityCoding היקרים! 🚨
הגיע הזמן שתבחרו את הנושא הבא שאני אפרט עליו 💡

🔍 איזה תחום בסייבר מסקרן אתכם במיוחד?
זה יכול להיות כל דבר:

פריצה אתית (Ethical Hacking)
ניתוח נוזקות (Malware Analysis)
הגנות בענן
יOSINT
קריפטוגרפיה
יReverse Engineering
או כל נושא אחר
שאתם רוצים להבין לעומק!


🗳 כתבו בתגובות את הנושא שהכי הייתם רוצים שאסביר עליו.
❤️ התגובה עם הכי הרבה לייקים – עליה נפרט בפוסט מיוחד ומעמיק!

📌 הקבוצה שלנו: CyberSecurityCoding

יאללה, תנו בראש!
#CyberSecurity #סייבר #למידה #קהילה
🥰5🤩1
🔍 הפוסט שכולכם חיכיתם לו: OSINT – מודיעין ממקורות גלויים

📊 בהצבעה האחרונה בקבוצת CyberSecurityCoding, הנושא שזכה להכי הרבה לייקים ותגובות היה ללא ספק – OSINT. אז כמו שהבטחנו – הנה פוסט מעמיק שיפתח לכם את הראש!

🧠 מה זה OSINT?

OSINT (Open Source Intelligence) הוא תחום במודיעין שמתמקד באיסוף, ניתוח והסקת מסקנות ממידע שזמין לציבור – כלומר, ממקורות פתוחים. זה כולל את האינטרנט, רשתות חברתיות, פורומים, מסמכים ציבוריים, תמונות לוויין, מאגרי מידע ממשלתיים ועוד.

OSINT הוא כלי עוצמתי בידי חוקרי סייבר, אנליסטים, עיתונאים, חוקרים פרטיים, ואפילו תוקפים (Black Hat Hackers).

⚙️ איך OSINT עובד?

1. הגדרת מטרה – מה מחפשים? מידע על אדם? ארגון? כתובת IP?
2. איסוף מידע – שימוש בכלים וטכניקות למציאת מקורות רלוונטיים.
3. אימות וסינון – לא כל מה שכתוב באינטרנט נכון. צריך לבדוק מה אמין.
4. ניתוח והסקת מסקנות – חיבור הנקודות, זיהוי דפוסים, בניית פרופיל.
5. דיווח או שימוש במידע – תלוי במטרה: חקירה, הגנה, או תקיפה.

🧰 כלים פופולריים ב-OSINT

Maltego
מיפוי קשרים בין אנשים, דומיינים, IPs


theHarvester
איסוף מיילים, שמות משתמשים, דומיינים


Shodan
סריקת מכשירים מחוברים לאינטרנט


SpiderFoot
אוטומציה של איסוף מידע ממקורות רבים


Google Dorks
חיפושים מתקדמים בגוגל למציאת מידע רגיש


Recon-ng
פלטפורמה מודולרית לאיסוף מודיעין


Have I Been Pwned
בדיקת דליפות מידע לפי אימייל




🧭 סוגי OSINT

1. SOCMINT – מודיעין מרשתות חברתיות (Social Media Intelligence)
2. GEOINT – מודיעין גיאוגרפי (למשל, תמונות לוויין)
3. TECHINT – מידע טכנולוגי (כמו פורטים פתוחים, מערכות הפעלה)
4. HUMINT – מידע שמגיע מבני אדם (פורומים, בלוגים)
5. WEBINT – מידע מהאינטרנט הגלוי והעמוק (כולל Dark Web)

🕵️ דוגמה מהשטח

נניח שאתה רוצה לבדוק אם ארגון מסוים חשוף לסכנות:

תתחיל ב־whois על הדומיין.
תבדוק עם Shodan אם יש פורטים פתוחים.
תאסוף מיילים עם theHarvester.
תבדוק אם אחד מהם דלף עם Have I Been Pwned.
תנתח את הקשרים עם Maltego.


תוך זמן קצר – יש לך תמונת מצב מודיעינית.

🚨 למה זה חשוב?

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


💬 לסיכום

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

רוצים שנעשה תרגול OSINT בקבוצה?
כתבו בתגובות!

#CyberSecurity #OSINT #מודיעין #למידה_בקהילה #סייבר
👍21🔥1
איתור משתמשים ו-OSINT עם Sherlock (חלק 1)
אנחנו פותחים סדרה חדשה על People OSINT , לאיסוף מודיעין על אנשים וזהויות.
הכלי הראשון שנלמד לעומק הוא Sherlock, שנחשב לסטנדרט בתחום ה-Username Enumeration.

הלוגיקה: למה זה עובד?
נקודת התורפה שאנחנו מנצלים היא פשוטה: מיחזור שמות משתמש (Username Reuse).
רוב האנשים משתמשים באותו כינוי (User) במגוון פלטפורמות ב-GitHub, ברשתות החברתיות, בפורומים מקצועיים ואפילו באתרי היכרויות.
מבחינת תוקף או חוקר OSINT, מציאת שם משתמש בפלטפורמה אחת מאפשרת לבצע Correlation (הצלבה) ולמצוא את המטרה בעשרות אתרים אחרים. כך בונים "פרופיל" מלא שכולל תחומי עניין, מיקום גיאוגרפי, ולעיתים מוביל לחשיפת המייל האישי.

איך Sherlock עובד טכנית?
במקום לחפש ידנית, Sherlock מבצע אוטומציה מול כ-400 אתרים ושירותים שונים.
הסקריפט שולח בקשות HTTP (לרוב GET) לכתובות ה-URL של הפרופילים, ומנתח את התשובה של השרת (Response Code):
קוד 404 (Not Found): המשתמש לא קיים באתר.
קוד 200 (OK): המשתמש קיים.
סינון רעשים: יש אתרים שמחזירים קוד 200 גם כשאין משתמש (אבל מציגים דף שגיאה מעוצב). Sherlock יודע לנתח את ה-Body של התשובה ולזהות אם מדובר בפרופיל אמיתי או ב-False Positive.
הקמת סביבת עבודה
כדי להריץ את הכלי נצטרך Python 3 ו-Git מותקנים. מומלץ לעבוד בסביבת לינוקס (כמו Kali), אבל זה עובד מצוין גם ב-Windows.

1. הורדת הפרויקט (Clone)
נמשוך את הקוד העדכני מ-GitHub:

git clone https://github.com/sherlock-project/sherlock.git
cd sherlo
ck

2. התקנת חבילות (Requirements)
הכלי משתמש בספריות חיצוניות (כמו requests לתקשורת). נתקין אותן בצורה מרוכזת.
טיפ: מומלץ תמיד לעבוד בתוך סביבה וירטואלית (Virtual Environment) של פייתון כדי לא ללכלך את המחשב.


python3 -m pip install -r requirements.txt

3. בדיקה שהכל עובד
נריץ את פקודת העזרה. אם קיבלתם את רשימת האפשרויות ההתקנה הצליחה.

python3 sherlock --help

בפוסט הבא: נבצע סריקה ראשונה על שם משתמש אמיתי, נלמד איך להתמודד עם חסימות מצד האתרים (Timeouts) ואיך לשמור את התוצאות לקובץ מסודר להמשך חקירה.

הצטרפו לערוץ: @CYBERSECURITYCODING
11🔥3🥰1
איתור משתמשים עם Sherlock: ביצוע סריקות ומתודולוגיה (חלק 2)
בפוסט הקודם הקמנו את סביבת העבודה והבנו את הלוגיקה מאחורי מיחזור שמות משתמש.
היום אנחנו עוברים ל-Execution. נלמד איך להפעיל את הכלי בצורה מבצעית, איך לשמור על אנונימיות (OpSec) ואיך לנהל את המידע שנאסף כדי לא לטבוע בים של נתונים.
סריקה בסיסית:
הפעולה הבסיסית ביותר היא סריקה של שם משתמש בודד מול כל מאגר האתרים של Sherlock.
מתוך התיקייה של הכלי, הריצו את הפקודה הבאה (החליפו את target_user בכינוי שאתם חוקרים):

python3 sherlock target_user

מה קורה עכשיו במסך?
הכלי מתחיל לרוץ במקביל על מאות אתרים. כל שורה ירוקה עם הסימן [+] מסמנת Match כלומר, השרת החזיר תשובה חיובית (HTTP 200) והפרופיל קיים. הקישור לפרופיל יופיע מיד ליד שם האתר.

ניהול המידע (Output Management)
בחקירת OSINT אמיתית, אנחנו לא סתם זורקים פקודות לטרמינל. אנחנו צריכים לשמור ראיות.
כברירת מחדל, Sherlock ייצור קובץ טקסט בשם target_user.txt באותה תיקייה ממנה הרצתם את הסקריפט.
אבל מה אם אנחנו חוקרים כמה מטרות במקביל? אנחנו רוצים סדר.
נשתמש בדגל --folderoutput כדי לנתב את התוצאות לתיקייה ייעודית לכל חקירה:

python3 sherlock target_user --folderoutput /home/kali/investigations/case_1/

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

התמודדות עם חסימות ואיטיות (Timeouts)
אחת הבעיות הנפוצות בשימוש בכלים אוטומטיים היא ששרתים מסוימים מגיבים לאט, או שהחיבור שלנו נחנק מעומס הבקשות.
אם שרת לא עונה מהר מספיק (או שהאינטרנט שלנו איטי), Sherlock יסמן אותו כ-Not Found, ואנחנו עלולים לפספס מידע קריטי (False Negative).
כדי למנוע את זה, נגדיר Timeout ארוך יותר (ברירת המחדל היא קצרה יחסית).
נשתמש בדגל --timeout כדי לתת לכל בקשה כמה שניות לפני שמוותרים עליה:

python3 sherlock target_user --timeout 10

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

עבודה חשאית: שילוב Tor לאנונימיות
זהו החלק הכי חשוב בהיבט של אבטחת מידע ו-OpSec.
כשאתם מריצים את Sherlock מהמחשב שלכם, אתם שולחים בקשות ישירות לשרתים של האתרים (Instagram, GitHub וכו'). השרתים האלו רושמים את כתובת ה-IP האמיתית שלכם בלוגים שלהם.
במקרים רגישים, נרצה להסתיר את ה-IP שלנו. Sherlock תומך אינטגרלית בניתוב התעבורה דרך רשת Tor.
דרישות מקדימות:
חובה ששירות Tor ירוץ ברקע במחשב שלכם.
ב-Kali Linux או Ubuntu:

sudo service tor start

הפעלת הסריקה דרך Tor:

python3 sherlock target_user --tor

עכשיו, כל הבקשות עוברות דרך רשת ה-Onion, והאתר היעד יראה כתובת IP רנדומלית של Tor Exit Node במקום את הכתובת של הבית שלכם.
שימו לב: השימוש ב-Tor יאט משמעותית את הסריקה.

ניתוח תוצאות ו-False Positives
סיימתם לסרוק. קיבלתם רשימה של 15 אתרים. האם כולם שייכים לאותו אדם? חד משמעית לא.
כאן נכנסת העבודה של החוקר האנושי.
אימות ידני: חובה להיכנס לקישורים. האם תמונת הפרופיל זהה? האם תיאור המשתמש (Bio) דומה?
פופולריות השם: אם הכינוי הוא alex1990, סביר להניח שתמצאו אותו בכל אתר, אבל אלו יהיו אנשים שונים. אם הכינוי הוא xX_CyberGhost_IL_Xx, הסיכוי ל-Match אמיתי הוא גבוה מאוד.
הקשר לוגי: אם המטרה היא מפתח תוכנה, הגיוני למצוא אותו ב-GitHub, StackOverflow ו-HackerNews. פחות סביר (אך אפשרי) למצוא אותו באתרים של סריגה או מתכונים.

בפוסט הבא: ה-Pivoting. איך לוקחים את הקישורים שמצאנו ב-Sherlock (למשל חשבון Spotify או Trello) ושולפים מתוכם מידע אישי כמו שם מלא, מיקום או כתובת מייל כדי לסגור מעגל.

יש לכם שאלות? נתקלתם בשגיאות? שתפו בתגובות! 👇
הצטרפו לערוץ: @CYBERSECURITYCODING
6🔥5
🕵️‍♂️ מ-Username לזהות אמיתית: אמנות ה-Pivoting (חלק 3)
בשלב הזה של הסדרה, כבר יש בידיכם רשימת תוצאות ש-Sherlock הפיק: קובץ טקסט עם 10-20 קישורים לפרופילים שונים (GitHub, Twitter, Trello, Spotify וכו').
אבל רשימת קישורים היא לא המטרה. היא האמצעי.
בפוסט זה נלמד את שלב ה-Pivoting . זוהי הפרקטיקה של שימוש בפיסת מידע אחת (שם משתמש) כדי לחלץ פיסת מידע חדשה וחזקה יותר (כמו כתובת אימייל או שם מלא), שתאפשר לנו להעמיק את החקירה.
ננתח שלוש טכניקות מרכזיות לניתוח התוצאות שקיבלתם מ-Sherlock.

1. מכרה הזהב של המפתחים: חשיפת אימייל דרך GitHub
אם Sherlock מצא שלמטרה שלכם יש חשבון GitHub, רוב הסיכויים שזהו ה-Game Over של החקירה מבחינת אנונימיות.
מפתחים רבים מגדירים את ה-Git Client שלהם עם כתובת המייל הארגונית או הפרטית, ושוכחים שמידע זה נשמר בתוך ה-Metadata של כל העלאת קוד (Commit), גם אם האימייל מוסתר בפרופיל הראשי.
הטכניקה (The .patch Method):
זוהי דרך אלגנטית לשלוף את המידע ללא כלים חיצוניים, רק באמצעות הדפדפן:
היכנסו לפרופיל ה-GitHub שהכלי מצא.
פתחו את אחד ה-Repositories (מאגרי הקוד) שהמשתמש יצר או תרם להם (לא Fork).
לחצו על לשונית ה-Commits (היסטוריית השינויים).
לחצו על Commit ספציפי שהמשתמש ביצע.
כעת, הביטו בשורת הכתובת (URL) בדפדפן. היא תיראה כך:
github.com/username/repo/commit/88e4...
הטריק: הוסיפו את הסיומת .patch לסוף הכתובת ולחצו Enter.
הדפדפן יציג לכם מסך טקסטואלי גולמי. בשורה השנייה או השלישית, תחת השדה From:, תופיע לרוב כתובת האימייל המלאה של המשתמש, ושמו המלא כפי שהוגדר במחשב ממנו הוא כתב את הקוד.

2. דפוסים ומידע משלים (Cross-Reference)
יSherlock נותן לכם את ה"איפה", אתם צריכים להבין את ה"מי".
אחת הטעויות הנפוצות היא להניח שכל התוצאות רלוונטיות. עליכם לבצע הצלבה ויזואלית ותוכנית:
תמונות פרופיל (Avatars): האם המשתמש ב-Steam משתמש באותה תמונה כמו המשתמש ב-Twitter? אם כן, רמת הוודאות עולה ל-99%. שמרו את התמונה ופצעו עליה חיפוש הפוך (Reverse Image Search) כדי למצוא רשתות ש-Sherlock פספס.

הביוגרפיה (Bio): אנשים נוטים להשאיר רמזים בתיאור הפרופיל. בטוויטר הוא עשוי לכתוב "Dev at X", ובאינסטגרם תחת אותו שם משתמש תראו תמונות ממשרדי החברה. זהו אימות מיקום ותעסוקה.
יTrello ולוחות עבודה: אם מצאתם משתמש Trello, בדקו את הלוחות הציבוריים. לעיתים קרובות תמצאו שם משימות כמו "To do: Send invoice to [Client Name]", שחושפות את מקום העבודה או הלקוחות של המטרה.

3. ניצול מנגנוני שחזור סיסמה (Password Reset Enumeration)
זוהי טכניקה המהלכת על הגבול האפור (Gray Area) ומשמשת תוקפים לאימות סופי של זהות. אין לבצע זאת למטרות זדוניות, אלא רק לצורך מחקר והבנת הסיכון.
נניח ש-Sherlock מצא משתמש בטוויטר, אבל אין לכם את האימייל שלו.
התוקף ניגש למסך ההתחברות ולוחץ על "שכחתי סיסמה".
הוא מזין את שם המשתמש שנמצא.
האתר יציג הודעה: "שלחנו קוד אימות לכתובת d***@gmail.com".
אומנם הכתובת מצונזרת, אבל זה נותן שני נתונים קריטיים:
אימות קיום: המשתמש אכן פעיל ומקושר לאימייל.

רמז: האות הראשונה והספק (Gmail) עוזרים להצליב מידע עם האימייל שמצאנו קודם בשיטת ה-GitHub. אם הם תואמים יש לנו זיהוי ודאי.
סיכום ביניים: בניית התיק
בשלב הזה, התחלנו משם משתמש פשוט כמו CyberNinja90.
באמצעות Sherlock והטכניקות שלעיל, הפכנו אותו ל:
שם מלא: ישראל ישראלי (מתוך ה-GitHub Patch).
אימייל: israel.dev@company.com.
תחביבים: גיימינג (Steam), מוזיקת רוק (Spotify Public Playlists).
מראה: תמונה עדכנית (Instagram/Twitter).
זהו הכוח של Aggregation (איסוף מצטבר). כל פיסת מידע בנפרד נראית תמימה, אך החיבור שלהן יוצר תמונת מודיעין מלאה.
בפוסט הבא: הגנה. איך מונעים את כל מה שעשינו עכשיו? נדבר על OpSec, מחיקת עקבות, והפרדת זהויות (Compartmentalization).

הכרתם את טריק ה-.patch בגיטהאב? ספרו לי בתגובות! 👇

הצטרפו לערוץ: @CYBERSECURITYCODING
🔥83
🕵️‍♂️ סוף דבר: שרלוק "מתחת למכסה המנוע" ומדריך ההגנה המלא (חלק 4/4)
אנחנו מגיעים לסיום סדרת ה-OSINT שלנו.
בפרקים הקודמים עבדנו עם Sherlock כמשתמשים רגילים, ביצענו סריקות וחשפנו מיילים דרך GitHub.
היום בפוסט הסיום נעשה שני דברים קריטיים:
יRed Team (התקפה): נלמד איך לערוך את הקוד של Sherlock כדי להוסיף לו אתרים שהוא לא מכיר (כמו פורומים ישראליים).
יBlue Team (הגנה): נלמד איך חוסמים את כל מה שעשינו בסדרה, כולל סגירת דליפת המייל ב-GitHub.
מתחילים! 👇

🛠️ חלק א': Weaponization – התאמה אישית של הכלי
יSherlock הוא לא קסם, הוא סקריפט Python שקורא מקובץ נתונים.
כברירת מחדל, הוא סורק כ-400 אתרים בינלאומיים. אבל מה אם המטרה שלכם נמצאת בפורום ישראלי קטן? או בפורטל ארגוני ספציפי?
כדי להפוך את הכלי לקטלני יותר, נצטרך לערוך את הקובץ sherlock/resources/data.json.
איך מוסיפים אתר חדש?
נפתח את הקובץ בעורך טקסט. המבנה של כל אתר נראה כך (JSON):
JSON
"IsraelHackingForum": { "errorType": "status_code", "errorMsg": null, "url": "https://israel-hack.co.il/profile/{}", "urlMain": "https://israel-hack.co.il/", "username_claimed": "blue" },
הסבר הלוגיקה (לקודרים שבינינו):
יurl: זו הכתובת לפרופיל. הסוגריים המסולסלים {} הם המקום שבו הסקריפט יציב (Inject) את שם המשתמש שאנחנו מחפשים.
יerrorType: איך הכלי יודע אם המשתמש קיים?
יstatus_code: השיטה הקלאסית. אם השרת מחזיר 404 אין משתמש. אם 200 יש.
יmessage: באתרים מורכבים שמחזירים 200 גם כשאין משתמש, נגדיר לשרלוק לחפש מחרוזת טקסט ספציפית בתוך ה-HTML (למשל "User not found") כדי לזהות שאין תוצאה.
למה זה טוב? כי זה מאפשר לכם לבנות כלי OSINT שמכיר אתרים שאף חוקר אחר לא בודק(כמו פרום חדש שמצאתם)!

🛡️ חלק ב': Blue Team – אסטרטגיית ההגנה (OpSec)
אחרי שהבנו כמה קל לבנות פרופיל על אדם, אנחנו חייבים להפוך את הקערה.
אי אפשר באמת "להיעלם" מהאינטרנט, אבל אפשר לנהל את הסיכון. הנה הפעולות הטכניות שאתם חייבים לעשות היום:

1. סתימת הפרצה ב-GitHub (קריטי!) 🚨
בפרק 3 ראינו איך אפשר לחשוף מייל פרטי מכל משתמש GitHub באמצעות טריק ה-.patch.
כדי למנוע את זה אצלכם:
כנסו ל-Settings בגיטהאב.
גשו לתפריט Emails.
סמנו V על: Keep my email addresses private.
הכי חשוב: סמנו V גם על Block command line pushes that expose my email.
למה? הגדרה זו תמנע מכם לבצע git push מהטרמינל אם הקונפיגורציה במחשב שלכם חושפת את המייל האמיתי, ותכריח אתכם להשתמש במייל ה-noreply האנונימי של גיטהאב.

2. טקטיקת ה-Disinformation
במקום לנסות למחוק את עצמכם (שזה כמעט בלתי אפשרי), צרו רעש.
אם שם המשתמש שלכם הוא CyberWolf90 ואתם משתמשים בו להכל אתם חשופים.
הפתרון: צרו חשבונות פיקטיביים עם אותו שם משתמש באתרים לא רלוונטיים (פורום סריגה, אתר מתכונים), עם פרטים ביוגרפיים שונים (גיל שונה, מדינה שונה).
כשחוקר יריץ עליכם Sherlock, הוא יקבל 50 תוצאות שסותרות אחת את השנייה, ולא ידע מי ה-CyberWolf האמיתי.

3. ניהול זהויות (Identity Management)
חלקו את האינטרנט שלכם ל-3 רמות נפרדות (Compartmentalization):
רמה 1 (ציבורית): לינקדאין, טוויטר מקצועי (בשמכם האמיתי).
רמה 2 (פרטית): פייסבוק, אינסטגרם (כינוי שרק חברים מכירים).
רמה 3 (אנונימית/צללים): פורומים, Reddit, Discord. כאן השתמשו במייל ייעודי ובכינוי רנדומלי לחלוטין שלא קשור לשמכם.

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

🏁 סיכום הסדרה
בארבעת הפוסטים האחרונים עברנו מסע שלם של מודיעין סייבר:
הבנו למה Username Reuse הוא חולשה.
השתמשנו ב-Sherlock לאיתור רוחבי ואוטומטי.
ביצענו Pivoting חכם כדי להפוך שם משתמש לזהות אמיתית.
ולסיום למדנו איך לשפר את הכלי ואיך להגן על עצמנו.
מקווה שהסדרה נתנה לכם כלים חדשים לארגז הכלים!
על איזה כלי תרצו את הסדרה הבאה?
כתבו לי בתגובות! 👇
הצטרפו לערוץ: @CYBERSECURITYCODING
🔥92
עדכון כלי: NetExec

הכלי הפופולרי NetExec (הממשיך של CrackMapExec) קיבל עדכון משמעותי ביכולות ה-Dump שלו מול ה-Active Directory.
מהיום, בעת שליפת קובץ ה-NTDS.dit, נוספו שני דגלים (Flags) חדשים שמשנים את התמונה:
--history

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

שליפה אוטומטית של מפתחות ה-AES/DES המשמשים לאימות ב-Kerberos.
למה זה טוב? קריטי ליצירת Silver/Golden Tickets וביצוע התקפות מתקדמות ללא סיסמה ב-Cleartext

הפקודה לדוגמה:

nxc smb <IP> -u <User> -p <Pass> --ntds --history --kerberos-keys



תעדכנו גרסאות!
@CYBERSECURITYCODING
6
יIP Short-Handing: כשהמחשב "משלים" אותנו (ומה האקרים עושים עם זה)

אנחנו רגילים לחשוב על כתובות IP בצורה מאוד מקובעת: ארבעה מספרים מופרדים בנקודות (Dotted Decimal), כמו 192.168.1.1. אבל האם ידעתם שאם תכתבו בטרמינל ping 127.1 זה יעבוד ויגיע ל-Localhost?
היום נכנס לעומק פרוטוקול ה-IP, נבין איך מערכת ההפעלה באמת קוראת כתובות, ואיך טכניקה פשוטה של "קיצור כתובות" הופכת לכלי נשק לעקיפת הגנות.

רקע תיאורטי: זה הכל בינארי
כדי להבין למה 10.68 זה בעצם כתובת תקינה, צריך לזכור איך המחשב עובד. למחשב לא באמת אכפת מהנקודות. מבחינתו, כתובת IPv4 היא בסך הכל מספר בינארי אחד באורך 32 ביט.
השיטה עם הנקודות נועדה רק לנו, בני האדם. אבל כשאנחנו מזינים כתובת "חלקית" (פחות מ-4 חלקים), מערכת ההפעלה (בהתבסס על סטנדרטים היסטוריים כמו פונקציית inet_aton) מפעילה אלגוריתם השלמה אוטומטי:
החלקים הראשונים: נשארים בגודל רגיל של 8 ביט (אוקטטה).
החלק האחרון: "בולע" את כל הביטים שנשארו עד סוף הכתובת (עד ל-32 ביט).

בואו ננתח את הדוגמה 10.68:
המחשב מזהה שני חלקים.
החלק הראשון (10) תופס את 8 הביטים הראשונים -> 10.
החלק השני (68) צריך למלא את כל מה שנשאר (24 ביטים!).
בייצוג של 24 ביטים, המספר 68 הוא פשוט... 68 (עם המון אפסים לפניו שיוצרים שתי אוקטטות ריקות).
התוצאה: 10.0.0.68.
דוגמה נוספת 10.20.2:
10 (8 ביט) -> נשאר 10.
20 (8 ביט) -> נשאר 20.
2 (צריך למלא את 16 הביטים הנותרים) הופך ל-0.2.
התוצאה: 10.20.0.2.

פרקטיקה: איך זה עוזר לתוקף? (Offensive Security)
אז הבנו את המתמטיקה, אבל למה זה מעניין אותנו כאנשי אבטחה או האקרים? התשובה טמונה בדרך שבה מפתחים ומערכות הגנה מבצעים וולידציה (Input Validation).

1. עקיפת הגנות (WAF / Filter Evasion)
מערכות WAF (Web Application Firewall) או קוד צד-שרת מנסים לרוב לזהות כתובות IP זדוניות או חסומות באמצעות ביטויים רגולריים (Regex) או השוואת מחרוזות (String Matching).
התרחיש: המגן כתב חוק שחוסם את הכתובת 10.0.0.68. החוק מחפש את המחרוזת המדויקת הזו.
התקיפה: התוקף שולח בקשה עם הכתובת 10.68.
התוצאה: ה-WAF לא מזהה את המחרוזת ומעביר את הבקשה פנימה. מערכת ההפעלה של השרת, שמקבלת את הפקודה, מתרגמת את זה ל-IP המלא והתקיפה מצליחה.

2. מתקפות SSRF (Server Side Request Forgery)
במתקפות SSRF, התוקף מנסה לגרום לשרת לגשת למשאבים פנימיים שהוא לא אמור לגשת אליהם (כמו ממשק הניהול הפנימי או שירותי Metadata בענן).
התרחיש: מפתח חוסם גישה ל-127.0.0.1 (Localhost) כדי למנוע מהתוקף לגשת לשירותים מקומיים על השרת.
התקיפה: התוקף משתמש בקיצור המפורסם 127.1.
ההסבר: ה-1 נכנס ל-24 הביטים האחרונים הופך ל-0.0.1. ביחד עם ה-127 בהתחלה, זה מתורגם בול ל-127.0.0.1.
התוצאה: הפילטר נעקף, והשרת ניגש לעצמו.
י Hands-on: נסו בעצמכם
אתם יכולים לראות את ה"קסם" הזה קורה עכשיו בכל מערכת הפעלה (Linux, Windows, macOS).
פתחו טרמינל/CMD ונסו

ping 127.1
תראו שבפלט של ה-Ping, המערכת תציג לכם את הכתובת המלאה שתורגמה.

שורה תחתונה:
מחשבים קוראים מספרים, אנשים קוראים תבניות. הפער הזה הוא בדיוק המקום שבו נוצרות חולשות אבטחה. כשאתם כותבים קוד הגנה או מגדירים פיירוול תוודאו שאתם מנרמלים (Normalize) את ה-IP לפורמט מלא לפני שאתם בודקים אותו!
אהבתם? שתפו לחברים שחושבים שחייבים 4 נקודות בכתובת IP! 😉
הצטרפו לערוץ @CYBERSECURITYCODING
👍8🔥54
יTokenFlare - הדור הבא של מתקפות ה-AiTM ב-Serverless
היום נסקור כלי עוצמתי במיוחד בשם TokenFlare. מדובר ב-Framework מבוסס Python ו-JavaScript שנועד לבצע מתקפות Adversary-in-the-Middle (AiTM) מול סביבות Microsoft 365 / Entra ID, והכל תוך ניצול התשתית של Cloudflare Workers.

רקע תיאורטי: מה זה TokenFlare ולמה הוא מסוכן?
בעבר, פישינג התמקד בגניבת סיסמאות. היום, כשרוב הארגונים משתמשים ב-MFA (אימות דו-שלבי), סיסמה לבדה לא מספיקה לתוקף. כאן נכנס ה-AiTM.
איך זה עובד?
במקום דף מזויף סטטי, TokenFlare מקים "פרוקסי" (Proxy) חי בין הקורבן לבין השרת האמיתי של מיקרוסופט. הקורבן גולש לאתר של התוקף, אבל רואה את דף ההתחברות האמיתי של Microsoft בזמן אמת.

השלכות אבטחת מידע:
עקיפת MFA: מאחר והאימות מתבצע מול השרת האמיתי, הקורבן מזין את קוד ה-MFA שלו במידת הצורך. ברגע שהאימות מצליח, השרת שולח "Session Cookie" (אסימון התחברות). TokenFlare תופס את האסימון הזה ושולח אותו לתוקף. בעזרת האסימון, התוקף יכול להיכנס לחשבון בלי לדעת את הסיסמה ובלי לעבור MFA.

ניצול Serverless: הכלי רץ על Cloudflare Workers. זה אומר שאין שרת פיזי שאפשר להוריד בקלות, והתעבורה נראית לגיטימית לחלוטין למערכות הגנה רבות.
יOpSec (אבטחת מבצעים): הכלי כולל מנגנוני סינון שחוסמים בוטים של חברות אבטחה וסורקים אוטומטיים, מה שמשאיר את הקמפיין "חי" לאורך זמן.

🛠️ פרקטיקה: איך זה עוזר בתקיפה ואיך מפעילים אותו?
יTokenFlare בנוי בצורה מודולרית מאוד שמאפשרת גמישות מקסימלית לתוקף.
שלבי ההפעלה (למטרות מחקר ובדיקות מאושרות בלבד!):


התהליך מתחיל בהגדרת הדומיין שבו נשתמש.

python3 tokenflare.py init yourdomain.com

הפקודה הזו מייצרת את מבנה הפרויקט, מפיקה מפתחות UUID ייחודיים לקישורי ה"פיתיון" (Lures) ומייצרת תעודת SSL זמנית.
הגדרת הקמפיין (Configure Campaign):
זהו שלב אינטראקטיבי שבו קובעים לאן הקורבן יופנה, איזה "פיתיון" יוצג לו (למשל דף התחברות ל-Teams או Office 365) ולאן המידע הגנוב יישלח (Webhook).

python3 tokenflare.py configure campaign

הגדרת ענן (Cloudflare Configuration):
כדי להעלות את הכלי לאוויר, מחברים אותו לחשבון Cloudflare בעזרת API Key.

python3 tokenflare.py configure cf

פריסה (Deployment):
ניתן להריץ את הכלי מקומית לבדיקות או להעלות אותו לענן של Cloudflare בלחיצת כפתור:

python3 tokenflare.py deploy remote

איך המידע מגיע לתוקף?
הקוד ב-src/worker.js יודע לזהות את ה-Cookies הקריטיים (כמו ESTSAUTH ו-ESTSAUTHPERSISTENT) ואת ה-Auth Codes שנשלחים ב-URL. ברגע שהם נתפסים, הם נשלחים אוטומטית ל-Webhook שהוגדר (Discord/Slack/Teams).
קישור לכלי
https://github.com/JumpsecLabs/TokenFlare.git

📝 סיכום ודעה אישית
יTokenFlare הוא דוגמה קלאסית לכך שהגנה מבוססת סיסמה ו-MFA "סטנדרטי" כבר אינה מספיקה בארגונים רגישים. הכלי הזה פשוט להפעלה בצורה מפחידה, וזה מה שהופך אותו למסוכן כל כך.
מה דעתכם? האם הארגון שלכם ערוך להתמודד עם מתקפות AiTM? האם אתם משתמשים ב-FIDO2 או בשיטות MFA עמידות לפישינג?
שתפו את המאמר לחברים כדי שגם הם יכירו את האיומים החדשים! 🛡️🚀
הצטרפו לערוץ @CYBERSECURITYCODING
10🔥41👍1
🚨 פגיעות קריטית בגוגל Gemini: חשיפת נתוני יומן פרטיים דרך הזמנות תמימות! 🚨

🔍 מה קרה? 
חוקרים גילו התקפת indirect prompt injection ב-Gemini:

📅 תוקף שולח הזמנת יומן רגילה, אבל מסתיר בתיאור הנחיה זדונית. 

🤖 כשאתה שואל את Gemini "מה הלו"ז שלי?" או "סכם לי את הפגישות" – הוא קורא את ההזמנה ומבצע את ההנחיה הזדונית. 

📝 Gemini יוצר אירוע יומן חדש עם סיכום מלא של כל הפגישות הפרטיות שלך (כולל פרטים רגישים)! 

👀 בארגונים עם Google Workspace – התוקף (כמשתתף בהזמנה) רואה את האירוע החדש וגונב את המידע. 


החדשות הטובות: גוגל תיקנה את הפגיעות לאחר דיווח אחראי.

📅 פורסם היום: 19 בינואר 2026 
📖 מקור מלא: 
🔗 https://thehackernews.com/2026/01/google-gemini-prompt-injection-flaw.html

זה מדגים סיכונים חדשים בבינה מלאכותית משולבת בכלים יומיומיים 🔒

הצטרפו לקבוצה לעדכוני סייבר יומיים חמים! 🔥 
👇 https://t.me/CyberSecurityCoding
6👍1🔥1
היי לכולם, חזרנו! עבר קצת זמן מאז העדכון האחרון שלנו בקבוצה, אבל יש חדשות שפשוט אי אפשר להתעלם מהן והיה חשוב לנו להציף לכם אותן מיד.


🚨 דרמה בפרטיות: אינסטגרם ביטלה את ההצפנה מקצה לקצה (E2EE) בהודעות ה-Direct! 🚨


🔍 מה קרה?
החל מאתמול, ה-8 במאי 2026, פלטפורמת #Instagram הפסיקה רשמית את התמיכה בהצפנה מקצה לקצה בשיחות הפרטיות שלכם.


המשמעות המיידית:
* 🔓 הפרטיות בסכנה: חברת Meta יכולה כעת לגשת ולקרוא את כל תוכן הצ'אטים שלכם.


* 📥 גיבוי דחוף: מומלץ להוריד את כל נתוני השיחות שלכם עכשיו, אחרת המידע הישן עלול ללכת לאיבוד או להפוך לחשוף


* 📲 מעבר לפלטפורמות אחרות: ההמלצה המקצועית היא לעבור לשימוש ב-WhatsApp (שעדיין שומרת על הצפנה) או באפליקציות ייעודיות אחרות עבור שיחות רגישות.


📅 פורסם: 8 במאי 2026
📖 מקור לפרטים המלאים:
🔗 https://thehackernews.com/2026/03/meta-to-shut-down-instagram-end-to-end.html


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


הצטרפו לקבוצה לעדכוני סייבר וטכנולוגיה שוטפים! 🔥
👇
https://t.me/CyberSecurityCoding
7🔥1
🌟 היי לכולם! 🌟

אני מקווה שכולכם בסדר! 😊

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

אם יש לכם משהו בראש, אל תהססו לכתוב בתגובות! 👇

בואו נשתף רעיונות וניצור משהו מדהים ביחד! 🚀

מחכה לשמוע מכם! ❤️