Leaderboard

Am publicat informatiile necesare (aproape complet) pe site: https://rstcon.com/ Asteptam: 1. Propuneri pentru prezentari (Call for Papers) 2. Donatii pentru premiile concursului CTF 3. Exercitii pentru concursul CTF Daca ne poate ajuta cineva, astept un mesaj privat sau un email la contact@rstcon.com

Practic cu secure boot adio bootkits https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot Enable/disable https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/disabling-secure-boot?view=windows-11 Verifica si informatiile manufacturierului.

Events: Linkedin: https://www.linkedin.com/events/rstcon-26894664423269556224/about/ Facebook: https://www.facebook.com/events/312925840851762/ Inregistrare (Zoom): - Prima zi (17 martie): https://us02web.zoom.us/webinar/register/7716432416217/WN_ihd6n-QbT9SmhUFEEiOouw - A doua zi (18 martie): https://us02web.zoom.us/webinar/register/8216433285169/WN_FvmdS_d2SJSo-OJpFaNRMA

Introduction RefleXXion is a utility designed to aid in bypassing user-mode hooks utilised by AV/EPP/EDR etc. In order to bypass the user-mode hooks, it first collects the syscall numbers of the NtOpenFile, NtCreateSection, NtOpenSection and NtMapViewOfSection found in the LdrpThunkSignature array. After that, there are two techniques that the user can choose to bypass the user-mode hooks. Technique-1, reads the NTDLL as a file from C:\Windows\System32\ntdll.dll. After parsing, the .TEXT section of the already loaded NTDLL (where the hooks are performed) in memory is replaced with the .TEXT section of the clean NTDLL. In Technique-2, NTDLL reads as Section from KnownDlls, \KnownDlls\ntdll.dll. (beacuse DLL files are cached in KnownDlls as Section.) After parsing, the .TEXT section of the already loaded NTDLL (where the hooks are performed) in memory is replaced with the .TEXT section of the clean NTDLL. The detailed flow of the methodology and all techniques is given below. How to Use You can open and compile the project with Visual Studio. The whole project supports x64 architecture for both Debug and Release modes. The RefleXXion-EXE solution generates the EXE for PoC purpose. If you want to understand how the project works step by step, it will make your job easier. Main function contains Technique1 and Technique2 functions definations. Comment one of them and compile. Do not use both functions at the same time. The RefleXXion-DLL solution generates the DLL that you inject into the process you want to bypass the user-mode hooks for NTDLL. At the beginning of the main.cpp file, there are definitions of which technique to use. You can choose one of them and compile it. Do not set all values at the same time, set only the one technique you want. Example configuration is given below. // Techniques configuration section #define FROM_DISK 1 // If you set it to 1, the Technique-1 will be used. For more information; https://github.com/hlldz/RefleXXion #define FROM_KNOWNDLLS 0 // If you set it to 1, the Technique-2 will be used. For more information; https://github.com/hlldz/RefleXXion Operational Usage Notes & OPSEC Concerns RefleXXion currently is only supports for x64 architecture. RefleXXion only unhooks NTDLL functions, you may need to unhook other DLLs (kernel32.dll, advapi32.dll etc.) as well. For this, you can easily edit the necessary places in the project. The RefleXXion only uses the RWX memory region when overwriting the .TEXT section process starts. For this process a new memory reginon is not created, the existing memory region (the TEXT section of the NTDLL that is already loaded) is RWXed and then converted to RX. ULONG oldProtection; ntStatus = NtProtectVirtualMemory(NtCurrentProcess(), &lpBaseAddress, &uSize, PAGE_EXECUTE_READWRITE, &oldProtection); memcpy()... ntStatus = NtProtectVirtualMemory(NtCurrentProcess(), &lpBaseAddress, &uSize, oldProtection, &oldProtection); P.S. The RefleXXion invokes the NtProtectVirtualMemory API over the cleanly installed NTDLL. It uses the CustomGetProcAddress function for this because the clean NTDLL is not in the InLoadOrderModuleList even though it is loaded into memory. So a solution like here (https://stackoverflow.com/questions/6734095/how-to-get-module-handle-from-func-ptr-in-win32) will not work. That's why the custom GetProcAddress function exists and is used. You can load RefleXXion DLL from disk to target process. You may not prefer a run like this for sensitive work such as a Red Team operation. Therefore, you can convert the RefleXXion DLL to shellcode using the sRDI project or integrate the RefleXXion code into your own loader or project. Even if NTDLL (as file or as section) is reloaded to the injected process, it does not remain loaded. RefleXXion close all opened handles (file & section handles) for own processes. Special Thanks & Credits Research & PoC for collecting clean system calls with LdrpThunkSignature by Peter Winter-Smith, @peterwintrsmith. EDR Parallel-asis through Analysis, https://www.mdsec.co.uk/2022/01/edr-parallel-asis-through-analysis/ Windows 10 Parallel Loading Breakdown by Jeffrey Tang. https://blogs.blackberry.com/en/2017/10/windows-10-parallel-loading-breakdown https://stackoverflow.com/questions/42789199/why-there-are-three-unexpected-worker-threads-when-a-win32-console-application-s Shellycoat by Upayan, @slaeryan. https://github.com/slaeryan/AQUARMOURY/tree/master/Shellycoat Sursa: https://github.com/hlldz/RefleXXion

Haha, metoda folosita ca intotdeauna: "smack my bitch up". Multumim frate @Nytro