API Unhooking: EDR সিস্টেমের নজরদারি এড়িয়ে ম্যালওয়্যার যেভাবে কাজ করে!

প্রথমে বোঝা প্রয়োজন EDR কীভাবে কাজ করে। যখন একটি malicious code execute হয়, এটি সাধারণত Windows API call করে—যেমন VirtualAlloc দিয়ে memory allocate, WriteProcessMemory দিয়ে অন্য process-এ code inject, বা CreateRemoteThread দিয়ে remote execution। EDR এই critical API-গুলোকে hook করে রাখে, অর্থাৎ ntdll.dll-এর API function-এর শুরুতে একটি JMP instruction insert করে যা EDR-এর own analysis routine-এ redirect করে।

এই hooking সাধারণত user-mode-এ হয়, kernel-mode-এ নয়। Microsoft-এর PatchGuard kernel-এ third-party hooking restrict করায় EDR vendor-রা মূলত user-mode hooking-এর উপর নির্ভরশীল। যখন একটি process load হয়, EDR-এর DLL সেই process-এ inject হয় (সাধারণত AppInit_DLLs বা SetWindowsHookEx-এর মাধ্যমে নয়, বরং minifilter বা PsSetCreateProcessNotifyRoutine-এর মাধ্যমে kernel থেকে trigger হয়ে)। এই DLL ntdll.dll-এর function-গুলো overwrite করে।

Ntdll.dll-কে target করার কারণ হলো প্রায় সব Windows API শেষপর্যন্ত ntdll.dll-এর Nt* বা Zw* prefix-যুক্ত syscall-এ catch করে। উদাহরণস্বরূপ, kernel32.dll-এর VirtualAlloc কল করে ntdll.dll-এর NtAllocateVirtualMemory, যা শেষপর্যন্ত kernel-এ syscall করে। ntdll.dll-এর function hook করলে এক জায়গা থেকেই হাজার হাজার higher-level API monitor করা যায়।

API Unhooking-এর সরল ধারণা হলো EDR-এর inject করা hook সরিয়ে fresh, clean ntdll.dll function restore করা। যেহেতু ntdll.dll একটি static file disk-এ সংরক্ষিত, এবং তার content কখনো পরিবর্তিত হয় না (digital signature দিয়ে validated), attacker disk থেকে original byte পড়ে in-memory copy-এর hooked bytes overwrite করতে পারেন।

এই process কয়েক ধাপে সম্পন্ন হয়। প্রথমে disk থেকে ntdll.dll-এর একটি fresh copy load করা হয়—সাধারণত CreateFileW এবং ReadFile দিয়ে। অথবা আরও chwild পদ্ধতিতে, একটি new section তৈরি করে NtCreateSection দিয়ে এবং সেখান থেকে map করে।

দ্বিতীয় ধাপে in-memory ntdll.dll-এর .text section-এর address খুঁজে বের করা হয়। PE header parse করে section header থেকে এই information পাওয়া যায়। .text section হলো executable code section যেখানে API function-গুলো থাকে।

তৃতীয় ধাপে memory protection পরিবর্তন করা হয়। .text section সাধারণত PAGE_EXECUTE_READ, write permission নেই। VirtualProtect কল করে এটিকে PAGE_EXECUTE_READWRITE করা হয়। তারপর disk থেকে পড়া fresh bytes দিয়ে in-memory copy overwrite করা হয়। শেষে memory protection original-এ restore করা হয়।

সবচেয়ে straightforward unhooking method হলো ntdll.dll directly disk থেকে read করা। কোডের একটি simplified flow:

HANDLE hFile = CreateFileW(L"C:\\Windows\\System32\\ntdll.dll", 
                           GENERIC_READ, FILE_SHARE_READ, NULL, 
                           OPEN_EXISTING, 0, NULL);
