An old trick to make sure you got shell access on a very large system later was to change the MOTD and tell people to run a command to verify account usage. The percentage of Unix savvy people who would run a program called "RunMe" that appeared in their Home directory does not seem to be different than it was 10 years ago.
Pardon me if I'm being literal-minded, but how did that executable get into the target user's home directory, if you didn't yet have shell access on his/her system? And wouldn't you already (likely) possess at least as much privilege as you could trick a regular user into giving you, if you were already permitted to write files in his/her home directory? (Modern *ix systems don't default to other groups having write permissions to a user's homedir, anyway.)
You probably mean tricking a fellow shell user into running an untrustworthy executable, and then social-engineering him/her into disclosing confidential data to that program. If "." isn't part of $PATH, this tends to be at least a little challenging, in the sense that it's difficult to get users to run /tmp/passwd under the misconception that it's /usr/bin/passwd. (The user would have to have "." in $PATH, or you'd have to be able to convince him/her to set a shell alias of your devising, or something like that.)
If you're a good enough social engineer to convince a user to run /tmp/passwd knowing that it's not /usr/bin/passwd (or the user is just that gullible), and he/she's willing to pass confidential data to that executable anyway, then there's no helping that person.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds