The only thing you have to do is simply throwing the URL – base64 encoded – against it. Sample:

echo “http://ftp.icq.com/pub/ICQ7/install_icq7_f.exe” |openssl enc -base64
aHR0cDovL2Z0cC5pY3EuY29tL3B1Yi9JQ1E3L2luc3RhbGxfaWNxN19mLmV4ZQo=

Once queried (sample from above), the webservice responds in a JSON format, like follows:

{“code”:”200″,”message”:”actively malicious”,”signature”:”ADWARE\/Adware.Gen”}

Possible answers are:

• $response['code'] = ’403′; $response['message'] = ‘parameter value missing’;
• $response['code'] = ’402′; $response['message'] = ‘parameter must be base64 encoded’;
• $response['code'] = ’404′; $response['message'] = ‘no incident known’;
• $response['code'] = ’200′; $response['message'] = ‘actively malicious’; $response['signature'] = $row->info;
• $response['code'] = ’201′; $response['message'] = ‘previously malicious but solved within the last 24 hours’; $response['signature'] = $row->info;
• $response['code'] = ’202′; $response['message'] = ‘previously malicious but solved within the last 7 days’; $response['signature'] = $row->info;
• $response['code'] = ’203′; $response['message'] = ‘previously malicious but solved within the last 30 days’; $response['signature'] = $row->info;

Please note: The webservice itself caches the answer of each previously requested URL for 15 minutes.

Having talked about both our projects, Marcel agreed to setup a live URL feed for us by querying a webservice we provide. After checking and categorising the requested and/or alerted URLs, we trigger our take-down measurements to shut down each kind of abuse we detect: phishing sites, infected websites, canadian pharmacy (landing) pages and so on. Additionally we add them to our URL blacklist and spread the information about the malicious content widely.

Thanks again, Marcel. You guys have enhanced our project with your contribution.

Wanna do same? Get in contact with us and let’s talk about it.

In an average, phishing sites are tackled down by us within 1.4 days, regardless of the country, the ISP or domain owner.

As part of our mitigation processes, we feed the toolbars of big brands, like WEB.DE & GMX, to protect millions of customers against phishing attacks or other fraudulent websites. So, more than 6.000 fraudsters URLs (on a regular base) are blocked during the take-down efforts of cyscon’s Security Incident Response Team. A value added service to protect your brand!

Feeded and supported by multiple partners, via webform submissions, spamtrap data and other sensors, we process a couple of tenthousand URLs every day. With our Anti-Abuse Perfomance Index, we provide a KPI (Key Performance Indicator) toolset to measure the effectiness of the responsible network owner. All of these values are independent, hard facts, based on data of malicious URL content (malware, phishing, command & control servers) cyscon SIRT detects, classifies and have previously been reported over to the responsible security contact of the given network.

Give it a try! Join our community and contact us today!

Regarding our records (C-SIRT report) the wordpress based blog was owned a very short time after the exploit came out, via a security leak in the CMS or broken/stolen/bruteforced access credentials (like FTP). The attackers add the following Java applet code:

The payload (the linked JavaX.jar) – hosted on exportidaho.com (see C-SIRT reports) – added to the source code, have been uploaded to another wordpress installation (currently still online) what bring us to the conlcusion, that from an external view it seems that they use a WordPress security hole to break in.

With more than 2 million facebook followers, frequently updated content redirecting the people to the thematical blog, we expect that especially due to the fact, that at the same time the IFA exhibition took place in Berlin, a lot of people got infected as it is likely that most of them haven’t closed the Java security leak in time!

We strongly recommend and ask/advice Samsung to inform their visitors and Facebook fans about the potential risk of a possible infection!

• percentage of open / unhanded incidents
• percentage of recurring incidents
• speed of taken action

All of these criteria’s fits the main goal of each serious network owner: “Tracking down malicious content: reliable, fast & sustainable“.

The Top 10 of  them are namely mentioned on cyscon SIRT’S reputation page, day by day fresh and out of all networks we monitor, based on the data our “Incident Reporting Team” detects and classifies with the help and assistance of our partners & friends!
Check out your “Anti-Abuse Reputation Values” and get in competition the Best …

