I am doing some hands-on training with Kali linux and one of the exercise I came across was to make an exe file containing malicious payload(say to obtain reverse shell), send it to a victim and hope for the victim to download the exe file. If he/she downloads it, it is fairly easy after that.

Now this isn't tricky at all, assuming the fact that many users aren't aware of security. But in real world, to carry out this attack, there must be more hurdles that an attacker needs to cross for exploitation?

What are those security measures that stops attempt to exploit users? For example I can think of firewall which tries to detect malicious looking requests.

Please answer the question for both internal and external attacks.

3 Answers 3


There are a number of ways that people attempt to mitigate these attacks.


  • Prevent spam filter from allowing MIME types frequently associated with malware (it's highly unlikely there is a business relevant reason to send .exe or .bat files for instance)
  • Use Anti-Virus as .exe's can be detected even after several rounds of encoding. Preferably you'd want "behavioural based" anti-virus which block applications based on actions they attempt to take.
  • Educate your staff on how to spot threats and what to do should they encounter them.
  • If you're IT department is big enough and you want to pull your hair out figuring it out, software restriction policies can be implemented to only allow known .exe's from running
  • Disable the ability for executables to run from the temp directory / directories
  • Implement firewall egress filtering. Set up a proxy with deep packet inspection that intercepts SSL / TLS connections and blocks outbound traffic that seems suspicious.


  • Do not give local admin access to end users. Just don't. If they need to raise privileges assign them a special account that they have to use the "Run As..." functionality to use, but end users should not have administrative privileges on their workstations.
  • Software restrictions / egress filtering / AV / Education / disabling executables from temp directory all still apply for internal
  • Segregate your network to prevent lateral movement in the instance there is compromise

You'd be surprised how successful something like this can be - especially for a typical user who may not have any security controls in place. Also, I would argue that if you are able to convince a user to execute code you have provided, a malicious exploit is probably not even necessary - (i.e. "Microsoft Tech Support calls" that obtain remote access to systems utilizing legitimate tools).

In a corporate environment, there would be a variety of security measures that should help to prevent (stop it from happening) and control (limit the successfulness) of such an attack. Most companies take a layered security approach with multiple measures in place.

Walking through how such an attack would take place, here are some of the controls that might be implemented for an attack like this:

  1. Provide malicious file to user via email or other means

    • Email filtering (Antispam, AV, whitelisting), Email policies (Attachment restrictions such as size or file type)
  2. User saves file and launches it
    • User awareness training, group policy restrictions (prevent files can be launched from), application whitelisting (prevents unknown files from running), Endpoint AV (scans/deletes/blocks known malicious files).
  3. File launches and establishes connection back to attacker (perhaps via an exploit or via legitimate software
    • Endpoint and/or network (egress) filtering or proxy (block unknown/untrusted connections), system patches (block known exploits)
  4. Attacker gains control of system, exfiltrates data, maintains access, and spreads laterally
    • Restricted user permissions (i.e. non-admin), monitoring tools (to record forensic activity for later review)

I'm sure there are more but this was briefly pulled from the top of my head - but you can always take an attack, walk through the appropriate steps, then think of potential mitigations for those steps - and of course you can then rinse, repeat with more attacks against those mitigations.


First and foremost you can adopt a firewall policy of "allow what's needed, block the rest". That will only go so far because your malicious outgoing link may take advantage of a hole you have poked in the firewall.

Enterprise grade products will "hook" certain functions like connect(). By hooking the function an analysis engine determines if the connection is legit or bad. This decision take many data points into account like where is the connection going, what prompted the connection, etc...

If you OSX and want to see this in action get a copy of a tool called Little Snitch. This program will hook outgoing connections and allow you to decide if it should be allowed or not.

  • A reflective DLL loaded in the browser's address space make it very difficult (impossible?) to decide on the network layer whether the connection is legit or not.
    – void_in
    Commented Jul 21, 2016 at 5:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .