  Attacks Against GRC.COM by Steve Gibson, Gibson Research Corporation Page last modified: Jun 28, 2004 at 12:04 |
old hacker is required to knock any user, site, or server right off the Internet. I believe you will be as fascinated and concerned as I am by the findings of my post-attack forensic analysis, and the results of my subsequent infiltration into the networks and technologies being used by some of the Internet's most active hackers.
When
you are through with this page, you may also be interested in seeing
the report of the January 11th, 2002 "DRDoS" attack. The report
contains very thorough explanations of bandwidth floods and traditional
denial of service attacks:
What Happened? |
Stemming the Flood with Our ISP Within a minute of the start of the first attack it was clear that we were experiencing a "packet flooding" attack of some sort. A quick query of our Cisco router showed that both of our two T1 trunk interfaces to the Internet were receiving some sort of traffic at their maximum 1.54 megabit rate, while our outbound traffic had fallen to nearly zero, presumably because valid inbound traffic was no longer able to reach our server. We found ourselves in the situation that coined the term: Our site's users were being denied our services.
the attack and I wanted to get us back online. I immediately reconfigured our network to capture the packet traffic in real time and began logging the attack. Dipping a thimble into the flood, I analyzed a tiny sample and saw that huge UDP packets — aimed at the bogus port "666" of grc.com — had been fragmented during their travel across the Internet, resulting in a blizzard of millions of 1500-byte IP packets. Mixed into this appeared to be ICMP debris from large-packet ping commands.
traffic and valid traffic was unable to compete with the torrent. At our end of our T1 trunks, our local router and firewall had no trouble analyzing and discarding the nonsense, so none of our machines were adversely affected. But it was clear that this attack was not attempting to upset our machines, it was a simple brute force flood, intended to consume all of the bandwidth of our connection to the Internet . . . and at that it was succeeding all too well. Gibson Research Corporation is connected to the Internet by a pair of T1 trunks. They provide a total of 3.08 megabits of bandwidth in each direction (1.54 megabits each), which is ample for our daily needs. |
| As
you can see from the schematic diagram above, the Verio (our ISP)
router that supplies our T1 trunks enjoys two massive 100 megabit
connections to the Internet. But from there all of the traffic bound
for us must be funnelled through our two T1 trunks. Therefore, in order
for the congestion of our T1's to be relieved of the malicious traffic,
the "bad packets" had to be filtered before they left Verio's router.
In this way, the packet flood would be stopped at a high-bandwidth
point — upstream of the T1 choke point — thus allowing the "good
packets" to slip past the bad packets and cross our T1's in peace.
It took us a while . . .
Verio router, shutting down all UDP and ICMP traffic ... and GRC.COM instantly popped back onto the Internet. That part was pretty cool. We were still very much under attack, but because the attack was prone to filtering (thank goodness) we were able to have Verio's router "weed out" the bad packets and return us to almost normal operation.
An Attack "Prone to Filtering" ?
any version of Windows 3.x/95/98/ME or NT to "spoof" its source IP or generate malicious TCP packets such as SYN or ACK floods.
As a result, Internet security experts know that non-spoofing Internet attacks are almost certainly being generated by Windows-based PC's. Forging the IP address of an attacking machine (spoofing) is such a trivial thing to do under any of the various UNIX-like operating systems, and it is so effective in hiding the attacking machines, that no hacker would pass up the opportunity if it were available. It is incredibly fortuitous for the Internet that the massive population of Windows-based machines has never enjoyed this complete "Unix Sockets" support which is so prone to abuse. But the very bad news is . . .
with the release of Windows 2000 and the pending release of Windows XP. For no good reason whatsoever, Microsoft has equipped Windows 2000 and XP with the ability FOR ANY APPLICATION to generate incredibly malicious Internet traffic, including spoofed source IP's and SYN-flooding full scale Denial of Service (DoS) attacks! (See my WinXP & DoS Page.) While I was conducting research into the hacker world following these DoS attacks, I encountered evidence — in attack-tool source code — that malicious hackers are already fully aware of the massive malicious power of the new versions of Windows and are waiting impatiently for the "home version" of Windows XP to arrive in the homes of millions of less clueful end users.
machines are mated to high-bandwidth Internet connections, we are going to experience an escalation of Internet terrorism the likes of which has never been seen before. If I fail in my mission to convince Microsoft to remove this from Windows XP, the historical problems with Internet attacks promise to pale in comparison to what will begin happening as Windows XP is deployed next year. Thanks to the fact that the fleet of attacking machines were Windows PC's, they were unable to send TCP SYN packets to our port 80 (which would have crippled us completely), and were only able to flood us with UDP and ICMP packets (which we could temporarily ignore). Working with our ISP we were able to filter our receipt of the malicious packets before they were able to reach our T1 trunks. We were able to continue offering our TCP-based services (Web/FTP/News) even while under continuing attack.
attacked by 474 Windows PC's. This was a classic "Distributed" Denial of Service (DDoS) attack generated by the coordinated efforts of many hundreds of individual PC's.
A determination of the network domains hosting the attacking machines revealed the following, hardly surprising, cast of Internet end user service providers: |
|
|
|
Domains hosting two or more security-compromised, attack Zombie, Windows PC's
|
(The balance of the 474 Windows PC's not represented above were scattered across a multitude of domains, one machine apiece.)
It probably comes as no surprise that the top two U.S. residential cable-modem Internet service providers — @Home and Road Runner — provide Internet connectivity to the host machines most often sought by malicious hackers for the installation of bandwidth flooding Zombie attack Trojans. While I was monitoring several online hacker hangouts (with the aid of custom spy-bots I created for the purpose — more on that below), I often overheard hackers referring to various lists of "cable Bots" and saying things like "Heh, but how many of his Bots are cable?" It is clear that the "cable Bot" — a remote control Zombie program installed on a high bandwidth, usually on, Windows machine — has become a highly sought-after resource among malicious "Zombie/Bot running" Internet hackers.
| |||||||||||||||||
|
the 13 year-old Internet terrorist. I immediately and politely replied to "Wicked" via the newsgroup. I invited him to write to me via eMail through any anonymous channel of his choosing. I wanted to understand what had precipitated these multiple attacks, and I wanted to see what I could do to get them to stop. "Wicked" soon wrote to me through an eMail account at YAHOO.COM:
My reply to this note from "Wicked" carefully explained that he really had me all wrong. I pointed to my "Acknowledgement of Debt to the World's Hackers" at the bottom of my "NanoProbe" page. I explained that while I did feel there was a distinction between an elite hacker and a script kiddie, I was someone who always took pains to be respectful of others' egos (when possible), and that I was unlikely — unless provoked — to casually refer to anyone using a derogatory term. I told him that while I was aware of a dispute that had erupted several weeks before in one of our newsgroups, and reportedly involved his friends "HeLLfiReZ" and "DrGreen", I had neither read nor participated in any of that conflict. "Wicked" replied that perhaps he had "misjudged me", since he was only going by word of mouth. He volunteered to speak with his friends and call off the attacks. He promised that there would be no further attacks from then on . . . after which he attacked us on the evening of May 16th, saying afterwards:
"i just ddosed you ..." Indeed. Fortunately, that was the first night of our new and (so far) impregnable router filters, so we felt nothing across our T1's while Verio's router counted and discarded nearly five hundred and thirty-nine million (538,916,268) malicious bandwidth-consuming attack packets. From my dialog with "Wicked", I saw that these repeated attacks were "fun" for him. He was like a child pulling the legs off a spider to see what it would do, watching it flail and attempt to get away from its tormentor. And, as we have seen, he experiences absolutely no remorse and has no regard for any damage being done as a consequence. He believes that he can not and will not be caught. Hiding behind the anonymity created by the Internet's trusting technology, he exhibits no social conscience.
that we can not have a stable Internet economy while 13 year-old children are free to deny arbitrary Internet services with impunity. I wanted these attacks to stop, but I was certainly in no position to make any "parental" demands of "Wicked". While we were essentially functional, hiding behind our router filters, we could not remain behind them forever. We were unable to send and receive "ping", "trace route" and UDP fragments — all crucial requirements for full Internet function. In the long term this would pose serious problems for the delivery of GRC's Internet security testing services. I had to find a better solution.
Since I had collected the exact dates, times, and IPs for each of "Wicked's" several dial-up connections, I felt that perhaps Earthlink could preserve the access and phone records in case the FBI might need them later. If his home phone number could be determined, we could identify him. I knew that Earthlink would never reveal such information to me, but I just wanted them to preserve the evidence against the possibility of future need. Two months before this, Earthlink's privacy officer, Les Seagraves, and I met and formed a good relationship during our quest to understand the peculiar Earthlink Browser Tag. Unfortunately, Les' voicemail explained that he would be out of town through the end of the month. So I got the name of Earthlink's director of corporate communications, Kurt Rahn, from a well-placed press contact of mine. Kurt was prompt with eMail, and he made lots of motivated-sounding noises, but nothing more ever happened. After waiting hopefully for several days, I finally spoke to Kurt on the phone and allowed myself to sound a bit perturbed. It had no discernible effect. His many promises to have Earthlink's security people get in touch with me never resulted in a single contact from anyone.
Now, you might think that this would be significant to @home's chief of security, Todd Welch, but it isn't. I tried to talk to him on the phone, leaving a detailed voicemail describing the situation, but I was shuffled off into the system and asked to eMail the IP's to "abuse@home.com". Refusing to have the machine IP's disappear and never to know what, if anything, had been done, I called back the next day and got Todd on the phone. I have no idea why, but he didn't sound at all happy to be talking with me. It was as if he wished this problem would just go away — or that at least, I would. I explained that many of the compromised and Zombie-infected @home machines were showing a machine name of *.sfba.home.com, which I presumed, and he reluctantly confirmed, stood for "San Francisco Bay Area". Since @home is in Redwood City on the Bay Area Peninsula, I thought that perhaps I could fly up to their offices, then he and I could make a few house calls on some Bay Area Zombie-infected @home subscribers.
nasty nightmares that had been plaguing us for the previous two weeks so that I could take it apart and figure out what made it tick. I told Todd that after I had dissected a Zombie, I might be able to come up with a way for @home to scan their network to find all of them. It turns out that I have found a way, but again, Todd and @home couldn't be bothered. He declined all cooperation of any sort, curtly adding that they work with the FBI, and no one else. As we will see next, this is a policy in dire need of change. Nice as it sounds on the surface, the realities of Federal government involvement mean that most of the time Todd and @home . . . do nothing. Okay, time to call the Feds . . .
Both FBI guys said similar things:
Contrary to what you might presume, I did not regard any of this as particularly bad news. I felt that I should do what I could do in the legal arena, because I should. But I really didn't have any desire to be responsible for putting a 13 year-old behind bars. I have since told "Wicked" that if he doesn't wise up, in five years his "youthful offender shield" is going to dissolve and he could find himself in some serious trouble. He says that he was already in trouble with the FBI when he was eight — for hacking government servers. His computer was taken away until he was ten, then he was carefully monitored for another year until he was eleven. But now he's right back at it. <sigh> The local FBI agent did ask for the IP's and domain names of the 474 machines that participated in the May 4th attack. I forwarded the information to him immediately, so now they have that stuff. But I was still no closer to having any REAL answers . . .
But that gave me an idea: Although the big ISP's are apparently so big that they no longer need to care about their customers, the smaller users — like TAMU — might be much more receptive. So I sent out a mass of eMail to every smaller ISP and domain administrator of the infected attacking machines. I explained the situation and asking for their help.
Zombie and sent it to us! I will never know whom to thank because they dropped the Zombie into our anonymous web-based Spyware drop-box. But it was all I needed to learn how these Zombie's operate and then infiltrate the Zombie High-Command . . .
My inspection of the 15,904 byte Zombie program quickly revealed it to be an IRC (Internet Relay Chat) client. So I decided to sacrifice a PC to the Zombie by deliberately infecting it while keeping it under observation with a packet sniffer running on an adjacent machine. I freshly reformatted a laptop, installed a completely clean copy of Microsoft Windows, named the machine "Sitting Duck" . . . and turned it on.
pre-programmed, IRC chat server. It then joined a secret and password key-protected channel on that server . . . and waited for instructions. It didn't have long to wait.
hundreds of others — arrived and departed the secret "Zombie meeting grounds" of the IRC server. Somewhere, Windows users were innocently turning on their PC's. Lacking any effective personal firewall security (we will see later that BlackICE Defender provides no protection), the Zombies running secretly and silently inside those machines were connecting to this IRC server. They maintained persistent connections for the duration of that PC's access to the Internet. The Zombie and its master don't care whether the machine is cable-connected, DSL, or dial-up — though higher-speed connections are always preferred, as are machines that tend to be "on" most of the time. After all, you just never know when you're going to need to go attack someone. While I was watching this sad drama, suddenly and with no warning everything went crazy: The packet sniffer's packet display became a blur as its scrollbar "thumb" rapidly shrunk to its minimum size. Thousands of packets were being logged per second! Since I was nervous during this first incursion into hacker territory, my first thought was that I had somehow already been discovered, and my little "Sitting Duck" laptop was under attack. But the cable-modem I was using to guarantee my anonymity revealed the truth: The RECEIVE light was dark, but the TRANSMIT light was ON SOLID! I immediately shut down the Zombie-infected PC and scrolled the packet log back before the beginning of the attack. I found the command that the Zombie running in my laptop had received just before all hell broke loose . . .
of Service attack against a machine in Finland! Yikes! This was unacceptable. I wanted to keep active Zombies running here so that I could study their behavior, but I could not have them participating in Internet Denial of Service attacks. So I hacked the Zombie to kill its ability to send damaging packets.
"Attack-Neutered Mutant Zombies" Later that night I received another surprise . . .
The Sub7Server Trojan is massively invasive. It has been designed to give its master virtually complete control over the compromised PC. This includes complete file system inventorying and file access, and real-time keyboard keystroke logging. Any user with Sub7 in their machine might as well have the hacker standing right next to them watching every move they make while using the computer. Although it was not the focus of my research, examining the latest version of Sub7 was an education in itself. Sub7 is downloaded by the Zombie from a "free web pages" web server as a single file named "HardcoreS7.exe". When this executable file is run it breaks apart into two randomly-named files so that it is not possible to search by filename. The original "HardcoreS7.exe" file is then deleted. Sub7 insinuates itself into Windows in a few clever ways. It installs in the seldom used "run=" line of the deprecated WIN.INI file. It also installs under the "Run" key of the registry, and it inserts a much smaller 10k "runner" into the Windows Shell "command/open" key. All of this pretty much guarantees that Sub7 will keep running inside the system. It's difficult to shake it loose. When Sub7 awakens inside a machine it begins listening on the random port it chose during its installation. This means that security scanners can no longer scan for "the Sub7 port" since there isn't one. After setting itself up for business, Sub7 sends out notifications to hackers of its availability through two different channels: It joins a special Sub7 IRC chat server where it posts a notice listing all the details required for its connection and use:
At the same time, identical information is posted to a newsgroup server through a web server CGI script. Hackers no longer need to "scan" the Internet for vulnerable machines running Sub7 . . . each copy of Sub7 phones home providing complete connection details.
So I downloaded a copy of the Internet RFC 1459 for Internet Relay Chat (IRC) Protocol and figured out how IRC works. By the time I was done, I had written a handful of application-specific tools for infiltrating and spying on hacker and Sub7 Trojan IRC channels. The tools chronicled dialogs, and captured references to other server, hacker and Zombie channels. They automatically spawned new instances to begin monitoring newly discovered servers. They snagged passing URLs and quickly downloaded anything that was referenced. I even got quite fancy and built a Markov-chain finite-state statistical dialog modeller. It monitored the flow of IRC channel nicknames and automated the process of determining who was talking to whom, and who were the "bosses" who commanded the most power and respect. I learned an amazing amount about this bizarre world of zombie-running hackers. During the process I witnessed a truly disturbing number of nightly Internet attacks. At this point I had two goals: I wanted to thoroughly understand this technology for its own sake. After all, I am fascinated by the issues surrounding Internet security and privacy. I also wanted to understand how everything worked so that I could, if possible, defend against any future similar attacks. (For example, by infiltrating, commandeering, and neutralizing any attacking force of Zombies.) I also still needed to "get through to" Wicked somehow. I needed to convince him to lay off his repeated attacks.
One afternoon, one of my spy-bots intercepted a conversation taking place between that hacker ("^b0ss^") and another nicknamed "lithium_". Their dialog revealed that "^b0ss^" was creating a new Zombie for "lithium_", editing it to report to a different secret IRC channel using a different password. Unaware that they were under surveillance, they spoke openly of their plans. I didn't discover that interchange until later that evening, but my URL interceptor and downloader had automatically snagged a copy of the new Zombie (this time named "win.exe") and had downloaded it into my Zombie-repository for safe keeping. Peeking into this new Zombie's now-quite-familiar guts, I immediately noticed something odd: "^b0ss^" had apparently made a small mistake with his Zombie hex editing. He had separated the new strings for the channel and the password key with a period (.) rather than a null (0). This Zombie would not hunt. I saw an opportunity to help.
I'm no Zombie lover. I have NO desire to aid and abet the hackers in their pursuit of unlawful Internet terrorism. "^b0ss^" and "lithium_" would have soon figured out that something was wrong with the new Zombie — and fixed their simple mistake. But I felt that my pointing it out, bringing an olive branch with me into "Zombie-land", would be the perfect means of establishing a constructive dialog with "^b0ss^ (who was likely to be at least somewhat freaked out when I just popped into his private inner-Zombie-sanctum.) So, I ask you to PLEASE KEEP IN MIND that I had a deliberate need and intent underlying the following dialog which took place with "^b0ss^". When he left one of the main Sub7Server areas and appeared over in the room where he tends his Zombies, I had all of the secret channel names and pass-keys at my disposal. So I just jumped into the room and said "heh". While I was using a Windows IRC chat client, one of my Spy-Bots was automatically recording and logging our dialog from that "long under surveillance" Zombie haven: |
|
As we now know, A 13 year-old hacker . . . . . . (living in Kenosha, Wisconsin) who goes by the hacker handle "Wicked", was informed by some senior hackers — among them "HeLLfiReZ" a member of the notorious Sub7 crew — that I had referred to them in an online forum, using the derogatory term "script kiddies". I had not. But these senior hackers were upset over a dispute that had erupted in one of our Internet security newsgroups. "Wicked's" response was to team up with two other hackers, all of whom tend and manage large fleets of "IRC Attack Bots". They launched a concerted and extended "packet attack" against grc.com. In the slang that I learned while monitoring their many conversations, they "packeted" us. They did this, not using any tool they had written, and not possessing the ability to create such a tool themselves, but using a powerful "IRC Bot" that had been passed around extensively. Neither Wicked nor his friends know who wrote it or even where it came from.
The "Wicked" Attacks After "Wicked's" Bots connect to the "wkdbots" server, they join and monitor the secret "#pines1" IRC channel using the password key "penile". (You will note that "pines" is the word "penis" with the vowels transposed.) The IRC Bot which Wicked hex-edited to create his own uses a more straightforward channel and password key. On the evening of May 4th, 2001, after logging onto the wkdbots IRC server and joining his Bots on the #pines1/penile channel, "Wicked" typed the following two commands which were immediately relayed, courtesy of their shared IRC chat server, to his awaiting fleet of IRC attack Bots:
Windows PC's, containing remote control attack "Zombies", were attacking the grc.com server.
A small sampling of the "Bot's" command language . . .
This causes the Windows machine to send ten thousand very large (64 kbyte) "ping" packets to the machine at the specified IP. A bit of math shows that this is 655 megabytes of data. This doesn't generate a high-speed stream because the "ping" command waits for a reply before trying again. But if many machines are all pinging at once, the result is cumulative and can be significant. Since the ping command is being executed by a separate (ping.exe) program, the Bot is then free to wreak more havoc . . .
In response to receiving the !udp command, each of the hundreds of attacking machines replied: |
| . . .
and then began "bombing" grc.com with a blizzard of fragmented UDP and
ICMP packets, thus consuming our bandwidth several times over and
denying our services to the Internet.
PC's, pumping out maximum-size UDP packets at their maximum upstream bandwidth, were easily able to flood and completely consume grc.com's bandwidth. This was no "finesse" attack. There was nothing clever about it. The 13 year-old perpetrator had not created the attack tool, and never could. He barely even knew how it operated. But like someone who is handed a loaded gun, even lacking any understanding of how that gun operates, "Wicked" was able to pull the trigger.
for 17 hours by a classic Distributed Denial of Service (DDoS) attack. Before I leave the topic of Zombie/Bot commands, I thought you might find the "!r" command interesting. "R" must be short for "Ready" or "Report" or "Rally" because it immediately causes all currently connected and listening Zombie's to "report in". Here is a snippet that one of my spy-bots picked up when "^b0ss^" gave the "!r" command to his troops:
Those random-character evilbot nicknames, appearing in angle brackets at the front of each line, are the random names generated by each Zombie when it logs on to the IRC server. In the unlikely event of a nickname collision the Bot simply generates another.
"IRC Bots" are among the newer breed of Distributed Denial of Service (DDoS) agents deployed by the Internet's most active hackers. Whenever an IRC Bot hosting Windows PC is started, the Bot waits for the system to finish booting, then connects to a previously designated IRC server. Using a private password key, it joins a secret IRC channel that is not visible to other users of the IRC server . . . and awaits commands. The use of a central IRC server provides significant anonymity, deployment, and logistical benefits to the hackers, although as we have seen, it is not without liabilities. I was able to successfully penetrate the Bot's world without much trouble. IRC servers are often configured to deliberately obscure the names and IP addresses of their clients, thus providing anonymity to all users. Since this anonymity can only be breached through physical access to the server, many Bot armies are "run" from servers located on foreign soil where access is impossible to obtain. Since IRC Bots "phone home" to the central server, the hacker does not need to know which specific machines are hosting his Bots. This allows Bots to be deployed in the wild by a wide variety of means. Hackers create Bot-carrying eMail viruses (frequently enabled by Microsoft's virus-friendly Outlook Express), they create infected Internet "Trojan" downloads, place Bots in USENET newsgroups, and do anything they can to get their Bots into other people's computers. IRC Bots never need to be "scanned for" since all active Bots contact their home base IRC server whenever they "awaken". The various IRC Bots I have acquired and examined are just 15,904 bytes in size, so they are easily hidden as trojans within other, typically huge, Windows programs.
All of the IRC Zombie/Bots open and maintain static connections to remote IRC chat servers whenever the host PC is connected to the Internet. Although it is possible for an IRC chat server to be configured to run on a port other than "6667", every instance I have seen has used the IRC default port of "6667". Consequently, an active connection to an IRC server can be detected with the following command:
Open an MS-DOS Prompt window and type the command line above, then press the "Enter" key. If a line resembling the one shown below is NOT displayed, your computer does not have an open connection to an IRC server running on the standard IRC port. If, however, you see something like this: |
TCP 192.168.1.101:1026 70.13.215.89:6667 ESTABLISHED
| . . . then the only question remaining is how quickly you can disconnect your PC from the Internet!
A second and equally useful test can also be performed. Since IRC servers generally require the presence of an "Ident" server on the client machine, IRC clients almost always include a local "Ident server" to keep the remote IRC server happy. Every one of the Zombie/Bots I have examined does this. Therefore, the detection of an Ident server running in your machine would be another good cause for alarm. To quickly check for an Ident server, type the following command at an MS-DOS Prompt:
As before, a blank line indicates that there is no Ident server running on the default Ident port of "113". (Note the "space" after the 113 and before the closing double-quote.) If, however, you see something like this: |
TCP 0.0.0.0:113 0.0.0.0:0 LISTENING
| . . . then it's probably time to pull the plug on your cable-modem!
I downloaded the current, completely free, version of ZoneAlarm 2.6 from the ZoneLabs web site and installed it on the "Sitting Duck" laptop. Upon restarting the machine I was gratified to receive immediate notification that the Zombie/Bot was attempting to make an outbound connection to its IRC chat server. Meanwhile, the Sub7 Trojan was sitting quietly waiting for someone to connect to it. So I used another machine to "Telnet" to the port the Sub7Server Trojan was listening on. Up popped ZoneAlarm asking whether the nonsense-looking random character name the Sub7Server had chosen for itself should be allowed to accept a connection from the Internet. Perfect performance from ZoneAlarm. Then I had a thought: What would Network ICE's BlackICE Defender do under the same circumstances?
As far as I could tell, BlackICE Defender had ABSOLUTELY NO EFFECT WHATSOEVER on the dialogs being held by the Zombies and Trojans running inside the poor "Sitting Duck" laptop. I knew that BlackICE Defender was a lame personal firewall, but this even surprised me. The Zombie/Bot happily connected without a hitch to its IRC chat server to await further instructions. The Sub7 Trojan sent off its eMail containing the machine's IP and the port where it was listening. Then it connected and logged itself into the Sub7 IRC server, repeating the disclosure of the machine's IP address and awaiting port number. No alerts were raised, nothing was flashing in the system tray. The Trojans were not hampered and I received no indication that anything wrong or dangerous was going on.
I took a lot of grief after my LeakTest utility
cut right through BlackICE Defender. Network ICE told everyone that
LeakTest was "being allowed through" because it was a completely benign
Trojan. I knew that was a load of bull (and they must have too), but it
didn't really matter to me, and I had no affirmative means of proving
otherwise. I performed one final test: As I had with ZoneAlarm, I attempted to connect to the Sub7Server Trojan running inside the "Sitting Duck" machine on the IP and listening port number the Trojan was advertising all over the Internet . . . and it worked perfectly. I received Sub7's "PWD" prompt asking me to login.
copy of BlackICE Defender? I certainly have no use for it.
|
ZoneAlarm v2.6 (Free) —
The name of that FREE tool will be:
| Spoofarino | tm |
| (If you would like to be notified when Spoofarino is ready, you are invited to join our user-managed eMail system. You can leave any time) |
|
|
| Last Edit: Jun 28, 2004 at 12:04 (201.63 days ago) | Viewed 489 times per day |
 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
|