I wish they would come out with everything they know, what they are doing (if anything) to help limit the utility of TV as the attack vector, and provide some concrete guidance.Īs of now, no one in the Teamviewer Breach Masterthread had 2FA turned on when they were breached.
#Teamviewer hacked password
I certainly don't think the local Windows user account password would be.Īt this time, I don't think TV is the root cause of the attacks, though they are certainly the attack vector. I would be surprised if the local custom password was stored on TV servers. I think credentials were somehow compromised. There is no sign of brute forcing attacks.
In most cases the attackers authenticated using the Custom password. In most cases windows was LOCKED at the time of connection, and the attacker either was able to circumvent it or knew the password. The attackers are spending between 10 minutes and a few hours connected. So far, there appear to be three different patterns to the login (not all of which I have been able to replicate in testing). I have examined log files from a few people that confirmed they were hacked. simulating Ctrl-Alt-Del (with SASLibEx)Ĥ) 13 minutes after connecting, the clipboard was used three times to take data off the computer CClipboardController::SendClipboardContent: (3 data formats)ĬClipboardController::SendClipboardContent: (3 data formats)ĬClipboardController::SendClipboardContent: (8 data formats)ĥ) 17 minutes after connecting, the client disconnected. Hopefully some of these entries in the log may prove helpful to others trying to search their logs for odd entries.ġ) Client connected using custom password CLoginServer::PasswordLogin: AuthOk with CustomPasswordĢ) Windows was locked at the time of connection CServer::ChangeToServermode: WindowsSession Locked: yes, secure screensaver running: noģ) Less than 10 seconds after connecting Ctrl-Alt-Del was sent to the machine. I need to do some more testing in the morning to try and replicate some of the stuff I see. I searched for terms included in the line with the ID's from my logs and found nothing from that in this log. In all my tests it was scattered throughout the logs during the connection. First, I can't find the TeamViewer ID of the connected client anywhere. I have a log from someone who was hacked and it's different than what I have created during testing. This would make a basic brute-force attack time consuming, but might not rule out some kind of distributed attack (which is beyond my means of testing easily). After their 30 second ban, it appears they are limited to 2 attempts with a 60 second ban with consecutive attempts increasing the ban time (with two attempts each). If a user tries to connect during a ban you will see "CLoginServer.AuthenticateServer: still blocked" in the log. If someone uses all the retries, it bans that ID for 30 seconds. You will have to search up from that line to find the most recent instance of "client hello sent" which shows their TeamViewer ID. That line will also show the retries remaining (default seems to be 5). You can search for "Authentication failed" to find instances of someone attempting to connect and entering the wrong TeamViewer password. Since any successful connections are shown in Connections_incoming.txt, this is mainly useful to search for failed connections. There's a lot of crap mixed in here, so I am using search to jump to what we're looking for. This appears to rotate, so there's also a TeamViewer11_Logfile_OLD.log file as well, which is just older data. It's called TeamViewer11_Logfile.log (replace 11 with the version you are running if it's not 11).
There are two log files that you can check for connections. (Note: All my testing was done on the latest TeamViewer 11) I want to share my findings in hope it can help someone else. I have been doing some research as we have a number of computers running TeamViewer in sensitive commercial environments.
0 kommentar(er)
