When I want to code something from scratch, I will often look for libraries that help me achieve it best regardless of language they are written - for common situations  Python has a good ecosystem (but web interfaces don't look so great there anymore), if it's enterprise-y, most likely Java (which I'll use via Jython if I can help it), if it's Windows-ish - C# with WinApi calls. Weirdly RubyDNS/EventMachine is good for quick DNS shenanigans. I do this because I don't have an infinite amount of time to re-implement something in my langage du jour.

Same holds true for people moving code for hacking operations. If an operator wants to search for specific data on a computer, I'm probably best off using Windows Search API and the easiest way to invoke it is via PowerShell - about 20 lines of code seems to do it.  I looked at my code for selectively exfiltrating Outlook mailbox contents and discovered it was a bit of OLE Interop code (again - PowerShell, but I concede that C# would be pretty close line-wise). We could of course bring OpenDLP package or ntfs raw copy the entire .ost, but that seems to be heavyweight. A parallel exists for EDRs as well - EDRs like to rely on cool Win8.1+ features and tell customers to upgrade their XP/7 and Win2k3 boxes or not have latest features - they don't want to re-implement same stuff 3 times and could you please have our .NET to 4+ kthx bye. (this is also why network traffic recorders are useful).

You can see right now the fad for POC implants has moved away from C to C# to Golang, because all of this makes programmers more productive. as you're paid for operations not tool fetish, why write it in C? Sometimes doing stuff in non-C is harder. Over the last 2 months there's been an explosion of API unhooking articles thanks to great work by F-Secure (ex MWR) and so to keep up with the Joneses any decent toolkit needs now the ability to manipulate loaded libraries which perhaps excludes some choice of languages (I'm not quite sure how to achieve this in PS).

Other code economics matter as well. When you're in shellcode territory, the crawl space is small. Once you're in "bootstrap" territory, you have more space (e.g. your Office macro that downloads the kit can be fairly meaty) and you have options to hunt for eggs (e.g. retrieve a hidden attachment from Outlook in which your macro came in). Once you're in the "I can run an exe/dll here" territory, 20 megs is nothing. In one report I read, hackers downloaded and installed VirtualBox to run their toolkit. I think Dave's INNUENDO ran to 40 megs. Once they were done, it was a matter of shutting down the encrypted VM - good luck with forensics.

<retransmission>