HANDLE hMapping = CreateFileMappingW(hFile, NULL, PAGE_READONLY | SEC_IMAGE, 0, 0, NULL);
LPVOID pMapping = MapViewOfFile(hMapping, FILE_MAP_READ, 0, 0, 0);

এর পর in-memory ntdll.dll-এর base address GetModuleHandle("ntdll.dll") দিয়ে পাওয়া হয়। দুটি PE structure parse করে .text section locate করা হয়। তারপর memcpy দিয়ে content copy করা হয়।

এই পদ্ধতির সরলতা হলো এর সবচেয়ে বড় শক্তি এবং দুর্বলতা। সরল মানে quick implementation, কিন্তু EDR-এর জন্যও detection সহজ। CreateFileW দিয়ে ntdll.dll open করা একটি unusual behavior—সাধারণ process এটা করে না।

Hell's Gate—am0nsec এবং RtlMateusz-এর তৈরি—একটি আরও sophisticated approach। এটি ntdll.dll-এর function থেকে directly syscall number extract করে এবং পরবর্তীতে নিজের assembly-এর মাধ্যমে syscall execute করে। যেহেতু এই syscall ntdll.dll-এর hooked function bypass করে, EDR কোনো monitoring trigger পায় না।

প্রতিটি Nt* function-এর শুরুতে কয়েকটি standard instruction থাকে যা syscall number set করে এবং তারপর syscall instruction execute করে। সাধারণ pattern:

mov r10, rcx
mov eax, <syscall_number>
syscall
ret

Hell's Gate এই pattern parse করে syscall number বের করে। তবে যদি function hooked থাকে, প্রথম bytes JMP instruction হয়ে যায়, এবং syscall number invisible। এই সমস্যা সমাধানে এসেছে Halo's Gate। এটি adjacent function-গুলো check করে—সাধারণত syscall number sequential হয় (NtAllocateVirtualMemory-এর number 0x18 হলে NtFreeVirtualMemory হবে 0x1E বা কাছাকাছি)। তাই unhooked neighbor function থেকে base বের করে target function-এর number calculate করা সম্ভব।

Tartarus' Gate এই concept-কে আরও এগিয়ে নিয়েছে—এটি multiple hooking pattern handle করে এবং fallback mechanism প্রদান করে।

Perun's Fart একটি creative technique যেখানে একটি new process suspended state-এ create করা হয়। এই suspended process-এ EDR-এর DLL এখনো inject হয়নি, তাই ntdll.dll clean থাকে। তারপর parent process এই suspended child-এর memory থেকে clean ntdll.dll read করে নিজের memory-তে copy করে।

এই পদ্ধতির সৌন্দর্য হলো disk থেকে file read করতে হয় না, যা suspicious file access pattern এড়ায়। কিন্তু সমস্যা হলো process creation নিজেও monitored। আধুনিক EDR child process creation-এ early hook inject করে, ফলে এই technique-এর effectiveness limited।

আরেকটি বৈচিত্র্য হলো NtCreateSection দিয়ে ntdll.dll-এর জন্য একটি new section তৈরি করা এবং সেখান থেকে clean copy পাওয়া। এই পদ্ধতি file system API call এড়ায় কিন্তু section creation নিজেই EDR-এর radar-এ আসতে পারে।

API Unhooking-এর একটি বিকল্প পথ হলো ntdll.dll-এর function call না করেই syscall execute করা। Direct Syscall-এ attacker নিজের assembly code লেখেন যা syscall number set করে এবং syscall instruction execute করে। এই approach completely bypass করে user-mode hook।

mov r10, rcx
mov eax, 0x18  ; NtAllocateVirtualMemory
syscall
ret

তবে modern EDR এই pattern detect করতে পারে। তারা check করে syscall instruction-এর address কোথা থেকে আসছে। যদি syscall instruction ntdll.dll-এর .text section-এ না থাকে—বরং attacker-এর own code section-এ—এটি একটি strong indicator।

