Jump to content

DRSpalding

Members
  • Posts

    38
  • Joined

  • Last visited

Everything posted by DRSpalding

  1. % Information related to '193.27.228.0 - 193.27.228.255' % Abuse contact for '193.27.228.0 - 193.27.228.255' is 'info@starcrecium.com' inetnum: 193.27.228.0 - 193.27.228.255 netname: CY-STARCRECIUM country: RU org: ORG-SL1012-RIPE admin-c: SL13896-RIPE tech-c: SL13896-RIPE status: ASSIGNED PA mnt-by: IP-RIPE created: 2019-12-18T15:04:50Z last-modified: 2020-12-14T21:28:15Z source: RIPE
  2. Abuse contact for '43.228.72.0 - 43.228.75.255' is abuse[at]gazonindia.com, sourced from APNIC WHOIS. Current recipient is search-apnic-not-arin#apnic.net[at]devnull.spamcop.net.
  3. Abuse contact for '153.120.0.0 - 153.120.191.255' is abuse[at]sakura.ad.jp sourced from APNIC WHOIS. Current recipient is search-apnic-not-arin#apnic.net[at]devnull.spamcop.net.
  4. Abuse contact for '43.246.252.0 - 43.246.255.255' is 'ipv4bsnl[at]gmail.com' sourced from APNIC WHOIS. Current recipient is set to the usual search-apnic-not-arin#apnic.net[at]devnull.spamcop.net.
  5. From APNIC WHOIS, this net block should contact 'ipv4bsnl[at]gmail.com'. Currently, the net block is set to the fabulous 'search-apnic-not-arin#apnic.net[at]devnull.spamcop.net'.
  6. Abuse contact for '43.228.72.0 - 43.228.75.255' is abuse[at]chiraagcommunications.com SC currently giving search-apnic-not-arin#apnic.net[at]devnull.spamcop.net Found current data on APNIC WHOIS lookup for IP address 43.228.74.46 used to send spam this morning.
  7. Abuse contact for '139.175.0.0 - 139.175.255.255' is 'hostmaster[at]twnic.net.tw', from APNIC WHOIS data specifically as abuse mailbox. Currently, this range shows as 'search-apnic-not-arin#apnic.net[at]devnull.spamcop.net'
  8. Abuse contact for '139.167.0.0 - 139.167.255.255' is 'ip.abuse[at]ril.com' based on data from APNIC WHOIS. Currently, it is set to "search-apnic-not-arin#apnic.net[at]devnull.spamcop.net".
  9. Abuse contact for '47.11.0.0 - 47.11.127.255' is 'ip.abuse[at]ril.com'. Currently SpamCop shows "search-apnic-not-arin#apnic.net[at]devnull.spamcop.net". Abuse address retrieved from APNIC WHOIS data.
  10. Abuse contact for '47.11.128.0 - 47.11.255.255' is 'ip.abuse[at]ril.com'. Data from APNIC WHOIS. Currently, SpamCop comes up with 'search-apnic-not-arin#apnic.net[at]devnull.spamcop.net'
  11. Currently it comes up as the ol' "search-apnic-not-arin#apnic.net[at]devnull.spamcop.net". Based on APNIC WHOIS, it should be: Abuse contact for '47.247.0.0 - 47.247.255.255' is 'ip.abuse[at]ril.com'
  12. The website appears to be up and running now.
  13. If there is junk added in to a style sheet in the spam or other blatant filler to either add so many URLs that SpamCop gives up or pushes the size out beyond 50KB so that the actual payload URLs are deleted by truncating the message, I have started removing much of the repetitive junk out of the message to make it work. The spam I was receiving that did this routinely has now stopped, whether by filtering upstream from me or because they finally ran their run, but the URLs they were using were a much better target than the myriad 'bot sites being used to send it. So, I munged it myself, rationalizing that SpamCop would have "munged" it too, just at the end of the message and not in the middle like me.
  14. Yes, the website appears to be unavailable. Email submissions of spam attachments seems to work quite nicely though as I just sent in and very quickly received the reply, so it looks like the parsing and whatnot is working on the backend just fine. If you have enabled quick spamcop email reporting, it looks like you can at least report the senders of the spam. I'm trying that right now. Edit to add: Quick reporting worked just fine, according to the response that it sent a report like normal.
  15. Tracking URL: https://www.spamcop.net/sc?id=z6289054704z1ca8c0c6638bb944ad328cf46dd3ee00z This spam contains URLs that are not getting reported but SpamCop is noting the following: Resolving link obfuscation HTTP://dimo.site/0a9843a2f4fdfdb3cd243d65913/auto.php?9020321_hcywgultvlggov_1_track57_57_2_79206 Remove email parameters: HTTP://dimo.site/0a9843a2f4fdfdb3cd243d65913/auto.php HTTP://dimo.site/0a9843a2f4fdfdb3cd243d65913/auto.php?9020321_jeadarfaqcmadj_1_track57_57_2_79206 Remove email parameters: HTTP://dimo.site/0a9843a2f4fdfdb3cd243d65913/auto.php HTTP://dimo.site/unsub I do not know what that means, but I have modified the links to not include anything at all other than the domain name and resubmitted it, it doesn't emit that message but it still won't send a report. If you put one of the sites directly into the report spam form and submit it to see what happens, it does in fact parse it and would submit a report. What's it all mean?
  16. Spamvertised web site hosted at IP address 5.157.2.178. Per RIPE Whois: C:\Tmp> whois -h whois.ripe.net 5.157.2.178 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '5.157.2.0 - 5.157.2.255' % Abuse contact for '5.157.2.0 - 5.157.2.255' is 'noc@interconnects.us'
  17. I received a spam message via 217.60.218.149 today and reported it. SC sent report to abuse[at]sektornet.dk. I received back their notice: --- Hi This prefix has been transferred - please update your abuse information: Abuse contact info: abuse[at]rasana.net inetnum: 217.60.0.0 - 217.60.255.255 netname: IR-RASANA-20001101 country: IR org: ORG-ART1-RIPE admin-c: AA10926-RIPE tech-c: AA10926-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-by: MNT-RASANA mnt-lower: MNT-RASANA mnt-routes: MNT-RASANA created: 2016-05-11T11:09:51Z last-modified: 2016-06-09T11:44:32Z source: RIPE Kind regards Jesper Joensen Danish Ministry of Education The National Agency for It and Learning --- I took a look at the RIPE whois data and confirmed that what Jesper says appears to be correct.
  18. https://www.spamcop.net/sc?id=z6250422071z6edcfa3163cf7ddc87032aa5cce1a840z Let me know if the link gives you the information you need or not. I'll post the relevant headers if necessary. The Received lines after the X-Yahoo-* stuff are fakes/filler and the dates are being noted by SpamCOP and not allowing the spam to be reported even though the spam is quite fresh. Perhaps SpamCOP is thinking that these lines are legitimate internal hand-offs. However, it then continues and goes on to the following Received lines with external IP addresses in them and parsed out the abuse recipient of abuse at Hawaii.edu for 166.122.98.137 from what I am pretty sure are spammer inserted Received lines. It appears that this persistent set of spammers on Yahoo have been trying to get past SpamCOP reporting for awhile. First it was repeating large blocks of bogus text in the body to grow the message past 50kb and SpamCOP would chop off the shortened links (generally bit.ly or tinyurl.com) near the end of the message and now, putting in some rather shifty headers that fool SpamCOP. Can anything be done here? Can I edit the header to remove the bogus Received lines so that it will report it to Yahoo as it should? I hope that the spammer doesn't actually know that they have stumbled upon this technique, but for now, I will report by hand to Yahoo and cloudflare. Addendum: I received a nearly identically formed spam a bit later but it parsed correctly. The only meaningful difference to my eye was that the X-YMail-OSG block was a couple of lines shorter in the mail that parsed correctly.
  19. I use wget to traverse the redirects w/o downloading anything and then find the redirect site(s) in that mess. The output I generate looks like this, from the last one I received and reported just a while ago: 189.cn for t.cn: Note t.cn shortened URLs from this spam message noted below redirecting to spam sites or other shortening sites. http://t.cn/RUZXue0--> http://rlziw.com/welcome/ http://t.cn/RUZXuel--> http://www.rlziw.com/welcome/ http://t.cn/RUkTeT5--> http://milfaholic.ru/remove/ The guts of the scri_pt uses this command line: wget --spider -t 2 -T 10 --referer=www.rlziw.com[103.196.152.6]:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] 200 OK 
  20. I think that that could be the issue, but I see most spam messages that have multiple links in them get at least two links reported. I still think that there may be an issue with the links getting lost or overwritten in the back-end scripts because of their very close similarity with the same length and very close matching on their content as well. The main issue is that I end up cracking them manually with a scri_pt and adding the extra links to the reporting myself and I would like to not have to do that. I would be completely ok with a switch that indicated to SpamCop that I was ok with it taking more time so go ahead and inspect it deeper and slower if you have to, and a message saying it was too busy to accomplish the deeper parse, DNS lookups, and abuse address lookups necessary for the links.
  21. HI, I have seen for quite a long while (years) that SpamCop sometimes misses multiple t.co and t.cn shortened URLs in spam message bodies. This typically happens with one particular form of the spam that has three links in it and sometimes when there are two. Generally speaking, it gets the two URL version most of the time and the three URL version none of the time. Is SC simply making the call to not lookup links that are so similar when there are multiples in the spam or is there a parsing issue that leads SC to believe that there is only one link? It doesn't seem to have a pattern which link is chosen to be in the report as far as I can tell. Tracking URL: https://www.spamcop.net/sc?id=z6211131844z4e60e9f57f89dc944c58e921899e83ffz Thanks! - Dan
  22. You must have caught my message before I edited to correct the '&' to the proper '#' in the HTML literal character encoding. It should be "#064 ;".
  23. Not in my case. The phish attempts (or hook attempts, really--they just want the click, not the credentials) are not from LinkedIn, but messages that look like LinkedIn. It's funny that the '[at]' character with the spammer's "\#064;" (sans the backslash) HTML encoding that I placed in a code block so that it wouldn't be reinterpreted was converted somewhere along the way to another obfuscated form, with the "[at]" human readable encoding. If a moderator could edit it back to the way it was to be clear to anyone else that comes along, that would be great, since the one I am requesting a feature upgrade on is actually decodable via a HTML rendering.
  24. Hi, I have been seeing a bunch of LinkedIn phishing spam/scam mails that are using an email address that does not get munged in the reports. The email address is of the form: This email was intended for somebody#064;example.com I know it's a lot to ask, but I would really like it if those could be found and cleaned up too, along with the "somebody%40example.com" variant. I have also recently seen quite a few industriously devious spammers placing the recipient address as the "From:" address as well, which notably, SpamCop does not munge either. Both of these cases require me to a) be vigilant to them and b\) manual munging of email addresses. Can either of these issues possibly be addressed? Thanks! D.
  25. I disagree a bit on this, since the bot networks most spammers use are vast and have lots of nodes. The servers being spammed are either hacked sites or near-bulletproof hosted and are far fewer in number. Getting them off the net probably hurts them more than the disconnection or cleansing of a few of the bot nodes that sent the spam. In addition, I do the two steps myself now already and I would rather it be done in one shot. I don't like spending time doing it, but I also despise spammers and scammers. So, I do it for the greater good. Regardless, this is an interesting conversation to have.
×
×
  • Create New...