{
	"id": "9be8592d-2f94-4db9-93f3-d2cccfa67193",
	"created_at": "2026-04-06T00:20:17.50498Z",
	"updated_at": "2026-04-10T03:21:43.570664Z",
	"deleted_at": null,
	"sha1_hash": "7ceeb06ac7cac799f0ed9d71d6190b2d033eb8f0",
	"title": "Snakes \u0026 Ladders: the offensive use of Python on Windows",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 97319,
	"plain_text": "Snakes \u0026 Ladders: the offensive use of Python on Windows\r\nBy By Theta\r\nArchived: 2026-04-05 14:23:39 UTC\r\nRecent news that Python’s founder (and previous BDFL) Guido Van Rossum is working with Microsoft - along\r\nwith the prospect of integration between Python and Windows - is an interesting and ultimately good development\r\nfor fans of the versatile and incredibly popular language. However, the offensive use of Python on Windows\r\nremains an edge case to be considered (as some have) by defensive and offensive security practitioners alike.\r\nThe 'state of the art'\r\nTheta’s Cyber Security Practice has several forward-leaning observations around the offensive use of Python in\r\nWindows environments, which may only accelerate in relevance as Microsoft further integrates the language into\r\nits ecosystem. Much of the offensive tradecraft and detection engineering efforts of the world are currently (and\r\nrightly) focused on things like .NET and C#, along with coverage of “classic” windows LOLBins (so-called\r\n“living off the land binaries” – such as bitsadmin, certutil, scrobj and mavinject etc).\r\nThis comes after the instrumentation and subsequent transition away from PowerShell and cmd.exe before that.\r\nHowever, Python currently remains a good way to deploy and execute tooling and scripts onto Windows hosts:\r\neither as a scripting interface or as a fully-fledged interpreter.\r\nTraditional use of offensive Python has been focused around its usage on dedicated Linux hosts for pentesting,\r\nparticularly for network or packet manipulation, or in the delivery of fully functioning and otherwise “fat” remote\r\naccess trojans (or RATS) to systems. While MITRE ATT\u0026CK has the sub technique T1059.006 - Command and\r\nScripting Interpreter: Python, few are familiar with its capabilities - specifically in relation to Windows. Cobalt\r\nStrike’s flexible Agressor Scripts (its own native scripting language for modification and extension of the popular\r\noffensive software) comes with a hook for Python as an example.\r\nYear of the snake\r\nUnless it’s been disabled, Python can be installed from the Windows store (programmatically via `winget\r\nPython.Python`, if winget is deployed – which itself is likely to see an uptick in adoption and worthy of\r\npractitioners' understanding). Whilst installed Python packages do touch disk and can be discovered by\r\ninvestigators, there aren’t many reasons to hunt for them.\r\nWe've observed first hand the ability to directly download offensive modules via pip onto otherwise orchestrated\r\nor monitored systems. EDR and AV are likely to turn a blind eye to packages like Skelsec’s Pypykatz – an\r\nimplementation of the infamous Mimikatz (admittedly with some reduced functionality), the ever-useful Impaket\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/snakes-ladders-the-offensive-use-of-python-on-windows/\r\nPage 1 of 4\n\n(GetUserSPNs.py) or FOXIT’s Bloodhound.py ingestor module. Rounding out offensive capabilities, there are\r\nalso Python implementations of psexec and wmiexec (part of the lsassy project).\r\nNone of any of these items would be expected to be on a normal corporate workstation and whose presence would\r\ncause alarm to a human analyst.\r\nIn systems where the Windows store isn’t available, Python can be downloaded from the web. Doing so is\r\nextremely unlikely to trigger any detection by either host or network instrumentation: proxies, firewalls or other\r\nsecurity controls simply do not classify IDEs as malicious - and nor should they.\r\nPython’s pip (its main package manager which can be used to download all of the tooling mentioned above) is an\r\ninteresting delivery mechanism as implemented in Windows. The packages it collects are written to disk as\r\ncompiled .exe files - valid DOS MZ executables – however, these exe’s come with zip archives embedded (with a\r\n“__main__.py” file inside them); and possibly hints to some of the reasons behind defensive tooling not\r\nresponding well to offensive packages.\r\nNote the “PK” the header for a .zip file - embedded at the end of the .exe\r\nThis is in contrast to a unix system - where pip will collect ultimately a script (a text file).\r\nAt the end of the day, this leaves us with a stark difference between downloading via a web browser or\r\nPowerShell a well-known “Offensive Security Tool” (OST) and using pip to download the Python equivalent.\r\nEffects\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/snakes-ladders-the-offensive-use-of-python-on-windows/\r\nPage 2 of 4\n\nTheta has developed a range of cross-platform capabilities in Python to support our operations –  performing\r\nmany of the same types of capabilities we've observed real malicious actors and their tools in the wild. So far, we\r\ncan sadly report that they haven’t been detected or blocked in environments with EDR or other monitoring – even\r\nwithout obfuscation - including against specific software designed to detect particular TTPs. In the real world, this\r\nis only made worse as many endpoint security products make for easy targets. It’s usually a trivial exercise to\r\ndegrade and disable them – which is something we see ransomware operators, in particular, do very frequently.\r\nUnsettlingly, we've been able to conduct a complete kerberoast of a domain from a single host using Python from\r\nthe Windows Store without any need for lateral movement, privilege escalation or defensive evasion; all while AV\r\nwas running on the machine.\r\nDefensive Advice\r\nUnlike PowerShell, Python’s logging isn’t well understood or documented. Execution or Transcript logging\r\ndoesn't exist as it does with modern PowerShell, nor is there any equivalency of AMSI. Python requires the\r\ninclusion of additional modules to write out to the Windows Event Log, making it a dark spot for introspection\r\nand analysis – which is ironic given the extremely heavy use of Python in the forensics world for performing\r\nanalysis.\r\nFrom an analysis standpoint, finding the following on-disk is cause for some alarm and would be considered high\r\nfidelity sign of malicious activity if there wasn’t legitimate testing being carried out.\r\nSource: %LOCALAPPDATA% \\Programs\\Python\\Python\u003cVersion\u003e\\Scripts\\\r\nWe debated releasing some Yara to look for these indicators. But rather than focusing on brittle detections for\r\nattributes like file names (remember the pyramid of pain), it's likely to be more useful if we understand what types\r\nof systems should be installing fully-fledged interpreters - particularly on servers where workloads should be\r\nfairly static. Albeit less straightforward advice: the reasons for non-technical users to suddenly deploy Python on a\r\nWindows endpoint remain limited, although the effort or cost to get that level of insight and visibility across an\r\nestate isn’t trivial.\r\nFor those with hunt programs, developing Python-specific hunts or including Python artefacts in them may prove\r\nfruitful, along with potentially building out specific detections for Python execution. Hunting across\r\n%LOCALAPPDATA%\\Programs\\Python\\Python\u003cVersion\u003e\\Scripts\\ for evidence of pip module names could\r\nprove a simple start. Detections based on pypsexec or similar lateral movement tools are also likely to be higher\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/snakes-ladders-the-offensive-use-of-python-on-windows/\r\nPage 3 of 4\n\nfidelity signs of something amiss than their non-Python equivalents – although this moves towards network\r\ninstrumentation or in-memory detections.\r\nAt a more abstract level, looking for other languages (particularly ones with Windows interpreters or script\r\ninterfaces) with these sorts of techniques is a valid exercise as more and more offensive research about different\r\nframeworks and languages available to practitioners continues to surface. This type of over-the-horizon scanning\r\nmay not be relevant for what’s happening today, but new offensive tradecraft has been shown to be adopted\r\nrapidly by sophisticated adversaries and red teams once it’s been shown to work; understanding what’s going on in\r\nthe Twittersphere and GitHub provides some degree of early warning.\r\nSystem administrators and security practitioners should also be cognizant of the Windows Store and develop a\r\nstrategy for its use in their organisations. Microsoft’s traditional model of application deployment being a free-for-all is slowly getting a viable alternative, but as with all things, there is an edge case around malicious usage to be\r\nconsidered. This goes beyond just Python. The opportunity to use WSL (or WSL2) to do ill is large and an\r\ninteresting topic all of its own (going all the way to having Kali Linux built-in). Although, in our experience, this\r\nis more likely a trap for curious internal users than serious adversaries.\r\nSummary\r\nFurther research by the community is required into the additional forensic opportunities available with Python\r\nScripting on Windows; very little is currently available in the public domain. We can only hope that Microsoft\r\nplaces extra attention on working towards logging parity between PowerShell and Python in Windows. Especially\r\nif it’s going to get further integrated into the Windows ecosystem.\r\nUntil then, you should strap yourselves in. If offensive use of Python and supporting features like NuGet goes the\r\nsame way as PowerShell, then we’re all in for a rough ride.\r\nSource: https://www.theta.co.nz/news-blogs/cyber-security-blog/snakes-ladders-the-offensive-use-of-python-on-windows/\r\nhttps://www.theta.co.nz/news-blogs/cyber-security-blog/snakes-ladders-the-offensive-use-of-python-on-windows/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.theta.co.nz/news-blogs/cyber-security-blog/snakes-ladders-the-offensive-use-of-python-on-windows/"
	],
	"report_names": [
		"snakes-ladders-the-offensive-use-of-python-on-windows"
	],
	"threat_actors": [],
	"ts_created_at": 1775434817,
	"ts_updated_at": 1775791303,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7ceeb06ac7cac799f0ed9d71d6190b2d033eb8f0.pdf",
		"text": "https://archive.orkl.eu/7ceeb06ac7cac799f0ed9d71d6190b2d033eb8f0.txt",
		"img": "https://archive.orkl.eu/7ceeb06ac7cac799f0ed9d71d6190b2d033eb8f0.jpg"
	}
}