Keeping strings real - Part II

In part 1 of keeping strings real, strings were chased around in a disassembler to provide insight into the functionality of a piece of malware. Part two investigates the instance where there seem to be no recognizable strings in the target at all.

When doing a quick skim of a malware file (in this case, ldr.exe md5:007571544614a7646e750a51ccaf2e9e), sometimes you encounter data that looks similar to the below image. In this particular instance, it seems that these strings are encrypted.

Encrypted strings make it very difficult to do quick analysis. Fortunately, a there are a couple of options to get past this small road block. The string can be observed as it is passed around between functions, or debuggers can be used to halt execution when the target string data is accessed.

For this sample, the above strings were followed from the initial cross reference to a function that is self contained. It takes arguments, executes some code, and returns. The code has a loop, operates on individual bytes (reads from pointers into register halves), and performs a few additions. Is this a possible candidate for a string decryption? You betcha.

After walking through the function once in a debugger, it becomes obvious this function decrypts the string to a different buffer. This is an excellent first step, but there are a massive amount of strings in this file. It would be less than desirable to execute this function in a debugger and make note of the result for each and every encrypted string present. There has to be a faster and more elegant way to figure these out. Now what?

Enter Cryptanalysis. This particular function is not very large or complicated, so determining the algorithm used to reveal the strings should not take an unreasonable amount of effort. After determining the algorithm, it is possible to write a program or script to accept the encrypted string data and output the decrypted string.

Below is what the reversed function looks like.

This function accepts what looks like a null terminated pascal string. The first character in the string contains the length (0 to 255), followed by the ciphered string data, then a zero to indicate the end of the string.

The next step is to add the cipher key value to the first encrypted character in the string. This key value starts at 186 (or 0xBA in hexadecimal). On each loop pass, the key is increased by 2 and added to the next character in the string.

For instance, the character 'a' is represented by the number 97 (0x61). To encrypt this initial data based on the algorithm above, we would subtract 186 (0xBA). To decrypt it later, 186 (0xBA) is added to the encrypted data.

The result of this 97 - 186 subtraction is 167 (0xA7). This math looks funny, but it works this way when working with individual bytes and their associated range of 0 to 255 (unsigned).

This behavior is due to the wrap-around effect caused by an integer overflow. To see this in action on Windows, open calculator (calc.exe), change the view to scientific mode, then change the number system from decimal (Dec) to hexadecimal (Hex), lastly change the size from "Qword" to "Byte." Now you can type in 61 minus BA and the result is A7 (167).

Keeping the above math in mind, the algorithm can now be re-implemented using IDA's built in scripting language (IDC). The script will be need to be passed the source string data, extract a byte, add the key to the byte, store the result, add 2 to the key, and repeat this process till all bytes in the string have been processed.

The Byte() function will be used to extract the byte from the "address" of the string's beginning found in IDA's dissassembler window. The Message() function will display the deciphered byte in the message window, and the PatchByte() function will modify the representation of the byte inside of the disassembler window. (Note: PatchByte() can be commented out to prevent the script from actually modifying any data, it will simply print the result in the message window)

The script representation of this algorithm reconstruction is found in the image below, and the idc script itself can be downloaded from our PC Tools ThreatFire forum, where you can log in and scroll down the thread for 186plus2_decipher.zip:

Now it is time for some fun. An encrypted string is selected in IDA for decoding and the script is launched. The result:

Keeping strings real - Part I

All malware researchers love strings. They allow us to gain valuable insights into the possible behavior of the sample being investigated. Even IT professionals, who do not research malware professionally, can make good use of these clues.

Here's a quick example of strings in a malware disassembly listing:

