Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 1996 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Tricky way to use the SEC to execute/schedule a program on a remote endpoint

RobertoF

A Sophos engineer a few years ago showed us a trick that could have allowed us to run an executable on a remote endpoint by using the SEC messages. I didn't document it at the time as I thought we had other tools to do that and didn't need another one. But now we have an endpoint that lost its trust with the domain, has the local admin account disabled, and is in an unreachable physical location so nobody can login into it remotely or even onsite to re-install Windows.

As Sophos is the only application that is still working on the device... if we can figure out how to use the message router to run a command remotely on the endpoint we'll be able to regain access.

Does anyone know how we could do that?



This thread was automatically locked due to age.
Parents
  • 0

    Hello RobertoF,

    I'm not aware that RMS (and SEC) ever allowed custom messages that moreover resulted in the execution of arbitrary commands.

    in an nreachable physical location - but doing some useful and perhaps important work? And running Windows [:P]? Guess you wouldn't try to re-install Windows remotely. Whatever action you'd take you have likely just one try.

    Christian 

Reply
  • 0

    Hello RobertoF,

    I'm not aware that RMS (and SEC) ever allowed custom messages that moreover resulted in the execution of arbitrary commands.

    in an nreachable physical location - but doing some useful and perhaps important work? And running Windows [:P]? Guess you wouldn't try to re-install Windows remotely. Whatever action you'd take you have likely just one try.

    Christian 

Children
  • 0 in reply to QC

    Hi Christian,

     

    I confirm it's possible - we had Sophos Professional Services onsite for two weeks during our initial Sophos rollout, and he proudly showed us an undocumented trick that allowed us to do just that. I think it involved using one of the functions of the SEC to deploy a script that was then executed on the endpoint... if I could just remember!

    Too bad it's actually not an XP machine, otherwise we could have used one of the un-patcheable exploits to get in! It's a Windows 7 patched to the latest publicly available updates, and all my Metasploit attempts to break in have been unsuccessful so far.

     

    Roberto

  • 0 in reply to RobertoF

    SEC scheduled a task to run straight away which runs setup.exe from the CID.  Did they replace setup.exe in the CID with a customer setup.exe that did what you needed?

  • FormerMember
    0 FormerMember in reply to RobertoF

    the scripting calls in SEC are not meant to alter the OS - they are for our own components.

    In theory, you could deploy a PS script (not sure how you would get it onto the box if there is no trust) but based on what you are describing I have little hope of success. A domain trust break can be indicative of some serious problems on the box (HDD sectors failing, corrupted memory, amongst other things). However, you could try unjoining it -> have the script output a log -> check the log for success -> then try a join. There will be a reboot (maybe two) in there so that's a risk. 

    It would be very risky. If I was you, I would get my hands on the device before attempting anything.

    SEC will not be able to help you here. If you just throw a file in the CID that won't do anything - the endpoints only download files that are signed and part of their manifest - you can't use SEC to infiltrate a system.

  • 0 in reply to FormerMember

    AutoUpdate will not pull down any old file added to the CID but the deployment workflow from SEC schedules a Windows task to run setup.exe from the CID.  That's just a Windows Scheduled Task once created and will run the setup.exe it points at.

    Of course this deployment workflow doesn't use RMS, just DCOM to create the remote scheduled task and the computer needs to be on at the time of creation, so if you can do it in SEC, you don't really need SEC but maybe it's a convenient way of performing the task on a number of machines in a particular group for example or in a specific state in SEC.

Unfiltered HTML