Showing posts with label malcious JavaScript. Show all posts
Showing posts with label malcious JavaScript. Show all posts

Thursday, August 15, 2013

CookieBomb still dropping malicious content

Cookiebomb is malicious obfuscated javascript injected into legitmate sites.  We've talked on this blog about compromised sites before, but this one appears to still be fully functional and actively spreading malicious content to unsuspecting users.  The talent at MalwareMustDie is onto their shenanigans as well.  As they have mentioned, this is a multi-redirection exploitation that uses two stage obfuscation to hide it's malicious payload.  The curious thing about this situation is that few AV vendors have taken note of the good research.  The final dropped file is being detected by only 7/45 vendors.

Below is the analysis of a single sample taken from the final list of infected sites we have seen propagating this threat.

First, there is the obfuscation of a small JS inclusion into a potentially legitimate site.  This is where the CookieBomb sets a name, special variable, expiry date, and access path for the eventual infection.  If the cookie is not readily available, it will create one for you and redirect you to another obfuscated hidden iFrame.  Once the hidden site is visited, it will read the cookie's expiry date and provide redirection and infection at a later point to avoid security vendor detection.

Figure 1: Obfuscated Code
Please note that the comment at the top of the image ("/*0f24908*/") is changed and is not therefore useful for detection.
Figure 2: De-obfuscated code from Fig.1

In the deobfuscated code above, we see another URL delivered in a 1px iFrame.  Going to this site leads to yet another obfuscated page, where the real magic happens.  The very first thing that it does is attempt to confirm the version of browser plug-ins the attackers are up against.


Depending on the version installed, it will send the next portion of the attack.


The final step sends the malicious payload that the attackers went to so much trouble to obfuscate.  
 


Attack URLs


Obfuscated content from the obfuscated content

The final drop for this content is a malicious executable that is delivering a small Trojan.  At the time of research, only 7/45 vendors were detecting this content as malicious.



Fiddler session with malicious content being dropped.  (Readme.exe in this case.  Calc.exe in others.)


