Checking our Bigbrother monitor we noticed some Security Event Log entries that seemed to indicate someone was knocking on the door, usually not very strange.. The strange part came when the same Workstation Name (Name = "lQPxf2ISQgEV1bGK") was presented from several different IP addresses.
Event Log Entry Example from 2003 (IP Changed to protect the ..)
security: failure - 2009/04/16 10:32:10 - Security (529) - NT AUTHORITY_SYSTEM
"Logon Failure: Reason: Unknown user name or bad password User Name: Domain: WORKGROUP
Logon Type: 3 Logon Process: NtLmSsp Authentication Package: NTLM Workstation
Name: lQPxf2ISQgEV1bGK Caller User Name: - Caller Domain: - Caller Logon ID:
- Caller Process ID: - Transited Services: - Source Network Address: 192.168.163.101
Source Port: 0"
security: failure - 2009/04/16 10:31:44 - Microsoft-Windows-Security-Auditing (4625) - n/a
"The description for Event ID ( 4625 ) in Source ( Microsoft-Windows-Security-Auditing
) cannot be found. The local computer may not have the necessary registry
information or message DLL files to display messages from a remote computer. You
may be able to use the /AUXSOURCE= flag to retrieve this description_ see Help
and Support for details. The following information is part of the event: S-1-0-0_
-_ -_ 0x0_ S-1-0-0_ _ WORKGROUP_ 0xc000006d_ %%2313_ 0xc0000064_ 3_ NtLmSsp
_ NTLM_ lQPxf2ISQgEV1bGK_ -_ -_ 0_ 0x0_ -_ 192.168.163.101_ 1413."
Repeated over a few times on but with different Source Address.
Further searching on google with the strange Workstation name brings up other hits with the same name... none of which answer my question as it seems noone has yet tied the name to different IP addresses - they were visited from only the one source perhaps. 1st noticed this strange name at the beginning of March - but thought nothing of it as it all came from the same source address - and assumed it really was the workstation name. It wasn't until recently that it appeared from several IPs at the same time. This Event Log Entry appears on multiple (10-15) servers.
Hopefully an astute reader has already investigated or can share theories as to the source. Thanks Julian for writing in!
Update1: Shawn writes:
Here is a copy of one of the event log entries that we saw during an incident in December involving a worm that spread via MS08-067 (not conficker). These entries were found in the event log, and it I reasoned that it was a symptom of the server service being "crashed" by the exploit. The malware called itself vmwareservice.exe and installed as a service, in c:windowssystem.
Update2: Ed writes:
Regarding the recent diary post about the strange log entries, I can describe this in exacting detail. Just last week a customer was hit with new malware, which was a repackage of many different viruses, trojans, and bots. One of the spreading mechanism used the same exploit as Conficker, and the strange client hostname you mention is the same one we see in our forensic examples.
The spreading mechanism does not assume vulnerability to MS08-067, first attempting some brute force attacks before moving on to exploiting the vulnerability. It then dumps malware onto the target system's disk, most notably a file called svhost.exe which then executes as NETWORK SERVICE (as well as each user who logs in, thanks to a registry autorun). This executable then begins scanning the local subnet as well as network addresses close to the local network's value on port 445, and uses the same exploit/infection method.
In all cases we see the same garbage host ID in the event log. Some of the relevant filenames in the malwarwe we have seen are:
svhost.exe (MS08-067 exploiter and malware dropper)
[x]3.scr (same md5 hash as svhost.exe)
<numbers 1 through ~83>.scr (same md5 hash as svhost.exe)
stnetlib.dll (a downloader)
Things to look for in logs are the 445 connections bouncing off your internal Firewall interfaces, connection attempts on port 976 outbound (IRC) and also connection attempts outbound on port 80 (I can't remember the IP address right now). We're not sure at the moment which malware came first - it's the chicken and egg syndrome - but forensics continues. McAfee and Symantec both have signatures for most (if not all) of these files now.
Adrien de Beaupré
I will be teaching next: Enterprise and Cloud | Threat and Vulnerability Assessment - SANS Secure Japan 2022