metasploit-framework
metasploit-framework copied to clipboard
loot type filter appears broken
It appears the -t filter, and possibly others is not working.
msf5 post(osx/capture/screen) > loot
Loot
====
host service type name content info path
---- ------- ---- ---- ------- ---- ----
2.2.2.2 keylog keylog.log text/plain OSX keylog /loot/20190414205322_default_2.2.2.2_keylog_740944.txt
2.2.2.2 keylog keylog.log text/plain OSX keylog /loot/20190414205559_default_2.2.2.2_keylog_534584.txt
2.2.2.2 screen_capture.screenshot screenshot.0.png image/png Screenshot /loot/20190414205923_default_2.2.2.2_screen_capture.s_194117.png
2.2.2.2 screen_capture.screenshot screenshot.0.png image/png Screenshot /loot/20190414210021_default_2.2.2.2_screen_capture.s_442248.png
msf5 post(osx/capture/screen) > loot -t screen_capture.screenshot
Loot
====
host service type name content info path
---- ------- ---- ---- ------- ---- ----
2.2.2.2 keylog keylog.log text/plain OSX keylog /loot/20190414205322_default_2.2.2.2_keylog_740944.txt
2.2.2.2 keylog keylog.log text/plain OSX keylog /loot/20190414205559_default_2.2.2.2_keylog_534584.txt
2.2.2.2 screen_capture.screenshot screenshot.0.png image/png Screenshot /loot/20190414205923_default_2.2.2.2_screen_capture.s_194117.png
2.2.2.2 screen_capture.screenshot screenshot.0.png image/png Screenshot /loot/20190414210021_default_2.2.2.2_screen_capture.s_442248.png
msf5 post(osx/capture/screen) > loot -t keylog
Loot
====
host service type name content info path
---- ------- ---- ---- ------- ---- ----
2.2.2.2 keylog keylog.log text/plain OSX keylog /loot/20190414205322_default_2.2.2.2_keylog_740944.txt
2.2.2.2 keylog keylog.log text/plain OSX keylog /loot/20190414205559_default_2.2.2.2_keylog_534584.txt
2.2.2.2 screen_capture.screenshot screenshot.0.png image/png Screenshot /loot/20190414205923_default_2.2.2.2_screen_capture.s_194117.png
2.2.2.2 screen_capture.screenshot screenshot.0.png image/png Screenshot /loot/20190414210021_default_2.2.2.2_screen_capture.s_442248.png
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.
Looks like this is still an issue.
msf6 > loot
[-] Database not connected
msf6 > db_connect msf:[email protected]/msf
Connected to Postgres data service: 127.0.0.1/msf
msf6 > loot
Loot
====
host service type name content info path
---- ------- ---- ---- ------- ---- ----
172.16.191.158 linux.passwd passwd.tx text/plain Linux Passwd File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.passwd_692584.txt
172.16.191.158 linux.shadow shadow.tx text/plain Linux Password Shadow File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.shadow_389963.txt
172.16.191.158 linux.passwd.history opasswd.tx text/plain Linux Passwd History File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.passwd.his_499617.txt
172.16.191.158 linux.hashes unshadowed_passwd.pwd text/plain Linux Unshadowed Password File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.hashes_704257.txt
msf6 > loot -t linux.hashes
Loot
====
host service type name content info path
---- ------- ---- ---- ------- ---- ----
172.16.191.158 linux.passwd passwd.tx text/plain Linux Passwd File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.passwd_692584.txt
172.16.191.158 linux.shadow shadow.tx text/plain Linux Password Shadow File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.shadow_389963.txt
172.16.191.158 linux.passwd.history opasswd.tx text/plain Linux Passwd History File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.passwd.his_499617.txt
172.16.191.158 linux.hashes unshadowed_passwd.pwd text/plain Linux Unshadowed Password File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.hashes_704257.txt
msf6 > help loot
Usage: loot [options]
Info: loot [-h] [addr1 addr2 ...] [-t <type1,type2>]
Add: loot -f [fname] -i [info] -a [addr1 addr2 ...] -t [type]
Del: loot -d [addr1 addr2 ...]
-a,--add Add loot to the list of addresses, instead of listing
-d,--delete Delete *all* loot matching host and type
-f,--file File with contents of the loot to add
-i,--info Info of the loot to add
-t <type1,type2> Search for a list of types
-h,--help Show this help information
-S,--search Search string to filter by
msf6 > loot -t linux.passwd
Loot
====
host service type name content info path
---- ------- ---- ---- ------- ---- ----
172.16.191.158 linux.passwd passwd.tx text/plain Linux Passwd File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.passwd_692584.txt
172.16.191.158 linux.shadow shadow.tx text/plain Linux Password Shadow File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.shadow_389963.txt
172.16.191.158 linux.passwd.history opasswd.tx text/plain Linux Passwd History File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.passwd.his_499617.txt
172.16.191.158 linux.hashes unshadowed_passwd.pwd text/plain Linux Unshadowed Password File /root/.msf4/loot/20200913013534_default_172.16.191.158_linux.hashes_704257.txt
There is a workaround for this for the time being but going to see if I can dig into this a bit deeper.
msf6 post(windows/gather/memory_dump) > loot --type enum_patches
Loot
====
host service type name content info path
---- ------- ---- ---- ------- ---- ----
192.168.153.147 windows.environment text/plain /home/gwillcox/.msf4/loot/20230201105703_default_192.168.153.147_windows.environm_800641.txt
192.168.153.147 enum_patches text/plain /home/gwillcox/.msf4/loot/20230201105933_default_192.168.153.147_enum_patches_417548.txt
192.168.153.147 host.ms_keys ms_keys.txt text/plain Microsoft Product Key and Info /home/gwillcox/.msf4/loot/20230201110051_default_192.168.153.147_host.ms_keys_342492.txt
192.168.153.147 windows.process.dump application/octet-stream /home/gwillcox/.msf4/loot/20230201110201_default_192.168.153.147_windows.process._632215.bin
192.168.153.147 windows.process.dump application/octet-stream /home/gwillcox/.msf4/loot/20230201110258_default_192.168.153.147_windows.process._783132.bin
msf6 post(windows/gather/memory_dump) > loot -h
Usage: loot [options]
Info: loot [-h] [addr1 addr2 ...] [-t <type1,type2>]
Add: loot -f [fname] -i [info] -a [addr1 addr2 ...] -t [type]
Del: loot -d [addr1 addr2 ...]
OPTIONS:
-a, --add Add loot to the list of addresses, instead of listing.
-d, --delete Delete *all* loot matching host and type.
-f, --file <filename> File with contents of the loot to add.
-h, --help Show this help information.
-i, --info <info> Info of the loot to add.
-S, --search <filter> Search string to filter by.
-t, --type <type1,type2> Search for a list of types.
-u, --update Update loot. Not officially supported.
msf6 post(windows/gather/memory_dump) > loot -S windows.environment
Loot
====
host service type name content info path
---- ------- ---- ---- ------- ---- ----
192.168.153.147 windows.environment text/plain /home/gwillcox/.msf4/loot/20230201105703_default_192.168.153.147_windows.environm_800641.txt
msf6 post(windows/gather/memory_dump) > loot -S windows.process.dump
Loot
====
host service type name content info path
---- ------- ---- ---- ------- ---- ----
192.168.153.147 windows.process.dump application/octet-stream /home/gwillcox/.msf4/loot/20230201110201_default_192.168.153.147_windows.process._632215.bin
192.168.153.147 windows.process.dump application/octet-stream /home/gwillcox/.msf4/loot/20230201110258_default_192.168.153.147_windows.process._783132.bin
msf6 post(windows/gather/memory_dump) >
Might also need to update the -d option as well since that seems to be either broken or I'm using it completely wrong.
Alright so best I can tell the reason this is failing is because the loots method inside of lib/msf/core/db_manager/loot.rb never actually uses any of the tag information for its searches which use the :search_term key of the opts hash, yet the -S option sets this :search_term option and this is used to filter the search by this loots method. So the two options are either to entirely remove the tags feature all together in favor of the existing -S option which may be better than trying to code two things which essentially do the same thing, or to somehow rework the logic so that the tags specified are actually passed into this :search_term parameter to reuse the existing logic but have things passed correctly.