Ludi incipiant:
Show your competitor, that you are a “non-abuse tolerant network owner” – responsible for a trustworthy internet within your borders –  and get a frequently guest on our reputation “landing page”:  http://www.c-sirt.org/reputation

 (…) the capacity to endure. For humans, sustainability is the long-term maintenance of responsibility, which has environmental, economic, and social dimensions, and encompasses the concept of stewardship, the responsible management of resource use. (…)
(source: Wikipedia)

So let’s have a look on some “special cases”, we have tracked over the past month:

http://www.c-sirt.org/incident/?incident=21aa85bf0e489eb5a7d90a7c2a23b7b0
http://www.c-sirt.org/incident/?incident=ab841f293cb3955d3e84afac4807d774
http://www.c-sirt.org/incident/?incident=6196ffdacd8f50857d65e935b984f4c0

All of these cases are PayPal-Phishing cases, classified by us as “CYSC.PHISH.PAYPAL-40″ and all of them have been reported again, and again, and again, after they have been marked as resolved and were appearingly offline. And indeed, they were offline for some hours, but after the ISP “unlocked” the contract, the customer didn’t take down the malicious stuff … either the customer is unable to understand what to do, or the customer itself is “part of this activities”.

So my question today:
Hey, do you as an ISP monitor the actions of your customers? Or do you just work on the model: “FIRE & FORGET“?

Neither from an economic perspective, nor from a securtity point of view, a single phishing site should be reviewed and processed 22 times (like those above), as this costs a lot of money, for both: The ISP and the phished brand! So why don’t do abuse serious and save time, money and reputational damages, by simply act with the focus: “ONCE & DONE”?

So how’s about you? Do you take abuse serious?

Here are some samples:

abuse@****.**: host antispam4.xxx.xxx.xx [xx.xxx.xx.xxx] said: 521 A URL in
the email is Blacklisted by SURBL: multi.surbl.org. Blocked, xxx.xx.xxx.xxx
on lists [ws], See: http://www.surbl.org/lists.html (in reply to end of
DATA command)

This made it impossible to shut down a very heavily spamvertized cutwail botnet “landing page”.

abuse@****.**: host filter.xxx.xx [xx.xxx.xxx.xx] said: 550 Message
contained unsafe content (Heuristics.Safebrowsing.Suspected-phishing_safebrowsing.clamav.net)
(in reply to end of DATA command)

That’s right: The reported phish hosted here was also listed in Google Safebrowsing.

abuse@****.***.**: host mxin3.xxx.xxx.xx [xxx.xxx.xx.xx] said: 554 rejected
due to spam content (in reply to end of DATA command)

Jepp. And the spamvertized malware was the reason, why we have tried to reach this ISP out.

abuse@****.**: host maildrop1.xxxxxxxx.xx [xxx.xxx.xx.xx] said: 550
An address in this message is listed on inv-uri.rbl.spamrl.com. Please
organise removal and retry. (in reply to end of DATA command)

Why not shutting down the malicious content? The mentioned URL in our abuse report is heavily and widely blacklisted.

abuse@***.**.**: 550 5.7.1 Message rejected due to content restrictions

That’s true it is a phishing site against the paypals users base.

abuse@*****.**: host xxxxx.xxxxxx.xxxxxx.xxx [xx.xxx.xx.xxx] said: 550
5.7.1 Message rejected due to content restrictions (in reply to end of DATA
command)

Sure thing. Same like above … but just against Chase Online banking users.

5.3.0 – Other mail system problem 550-’5.7.1 Message rejected due to content restrictions’
Reporting-MTA: dns; xxxxxxx.xxxxxx.xx.xx

Isn’t it your customers domain, hosted on your shared infrastructure that is spreading FakeAV?

abuse@xxxxx.xx: host mail.xxxx.xx [xxx.xxx.xxx.xxx] said: 550 5.7.1
Command rejected (in reply to end of DATA command)

Yes, we are doing the same, if our customers get phish emails pointing to your host. But why do you reject our complaint about that offending content?

I can write down hundreds of further samples. And all will lead to the same conclusion: Spamfilters are in a wrong use if they are configured to reject emails in front of an abuse mailbox! Why don’t you use them to verify an incoming complaint (by simply tagging them) and will save a lot of human ressources?

So if you are an ISP, please check if your spamfilters are rejecting complaints to your abuse mailbox! It doesn’t make any sense for us, to use them there! And BTW: We track these kind of behaviors …

