Weird file named ".."

kyaizen

揸緊中指
May 26, 2007
606
1
0
OK, so my site has been infected by malware, and while I was cleaning it up I came across this file by the name ".." -

bVa53I8.jpg


Couldn't transfer it via FTP, so I looked at the file on cpanel -

Code:
vFPuWN80hSq17G4OF8oyhg==
6gi4EYJk02vwpTBOQpZ2
6AuvDYBkyXD1vjNY
6A2vDYJkyXfxpSlRSpM=
6gm5EYFk0mvzoTJOQpZw
6gi4EYJk02vwpTVOQpd8
6AuvDYBkyXH5vjBU
6gi1EYRnyXfyoilUSg==
7wqvDYJ/1nH3vjZVQQ==
4givCIV/1Xfxvj5Q
4wmvDoZoyXfypylSQJQ=
6gi3EYN/0HzvoT9S
6gS5EYVnyXDvoTVX
4g2vDYNhyXT1vjZSQQ==
6gy4EYFh0WvwpjJOSpA=
7hKwC4p/1XDxvjZVQw==
6gu5EYFgyXfyvjVTQw==

I checked my backups and the file wasn't there originally and so I deleted it, but it gets re-created automatically.

What's this file? Is it malicious?
 


x42f (the folder I see in your structure) is not an WP folder, either.

::emp::
 
what httpd are you running, apache?
 
You've been hacked.

'..' on nix is a "file" which means "go up one level", aka "cd ..", but it wouldn't have data in.

Backup, wipe, reinstall latest versions of everything.
 
I've gotten the host to clean up the infected files: here's the logs in case someone similarly infected stumbles upon this later -

SITE.com/test_php.php: HG.PHP.Shell.17768.UNOFFICIAL FOUND

SITE.com/wp-includes/wp-4BaO4S.php: HG.PHP.Shell.10901.UNOFFICIAL FOUND

SITE.com/wp-includes/js/jcrop/jquery.Jcrop.php: HG.PHP.Shell.12109.UNOFFICIAL FOUND

SITE.com/wp-content/plugins/wp-live-chat-software-for-wordpress/plugin_files/images/gallery.php: HG.PHP.Shell.12258.UNOFFICIAL FOUND

SITE.com/wp-content/plugins/wp-dropcaps/gallery.php: HG.PHP.Shell.12258.UNOFFICIAL FOUND

SITE.com/wp-content/themes/wp-booter.php: Atomicorp.PHP.Reverse.Shell.20101124191802.UNOFFICIAL FOUND

SITE.com/wp-content/uploads/optpress/images_optbuttons/2013120712-14-58phpinfo.php: HG.PHP.Backdoor.17374.UNOFFICIAL FOUND

SITE.com/wp-admin/images/screenshots/about-retina.php: Atomicorp.honeypot.hex.php.cmdshell.egyspider.217.UNOFFICIAL FOUND

The site runs OptimizePress which was compromised.
 
WP sites always get reinfected, absolute nightmare once they've had malware.

It maybe good for a while but dont be surprised if it comes back.
 
WP sites always get reinfected, absolute nightmare once they've had malware.

It maybe good for a while but dont be surprised if it comes back.

ya, it's a pain in the balls but i successfully cleaned a server after a wordpress hack without a full reformat. the key thing for me was logging outbound DNS requests. most of our compromised servers are just used to launch attacks on other servers. after watching the DNS for a week, i found the backdoors they'd placed.
 
ya, it's a pain in the balls but i successfully cleaned a server after a wordpress hack without a full reformat. the key thing for me was logging outbound DNS requests. most of our compromised servers are just used to launch attacks on other servers. after watching the DNS for a week, i found the backdoors they'd placed.

You log them somehow or just watch using netstat?
 
just enable log in bind at /var/log/bind.log
this file should just have the domains on your server and any server scripts that contact the internet for some reason. anything else is suspect.

this log doesn't list the process or anything. this was all this time last year and i can't remember how exactly i did it.
 
What we do nowadays is after installation of the software, we hash every file on the server. Just grab the contents of the file, and create a simple MD5 hash out it. Every few hours a cron job runs, and checks all files against the initial hashes. If any files have been added or a single character changed, we're instantly notified of it.

I guess there's also LINUX daemons out there that will watch all changes to the filesystem, and can immediately notify you of changes in various ways, but I haven't had time to fully research it yet. It's one of the 18,432 things that are on the to-do list.

Plus obviously, ensure your server permissions don't allow for the software to write to the server. If you're using Apache suEXEC of Nginx's php-fpm, ensure the user / group it's running on is NOT the same as the user / group that owns your domain / files. Have HTTPd running under say nobody / nobody, with all your domain's files & directories owned by an actual user. It's a pain at times, but it helps.

EDIT: I'll get blasted for this one, but ionCube is also a great help too, because it basically 100% prevents any file injection into existing scripts. If you try to inject code into an ionCube encoded file, it simply breaks the entire file, and it won't run anymore.
 
^^ Holy shit, and am I ever a nerd these guys. Quite comical when considering back in the day, I used to rake rocks out of dirt for a living. "Matt! Get your ass over there, and rake that dirt! I want a perfect slope when I get back!"
 

Yeah, that's the one I seen. Have you ever used it? If so, would you recommend it for things such as protecting against file injection attacks? This is assuming once the server is locked down for production mode, no files are changed / modified.

In other words, is it worth a few hours of my time to delve into, and play around with? Or is it still in somewhat of a wait-and-see / development phase?
 
Yeah, that's the one I seen. Have you ever used it? If so, would you recommend it for things such as protecting against file injection attacks? This is assuming once the server is locked down for production mode, no files are changed / modified.

In other words, is it worth a few hours of my time to delve into, and play around with? Or is it still in somewhat of a wait-and-see / development phase?

I think it has been in the kernel for a while, so go for it. Obviously it won't protect against a rootkit, but I don't know what will.