Simple Help attacked

It sounds to me like this is an inside job - somebody working in the company. The chances of a hacker being able to simultaneously hack Simple Help and Avast is remote. Usually malware attacks one target whereas this sounds like a very specific attack for your company.

Maybe I am wrong, but the fact that the logs were deleted as well does feel like an employee trying to cover his tracks.

I will pose a few questions of my own here. I have always closed Simple Help Technician. I am not aware of any logoff button. Where do you logoff? Did this attack occur as result of the technician being logged onto Simple Help Technician at the time or just having the software installed on their computer?

Have a look at event viewer in Windows on the Simple help server to see if there is anything there.
Try easus data recovery to see if you can restore the log files. But also ensure that you start backing up the log files.

Yes I agree, point 2 is very concerning. I would like an answer on this point as well. I think by default there needs to be more security against a file being deployed on so many machines. This is a very serious security design flaw that needs to be addressed.

A question that I would like answered would be could a client computer that has remote access installed infect other machines using simple help or is the transmission one way only - from server to client? More information on this point would be helpful in terms of what a hacker could do with a stolen computer running remote access.

What I have done with my server which hosts Simple Help amongst other things is using IP Address restriction to lock down admin and user access for as many of the services as possible. Perhaps the same could be done for Simple Help as well - to block technician access to Simple Help outside client and office locations?

1 Like

Based on what we have heard so far there does not appear to be any evidence that either SimpleHelp or Avast was hacked. Rather the technician’s machine was compromised and they were logged in to both SimpleHelp and Avast and were absent at the time.

There is a logoff button in the technician preferences tab under Account (the top entry).

Regarding point 2, being able to deploy a script to multiple machines rather than having to take the same action 700 times is not a design flaw it is the entire point of the feature. There are permissions to disable this facility on a per-tech or per-tech group basis if you wish to make it unavailable but limiting this by number (e.g. 10 machines max at a time) won’t prevent a bad actor that has already gained access as an authorised user from carrying out the same attack on all the machines, it will just take them a little longer.

As with the technician console timeout, a limit would not prevent any attack from a security standpoint. Rather the focus has to be on preventing bad actors from gaining access as an authorised technician. We have a number of features in place such as MFA and technician client login IP restriction to ensure that tech accounts are secure from hack, but fundamentally if the technician logs in to SimpleHelp (or any other software, like Avast) from a compromised machine and then leaves the bad actor free to use it, whether by accident or intention, then any software on that machine that is already authenticated is open to abuse and there is really not anything that any of that software can do about it.

Remote Access service machines are not considered privileged and do not have any of the abilities of authenticated technicians, it is not possible for them to run scripts arbitrarily on other remote access services.

6 Likes

Agreed, I would hate to have this feature removed. I would have to look at another product. I do think though ( just my opinion ) there should be an additional confirmation when running tools. I have accidentally been bumped and ran the wrong tool from the list. Not a deal breaker though.

As with the technician console timeout, a limit would not prevent any attack from a security standpoint. Rather the focus has to be on preventing bad actors from gaining access as an authorised technician. We have a number of features in place such as MFA and technician client login IP restriction to ensure that tech accounts are secure from hack, but fundamentally if the technician logs in to SimpleHelp (or any other software, like Avast) from a compromised machine and then leaves the bad actor free to use it, whether by accident or intention, then any software on that machine that is already authenticated is open to abuse and there is really not anything that any of that software can do about it.

I agree with this as well but again ( just an opinion ) a configurable timeout, something that can be enabled and configured by the SimpleHelpAdmin, would help the absent minded. Though he should also have a lock screen set on his PC when away as well. That may or may not be enforceable though depending on their environment.

1 Like

5.2.12 includes a Technician Console timeout option as part of the Technician Group Permissions. It works as follows:

  • It is set in the Session Limits tab in much the same way as the session timeout.
  • Any activity in a session will prevent the Technician Console from timing out.
  • When the timeout is reached the Technician Console shows a new dialog that gives the user one minute to act prior to logout.
4 Likes

I agree and have spoken with SimpleHelp support about this before. There needs to be a confirmation prompt to the technician. We have been burn a few times on running the wrong toolbox task.

1 Like

When is 5.2.12 expected to drop? Thanks!

George said some time next week, hopefully the start of the week.

I would highly recommend that the logoff button be moved to the top row where you see remote support, access etc. I have been using Simple Help for nearly two years and never realised that there was a logoff button because I usually never click on that preferences tab.

