SimpleHelp Community

Simple Help attacked

#1

We had an incident on 7/14/2020 where a technicians PC was hacked and Simple Help was used to deploy the sodinokibi ransomware to all PCs connected to Access. About 700 PCs. Also the same PC had access to our cloud managed Avast Cloudcare. This was also hacked and all end point protection was turned off before before sodinokibi was deployed. I have been trying to discuss this with Simple Help but so far they refuse to call me back. I have to make a choice between securing Simple Help or abandon it. My preference is to keep it, but I need a few solutions.

  1. I need to make sure all technicians are automatically logged out after x amount of hours
  2. I need engineering to provide some insight into how the backend script was run and what we can do to limit a technician so that a script can only be run against ‘access’ computers that he is connected to. Currently it is obvious that a script can be run against all 700 computers at one time. Can’t have that
  3. We also have to figure out how the Simple Help log was deleted.
#2

Shit… That’s harsh.

Do you use Simplehelp to allow access to the Simplehelp Server itself, or is that running under Linux?

I think that we ought to suggest a login timeout to the devs. How did the technician’s PC get hacked? Was he not running an antivirus? Did they get ransomware’d as well?

I do think that the security in Simplehelp is higher than others, mainly because you host it yourself. It’s as secure as your own server, rather than relying on employees elsewhere not being compromised through phishing or social engineering, or hacking. You’re a smaller target too.

It makes me wonder just how clever these hackers were, because they’d have to first hack into the technician’s computer, and then work out how simplehelp worked, and how best to deploy stuff with it. It’s not hard, but it’s not something you instantly know how to do without testing it. They must have had access for some time before the ransomware was deployed.

What’s happening with the 700 PCs?

#3

There’s a facility to set a timeout, but that’s just a date at which the user will be disabled. There’s another timeout for sessions, but that relates to idle remote sessions, not technician logins.

#4

Hi ElectSys,

We’re sorry to hear about this exploit, particularly since it was the attack on a SimpleHelp technician’s local machine that allowed the software to be distributed.

Our request is always for additional information when security breaches such as this are reported. The more information we are presented with the easier it is for us to better understand whether SimpleHelp was compromised, the nature of the attack, and whether other SimpleHelp server are vulnerable.

From the brief information you sent us on Friday and have posted here it looks like access was gained to a technician’s machine (and thereby Administrative access to the SimpleHelp server).

Some things we suggest:

  • it is usually more feasible to automatically logout the inactive OS user rather than to specify this on an application-by-application basis. Logging out the user has advantages to locking the workstation (particularly, session tokens will automatically require renewing). Of course, if the machine has been compromised the malicious user might monitor keystrokes to subsequently gain OS-level access.

  • enabling 2FA in SimpleHelp will ensure that even if the technician’s password is compromised the malicious user won’t be able to login.

  • you can disable tools in the Access tab. It is a Technician Group permission (Toolbox > Run tools in the Access tab). This will not disable tools from running in the session.
    it was not the server log that was modified, but the history of sessions (this can be modified by any SimpleHelp administrator). There is no mechanism to modify the server-side log via the Technician Console.

Once we receive the logs we asked for we will better understand what actions were taken by this malicious user.

#5

In regards to logs.
If your SimpleHelp server was also logged into by the hackers, then removing the logs wouldn’t be that hard for a determined team. Probably not the first time they have done this.
This could well have been planned in advance, hackers could recently have signed up for a SimpleHelp trial, figured out all the techniques needed to do what they did, and then executed the hack.

To protect the logs…back them up, and copy those logs offsite so they cannot be deleted.
Protect your SimpleHelp Server. Is there a hardware appliance firewall between the SimpleHelp Server and the Internet. Are the logs for that device being backed up?

Above all don’t feel too bad.
2020 is a terrible year.
In IT, when we are wearing our System Administrator hat on trying to protect all the IT assets, we are trying to get everything right. The hackers only have to get one thing right.

#6

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?

#7

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.

#8

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.

#9

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.
#10

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.

#11

When is 5.2.12 expected to drop? Thanks!

#12

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

#13

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.

#14

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.

#15

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.

#16

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

#17

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

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