Server changing DNS settings spontaneously?

[sonofsanta]

By the gods, I've had a fun morning. Had someone from the police hi-tech crime unit in to get data on one of our students for an investigation (don't ask, I don't know), so of course, this being a day when i'm relying on everything working, Exchange was completely buggered up this morning when I came in - bleating about not being able to find a domain controller, even though all 3 were up and fine.

 

Lots of panicky investigation turned up that the DNS on the NIC had reset to 8.8.8.8 // 8.8.8.4, hence it being unable to find anything on the domain. Switching that back to the correct values corrected the errors and got everything running again.

 

However: wtf? How can a NIC spontaneously change its DNS settings? It's got me real scared now, because as far as I can tell, that shouldn't just happen. It seemed to switch about 18:50 last night, when there were a couple of webmail users on (me and one of the reception staff) and nothing else. Win2003R2 x64, Exchange 2007, on a three year old HP ProLiant of some description - the NIC is a HP NC373i Multifunction GbE Adapter, anyway.

 

Anyone got any clues? I hate to be paranoid, but hacking is not a million miles away from my mind right now, even though the logs show nothing other than

 

Event Type: Warning

Event Source: DnsApi

Event Category: None

Event ID: 11165

Date: 28/07/2011

Time: 18:50:35

User: N/A

Computer: [sERVER NAME]

Description:

The system failed to register host (A) resource records (RRs) for network adapter

with settings:

 

Adapter Name : {7A316C27-99FF-4CD1-9907-48D588517DF0}

Host Name : EM0

Primary Domain Suffix : [domain.local]

DNS server list :

8.8.8.8, 8.8.4.4

Sent update to server : >

IP Address(es) :

[server Static IP]

 

The reason the system could not register these RRs was because the DNS server contacted refused the update request. The reasons for this might be (a) you are not allowed to update the specified DNS domain name, or (b) because the DNS server authoritative for this name does not support the DNS dynamic update protocol.

 

To register the DNS host (A) resource records using the specific DNS domain name and IP addresses for this adapter, contact your DNS server or network systems administrator.

 

For more information, see Help and Support Center at Events and Errors Message Center: Basic Search.

Data:

0000: 2a 23 00 00 *#..

(details redacted)

[TheMan100]

It says it "refused the update request", so perhaps Windows reset the DNS back to the 8.8.8.8/8.8.8.4 addresses as it didn't have any DNS to resolve to at all. That's just my little hypotheses.

[sukh]

1. These IP are registered for Google. Do you have any association with Google for email or DNS?

2. Or ever had?

3.Have you used these IP's before?

[sonofsanta]

It says it "refused the update request", so perhaps Windows reset the DNS back to the 8.8.8.8/8.8.8.4 addresses as it didn't have any DNS to resolve to at all. That's just my little hypotheses.

 

I think the "refused update" portion is saying that it tried to post a DNS update to the servers at those addresses, and was refused because it doesn't have authority to do so. Presumably the DNS had already gotten itself set to .8/.4 by the time that event flagged up, and that event is the first I can see of any problem (and I was logged into my webmail from home less than an hour before, and it was fine then).

[sonofsanta]

1. These IP are registered for Google. Do you have any association with Google for email or DNS?

2. Or ever had?

3.Have you used these IP's before?

 

I'd seen the Google association when doing nslookups to test the GC lookup. However, to answer your questions: no, no and no, not in the last 20 months that I've been here. Possibly they were used once, long ago in the past, before my time, but I'd have no idea on that.

[sukh]

1. NSLookups for GC? So if you do a nslookup now, resolves ot your internal DNS?

[m25man]

Malware commonly uses the google DNS servers when running a scripted attack on a users IP stack.

 

Your NIC settings did not spontaneously change them selves, there were done by someone at your console or remotely elsewhere on your LAN with admin rights!

 

Check your group memberships who else has admin rights?

 

Change the passwords for all of these accounts immediately.

Look out for bogus admin accounts - DNS Admin - DHCP Admin etc etc

These are commonly planted so as not to attract your attention to them, I have found dozens of these backdoor accounts strewn around sites before.

 

A compromised account can then be exploited by a worm to take down the entire site....

 

You should at least be running an MBSA check on your servers ASAP.

[sonofsanta]

More worryingly now, at 16:09 yesterday there was a successful login attempt through the default gateway - which should never happen, because any time any one of us wants to work on something (and believe me, I was in no condition to do so yesterday) we remote into our PCs and then mstsc into the servers. The server then got restarted with event

Event Type: Information

Event Source: USER32

Event Category: None

Event ID: 1074

Date: 31/07/2011

Time: 16:10:46

User: EM0\Administrator

Computer: EM0

Description:

The process Explorer.EXE has initiated the restart of computer EM0 on behalf of user EM0\Administrator for the following reason: Security issue

Reason Code: 0x84050013

Shutdown Type: restart

Comment:

 

For more information, see Help and Support Center at Events and Errors Message Center: Basic Search.

Data:

0000: 13 00 05 84 ...„

 

Not happy, very worried, very annoyed now.

[sukh]

at least you know who now, passwords arent shared are they

[sonofsanta]

Well shared between us techies, but no-one else knows it. Or, I should say, no-one should know it, as far as I'm aware.

 

Running scans and changing passwords everywhere now anyway. Why do these things always happen just as you're in the process of replacing kit, but aren't far enough along to just turn off the broken bits...

 

EDIT: is it worth changing the IUSER_ and IWAM_ passwords? If so, do I need to provide updated details anywhere else?

[m25man]

I would definately be looking at Advanced Audit Settings

Advanced Security Audit Policy Settings

 

This should help you get things under a magnifying glass...

 

I meant to add, your restart yesterday was made under the local security context of EM0\Administrator so have you included a local Admin password change in your security sweep?

 

These are the most commonly abused accounts as so many are left blank/password/pa55word/letmein etc busted by TSGrinder in a few seconds..

Edited August 2, 2011 by m25man

[sonofsanta]

I would definately be looking at Advanced Audit Settings

Advanced Security Audit Policy Settings

 

This should help you get things under a magnifying glass...

 

I meant to add, your restart yesterday was made under the local security context of EM0\Administrator so have you included a local Admin password change in your security sweep?

 

These are the most commonly abused accounts as so many are left blank/password/pa55word/letmein etc busted by TSGrinder in a few seconds..

 

Server is 2k3 R2 so that doesn't apply to it, sadly. I have run all the updates I can, run the MS Malicious Software Removal Tool and MalwareBytes (both of which came up clean), changed the domain admin password (was overdue anyway) and yes, changed the local password on all member servers to a string of garbage stored in KeePass, so hopefully that's closed off whatever hole was open. I don't know what they were set to before (set up before my time, never used them, never thought to check ) but it's certainly given me a suitable level of paranoia before I set up the new server system.

[m25man]

Sorry, this is the 2003 link

HOW TO&#58 Audit Active Directory Objects in Windows Server 2003

 

Sounds like you have a good handle on it now anyway...