Detecting Virtualized Environment in Gnu/Linux

As sysadmin, it is hard to tell if you’re  in physical or virtualized environment 😉

Below are some command line available to detect whether we’re in virtualized environment or not :

user@server1:~$ dmesg | grep -i vmware
[    0.000000] ACPI: SRAT 0000000041ef07f6 00080 (v02 VMWARE MEMPLUG  06040000 VMW  00000001)
[    1.470135] ata1.00: ATAPI: VMware Virtual IDE CDROM Drive, 00000001, max UDMA/33
[    1.510687] scsi 0:0:0:0: CD-ROM            NECVMWar VMware IDE CDR00 1.00 PQ: 0 ANSI: 5
[    3.420736] scsi 2:0:0:0: Direct-Access     VMware   Virtual disk     1.0  PQ: 0 ANSI: 2
[    3.421765] scsi 2:0:1:0: Direct-Access     VMware   Virtual disk     1.0  PQ: 0 ANSI: 2

or :

user@server1:~$ dmesg | grep -i virtual
[    0.290665] Booting paravirtualized kernel on bare hardware
[    1.268543] input: Macintosh mouse button emulation as /devices/virtual/input/input2
[    1.470135] ata1.00: ATAPI: VMware Virtual IDE CDROM Drive, 00000001, max UDMA/33
[    3.420736] scsi 2:0:0:0: Direct-Access     VMware   Virtual disk     1.0  PQ: 0 ANSI: 2
[    3.421765] scsi 2:0:1:0: Direct-Access     VMware   Virtual disk     1.0  PQ: 0 ANSI: 2

or :

user@server1:~$ dmidecode | egrep -i ‘manufacturer|product’
Manufacturer: VMware, Inc.
Product Name: VMware Virtual Platform
Manufacturer: Intel Corporation
Product Name: 440BX Desktop Reference Platform
Manufacturer: No Enclosure
Manufacturer: GenuineIntel
Manufacturer: GenuineIntel

or :

user@server1:~$ dmidecode | egrep -i ‘vmware|virtual’
Manufacturer: VMware, Inc.
Product Name: VMware Virtual Platform
Serial Number: VMware-56 4d a7 a1 10 59 2a e7-76 16 97 8a 38 5d 6e 1c
VME (Virtual mode extension)
VME (Virtual mode extension)
Description: VMware SVGA II
String 2: Welcome to the Virtual Machine


user@server1:~$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: NECVMWar Model: VMware IDE CDR00 Rev: 1.00
Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: VMware   Model: Virtual disk     Rev: 1.0
Type:   Direct-Access                    ANSI  SCSI revision: 02
Host: scsi2 Channel: 00 Id: 01 Lun: 00
Vendor: VMware   Model: Virtual disk     Rev: 1.0
Type:   Direct-Access                    ANSI  SCSI revision: 02

(Yet Another) Quick Botnet Analysis

Botnets are network of malware-infected machines that are controlled by an adversary. Our approach to in studying this botnet is to perform active analysis by using an actual malware sample, infecting the machine and observe its activities.

As we probe deeper into the network traffic collected by Wireshark, we find very detailed IRC functionality, attack commands, and capabilities. We learn that the ‘scan//” refers to a specific Denial of Service (DoS) attack function. Other notable strings include the IRC channel names like  “#dpi”, “#!” and “#Ma” which may identify the IRC channel in which infected computers are summoned. Similarly the string “HTTP SET” is instructing the infected system to download the malicious executable file from the remote web server (other malware distribution site).

As displayed above, we have to make some modifications on our irc client to join the botnet with the password “laorosr”. The modification is rather simple, loaded the IRC client with OllyDbg and modified the string “NICK” to “NCIK” which allowed our IRC client joined the botnets without any error messages.

Update for Gallus Nov 3, 2010

Here are some of the major changes in the recent Gallus:

  • Improved extraction of malform PDF object structure
  • Added CAPTCHA functionality within sample submission
  • Integrate virustotal API as ‘two-factor verification’ of sample analysis
  • Added support for Adobe LibTIFF exploit analysis and detection

If you happen to come across with error/bugs while using Gallus, feel free to shoot us an e-mail at honeynet (at)

No endstream, no endobj, no worries

In analyzing malicious PDF documents, being able to understand the format of its object structure is definitely useful. In order to look for malicious content inside the file, we might need to go through some of the process that’ll include interpreting the PDF object structure. The PDF object is enclosed with “obj” and “endobj”. Between the “obj” and “endobj” there are  usually  2 components, object dictionary and stream. Object dictionary are represented by keys and values that enclosed with “<<” and “>>”, while stream is a sequence of bytes. A stream shall consist of zero or more bytes bracketed between the keywords stream (followed by newline) and endstream.

The below snippet reflects the normal PDF object structure;

obj 1 0
<< /Length 12 >>

The obj 1 0 contains the dictionary (in between << and >>) of /Length (key) with value of 12. Below the dictionary, the stream exist with string “HELLO WORLD!” just before the endstream.  Finally, thehe object structure is closed  with endobj tag which indicate the end of object 1 0’s portion.

Although the PDF object structure is rather easy to understand, these structure can also be easily manipulated in many ways for malicious intent. The main reason of manipulation purpose is to break the analysis process particularly for PDF analysis tools.
How can the PDF object structure be manipulated? Usually attackers omit some syntax or tags  required within the object. This omission, however, seems to be considered as valid structure by PDF reader such as Adobe Reader. For example:

Object without “endobj”
obj 1 0
<< /Length 1337 >>

Object without “endstream”
obj 1 0
<< /Length 1337 >>

So-called bluff trick
obj 1 0
<< /Length 1337 >>
HELLO WORLD!endstream\n

