Link to home
Start Free TrialLog in
Avatar of vistasupport
vistasupportFlag for United Kingdom of Great Britain and Northern Ireland

asked on

Rogue remote control identification

Hi all

We had a report from an end-user this morning about a rogue remote control session on her PC. The user witnessed the remote session reading e-mails and then shutting down her PC.

I've checked the event logs and there's nothing there, and have also ran a number of anti-spyware tools (CA, AVG, MalwareBytes, Spybot Search & Destroy) and none of them have found anything malicious.

What else can I check to identify the cause and source of the intrusion?

Cheers,

Paul
ASKER CERTIFIED SOLUTION
Avatar of Gerwin Jansen
Gerwin Jansen
Flag of Netherlands image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of vistasupport

ASKER

the only results from the GMER scan is that our AV product (CA) is being identified as an API Interceptor.

Other than that, there's no other entries.

I will reinstall the system, but I'd like to identify the cause to try to prevent future occurrences, as well as provide answers to senior people - something I can't do at the moment.

Thanks

Paul
In that case, what kind of remote / management application are you using? It may be as simple as someone knowing a password and just using Windows Remote assistance or some other commercial aplication that you use. I'm assuming your WindowsXP is SP3 and fully patched.
We use Dameware remote control, which writes to the event log upon connection as well as notify the end user.  Windows Remote Assistance is disabled.  Yes, Win XP SP3 fully patched through WSUS.

I've now run 5 different scans against and still not picking anything up.  How likely is it that such a tool can completely remove itself and if it is doing that, how is it getting back on (assuming the attacker would wish to get back on)?

I'm struggling to understand how there's no trace of such activity.

Thanks

Paul
>> How likely is it that such a tool can completely remove itself and if it is doing that, how is it getting back on (assuming the attacker would wish to get back on)?

I'm afraid this is possible in theory but it will require that the person has knowledge of an administrative password (domain or local) or a 0-day security issue. Copying files through a share to %TEMP%, starting a service through psexec, connecting and reversing the whole, including removing its traces.

This is a difficult case, I'm thinking of a way to log all inbound traffic, either by means of a firewall or some packet logger like wireshark.

Has this issue happened again in the meanwhile? Do you know of the same incident with other employees?
Did you find any evidence at all of this happening, apart fromt he User 'seeing it happen' ?

Not to discredit the user, but I've seen users having misinterpreted technical issue's rather often.
For example, a wireless mouse with low battery can do funny things with a mouse and a restart could also be caused by windows update.

gerwinjansen - We haven't had reports of any other incidents so this does seem to be an isolated event.  We'll take a look at the security on our LAN as we've just gone through some log files with our firewall people and there's absolutely no evidence the attack originated externally.

sarcast - from the users description, it's unlikely to be a technical issue.  The remote session loaded up some e-mails and then clicked on the Start button, chose shutdown and then shutdown the PC.  That seems to be a clear number of specific steps.  We did initially think it was technical, but after that description it's unlikely.



>> we've just gone through some log files with our firewall people and there's absolutely no evidence the attack originated externally

That is (partially) good news, means that no one was able to access your system(s) from the outside. But it also means that someone from the inside may know admin usernames/passwords. I would change them if this is not already normal practice after such an incident. Do you have local admin accounts or only domain admin accounts?
Yes, it seems unlikely we are going to track this down so we need to review our security.

We have local admin accounts on each PC, but member server admin accounts are disabled. Default domain admin account is also disabled.

Looks like we need to reset the password on every local admin (or disable it?) and lock down the firewall to only accept Dameware connections from specific IPs (those in IT dept).

One problem we have is managing password change for remote users.

We have two groups:

Business Development team - equipped with laptops that are members of our domain, but have offline files enabled. They visit the office and connect to the domain on an irregular basis - there's no guarantee that they will receive a password expiry notification (currently 14 days) during their visit.

Field workers - will login to OWA & Sharepoint via a remote web browser (home PC, etc) from non-domain PCs.

Currently we set their passwords to not expire - what's the best way for them to change their password while off our domain should their password expire?