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.
I need to make sure all technicians are automatically logged out after x amount of hours
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
We also have to figure out how the Simple Help log was deleted.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
Remote Support
Remote Access
Monitoring and Management
Presentation
Remote Work
Standard
Business
Enterprise