I didn’t expect my virustotal-search program to be that popular, so here is a new version with new features and a few fixes (version 0.0.1 contained a buggy experimental feature I hadn’t planned to release then).
What I didn’t explain in my first post, is that virustotal-search builds a database (virustotal-search.pkl) of all your requests, so that recurring requests are served from that local database, and not from the VirusTotal servers. I’ve added a field (Requested) to indicate if the request was send to VirusTotal or served from the local database.
If you want all requests to be send to VirusTotal, regardless of the content of the local database, use option –force.
And if you don’t want to include your API key in the program source code, you have two alternatives:
- use option –key and provide the API key on the command line
- define environment variable VIRUSTOTAL_API2_KEY with the your API key
Did you know that you can search VirusTotal? You don’t have to submit a file, but you can search for the report of a file has been submitted before. You use a cryptographic hash (MD5, SHA1, SHA256) to identify the file.
There are several tools to submit a batch of files to VirusTotal, but I didn’t find any that just searches VirusTotal for a list of search terms via VirusTotal’s API.
Thus I wrote my own Python program. It accepts a file with a list of hashes, and produces a CSV file with the result. Here is an example displayed with InteractiveSieve:
To get this program working, you need to get a VirusTotal API key and add it to this program. You need a VirusTotal account to get your API key.
And my program respects VirusTotal’s rate limitation (4 requests per minute), I don’t want it to DoS VirusTotal.
I wrote shellcode that calls ExitProcess for my TaskManager.xls spreadsheet.
Now I’ve added the asm files (sc-ep.asm for 32-bit and sc-64-ep.asm for 64-bit) for this shellcode to my library.
Remark that the 32-bit version assembler code, that was generated with my simple shellcode generator, has a ret instruction after the call to ExitProcess. This instruction will never be executed, as a call to ExitProcess does not return.
You can find this shellcode on my shellcode page.
I quickly developed a dll that kills calc.exe when started from anything else than explorer.exe.
This way, you can mess with all those PoCs that launch calc.exe ;-)
My TaskManager spreadsheet provides you with a couple of commands to terminate (malicious) programs. But sometimes these commands can’t terminate a process (for various reasons).
Today I’m adding a new command to our toolkit: injecting and executing shellcode in the target process. I’m providing 32-bit and 64-bit shellcode that calls ExitProcess. When this shellcode is injected and executed inside a process, the process will terminate itself.
Here I’m using the command “e ep64”: this command injects and executes the shellcode found in sheet ep64 (as hex strings) in process notepad:
The result is that notepad will terminate itself.
When using TaskManager on a 64-bit system, you’ll have to pay attention to the following: to terminate a 32-bit process, you inject 32-bit shellcode (ep32) and for a 64-bit process, you use 64-bit shellcode (ep64). And a 32-bit process can’t access a 64-bit process’ memory through the Windows API, so if you are using 32-bit Excel on a 64-bit machine, you won’t be able to inject shellcode into 64-bit processes.
FYI: If you want to know more about 32-bit and 64-bit processes on x64 Windows, I’ll bedoing a workshop at Brucon this year: “Windows x64: The Essentials”.