none
Virtual Machine hacking RRS feed

  • Question

  • We have been doing some work with Virtual Machine and we now have multiple cases of where a VM has had software installed into it that we did not put there.

    Firefox and Bonjour have been the two applications identified so far.

    One machine we found a number of denied logon attempts from a foreign IP.

    Needless to say, both VMs have ben destroyed.  But this does raise concerns.

    Has anyone else noticed anything similar?


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Wednesday, November 28, 2012 4:49 PM

Answers

  • I finally got my blog article out with all my ideas (more than mentioned here):

    http://itproctology.blogspot.com/2012/12/securing-azure-virtual-machines-or-i.html


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    • Marked as answer by BrianEhMVP Thursday, December 13, 2012 6:33 PM
    Thursday, December 13, 2012 6:33 PM
  • Thanks for asking Bill.  I am going to blog the entire thing.  I am not afraid to tell the shaming tale.

    This is an exploit tripping around the Virtual Machine(s).  Describing a little bit about it, you can understand why.

    Specifically how the exploit is working:

    It is attacking open RDP endpoints with a brute force password attack.  It is driving the RDP protocol programmatically (there are lots of off the shelf testing tools that do this too).  Using well known local accounts (.\administrator).  Once in, the password of the local account is changed, the machine becomes a zombie and your machine is part of something much larger.

    And then it propagates itself, searching for others to infect.

    1. establish a local administrator account that is not 'administrator'
    2. Use a 'strong' password.  Actually, complex + strong.
    3. Don't use 3389 as your public RDP (administrative) port (it will just take longer to find you though).  The first Virtual Machine of a Service is 3389 by default.
    4. Remove the RDP endpoint if you are not needing it.  And only add it while needing it.
    5. Use something other than RDP to manage your Virtual Machines (GoToMyPC, et al)
    6. Use the Virtual Network Gateway and VPN to administrator your Virtual Machines (if it fits your model).

    I am sure you can think of more measures.


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Monday, December 3, 2012 5:24 PM

