Microsoft Access Trojan VBA code: The overlooked "macro virus"
--[ Brief Summary:
Microsoft Access Databases are not afforded "Macro execution protection"
in the manner of Word/Excel/Powerpoint documents. Attackers can insert
trojan VBA code into MS Access documents to execute arbitrary commands
on the remote machine.
There has been a great deal of discussion about MS Jet and ODBC not
affording appropriate protection to metacharacters, and the subsequent
inbound hooks from an IIS server. (I'm terribly oversimplifying an
excellent article by firstname.lastname@example.org et al:
http://www.securityfocus.com/bid/286) However, trojan applications have
created a nasty media stir in the recent past. With Office 2000
protection from macros, Access stands alone as unprotected. Hence this
spin on the trojan VBA issue.
There has been (perhaps too much) publicity surrounding the trojan/virus
capabilities of Microsoft Office applications which enable macro
The use of these trojans should subside now that Microsoft has
implemented more stringent security options into the Office 2000 suite.
Specifically, under Tools|Macro|Security there are three security
levels: High, Medium and Low (not recommended). The "High security"
setting is the default option for Word, Excel, and Powerpoint. This
setting states that "Only signed macros from trusted sources will be
allowed to run. Unsigned macros are automatically disabled." Bye, bye
Melissa. Thanx, Microsoft.
The Office 2000 suite uses Visual Basic for Applications (VBA) as it's
application-portable programming language. When a user records a macro
in Word/Excel/Powerpoint, the actions are translated into VBA code. The
subsequent VBA code sequence is then termed a macro, and afforded the
protections of the security settings listed above.
The Access application, however uses VBA as an integral part of forms
presentation and processing which is in turn an integral part of a
stand-alone Access application. You turn off VBA, Access is neither
shiny nor happy.
An attacker can craft an MS Access database with a single form which
auto-launches. When the database is opened, the form is presented
automagically. Within the properties of the form, the "On Open" property
(default sub of Form_Open) can contain VBA code.
It happens like this:
Double click Database (.mdb file)
Execute VBA code
The user simply opens the document, and the code is launched.
--[ What can VBA do to me?
Bad VBA code has been talked about in several threads. RFP mentions the
VBA.Interaction.Shell command which executes a command on the local
system. This is a quick and dirty payload, especially when coupled to
the "regedit /s" command which would allow an attacker to create a .reg
file, and import it into the registry.
A cleaner way becomes available, which is not available to the ODBC
method. The advapi32.dll API Reg*Ex allows direct registry IO without
taking the time to upload a .reg file. These functions can simply be
defined along with the hideous necesary constants inside the VBA code.
In addition, an attacker can follow in the footsteps of Melissa et al
and use the VBA.Interaction.CreateObject call to create an MS Outlook
instance which sends trojan email to every address in the addressbook.
Simply click the attached Access application to see the effect this
trojan can have on your system. =) Seriously, these examples require
quite a few constant definitions to work. If you're good enough to get
all the constants figured out, you're sharp enough to create these
examples on your own. In short, I didn't show you how to do it. ;)
Our REG*EX method simply relies on a syntactically clean call to
RegCreteKeyEx to create a registry key:
rc = RegCreateKeyEx(HKEY_CURRENT_USER, "email@example.com", 0, "", _
REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, secattr, Result, Disposition)
This line will create a key under HKEY_CURRENT_USER called
The other calls, including RegSetValueEx and RegDeleteKey do various
groovy things too.
In honor of Kwyjibo, we can use the VBA.Interaction.CreateObject method
to spread like wildfire thanks to MS Outlook:
---Snip from Melissa---
Set UngaDasOutlook = CreateObject("Outlook.Application")
Set DasMapiName = UngaDasOutlook.GetNameSpace("MAPI")
If UngaDasOutlook = "Outlook" Then
DasMapiName.Logon "profile", "password"
Set BreakUmOffASlice = UngaDasOutlook.CreateItem(0)
BreakUmOffASlice.Subject = "Important Message From " &
Access doesn't implement the System library like MS Word does. Hence,
the System.[doregistrystuff] calls won't work here. The system calls can
be replaced with just about any API you care to 'Define' in the VBA
code. Other VBA libraries such as the Application library shown above
may prove as suitable replacements.
Microsoft has certainly taken strides to protect against application
trojans within the Office 2000 suite. However, MS Access would have
to be (IMHO) gutted and fileted in order to follow the same security
measures. In the mean time, be sure not to trust every MS Access
database you stumble across in your inbox unless you're a pine
I have posted an example .MDB file illustrating some of the above
examples on my web site http://johnny.ihackstuff.com/ in the
security section. Be warned that the .MDB file will create
a top-level registry key called "firstname.lastname@example.org". I have
"protected" (*hrmph*) the code by disabling the VBA editor, and
shutting down Access as soon as the payload is delivered. Access
gets all pissy about that, and sends out a hideous error, but it
makes it a pain to use this maliciously.
Jake, Mac, Buddy, the Family
ADM, "...'cuz damn"
RFP for those writeups that take me days to really _get_
the boys and girls of CHAOS for keeping it real (the H.E.A.T. is on)
route for right pointers ;)
topher, coretez, dr. mudge, hobs, punkis
The boys of HL
"I'm Johnny. I hack stuff." - email@example.com