How does a RAT works? I understand it as once we visit the infected website, the browser might download the Trojan to our PC automatically. Will it be executed and auto-installed in our computer?

I can't see how JavaScript can run the malicious code and automatically install the RAT into our/visitors PC and gaining access to their PC.

Does it work like this?

  1. Hackers uploaded the exe file to an exploit server.
  2. Visitors visit the server/hackers send the affected website link to the particular victims.
  3. The malicious code is written in js file and the js file will be automatically downloaded to visitor's PC (C:\users\pcname\AppData\Local\Temp)
  4. The js file automatically installs the RAT Program?
  5. The RAT program will auto send the victim's IP address and username/password to the hackers each time the visitor is online?
  • 1
    I think you have a couple of misunderstandings here - but have a read of the first couple of links in the Related sidebar on the right. Your points 1 to 4 are broadly correct. Point 5 is dramatically understating what the attacker can do. Basically there are many ways to exploit the browser or its plugins to get an exploit executed. Once that is done, the attacker can do whatever they want.
    – Rory Alsop
    Aug 29, 2012 at 15:08

3 Answers 3


I can't see how a javascript can run the malicious code and automatic install the RAT into our/visitors PC and gaining access to their PC.

Javascript in and of itself cannot - the implementation of javascript usually has very, very limited access to the local system by design. That's assuming all works as designed.

Software systems rarely do; the larger the piece of software, the more likely bugs are to creep in. If one of those bugs happens to let you run arbitrary code, that's a problem.

