Web U-M ITSS only
ITSS: Information Technology Security Services - Keeping IT Safe at U-M

Password Attack - 5/01/08

Preliminary investigation reveals that passwords are being captured by a piece of malware that replaces the Windows logon UI. Captured passwords are stored in a clear-text file for later retrieval via FTP. As part of the containment effort, we’re sending this message to explain how you can identify infected machines and to provide techniques for mitigating the threat.

PLATFORMS AFFECTED:

Windows NT-based systems from Window NT 3.51 through Windows Server 2003, but not including Windows Vista or Windows Server 2008. McAfee Antivirus will NOT prevent this attack.

TECHNICAL DESCRIPTION:

Windows uses a Graphical Identification and Authentication module, or GINA, to accept a user's credentials and authenticate that user against a given domain. The GINA is a dynamic link library (DLL) that is called by the winlogon process, and is what you see when you press CTRL+ALT+DELETE to logon. Windows allows the default GINA (MSGINA.DLL) to be replaced by a custom GINA to support alternative authentication methods such as smart cards, Netware logon etc.

This attack replaces the default GINA with a "backdoor" GINA that accepts the username, domain name and password, and logs them to a file for later retrieval. In all cases observed thus far, the backdoor GINA is called MSCAD.DLL which is specified via the following registry value: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL

We do not believe Windows Vista (or later) machines are affected because the GINA model has been replaced in Windows Vista.

Consistently accompanying the backdoor GINA is the ServU FTP daemon disguised using the names of several different executables.  We believe FTP is how the attacker collects the captured passwords.

SOURCE OF ATTACK:

Thus far, the following IP addresses have been associated with the source of this attack. ITSS is working with the appropriate authorities and monitoring appropriate traffic as the incident evolves:

  • 82.248.112.55/lns-bzn-23-82-248-112-55.adsl.proxad.net
  • 35.10.78.33/user-bf3dea.user.msu.edu
  • 128.95.172.127/campbell-pc.chem.washington.edu

SCOPE, PROPAGATION AND TIMELINE: 

We are confident that the attack began to spread when a domain admin account was used to log on to an infected machine on April 18, 2008. That domain admin account was part of the LSA domain within the U-M Windows Forest. Once the domain admin account was compromised, it was used on April 22 to infect other machines joined to the LS&A domain.

Two important takeaways:

It is feasible for the attack to "jump" the LSA domain and infect other domains in the U-M Windows Forest. One reason for this is that the majority of accounts for LS&A staff are actually in the UMROOT domain. Thus, even though the infected machine is in the LS&A domain, the compromised account is in the UMROOT domain.

Firewall rules that restrict access from the Internet can be ineffective. Once a machine is infected behind your firewall, it can spread without further remote access.

IDENTIFYING COMPROMISED MACHINES:

The following "signatures" may be used to identify machines that have likely been infected:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL = Mscad.dll (REG_SZ)
  • Mscad.dll in %windir%\system32 or anywhere else on the filesystem
    inst.dat or inst.bmp, which is a file in the root directory containing the clear-text passwords
  • The ServU FTP daemon, disguised as anyone of the following:
    • %windir%\svchost.exe (the legitimate svchost.exe file is in %windir%\system32)
    • %windir%\winlogon.exe (the legitimate winlogon.exe file is in %windir%\system32)
    • %windir%\java\java.exe
    • %windir%\tapechgr.exe, which is configuration information for the ServU FTP daemon
  • An unauthorized account in the local administrators group. We have seen it called Admin and Gandalf and Gandolf.
  • The Microsoft Telnet Service enabled (and listening on port 23)

Note: It is best to perform such queries remotely if possible in order to bypass a local (GINA-based) logon.

Another sign that a machine has been compromised is if the Windows logon UI does not pop up when you press CTRL+ALT+DEL. Instead, the screen simply flickers.

IF YOU FIND AN INFECTED MACHINE:

  • Contact security@umich.edu.
  • Disconnect the machine from the network.
  • Ask any user who logged on to that machine change their password.
  • Rebuild the machine when no further investigation is warranted.

MITIGATING TECHNIQUES:

Use software restriction policies and restricted groups to contain the threat posed by an infected machine

Use the following security best practices to prevent or limit initial infections:

  • Log on as an administrator only when necessary.
  • Restrict remote network and terminal service logon to authorized personnel and, if possible, from authorized locations.

Auditing Logon Events, Account Management Events, and modifications to the Winlogon registry key referenced above (requires object access auditing be enabled) will minimally aid with forensic analysis and, depending on your monitoring capabilities, may help you detect an attack.

 

Thank you for your immediate attention to this matter. Please contact itss@umich.edu with any questions or concerns.

IT Security Services