00403100 Security Troubleshooting.url
00403120 ot.ico
00403128 %s/soft/?c=%1.1d%d%1.1d
00403140 Online Security Guide.url
0040315C ts.ico
00403164 %s/test/?c=%1.1d%d%1.1d
0040317C Online Security Test.url
00403198 *.securemanaging.com
004031B0 *.safetyincludes.com
004031C8 *.securewebinfo.com
004031DC 85.255.117.158
004031EC 88.255.74.197
00403300 195.95.*.*
0040330C 194.187.*.*
00403318 turbocodec.com
00403328 flyvideonetwork.com
0040333C websoft-c.com
0040375C plus-codec.com
0040376C freerealitympegs.com
00403784 inc-codec.com
00403794 user_pref("browser.search.selectedEngine", "Search");
004037D0 user_pref("browser.search.selectedEngine"
00403840 \profiles.ini
00403850 Mozilla\Firefox
00403908 Software\Microsoft\Internet Explorer\New Windows\Allow
00403940 %sVersion\Internet Settings\ZoneMap\EscDomains\%s
004039A8 Domains\%s

Right off the bat, one might guess that there is probably something fishy going on with these domains in relation to Firefox and Internet Explorer settings. A quick google search on some of these domains yields many results which are seemingly related to malware. If the search result is some what ambiguous, a researcher can always plug a string into ThreatExpert to find related malware behavior.

Searching for "securewebinfo.com" on ThreatExpert yields plenty of results. Most of the strings found in this particular sample match up very nicely to the results found, so it is reasonably safe to assume that this sample is probably a variant. However, if the search results were inconclusive, one of the next steps a malware researcher can take is to disassemble the file in the IDA Pro.

What is this malware actually doing with those strings? We are glad you asked!

Below is the image of the strings in the disassembler. The following items are shown moving from left to right: the address in memory where the strings reside, the automatic name IDA gave this location, the string data itself, and last but not least, the cross reference (XREFs).

Navigating to one of the cross references changes the view to an array of string pointers as seen in the image below. This array also contains a cross reference, but to a function this time.

The function seen below was labeled "modify_IEXPLORE_SecurityZones" as it was found to call sub-functions which modify the registry associated with Internet Explorer's Security Zones.

The last loop in this function, "AddAllowPopup_loop", executes once for each item in the domain_name_array. Each item in the array will be added to the AllowPopup registry key. The next time Internet Explorer is run, those domains will be allowed to display pop-up windows at will. This code confirms our suspicions of malicious behavior.

AMTSO and CARO Workshop

The AV industry was busy this past week amongst the blooming tulips in Hoofddorp, the Netherlands. Both an AMTSO conference and a CARO workshop was held the last three days of the week.

A large group of attendees arrived for the Wednesday all-day testing standards meeting, with more journalists in attendance than before. It was encouraging to see, because one of the AMTSO's formative goals has been to invite and include representatives from all parts of the computer security industry. Progress is being made toward a set of testing standards for anti-malware products for everyone involved.

The CARO workshop followed on Thursday and Friday, with presentations focusing on malware obfuscation from the AV industry's perspective (googling "datasecurity event caro" provides a link to the home page). The opening talk by Paul Ducklin from Sophos set the tone for most of the event -- legitimate compressors/packers are acceptable and good (according to a number of individuals in the AV scanner business), while software protection solutions like Themida and SVKP are unacceptable and evil (to a number of individuals in the AV scanner business).
It was interesting that while AV vendors and Ilfak Guilfanov of IDA Pro/Hex Rays spoke and gave presentations over the two days, none of the developers or vendors from Themida or ASProtect (a couple of software protection systems that were referred to in the presentations) were invited or presented their thoughts.

Even at the workshop, it seems that there remains disagreement on how the industry should handle software obfuscation, and there remains a sense that software obfuscation is a major source of problems for the AV industry. Whether it's due to difficulties in emulation, performance issues when unpacking, the complexities of the virtualization packers (where Sophos' Boris Lau showed that a single NOP instruction can be easily and inexpensively be translated into over 50 virtual instructions) or simply disagreement over how to identify what is behind software protection, it continues to be a weakness for traditional AV scanners.
Just to give an idea of the volume of difficulties and tricks that researchers have to develop methods to deal with, Peter Ferrie's paper was presented by Mady Marinescu of Microsoft, and in it he enumerated over 50 anti-unpacking tricks commonly seen in packers and often seen in malware.
Presenters also included evaluations of the proportions of malware seen packed by specific packers and various approaches to dealing with them, including blacklisting. It seems that it is easier to include this approach in a scanner than to have to actually implement an unpacker in a scanner for all the different varieties of packers. Blacklisting is cheap and easy, but is more prone to causing fp's, and often decisions to blacklist may be debatable.
We will see what this turn away from extremely low false positive rates will do to the major advantage that the scanners had over behavioral based solutions.

From the perspective of an individual pushing a behavioral solution that solves for the difficulties that scanners have with obfuscation, it is somewhat easy to be critical of AV scanner products' inability to continue performing with such a low level of false positives and exacting matches in the face of ongoing obfuscation and "server-side polymorphism"/"rapid release" techniques currently used by malware distributors to evade the AV solutions. The complexity and difficulties are high for the guys trying to develop elegant and effective AV solutions to these problems.
We'll see more of this obfuscation topic, but from the "hackers" perspective, when defcon's "Race To Zero" contest is held this fall.

