Tracking down source of Event ID: 4625 on Windows 2008R2 server

Hello experts,
I have several entries in my Security logs of a hacking attempt. Initially I thought it may be an owa brute force attack. There is nothing in the IIS logs that correlate to this timestamp, and the Loginprocess is NtLmSsp rather than Advapi. Any advice on how to track the source of this hack attempt would be greatly appreciated.  Attached is the logged event.


Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          7/10/2014 3:00:35 PM
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      EXCH2.foo.com
Description:
An account failed to log on.

Subject:
                Security ID:                         NULL SID
                Account Name:                 -
                Account Domain:                             -
                Logon ID:                             0x0

Logon Type:                                       3

Account For Which Logon Failed:
                Security ID:                         NULL SID
                Account Name:                 !
                Account Domain:                             #$%^@foo.com

Failure Information:
                Failure Reason:                 Unknown user name or bad password.
                Status:                                  0xc000006d
                Sub Status:                         0xc0000064

Process Information:
                Caller Process ID:             0x0
                Caller Process Name:     -

Network Information:
                Workstation Name:        ASMIRCRACKER1
                Source Network Address:            -
                Source Port:                       -

Detailed Authentication Information:
                Logon Process:                  NtLmSsp
                Authentication Package:               NTLM
                Transited Services:          -
                Package Name (NTLM only):       -
                Key Length:                        0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
                - Transited services indicate which intermediate services have participated in this logon request.
                - Package name indicates which sub-protocol was used among the NTLM protocols.
                - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4625</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2014-07-10T22:00:35.823496200Z" />
    <EventRecordID>57526864</EventRecordID>
    <Correlation />
    <Execution ProcessID="552" ThreadID="620" />
    <Channel>Security</Channel>
    <Computer>EXCH2.foo.com</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-0-0</Data>
    <Data Name="SubjectUserName">-</Data>
    <Data Name="SubjectDomainName">-</Data>
    <Data Name="SubjectLogonId">0x0</Data>
    <Data Name="TargetUserSid">S-1-0-0</Data>
    <Data Name="TargetUserName">!</Data>
    <Data Name="TargetDomainName">#$%^@foo.com</Data>
    <Data Name="Status">0xc000006d</Data>
    <Data Name="FailureReason">%%2313</Data>
    <Data Name="SubStatus">0xc0000064</Data>
    <Data Name="LogonType">3</Data>
    <Data Name="LogonProcessName">NtLmSsp </Data>
    <Data Name="AuthenticationPackageName">NTLM</Data>
    <Data Name="WorkstationName">ASMIRCRACKER1</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">-</Data>
    <Data Name="KeyLength">0</Data>
    <Data Name="ProcessId">0x0</Data>
    <Data Name="ProcessName">-</Data>
    <Data Name="IpAddress">-</Data>
    <Data Name="IpPort">-</Data>
  </EventData>
</Event>
sreynolds27Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

joharderCommented:
Looks like that's a known MS issue with a hotfix:  http://support.microsoft.com/kb/2157973.
0
sreynolds27Author Commented:
Doubtful as we're not using smart cards, different login process too among other things. Thanks for your suggestion though.
0
Leon FesterSenior Solutions ArchitectCommented:
Here's the important parts of that message:
Account For Which Logon Failed:
                 Security ID:                         NULL SID
                 Account Name:                 !
                 Account Domain:                             #$%^@foo.com

 Failure Information:
                 Failure Reason:                 Unknown user name or bad password.
                 Status:                                  0xc000006d
                 Sub Status:                         0xc0000064

 Process Information:
                 Caller Process ID:             0x0
                 Caller Process Name:     -

 Network Information:
                 Workstation Name:        ASMIRCRACKER1
                 Source Network Address:            -
                Source Port:      

Is this valid information or did you change it for posting purposes:
                 Account Name:                 !
                 Account Domain:                             #$%^@foo.com

If it is valid domain and user accounts that you know must be on your network then most likely there is a password saved on  the PC named: ASMIRCRACKER1

Logon to the computer and check the event logs and any saved passwords
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

sreynolds27Author Commented:
Only the domain suffix has been changed in the post.  The workstation name does not exist on our network,  well at least it shouldn't! Which is exactly why I'm trying to track down the source address.
Anyone?
0
Leon FesterSenior Solutions ArchitectCommented:
The workstation name does not exist on our network,  well at least it shouldn't!
Can you discount the fact that somebody may have brought a 'rouge' device onto your network? i.e. a personal laptop or other device that was connected to your network? What about virtual machines? Somebody could have created a local VM that is failing.

Your question heading is then a little misleading. The way it reads, you're looking for the application that is  trying to authenticate on the Exchange Server.

While what you're looking for is the actual computer?

If it's a local network 'attack' then I would suggest running wireshark or netmon on your LAN so that you can capture more data about this workstation. A full network scan might also work, but then you'd need that workstation to be on.

If you think it a direct OWA connection then you should see something on your firewall logs. Did you check those logs?

The bottom line that this event is only telling you that an authentication request failed due to bad username/password. It is not an indication that your system is under attack.

If you cannot find that workstation then there is nothing else from a LAN management perspective that you can do to stop this message from being logged, except to disable auditing....which I would never recommend on a production system
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sreynolds27Author Commented:
Hi Leon
I'm leaning towards the rogue device on the network, as I haven't found anything in the firewalls logs with a time stamp that correlates to the security logs. Whatever the device was, there has been no more occurences since my initial post.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server Apps

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.