All replies

  • Hi Brian,

    Would you send me an e-mail to iaasforum at microsoft.com?  Include the forum link and title.  I'd like to get a bit more information.

    John

    Thursday, November 29, 2012 4:29 AM
    Moderator
  • What type of VM was this? Was this one of the windows VM templates?

    Regards, Bill

    Monday, December 3, 2012 4:40 PM
  • Thanks for asking Bill.  I am going to blog the entire thing.  I am not afraid to tell the shaming tale.

    This is an exploit tripping around the Virtual Machine(s).  Describing a little bit about it, you can understand why.

    Specifically how the exploit is working:

    It is attacking open RDP endpoints with a brute force password attack.  It is driving the RDP protocol programmatically (there are lots of off the shelf testing tools that do this too).  Using well known local accounts (.\administrator).  Once in, the password of the local account is changed, the machine becomes a zombie and your machine is part of something much larger.

    And then it propagates itself, searching for others to infect.

    1. establish a local administrator account that is not 'administrator'
    2. Use a 'strong' password.  Actually, complex + strong.
    3. Don't use 3389 as your public RDP (administrative) port (it will just take longer to find you though).  The first Virtual Machine of a Service is 3389 by default.
    4. Remove the RDP endpoint if you are not needing it.  And only add it while needing it.
    5. Use something other than RDP to manage your Virtual Machines (GoToMyPC, et al)
    6. Use the Virtual Network Gateway and VPN to administrator your Virtual Machines (if it fits your model).

    I am sure you can think of more measures.


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Monday, December 3, 2012 5:24 PM
  • Sure - this is systems administration 101.

    Reason I ask if this was a template or a VM you imported...

    The template VM's that Microsoft provides, do not use RDP port 3389. Also make sure to rename the "administrator" account if your going to use it. Better yet disable it and create a new account.

    I wouldn't consider this an exploit.


    Regards, Bill

    Monday, December 3, 2012 5:35 PM
  • The templates (on provision) actually do set up 3389.  Unless that has very recently changed. 

    The first Virtual Machine deployed in an "IaaS Service" gets 3389 mapped to 3389.  Only using the API can you prevent the endpoint from being created by default, or defining its port number.  Any Virtual Machines in an "IaaS Service"beyond 1 get an ephemeral port mapped to 3389 by default.

    The machine is being exploited / hacked.  Is it patch related, no.  Simply opportunistic.

    Folks just are not locking things tight enough.  Or things are being deployed and played with without the extra measures put into place (that an IT department would impose).

    Still.  Better to learn about these things and how they are working as that feeds back into practice.

    So for quick test environments that are not under the watch of IT or security folks.  There is huge potential.  A machine could be compromised simply as it is being secured, after provisioning - very quickly.


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.


    • Edited by BrianEhMVP Monday, December 3, 2012 5:46 PM
    Monday, December 3, 2012 5:42 PM
  • The VM templates use 3389 on the internal private network, but use a randomly generated public port that redirects to 3389. So, in other words by default the 3389 is not used or open.


    Regards, Bill


    • Edited by Bill - MCSE Monday, December 3, 2012 5:51 PM
    Monday, December 3, 2012 5:50 PM
  • My experience has been that the first Virtual Machine in a Service gets 3389 as the public RDP endpoint (I know of others that had a machine or two compromised that also mention this behavior).

    I am strictly talking of the IaaS "Virtual Machine" in Preview.

    Unless, like I mentioned, the default endpoint for the first VM in the Service has very recently changed (as a result of this hack propagating around).

    I just deployed a Virtual Machine from a Gallery image and got 3389 on the internal endpoint (as expected) and also 3389 as the public endpoint (as I expected).


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Monday, December 3, 2012 6:56 PM
  • Which machine is that? All the one's I've used all used a random public port for rdp.

    Regards, Bill

    Monday, December 3, 2012 6:58 PM
  • Any Windows Image.  That particular was one of my own gallery images.  Not using quick create.

    And, it is its own service - standalone.

    If I deploy to an existing service then it gets an ephemeral port.  But not the very first one by itself.

    The same thing happens if I create a bunch of Virtual Machines using PowerShell into a single new Service.  One gets public 3389 all the others an ephemeral port mapped to 3389.


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Monday, December 3, 2012 7:01 PM
  • That is the correct. The first VM in a Cloud Service uses port 3389 externally. Additional VMs after the first one use an ephemeral port. Months ago, they all used ephemeral ports but some customers found this confusing since most of them use only one VM per Cloud Service.

    Strong and Complex passwords are always recommended. You may also change the external port of your endpoint. Do not choose ports within 3 higher or lower than 3389 (3387-3341) as these ports are also commonly targeted.

    Best regards,

    -Steve

    Tuesday, December 4, 2012 1:00 AM
    Moderator
  • I finally got my blog article out with all my ideas (more than mentioned here):

    http://itproctology.blogspot.com/2012/12/securing-azure-virtual-machines-or-i.html


    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    • Marked as answer by BrianEhMVP Thursday, December 13, 2012 6:33 PM
    Thursday, December 13, 2012 6:33 PM
  • I was checking out the forums when I came across this. Please allow me to indulge you with an idea.

    A few days ago my windows 7 machine was hacked and I wasn't able to figure out how they had made it impossible for me to recognize their presence while maintaining control, complete control, of the way that my laptop "seemed" to be acting despite evidence that it was doing otherwise, for instance, it seemed as though my wireless functions were off, yet somehow my laptop was still connecting with the router, though I personally couldn't use the connection and even lost access to my own machine though I still seemed to have administrator privileges, this was just after I had migrated into Microsoft Live and some sensitive information was extracted from my laptop as well as other strange things that happened, my router was hacked, DNS hijacking, etc, etc. 

    I also noticed that it seemed like processes from Bonjour and Firefox were involved but I'm no expert.

    My question is, could it be possible that after a hacker gains administrative privileges, they could somehow create an internal VM, placing a replica of your OS inside it, running a shell around it on your machine and creating a MITM kind of situation using an NT environment to redirect and handle all services while making your machine appear to be running normally?

    Possibly they could even build a BIOS shell that appeared to be booting up if you restarted, or even tried to do a factory restore, being a laptop, it would still have power running to the shell and could mimic a full restore while keeping it's shell running underneath...

    I used to work with NT back in 2000 before I left the field to pursue another career so I have some understanding of how the OS is working but honestly I forget almost all of it and I was no guru in the first place. I had just enough understanding to really try to get into this and I'm no match for a legit hacker but it occurred to me, after seeing this info about Virtual Machines, that it really felt like that is what was happening to me.

    This wasn't just some hacker pulling out credit card numbers, it was much more but I'd be interested to talk to someone about that offline

    David Patrone
    davidpatrone at gmail 

    you can easily find my contact info if you google me


    Thursday, June 13, 2013 11:41 AM