Account Logon Time Restriction

[Guest]

We are operating SBS2003. Today I noted that there where over 1000 login
failures for one particular user. This user was not on the premisis during
the hours when these occured. I noticed that the Failure audit had a type 3
which indicates that someone tried to log on over the network. Another
interesting point is that the failure audit indicates that the user name and
password were correct. I assume however, based upon the quantity of attemtpts
that someone is doing this with a script. How should I proceed?

Thanks.

 

[Roger Abell [MVP]]

We are operating SBS2003. Today I noted that there where over 1000 login
failures for one particular user. This user was not on the premisis during

I am sure you do understand this, but the use of "user" with two different
meanings above troubles me, and it might lead to less than full clarity
about what is happening. This about "account" and "individual" instead
of "user" in the first and second cases of "user" above.

the hours when these occured. I noticed that the Failure audit had a type
3
which indicates that someone tried to log on over the network. Another
interesting point is that the failure audit indicates that the user name
and
password were correct. I assume however, based upon the quantity of
attemtpts

I do not understand. Username and password were correct ? but the login
failed ? is that where the subject about login time constraint comes in ?

that someone is doing this with a script. How should I proceed?

Perhaps someone, more likely some thing
While is it possible that someone was using a tool to specifically
target your environment, it is more common to see such probes
from bot net / infected / zonbie machines which would probably
bring the environment to the notice of a "someone" or group thereof
if a correct access was uncovered.

You need to determine where this came from, at least as
far as the "from inside or outside" question. If that is not
a real distinction in you environment then you probably
need to rethink how the capabilities of SBS are being used.
If it is from inside, trace it down and find what is originating
this, which could be some errant process or some infection
on a machine that is logged into by that account (perhaps
locked, not hibernated, not on standby).
If it is from outside, try to determine what interface, that is
what access capability, was being utilized, and then ask
why that is exposed to the outside (in fact you should examine
all external exposures asking for each whether they are needed
and if so whether exposed in the most secure but usable way).

 

[Guest]

Let me try to clarify. All of the failure audits reference one specific user
account. Let me also point out that you mentioned a machine being logged into
and locked. I know this user does that frequently. Also you mentioned
determining "where this came from", first things first, how do I determin
inside vs. outside?

 

[Roger Abell [MVP]]

Normally the login messages contain mention of the
workstation from which the login originates. So, is
this recognizable as one of your machines? Failure
login attempts also contain the origin IP, but you are
seeing success. When next this happens, find that
account's likely logged-into workstation, check if
they are logged in with it locked, and if so shut the
machine down. If all attempts end then you know it
is some process running on that workstation in the
context of the logged-in user.

 

[Guest]

Ok, got that. I guess I was trying to make that harder than it needed to be.
It is definately listed as one of our machines, one of our IP's, and on of
our user names. So I will assume it is a process on that box.

I mentioned that the user frequently locks his computer. I spoke to him last
night and had him log out. In the first trial of the experiment the logon
attempts stopped. So it looks as if the simple solution would be just to make
the guy log off. However, should I be concerned about this further? What is
the process that is causing that, should I bother lookin for it?

 

[Roger Abell [MVP]]

I would investigate further, not stopping until I understood what
process was doing this, at least if the network logons were other
than to a set pattern of shares (i.e. the few the user would normally
be accessing to do work/tasks, and at a set interval, say once each
15 minutes). Sometimes frequent accesses can be from local virus
scan that is allowed to work against an mapped drive.
Keep in mind that one vector some malware uses to spread is to
attempt to see what all it can access via network shares.

 

[Guest]

I will have to expose my ignorance here. Based upon what I have seen I would
have to schedule this to the hours we have observed, lock the users station
and then begin to look. I know that once the logon attempts begin the occur 5
times per cycle and they cycle every 2-7 minutes. Aside from that I honestly
have no idea how to track down what process is doing this.

Any suggestions?

Thanks.

 

[Roger Abell [MVP]]

Let's see. Because there are shares on this server where the
login failures are logged, shares to which the user would be
making accesses during normal work hours when it is allowed,
it is not unusual for the account to be targeting that server. Right?

So, it seems a matter of knowing what processes are running
while the user logged into the locked machine.
I would just have a script running elsewhere that did a remote
list of processes to file, sleep for some time, repeat . . . and
end the script execution in the morning and hope to see something
like winword.exe, or outlook, etc. that might be trying to save
something all night long.

Along that line of thought, ask the user to close all of their
applications before they lock their station.

Perhaps if you were to go to
http://www.sysinternals.com
and get pslist from the pstools suite
http://www.sysinternals.com/Utilities/PsTools.html
and run this to refresh every so often remotely listing
the processes on that user's machine
For example, something like
pslist -s 3600 -r 300 \\usermachinename > c:\temp\pslist-out.txt
would record every 5 minutes for an hour into the txt file
when run with credentials that are admin on that user's machine

 

[Guest]

Ok,

So I completed per your suggestions. No applications running, workstation
locked. The logon failures decreased signigicantly but are still there. The
pattern is now 2 attempts every 90-110 minutes. I ran the script and even got
it to run once within the same minute that the logon failure occured. I don't
know that I see anything odd in the process list. Have to say that I don't
know exactly what I am looking for but in this particular instance the CPU
usage is 100% to system idle process.

Any further suggestions?

 

[Roger Abell [MVP]]

Well, now down at once each 90 +/- minutes is not unusual.
The periodic application of group policy for example checks
to see if there have been policy changes on exactly that schedule.
You will probably need to wait for this to recur, talk with the
person about what is left with a window (process, drive, prt, etc)
during the log off and take it up then.

 

[Guest]

Hi,
I just noticed a similar problem, though I have no idea where to look for
the details on what the source of this is. I see the failed logins listed in
the ISA Security Report. Where do I find the details/IP address of the source
of these failed logins?

BTW, we have SBS 2000 if that makes a difference.


Thanks,
James

 

[Roger Abell [MVP]]

If you are seeing this in the ISA logs then, since ISA rather than Windows
is intercepting the attempt, you probably should post to an ISA newsgroup
where someone may give you some ISA specific ideas on what to do to
collect more info.
In general, Windows failed event logging for Windows 2000 is not of
much use in determining the origin of an attempt unless you happen to
recognize the Netbios names for the origin that do get recorded in the
security log failure events.

 

[Guest]

I found matching entries in the Security event log. Some look like they are
coming from the server itself, and some from a workstation, but only when a
specific workstation is on. I may have to try some 'workstation isolation' to
determine if one is really trying to login via another.

BTW, I posted my question to the ISA newsgroup too.


Thanks,
James

 

[Roger Abell [MVP]]

"workstation isolation" sounds potentially productive.
Make sure that you scan the involved machines with multiple
malware detectors.

 

[Guest]

After playing “workstation roulette†it appears I have multiple problems: a
VPN user’s home computer working its way through our user names, a few repeat
IP addresses trying their hand at logging in as ‘administrator’, and random
“drive by†attacks on ports 21 & 25.

I’ll be exorcising the demons from the VPN user’s home computer myself and
I’ve redirected the incoming activity on ports 21 & 25 to a nonexistent IP
address on our network. I’m also documenting the ‘repeat offenders’ in case
we choose to move forward with blocking them at our ISP or taking legal
action.

Thanks for your help,
James