Sorry you misunderstood me. I don’t recommend removing the ability to deploy scripts etc to say 700 computers. However I think that there needs to be more security steps/confirmation to ensure that you really did intend to run that toolbox to prevent a malware script from accessing the toolbox and running things automatically. Another feature I could suggest would be before a file is deployed to machines it is checked against virustotal.com to make sure it’s not a virus. There are lots of things that can be done to protect against malware scripts, although it sounds to me in this particular case that a human agent manually did the damage.

Thank you for confirming about remote access Service Machines as this was something I wanted to look into. My next step will be to decide whether to have all clients using tcp or udp as the connection.

I would like to see the ability to send the logs to syslog (in linux) or event viewer (in windows) or other logging service.
Or even a way to specify they be automatically sent to a rsync or sftp service.

Concerning this being on inside job; there are only 5 of us technicians all of which would not have done this. We believe we were likely hit by the same hacking group that hit Argentina a couple days later on 7/18: https://www.zdnet.com/article/ransomware-gang-demands-7-5-million-from-argentinian-isp/

Can someone point me to the specific setting that restricts a tech from running scripts outright? I understand why some of you guys want to run scripts against all Access PCs at once, but this is not a feature that we need.

The tech PC that was hacked was not logged in as SimpleHelpAdmin. I don’t understand how the hacker was able to remove the logs without being a Simple Help Admin. The hacked PC was also outside the SimpleHelp server LAN, so it only had access to Simple Help server via the Simple Help technician client.

We do have nightly backups of the SimpleHelp server. I’ll see if a backup from the night of 7/13 would happen to contain any trace of their activity. If the rogue connection and the deletion of the log file both happened ‘after’ that backup, then they have successfully covered their tracks.

You should log in as administrator, click on ‘Groups’ in the administration tab, and then click on the group your techs are in. Then click on the ‘Permissions’ tab on the right, then scroll down to the ‘Toolbox’ section where you can allow tools to run in the access tab, and also whether tools can be run during sessions. 2020-07-28_11-17-30

I was wondering if they RDP into the machine running SimpleHelp?

Also do you use 2FA with SimpleHelp and have you limited IP access?

Hello Everyone.

We just moved over to SimpleHelp also, We also replaced our firewall with a Sophos XG firewall and going to use GEOLocation Lockdown.

Just thinking it might also be worth updating your Hardware Firewall.

Az

I noticed you and @Darrell_Swafford mentioning this months ago, but since the topic has been bumped I really, really third this.

Off-topic: The toolbox is frankly quite dangerous the way it stands, especially as it doesn’t carry over the notes via a tool tip or something. I often go to run something on a machine, hesitate about whether this is the correct tool, and have to go to the toolbox tab to look at the tool/notes and then go back to the endpoint, and I wrote the damn things. My prefered UI would be click the tool > this drops down/reveals a Run button along with the note for the tool if present > confirm that this will be run on $MachineName

If it could have an option to schedule a later time and a “skip offline machine” checkbox that would really make my year.

To be fair to SimpleHelp, Automate/Labtech don’t show the descriptions for the script either and SimpleHelp is definitely far better than anything from CW in terms of UI, but this would be a really important addition.

1 Like

Great suggestion for the toolbox. Open a Feature Request ticket about it. I’ve found the developer to be extremely responsive to new ideas/changes/bug reports, with many of my requests ending up in the next released update.

2 Likes

The SolarWinds incident alone should highlight the risks with any automated tools.

There are risks with all automation. I feel like SimpleHelp has evolved it’s security to mitigate most issues. Provided the end user enforces good policy to back it up.

Never leave the tech console logged in and unattended. ESPECIALLY where the technician app is installed on a mobile device.
Enable MFA.
Never use the primary admin account for day to day.
Enable session timeouts
Make sure the device that is running the technician app is properly protected and secured.

The above is not a comprehensive list of security items but a good starting point.

3 Likes

My main client recently underwent a two-day in-depth security review. 52 action points ranging from an hour to months…

Rob: Anything of general applicability that might be good for all to think about? :slightly_smiling_face:

Yay! I actually do all those things. The session timeouts are a pain, but I set them like that for a reason.

Another thing we practise: If you are on site, never be tempted to use a customer PC for remote support, just because you happen to be in front of it. Use your own laptop or tablet, or nothing at all.