এর সমাধানে এসেছে Indirect Syscall। এখানে attacker syscall number set করেন কিন্তু syscall instruction-এর জন্য ntdll.dll-এর একটি valid syscall; ret gadget-এ JMP করেন। ফলে instruction pointer ntdll.dll-এর মধ্যেই থাকে, EDR-এর check pass হয়।

SysWhispers এবং SysWhispers2 (jthuraisamy-এর তৈরি) এই concept-কে automated করেছে। তারা syscall number resolve, direct/indirect syscall generation, এবং Windows version-specific handling সবই handle করে।

EDR vendor-রা API Unhooking-এর বিরুদ্ধে বিভিন্ন countermeasure develop করেছেন। প্রথমত, hook integrity monitoring—EDR periodically নিজের hook check করে যে তারা intact আছে কিনা। যদি unhooking detect হয়, alert তৈরি হয় এবং re-hooking চেষ্টা করা হয়।

দ্বিতীয়ত, kernel-mode monitoring বৃদ্ধি। Microsoft-এর introduced ETW (Event Tracing for Windows) Ti (Threat Intelligence), kCFG (Kernel Control Flow Guard), এবং HVCI (Hypervisor-Protected Code Integrity)-এর মাধ্যমে kernel থেকে আরও deep visibility পাওয়া যাচ্ছে।

তৃতীয়ত, syscall monitoring at kernel level। PsSetLoadImageNotifyRoutine, ObRegisterCallbacks, এবং minifilter ব্যবহার করে EDR file system, registry, এবং process activity monitor করে user-mode hook-এর বাইরে।

চতুর্থত, behavioral এবং machine learning-based detection। শুধু individual API call নয়, পুরো behavior chain analyze করা হয়। API unhooking-এর জন্য typically যে sequence-এ events ঘটে—file read of ntdll.dll, VirtualProtect on system DLL memory, memcpy-like pattern—এই combination flag হয়।

পঞ্চমত, Code Integrity Guard (CIG) এবং Arbitrary Code Guard (ACG)। এসব Windows Defender Exploit Guard feature কিছু process-কে restrict করে যাতে তারা memory write করতে না পারে এমন region-এ যা executable।

Cobalt Strike-এর মতো commercial command-and-control framework API unhooking-কে standard feature হিসেবে অন্তর্ভুক্ত করেছে। অনেক Aggressor Script এবং BOF (Beacon Object File) hooked ntdll.dll detect এবং unhook করতে পারে।

APT41 এবং Lazarus group-এর মতো sophisticated threat actor-রা custom unhooking technique ব্যবহার করেন। তাদের malware অনেক সময় Hell's Gate-এর variant ব্যবহার করে এবং targeted EDR vendor-এর specific behavior বুঝে evasion implement করে।

Brute Ratel C4 এবং Sliver-এর মতো modern offensive framework আরও advanced unhooking implementation প্রদান করে। তাদের modular architecture-এ unhooking technique runtime-এ select করা যায় detected EDR-এর উপর নির্ভর করে।

Defender হিসেবে API Unhooking detect করার জন্য কয়েকটি strategy কার্যকর। প্রথমত, periodic integrity check—EDR-এর hook intact আছে কিনা continuously verify করা। দ্বিতীয়ত, suspicious memory access pattern monitor করা—বিশেষ করে ntdll.dll-এর .text section-এ write attempt।

তৃতীয়ত, syscall location verification। ETW provider যেমন Microsoft-Windows-Threat-Intelligence syscall-এর origin track করতে পারে। Non-ntdll origin থেকে syscall একটি strong red flag।

চতুর্থত, kernel-mode telemetry-তে বিনিয়োগ। Sysmon-এর ProcessCreate, FileCreate, এবং ImageLoad event সঠিকভাবে configure করা; advanced configurations যেমন SwiftOnSecurity-এর Sysmon config একটি ভালো starting point।