|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Account Logon Time RestrictionWe 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. "LDD15" <LD***@discussions.microsoft.com> wrote in message I am sure you do understand this, but the use of "user" with two differentnews:152FC6DD-AB24-41F5-B791-4A6A273C50A8@microsoft.com... > 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 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 I do not understand. Username and password were correct ? but the login> 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 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 thingWhile 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). 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? Show quoteHide quote "Roger Abell [MVP]" wrote: > "LDD15" <LD***@discussions.microsoft.com> wrote in message > news:152FC6DD-AB24-41F5-B791-4A6A273C50A8@microsoft.com... > > 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). > > > > > > 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. Show quoteHide quote "LDD15" <LD***@discussions.microsoft.com> wrote in message news:4C59D092-56F5-4618-93DE-C59466B954BE@microsoft.com... > 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]" wrote: > >> "LDD15" <LD***@discussions.microsoft.com> wrote in message >> news:152FC6DD-AB24-41F5-B791-4A6A273C50A8@microsoft.com... >> > 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). >> >> >> >> >> >> 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? Show quoteHide quote "Roger Abell [MVP]" wrote: > 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. > > "LDD15" <LD***@discussions.microsoft.com> wrote in message > news:4C59D092-56F5-4618-93DE-C59466B954BE@microsoft.com... > > 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]" wrote: > > > >> "LDD15" <LD***@discussions.microsoft.com> wrote in message > >> news:152FC6DD-AB24-41F5-B791-4A6A273C50A8@microsoft.com... > >> > 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). > >> > >> > >> > >> > >> > >> > > > 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. Show quoteHide quote "LDD15" <LD***@discussions.microsoft.com> wrote in message news:BE5C1D8D-9023-462C-ABFA-FAEFE9687E3B@microsoft.com... > 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]" wrote: > >> 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. >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message >> news:4C59D092-56F5-4618-93DE-C59466B954BE@microsoft.com... >> > 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]" wrote: >> > >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message >> >> news:152FC6DD-AB24-41F5-B791-4A6A273C50A8@microsoft.com... >> >> > 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). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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. Show quoteHide quote "Roger Abell [MVP]" wrote: > 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. > > > "LDD15" <LD***@discussions.microsoft.com> wrote in message > news:BE5C1D8D-9023-462C-ABFA-FAEFE9687E3B@microsoft.com... > > 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]" wrote: > > > >> 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. > >> > >> "LDD15" <LD***@discussions.microsoft.com> wrote in message > >> news:4C59D092-56F5-4618-93DE-C59466B954BE@microsoft.com... > >> > 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]" wrote: > >> > > >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message > >> >> news:152FC6DD-AB24-41F5-B791-4A6A273C50A8@microsoft.com... > >> >> > 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). > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> > >> > >> > > > 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 Show quoteHide quote "LDD15" <LD***@discussions.microsoft.com> wrote in message news:BFCF6039-BFA4-4EEC-A1A6-26CA419956C1@microsoft.com... >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]" wrote: > >> 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. >> >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message >> news:BE5C1D8D-9023-462C-ABFA-FAEFE9687E3B@microsoft.com... >> > 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]" wrote: >> > >> >> 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. >> >> >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message >> >> news:4C59D092-56F5-4618-93DE-C59466B954BE@microsoft.com... >> >> > 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]" wrote: >> >> > >> >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message >> >> >> news:152FC6DD-AB24-41F5-B791-4A6A273C50A8@microsoft.com... >> >> >> > 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). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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? Show quoteHide quote "Roger Abell [MVP]" wrote: > 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 > > > "LDD15" <LD***@discussions.microsoft.com> wrote in message > news:BFCF6039-BFA4-4EEC-A1A6-26CA419956C1@microsoft.com... > >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]" wrote: > > > >> 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. > >> > >> > >> "LDD15" <LD***@discussions.microsoft.com> wrote in message > >> news:BE5C1D8D-9023-462C-ABFA-FAEFE9687E3B@microsoft.com... > >> > 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]" wrote: > >> > > >> >> 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. > >> >> > >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message > >> >> news:4C59D092-56F5-4618-93DE-C59466B954BE@microsoft.com... > >> >> > 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]" wrote: > >> >> > > >> >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message > >> >> >> news:152FC6DD-AB24-41F5-B791-4A6A273C50A8@microsoft.com... > >> >> >> > 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). > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> > >> > >> > > > 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. Show quoteHide quote "LDD15" <LD***@discussions.microsoft.com> wrote in message news:6150C396-4AF2-4F7D-A41E-024F47DA3ED2@microsoft.com... > 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]" wrote: > >> 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 >> >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message >> news:BFCF6039-BFA4-4EEC-A1A6-26CA419956C1@microsoft.com... >> >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]" wrote: >> > >> >> 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. >> >> >> >> >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message >> >> news:BE5C1D8D-9023-462C-ABFA-FAEFE9687E3B@microsoft.com... >> >> > 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]" wrote: >> >> > >> >> >> 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. >> >> >> >> >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message >> >> >> news:4C59D092-56F5-4618-93DE-C59466B954BE@microsoft.com... >> >> >> > 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]" wrote: >> >> >> > >> >> >> >> "LDD15" <LD***@discussions.microsoft.com> wrote in message >> >> >> >> news:152FC6DD-AB24-41F5-B791-4A6A273C50A8@microsoft.com... >> >> >> >> > 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). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 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 Show quoteHide quote "LDD15" wrote: > 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. 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. Show quoteHide quote "James B" <Jam***@discussions.microsoft.com> wrote in message news:D85BE182-81B4-4EE4-A4BE-207F3F7DEFEA@microsoft.com... > 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 > > > "LDD15" wrote: > >> 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. 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 Show quoteHide quote "Roger Abell [MVP]" wrote: > 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. > > "James B" <Jam***@discussions.microsoft.com> wrote in message > news:D85BE182-81B4-4EE4-A4BE-207F3F7DEFEA@microsoft.com... > > 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 > > > > > > "LDD15" wrote: > > > >> 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. > > > "workstation isolation" sounds potentially productive.
Make sure that you scan the involved machines with multiple malware detectors. Show quoteHide quote "James B" <Jam***@discussions.microsoft.com> wrote in message news:B0AFA34E-BEC8-40F6-925E-34877C1A6A36@microsoft.com... >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]" wrote: > >> 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. >> >> "James B" <Jam***@discussions.microsoft.com> wrote in message >> news:D85BE182-81B4-4EE4-A4BE-207F3F7DEFEA@microsoft.com... >> > 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 >> > >> > >> > "LDD15" wrote: >> > >> >> 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. >> >> >> 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 Show quoteHide quote "Roger Abell [MVP]" wrote: > "workstation isolation" sounds potentially productive. > Make sure that you scan the involved machines with multiple > malware detectors. > > > "James B" <Jam***@discussions.microsoft.com> wrote in message > news:B0AFA34E-BEC8-40F6-925E-34877C1A6A36@microsoft.com... > >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]" wrote: > > > >> 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. > >> > >> "James B" <Jam***@discussions.microsoft.com> wrote in message > >> news:D85BE182-81B4-4EE4-A4BE-207F3F7DEFEA@microsoft.com... > >> > 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 > >> > > >> > > >> > "LDD15" wrote: > >> > > >> >> 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. > >> > >> > >> > > > 
Other interesting topics
"Force shutdown from a remote system"
Event 26. Your computer may be infected. Changing process priorities of normal users security and pipes explained Account membership changed/dissapeared off welcome screen User Restictions on a Standalone Machine Autoenrollment of Certificate ISA 2000 Recover files after using Robocopy /mir command ie |
|||||||||||||||||||||||
