0day Wednesday - research on the latest malware
Some might call it insane. For me, it's just a medium.
I got it yesterday, and I figured it out today. It came to a load to the java exploit from the old 2012 CVE (SecurityManager, I suppose). I call it 0day [1] , because it is not in the databases VirusTotal / Malwr in any way - neither packaged nor unpacked.
Attempt analysis in IDA [2] fails:
')
It seems that the asshole who did this most likely knew that someone like me would try to do an analysis. In any case, there are not too many variants of exe modifications that drive the disassembler crazy, but it ignores Windows.
Examining the exe file in CFF Explorer , we see an error in one of the NT headers, namely, in the “Data Directories” on the value of the Delay Import Directory RVA. CFF is wonderful because it immediately highlights the value 0x00000040 as incorrect. Zanulyaem it to correct the error.
Save the exe and re-open it in IDA - now there is no error and the opening takes place without a hitch.
A quick inspection reveals that this is MFC [3] -attachment. How do I understand this? This is explicitly stated in the Library column of the import section.
The application, of course, is packed. Memory is packed. No modified section headers, banal packed memory.
Well, static analysis is not an option. For further research, dynamic analysis is required. Immunity drafts bald!
Before plunging into Immunity and the virtual machine, it is worth noting a couple of interesting things that are not visible in the IDA, but were seen in the CFF Explorer. For starters, there are a couple of files that, to the delight of Captain Obvious, are hidden in the resource directory.
The first is the PNG file:
Second - HTML page:
Strange. Having loaded a PNG file into IrfanView (the best viewer for images, by the way), we see a small black rectangle that doesn’t quite fit in with its size of 55 KB. Surely something is hidden inside. Steganography ?
Now look at the HTML page. After downloading and cleaning it in Notepad ++, we get something similar to the browser type definition script.
Why all this is in the resources section, and even unpacked, remains a mystery. We will return to the resource section. For now, continue unpacking.
Launch Immunity Debugger and Virtual Box and load anti-anti-debug python plugin.
After the process is completed, you can drain the memory and do its analysis:
I noticed several areas of memory marked as Read Write Execute (RWE). One of them is at 0x00910000, another one is 0x00930000, the next is 0x00940000 and, finally, the last is at 0x00970000. Further analysis shows that only 3 out of 4 contain programs. However, three programs to hide in one? Good Easter eggs.
Now we will dump our programs for further analysis. We load OllyDumpEx and feed our 0090 areas. It is seen that the programs at addresses 0x00910000 and 0x00970000 coincide with the original, judging by their size, section headers and characteristics. And the area at 0x00950000 is different from them: other section headers, other sizes. It must be that golden egg (I left a literal translation, because the author uses the golden egg in his screenshots later on - approx. Transl.).
We will dump our exe using Binary (Raw) mode instead of Rebuild mode to preserve the integrity of the dump.
Two section headers indicate that the program is packed using UPX [4] . Running the upx utility confirms this. So we can easily unpack our egg.
The new exe is about 40KB larger and unpacked correctly, so now we can finally feed it with IDA. Looking at the lines, we see interesting things.
This is an HTTP request. Looks like this thing is sent home to mommy using a POST request.
You may ask - what about the C & C server? It does not seem to be contained in the program in plain text form. Remember, I asked you not to forget about the resources section? Look at the resources section of our golden_egg.exe
Voila http://31.207.6.161. It is wonderful to provide us with an open address. Security through obscurity strikes again.
You are probably wondering what happens when the main application runs. Let's get a look:
At boot time, it automatically closes my Process Explorer and for any attempts to load the task manager responds with the message "task manager was disabled by the administrator" before closing almost instantly. I wanted to take a screenshot, but it turned out that I was not so fast. Turning to Immunity, we see that the original “golden_egg.exe” program has already been completed. Instead, some other program with the name “zpNvNKSi.exe”, launched from the tempo directory. Compare hashes - and they seem to be the same:
(Did you like my hasher? You can download it here without registration and SMS )
The commercial break is over, now it is clear what the program is doing - the task manager is turned off, it kills "unwanted" applications and is launched from the temp directory. The msconfig check shows 2 new entries in autoload:
I checked both files and they were byte by byte matched with the original program.
Attach to the program with Immunity, look at the memory and the number of threads (by pressing the "t" key) - we see that the program is multi-threaded. I counted 12 threads.
I assume that each thread watches if one of the other threads is killed. However, by suspending the process, we can look into its memory using Process Explorer. The analysis shows that there are lines that were not shown in IDA:
Suddenly. I think that the program checks these utilities and forcibly closes them if they are running. This explains why I could not use Process Explorer while the program was running. Quite a way to complicate the launch of any of these utilities, instantly killing them. In the list you can find regedit, LordPE, Wireshark, regmon, filemon, procmon, tcpview, taskmgr and even Windows Defender. Severely. True, I do not see a cousin Process Explorer'a - Process Hacker .
Returning toour rams of our memory: it is obvious that the program either obfusts lines or packs them twice. In any case, let's see.
Having performed a search in memory of one of the strings in the Unicode encoding, we see that the string “taskmgr” is in the .data section. Did IDA really lie about the lines? Not really. We try again using slow Binary search (Alt + B) - and we find more rows. Apparently, IDA does not show Unicode strings when searching by default. You can change the search parameters in IDA by pressing Alt + A and selecting Unicode.
The analysis of new lines reveals more functionality of the malicious program.
Interesting.
Considering the fact that our attempts to start Wireshark will be blocked by the program, it is necessary to find the function responsible for forcibly terminating the programs and patch it. How to do it? Let's look for the api TerminateProcess () call.
Using IDA, it's not that difficult. In the import section, we find a link to TerminateProcess.
It looks like a kind of loop that scans the names of the processes by calling CreateToolhelp32Snapshot and, if they meet a condition, completes them. It seems that the list of process names that we saw earlier is used here.
So what can we do? We can change the logic of the program so that instead of calling TerminateProcess will occur ... and nothing will happen. Having checked the Xref-th subroutines (eXternal REFerences), we see that the function is called from the 0x00401D2A sub-program. It contains the jnz instruction, which performs a conditional transition to a subroutine that scans the processes and completes them. If we can patch the program in such a way that this subroutine is not called, we can run any utilities from the blacklist.
We drop the sleeves. I prefer to patch using Immunity - it's pretty simple, and I am familiar with this better. Let's start with the search subroutines in our exe. The instruction with conditional branch is located at 0x00401D4E. We dig up the whole area - thus, we immediately proceed to the execution of ret instead of going to the address 0x00401D2C, where the completion of undesirable processes occurred.
We resume the program execution and try to start one of the prohibited programs. It seems that everything works, since regedit was launched, and Process Explorer was not forcibly completed.
Finally, you can conduct a detailed analysis of network activity using Wireshark, as well as activity in the file system and registry using procmon, and indeed play with a running program in Process Explorer.
Process Explorer shows that a SYN has been sent [5] the package to our C & C server (yes, the one whose address we pulled out of the resource section) to port 80.
Wireshark gives a little more information. Here we see not only the SYN packets sent to our HTTP C & C server, but also a large number of DNS queries to get information about strange domains. What's next?
The server will continue to knock home, but I do not need it. I could modify the resources section in our “golden_egg.exe” to wrap it on my own HTTP server and explore its functionality, but this is quite labor intensive. We already have quite a lot: the C & C server, the unpacked program, its HTTP signature, and we also know about its behavior. Case is closed. Another 0day Wednesday came and went.
If you want to download the malware and tinker with it, you can get it here . Password "infected".
I hope this small study will be useful to you. Successful quacking!
By Joe Giron
Original article
1. ↑ 0day (English Zero Day) is a term for malicious programs against which protection mechanisms or vulnerabilities have not yet been developed.
2. ↑ IDA Pro Disassembler (Interactive DisAssembler) is an interactive disassembler that is widely used for reverse engineering.
3. Microsoft Microsoft Foundation Classes (MFC) is a C ++ library developed by Microsoft and designed to facilitate the development of GUI applications for Microsoft Windows by using a rich set of library classes.
4. ↑ UPX (the Ultimate Packer for eXecutables) is an executable file packer that supports several different platforms and file formats.
5. ↑ SYN - packet sent by the client to the server to establish a connection.
I got it yesterday, and I figured it out today. It came to a load to the java exploit from the old 2012 CVE (SecurityManager, I suppose). I call it 0day [1] , because it is not in the databases VirusTotal / Malwr in any way - neither packaged nor unpacked.
Attempt analysis in IDA [2] fails:
')
It seems that the asshole who did this most likely knew that someone like me would try to do an analysis. In any case, there are not too many variants of exe modifications that drive the disassembler crazy, but it ignores Windows.
Examining the exe file in CFF Explorer , we see an error in one of the NT headers, namely, in the “Data Directories” on the value of the Delay Import Directory RVA. CFF is wonderful because it immediately highlights the value 0x00000040 as incorrect. Zanulyaem it to correct the error.
Save the exe and re-open it in IDA - now there is no error and the opening takes place without a hitch.
A quick inspection reveals that this is MFC [3] -attachment. How do I understand this? This is explicitly stated in the Library column of the import section.
The application, of course, is packed. Memory is packed. No modified section headers, banal packed memory.
Well, static analysis is not an option. For further research, dynamic analysis is required. Immunity drafts bald!
Before plunging into Immunity and the virtual machine, it is worth noting a couple of interesting things that are not visible in the IDA, but were seen in the CFF Explorer. For starters, there are a couple of files that, to the delight of Captain Obvious, are hidden in the resource directory.
The first is the PNG file:
Second - HTML page:
Strange. Having loaded a PNG file into IrfanView (the best viewer for images, by the way), we see a small black rectangle that doesn’t quite fit in with its size of 55 KB. Surely something is hidden inside. Steganography ?
Now look at the HTML page. After downloading and cleaning it in Notepad ++, we get something similar to the browser type definition script.
Why all this is in the resources section, and even unpacked, remains a mystery. We will return to the resource section. For now, continue unpacking.
Launch Immunity Debugger and Virtual Box and load anti-anti-debug python plugin.
After the process is completed, you can drain the memory and do its analysis:
I noticed several areas of memory marked as Read Write Execute (RWE). One of them is at 0x00910000, another one is 0x00930000, the next is 0x00940000 and, finally, the last is at 0x00970000. Further analysis shows that only 3 out of 4 contain programs. However, three programs to hide in one? Good Easter eggs.
Now we will dump our programs for further analysis. We load OllyDumpEx and feed our 0090 areas. It is seen that the programs at addresses 0x00910000 and 0x00970000 coincide with the original, judging by their size, section headers and characteristics. And the area at 0x00950000 is different from them: other section headers, other sizes. It must be that golden egg (I left a literal translation, because the author uses the golden egg in his screenshots later on - approx. Transl.).
We will dump our exe using Binary (Raw) mode instead of Rebuild mode to preserve the integrity of the dump.
Two section headers indicate that the program is packed using UPX [4] . Running the upx utility confirms this. So we can easily unpack our egg.
The new exe is about 40KB larger and unpacked correctly, so now we can finally feed it with IDA. Looking at the lines, we see interesting things.
This is an HTTP request. Looks like this thing is sent home to mommy using a POST request.
You may ask - what about the C & C server? It does not seem to be contained in the program in plain text form. Remember, I asked you not to forget about the resources section? Look at the resources section of our golden_egg.exe
Voila http://31.207.6.161. It is wonderful to provide us with an open address. Security through obscurity strikes again.
You are probably wondering what happens when the main application runs. Let's get a look:
At boot time, it automatically closes my Process Explorer and for any attempts to load the task manager responds with the message "task manager was disabled by the administrator" before closing almost instantly. I wanted to take a screenshot, but it turned out that I was not so fast. Turning to Immunity, we see that the original “golden_egg.exe” program has already been completed. Instead, some other program with the name “zpNvNKSi.exe”, launched from the tempo directory. Compare hashes - and they seem to be the same:
(Did you like my hasher? You can download it here without registration and SMS )
The commercial break is over, now it is clear what the program is doing - the task manager is turned off, it kills "unwanted" applications and is launched from the temp directory. The msconfig check shows 2 new entries in autoload:
I checked both files and they were byte by byte matched with the original program.
Attach to the program with Immunity, look at the memory and the number of threads (by pressing the "t" key) - we see that the program is multi-threaded. I counted 12 threads.
I assume that each thread watches if one of the other threads is killed. However, by suspending the process, we can look into its memory using Process Explorer. The analysis shows that there are lines that were not shown in IDA:
Suddenly. I think that the program checks these utilities and forcibly closes them if they are running. This explains why I could not use Process Explorer while the program was running. Quite a way to complicate the launch of any of these utilities, instantly killing them. In the list you can find regedit, LordPE, Wireshark, regmon, filemon, procmon, tcpview, taskmgr and even Windows Defender. Severely. True, I do not see a cousin Process Explorer'a - Process Hacker .
Returning to
Having performed a search in memory of one of the strings in the Unicode encoding, we see that the string “taskmgr” is in the .data section. Did IDA really lie about the lines? Not really. We try again using slow Binary search (Alt + B) - and we find more rows. Apparently, IDA does not show Unicode strings when searching by default. You can change the search parameters in IDA by pressing Alt + A and selecting Unicode.
The analysis of new lines reveals more functionality of the malicious program.
Interesting.
Considering the fact that our attempts to start Wireshark will be blocked by the program, it is necessary to find the function responsible for forcibly terminating the programs and patch it. How to do it? Let's look for the api TerminateProcess () call.
Using IDA, it's not that difficult. In the import section, we find a link to TerminateProcess.
It looks like a kind of loop that scans the names of the processes by calling CreateToolhelp32Snapshot and, if they meet a condition, completes them. It seems that the list of process names that we saw earlier is used here.
So what can we do? We can change the logic of the program so that instead of calling TerminateProcess will occur ... and nothing will happen. Having checked the Xref-th subroutines (eXternal REFerences), we see that the function is called from the 0x00401D2A sub-program. It contains the jnz instruction, which performs a conditional transition to a subroutine that scans the processes and completes them. If we can patch the program in such a way that this subroutine is not called, we can run any utilities from the blacklist.
We drop the sleeves. I prefer to patch using Immunity - it's pretty simple, and I am familiar with this better. Let's start with the search subroutines in our exe. The instruction with conditional branch is located at 0x00401D4E. We dig up the whole area - thus, we immediately proceed to the execution of ret instead of going to the address 0x00401D2C, where the completion of undesirable processes occurred.
We resume the program execution and try to start one of the prohibited programs. It seems that everything works, since regedit was launched, and Process Explorer was not forcibly completed.
Finally, you can conduct a detailed analysis of network activity using Wireshark, as well as activity in the file system and registry using procmon, and indeed play with a running program in Process Explorer.
Process Explorer shows that a SYN has been sent [5] the package to our C & C server (yes, the one whose address we pulled out of the resource section) to port 80.
Wireshark gives a little more information. Here we see not only the SYN packets sent to our HTTP C & C server, but also a large number of DNS queries to get information about strange domains. What's next?
The server will continue to knock home, but I do not need it. I could modify the resources section in our “golden_egg.exe” to wrap it on my own HTTP server and explore its functionality, but this is quite labor intensive. We already have quite a lot: the C & C server, the unpacked program, its HTTP signature, and we also know about its behavior. Case is closed. Another 0day Wednesday came and went.
If you want to download the malware and tinker with it, you can get it here . Password "infected".
I hope this small study will be useful to you. Successful quacking!
By Joe Giron
Original article
1. ↑ 0day (English Zero Day) is a term for malicious programs against which protection mechanisms or vulnerabilities have not yet been developed.
2. ↑ IDA Pro Disassembler (Interactive DisAssembler) is an interactive disassembler that is widely used for reverse engineering.
3. Microsoft Microsoft Foundation Classes (MFC) is a C ++ library developed by Microsoft and designed to facilitate the development of GUI applications for Microsoft Windows by using a rich set of library classes.
4. ↑ UPX (the Ultimate Packer for eXecutables) is an executable file packer that supports several different platforms and file formats.
5. ↑ SYN - packet sent by the client to the server to establish a connection.
Source: https://habr.com/ru/post/207042/
All Articles