Cookies set bij network proxies can be identified by their name.
BlueCoat proxy cookies start with BCSI-CS-.
Cisco IronPort proxy cookies start with iptac-. The string after iptac is the serial number of the device.
Google for these and you’ll find some examples.
More info later.
Soon I’ll release new versions of my Authenticode Tools.
Detecting extra data in the signature field is one of the new features. For example, it will analyze the size specified in the optional header data directory for security, the size specified in the WIN_CERTIFICATE structure and the size specified in the PKCS7 signature itself. These should be the same, taking into account some zero-byte padding.
In case you didn’t know: extra data can be added in the data directory that contains the signature, without invalidating the signature. My Disitool can do this.
With this new version of AnalyzePESig, I found some setup programs that contain extra data after the signature; data that seems to contain installation options for the installer. For example, the Google Chrome installer has this:
As you can see, the size specified in the optional header data directory for security and the size specified in the WIN_CERTIFICATE structure are both 6272 bytes, but the size of the PKCS7 signature is 6079. So that leaves 181 extra bytes. You can see them here:
And I found some other installers with extra data (config data or license information) in the signature directory: GotoMyPc, PowerGrep, RegexBuddy.
Microsoft’s Malware Protection Center has a blogpost on a version of Rovnix that uses its own TCP/IP stack.
I used Wireshark to capture the network traffic generated by this sample when it is executed in a VMware guest.
I ran the sample on a XP SP3 guest machine in VMware. The hostname is XPPROSP3 (this name will appear in the HTTP GET request).
The guest uses NAT.
I ran the Wireshark capture on my host machine on the VMware Virtual Ethernet Adapter.
I removed some traffic coming from my host machine (NetBIOS Name Service and DHCPv6 to be precise).
When I executed the sample on XPPROSP3, it rebooted after a few seconds.
The 37 second gap between packet 6 and 7 is due to the reboot of XPPROSP3
Packet 44: DNS request for youtubeflashserver
There are 3 HTTP requests. Notice User-Agent FWVersionTestAgent in all 3 GET requests.
Packet 50: first GET request with hostname XPPROSP3 as a parameter. Response: 404
Packet 61: second GET request, malformed. Response: 400
Packet 70: third GET request, malformed. Response: 400
I’m attending OHM2013. To mark the occasion of this outdoor hacker conference taking place every 2 years, I’m doing a 20% promo on my workshop videos.
In case you missed it, I posted this during the weekend: MSI: The Case Of The Invalid Signature.
I found a suspicious file on a Windows XP machine. I was able to trace its origin back to a Windows Installer package (.msi). This package in c:\windows\installer had an invalid digital signature. Like this:
A bit later I found another msi package containing the same suspicious file. But this time, the package had a valid digital signature. What’s going on?
After a deep dive into the internals of msi packages, I found the answer.
When an msi package is installed, it is cached inside the Windows Installer directory (%windir%\Installer). Prior to Windows Installer 5.0 (released with Windows 7), cached packages were stripped of their embedded cab files. But with digitally signed msi files, the signature remained inside the file: the digitally signed file was modified, hence the signature was invalidated. This behavior changed with Windows Installer 5.0: cached packages are no longer stripped, hence the signature remains valid.
This blogpost by Heath Stewart explains this change in more detail. Unfortunately, my Google-skills were not good enough to find this blogpost prior to my deep dive into msi files. Hindsight Googling FTW! ;-)
It looks like I didn’t release this update to my lookup tools.
lookup-hosts.py has a new argument: -R. This does a reverse lookup of the IP addresses (thus after it resolved the hostname).
And now you can also use letters as a counter: test-[a-z].com
Because I had to use a workaround in my js-unicode-unescape.1sc script to copy an array of bytes to the clipboard, I asked the 010 Editor developers if they could add a function that does exactly this.
They included this new function, CopyBytesToClipboard, in their new version 5.0.
Here is a new version that uses this function:
I had something of a puzzle to solve. A friend asked me to look at a set of files, all of the same size, but with some differences.
After some analysis, it dawned on me that these files were the result of a simple fuzzer applied to a single file. So I quickly wrote a program that took these files as input and reconstituted the original file. Later I wrote a more generic defuzzer. Here is an example:
defuzzer.py result.png a*.png
Number of defuzzed bytes: 171
Number of defuzzed sequences: 33
Length of shortest defuzzed sequence: 1
Length of longest defuzzed sequence: 10
From the result you can see that the program was able to reconstitute the original file, and that the fuzzer that was used to produce the different a*.png files, overwrote 33 byte-sequences with the character A. The longest sequence was 10 bytes long, the shortest only 1 byte. In total, 171 bytes were overwritten.
Mark Woan reported an issue with virustotal-search.py: sometimes VirusTotal returns a JSON object that the json parser can’t parse.
That’s something I didn’t expect. I’ve added error handling for this case.
This update adds x64 shellcode support to my shellcode2vbs.py script.