Source Byte – Telegram
Source Byte
7.75K subscribers
846 photos
73 videos
678 files
1.68K links
هشیار کسی باید کز عشق بپرهیزد
وین طبع که من دارم با عقل نیامیزد
Saadi Shirazi 187
Download Telegram
Emulating inline decryption for triaging C++ malware
[ Blog ]

References
Glory Sprout string decryptor:
gsprout_string_decryption.py
Glory Sprout Hash resolver:
gsprout_api_resolver.py
GlorySprout sample:
Malwarebazaar
Insight from GlorySprout and Taurus Stelaer:
RussianPanda Research Blog
Let’s play (again) with Predator the thief
An In-Depth analysis of the new Taurus Stealer


#malware_analysis
👍42🤷‍♂1
Unauthenticated SSRF on Havoc C2 teamserver via spoofed demon agent
Credit : Evan Ikeda


https://blog.chebuya.com/posts/server-side-request-forgery-on-havoc-c2/
👾6👍1
Forwarded from Pwn3rzs
🤣30😁54
Forwarded from Iman
درود. من یک مطلب کوتاهی نوشتم برای درک پروسه‌ای که توی کرنل رخ می‌ده موقع Null-dereference (معماری x86) و مقداری در مورد Virtual Memory Management کرنل صحبت کردم. شاید برای بچه‌هایی که روی آسیب‌پذیری‌های سمت کرنل کار می‌کنن هم جالب باشه:
https://imanseyed.github.io/posts/the-flow-of-the-kernel-upon-receiving-a-sigsegv-for-null-dereferene/
🔥8👍3👏1
11 Strategies of a World-Class Cybersecurity Operations Center
by mitre

Strategy 1: Know What You Are Protecting and Why
Strategy 2: Give the SOC the Authority to Do Its Job
Strategy 3: Build a SOC Structure to Match Your Organizational Needs
Strategy 4: Hire AND Grow Quality Staff
Strategy 5: Prioritize Incident Response
Strategy 6: Illuminate Adversaries with Cyber Threat Intelligence
Strategy 7: Select and Collect the Right Data
Strategy 8: Leverage Tools to Support Analyst Workflow
Strategy 9: Communicate Clearly, Collaborate Often, Share Generously
Strategy 10: Measure Performance to Improve Performance
Strategy 11: Turn up the Volume by Expanding SOC Functionality
👍3👎3🔥1
Forwarded from Stuff for Geeks (rВНm)
👍32
Forwarded from APT
🖥 Introduction for to Windows kernel exploitation

Explore the Windows Kernel with HEVD, a vulnerable driver. Dive into stack overflow exploits and bypass SMEP/KPTI protections using the sysret approach.
A detailed guide for Windows kernel explotation:

Part 0: Where do I start?
Part 1: Will this driver ever crash?
Part 2: Is there a way to bypass kASLR, SMEP and KVA Shadow?
Part 3: Can we rop our way into triggering our shellcode?
Part 4: How do we write a shellcode to elevate privileges and gracefully return to userland?

#windows #kernel #driver #hevd #hacksys
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11👾41
Forwarded from Dark Knight
👍4
7👍5👎2👏1
Global Windows outage hits computers around the world. This is linked to Crowdstrike update that cripples boot process.
Supposedly deleting “C-00000291*.sys” file in C:\Windows\System32\drivers\CrowdStrike directory fixes the issue. But editing system files you always do on your own risk :)


Credit: Lukasz Olejnik

#CrowdStrike
2👍1👾1
I created a simple Group Policy (GPO) to automatically fix CrowdStrike BSOD (Blue screen of death) issue.

Credit : Arda Büyükkaya

https://gist.github.com/whichbuffer/7830c73711589dcf9e7a5217797ca617


How are you deploying this to BSOD'd boxes?


You can remotely apply the GPOs using tools like Group Policy Management Console (GPMC) from a server or another computer with administrative privileges. If remote access is not possible due to the BSOD, you may need to boot the affected systems using a Windows recovery environment or a bootable media, manually apply the noscripts to force Safe Mode, and then restart the systems to allow the GPOs to execute the fix. I haven't tested it across multiple affected devices yet, but theoretically, booting into Safe Mode by GPO and then deleting the problematic driver should work. The idea is based on standard troubleshooting steps that target specific faulty drivers causing the BSOD.


🔥3👍2
Forwarded from Source Chat (main one)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 🪄࿐. ݁₊ 🌸 Ame 🎀
😁5👍1
ClownStrike.zip
16.9 MB
😁13👍2
Forwarded from Infosec Fortress
Zhang Yunhai - BYPASS CONTROL FLOW GUARD COMPREHENSIVELY - Blackhat

