Malware Analysis ! 4day
Today’s learning content is a combination of dynamic and static analysis of viruses, if there are inappropriate places hope that partners can point out, let us work together to improve and progress together
Note: The content of the article is only to share their own knowledge base, only their own understanding, not necessarily accurate, I hope that when watching just reference, thinking is not limited by it.
Note: This is a translation of a previously written article into English, so if you have trouble reading the information, I will improve the translation.
Practical explanation
Analyse test samples based on a combination of static and dynamic analysis techniques previously learnt
word macro virus
Surface layer
Open an external address en route to download a file
After opening a word document, the calculator program was found to be open (representing malicious behaviour here)
Monitoring
- Network monitoring
Analysis:
Launch Program-WINWORD.EXE *64 bitRequest address-http://192.168.86.144/Response service-web service opened by python3’s SimpleHTTPServer moduleRequest file-Code:
1 | http://192.168.86.144/word.cab |
Behaviour monitoringFind the main program to open word filesTask Manager:
Same process tree as network monitoring to the initiator to view the execution flow:
Analysis:Code:
1 | Normal: just opening a word document |
itself
7-z View word document
Found out how to access the suspicious address
Combined with previous network analysis to access this address and then jump to download the suspicious file
Downloaded documents
Unpacking the downloaded file
can open it directly and extract it (7-z extraction is also possible, the effect is the same, but the unpacked size is different) and find the configuration file msword.inf where the control panel program is executed
Run the test
Executed successfully, verifying that the malicious code was loaded by the file
String ViewingView the downloaded file word.cab using cutter
See calculator-related content (calc.exe here stands in for malicious program)
Debug monitoringThe key function has been run and the malicious program has been successfully loadedCode:
1 | essential call: |
Go to view (malicious profile loaded).
ShellExecuteExW function (can usually this function to execute external programs or open files)
rundll32.exe (rundll32.exe is used to run DLL files in memory, they will be used in the application, can be used to execute malicious in memory dll)
Code:
1 | *cmd,*bat //Guess the dos environment is ready here |
syscall (this syscall finishes running and loads the malicious configuration file in order to run the dos environment to start the calc program here for the malicious program syscall: indicates a system call)
Disassembly locator: const char Command starts calc.exe
Code:
1 | Positioning technique: string search for key information, then double-click to enter the disassembly page to view |
Running
- Test machine, suspicious processes located
Code:
1 | I see RPCRT4.DLL in the module list |
Attack aircraft have taken control of the test aircraft
Process treeFind the location of the suspicious program, run it and monitor it to see the process tree
Code:
1 | test calls certain programs |
- At this point it can be determined that test.exe has performed a malicious act
- Network traceability
Code:
1 | Frequent outreach to this IP: 192.168.86.114 |
Locate and analyse
Find the program and load the analysis tool to analyse it
- VirtualAlloc function
Code:
1 | Windows API function for requesting memory space |
- ExitProcess function
Code:
1 | Windows API function to end the calling process and all its threads. |
- FunctionsThis call will call syscall to send network data to the attacking machine
Code:
1 | call:00007FF8054B2A59 | 48:FF15 301F0500 | call qword ptr ds:[<&NtDeviceIoControlF | |
Linux virus checking
Network Related
- ifconfig commandIf the data sent is too large or the difference between the received and sent comparisons is too large (no data downloaded), it is suspicious and requires further investigation.
Code:
1 | RX Packets // Number of packets received |
nethogs command (installation required for normal conditions)Lists the network status of the process
Code:
1 | dev network card |
See process 1 sending and receiving data, see detail
top commandQuery the resource usage of a specified processCode:
1 | top -p 7132 //7132 for process pid |
At first, the monitoring resources are not high, but at a later stage, they are gradually over-occupied, probably because the remote control Trojan horse resides, and then receives commands to execute attacks such as: search for specified files
Find process path by PIDCode:
1 | cd /proc/7132 //7132 is the process pid |
Guess the status query outreach IPCode:
1 | netstat -na|grep ESTABLISHED |
Backtracking processes by port
Code:
1 | netstat -nap | grep 47074 |
View process memory based on pid
Code:
1 | pmap -d 3885 |
Shutting down processes based on pidCode:1
kill -HUP 3885
Exploiting program overflow vulnerabilities
This is an uncomplicated simulation of an attack program based on a program with an overflow vulnerability.
A brief analysis of the attack program exploit idea and the overflow vulnerability generation
Source Code Analysis
Buffer vulnerability program source code exists:
Note: Modified from STACK1_VS_2017.cpp
Toolchain: Mingw
Code:
1 | #include <stdlib.h> |
According to the source code, if the data obtained by the gets function is *DCBA ( wildcard, e.g. 11DCBA, the hexadecimal value of the string DCBA is 44434241, because the order of reading and writing data on the stack is first in and last out, so the real call is ABCD), it proves that the buffer overflow vulnerability of this program is exploited and the hidden message is displayed (according to the code logic, the normal operation of the program does not meet the condition of displaying this hidden message)
The buffer vulnerability is caused by the buf application buffer size of 2, and the buffer is not protected because it is acquired with gets, and if the acquired data exceeds 2, the buffer is overflowed.
Attack exploit code
Code:
1 | import sys |
Effect: The buffer overflow succeeded and the hidden message was read by entering a specific code
Monitoring:procexp64
Procmon64
Locate the script test.py to use
Disassembly analysis
Run to module value: test.exe
Entry breakpoint broken off, no leaked information related content seen, string search to quickly locate the vulnerable function code block
Note: The compiler adds a lot of code in order to make the executable work and start properly. Therefore, the first entry function breakpoint often does not break to the main function
Decompiler cross-reference:MapoAnalyzer
Snowman
Trace analysis: When entering a string, the two variables are seen next to each other in the stack window
According to the analysis of the decompiled result, the input string is the value of the corresponding buf variable, but now the cookie corresponding also has a value, analysis of data overflow, resulting in the cookie corresponding address has a value and for the input value minus two, that is, DCBA, as shown in the following figure:
Code:
1 | 00000000004015E1 | 8B45 E4 | mov eax,dword ptr ss:[rbp-1C] | |
You can see the input
The string has met the conditions and the jump was unsuccessful, resulting in the hidden message being retrieved Extended analysis:
The gets function
Code:
1 | Web source: gets can read indefinitely without judging the upper limit, that is, the gets function does not check the size of the buffer buffer, and in fact it cannot check the buffer space. |
In conjunction with the analysis, an overflow vulnerability exists due to the program’s use of the get function to obtain input data, where the program hides certain characters based on this vulnerability.