Correct. A good firewall should be blocking on the in and the out. I only allow specific ports to leave my LAN which I have designated on the firewall.
I'm about 3/4 the way through chapter 4. Chapters 2-3 were really all about configuration, chapter four is very interesting but didn't really leave me with any new questions just a couple new answers. Here is a fun little mini-mini how-to describing how to disable a victim's keyboard (note: I just looked this up on the metasploit website as it pops up in a lot of custom scripts that are available there) and how to put active meterpreter sessions in the background without disconnecting from them. I'm still trying to figure out msfd.
-Find out how to start a meterpreter session and then disconnect from it but still have it remain active:
This can be achieved with CTRL+Z, which will put a meterpreter session in the background so one can interact with the msfconsole again without ending the meterpreter session.
Note: One thing that is strange is that when it asks you if you want to background your session using [y/N]? and you type "y"<enter> you will get an error message saying your command was invalid, however if you check your active sessions the meterpreter session was in fact put in the background and is still fully functional.
-Learn about disablement of keyboard/mouse input.
I really like this one, very fun possibilities. Its also very simple to do. Once in the meterpreter shell just use uictl followed by the specified parameters, you can use the -h option for help. In the following example I disable the victim's keyboard.
-Can you execute a payload on a victim's pc which sends a meterpreter shell back to the attacker; who has used the msfd utility to listen on a specified port; then connect from another remote computer to the attackers computer and work with the meterpreter shell that has been sent to the original attacker?Code:meterpreter > uictl -h Usage: uictl [enable/disable] [keyboard/mouse] meterpreter > uictl disable keyboard Disabling keyboard... meterpreter >
This is still being tested, the two main problems are:
1. I'm not even sure if its possible.
2. I can't get msfd to run in the background so that I can interact with the msfconsole again.
Updated list of questions/curiousities:
-Research Transmogrify to mask/unmask files as any file type.
-What is network pivoting?
-How to interface Metasploit with Nmap or Nessus?
-Learn more about ilog, which is a method of Information logging.
-What is Serve Message Block (SMB)?
-Explore the potential of the Metasploit Data bases.
-Can you execute a payload on a victim's pc which sends a meterpreter shell back to the attacker; who has used the msfd utility to listen on a specified port; then connect from another remote computer to the attackers computer and work with the meterpreter shell that has been sent to the original attacker?
Do you assume that the victim is not running an antivirus?Because if (s)he does then you wont get your shell.The firewall is on. It doesn't really matter either way though because I'm using a payload that has been turned into an executable and then executing that executable on the victims computer (Win XP box). The victim could have to the best firewall in the world but it doesn't block (at least to my knowledge and correct me if I'm wrong) traffic going out, only traffic going in. Basically the victim is sending the meterpreter shell to the attacker who is listening and waiting for it. I'm pretty sure this renders any firewalls useless but I could be wrong.
I think others would appreciate what you've done here. Maybe it should be wiki'fied? http://backtrack.offensive-security.....php/Main_Page
I'm a compulsive post editor, you might wanna wait until my post has been online for 5-10 mins before quoting it as it will likely change.
I know I seem harsh in some of my replies. SORRY! But if you're doing something illegal or posting something that seems to be obvious BS I'm going to call you on it.
This is from a little while ago when KMDave suggested that I start msfd before I run the exploit. I thought that this would be a good idea too but I don't think that it is possible. After doing a bit of research I read that msfd runs in "daemon" mode as a default, from my understanding this meant that it could run in the background of the msfconsole session. However, then I a section of the remote-exploit wiki that shows an example of msfd being run in daemon mode and it does not return the "user interaction" (for lack of a better phrase). Link: https://wiki.remote-exploit.org/backtrack/wiki/msfd
Even though neither my first test or this one has been completely successful I am still hopeful that this goal:is still possible. The reason I am still hopeful is because in the msfd source I found an interesting comment: "The nice thing about this interface is that it allows multiple clients to share one framework instance and thus makes it possible for sessions to to be shared from a single vantage point". Link: http://trac.metasploit.com/browser/f...rk3/trunk/msfd. This leaves me to conclude that there is simply something I am doing wrong/forgetting to add. Maybe someone who is more knowledgeable can drop a hint.-Can you execute a payload on a victim's pc which sends a meterpreter shell back to the attacker; who has used the msfd utility to listen on a specified port; then connect from another remote computer to the attackers computer and work with the meterpreter shell that has been sent to the original attacker?
Edit: Something a little bit exciting; I started msfd from a terminal session instead of a msfconsole session and msfd was able to run in the background, however when I tried to perform the same experiment as below it failed again.
Thank you for the recognition, PMed.
This is actually one of the best threads I've read over the last weeks. I really appreciate that you share your findings, questions and solutions with the community.
Going to look into the msfd myself tomorrow, will have some more time for it by then.
Keep up the good work, it is a valuable contribution. I hope that this encourages more people to share their learning experience
Tiocfaidh ár lá