To be clear, this arbitrary code is typically actually a specially crafted piece of input into the program. For example, let's assume there's a bug in the .image renderer (a file type we've made up for the purposes) where I read data that should look like this:

FF 00 99 00 00 00

For reasons unknown, I've chosen to do crazy things like storing this RGB code in strings and am assuming string terminates with 00 and there's actually only one character. I don't know, maybe I'm anticipating bazillion colour screens. This may be a poor example. It's late. Bear with me. Anyway, let's assume I just use standard string functions in by renderer to copy that information out of the file. Now, if I send a valid file, great. However as an attacker, I could send a file that looks like this:

FF 00 99 11 11 11 11 11 11 <lots of 11s> 11 11 <some code> 00

How could I send that file? Easy. Include it in the html of the web page with bog standard img tags. The browser will then open/render the image (as it does with jpgs, pngs etc) and my broken dodgy code happily executes that buffer overflow. I might even be sneaky and display: none; it via css, but only if the browser still processes it.

At this point, those instructions in <some code> get executed, which allows me to do whatever I need to. Typically, this downloads an executable of some sort and runs it, which means the exploit only needs to be small and I can download something meatier if the exploit worked.

From there, the "payload" can begin attempting to elevate privileges and installing backdoors. You already have a good answer on what a backdoor could do and how it might work.

I've chosen to make up an image file with a very simple mistake nobody should make; however, in the real world there are all sorts of media which have very complex results:

  • Javascript - it's a programming language, needs parsing etc.
  • PDF - a document format with bells and whistles, also includes javascript.
  • PNG/JPG/GIF - I'd expect a bug in these to be rare, but I believe it has happened (not sure if it caused a remote execution vulnerability though).
  • More complex movie formats, e.g. MP4 etc.
  • Flash.

Now, two scenarios are slightly more complicated:

  • Java applets allow arbitrary code execution - in Java. There are three possible outcomes here:
    • You can avoid the signing dialog display via some mechanism and so load your class without user interaction, giving you the ability to download/exec code.
    • You can find a bug in the classloader or jar parser that you can exploit.
    • There is some bug in the Java language and/or runtime you can convince the user to use.
  • ActiveX controls: these are, effectively, DLLs or EXEs with "special magic". It's Open Season with one of these; the only barrier here is avoiding (by getting a valid signature, social engineering or a bug) the authenticode (code signing) screen you (should) get before running one.

Baaasically, the browser environment is incredibly complicated and there are a lot of moving parts that must all read untrusted input and correctly handle it.

Now, where does Javascript come into the mix? Well, it might not contain the vulnerability itself, but it certainly can enumerate lots of useful client side information to determine what vulnerability to send - much more than simply the browser version. This could be part of the attacker's landing page, for example, to decide what if any exploits can be run.

Now, that little comment of Rory's:

Point 5 is dramatically understating what the attacker can do.

Massively, really, megarly (that's a word now) understating what the attacker can do. Since a remote access trojan has full control of your PC, a few things an attacker may do:

  • Install further code, on demand, to carry out or co-ordinate attacks on other systems. This is commonly referred to as being part of a botnet.
  • Harvest any interesting-looking information from the current system.
  • Go around damaging things. Quite rare these days.
  • Drop payloads onto any media/medium likely to enable the attacker to an exploit another system, e.g. infecting all USB drives that are plugged in.

The possibilities are pretty limitless; the first point is actually reasonably likely, as is the last.

I can haz tl;dr?

Javascript is usually used to perform reconnaissance on the target system; beyond that, an exploit allowing arbitrary code execution must exist in the browser or one of its plugins. From there, you can persuade the computer to download more information, and from there, the computer is your oyster.


A RAT generally consists of two programs: A client and a server. The server is the program that's intended to be executed on the victim, the client is the program that is used to control the server.

In order to infect the victim, it must be executed somehow. It could be either exploiting some known vulnerability that allows code to be executed from an image, for example or through social engineering. It's possible (but hard) to make browsers to execute code from images, these are called buffer overflows but I can't tell you exactly how they work.

The server has to be executed in the victim and most of them need to have administrator privileges or somehow escalate to obtain these privileges in order to install itself in the victim's computer. An attacker will want it to boot the next time the computer runs, so having admin rights is needed to configure it to load with the operating system.

If the attacker was exploiting a buffer overflow in the browser and the browser was being ran as administrator, the attacker would have most of what he needs now.

After the server installs itself, it must communicate with the client to receive orders and execute them in the victim's computer. Traditional rats used to wait (listen) for connections but since the widespread home NAT routers, it's become unfeasible because the attacker would need to forward a port to the victim's computer within the network so they prefer to be waiting for a connection on the client side or transmit the orders using other channels such as IRC.


Remote Access Trojans (RATs) do not actuate the same kind of bad dreams as angry rodents, yet they can still be terror prompting if they hit your network system and workstations. The "trojan" portion of their name infers that they show up on the victim's system masked as a real or harmless program. It also infers that the system's user has played a key role in bringing the trojan to their system by downloading a file from a malicious website or clicking on a link in a malicious email message.

Once RAT is installed, the RAT starts the "Remote Access" operation when it "connects'' to a Command and Control (C&C) server that will control its future activities. This outbound call is very critical because most network systems are set up to be more permissive about the network system ports being used and traffic sent from inside the network to the outside network world, than from the outside network world to inside the network systems. Just to make itself more hard to detect, a RAT will mostly take use of system ports related to authorized communication or remote access applications, like the ports being used by network admins for remote communication management. When the connection is established, the RAT becomes open bi-directional network traffic for whatever length of time that is vital.

Up until this point, the RAT has not done anything truly awful, however that is going to change. When the C&C server is contacted, it will send the malicious payload to the RAT and start its "real" work, which can be a keylogger, privacy intruder (via webcam or microphone), botnet participant, cryptominer or pretty much whatever else. When the RAT has started the conversation from inside the system, for all intents and purposes any information can stream over the established connection.

The development of "malware as a service" has seen hackers and criminals take control over user's systems and keep them as resources, renting them out to clients for other kinds of purposes. When the system is infected with a RAT, a system can be a cryptominer one day and a spamming bot the next day. If a keylogger can get account credentials for banking and different applications, that is only an extra advantage for the hacker.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.