{
	"id": "098dc05c-ddbb-4706-b470-b6799abea98b",
	"created_at": "2026-04-06T00:19:17.313778Z",
	"updated_at": "2026-04-10T03:20:51.812006Z",
	"deleted_at": null,
	"sha1_hash": "3a64e05826a78e0b65e58a86a132c7b699dcd27d",
	"title": "Defense Evasion Techniques",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1451046,
	"plain_text": "Defense Evasion Techniques\r\nArchived: 2026-04-05 23:05:49 UTC\r\nLast updated: November 1st, 2021\r\nWritten by: Ariel silver\r\nAnalyzing, detecting, and preventing modern day techniques that malwares deploy to bypass security tools\r\nand professionals.\r\nIntroduction\r\nToday’s adversaries and attackers are no longer focused simply on doing the maximum possible damage; they’re\r\nlooking to remain undetected as long as possible. Malware authors go to great lengths to research new or\r\noverlooked mechanisms that let them blend with day-to-day machine operations. These methodologies (also\r\nknown as “defense evasion techniques”) seek to help malwares bypass defensive tools’ detection.\r\nSurprisingly, most of these techniques don’t involve malicious code, but rather use Microsoft distributed files and\r\nobjects. These strategies, known as “living of the land”, use legitimate mechanisms for malicious purposes.\r\nLuckily for us, Cynet 360 monitors evasion technique action points and add a layer of detection mechanisms to its\r\nrobust knowledge base.\r\nIn the scope of this article, we will cover in detail few interesting and powerful evasion techniques that Cynet’s\r\nCyOps team have faced lately.\r\nThis is part of an extensive series of guides about Malware Protection\r\nDisclaimer\r\nIn the examples below, you will see several videos of simulated attack scenarios that produce an alert. In some of\r\nthese scenarios the attack was successfully completed even though an alert was generated.\r\nIt’s important to note that for these simulations I have disabled Cynet’s prevention capabilities and left only\r\ndetections enabled. You should not attempt this in any shape or form. This should only be done in a lab isolated\r\nfrom the corporate network. If the prevention mechanisms are enabled, none of the scenarios could be successful.\r\nBreaking The Chains\r\nMost next-gen XDR agents continuously examine process actions and process trees to spot any suspicious\r\nbehavior. Let’s look at a common example of a suspicious process tree: Excel document initiates a mshta.exe\r\ninstance. This behavior indicates malicious behavior 90% of the time and hopefully triggers an alert with any EDR\r\nsystem.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 1 of 15\n\nTo break these process trees and avoid triggering predefined “child process” rules, attackers will add another\r\nlegitimate process in the middle to proxy the execution of the child process and break the process chain.\r\nOne of the most powerful executables for this job is Rundll32.exe.\r\nPer Microsoft, the original use of Rundll32.exe is that it “Loads and runs 32-bit dynamic-link libraries”, but in the\r\nCyber community this executable has become so much more.\r\nWith the use of DLL’s shell32.dll, Rundll32.exe can proxy the execution of almost everything.\r\n1) Rundll32.exe executes JavaScript code.\r\nIn this scenario, the attacker tried to use Rundll32.exe to proxy the execution of JS code.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 2 of 15\n\nThis detection is unpassable, as it doesn’t analyze the JavaScript code to determine the legitimacy of this behavior,\r\nbut examines the process behavior.\r\nAs indicated before: “Rundll32 Loads and runs 32-bit dynamic-link libraries” so no JavaScript execution should\r\nbe legitimate.\r\n2) Rundll32.exe proxies shell commands.\r\nIn this scenario, the attacker tried to abuse Rundll32.exe to proxy the execution of shell commands using CMD.\r\nThe use of shelldll32.dll with different arguments is something common with Rundll32.exe.\r\nOnce again this detection recognizes the process behavior as malicious and doesn’t analyze the shell command.\r\nDot Com Bubble\r\nThe next scenarios relate to COM object hijacking. These are sophisticated techniques that provide the attacker\r\ntwo crucial elements: security tools evasion and persistence.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 3 of 15\n\nAdmittedly, comparing this to the Dot Com crash might be exaggerating – it did take MSFT shares 17 years to\r\nbounce back – but this subject has certainly created massive headaches for Microsoft developers and security\r\nteams.\r\nBefore diving into the attacks and detections, we must establish a technical baseline:\r\nCLSID – a serial number that represents a unique ID for any application component in Windows\r\nCLSID’s location and structure:\r\nYou can find CLSID under the following registry keys:\r\nHKEY_CURRENT_USER\\Software\\Classes\\CLSID\r\nHKEY_LOCAL_MACHINE\\Software\\Classes\\CLSID\r\nHKEY_CLASSES_ROOT\\CLSID\\\r\nHKEY_CURRENT_USER + HKEY_LOCAL_MACHINE CLSID’s form the HKEY_CLASSES_ROOT which\r\nis the one\r\nthat the machine actually queries most of the time.\r\nif there is a conflict between the 2 Hives CLSID’s, HKEY_CURRENT_USER Overrides\r\nHKEY_LOCAL_MACHINE\r\nCOM objects – components that allow inter-process communication and code reuse\r\nCOM object keys – Sub keys of the CLSID’s. depends on the COM object key, but most of them point to\r\nfiles or other CLSID’s\r\n1) Abusing “TreatAs” subkey\r\nWith this technique, we are hijacking a COM object.\r\nWe do it by searching for CLSIDs that known softwares call but are unable to find as it doesn’t exist. This is when\r\nwe create this CLSID with any values and data we want, so next time the software calls the CLSID our hijacked\r\nCOM object will be “executed”.\r\nI used Procmon to find a vulnerable COM object like the ones described above which operate everyday\r\napplications and see which one will pay dividends.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 4 of 15\n\nAs you see I’m searching for keys under the HKEY_CURRENT_USER hive, that end with “InProcServer32”.\r\n“InProcServer32” – A subkey that indicates where a COM library is located on the disk, defines the threading\r\nmodel, and points to a dll.\r\nOnce we finish the initial search, we need to find an instance in which the software tried to access an\r\nInProceServer32 subkey of an inexistent CLSID.\r\nUsing Procmon we can find it when searching for a result that equals “NAME NOT FOUND”.\r\nThe COM object I found was referred to by WinWord.exe but didn’t exist. Once again, a perfect candidate for a\r\nhijack.\r\nI used the Registry editor to create this registry key and under it created two subkeys: “InProcServer32” and\r\n“TreatAs”\r\n“TreatAs” – Subkey of a CLSID. “TreatAs” contains a value named “(Default)” which can contain a string of\r\nanother CLSID number and spawn it as well when its own CLSID is called.\r\nUsually, the additional CLSID that is called by “TreatAs” will have a “InProcServer32” subkey that points to a\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 5 of 15\n\nmalicious DLL. For example:\r\nAttackers love this mechanism because it lets them create the following flow:\r\nCynet goes one step further to prevent this attack.\r\nInstead of monitoring all the “TreatAs” subkeys and waiting for them to call an unregistered CLSID, Cynet just\r\ndetects and prevents the adversary from modifying the data of “(Default)” value under the “TreatAs” subkey.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 6 of 15\n\nAs shown in the video and the alert below, Cynet immediately detects the attempt to modify a “TreatAs” subkey\r\nof a registered CLSID.\r\n2) Abusing “ScriptletURL” subkey\r\nIf you thought “TreatAs” is dangerous, the next sub-CLSID will look almost too powerful to be true.\r\nThe steps to find and hijack the missing CLSID are identical to the “TreatAs” flow.\r\nFor that reason, I’ve decided to further abuse the same CLSID as before: {DCB00C01-570F-4A9B-8D69-\r\n199FDBA5723B}. This time we are adding the “ScriptletURL” sub key.\r\nThis COM object allows software to download scripts from a remote URL and execute them without the script file\r\never touching the disk. Similar to Regsvr32.exe (which you will see in the following technique), “ScriptletURL”\r\nuses Scrobj.dll for these actions.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 7 of 15\n\nAs shown in the video above, this time I attempted to complete the scenario using the CMD.\r\nThis was done to assure our customers that these types of operations trigger an alert, regardless of the method\r\nused.\r\nOnce again Cynet detects and prevents the attempt to modify the registered CLSID’s “ScriptletURL” sub key.\r\nIn this case the operation was detected and not prevented. Therefore, the next time WinWord.exe calls this COM\r\nobject, it will download a PowerSploit script from GitHub and execute it.\r\nQakbot's BFF\r\nThe CyOps team has encountered Qakbot multiple times in recent months. Qakbot malware started as a banking\r\ntrojan in 2007. Its goal was to retrieve banking credentials and financial information. In later stages, it can be used\r\nfor a much wider range of activities, including spreading a ransomware attack.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 8 of 15\n\nQakbot’s attack flow first stages:\r\nThe important thing to notice in the above methodology is the use of Regsvr32.exe. Regsvr32.exe is a well-known\r\nand widely used system executable that has some documented functionalities regarding DLLs. Its documented\r\ncapabilities essentially add up to initiating DLLs, or in Microsoft’s words, it “registers .dll files as command\r\ncomponents in the registry.”\r\nSo how can we monitor and prevent the use of Regsvr32.exe without causing BSOD to our machine? First, we\r\ndon’t prevent any “clean” use of Regsvr32 such as executing a proper DLL file. Even so, we can monitor and\r\nprevent the following Regsvr32.exe abusing techniques:\r\n1) Masquerading DLLs\r\nOne commonly used technique is to disguise malicious DLLs as different file types with various extensions. For\r\nexample, an attacker can download a malicious DLL, change its extension to .jpg and use Regsvr32.exe to execute\r\nit as a DLL. Not many security tools monitor calls to a picture file.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 9 of 15\n\nIn above detection, Cynet looks at each and every instance of regsvr32.exe and the extension of every file being\r\nexecuted by regsvr32.exe.\r\nIf the file extension isn’t .dll , Cynet understands that it’s looking at a masquerading technique and prevents it.\r\n2) Squiblydoo\r\nSquiblydoo is the term name for methods using Scrobj.dll for LOLBin attacks. Scrobj.dll can load a COM\r\nscriptlet directly from the internet and execute it.\r\nAs promised, in the ScriptURL explanation paragraph, I will break down another overpowered evasion technique\r\nto conduct fileless attacks using Scrobj.dll.\r\nThe command above attempts to abuse Regsvr32.exe to proxy the execution of a remote scriptlet.\r\nThe Squiblydoo methods initiate Fileless attacks which receive malicious strings on HTTP and HTTPS and\r\nexecute them right on the RAM without ever touching the disk.\r\nCynet will alert and prevent this type of malicious behavior\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 10 of 15\n\nSorry… I don't speak base64\r\nThis method is used to bypass the not-so-good and very obsolete antivirus agents. To understand how it works, it’s\r\ncritical to first understand how AV categorizes files as malicious. AVs store a massive database of signatures that\r\nare searched against files. If a signature is matched, the file is labelled malicious. These signatures are built from\r\ncombinations of strings and hexes that were found in malwares but are unique enough to not generate many false\r\npositives. To provide an example we’re looking at Yara rules. These operate on the same concept as AV platforms,\r\nbut shouldn’t be mistaken for AV.\r\nFirst I dumped them in a hex editor to search for any unique strings.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 11 of 15\n\nThen I extracted the unique strings and created the following Yara rule:\r\nThis is a simple Yara rule created after analyzing a Trojan.\r\nWe found three unique strings and created a Yara signature that looks for executables containing one of these\r\nstrings or a random file containing all three of the strings, Case-insensitive. Once again, this is not an AV\r\nsignature, but just an example of the concept.\r\n1) Certutil – decode\r\nLet’s run a scenario. After compromising the system with a malicious macro, the attacker wants to transfer\r\nadditional tools into the system. The adversary knows the company has a Firewall and IDS with a built-in AV,\r\nwhich means they need to bypass it. The attacker can convert their malware to base 64, and once inside the system\r\nconvert it back into normal and execute it.\r\nThe malware can be decoded by a well-known system utility called Certutil. Certutil is a LOLBin attackers\r\nconstantly use as it’s signed and has many capabilities.\r\nCertutil -decode, is a way to decode a base64 file back to its functional form.\r\nLuckily, Cynet monitors Certutil.exe and alerts on this behavior and many more.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 12 of 15\n\nJust to prove that Antiviruses can’t handle an easy bypass technique like this, I took a well-known ransomware\r\nvariant called “WannaCry” and uploaded it twice to VirusTotal.\r\nFirst is pre-encoding:\r\nSecond is post-encoding:\r\nMore than 66% of the Antiviruses couldn’t keep up with such a simple technique.\r\nCOVID Vaccine\r\nInjection is one of the scariest phrases for any security analyst. Analyzing process injections requires ignoring the\r\nprocess tree and the vast majority of security tools to focus instead on process handled and API functions.\r\nLet’s take a look at Cobalt Strike. This malware started off as a red-team tool but has become a go-to platform for\r\nmany attackers. Cobalt Strike comes with a user-friendly GUI that allows adversaries to understand, document,\r\nand further damage machines they’ve exploited. Additionally, it comes pre-loaded with several post-exploitation\r\nmodules that can be initiated with a simple command.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 13 of 15\n\nFinally, there are attackers that use Cobalt Strike modules throughout the attack chain – from vulnerability scans\r\nto malware delivery or data exfiltration. Even though Cobalt Strike has endless attacking capabilities, the most\r\ncommonly noted is its capability for process injection. I have simulated a Cobalt attack ending with an injection in\r\nour labs, to see what API functions were used by the malicious file.\r\nFirst we created a .exe file called “artifact.exe”, that we will plant on the target machine:\r\nWhen executed by the target, the malicious file will create a reverse shell between the target and the C2:\r\nLastly used the cobalt injection command while specifying the PID of notepad.exe.\r\nThis generated the following alert on the target machine:\r\nBy looking at the requested flags, we see that the artifact.exe tried to create a remote thread on notepad.exe and\r\nwrite to its memory in order to execute malicious code on its behalf.\r\nCynet constantly monitors the API used between processes to find any anomalies that don’t align with the process\r\npermissions.\r\nConclusion\r\nThe evidence I’ve laid out in this article is only the tip of the iceberg when it comes to security tool evasion\r\ntechniques. This is an endless game of cat and mouse, with both sides constantly evolving. We’ve broken down\r\nsome common adversary techniques to remain undetected, and how Cynet can detect them. The Cynet research\r\nteam is continuously searching for, analyzing, and building mechanisms to detect these methods and prevent them.\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 14 of 15\n\nAdditionally, the CyOps team is constantly learning about new techniques and things to look out for when\r\nmonitoring our customers’ networks, whether its analyzing suspicious files or dealing with incident response.\r\nSource: https://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nhttps://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.cynet.com/attack-techniques-hands-on/defense-evasion-techniques/"
	],
	"report_names": [
		"defense-evasion-techniques"
	],
	"threat_actors": [],
	"ts_created_at": 1775434757,
	"ts_updated_at": 1775791251,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3a64e05826a78e0b65e58a86a132c7b699dcd27d.pdf",
		"text": "https://archive.orkl.eu/3a64e05826a78e0b65e58a86a132c7b699dcd27d.txt",
		"img": "https://archive.orkl.eu/3a64e05826a78e0b65e58a86a132c7b699dcd27d.jpg"
	}
}