A life view on the last 10 tracked down incidents is always available at:
http://www.c-sirt.org/incident/

Further, we have improved the customer / ISP self care system. By simple clicking on customized “perfom a reckeck”-links, the alerted abuse departments and/or end customers are able to “solve” an incident within our database/blacklist. Here is a sample:
http://www.c-sirt.org/incident/?incident=8e41d6597322873f311fe8f9cd651a72

If the incident is solved, the output is “green”. An unresolved and still open issue appears “red” (last check within 24 hours) or “orange” (our last re-scan is longer than 24 hours back, and it might be solved). In case of “red” or “orange”, the customer / ISP can perform a “rescan” and get an instant feedback, if he revisits the given URL. Depending on the load of our system, this only takes a few seconds.

As you might have mentioned, we use an own pattern basis (e.g. CYSC.PHISH.PAYPAL-27), to detect and alert webhosting related threads. In case of any false positives, we’d like to refer to: http://www.c-sirt.org/false-positive/, where we describe, how to proceed in case of any false alerts.

On 27th June 2012, cyscon SIRT, provides VirusTotal a webinterface to check if a given URL is listed in c-sirt.org‘s database, and displaying the result (C-SIRT) of this life check within their “URL scan” section.

Here are 2 samples:
VirusTotal result for: http://bbdzrhho.maydoctor.ru/ (CYSC.FRAUD.PHARMACY-4)
VirusTotal result for: http://packstation-kundendienst.com/ (CYSC.PHISH.DHL-3)

By clicking on “Additional information” the threat description is displayed, where we distinguish between 4 different answers:

- current threat
- solved within the last 24 hours
- solved within the last 7 hours
- solved within the last 30 days

If you are interested in using this webservice, e.g. to enhance your product with our dataset, feel free to reach us out.

Wanna get involved? cyscon SIRT could not exist without sponsors who donate hardware, software, bandwidth, data feeds and other services. Contact us to talk about sponsorship opportunities if you believe there is a way your company can help.

Since our last application and database restart on 10th February 2012, we have identified around 130.000 incidents in 3000 different networks (based on AS). By informing the responsible security departments in a standardized way (via easy to process X-ARF complaint) with all relevant data to resolve the issue on their end, C-SIRT was able to generate and publish some statistics about the take-down-practices of the involved abuse departments.

As our infrastructure is in idle mode all the day, and can’t get enough URLs to check and verify, we are looking for more URL data to proceed!

Our scanners are really hungry. So feed them. To do so, please get in contact with us: sitesecurity@cyscon.de!

1. AS32244 resolves reported malware/phishing issues in an average take-down time of 269 hours
2. AS14618 resolves reported malware/phishing issues in an average take-down time of 261 hours
3. AS26496 resolves reported malware/phishing issues in an average take-down time of 193 hours
4. AS33182 resolves reported malware/phishing issues in an average take-down time of 168 hours
5. AS28753 resolves reported malware/phishing issues in an average take-down time of 178 hours
6. AS32613 resolves reported malware/phishing issues in an average take-down time of 169 hours
7. AS16276 resolves reported malware/phishing issues in an average take-down time of 157 hours
8. AS32475 resolves reported malware/phishing issues in an average take-down time of 157 hours
9. AS33626 resolves reported malware/phishing issues in an average take-down time of 155 hours
10. AS16626 resolves reported malware/phishing issues in an average take-down time of 154 hours
11. AS26347 resolves reported malware/phishing issues in an average take-down time of 151 hours
12. AS21844 resolves reported malware/phishing issues in an average take-down time of 147 hours
13. AS36351 resolves reported malware/phishing issues in an average take-down time of 142 hours
14. AS8972 resolves reported malware/phishing issues in an average take-down time of 138 hours
15. AS21788 resolves reported malware/phishing issues in an average take-down time of 132 hours
16. AS6724 resolves reported malware/phishing issues in an average take-down time of 132 hours
17. AS16265 resolves reported malware/phishing issues in an average take-down time of 131 hours
18. AS8560 resolves reported malware/phishing issues in an average take-down time of 128 hours
19. AS24940 resolves reported malware/phishing issues in an average take-down time of 115 hours
20. AS46606 resolves reported malware/phishing issues in an average take-down time of 109 hours