|
Posted by Arturo Gueta on May 30, 2007, 7:53 pm
Please log in for more thread options Why don't you tell us where domain server saves the logs?
so, i need to know this too, i had the same situation.
thanks.
>I think I understand the situation a bit better now, but...
>
> When you refer to "the system administrator ID", is that the domain
> administrator account, or the administrator account local to the machine
> that was attacked?
>
> Also, the perpetrator is said to have logged on to the victim's PC
> "through their workstation": how did they do that, using remote desktop?
>
> As I see it, then, the perpetrator logged into workstation "A" using
> account "B", then ran MSTSC.exe to connect to XP system "C", where he then
> "logged in" as the administrator. In order to determine the actual
> identity of the person, you would first need to know that there would be a
> one-to-one relationship between the personal accounts used and the owners
> of those accounts. In other words, if you could determine that which
> actual account is what I have referred to as account "B", then its owner
> would be the bad guy.
>
> If you could determine the originating PC, I would suspect you have
> already been looking at the event log entries most likely to contain this
> information. It might not give a workstation name, but perhaps some
> identification of the connection that could be traced back somehow. Sorry,
> but I don't know much about that.
>
> If you could do that, then you would still need to figure out which
> account was the last one to logon to workstation "A" before the time of
> the event. Again, that should be found in the event viewer, this time of
> the bad guy's workstation.
>
> But you asked about finding out from the domain controller which computer
> "this person logged in from". As I understand it, the domain controller
> may not actually keep such records. Even if it did, I don't think it would
> keep a perpetual log of who logged in where and when - perhaps just some
> stats on the last workstation a person logged in from. Someone in my
> organization has stated that there is a way to do this by enabling some AD
> feature, but nobody has been able to give me any actual details. And
> anyway, in this case, I don't think you know who the person is in the
> first place, so it would be difficult to find out where he logged in from.
>
> I would think that you might need to use other, perhaps less technical,
> methods to determine who did what, and how, and why. For example, do you
> have security cameras...
>
>
> As to how to prevent this kind of thing from happening, I believe one of
> the best things is to stop allowing accounts (especially privileged ones)
> from being shared. The actual administrator account, whether a domain
> admin or a local admin on a server or workstation, should almost never be
> used. Those individuals whose roles require administrative access to some
> resource should each be given their own administrative account (separate
> from the personal account they use for email and etc) that is added to
> whatever groups required, whether the administrators group local to a
> workstation or server, or the "domain admins" group in the domain. The
> structure of these permissions should be such that you can readily ensure
> that the admin users have admin access only to those resources they have a
> responsibility for.
>
> Passwords to actual administrator accounts should not generally be known
> by anyone, and perhaps left locked up somewhere in case they are ever
> needed. I am an administrator on one server, but I have absolutely no idea
> what the password for the administrator account is, and only knew it when
> it was created at install time. Since then it has been managed and secured
> remotely.
>
> This will not prevent the rogue admin syndrome from happening. But since
> they will have to use an account whose password should be known only to
> them, your list of suspects will be much shorter. And perhaps this
> additional accountability will dissuade some from even going rogue in the
> first place.
>
>
> /Al
>
>> Hi Al,
>>
>> okay, let me elaborate on the network setup. We have a MS 2003 Server as
>> the domain controller. I suspect an employee who used the system
>> administrator ID and password to logged into a PC through their
>> workstation and deleted files and folders. This person is one of 3
>> persons who has the password and ID to the administrator password.
>>
>> From victim's PC, we are able to view from the event viewer that the
>> administrator had logged in and deleted something. How we come to know of
>> the incident was that the user complained of missing folders.
>>
>> What I am concerned with, am I able to view MS 2003 server log to know
>> which PC this person logged in from. Or maybe tools available.
>>
>> Maybe you can give me some guidelines to prevent this type of incidents
>> happening.
>>
>> Al Dunbar wrote:
>>>> Hi, I have a situation where an employee had logged into the domain
>>>> network as an administrator and got into a PC to delete certain folders
>>>> in that PC.
>>>>
>>>> Can I obtain information such as :
>>>> 1. Which PC the administrator logged in from
>>>> 2. Which PC the administrator got into
>>>> 3. Time and date the incident happen
>>>
>>> You don't give much to go on. For example, do you know the administrator
>>> account that was used? Do you know who it was that did this? Is that
>>> person authorized to use the administrator account.
>>>
>>> And, if you do not know on which PC this happened, how did you become
>>> aware that any folders went missing?
>>>
>>> As to the specifics:
>>>
>>> 1. I don't know of a standard way to determine this. we do it by
>>> examining logs created by our logon scripts, but even then, a rogue
>>> administrator would be able to cover his tracks. I have been told that
>>> ad2003 may have a way of doing this, but the feature needs to be
>>> enbaled, as it is off by default.
>>>
>>> 2. you could search the hard drives of all workstations to see which one
>>> has these particular folders missing. Not much good if it was unique
>>> information and you want it back.
>>>
>>> 3. if you are not already doing extensive auditing, this may not be
>>> possible. That said, it might be worth having a close look at event
>>> viewer to see what kinds of events are being recorded there.
>>>
>>>
>>> /Al
>>>
>>>
>>
>
>
| 
XML Sitemap