{
	"id": "c525a228-f9ca-48f2-9dc9-87ca203e3963",
	"created_at": "2026-04-06T00:21:08.015315Z",
	"updated_at": "2026-04-10T03:20:43.956918Z",
	"deleted_at": null,
	"sha1_hash": "14edb83651be001cae4bd5c7ad23f2343babefbf",
	"title": "Bring Your Own Land (BYOL) — A Novel Red Teaming Technique | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 556695,
	"plain_text": "Bring Your Own Land (BYOL) — A Novel Red Teaming Technique\r\n| Mandiant\r\nBy Mandiant\r\nPublished: 2018-06-18 · Archived: 2026-04-05 23:00:45 UTC\r\nWritten by: Nathan Kirk\r\nIntroduction\r\nOne of most significant recent developments in sophisticated offensive operations is the use of “Living off the\r\nLand” (LotL) techniques by attackers. These techniques leverage legitimate tools present on the system, such as\r\nthe PowerShell scripting language, in order to execute attacks. The popularity of PowerShell as an offensive tool\r\nculminated in the development of entire Red Team frameworks based around it, such as Empire and PowerSploit.\r\nIn addition, the execution of PowerShell can be obfuscated through the use of tools such as “Invoke-Obfuscation”.\r\nIn response, defenders have developed detections for the malicious use of legitimate applications. These\r\ndetections include suspicious parent/child process relationships, suspicious process command line arguments, and\r\neven deobfuscation of malicious PowerShell scripts through the use of Script Block Logging.\r\nIn this blog post, I will discuss an alternative to current LotL techniques. With the most current build of Cobalt\r\nStrike (version 3.11), it is now possible to execute .NET assemblies entirely within memory by using the\r\n“execute-assembly” command. By developing custom C#-based assemblies, attackers no longer need to rely on\r\nthe tools present on the target system; they can instead write and deliver their own tools, a technique I call Bring\r\nYour Own Land (BYOL). I will demonstrate this technique through the use of a custom .NET assembly that\r\nreplicates some of the functionality of the PowerSploit project. I will also discuss how detections can be\r\ndeveloped around BYOL techniques.\r\nBackground\r\nAt DerbyCon last year, I had the pleasure of meeting Raphael Mudge, the developer behind the Cobalt Strike\r\nRemote Access Tool (RAT). During our discussion, I mentioned how useful it would be to be able to load .NET\r\nassemblies into Cobalt Strike beacons, similar to how PowerShell scripts can be imported using the “powershell-import” command. During a previous Red Team engagement I had been involved in, the use of PowerShell was\r\nprecluded by the Endpoint Detection and Response (EDR) agent present on host machines within the target\r\nenvironment. This was a significant issue, as much of my red teaming methodology at the time was based on the\r\nuse of various PowerShell scripts. For example, the “Get-NetUser” cmdlet of the PowerView script allows for the\r\nenumeration of domain users within an Active Directory environment. While the use of PowerShell was not an\r\noption, I found that no application-based whitelisting was occurring on hosts within the target’s environment.\r\nTherefore, I started converting the PowerShell functionality into C# code, compiling assemblies locally as\r\nPortable Executable (PE) files, and then uploading the PE files onto target machines and executing them. This\r\nhttps://www.mandiant.com/resources/bring-your-own-land-novel-red-teaming-technique\r\nPage 1 of 6\n\ntactic was successful, and I was able to use these custom assemblies to elevate privileges up to Domain Admin\r\nwithin the target environment.\r\nRaphael agreed that the ability to load these assemblies in-memory using a Cobalt Strike beacon would be useful,\r\nand about 8 months later this functionality was incorporated into Cobalt Strike version 3.11 via the “execute-assembly” command.\r\n“execute-assembly” Demonstration\r\nFor this demonstration, a custom C# .NET assembly named “get-users” was used. This assembly replicated some\r\nof the functionality of the PowerView “Get-NetUser” cmdlet; it queried the Domain Controller of the specified\r\ndomain for a list of all current domain accounts. Information obtained included the “SAMAccountName”,\r\n“UserGivenName”, and “UserSurname” properties for each account. The domain is specified by passing its\r\nFQDN as an argument, and the results are then sent to stdout. The assembly being executed within a Cobalt Strike\r\nbeacon is shown in Figure 1.\r\nFigure 1: Using the “execute-assembly” command within a Cobalt Strike beacon.\r\nSimple enough, now let’s take a look at how this technique works under the hood.\r\nHow “execute-assembly” Works\r\nIn order to discover more about how the “execute-assembly” command works, the execution performed in Figure\r\n1 was repeated with the host running ProcMon. The results of the process tree from ProcMon after execution are\r\nshown in Figure 2.\r\nhttps://www.mandiant.com/resources/bring-your-own-land-novel-red-teaming-technique\r\nPage 2 of 6\n\nFigure 2: Process tree from ProcMon after executing “execute-assembly” command.\r\nIn Figure 2, The “powershell.exe (2792)” process contains the beacon, while the “rundll32.exe (2708)” process is\r\nused to load and execute the “get-users” assembly. Note that “powershell.exe” is shown as the parent process of\r\n“rundll32.exe” in this example because the Cobalt Strike beacon was launched by using a PowerShell one-liner;\r\nhowever, nearly any process can be used to host a beacon by leveraging various process migration techniques.\r\nFrom this information, we can determine that the “execute-assembly” command is similar to other Cobalt Strike\r\npost-exploitation jobs. In Cobalt Strike, some functions are offloaded to new processes, in order to ensure the\r\nstability of the beacon. The rundll32.exe Windows binary is used by default, although this setting can be changed.\r\nIn order to migrate the necessary code into the new process, the CreateRemoteThread function is used. We can\r\nconfirm that this function is utilized by monitoring the host with Sysmon while the “execute-assembly” command\r\nis performed. The event generated by the use of the CreateRemoteThread function is shown in Figure 3.\r\nFigure 3: CreateRemoteThread Sysmon event, created after performing the “execute-assembly” command.\r\nMore information about this event is shown in Figure 4.\r\nFigure 4: Detailed information about the Sysmon CreateRemoteThread event shown in Figure 3.\r\nIn order to execute the provided assembly, the Common Language Runtime (CLR) must be loaded into the newly\r\ncreated process. From the ProcMon logs, we can determine the exact DLLs that are loaded during this step. A\r\nportion of these DLLs are shown in Figure 5.\r\nhttps://www.mandiant.com/resources/bring-your-own-land-novel-red-teaming-technique\r\nPage 3 of 6\n\nFigure 5: Example of DLLs loaded into rundll32 for hosting the CLR.\r\nIn addition, DLLs loaded into the rundll32 process include those necessary for the get-users assembly, such as\r\nthose for LDAP communication and Kerberos authentication. A portion of these DLLs are shown in Figure 6.\r\nFigure 6: Example of DLLs loaded into rundll32 for Kerberos authentication.\r\nThe ProcMon logs confirm that the provided assembly is never written to disk, making the “execute-assembly”\r\ncommand an entirely in-memory attack.\r\nDetecting and Preventing “execute-assembly”\r\nThere are several ways to protect against the “execute-assembly” command. As previously detailed, because the\r\ntechnique is a post-exploitation job in Cobalt Strike, it uses the CreateRemoteThread function, which is commonly\r\ndetected by EDR solutions. However, it is possible that other implementations of BYOL techniques would not\r\nrequire the use of the CreateRemoteThread function.\r\nThe “execute-assembly” technique makes use of the native LoadImage function in order to load the provided\r\nassembly. The CLRGuard project hooks into the use of this function, and prevents its execution. An example of\r\nCLRGuard preventing the execution of the “execute-assembly” command is shown in Figure 7.\r\nFigure 7: CLRGuard blocking the execution of the “execute-assembly” technique.\r\nThe resulting error is shown on the Cobalt Strike teamserver in Figure 8.\r\nhttps://www.mandiant.com/resources/bring-your-own-land-novel-red-teaming-technique\r\nPage 4 of 6\n\nFigure 8: Error shown in Cobalt Strike when “execute-assembly” is blocked by CLRGuard.\r\nWhile CLRGuard is effective at preventing the “execute-assembly” command, as well as other BYOL techniques,\r\nit is likely that blocking all use of the LoadImage function on a system would negatively impact other benign\r\napplications, and is not recommended for production environments.\r\nAs with almost all security issues, baselining and correlation is the most effective means of detecting this\r\ntechnique. Suspicious events to correlate could include the use of the LoadImage function by processes that do not\r\ntypically utilize it, and unusual DLLs being loaded into processes.\r\nAdvantages of BYOL\r\nDue to the prevalent use of PowerShell scripts by sophisticated attackers, detection of malicious PowerShell\r\nactivity has become a primary focus of current detection methodology. In particular, version 5 of PowerShell\r\nallows for the use of Script Block Logging, which is capable of recording exactly what PowerShell scripts are\r\nexecuted by the system, regardless of obfuscation techniques. In addition, Constrained Language mode can be\r\nused to restrict PowerShell functionality. While bypasses exist for these protections, such as PowerShell\r\ndowngrade attacks, each bypass an attacker attempts is another event that a defender can trigger off of. BYOL\r\nallows for the execution of attacks normally performed by PowerShell scripts, while avoiding all potential\r\nPowerShell-based alerts entirely.\r\nPowerShell is not the only native binary whose malicious use is being tracked by defenders. Other common\r\nbinaries that can generate alerts on include WMIC, schtasks/at, and reg. The functionality of all these tools can be\r\nreplicated within custom .NET assemblies, due to the flexibility of C# code. By being able to perform the same\r\nfunctionality as these tools without using them, alerts that are based on their malicious use are rendered\r\nineffective.\r\nFinally, thanks to the use of reflective loading, the BYOL technique can be performed entirely in-memory, without\r\nthe need to write to disk.\r\nConclusion\r\nBYOL presents a powerful new technique for red teamers to remain undetected during their engagements, and can\r\neasily be used with Cobalt Strike’s “execute-assembly” command. In addition, the use of C# assemblies can offer\r\nattackers more flexibility than similar PowerShell scripts can afford. Detections for CLR-based techniques, such\r\nas hooking of functions used to reflectively load assemblies, should be incorporated into defensive methodology,\r\nas these attacks are likely to become more prevalent as detections for LotL techniques mature.\r\nAcknowledgement\r\nhttps://www.mandiant.com/resources/bring-your-own-land-novel-red-teaming-technique\r\nPage 5 of 6\n\nSpecial thanks to Casey Erikson, who I have worked closely with on developing C# assemblies that leverage this\r\ntechnique, for his contributions to this blog.\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.mandiant.com/resources/bring-your-own-land-novel-red-teaming-technique\r\nhttps://www.mandiant.com/resources/bring-your-own-land-novel-red-teaming-technique\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.mandiant.com/resources/bring-your-own-land-novel-red-teaming-technique"
	],
	"report_names": [
		"bring-your-own-land-novel-red-teaming-technique"
	],
	"threat_actors": [],
	"ts_created_at": 1775434868,
	"ts_updated_at": 1775791243,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/14edb83651be001cae4bd5c7ad23f2343babefbf.pdf",
		"text": "https://archive.orkl.eu/14edb83651be001cae4bd5c7ad23f2343babefbf.txt",
		"img": "https://archive.orkl.eu/14edb83651be001cae4bd5c7ad23f2343babefbf.jpg"
	}
}