After a few days trying to get this working I finally got it. I created a wendigo module that can import python packages. The original scripts remote import functionality could pull single files from GitHub and import them, but with the design intention that they had been designed to be modular code pieces, and not python modules, in the traditional sense. However, that functionality could still be used to import python modules while in a wendigo module, provided that it was in the correct directory.
What it couldn’t do however, was import a package (such as the xml etree package that I was using for testing). This functionality is important for the overall performance of wendigo because it would be ideal to be able import libraries such as scapy or ctypes dynamically, without the guarantee that the victim host has the correct libraries installed. One alternative would be to download the packages and then import them, which, while not necessarily suspicious, may require privilege escalation (not necessarily a bad thing), and is definitely less stealthy than it could be. So, in comes dynamic, remote package installation.
I tried expanding the metapath-ed import classes functionality to include support for file searching and package importing, but to no avail (I think the problem was part of the way python imports and stores packages*). What needed to be done was to make use of the imp modules load_module function. You needed to find the module file (usually done by find_module, but I just went around that instead of adding to the custom path like with the ReImp class), which I did with a recursive depth first search of the module directory in the GitHub repo to deal with any sort of directory structure (which I expanded to start from the package when importing submodules). Then you just need to call load_module with the file (and some other data) and put the returned module in sys.modules. The trick is that you need to import the package and then (the subpackage and then) the actual file, and put each of them in sys.modules, and then you just have to reference the entry of the library you want to use in sys.modules to access it’s interface. (Or just return the entry you want to use and assign it to a variable, so ET = my_load(xml.etree.ElementTree) is the same as import xml.etree.ElementTree as ET.)
*Like if you wanted to import xml.etree.ElementTree you’d need to load xml, and then xml.etree, etc. but because of the way the python imports the modules, after importing xml python would try to import xml.etree and would hit an exception trying to access xmls etree element, because it didn’t have one (the initialization code just needs to be run and it needs to be put into sys.modules). The xml.etree and xml.etree.ElementTree files need to be found and loaded separately. So by using the metapath you were coming in too late in the process (you only got the import xml call, not the import xml.etree.ElementTree call to be able to split it up and manage it all yourself).
My Portfolio 