Reversing a suspicious dll continued

In a post earlier this month, I presented steps for unpacking and restoring the IT/IAT of a suspicious BHO for analysis purposes. In that case, it was packed with a tool called "Upack", otherwise known as the "Ultimate PE Packer" by its author Dwing. Upack often is used on executable files around 40kb in size. It compresses the file's contents with the LZMA algorithm and adds an unpacking stub to the target file for self-decompressing at runtime.
In other words, to make a file smaller for download and delivery without requiring a decompression utility like WinZip or WinRar to already be installed on another system at runtime, an author can compress their executable creation with this tool.
This posting will work with the PE file that was recreated from that previous work.

Here are some of the steps we used to work on this file, leaving off at the last step to identify some behaviors of this malicious file:
Change PE file to .exe in PE header, rename dll to exe extension
Load into Ollydbg
Find OEP (original entry point) -- pretty easy with Upack
Break at oep and dump file from memory to disk
Fixup IAT with ImpRec and write to dumped file
Rename fixed file and modify PE header back to dll
Load into IDA Pro 5.1 with the IDA Python plugin installed...

When we load this file into IDA Pro, the disassembler now can provide a listing that can be used to reverse engineer the component's functionality. Without properly unpacking the file and fixing up the imports, the disassembler cannot analyze the code.
However, the listing doesn't seem to immediately reveal much about the component's activity. But knowing that this component is a BHO helps identify key areas for reversing progress. We do see fundamental Win32 API calls like "AtlInternalQueryInterface" and "AtlComPtrAssign", leaving clues about COM programming within the component. The location of these calls can lead us further down the control flow to locations where COM calls can be further analyzed and easily understood. Joe Stewart published information about reversing OLE, but this code is more complex than a common SubmitHook trojan.
Frank Boldewin's Python scripts come in handy for walking through these COM calls -- the listing now reveals a section where the code obtains the "document" interface within the web browser and enumerates its connection points. We can set memory breakpoints on these sections for further analysis, and when we visit various banking web sites, we can see that the BHO is building an event sink:

















Once the event sink is set, GetKeyState is then called on "KEY_DOWN" events. The component can check on each individual keystroke as they are hit. And it appears that the only keystrokes being checked are the ones emanating from the userid and pass input fields.

So, we've got a dll that identifies Urls of banks and other financial institutions and, after parsing and identifying an "interesting" Url, then constructs an event sink attached to very specific fields within the browser's web page -- namely, userid and password input fields. This ActiveX component will log these keystrokes and send them off the system. The component calls "HttpSendRequestA" to send off the banking usernames and passwords it just collected from these fields. I think that we've found an interesting piece of malware, quite possibly a password stealer for banking websites. We'll add more technical detail to this post as time permits.
It helps to be able to dump this file and modify it for static analysis.

Unpacking a suspicious dll -- top to bottom

Fyi, this writeup is geared to satisfy curiosities about technical stuff, to start responding to some of the interest expressed over at our forum. You have been warned...

We use Ollydbg for all sorts of things around here. It's an outstanding tool. In fact, Olly himself found some spare time and is releasing a new version soon. He's got the pre-alpha version 2 code available on his website.

His debugger is a very useful tool for reversing user-mode software. When we're looking to get to the bottom of a suspicious component, one way is to fire up olly and get started. Unfortunately, there are challenges to that approach. Sometimes, we need to understand what a dll or other component is doing as well, and sometimes those dlls and other components are packed.
There are other tools that we use, and this post will survey the steps for using them while unpacking a dll...you can find this sort of information all over the web, but the writing styles sometimes make understanding the content very difficult.
Some of the fine reverse engineering tools available are
Ollydbg
LordPE
Import Reconstructor
IDA Pro

In our labs, we have a suspicious dll to examine. Apparently, it was installed as a bho into Internet Explorer:





















When you load this dll into Olly, the tool reports that its listing of the binary's instructions are most likely inaccurate. IDA Pro can't disassemble the binary either.
So we can use a couple of tools to help identify if this executable has been tampered with. One popular tool is PEiD. PEiD detects "Upack" as the packer used here, and usually is pretty accurate. You can also take a peek with ProtectionID.
Upack is a very simple packer, used to compress executables, and can make file examination only somewhat difficult. There are no antidebugging tricks that it employs to be concerned with. Here is PEiD in action, identifying the file as packed with UPack by Dwing:























If we want to load it into olly and dump it for full unpacking, one way to start the unpacking process is to simply rename the file extension to "exe" and modify a flag in its PE header so that windows loads the file as an exe, not a dll. You can take a course from a reverser like Jason Geffner on deobfuscation and read all the PE documents, then perform the math, pop open Ultraedit or hexedit and manually edit the file's PE header. Or you can run LordPE on the file and simply deselect the "Dll" checkbox under its file characteristics:
























After you save your modification, load up the file into Olly and identify the program's original entry point, or OEP. This work can be time consuming when learning about a new packer. But Upack is a simple packer. It's much like UPX, the industry standard, but it uses the LZMA compression algorithm. A reverser might notice that the first instruction of the unpacker is "pushad", followed by a call instruction:

















The easiest thing to do would be to scan the rest of this section for a matching "popad" instruction followed by a jmp to the beginning of the lzma decompressed code. When we do that, we find a popad (a restore of all the register values that were pushed onto the stack at the beginning of the unpacker stub) followed immediately by a jmp to the .Upack section that was previously empty:























At this point, we can hit "F7" to step into this new code section, use Olly's "Analyse" function and voila, we see
push ebp
mov ebp, esp
and we are most likely at the dll's original entry point (OEP):






















Great! Now, using LordPE again we can dump the file to disk and fix up the Imports with ImpRec. Here's a view of LordPE options for attaching to a process and dumping an individual module to disk:











Now that we have the image dumped to disk, we can use Import Reconstructor to attach to the dll's process as it is suspended at its OEP, find the import address table in memory and then fixup the dumped image on disk:























We have to provide ImpRec with the OEP. Hopefully it then can find the Import Directory and IAT for us, and with UPack, it reliably completes the fixup for us. Clicking on "Fix dump" and selecting the image dumped by LordPE will provide us with an unpacked file that we can next throw into IDA Pro for disassembly and analysis, which will be another post:























Hope that satisfies some of the curiosities of our forum readers, next we'll take a look at some of the malicious behaviors this dll performs.


Note- This example worked through one of the simplest packers out there, Upack. For more information on unpacking tricks, you can find a couple of awesome lists of tips and tricks related to anti-debugging/anti-reversing and at openrce and Mark Vincent Yason's Blackhat paper.

Spyware Doctor bundle?

This morning, we were observing a surge in hits from an Armadillo/SoftwarePassport packed Rbot variant. It looks like this one might be distributed over a P2P network. AV scanner detection appears to be fairly spotty for now:


























When we are looking through files that come in, we see the work of fairly underground joiners/stickers of all sorts -- microjoin, minichain, exebind, etc. These tools are used to bind an executable to another file package, so that a stub is added to the original file along with the bot, and they are "binded" together. That way, when the unwitting victim receives a bound file, they'll think they are running one executable when really they are running two.
An interesting example came in this morning: sdsetup.exe. Interesting, because the filename is the same as the PC Tools product installer for SpywareDoctor. And the icon of the file appears to be the one that PC Tools uses for their SpywareDoctor product. However, here are some properties of the file that appear when you right click on the installer file and select "Properties". The file is missing a digital signature, and the file's "Description" is "Win32 Cabinet Self Extractor". It seems fishy right off the bat, because that's a legitimate tool normally used to build installers and files that bind more than one executable together, just like the underground binders we see all the time:

















Now, below is a genuine installer from PC Tools. Cool icon, huh? You can see the file's properties by right clicking on it again. Notice the "Digital Signatures" tab, the "PC Tools" signer name, and the confirmation that the signature itself is ok from Verisign. This countersignature provider confirms that the file is from PC Tools, much like a Notary Public's stamp would for a legal document:




















Now we run the file that arrived with the odd Description property and is missing the digital signature. BAM! a new executable is created in the system directory and silently executed. This little obfuscated Rbot treat comes with keylogging capabilities and more, and calls home to a computer running on a dsl line here in Kansas City in the U.S. The server is down for now, but it appears to be cycling through ip addresses:


























Reason to be alarmed? Not really, this technique commonly is used by creeps every day. But there are lessons to be learned here. If you are going to install a product, do not get it from your favorite P2P collection. Instead, go to the source, like the PC Tools or ThreatFire web site.
And, if you are going to run an executable, you can check it for a digital signature. It's one more layer of security -- the signature helps confirm that the source of the executable is genuine.

