Back
  • This topic is empty.
Viewing 1 post (of 1 total)
  • Author
    Posts
  • #17081 Reply
    calliefuerst27
    Guest

    In this static malware analysis, we perform an analysis on a Zeus Trojan file (to understand its inner workings) but, we are not going to run the file as an executable. This is because malware authors have become (more) cunning as they try to make analysis of their handy work more difficult. They are encrypting some (or all) of the referenced “strings” in memory (such as the registry keys used to auto-start, hosts and ports the malware connects to). When they do this, we can’t just dump the process memory and run “strings”, when the “strings” are encrypted. We are even seeing “strings” encryption after the malware executable is unpacked. The values which are all stored encrypted will not show up in the unpacked EXE or a dump of the process. It is difficult to observe individual functions when we can’t figure out what they are doing.

    The ideal situation would have A Seasoned Administrator running “Ida Pro” to create and run a script to decrypt encrypted “strings” used in the “Zeus Trojan”. We would prosecute the decrypt and encrypt functions and once the bot was ready to access its “strings”, the pointer would be passed to the decrypt to decrypt the string in-place in memory. After the code calls to re-encrypt the data, the “strings” won’t show up in a process memory dump. The function is irrelevant but it relies on a key that’s calculated when the bot starts. It’s an MD5 of some other data embedded in the EXE file. But let’s break this into a Primer…

    Strings

    In Windows, if we are not faced with encrypted malware “strings”, one of the first things that we can do is employ a Windows utility called “strings” to see if we can get some information out of the file. This is actually a “Sysinternals” tool that allows you to extract UniCode or ASCII “strings”. When the file is sitting on disk and remove spam we’re not going to actually run it (which actually protects our system), we can run “strings”. When we do this, we may also get some additional information about the program we are running. At the command line type:

    C:usersAdministrator>z:

    Z:>y:

    Y:>cd Downloads

    Y:>Downloadsstringsdir

    Y:Downloadsstrings

    We can run “strings” by typing “strings”.exe” where you are prompted to agree to “Sysinternals Software License’s” terms.

    “Strings” will go through an executable and find sections where there are “strings” or printable ASCII characters that are null terminated. As it finds those, it can print them out. The output will make it clear what we have going on as we observe the individual functions.

    If we have Microsoft code we may see “Microsoft Corporation”, “Redmond Washington,” “Microsoft Code Signing”, etc. written out. We may see Microsoft URLs and timestamps all built into the code. We may even see the name of the codes author. “Strings” can actually provide us with some pretty useful information.

    Exe Explorer

    Another program we can employ is “Exe Explorer” which will give us a different set of information. It is software designed to read and display executable file’s properties and structure. EXE Explorer is mainly focused on gathering data about the targeted file. The user is given the ability to read the properties of the EXE file such as its code page and the raw data offset.

    “Exe Explorer” opens up an executable and allows us to see its directory called Zeus (from the Zeus botnet) where we can go and open up “bot.exe”. “Exe Explorer” pulls that executable are part and gives up information showing the “bot” is destined for a 32-bit machine, which means we are dealing with 32-bit code. On the signature line we will see that this “bot” is a “portable executable”. This means it is an executable design for the Windows operating system.

    There is a tab in “Exe Explorer” called “strings” which does the exact same thing the “Systems Internals” utility does. This particular “strings” in “Exe Explorer” actually provides additional information.

    The “strings” in “Exe Explorer” has a lot of function calls within it like “Gdiplus start-up”and “Gdiplus shut-down” which are a graphics device. The “Gdi” (suite of functions) have to all do with graphics. A malware program with this suite will have a graphical component. If you can see a create stream, it would probably indicate some sort of file or network communication (“on H Global”). It could be grabbing some images or graphics.

    You can look for other functions in the file but you will also see a lot of garbage in the file. Sometimes the garbage is Opcodes and sometimes it is just other types of data. You will also run across encrypted “strings”. You also see data that appears to be “strings” but is not.

    You will see a tab for the different sections. “Exe Explorer” pulls the entire executable apart and shows you a unified view of what is going on within the file. You get a lot of detailed information about the executable.

    PEid and Packers

    Now that you have information via the “strings” that may provide information concerning the actions being taken by the executable you can run an application called “PEid.exe”. This program will examine the algorithm and tell you if a piece of software is packed or not.

    Once we have located the file we will open up with “PEid.exe” and look for Packers, we are getting into the meat of the executable. Packers are usually located via deep scans. Packers obscure a piece of code to make it harder to see what is being performed by the executable. Garbage in the “strings” could have been the result of packers being present in a piece of code. We can’t see what is happening because the “strings” have been compressed or encrypted which we wouldn’t be able to see.

    When you see an executable piece of code that is packed you are probably dealing with a piece of malware. Different Packers are associated with different versions of malware. We may actually get some information on the malware based on the particular Packer that is present within the executable file and the version of the Packer that is in use.

    Static analysis just looks at components of the files. You can click on the properties of the file and look at the details to see what is available. A normal program developed by a reputable vendor is going to have a description, a copyright, a product name, a product version and possibly even a file version. It is going to have information along those lines. If this information is missing, it is either written by someone who doesn’t want to set that information or someone who doesn’t know how to set that information. You can basically find out some information about the author of the executable by looking in the properties under the details.

    Conclusion

    We have observed several techniques and tactics for examining Windows malware in a static way (where it is actually not being run). The logic of this is we avoid the danger of running the malware in our system. Dynamic analysis of Windows malware (which allows us to run the executable and observe its characteristics) will require either a sandbox or standalone system where it poses no danger to your operational network. Dynamic malware analysis gives us the chance to analyze the malware while it is in operation. Static malware analysis allows us to examine hints from the executable or the file itself to see it we can figure out what is happening (just by looking at the file), what is in it and the information we can pick out of an executable by digging in and observing the characteristics.

    Cee Simpson is a Security Systems Analyst with EZMobilePC.com. He has over 20 years experience as an active duty and contract Network Administrator with the DoD.

Viewing 1 post (of 1 total)
Reply To: Windows Malware Analysis
Your information:




×

 

Hello, salut, witam, hei, Γεια σας, hola,

Click one of our contacts below to chat on WhatsApp. If you do not use this messenger, feel free to write us an e-mail or take part in the forum.

× Chat with us!