چگونه تیم SOC حمله Brute Force را با Splunk شناسایی می‌کند؟

 ساعت ۹:۱۲ صبح، چند تلاش برای ورود از راه دور به یکی از سرورهای ویندوزی شرکت ناموفق می‌ماند. دو دقیقه بعد، همان حساب کاربری از همان آدرس شبکه وارد سرور می‌شود. آیا کاربر پس از چند بار اشتباه، رمز درست را وارد کرده یا کسی توانسته رمز حساب را حدس بزند؟

این همان سؤالی است که تیم مرکز عملیات امنیت یا SOC، یعنی تیمی که فعالیت‌های مشکوک را بررسی می‌کند، باید به آن پاسخ دهد. در این مقاله، تشخیص حمله Brute Force با Splunk را با همین مثال دنبال می‌کنیم. ابتدا می‌بینیم چه چیزی توجه تیم را جلب می‌کند و بعد بررسی می‌کنیم چه شواهدی می‌تواند به تشخیص علت کمک کند.

حمله Brute Force چیست و در گزارش‌های ورود چگونه دیده می‌شود؟

تصور کنید کسی بخواهد وارد حساب کاربری شما شود و رمز آن را نداند. اگر برای پیدا کردن رمز، چند گزینه را پشت سر هم امتحان کند، با یکی از شکل‌های حملهBrute Force  روبه‌رو هستیم که به آن حدس‌زدن رمز عبور یا Password Guessing  می‌گویند. هر تلاش می‌تواند در گزارش امنیتی سیستم ثبت شود. اگر یکی از رمزها درست باشد، ممکن است پس از چند تلاش ناموفق، یک ورود موفق هم در گزارش دیده شود.

همین الگو ممکن است در یک روز عادی هم دیده شود. برای مثال، کاربری که تازه رمز خود را عوض کرده، ممکن است چند بار رمز قبلی را وارد کند و بعد با رمز جدید وارد شود. هر دو حالت در نگاه اول شبیه هم هستند. برای همین، تیم امنیت چند تلاش ناموفق و یک ورود موفق را دلیلی برای بررسی بیشتر در نظر می‌گیرد.

مجموعه ویدیوی آموزش ضوابط SOC 2: خروجی‌های کامل و دقیق

تشخیص حمله Brute Force با Splunk چگونه انجام می‌شود؟

Splunk  ابزاری است که تیم امنیت می‌تواند با آن گزارش‌های ثبت‌شده در سیستم‌های مختلف را جست‌وجو کند و رویدادهای مرتبط را کنار هم ببیند. مثلاً اگر تیم امنیت بخواهد بداند پیش از ورود به یک سرور چه اتفاقی افتاده، می‌تواند ورودهای موفق و ناموفق ویندوز را بر اساس زمان، حساب کاربری، آدرس شبکه و سرور مقصد مرتب کند. در مثال فرضی ما، گزارش ساده‌شده ورودها به این شکل است:

زمان	حساب کاربری	سرور مقصد	آدرس شبکه مبدأ	نتیجه
۹:۱۲ تا ۹:۱۳	analyst01	RDS-01	192.0.2.25	۶ تلاش ناموفق
۹:۱۴	analyst01	RDS-01	192.0.2.25	۱ ورود موفق

در ویندوز، رویداد 4625 نشان می‌دهد تلاش ورود ناموفق بوده و رویداد 4624 نشان می‌دهد یک نشست ورود ایجاد شده است. در این مثال،Splunk  کمک می‌کند ببینیم شش شکست در فاصله کوتاهی پیش از ورود موفق رخ داده‌اند و حساب، آدرس مبدأ و سرور مقصد در هر دو ردیف یکسان‌اند. اگر تیم امنیت جست‌وجویی تنظیم کرده باشد که پس از پنج شکست در پنج دقیقه به دنبال ورود موفق بگردد، این مورد در نتیجه ظاهر می‌شود. عدد پنج در این مثال برای نمایش روش کار انتخاب شده و تیم می‌تواند آن را بر اساس الگوی معمول ورودها تنظیم کند.

بیشتر بخوانید: سناریوی عملی تشخیص Brute Force در SOC

تیم SOC در تشخیص حمله Brute Force با Splunk و بعد از مشاهده هشدار چه چیزهایی را بررسی می‌کند؟

اول، دلیل ورودهای ناموفق را بررسی می‌کند. گزارش ویندوز می‌تواند نشان دهد رمز اشتباه بوده یا نام کاربری اصلاً وجود نداشته است. تیم امنیت همچنین بررسی می‌کند که حساب متعلق به چه کسی است و آیا او معمولاً به این سرور وارد می‌شود. اگر کاربر بگوید همان موقع رمز قبلی را چند بار وارد کرده و گزارش‌ها هم با توضیح او هم‌خوانی داشته باشند، احتمال خطای عادی بیشتر می‌شود.

بعد، مشخص می‌کند اتصال از کجا آمده است. آدرس شبکه یا IP یک سرنخ است. ممکن است چند نفر از یک آدرس مشترک، مثلاً از طریق سامانه دسترسی از راه دور شرکت، وارد شوند. تحلیلگر می‌تواند زمان ورود و اطلاعات ثبت‌شده در آن سامانه را با گزارش ویندوز مقایسه کند تا مشخص شود کدام اتصال با ورود مشکوک هم‌زمان بوده است.

