You are not logged in.
Some of it from firefox and some from chromium. The problem with the live monitoring is that it does not turn up in the history before a reboot.
Offline
OK, that probably means the mysterious process writes to the history file at logout. Try monitoring in that time window.
This silver ladybug at line 28...
Offline
Which also suggests all of it is stored somewhere else between boots. Maybe 'grep -Ri unique_typed_phrase /{home,var,run,tmp}' would find something*.
Edit: Or is it written just before shutdown.target. Then it can be kept in memory.
Edit2: Added other possibilities.
Edit3: * I forgot already, see hokaschs post.
Last edited by emeres (2014-09-02 11:39:35)
Offline
What do you mean by it comes to effect after reboot? What's the difference between the two boots? (Don't tell me one is the left and the other is the right.) Or do you mean it comes into effect after bootup, even before the browser is started?
One is to the left and the other is the right.
....
Seriously:
The difference between the two boots are that nothing - nix, de nada - is logged in history or in ~/ after I have entered a search in the browser input field.
history will show nothing - and look clean.
After a boot it is all there.
I thought I had made that clear - sorry about that.
So I have a problem with monitoring consistently through the boot at which time the dirty content is put into the .bash_history file.
watch pgrep will be interrupted as will lsof - am I wrong?
Edit: you guys are fast ... several new posts - will monitor as suggested there....No great hopes though since the content does not get there with a logout/in
Last edited by viking60 (2014-09-02 14:18:15)
"Common sense is not common"
Offline
You also said this:
What I write here and on other forums - on that laptop - is stored on her /home/wife and given the name of the content. there are lots and lots of files marked as backup files.
Not sure how these files look exactly (and they still only save stuff from the wife user, right?), but at what time are they created?
Check out LoggedFs, sounds like it would be an easy way to log file access.
EDIT:
The difference between the two boots are that nothing - nix, de nada - is logged in history or in ~/ after I have entered a search in the browser input filed.
double-check if a reboot is really needed, or a logout/login is enough
Last edited by hokasch (2014-09-02 11:34:38)
Offline
Been there done that many times, nothing is (visibly) written after a logout and login (It tricked me to believe I got rid of the problem a few times too)
Reboot is really needed afaict -
source .bashrc doesn't do it either
Edit
From this emeres idea to check the clipboard made sense, because the data have to hide somewhere until they are written on reboot...
Last edited by viking60 (2014-09-02 12:26:57)
"Common sense is not common"
Offline
nothing is (visibly) written after a logout and login
So it dumps the logs somewhere on the filesystem, and then it copies it to your history on reboot?! if its really a dedicated keylogger, that sounds broken...
EDIT: eh, as emeres said - if it happens on shutdown, it could still be in memory..
If you want to go the loggedfs route, write an "includes" rule that matches your bash_history, I would guess like this:
<include extension=".bash_history" uid="*" action=".*" retname=".*"/>test it first, then launch it from a systemd unit before multi-user.target, log to a file. That should at least give you the pid and access time.
As an aside, does it append only the keylogged stuff to your history on boot, or are you missing your "legit" bash command history as well until you reboot? Does the keylogged stuff actually execute in a shell somewhere? Like, if you search for "echo "wth" > /home/wife/testfile" will you eventually end up with "testfile" on your disk?
Last edited by hokasch (2014-09-02 12:31:09)
Offline
Wait. If there somehow exists a rogue bash process that is just sucking up all your input, runs as user wife but not running inside your session (so it would survice a log out), this would kind of make sense that you only see it on reboot. Try adding
export PROMPT_COMMAND="history -a"to /etc/bash.bashrc and see if this makes the keylogged line show up immediately in your .bash_history (you need to run history -n to see the new lines in "history" command).
Offline
nothing is (visibly) written after a logout and login
So it dumps the logs somewhere on the filesystem, and then it copies it to your history on reboot?! if its really a dedicated keylogger, that sounds broken...
EDIT: eh, as emeres said - if it happens on shutdown, it could still be in memory..If you want to go the loggedfs route, write an "includes" rule that matches your bash_history, I would guess like this:
<include extension=".bash_history" uid="*" action=".*" retname=".*"/>test it first, then launch it from a systemd unit before multi-user.target, log to a file. That should at least give you the pid and access time.
As an aside, does it append only the keylogged stuff to your history on boot, or are you missing your "legit" bash command history as well until you reboot? Does the keylogged stuff actually execute in a shell somewhere? Like, if you search for "echo "wth" > /home/wife/testfile" will you eventually end up with "testfile" on your disk?
Last things first Yes I will end up with a testfile (as I should).
[wife@wife-lap ~]$ echo "wth" > /home/wife/testfile
[wife@wife-lap ~]$ cat testfile
wthI do not miss the legit history - I just get a lot added.
Edit:
The keylogged stuff is not "executed" which naturally would give error messages
Digging into systemd.....
Last edited by viking60 (2014-09-02 13:11:55)
"Common sense is not common"
Offline
Last things first Yes I will end up with a testfile (as I should).
[wife@wife-lap ~]$ echo "wth" > /home/wife/testfile [wife@wife-lap ~]$ cat testfile wthI do not miss the legit history - I just get a lot added.
Digging into systemd.....
You should write the echo line into your web-browser window and press enter, not in a terminal. Then check if testfile exists with that content. If it does not, reboot and test if it exists.
Last edited by progandy (2014-09-02 13:14:06)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
Ah yes ; done that now but adding this to /etc/bash.bashrc
export PROMPT_COMMAND="history -a"did in fact remove all history so there was no history after reboot. - no "spylogged" material either. And the file was not created.
Removing the entry in /etc/bash.bashrc and doing the test again......
Last edited by viking60 (2014-09-02 13:25:45)
"Common sense is not common"
Offline
did in fact remove all history so there was no history after reboot
Sorry! You need "shopt -s histappend" as well. Forgot this is not set as default.
Offline
Well the reboot gave me a detailed overview of what I have written here
15 Ah yes ; done that now but adding this to /etc/bash.bashrc
16 did in fact remove all history so there was no history after reboot. - no spylogged material either.~ls+++
and the testfile put into the browser search field was not created.
did in fact remove all history so there was no history after reboot
Sorry! You need "shopt -s histappend" as well. Forgot this is not set as default.
Like this ?
export PROMPT_COMMAND="history -a shopt -s histappend"Last edited by viking60 (2014-09-02 13:48:58)
"Common sense is not common"
Offline
Like this ?
No, like this:
shopt -s histappend
PROMPT_COMMAND='history -a'You can put it in your wife's ".bashrc", and reboot to make it stick. This will execute "history -a" after every command, which will append the last command to the history file instead of writing to it only on exit. So you can inspect .bash_history and see what got executed from another shell in "realtime". My idea with that was that if you could make it write not only on reboot, it might be easier to monitor the file, get the pid etc.
But maybe this is all to much mucking around, did you ever try lolilolicon's "bash wrapper" suggestion?
Last edited by hokasch (2014-09-02 14:03:16)
Offline
Thanks for that hokasch!
Sorry but no cigar - no immediate history and the spy content keeps coming after reboot.
"Common sense is not common"
Offline
Use the wrapper lolilolicon suggested and loggedfs, preferably one at a time. As for systemd you should check all targets, something along those lines:
find /{usr/lib,etc}/systemd/ -iname \*.target.wants \! -empty -exec ls -al {} \;
find /{usr/lib,etc}/systemd/ -type f -exec egrep -H 'shutdown|multi-user'.target {} \;Remember to also look in ~/.config/systemd. The point is to find something that is not supposed be there, especially somewhere around multi-user and shutdown targets. Most targets/units should be either documented or easy to find online. Since only one user seems to be targeted, that might also help filtering the information out.
Report back when you win all three battles.
Side note: Should your wife have nothing private in her home directory, maybe it would be wise to upload its content somewhere/pastebin using find and sed, should any part of it need masking. There are access and modification flags, that might be also useful after reboot with freshly logged content. We could look through it, maybe something suspicious comes up. It is okay if you/she do/does not want to.
find $HOME \! -empty | sed 's/wifesrealuser/wife/g'Offline
I had to bail out on this one. I won the battle by deleting the user and creating a new one.
My wife would rather have an un-successful treatment and a healthy patient (computer) than a:
"Successful treatment but the patient is dead". (With the possibility of including me among the patients....)
And she is a (recomendable) private person....
Sorry guys - this is were this ends.
Last edited by viking60 (2014-09-25 08:32:39)
"Common sense is not common"
Offline