Online games and false positives

Online games have always had the problems of cheats, password stealers and bots. Volumes of information have been written on the topic, including Hoglund and McGraw's published material. In response, game developers at studios like Blizzard Entertainment and Amped have developed ways to unexpectedly "govern" the software that is running on their users' systems, and ways to "harden" their software against reverse engineering attempts. For better or worse, these "tools" have turned into somewhat intrusive tools that peek into everything on the system and prevent RE activity using methods similar to those used by malware writers.

Sometimes, these defenses cause problems for the software security industry. You can see here from virustotal signature-based scan results today that our Tantra-playing friends in the Phillipines trying to play "Tantra" might be interrupted by their game's security software:


























These problems cropped up with today's binaries, and have cropped up in the past. In August, AVG already was detecting the "tantrum.exe" component as a virus with its generic packer detections: Regarding Virus "obfustat.iiy" On Wr Ph, Problem Fixed
The problem, in part, for the av signature-based products seems to be the packer. The packer that Amped is using, Molebox, is polymorphic and provides some difficulties for black, grey and white hat reversers trying to peek into the code behind their tantrum.exe component. Malware writers and distributors in the recent past have used molebox to evade detection and make their creations more difficult to reverse engineer. You might notice that the screenshot above shows that Ikarus detects the component as "Rbot".

For behavioral-based security products, a problem arises when these components, which have very similar file characteristics to malware that we've seen, exhibit behaviors similar to malware. For example, this Tantra game component injects itself into operating system components in the same way as backdoors like Bifrost and other trojans.

For now, it seems that these problems will be ongoing. The game developers need to protect their games the best that they can, and security software products need to be as sensitive as possible.

Undetected bot activity

We're seeing a pretty dramatic uptick in bot activity today. With all the attention that botnet activity has been getting lately, I thought that this stuff was going the way of Ruben Studdard. Anyways, unfortunately, we are also seeing a very low detection rate for the major AV players, with most of the detections in the scanners supported by Virustotal coming from somewhat unreliable heuristic based detections:

File V received on 11.16.2007 21:22:05 (CET)
Antivirus Version Last Update Result
AhnLab-V3 2007.11.17.0 2007.11.16 -
AntiVir 7.6.0.34 2007.11.16 HEUR/Crypted
Authentium 4.93.8 2007.11.16 -
Avast 4.7.1074.0 2007.11.15 Win32:IRCBot-CFX
AVG 7.5.0.503 2007.11.16 Obfustat.VTU
BitDefender 7.2 2007.11.16 Packer.Krunchy.B
CAT-QuickHeal 9.00 2007.11.16 (Suspicious) -
DNAScanClamAV 0.91.2 2007.11.16 -DrWeb 4.44.0.09170 2007.11.16 BackDoor.IRC.Sdbot.2056
eSafe 7.0.15.0 2007.11.14 -
eTrust-Vet 31.2.5300 2007.11.16 -
Ewido 4.0 2007.11.16 -
FileAdvisor 1 2007.11.16 -
Fortinet 3.11.0.0 2007.10.19 -
F-Prot 4.4.2.54 2007.11.16 -
F-Secure 6.70.13030.0 2007.11.16 -
Ikarus T3.1.1.12 2007.11.16 Virus.Win32.IRCBot.CFX
Kaspersky 7.0.0.125 2007.11.16 -
McAfee 5165 2007.11.16 -
Microsoft 1.3007 2007.11.16 Backdoor:Win32/Poebot.V
NOD32v2 2664 2007.11.16 -
Norman 5.80.02 2007.11.16 -
Panda 9.0.0.4 2007.11.16 Suspicious file
Prevx1 V2 2007.11.16 -
Rising 20.18.40.00 2007.11.16 Trojan.Win32.Agent.vyl
Sophos 4.23.0 2007.11.16 Mal/EncPk-BP
Sunbelt 2.2.907.0 2007.11.16 -
Symantec 10 2007.11.16 -
TheHacker 6.2.9.132 2007.11.16 -
VBA32 3.12.2.5 2007.11.16 -
VirusBuster 4.3.26:9 2007.11.16 Packed/FRBR
Webwasher-Gateway 6.0.1 2007.11.16 Heuristic.Crypted

This low detection antivirus scanner rate may be due to the use of the kkrunch packer.
Threatfire has been identifying it as "Trojan.CnomBot".
The bots are all reporting back to a server in China. We'll keep you updated.