Forwarded from Source Byte
REMOTE WINDOWS CREDENTIAL DUMP WITH SHADOW SNAPSHOTS: EXPLOITATION AND DETECTION
https://labs.itresit.es/2025/06/11/remote-windows-credential-dump-with-shadow-snapshots-exploitation-and-detection/
https://labs.itresit.es/2025/06/11/remote-windows-credential-dump-with-shadow-snapshots-exploitation-and-detection/
❤1
Forwarded from Sec Note
❤1
UAFuzz: Binary-level Directed Fuzzing for Use-After-Free Vulnerabilities
https://github.com/strongcourage/uafuzz
@reverseengine
https://github.com/strongcourage/uafuzz
@reverseengine
GitHub
GitHub - strongcourage/uafuzz: UAFuzz: Binary-level Directed Fuzzing for Use-After-Free Vulnerabilities
UAFuzz: Binary-level Directed Fuzzing for Use-After-Free Vulnerabilities - strongcourage/uafuzz
❤1
Fuzzing the Windows API for AV Evasion
https://winternl.com/fuzzing-the-windows-api-for-av-evasion
@reverseengine
https://winternl.com/fuzzing-the-windows-api-for-av-evasion
@reverseengine
winternl
Fuzzing the Windows API for AV Evasion
Malware Detection Systems (MDSs) use a technique called emulation as perhaps their most effective weapon against novel malware threats. Emulation does not rely on the static structure or signature of…
❤1
Attack Secure Boot of SEP
https://github.com/windknown/presentations/raw/master/Attack_Secure_Boot_of_SEP.pdf
@reverseengine
https://github.com/windknown/presentations/raw/master/Attack_Secure_Boot_of_SEP.pdf
@reverseengine
❤1
Reverse-engineering and analysis of SanDisk High Endurance microSDXC card
https://ripitapart.com/2020/07/16/reverse-engineering-and-analysis-of-sandisk-high-endurance-microsdxc-card
@reverseengine
https://ripitapart.com/2020/07/16/reverse-engineering-and-analysis-of-sandisk-high-endurance-microsdxc-card
@reverseengine
Rip It Apart - Jason's electronics blog-thingy
Reverse-engineering and analysis of SanDisk High Endurance microSDXC card
As seen on Hackaday! TL;DR – The SanDisk High Endurance cards use SanDisk/Toshiba 3D TLC Flash. It took way, way more work than it should have to figure this out (thanks for nothing, SanDisk!…
❤2
Forwarded from ARVIN
Malware development trick 46: simple Windows keylogger. Simple C example
https://cocomelonc.github.io/malware/2025/05/01/malware-tricks-46.html
https://cocomelonc.github.io/malware/2025/05/01/malware-tricks-46.html
cocomelonc
Malware development trick 46: simple Windows keylogger. Simple C example.
﷽
❤1
Article: Removing Kernel Callbacks Using Signed Drivers
https://br-sn.github.io/Removing-Kernel-Callbacks-Using-Signed-Drivers
Code: Enumerating and removing kernel callbacks using signed vulnerable drivers
https://github.com/br-sn/CheekyBlinder
@reverseengine
https://br-sn.github.io/Removing-Kernel-Callbacks-Using-Signed-Drivers
Code: Enumerating and removing kernel callbacks using signed vulnerable drivers
https://github.com/br-sn/CheekyBlinder
@reverseengine
GitHub
GitHub - br-sn/CheekyBlinder: Enumerating and removing kernel callbacks using signed vulnerable drivers
Enumerating and removing kernel callbacks using signed vulnerable drivers - br-sn/CheekyBlinder
❤1
Reverse Engineering Starling Bank (Part I): Obfuscation Techniques https://hot3eed.github.io/2020/07/30/starling_p1_obfuscations.html
Reverse Engineering Starling Bank (Part II): Jailbreak & Debugger Detection, Weaknesses & Mitigations
https://hot3eed.github.io/2020/08/02/starling_p2_detections_mitigations.html
@reverseengine
Reverse Engineering Starling Bank (Part II): Jailbreak & Debugger Detection, Weaknesses & Mitigations
https://hot3eed.github.io/2020/08/02/starling_p2_detections_mitigations.html
@reverseengine
hot3eed.github.io
Reverse Engineering Starling Bank (Part I): Obfuscation Techniques
Reverse Engineering Starling Bank (Part I): Obfuscation Techniques 2020-07-30
❤1
A gentle introduction into ARM assembly
https://www.shadowinfosec.io/2018/05/a-gentle-introduction-into-arm-assembly.html
@reverseengine
https://www.shadowinfosec.io/2018/05/a-gentle-introduction-into-arm-assembly.html
@reverseengine
❤1
Memory Layout: Arrays, Structs, Pointers
مهمترین بخش برای Exploit, InfoLeak، ROP، UAF، heap overflow
آرایهها (Arrays) داخل حافظه چگونه ذخیره میشن؟
آرایه همیشه contiguous پشت سر هم داخل استک یا هیپ ذخیره میشه
مثال:
داخل حافظه:
نکته Exploit:
اگر بافر آرایه باشه اورفلو مستقیم وارد متغیر های محلی RBP Return Address میشه
Memory Layout: Arrays, Structs, Pointers
The most important part for Exploit, InfoLeak, ROP, UAF, heap overflow
How are Arrays stored in memory?
Arrays are always stored contiguously in the stack or heap
Example:
In memory:
Exploit Tip:
If the buffer is an array, the overflow goes directly into the local variables RBP Return Address
@reverseengine
مهمترین بخش برای Exploit, InfoLeak، ROP، UAF، heap overflow
آرایهها (Arrays) داخل حافظه چگونه ذخیره میشن؟
آرایه همیشه contiguous پشت سر هم داخل استک یا هیپ ذخیره میشه
مثال:
int a[5] = {1,2,3,4,5};
داخل حافظه:
a[0] → offset 0
a[1] → offset 4
a[2] → offset 8
a[3] → offset 12
a[4] → offset 16
نکته Exploit:
اگر بافر آرایه باشه اورفلو مستقیم وارد متغیر های محلی RBP Return Address میشه
Memory Layout: Arrays, Structs, Pointers
The most important part for Exploit, InfoLeak, ROP, UAF, heap overflow
How are Arrays stored in memory?
Arrays are always stored contiguously in the stack or heap
Example:
int a[5] = {1,2,3,4,5};
In memory:
a[0] → offset 0
a[1] → offset 4
a[2] → offset 8
a[3] → offset 12
a[4] → offset 16
Exploit Tip:
If the buffer is an array, the overflow goes directly into the local variables RBP Return Address
@reverseengine
❤1
پاکسازی ردپای سیستم فایلی FileSystem Artifacts
FileSystem Artifact
هرچی میسازید باز میکنید Extract میکنید حتی فقط لمس میکنید روی NTFS یه اثر میذاره
ردپای سیستم فایل دقیقا همین اثرات رو داره:
یعنی حتی اگه فایلتوتو پاک کنید باز از این طرف و اون طرف لو میرید
رایج ترین ردپاهایی که معمولا جا میمونن
MFT Entries
هر فایلی که ساخته کپی Extract بشه
تو Master File Table رکوردش میمونه
USN Journal
تقریبا قابل حذف نیست و همه تغییرات فایل رو log مینه
Zone.Identifier
وقتی فایلی از اینترنت میاد حتی از ابزار خودتون ویندوز میگه این از اینترنت اومده روش Alternate Data Stream میزاره
گاهی ابزارا config یا متادیتا رو تو ADS ذخیره میکنن
Prefetch
هر فایل اجرایی که اجرا شد یه PF ساخت میشه
Jump Lists Recent Items
وقتی یه فایل باز یا اجرا میشه اینجا لیست میشه
Thumbnail Cache
اگه فایل تصویری باز شده باشه preview ش ذخیره میشه
Temp / Roaming / LocalLow
ابزا را هزار جور اثر ریز تو مسیر های جانبی میذارن
هیچ روش مخربی توضیح نمیدم فقط اصول حرفهای و پاک
فایلی که نمیخواید اثر بذاره اصلا روی دیسک نسازید
تا میتونید memory-only کار کنید
Extract نکنید مگر مجبور باشید
بیشترین ردپا ها از همینه:
zip → Extract → اجرا → حذف →
پایان
اما ردپاها باقی
Prefetch-aware رفتار کنه
اجرای فایل های با اسم random، Prefetch لو بره سناریو های قانون باید بدونید چیزی که اجرا میکنید اثر long-term میذاره
Zone.Identifier رو چک کنید
اگه فایلی رو جا به جا میکنی باید بدونید ویندوز حتی منبع اینترنتی رو علامت گذاری میکنه
Temp رو حواست باشه
کلی ابزار خودشون فایل temp درست میکنن بدون اینکه شما بفهمید
تغییرات جانبی مثل Thumbnail و JumpList رو پیشبینی کنید
چیزی که Preview میزنید یا Open میکنید احتمالا Thumbnail میسازه
File System Artifacts Cleanup
FileSystem Artifact
Everything you create, open, extract, even just touch leaves an impact on NTFS
File system footprints have exactly the same effects:
That is, even if you delete your file, it will still be visible from here and there
The most common footprints that are usually left
MFT Entries
Every file that is created, copied, extracted
Its record is left in the Master File Table
USN Journal
It is almost impossible to delete and does not log all file changes
Zone.Identifier
When a file comes from the Internet, even from your own tool, Windows says that it came from the Internet, it uses the Alternate Data Stream method
Sometimes tools store config or metadata in ADS
Prefetch
Every file The executable that is run will create a PF
Jump Lists Recent Items
When a file is opened or executed, it will be listed here
Thumbnail Cache
If an image file is opened, its preview will be saved
Temp / Roaming / LocalLow
Tools leave a thousand kinds of small traces in side paths
I will not explain any destructive methods, just professional and clean principles
Do not create a file that you do not want to affect on the disk at all
So that you can work memory-only
Do not extract unless you have to
Most traces are like this:
zip → Extract → Run → Delete →
End
But traces remain
Behave Prefetch-aware
Executing files with random names, Prefetch will be leaked
Legal scenarios, you should know that what you are executing has a long-term effect
Check Zone.Identifier
If you move a file, you should know that Windows even marks the Internet resource
Watch Temp
All tools They create temp files without you knowing
Anticipate side effects like Thumbnails and JumpLists
Anything you Preview or Open will probably create a Thumbnail
@reverseengine
FileSystem Artifact
هرچی میسازید باز میکنید Extract میکنید حتی فقط لمس میکنید روی NTFS یه اثر میذاره
ردپای سیستم فایل دقیقا همین اثرات رو داره:
MFT Records
USN Journal
Zone.Identifier
ADS Alternate Data Streams
Prefetch
Recent Files
Jump Lists
ShellBags
Thumbnails
یعنی حتی اگه فایلتوتو پاک کنید باز از این طرف و اون طرف لو میرید
رایج ترین ردپاهایی که معمولا جا میمونن
MFT Entries
هر فایلی که ساخته کپی Extract بشه
تو Master File Table رکوردش میمونه
USN Journal
تقریبا قابل حذف نیست و همه تغییرات فایل رو log مینه
Zone.Identifier
وقتی فایلی از اینترنت میاد حتی از ابزار خودتون ویندوز میگه این از اینترنت اومده روش Alternate Data Stream میزاره
گاهی ابزارا config یا متادیتا رو تو ADS ذخیره میکنن
Prefetch
هر فایل اجرایی که اجرا شد یه PF ساخت میشه
Jump Lists Recent Items
وقتی یه فایل باز یا اجرا میشه اینجا لیست میشه
Thumbnail Cache
اگه فایل تصویری باز شده باشه preview ش ذخیره میشه
Temp / Roaming / LocalLow
ابزا را هزار جور اثر ریز تو مسیر های جانبی میذارن
هیچ روش مخربی توضیح نمیدم فقط اصول حرفهای و پاک
فایلی که نمیخواید اثر بذاره اصلا روی دیسک نسازید
تا میتونید memory-only کار کنید
Extract نکنید مگر مجبور باشید
بیشترین ردپا ها از همینه:
zip → Extract → اجرا → حذف →
پایان
اما ردپاها باقی
Prefetch-aware رفتار کنه
اجرای فایل های با اسم random، Prefetch لو بره سناریو های قانون باید بدونید چیزی که اجرا میکنید اثر long-term میذاره
Zone.Identifier رو چک کنید
اگه فایلی رو جا به جا میکنی باید بدونید ویندوز حتی منبع اینترنتی رو علامت گذاری میکنه
Temp رو حواست باشه
کلی ابزار خودشون فایل temp درست میکنن بدون اینکه شما بفهمید
تغییرات جانبی مثل Thumbnail و JumpList رو پیشبینی کنید
چیزی که Preview میزنید یا Open میکنید احتمالا Thumbnail میسازه
File System Artifacts Cleanup
FileSystem Artifact
Everything you create, open, extract, even just touch leaves an impact on NTFS
File system footprints have exactly the same effects:
MFT Records
USN Journal
Zone.Identifier
ADS Alternate Data Streams
Prefetch
Recent Files
Jump Lists
ShellBags
Thumbnails
That is, even if you delete your file, it will still be visible from here and there
The most common footprints that are usually left
MFT Entries
Every file that is created, copied, extracted
Its record is left in the Master File Table
USN Journal
It is almost impossible to delete and does not log all file changes
Zone.Identifier
When a file comes from the Internet, even from your own tool, Windows says that it came from the Internet, it uses the Alternate Data Stream method
Sometimes tools store config or metadata in ADS
Prefetch
Every file The executable that is run will create a PF
Jump Lists Recent Items
When a file is opened or executed, it will be listed here
Thumbnail Cache
If an image file is opened, its preview will be saved
Temp / Roaming / LocalLow
Tools leave a thousand kinds of small traces in side paths
I will not explain any destructive methods, just professional and clean principles
Do not create a file that you do not want to affect on the disk at all
So that you can work memory-only
Do not extract unless you have to
Most traces are like this:
zip → Extract → Run → Delete →
End
But traces remain
Behave Prefetch-aware
Executing files with random names, Prefetch will be leaked
Legal scenarios, you should know that what you are executing has a long-term effect
Check Zone.Identifier
If you move a file, you should know that Windows even marks the Internet resource
Watch Temp
All tools They create temp files without you knowing
Anticipate side effects like Thumbnails and JumpLists
Anything you Preview or Open will probably create a Thumbnail
@reverseengine
❤1
The core of Apple is PPL (Apple's Page Protection Layer): Breaking the XNU kernel's kernel
https://googleprojectzero.blogspot.com/2020/07/the-core-of-apple-is-ppl-breaking-xnu.html
@reverseengine
https://googleprojectzero.blogspot.com/2020/07/the-core-of-apple-is-ppl-breaking-xnu.html
@reverseengine
Blogspot
The core of Apple is PPL: Breaking the XNU kernel's kernel
Posted by Brandon Azad, Project Zero While doing research for the one-byte exploit technique , I considered several ways it might be poss...
❤1
One Byte to rule them all - The new iOS kernel exploitation technique that turns a one-byte controlled heap overflow directly into a read/write primitive
https://googleprojectzero.blogspot.com/2020/07/one-byte-to-rule-them-all.html
@reverseengine
https://googleprojectzero.blogspot.com/2020/07/one-byte-to-rule-them-all.html
@reverseengine
Blogspot
One Byte to rule them all
Posted by Brandon Azad, Project Zero One Byte to rule them all, One Byte to type them, One Byte to map them all, and in userspace bind...
❤1
Forwarded from GO-TO CVE
CVE-2024-29291-week-80.pdf
213.2 KB
با عرض سلام خوش اومدین به هفته 80 از تحلیل CVE ها با برنامه GO-TO CVE این هفته به برسی اسیب پذیری جالبی رو لاراول ورژن 8 تا 11 میپردازیم
🔹CVE : CVE‑2024‑29291
🔹Target: Laravel Framework (Versions 8 – 11)
🔹Type: Credential Exposure / Configuration Analysis (CA)
🔹week : 80
#week_80
🔹CVE : CVE‑2024‑29291
🔹Target: Laravel Framework (Versions 8 – 11)
🔹Type: Credential Exposure / Configuration Analysis (CA)
🔹week : 80
#week_80
❤4
Pointer Arithmetic
مهمترین نکته برای Exploit:
پس:
و:
یعنی:
نه 1 بایت 8 بایت
همین موضوع برای باگ های زیر مهمه:
Pointer Arithmetic
The most important thing for Exploit:
So:
And:
That is:
Not 1 byte, 8 bytes
The same thing is important for the following bugs:
@reverseengine
مهمترین نکته برای Exploit:
a + i
آدرس a + i * sizeof(type)
پس:
double arr[10];
و:
arr + 1
یعنی:
arr + (1 * 8)
نه 1 بایت 8 بایت
همین موضوع برای باگ های زیر مهمه:
Out-of-bounds read/write
Heap corruption
InfoLeak
Pointer Arithmetic
The most important thing for Exploit:
a + i Address a + i * sizeof(type)
So:
double arr[10];
And:
arr + 1
That is:
arr + (1 * 8)
Not 1 byte, 8 bytes
The same thing is important for the following bugs:
Out-of-bounds read/write
Heap corruption
InfoLeak
@reverseengine
❤1