در پایان، فعالیت‌های پس از ورود را می‌بیند. آیا حساب پس از ورود همان کار همیشگی را انجام داده یا فعالیتی دیده شده که با وظیفه‌اش هم‌خوانی ندارد؟ برای مثال، اجرای برنامه‌ای غیرمعمول روی یک سرور حساس می‌تواند بررسی بیشتری بخواهد. اگر کاربر ورود را تأیید نکند و شواهد دیگری هم از فعالیت غیرعادی وجود داشته باشد، تحلیلگر می‌تواند زمان‌بندی رویدادها و شواهد را برای پیگیری به تیم پاسخ به رخداد منتقل کند.

اگر هیچ ورودی موفق نشود چه اتفاقی می‌افتد؟

گاهی همه تلاش‌های مهاجم شکست می‌خورند. برای پیدا کردن این موارد، تیم امنیت می‌تواند تکرار ورودهای ناموفق را جداگانه زیر نظر بگیرد. گاهی هم الگو برعکس مثال ماست. از یک مبدأ، روی تعداد زیادی حساب فقط یکی دو تلاش ناموفق دیده می‌شود. این حالت می‌تواند نشانه Password Spraying باشد، یعنی کسی یک یا چند رمز رایج را روی چندین حساب امتحان می‌کند. در این حالت، شمارش تعداد حساب‌های هدف از یک مبدأ می‌تواند سرنخی بدهد که با بررسی هر حساب به‌تنهایی دیده نمی‌شود.

Splunk کمک می‌کند تلاش‌های ناموفق و ورود موفق بعد از آن را در یک خط زمانی ببینیم. در مثال مقاله، شش شکست و یک موفقیت برای یک حساب، تیم امنیت را به بررسی بیشتر هدایت کرد. تصمیم نهایی به پاسخ سه سؤال بستگی دارد. چرا ورودها شکست خوردند؟ اتصال از کجا آمد؟ بعد از ورود چه فعالیتی ثبت شد؟ پاسخ این سؤال‌ها به تیم کمک می‌کند خطای عادی کاربر را از رخدادی که نیاز به پیگیری دارد جدا کند.

بیشتر بخوانید: نمونه تشخیص ورود مشکوک با SPL

نمونه عملی برای کارشناسان Splunk

اگر به محیط Splunk دسترسی دارید، می‌توانید سناریوی بالا را با SPL، زبان جست‌وجوی Splunk، بررسی کنید. نمونه زیر برای لاگ‌های امنیتی ویندوز با قالب XML و ورود از راه دور با Remote Desktop نوشته شده است. در این نمونه، مقدار ۱۰ در فیلد LogonType نوع ورود را مشخص می‌کند. پیش از اجرا، نام ایندکس و فیلدهایی مانند TargetUserName، IpAddress  و Computer را با داده‌های محیط خود تطبیق دهید. در محیطی با جمع‌آورنده مرکزی، مطمئن شوید فیلد Computer نام سروری را دارد که رویداد را ثبت کرده است.

index=wineventlog (source=”XmlWinEventLog:Security” OR sourcetype=”XmlWinEventLog:Security”) (EventCode=4624 OR EventCode=4625)

| eval event_id=tonumber(EventCode), account=lower(TargetUserName),

       realm=lower(TargetDomainName), src=lower(IpAddress),

       dest=lower(Computer), logon_type=tonumber(LogonType)

| eval src=replace(src, “^::ffff:”, “”)

| where logon_type=10 AND isnotnull(account) AND account!=”” AND account!=”-“

    AND isnotnull(realm) AND realm!=”” AND realm!=”-“

    AND isnotnull(src) AND src!=”” AND src!=”-“

    AND isnotnull(dest) AND dest!=”” AND dest!=”-“

| eval failed=if(event_id=4625, 1, 0)

| sort 0 _time, event_id

| streamstats time_window=5m sum(failed) AS failures_5m BY realm account src dest

| where event_id=4624 AND failures_5m>=5

| table _time realm account src dest logon_type failures_5m

جست‌وجو برای هر حساب، آدرس مبدأ و سرور مقصد، تعداد شکست‌ها را در پنج دقیقه پیش از ورود موفق محاسبه می‌کند. دامنه حساب هم در مقایسه لحاظ می‌شود تا حساب‌های هم‌نام با هم ترکیب نشوند. در مثال مقاله، نتیجه یک ردیف با مقدار ۶ در ستون failures_5m است. ابتدا نمونه را روی بازه‌ای کوتاه، مثلاً ۳۰ دقیقه، بررسی کنید. اگر آن را به هشدار زمان‌بندی‌شده تبدیل می‌کنید، برای پنج دقیقه سابقه و تأخیر دریافت لاگ در بازه ورودی جا بگذارید و نتیجه‌های تکراری را با شناسه رویداد موفق و نام سرور کنترل کنید.

این نمونه فقط ورود از راه دور را بررسی می‌کند و ردیف‌هایی را که اطلاعات حساب، دامنه، مبدأ یا مقصد در آن‌ها کامل نیست، کنار می‌گذارد. اگر چند رویداد زمان یکسانی داشته باشند، جست‌وجو ورود موفق را پیش از شکست‌های همان زمان می‌چیند تا آن شکست‌ها را به‌عنوان تلاش قبلی نشمارد. اگر یک حساب از چند آدرس هدف قرار می‌گیرد، آن الگو را جداگانه با شمارش آدرس‌های متفاوت برای هر حساب بررسی کنید.