Audit Account Logon Events, Client IP address incorrect?

[Guest]

Hi,

We recently set up an audit policy to audit failed account logon events for
our domain controllers. If I look at the logs, I can see Event ID 675 for
the failed logons. However, when I look at the detail, the Client IP address
does not have the address of the client, but instead the IP of one of the
domain controllers (and often not even the closest DC). For example, I
deliberately entered a bad password to log onto a client at IP address
192.168.22.126. The Security log on the local DC showed Event ID 675 for the
userID I used, but the Client IP address shows as 192.168.7.17 which is a DC
at a remote location.

Can anyone help me understand why this is happening?

Thanks so much!

 

[Herb Martin]

Hi,

We recently set up an audit policy to audit failed account logon events for
our domain controllers. If I look at the logs, I can see Event ID 675 for
the failed logons. However, when I look at the detail, the Client IP address
does not have the address of the client, but instead the IP of one of the
domain controllers (and often not even the closest DC). For example, I
deliberately entered a bad password to log onto a client at IP address
192.168.22.126. The Security log on the local DC showed Event ID 675 for the
userID I used, but the Client IP address shows as 192.168.7.17 which is a DC
at a remote location.

Can anyone help me understand why this is happening?

Probably because historically logon might happen over
any supported network protocol so these events never
included the IP address (it might not even have been IP.)

It is sort of silly these days, but it's one of those things
(I believe) the developers know needs improving.

When I have a bad logon attempt, I would much prefer
to know the IP address of the offender -- if he's on my
network I can find him with that but if he is NOT on
my network I have no chance of finding him by NetBIOS
name or some other irrelevant information.

 

[Guest]

Thanks Herb! Now I at least have an explanation for the "powers that be"
when they look at the logs.

Lori

 

[Herb Martin]

Thanks Herb! Now I at least have an explanation for the "powers that be"
when they look at the logs.

The next step is to run an IDS (Intrusion Detection
System) but that is a LOT of work UNLESS you will
actively read and use the logs.

I hope someone will pipe in here and suggest a way
to match Snort (a free IDS) logs with Windows logs.

By now, I really should have written a Perl program
to do that (probably something simple based on time
stamps would get me close.)

 

[ptwilliams]

By now, I really should have written a Perl program to do that (probably

something simple based on time

stamps would get me close.)

Well, don't just talk about it!!! Get too it!

And post it free for all of us when you're done ;-)


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net

Thanks Herb! Now I at least have an explanation for the "powers that be"
when they look at the logs.

The next step is to run an IDS (Intrusion Detection
System) but that is a LOT of work UNLESS you will
actively read and use the logs.

I hope someone will pipe in here and suggest a way
to match Snort (a free IDS) logs with Windows logs.

By now, I really should have written a Perl program
to do that (probably something simple based on time
stamps would get me close.)

 

[Herb Martin]

stamps would get me close.)

Well, don't just talk about it!!! Get too it!

And post it free for all of us when you're done ;-)

Ok, let's try a simple design and IF I have some
time I will hook it up....

What sort of messages do we need to capture in
Snort? (You don't have to answer but pointing me
to the current docs for Kerberos and NTLM authentication
and secure channel packet types would help...)

1) Find Account Logon or Logon events in event log
( I can do that.)

2) Find messages of the relevant types in Snort log

3) Filter Snort messages to plus or minus N seconds
or milliseconds of each Audit event.

Can that (little bit) be useful?

Do you run Snort and Perl? Would you run them if
this worked?

Comments from PT or ANYONE welcome.

Alternative:
4) Find something in Audit that can be directly matched
to the Snort log....

 

[ptwilliams]

Sorry for the delay Herb - I lost the post! Until I read this post I didn't
know what Snort was -and still only have a vague idea! I figured that a
veteran such as yourself, with many programming languages under his belt
could whip up a nice, free tool for the community -just like Joe's oldcmp or
something <g>.

I'd be sure to give it a go; although most of out clients are quite big and
we have certified network detectives, etc. so wouldn't utilise it as much as
some of the people on here with smaller environments...

Do you run Snort and Perl? Would you run them if this worked?

No. I just started playing with VBScript and was considering Perl sometime
next year. Is it worth it?


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net

stamps would get me close.)

Well, don't just talk about it!!! Get too it!

And post it free for all of us when you're done ;-)

Ok, let's try a simple design and IF I have some
time I will hook it up....

What sort of messages do we need to capture in
Snort? (You don't have to answer but pointing me
to the current docs for Kerberos and NTLM authentication
and secure channel packet types would help...)

1) Find Account Logon or Logon events in event log
( I can do that.)

2) Find messages of the relevant types in Snort log

3) Filter Snort messages to plus or minus N seconds
or milliseconds of each Audit event.

Can that (little bit) be useful?

Do you run Snort and Perl? Would you run them if
this worked?

Comments from PT or ANYONE welcome.

Alternative:
4) Find something in Audit that can be directly matched
to the Snort log....

 

[Herb Martin]

Sorry for the delay Herb - I lost the post! Until I read this post I didn't
know what Snort was -and still only have a vague idea! I figured that a
veteran such as yourself, with many programming languages under his belt
could whip up a nice, free tool for the community -just like Joe's oldcmp or
something <g>.

The hard part is not the code but figuring out what
to capture and compare.

I'd be sure to give it a go; although most of out clients are quite big and
we have certified network detectives, etc. so wouldn't utilise it as much as
some of the people on here with smaller environments...

Ok, how do they find the address of a Logon failure?

No. I just started playing with VBScript and was considering Perl sometime
next year. Is it worth it?

Absolutely and you don't have to be much if any of
a Perl programmer to benefit.

Tools like SpamAssassin are freely downloadable and
written in Perl.

Many of the librarys make doing things like programmatically
searching DNS or comparing RBL DNS results the matter of
only a few lines in Perl.

Perl is generallly a strong language than most but benefits
as much from having fantastic community support with
tons (literally) of libraries and free (auto-installed) downloads,
as well as significant cross platform capability.

Most of the time my Perl can run on Unix or Macs (with
some very small deference to system differences, but the
libraries are generally written to hide most of that.)

I use (real) VB for quick GUI programs but I write perl
in the same way I write CMD files, as soon as I need
them and almost as quick as I can think of it (for little
stuff).

I almost never write VBS since Perl is so much easier
after you get past the initial shock and awe.

This problem of comparing the logs is NOT a hard one
in Perl, it is just complicated by figuring out what to
compare.