#binary
#exploitation
———
🆔 @Infosec_Fortress
5👍3
Forwarded from Infosec Fortress
us-15-Zhang-Bypass-Control-Flow-Guard-Comprehensively-wp.pdf
425.2 KB
👍3👎1
Forwarded from An Inspired Engineer
کرنل چطور میدونه توی این لحظه کدوم پروسس روی یک هسته‌ی cpu در حال اجراست؟

کرنل تسک(پروسس)هایی که در حال اجرا هستن رو توی یک Linked List به صورت double به اسم task list نگهداری میکنه، ساختمون داده ای که این linked list نگهداری میکنه task_struct هست که نسبتا بزرگه و تمامی اطلاعاتی که کرنل نیاز داره تا بروی پروسس ها context switch انجام بده یا چه فایل هایی توسط این پروسس بازه، وضعیت پروسس چیه، فضای آدرس حافظه کجاست و ... رو توی خودش داره.

نکته:
هر پروسس توی فضای کرنل یک استک داره که کرنل اطلاعات مربوط به این پروسس، ادرس برگشت متد ها، متغیرهای محلی و... رو توش نگه‌میداره. و توی معماری x86 کرنل پوینتر ساختمون داده task_struct متعلق به هر پروسس رو توی انتهای استک همون پروسس میزاره، یعنی اگه از انتهای استک یک پروسس به عقب برگردیم به اطلاعات اون پروسس دسترسی داریم(البته که توی فضای کرنل).

خب حالا خود کرنل چطور به تسکی که الان در حال اجراست میرسه تا بتونه اصلا به task_struct دسترسی داشته باشه؟
همونطور که بالاتر گفتم لیست تسک ها توی یک linked list نگهداری میشن و برای اینکه بتونیم تسکی که در حال اجراست رو پیدا کنیم باید کل لیست رو بگردیم، شاید روی ماشین های خونگی به چشم نیاد ولی روی سرورهایی که چندین هزار پروسس میتونن داشته باشن O(n) هزینه‌ی بالایی محسوب میشه. راه حل؟ کرنل میاد برای اینکه تسک درحال اجرا رو پیدا کنه از ماکروی current استفاده میکنه که اون هم متد current_thread_info() رو کال میکنه. حالا با توجه به معماری یا ادرس این ساختمون داده روی یکی از رجیستر های cpu میزاره. یعنی دیگه نیازی نیست کل لیست رو بگردیم.

پیاده سازی این متد به معماری سخت افزار وابسته اس، برای مثال توی ماشین های power pc IBM رو اجرا میکنند کرنل این اطلاعات رو توی رجیستر r2 نگهداری میکنه و از طریق اسمبلی بهش دسترسی داره:

register struct task_struct *current asm ("r2");


حالا شاید بگین که اوکی ما دیگه چه نیازی به لیست داریم وقتی اطلاعات توی رجیستر وجود داره؟
در حقیقت لیست برای اینه که scheduler بدونه تسک بعدی متعلق به کیه و آیا باید اجرا بشه یا نه؟! اینجا برای انتخاب کردن تسک بعدی کرنل پارامترای اون پروسس رو چک میکنه که مهمترینشون state و priority هست، بعد از اینکه تسک بعدی انتخاب شد، اطلاعات تسک فعلی روی استک نوشته میشه و اطلاعات تسک بعدی روی رجیستر بارگیری میشه.

جمع بندی بخوام بکنم میشه:
- زمانی که پروسس جدید با fork یا clone ساخته میشه کرنل کپی task_struct از parent پروسس جدید هست رو توی task list که یک linked list گلوبال توی فضای کرنل هست اضافه میکنه.
- ماژول scheduler میاد و بر اساس اولویت و پارامتر های دیگه بین پروسس ها برای هر هسته‌ی cpu عملیات context-switching رو انجام میده ولی قبلش مقدار جای فعلی استک، رجیسترهای cpu و وضعیت پروسس رو توی task_struct ذخیره کنه و بعد از انتخاب عملیات context swithing رو انجام بده.
- کرنل باید پوینتر ماکروی current رو به روز کنه تا به task_struct تسک جدید اشاره کنه و این ماکرو از طریق رجیسترهای cpu با سرعت بالا به task_struct دسترسی پیدا میکنه.
- وضعیت تسک جدید توی رجیسترهای cpu و از استک بارگیری میشه.

پس جواب ما برای سوال: کرنل چطور میدونه توی این لحظه کدوم پروسس روی یک هسته‌ی cpu در حال اجراست؟ میشه اینکه کرنل اطلاعات رو توی یک لینک لیست نگهداری میکنه و پوینتر تسک فعلی رو هم برای اینکه O(n) هزینه نکنه از رجیستر میخونه.

منبع ۱
منبع ۲

@knowpow
👍65🤣2👏1🍾1