For the last several weeks, this attack has impacted the below sites:
    •  hxxp://www.citytavern.com/
    • hxxp://www.usadu.cz/park-en/
    • hxxp://bluen.de/jobborse/
    • hxxp://bluen.de/
    • hxxp://www.niblackfuneralhome.com/
    • hxxp://www.kinwindsor.com/
    • hxxp://www.mtldesign.net/
    • hxxp://javiervazquez.me/ernesto/fdjw3hv7.php
    • hxxp://www.cmfurniturerental.com/
    • hxxp://sdrs.splashtop.com/strs01/macupdatenotes/en-us/strs01.html
    • hxxp://www.nauticodiver.de/tauchbas.htm
    • hxxp://www.tmv-alsace-vtt.com/f/parcours.htm
    • hxxp://www.cmstaging.com/
    • hxxp://educationdegreeonlines.com/benefit-from-studying-with-the-laptop/
    • hxxp://www.gute-reise-berlin.de/aussteller.html
    • hxxp://lexespana.com/comunes                                                                                                          
    • hxxp://livehappylife.com/
    • hxxp://corpdeli.com/
    • hxxp://www.sudan-sudan.com/sudan/architecture-sudan-sudan.html
    • hxxp://www.cmfurniturerental.com/index.php?main_page=index&cPath=114&zenid=8557f58ea51118a7bd633015e3b954ec
    • hxxp://www.cherokeecountysc.com/id26.html
    • hxxp://www.gute-reise-berlin.de/startseite.html
    • hxxp://www.selbstversuch-spanien.de/
    • hxxp://educationdegreeonlines.com/
    • hxxp://www.nauticodiver.de/schule.htm
    • hxxp://bluen.de/uber-uns/
    • hxxp://www.nauticodiver.de/impresssum.htm
    • hxxp://www.imschuh.de/
    • hxxp://www.nauticodiver.de/preisliste.htm
    • hxxp://familyreunion.blackamericaweb.com/
    • hxxp://bluen.de/jobborse/spezialist-in-akustikversuch/
    • hxxp://www.uppertraining.com/blog/cisco-mobile-apps-cover-a-surprising-range-of-functionality/
    • hxxp://www.opheij.nl/contact.html
    • hxxp://www.hotelmirallac.com/castellano/tarifas.htm
    • hxxp://www.sugargrovechamber.org/member_listing/34/curt+john+karas,+cpa,+mba,+pc/
    • hxxp://www.kinwindsor.com/favicon.ico
    • hxxp://glassdoctor-denver.calls.net/?gclid=CPLt2r3F-LgCFUFyQgodZxwAjQ
    • hxxp://bluen.de/jobborse/spezialist-in-logistikplanung/
    • hxxp://dreamliftgifts.com/faq.html
    • hxxp://www.gute-reise-berlin.de/kontakt.html
    • hxxp://www.plomberiumpierrefonds.ca/robinets-de-cuisine/
    • hxxp://www.cerexagri.nl/
    • hxxp://www.mrbouncehouse.com/
    • hxxp://guia.lexespana.com/familia/servicio-domestico/extincion-del-contrato/
    • hxxp://www.nauticodiver.de/start.htm
    • hxxp://corpdeli.com/lunch-menu
    • hxxp://www.hotelmirallac.com/castellano/habitaciones.htm
    • hxxp://www.nauticodiver.de/
    • hxxp://www.heapoil.org
    • hxxp://www.mtldesign.net/aboutus.htm
    • hxxp://www.le-vieux-four.com/
    • hxxp://www.cleargridsolutions.com/developer.html
    • hxxp://www.horseridingfun.com/
    • hxxp://educationdegreeonlines.com/2013/07/

    The most notable site here is splashtop.com, however, the malicious content has since been removed.  Since AV seems to be uninterested in protecting against this threat, it is advisable to make sure your browsing is safe through other means.

    Technical Research: Krishnan Subramanian

    Tuesday, September 25, 2012

    How to install silently malicious extensions for Firefox

    Recently, I had the pleasure of presenting on malicious browser extensions at SOURCE Seattle. I showed, amongst other things, how a malicious browser extension can be added silently to any Firefox profile. I've reworked the demonstration, and want to make it available to a wider audience.

    3rd-party installation

    You have probably already have encountered applications, like the Flash player or some repackaged free software, that wants you to install a toolbar or some spyware/adware for your browser. This is a 3rd-party installation of an extensions. For Firefox, this installation consists of copying the browser extension into your Firefox profile (or a special folder that contains extensions shared by all profiles).

    Software installer contains a toolbar/adware/spyware extension

    Firefox protects against this type of external extension installation by prompting the user the next time the browser is started - the user has the option to disable (default action) or enable the new extension.

    Firefox warning for an extension installed outside of the browser

    Silent installation

    It is actually very easy to bypass the warning from Firefox. Firefox stores information about all extensions in a Sqlite3 database named extensions.sqlite, located in each Firefox profile. It contains:
    • name, version, description, etc.
    • enabled or disabled
    • active or not
    • installed from official Mozilla extension site or not
    extensions.sqlite

    When Firefox starts, it checks the list of extensions under /extensions/ against the content of extensions.sqlite. If an extension exists on disk, but is not listed in the database, a warning is shown. The trick to install an extension silentlt, is to add a record into the database about the extension being installed and tell Firefox that the extension has actually already been approved by the user (active and enabled).

    Demonstration

    I've written a small program that installs an extension silently into any Firefox profile. You can download the program and the extension here, and the source code there.

    The program was written in C# and can be compiled with the free Visual Studio Express for .Net from Microsoft.

    Tool shows the steps to install the extension silently

    The "malicious" extension does not actually do anything. All the malicious code has been commented out, although it includes some of the things an attacker could do, such as:
    • steal the list of logins and passwords saved
    • send out all the URLs visited by the user
    • disable security features
    Do not worry about testing the "malicious" finctionality, the extension will not do anything - no information will be sent out.

    I suggest that you create a custom profile to test the extension. To create a new profile named "demo", run the following command:

    firefox -CreateProfile demo --no-remote

    Then start Firefox with your new profile:

    firefox -P demo --no-remote

    I've included a video that shows the silent installation in case you're fearful of trying it for yourself:


    Why it matters

    Many free software packages push toolbars, adware and spyware into Firefox and other browsers, installed as part of their installation to earn some money for the extension creator (see previous PPI campaigns). Firefox gives users a chance to explicitly and clearly decide whether or not they want to enable these add-ons. Without this protection, many users can be tricked into running extensions they were are not aware of.

    The second important point is that malicious browser extensions are much harder to detect once installed. Because extensions are part of the browser, their activity cannot be differentiated from the activity of the browser. Accessing the internet and accessing the file system are legitimate actions for the browser. The extension does not need to add itself to the startup scripts, or as a Windows service to be running after a computer reboot. The extension does not need to hook into Windows to intercept logins and passwords, etc. Finally, AV vendors struggle with detecting malicious JavaScript and any of the malicious Firefox extensions I've checked with VirusTotal were never flagged.


    Going further

    The silent installation could be even more sneaky. Instead of adding a new extension, it could also replace an existing extension, or append itself to an existing extension.

    Tuesday, May 17, 2011

    Facebook under attack by scammers

    Facebook is facing no shortage of attacks from scammers. Yesterday, I posted a blog about a recent scam being circulated on the Facebook network and only a few hours later, we uncovered yet another one. The goal of this scam remains the same as earlier one, namely to coerce Facebook users into completing various surveys which in turn generate money for the scammer. The interesting fact about this scam is that it is not only posting the malicious message to the wall of the victim’s friends, but it also gets a list of online friends to send them chat message like “hey you are still there?Check my wall for the link ^_^ It showed me who viewd my profile. Amazing :p" with a link to the malicious domain. Here is what the wall posts look like:


    When a user clicks on the links in the message, they are presented with a fake pop up displaying how many friends are supposedly viewing the victim’s profile. Here is a screenshot:

    Remember, this is fake message and each time it is accessed, it simply generates a random number– this has nothing to do with actual users viewing your profile (something that Facebook does not share). The page also suggests that the user must copy and paste JavaScript into the address bar, which will of course execute the JavaScript in the context of the victim. This is similar to the earlier scam. Once the user runs that malicious code, they are presented with some fake messages requiring that they undertake surveys or view additional messages: Here are the screenshots:

    As mentioned, the attack also sends chat messages to online friends in order to further spread the attack. Here is the screenshot of the associated source code:

    The malicious code also forces the victim to become a fan of “OSAMA” Facebook pages. Here is the screenshot of that code:

    Facebook is currently losing this cat and mouse game. As quickly as they take scams down, new ones appear and take their place, each time evolving the tactics slightly to evade detection. This is second scam we uncovered in only a few hours. Facebook needs to do a better job protecting its users. Both of these scams use the same techniques of social engineering users into pasting JavaScript into the URL bar – something that we’re seeing on a more regular basis and something that would never be required by a legitimate page.

    Nasty Scams!!!
    Umesh

    Monday, May 16, 2011

    Yet another Facebook scam – You look so stupid in this video

    Today, we have come across yet another rapidly spreading Facebook scam. The ultimate aim of this scam is to coerce Facebook users into completing various surveys which in turn generate money for the scammer. The messages arrive with embedded Flash video and different messages such as “WTF!! You look so stupid in this video” or “yo, why are you on this video” etc. Below is a screenshot of such messages:

    The post displays fake meta data showing the number of “Views”, “Likes”, etc. to make the posts appear more genuine. When a user clicks on the video link, the Flash file loads in the background. Once the loaded, it prompts the user to play a fake video. When the user clicks again to play the video, it looks like,

    The above message displays instructions with keyboard shortcuts that cause the victim to paste clipboard information in the address bar. The flash file itself sets the clipboard data with malicious JavaScript which further spreads the attack. Here is what the malicious JavaScript looks like:

    Let’s format this for better readability. Here is a formatted version:

    If user runs this malicious JavaScript in the address bar, the script will randomly load one of two JavaScript files from different domains. The “config.js” is actually used to further spread this scam using different descriptions of the video. This JavaScript file not only posts the same flash video message to user’s wall, but also their friends walls. Here is partial screenshot of “config.js” file:

    The above code contains all the configuration settings for spreading this message with different text messages and different domains. The “config.js” file also contains the code for posting the message to wall of every Facebook friend.

    Here is what the source of “verify.js” looks like:

    The above file references yet another JavaScript file. This referenced file is used to keep track of real time stats. The user is further prompted with message box asking “Please verify your identity” by taking surveys as shown below:

    It will keep checking for the survey to be completed even if you click “Complete” button without taking the survey. This is yet another scam run by attackers to earn some money by encouraging Facebook users to complete surveys that pay for completion. This is not the first time we have seen such a scam spreading on Facebook. Attackers are doing an excellent job by taking advantages of both social engineering and social networking.

    Believe me - I don’t look stupid in that video!

    Umesh

    Sunday, May 15, 2011

    Geek.com hacked with an exploit kit

    Update 15/04/11 @ 3.40pm IST: With further research, it has come to our attention that many different pages like main homepage, about us page are infected with malicious Iframe pointing to different malicious sites.

    We often blog about popular web sites being infected with different exploit kits. The attack vector remains the same, namely injecting a malicious HTML Iframe or script tag into the legitimate pages. One of our blog readers, Mr. David S. emailed me to share a popup alert that he was receiving on one of the pages of Geek.com. Geek has been a very popular site for online technology resources since 1996. They feature the latest news and reviews from the technology world. Here is the home page:

    If you look at the screenshot above, you will notice that they feature the latest articles on the home page. The latest topic or article currently discussed is “Call of Duty: Modern Warfare 3 details leaked”. As this is first article is highlighted and “Call of Duty” is a very popular game, one can assume that many people have fallen victim to this attack. It is in the article itself where the malicious Iframe has been injected. Here is the screenshot of the article in question:

    The article was published on May 13th. As usual, the malicious Iframe is injected at the bottom of the page. Here is a screenshot of the malicious Iframe:

    The malicious Iframe redirects victims to a malicious website hosting an exploit kit. Once you visit, heavily obfuscated JavaScript is returned which will target various known vulnerabilities. Here is what the exploit looks like:


    The decoded version of this malicious JavaScript results in the same vulnerabilities being exploited as we have seen in past blogs on exploit kits, so I will omit details on decoding the JavaScript. For interested readers, a Webpawet report is available for the malicious JavaScript.

    Unfortunately, we see hundreds of attacks such as this each and every day. Many legitimate websites are being compromised by taking advantages of poor coding practices in web applications. Attackers are constantly on the lookout for popular websites or top news sites as targets for their attacks. Users need to be aware that no site is a safe site.

    Umesh

    Tuesday, May 3, 2011

    Latest victim of an Exploit Kit - Lenovo, India


    Update 05/04/11 @ 7.49pm IST: Thanks to feedback from an Anonymous blog poster, I've done some further investigation and this attack actually appears to be tied to the Incognito Exploit kit as opposed to the Blackhole Exploit kit.

    Back in February, I posted a blog about the rising prevalence of attacks involving Blackhole exploit kits. We received numerous comments and emails about the same threat being found on various websites from our blog readers. The toolkit has been linked to from numerous compromised websites, which in turn have victimized a number of their visitors. Attackers are injecting malicious iframes into the legitimate sites, which in turn redirect to malicious websites hosting the Blackhole Incognito exploit kit. We have observed and identified such compromised sites due to Zscaler’s advanced security features in our solution. The latest victim is Lenovo, India whose website for product warranties http://www.lenovowarranty.co.in/ has been compromised, redirecting visitors silently to the Blackhole Incognito exploit kit. Here is the screenshot of the home page of the compromised Lenovo site:
    One of the pages on the site, http://www.lenovowarranty.co.in/regspacks2.asp, is infected with a malicious iframe. Here is the screenshot of that page:
    If you look at the source of page, you will find the malicious iframe injected into the source code as shown below:


    The malicious iframe points to the site “hxxp://nemohuildiin.ru/tds/go.php?sid=1". This malicious site actually redirects the user to another malicious website hosting the Blackhole Incognito exploit kit. Here is the packet capture when you visit the mentioned malicious site:

    Observing the “Location” field in the HTTP header, we see the user is being redirected to another malicious website hosting the malicious toolkit, a common pattern that we’ve seen in the past. The malicious website “hxxp://andromari.cx.cc” returns obfuscated malicious JavaScript code to exploit different vulnerabilities and downloads malicious binaries. Here is the screenshot of the malicious JavaScript sent by this kit


    I am not going into the details of the exploits themselves as they are related to the same vulnerabilities and toolkit, which I have discussed in an earlier blog. The malicious site hosting the Blackhole Incognito exploit kit only attempts to exploit the victim on their first visit. If you revisit this site, it will either redirect you to Google or simply return a “Page not found” error.

    This post further supports my claim in an earlier blog, which states that “Blackhole exploit kits are rising”.

    Blackhole is Exploit kits are definitely a Bad Hole bad for web security.


    Umesh

    Thursday, April 28, 2011

    Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), SQL Injection, HTML Injection, etc.

    Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), SQL Injection and HTML Injection are security flaws that have been around for years. They are well know vulnerabilities, with well-known solutions. As we've seen in recent weeks, even well-established tech companies are not immune to these basic flaws:
    These flaws go by different names, but there cause and consequences are about the same. They are caused by insufficient user input sanitization, and result in malicious code being executed in the browser of the user visiting the site.

    I believe one of the reason these flaws are still present in new websites is due to the fact that their exploitation and consequences are not fully understood. Here are few misconceptions I have heard.

    XSS is simply about popups

    Proof-of-concept for XSS flaws often consists of showing a JavaScript alert popup being displayed. This is just for demonstration purposes. A successful XSS injection can insert any JavaScript into the page, which can, amongst other things:
    • steal user credentials (login, password, session, etc.) and other confidential information (credit card number, mailing address, etc.)
    • hijack administrator sessions
    • force the download of malicious executables
    • run other types of code: Flash, Java, ActiveX, etc.
    SQL injection is all about reading data

    SQL Injection is not only used to dump a database, or to login without valid user credentials. A lot of web applications, like Wordpress, store the site content into a database. If an attacker get write access to the database, he can insert malicious code which will then be rendered for all users.

    Users are at fault for not being diligent

    Another belief is that a user must click on link that contains the XSS, CSRF of HTML infection in order to be affected. Since the "bad" content is often shown in the URL the user clicks on, users should simply be more careful.

    First, "bad" links can be hidden with a URL shortener, for example and users may not be aware were they will be redirected. Second, all attacks are not necessarily transient. Malicious content can be inserted by one user, or the attacker, and displayed to all other users via a persistent XSS or HTML Injection flaw. It is the responsibility of the webmaster to protect users. This responsibility should not be placed on each user.


    A good blacklist will do the trick

    User input filtering is often performed by a blacklist: allow anything, except a few dangerous strings. Unfortunately with HTML and JavaScript, there are too many ways to do the same things. Here are a couple of examples

    Conditional comments

    HTML comment should be safe, right? Wrong. Internet Explorer actually interprets the content of HTML comments called conditional comments. These 2 lines will make Internet Explorer load and execute JavaScript for evil.com:

    These lines are not interpreted as comments by IE
    Conditional comments for Internet Explorer also exist for Javascript:

    document.write is executed by Internet Explorer

    XSS can hide anywhere

    A XSS attack does not require the addition of a new script tag on a page. It can hide in a link, tag attributes, CSS, etc.

    Examples of harmful JavaScript/HTML insertion
    Encoding

    Don't forget about HTML encoding, JavaScript encoding, JavaScript obfuscation, ASCII-7, UTF with null characters, etc.

    Some examples of encoding


    It's pretty much impossible to get a comprehensive list of dangerous strings. Instead, a tight whitelist of authorized strings and/or characters should be used first, and only supplemented with a blacklist as needed.

    I hope that the high-profile attacks that happened recently will push web developers to pay more attention to the code injection vulnerabilities. Many programming frameworks include libraries and functions to take care of most of these issues. Hopefully they will be used everywhere user input is received and displayed. Don't ever trust external input!

    -- Julien

    Tuesday, April 5, 2011

    Fake AV vs. Zscaler

    I've been monitoring Blackhat spam SEO for more than a year now. I frequently have to modify the scripts used to retrieve the fake AV pages in order to deal with obfuscation and other obstacles the perpetrators have put in place.

    Fake AV pages are designed to keep security scanners and researchers away. One of the techniques used to weed out automated scanning tools from victims using real web browser is JavaScript redirection. I have seen more than ten different techniques to redirect users from the spam page to malware pages leveraging different types of JavaScript. Usually, they use two to four redirections, one after the other, each using different code.

    JavaScript code of some of the redirections
    Once again, by trying too hard to hide the malicious code, Fake AV pages are actually easier to detect by looking at the redirections rather the malicious code itself.

    Strict HTTP Referer

    In addition to making the JavaScript redirections difficult for security tools to follow, there are strict checks on the HTTP Referer header. For example, a real browser sends a Referer if the redirection is done through an HTTP Location header redirection, a meta redirection, etc., but no referer is sent through when using the JavaScript functions location.assign(new_value) or window.location=new_value

    IP Blacklisting

    It usually only requires a few minutes of work to bypass the "protections" put in place by Fake AV pages. The fake AV authors have no doubt realized that their modifications were not very effective, and that Zscaler and others are still finding their malicious content.

    A few days after Mike found IP tables settings shared online to block major security vendors, our main IP address was blacklisted. I quickly changed to a different IP address in the same sub-net, but only 3 days later, our complete sub-net was blacklisted. I have recently switched to Tor to get random IP address. This has allowed me to keep tracking new Fake AV pages.

    The cat and mouse game between Fake AV and the security researchers will probably keep going on for a long time. Since the attackers keep modifying their content, malicious HTML, JavaScript and executables, Zscaler has to keep monitoring the changes in order to protect their customers given this rapidly-evolving threat.

    -- Julien

    Wednesday, March 9, 2011

    Analyzing PDF exploits for finding payloads used

    We have written a couple of previous blogs which focus on an in-depth analysis of PDF exploits as this is yet another techniques used by attackers to package malicious code and avoid antivirus detection. We have also written in the past about different decoding filters used to hide the malicious code inside PDF files. In this blog, we will examine yet another in the wild PDF exploit which has hidden it’s malicious code under different objects. We will also identify the final payload used to carry out the attack. The malicious PDF sample was retrieved from “hxxp://sj1s.co.cc/games/pdf.php?f=21”. Here is the PDF source code:

    The above PDF file is small in size and contains clear text JavaScript. Let’s look at object 1, which contains malicious JavaScript code. This code is very simple to read and understand. The JavaScript accesses some property values declared elsewhere such as “this.producer”, “this.subject” etc. Now, where are those declared values coming from? If you look at the object 3, you will notice that all other variables are accessed from these object properties. The strings used like “eval” and “StringfromCharCode”, suggest this JavaScript is used for malicious purposes. Now, we have 3 different strings from object 3, which will be used in the malicious JavaScript code.

    1) Property Producer contains a long array of values
    2) Property Subject contains string “eval”
    3) Property Title contains string “StringfromCharCode”

    We will use Malzilla for decoding this malicious JavaScript. For that, we need to substitute the respective values into the variables. We will re-create the JavaScript code for Malzilla using those values to as it with the decoding process. We will need to look at the code carefully, because the array contains some substitution and arithmetic operations. Here is what we need to substitute:

    Let’s take the first value from the Producer property array, which is “t9.5*w”. The malicious JavaScript contains one variable “w”, declared with a value of 4 and then there is another function (axp = axp.replace\(/t/g,'2'\);), which will replace character “t” with value 2. So the first integer of the array will become (29.5*4) = 118. When we substitute the whole array with values of “t” and “w” we can create the final simple JavaScript code:

    We will now decode the above simplified code using Malzilla. The decoded content is shown below:

    The decoded content contains malicious heap spray code, shellcode and code for attacking different Adobe vulnerabilities. However, we have to yet identify what this malicious code does once it exploits the vulnerability? What payloads does it use for the exploit? For this we need to identify the shellcode used. Here is what the shellcode looks like:

    The shellcode used, is in %u Unicode-encoded format. We will convert this code into byte code or executable code for further reversing using IDA pro or OllyDbg. For this, we will use favorite online tool Shellcode 2 EXE. We will copy and paste the shellcode bytes from the variable, which will generate a sample “.exe” file to analyze. Here is the screenshot:

    Now, we have executable file to analyze. So let’s open in IDA pro first to look at the strings used inside the payload. Here are the strings found,

    The string shows that this payload is going to download additional files on the system. Now let’s open this file in OllyDbg for obtaining the malicious URL used inside the payload.

    The shellcode starts with NOP instructions followed by another loop which will decode the malicious code. Look at the instructions above, inside the highlighted box. Those are the instructions which are used to decode everything. By stepping through the code, we come to know that there is an instruction that will compare the value with E9 to exit and another, which is XORing byte with a value of 31. We will put breakpoint at the RETN instruction. The code will successfully run and we will be presented with the decoded content, which contains more interesting strings.

    Look at the highlighted string above in the dump area. This URL will be used to download another binary from the server. Now, we have identified this malicious payload and the URL used. For reference, here is the result from ThreatExpert for the same shellcode.

    That’s it for now.

    Umesh