captainB Posted October 2, 2013 Report Posted October 2, 2013 Sadly, when there is a vulnurability, you find out when it's too late. As I mentioned earlier a checksum would at least give us early indication that some files have been tampered with. Maybe it would be possible to automate site backups/restores based on that information. By the way, before this happened, I got bots trying to get through the login system at phpVMS and phpBB for months. They finally managed to break into phpBB a few months ago. Afterwards I was able to reduce bot attcks by blocking a LOT of ip ranges, and reduce it further by implementing a "human check" on the register page, which by the way I think should be standard since some of their attempts have managed to overcome captcha. Yeah, I saw the official "post" about patch for phpvms. But since the phpvms is not so widely used, as some other software (wordpress for example or similar), the week spots there are, will be patched after most of the users are already hacked. That is just something that we can not allow to happen anymore, since "sensitive" information can be lost. That is the reason why "dual" protection is used. Our phpvms users wont notice it anyways. Quote
Moderators mark1million Posted October 2, 2013 Moderators Report Posted October 2, 2013 Sadly, when there is a vulnurability, you find out when it's too late. As I mentioned earlier a checksum would at least give us early indication that some files have been tampered with. Maybe it would be possible to automate site backups/restores based on that information. By the way, before this happened, I got bots trying to get through the login system at phpVMS and phpBB for months. They finally managed to break into phpBB a few months ago. Afterwards I was able to reduce bot attcks by blocking a LOT of ip ranges, and reduce it further by implementing a "human check" on the register page, which by the way I think should be standard since some of their attempts have managed to overcome captcha. I found adding an extra page which requires a tick box to be checked before registration completely eliminated spam or bot registrations.to date so far. Quote
llju1 Posted October 2, 2013 Report Posted October 2, 2013 I posted this earlier and did it in the wrong place. Sorry to be a bother. Here is what I put up. Thanks. Ok I'm doing a new clean install after the HACK. I go to my domain/install.install.php and get this error. Fatal error: Class 'DB' not found in /hermes/waloraweb095/b338/pow.llju1/htdocs/core/common/SettingsData.class.php on line 28 I have the newest version with the patch What have I done wrong? Lloyd Mendenhall <solved> Quote
Txmmy83 Posted October 2, 2013 Report Posted October 2, 2013 looks more like a database connection problem Quote
ferdiiskandar Posted October 3, 2013 Report Posted October 3, 2013 It's always sad to see these stupid people doing thing like this, specially they are from Indonesia. One of my VA also has been compromised and I decide do temporary disable it while our WM checking the possible solution as discuss. Regards, Quote
reed0427 Posted October 3, 2013 Report Posted October 3, 2013 Our site was compromised, so I read the forum and looked for all the suspicious files. Found one, deleted it. Problem persisted. So I did what most people suggested- I went through every file and deleted everything dated after Sept 10. Now the entire website is down. WTF? Quote
Moderators joeri Posted October 3, 2013 Moderators Report Posted October 3, 2013 reed you schould not just have deleted every file that datad after sept 10 you schould look at file that schould not have been there Quote
Moderators mark1million Posted October 3, 2013 Moderators Report Posted October 3, 2013 Our site was compromised, so I read the forum and looked for all the suspicious files. Found one, deleted it. Problem persisted. So I did what most people suggested- I went through every file and deleted everything dated after Sept 10. Now the entire website is down. WTF? If you have a backup i could have a look at the files in there for you, you know what should be there not not really but also if your on the same server check other directories. Quote
Administrators simpilot Posted October 3, 2013 Author Administrators Report Posted October 3, 2013 Done that now, already made the code that produces the MD5 from all the files, will work on the script that will do the checks and then try to integrate that somehow ( in the admin panel? or a CRON outside script? ) Either would be benefical. I think you would probably need to be able to have set to run in either format, just as the maintenance functions of phpVMS. Create a pull request on gitHub or link us to your repo, we probably can help out develop the code. Quote
freshJet Posted October 3, 2013 Report Posted October 3, 2013 If you have a backup i could have a look at the files in there for you, you know what should be there not not really but also if your on the same server check other directories. Well, if you have any files that you need that were edited after that date then that was a bit silly. Anyway, why Sept 10th? All of mine were later on, find out when your site was compromised, not when everyone else's was. 1 Quote
mischka Posted October 3, 2013 Report Posted October 3, 2013 Today I got an email from my hosting provider We have received notification about compromised website virtualairlines.eu. Please check the attachment for more detailed information. Also, we have scanned your website files with server antivirus and it found the following infected files. admin/modules/Settings/NoFree.php: PHP.Hide FOUND admin/modules/SiteCMS/thumb.php: PHP.C99-13 FOUND default.php: PHP.Hide FOUND Looks like they now managed to get into one of my sites, even though the ofc_upload_image file wasn't there anymore... I deleted it a few days ago! Judging from the timestamps of several files in my root, the files were created on 1st of October. Quote
Moderators mark1million Posted October 3, 2013 Moderators Report Posted October 3, 2013 You guys could use this, its not 100% but it will give you some idea, http://app.webinspector.com and http://www.unmaskparasites.com/ Pop your url in there and let it scan your site. Quote
Moderators mark1million Posted October 3, 2013 Moderators Report Posted October 3, 2013 Well, if you have any files that you need that were edited after that date then that was a bit silly. Anyway, why Sept 10th? All of mine were later on, find out when your site was compromised, not when everyone else's was. We all know this exploit has been about since 2009 so dating your files is useless. You need to examine everything unless you know exactly. Most of the default phpvms files are 2011 depending what version your running so you can easily check that way. Quote
reed0427 Posted October 3, 2013 Report Posted October 3, 2013 Yes, deleting all the recent files was probably a pretty lame idea on my part. Luckily I have friends who aren't so ignorant of web site-ology and have been able to get things rolling again. Lesson learned- next time, call in an expert! Quote
RVF147 Posted October 5, 2013 Report Posted October 5, 2013 Still working to get this all sorted out. They deleted my entire root folder i had everything in and replaced it with their crap. Backups are failing each time...any suggestions? Im running out of thoughts. Quote
Strider Posted October 5, 2013 Report Posted October 5, 2013 If u still have everything, and the database is intact, u can just reinstall phpvms using the updated version. and put the things u had edited and modified back. Quote
freshJet Posted October 5, 2013 Report Posted October 5, 2013 What's also useful is if you have a malware scanner on cPanel. I used it and it detected the harmful files. Quote
FlyingMachine Posted October 10, 2013 Report Posted October 10, 2013 in case nothing found in this folder is there any step to close this vulnerability exploit ??? Quote
freshJet Posted October 10, 2013 Report Posted October 10, 2013 Whether anything is found or not, you must use the patch that Nabeel released last week. Quote
FlyingMachine Posted October 11, 2013 Report Posted October 11, 2013 Whether anything is found or not, you must use the patch that Nabeel released last week. please can u give me the post number or the link ? Quote
freshJet Posted October 11, 2013 Report Posted October 11, 2013 Doesn't take much to look, but here it is: http://forum.phpvms.net/topic/16598-21936-security-patch/ Quote
vcal Posted October 15, 2013 Report Posted October 15, 2013 Can someone tell me what this means? I have been having a few issues with VMS installing. I have read through the messages and cannot find anything that might help me. This was a fresh install as they completely messed my site up. RewriteEngine on RewriteCond %{HTTP_HOST} ^fanplastic\.co\.uk$ [OR] RewriteCond %{HTTP_HOST} ^www\.fanplastic\.co\.uk$ RewriteRule ^/?$ "http\:\/\/www\.fanplastic\.co\.uk\/" [R=301,L] RewriteCond %{HTTP_HOST} ^fanplastic\.vcal\.org\.uk$ [OR] RewriteCond %{HTTP_HOST} ^www\.fanplastic\.vcal\.org\.uk$ RewriteRule ^/?$ "http\:\/\/www\.fanplastic\.co\.uk\/" [R=301,L] Warning: Creating default object from empty value in /home/vcalorgu/public_html/core/classes/Vars.class.php on line 74 Strict Standards: Accessing static property XML::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property XML::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property XML::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property XML::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property ACARS::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property ACARS::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property ACARS::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property ACARS::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property RouteMap::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property RouteMap::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property RouteMap::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property RouteMap::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Downloads::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Downloads::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Downloads::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Downloads::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Pages::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Pages::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Pages::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Pages::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Logout::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Logout::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Logout::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Logout::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property FSFK::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property FSFK::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property FSFK::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property FSFK::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Login::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Login::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Login::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Login::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Finances::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Finances::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Finances::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Finances::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property FrontBids::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property FrontBids::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property FrontBids::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property FrontBids::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Schedules::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Schedules::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Schedules::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Schedules::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property News::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property News::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property News::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property News::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property PIREPS::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property PIREPS::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property PIREPS::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property PIREPS::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Contact::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Contact::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Contact::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Contact::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Frontpage::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Frontpage::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Frontpage::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Frontpage::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Registration::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Registration::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Registration::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Registration::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Registration::$get as non static in /home/vcalorgu/public_html/core/modules/Registration/Registration.php on line 25 Strict Standards: Accessing static property Pilots::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Pilots::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Pilots::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Pilots::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property kACARS_Free::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property kACARS_Free::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property kACARS_Free::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property kACARS_Free::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Strict Standards: Accessing static property Profile::$post as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 67 Strict Standards: Accessing static property Profile::$get as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 68 Strict Standards: Accessing static property Profile::$controller as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 70 Strict Standards: Accessing static property Profile::$activeModule as non static in /home/vcalorgu/public_html/core/classes/CodonModule.class.php on line 73 Welcome to phpVMS! Posted by phpVMS Installer on 10/15/2013 Thanks for installing and using phpVMS! Check out the docs for help and information on getting started on your VA. This is just a starter skin - customize yours completely. This is just a basic, barebones example of what a skin is and how it works. Check out the crystal folder in the lib/skins directory. Make your own copy and fiddle around. For help, check out the forum, and skinning docs. Also, be sure to check out the skinning tutorials for a quick primer. The forums are also filled with plenty of helpful people for any questions you may have. Good luck! Welcome to phpVMS! Posted by phpVMS Installer on 10/15/2013 Thanks for installing and using phpVMS! Check out the docs for help and information on getting started on your VA. This is just a starter skin - customize yours completely. This is just a basic, barebones example of what a skin is and how it works. Check out the crystal folder in the lib/skins directory. Make your own copy and fiddle around. For help, check out the forum, and skinning docs. Also, be sure to check out the skinning tutorials for a quick primer. The forums are also filled with plenty of helpful people for any questions you may have. Good luck! Recent Reports No reports have been filed Newest Pilots Fatal error: Cannot re-assign auto-global variable _FILES in /home/vcalorgu/public_html/core/common/PilotData.class.php on line 436 Quote
Vicar Posted October 17, 2013 Report Posted October 17, 2013 After the first exploit I deleted the file "ofc_upload_image.php" from the "php-ofc_library" folder. Did not help for long. Within the last 24 hrs I found 3 foreign folders in the root library, some foreign files in admin/modules/settings, 3 zipped packages containing files that had been unpacked to the foreign folders. The final effect of the exploit was fully working phishing site. Luckily my website itself has been left intact. I installed the update now, but being a layman, though, I presume that if the "ofc_upload_image.php" did not exist on my site during the yesterday's exploit, they must have another way to get through. Correct me if I'm wrong. (I checked FTP, there are no suspicious connections. Here's the log of 24 hrs connections to the website. It does show their activity, e.g. attempts to use the infamous "ofc_upload_image.php" file, which was not in there (unless it ha been placed there and then removed by the exploiters). But with my knowledge, I cannot work out how they sneaked in, maybe someone will be able to make a better use of it to plug the hole for good. http://www.moosedoma...et/imgs/log.txt The suspicious activity seems to be observed with my IT-half-blind eyes is 91.194.91.196 - - [16/Oct/2013:17:10:27 +0200] "POST //core/lib/php-ofc-library/ofc_upload_image.php?name=memex.php HTTP/1.1" 200 52 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36" and from then on. Quote
Vicar Posted October 17, 2013 Report Posted October 17, 2013 I am helpless. Right after I finished this post they attacked again. I keep getting warnings from the bank they phished. Quote
Administrators simpilot Posted October 17, 2013 Author Administrators Report Posted October 17, 2013 I am helpless. Right after I finished this post they attacked again. I keep getting warnings from the bank they phished. Is this a shared server? If you are deleting everything and using a new install of phpvms that either has the patched file or has the file removed and you are still being compromised I would guess that there is another compromised site on the server that has shell access to all the sites and just replaces the offending files in your server space. That or there is an exploit file above the web root of your hosting, for example in your /home directory. One of my dedicated servers I use for resale had this same issue which eventually turned into a DNS Amplification attack. If you have root access do a scan of the entire server, if not get your host to do it. Quote
Vicar Posted October 17, 2013 Report Posted October 17, 2013 No. it's not shared. A commercial one, leased and fully paid for. I talked to the ISP, he knows my problem, they verified, on my request, the security of my account on the shell /root level. As you see in my first post -> the quote -> they seem to be trying to use the previous method. And using that before, they still did get access to my (and not only my, but other victims') root directory, where ICA placed the infamous index.php with their page. Quote
Administrators simpilot Posted October 17, 2013 Author Administrators Report Posted October 17, 2013 Looking at your server IP it looks as though there are at least 12 sites hosted on the same server. -> http://whois.domaintools.com/77.235.50.205 Are all these yours? It would lead me to believe that it is a shared environment, whcih all sites should be checked for any compromised files. Your log entry simply means that someone or something tried to access the script to load up a new shell. If the patched file is in place it will return the 200 status as is noted but with the "exit;" in the patched file nothing more will happen. If you are installing and actually getting compromised again there is only 3 things that it could be in my opinion; 1 - You are not using the patched version of the ofc_upload_image.php file. 2 - There is another site on the server that is compromised that has access to your directory, possibly through the links created by a symlink attack. 3 - You have not changed passwords (FTP, cPanel, email) that were exposed in the original compromise. Quote
Vicar Posted October 17, 2013 Report Posted October 17, 2013 Thanks for help. My server IP is not 77.235.50.205, its 89.146.199.179. (www.moosedomain.net) In a sense of functionality, it does serve multiple internet accounts, ie. the ISP offers hosting to more than one account. In this sense it is shared. But he swore to death today that malware scans report problems only with my account/website, which is not shared or inter-related with any other one. I do not lease/more any other webspace account/server. Passwords. no matter how often we change them, are available once the site is peremeated, since they are stored in ... well, we know where. I have neither the patched version of the ofc_upload_image.php file not the old one. I use no email related to this site. FTP and MYSQL passwords were changed first after the first attack, then again this morning, and then after the second. Few moments later the third exploit came in. If there is another site on the server that is compromised that has access to my directory, possibly through the links created by a symlink attack, how can I react to that/detect/remove the threat? Interestingly I got notified by email from apparently from http://www.internetidentity.com. Not signed with the name. The notiofication was on the illegal content on my site (phishing). They requested any data related to this compromise that we can forward on to our client (i.e. the bank phished). This could include files, source code, log entries, connections to upload or download data to the site, or records of the account being created.. I did not send anything, but replied that the malicious stuff had been removed. 10 mins later (after the site cleanup, and changing passwords) I got another email from them that the site has been hacked again. And this was true...PS/EDIT: The history of FTP connection logs from the last few days show only my home and work IP numbers,. Quote
Administrators simpilot Posted October 17, 2013 Author Administrators Report Posted October 17, 2013 If your server IP is actually 89.146.199.179 and not what is shown in the search then I would guess that the DNS of the server you are hosted on has been compromised and is being redirected to the other server. I notice that when you search your domain info -> http://geoip.flagfox...www.vcal.org.uk <- it comes up with the 77. number, not what you say your IP is. Also, if you then search the IP -> http://whois.domaint...m/77.235.50.205 <- you see that there are a number of websites on it, interesting though is this one that caught my eye. -> fanplastic.co.uk <- which you also have in an htaccess file you posted above with rewrite rules. You can also check your DNS here -> https://www.whatsmyd...www.vcal.org.uk <- and see it is pointing atthe 77. IP address. If you are using the domain name in your FTP client and not the IP you may very well be loading files onto the other server, which is probably controlled by the phisher. If it is one server with multiple seperate sites on it, it is a shared server, ultimatly anyone with elevated permissions that has access to another site could access your home directory. If the 89. IP address is actually correct there are 800+/- sites using that IP, definitely a posibility of there being issues elsewhere on the server. -> http://whois.domaintools.com/89.146.199.179 <- Quote
Vicar Posted October 18, 2013 Report Posted October 18, 2013 Thanks again. How do you check my site against the IP to get the return address 77....? When I entered my website domain (www.moosedomain.net) I always get the correct data. You can also check your DNS here -> https://www.whatsmyd...www.vcal.org.uk <- and see it is pointing atthe 77. IP address. I did that, and I got the correct address in return: Also: Verification at: http://whois.domaintools.com/moosedomain.net returns correct data too. Kind regards, Rafal Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.