In the 3 examples above, we can see that even when some components are dropped (or added) from/to the structure and  the PDF reader can still render the text without generating any error.

In the last snippet,  we can see the use the bluff trick to confuse the security tools in getting the right portion of stream. When pattern matching technique is used, the script/tool might not get the complete stream content since it got confused between the first and the second endstream. A proper handling of these manipulation should be considered thoroughly in order to get a reliable extraction.

Generalizing the security tools seems to be a crucial task in order for it to work in any conditions encountered. Pattern matching technique alone will not work. Understanding the format within the PDF object helps a lot in the process of generalizing the analysis tools.

For example, in a normal manipulation method, attackers cannot get rid of the “endstream” and “endobj”‘s tag simultaneously. Instead, either “endstream” or “endobj” or both will exist. From our rough solution, a regular expression like />>.*?stream(.*?)(endstream|endobj)/m can be reliably implemented with aid of other filtering mechanism.

New features added to MyKotakPasir 2

A lot of improvements has been added in the last 2 months including security fixes, producing better report output and making the back end analysis engine more stable.

The following are the list of updates:

  • Antivirus scanning results now being taken care by  VirusTotal
  • Import Address Table Hook result
  • Hex Dump output can be downloaded from the report.
  • More details in General Information section.
  • File submission now protected by Captcha to prevent evilness
  • Now MyKotakPasir has been made available to the public

Additional cool features will be available soon!

Feel free to have a go  at it here

Gallus, yet another PDF analyzer (alpha)

Introducing Gallus

Gallus is a web-based malware detection service specifically to extract and analyze suspected malicious PDF documents. It is a free service designed to help security researchers and public to detect exploits and extract other useful information contained in PDF documents.

How Gallus Works

Gallus is designed to extract and analyze the malicious components resides inside PDF documents. If the component exist, it will gone through a series of analysis to collect further malicious element that might exist.

Extracting and parsing

Usually, a malicious PDF document uses JavaScript code to trigger the vulnerability(s) and to execute the payload. By detecting and parsing the embedded JavaScript code, we are able to determine the maliciousness of the PDF document.


After the detected code is parsed, a series of analyses will be conducted to obtain the shellcode used for payload and also the vulnerability(s) that’ll be exploited. Most of the malicious PDF document will use obfuscation techniques to bypass the analysis process. To encounter such techniques, Gallus uses Spidermonkey to interpret the obfuscated code plus other deobfuscation modules.


From the malicious JavaScript code, we can determine the vulnerability(s) used. To name some of the exploit that usually used inside malicious PDF documents are:


Gallus is able to detect and extract shellcode inside malicious PDF document. From the shellcode obtained, we are able to determine the behaviour of the shellcode by using shellcode analyzer. In a usual cases, we might also found potential malware URL used in URLDownloadToFile payload.


Gallus categorize the submitted PDF document into Malicious, Suspicious, and Benign. Malicious status indicates the exploit and shellcode are detected inside PDF document. Suspicious status indicates the JavaScript code inside the document contains doubtful instructions. Benign status indicates the PDF document does not contains any exploit, shellcode, or doubtful code.

Using Gallus

Gallus allows sample submission via two methods, file submission and URL submission. Upon submitting your file, Gallus will extract and run various analyses to identify the content of the file.

To give it a try, click here.

From Adobe Reader exploit to Foxit Reader exploit

Today, Gallus received a PDF sample submission with md5 hash 37b98d28762ceeaa5146e2e0fc0a3fdd. Marked as malicious, I was compelled to investigate further on this sample after looking at the potential malware URL produced by Gallus report.

The PDF sample contains URLDownloadToFile payload that points to hxxp://77.x.y.Z/webmail/inc/web/load.php?stat=3DWindows. Traversing the URL at hxxp://77.x.y.Z/webmail/inc/web/, I managed to retrieve the HTML code containing the JavaScript code plus another source of (suspected) malicious PDF link.

From the snippet  above, it is obvious to see the <embed> tag contains a URL path to a PDF file. As a result of that, I managed to get another PDF sample, two.pdf, from the previous PDF sample. Submitting to Gallus however returns benign status, thus forcing me to analyze manually.

Looking at the content of the second PDF sample collected, I figured out that it tries to exploit the vulnerability of Foxit Reader 3.0 by using the “Open/Execute a file” action. The payload for that exploit tries to download malware from hxxp:// which already down at the time I tried to access.

Currently, Gallus does not support the detection of /Launch exploit yet. The updates will come real soon.

Please stay tune and fire us your feedback!

Credit: Mahmud

MyX1: SSDT Detector and Remover

MyCERT has developed a tool to detect and restore changed address of API made by rootkit. MyX1 SSDT Detector and Remover is a part of our  Malware Tracking project.

Figure 1: Screenshot showing  MyX1 SSDT

The application relies on two  two (2) files will be use upon execution:

1. ssdt.sys is used to list all available SSDT on current operating system.
2. ssdtdetector_remover.exe used to display result list of SSDT and hooked SSDT. There is an option to save to log file for the analyst.

This small tool can display list of current installed driver and restore changed SSDT address. For MyX1 Malware Tracking project, the ssdt.sys will be used to monitor SSDT changes from kernel level and produce log file for analysis.

LNK (Windows File Shortcut) Parser

CVE-2010-2568 will need to have a LNK file with a malicious dll to cause harm. Feeling the urgency of parsing the LNK file to trace any present dll, we modified a small portion of the code from metasploit’s project to make it run independently from the metasploit framework. The original code is here. The main purpose of the dumplinks.rb is for getting information for each of LNK files. The code is originally coded by davehull. Here is the output of the modified code:

The code in bold shows that the DLL that is  loaded in the LNK file. Below is the result from p0c provided by ivanlef0u.