Spamcop not finding link in encoded message

[MisterBill]

I've recently managed to get one of my email addresses added to a spammer's list, getting several piece a day, generally for bogus medical cures.  The emails always have an encoded body and it appears that Spamcop is not decoding it and finding the link that is part of it. When I opened a recent email (and obviously not showing the image), I saw

 

Who knew you could regular blood sugar this easy
You May Safely Display Content of Message

and the second line is a link to http://131. 107.193.85joanny.info.boyman.space/205/3-2-2019-clickersin (space added after the first dot to  break the link)

Yet when I feed the email thru Spamcop, it doesn't find or report on the link. Has the spammer adjusted their behavior so that Spamcop cannot pick up and report the email to their host? In this case, the report is only going to network-abuse@google.com (where the email apparently originated from), which I'm assuming isn't doing anything about it. 

Edited March 2, 2019 by MisterBill

[RobiBue]

I am thinking that spamcop has disabled the parsing of links in the newest update.

Not sure about it though, but I haven't had any links parsed by SC since then.

 

[Lking]

1 hour ago, RobiBue said:

I am thinking that spamcop has disabled the parsing of links in the newest update.

FYI I just ran this spam. https://www.spamcop.net/sc?id=z6526524883z1d0a6302930f617dfedab5cc450aa8c3z

The report section includes

Quote

Re: http://www.strongskills.net/6656N2F3r95Sp8S613F... (Administrator of network hosting website referenced in spam)

 

[MisterBill]

Good idea to include a SC link with the contents of the email. Here's one of mine so folks can see what the mail looks like.

https://www.spamcop.net/sc?id=z6526542656z686e6200afbb5e1b095fea9160ee8108z

Edited March 2, 2019 by MisterBill

[Lking]

MisterBill, SC does not always take the time to look at the body of the spam.  Remember looking for links in the body of spam is the lowest priority task for the parser.  The added time to decode the body may the reason at the time you submitted this (or other) examples.

[lisati]

3 hours ago, MisterBill said:

and the second line is a link to http://131. 107.193.85joanny.info.boyman.space/205/3-2-2019-clickersin (space added after the first dot to  break the link)

 

It might not mean much but even if there wasn't the added space, my minimal parsing skills want to add a forward slash after what looks like an IPv4 address.

Time for me to wander off and enjoy my freshly made coffee.

[MisterBill]

29 minutes ago, lisati said:

It might not mean much but even if there wasn't the added space, my minimal parsing skills want to add a forward slash after what looks like an IPv4 address.

Good point, but if you try going to the site (without the stuff after the first slash) it actually is a valid address.

Edited March 2, 2019 by MisterBill

[MisterBill]

55 minutes ago, Lking said:

MisterBill, SC does not always take the time to look at the body of the spam.  Remember looking for links in the body of spam is the lowest priority task for the parser.  The added time to decode the body may the reason at the time you submitted this (or other) examples.

I'm pretty sure it used to de-obfuscate hidden links like that. It was a way to beat spammers who resorted to stuff like that.

https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/bom-obfuscation-in-spam/

The good news is that AOL is still picking it up as spam. Bad news is that whenever I went to the spam folder previously, it was false positives. Now it's mostly this crap.

Edited March 2, 2019 by MisterBill

[Lking]

20 minutes ago, MisterBill said:

I'm pretty sure it used to de-obfuscate hidden links like that. It was a way to beat spammers who resorted to stuff like that.

I did not say they never do check for links.  What I meant was some times the parser does not take the time.  At the decision was being made to look at the body or not, the load due to processing other higher priority task may preclude doing the work to fine links, even simple ones.  At other times of lighter load the parser may dig deeper. The timing of the parser is a black box.

[MIG]

Hello MisterBill,

Additional to all of the above (from verified Masters) & particularly if, when I parse spam via SC, if it doesn't "diagnose" embedded links, I use Virus Total. 

Referring specifically to http://131space.107.193.85joanny.info.boyman.space/205/3-2-2019-clickersin

[VT result]  https://www.virustotal.com/#/url/98a7e1fda3fdb40f9b964a20315257fcbd180c2d1807b5bc8630a1dbbc7762ca/details

[https://www.virustotal.com/#/ip-address/69.42.218.2

then, ('cause I'm only a grasshopper ) I hop across to: 

[TALOS] https://www.talosintelligence.com/reputation_center/lookup?search=69.42.218.2#whois

--------------------------

Apropo to Lking's [GrandMaster status I believe] last post, sometimes, if I cancel the parsed results, clear browser cookies, cache & history, re-parse, a more accurate outcome may be presented.

It's Sunday, grasshoppers don''t drink coffee, nevertheless other mundane tasks await.

Cheers!

 

Edited March 2, 2019 by MIG

[MisterBill]

21 hours ago, MIG said:

Apropo to Lking's [GrandMaster status I believe] last post, sometimes, if I cancel the parsed results, clear browser cookies, cache & history, re-parse, a more accurate outcome may be presented.

 

Couldn't you just cancel the processing and resubmit the email? What significance does clearing the browser cookies have?

 

BTW I tried submitting it via e-mail figuring maybe it would take the time to process the body, same result.

[MIG]

3 hours ago, MisterBill said:

1. Couldn't you just cancel the processing and resubmit the email?

2. What significance does clearing the browser cookies have?

3. I tried submitting it via e-mail, same result.

4. "the second line is a link to http://131. 107.193.85joanny.info.boyman.space/205/3-2-2019-clickersin (space added after the first dot to  break the link)"

Hello MisterBill,

1 & 2:

Absolutely, however, if, after the 1st, 2nd etc. parse, the results are the same., i.e. not what's expected/desired, fully clearing/swapping browser/s "sometimes" may result in a different/desired outcome.

SpamCop imbeds cookies (like every www), flushing may help; bit like a dunny😄! 

• If fully resetting any browser, always remember to save/export settings & bookmarks prior to reset.

3. Could we have the SpamCop report URL please or is it the SpamCop report URL you've already shared?

4. In the original received email do you actually see "http://131. 107.193.85joanny.etc" or is that url visible if the mouse is hovered over a image/imbedded link?

• Do you have another received spam email with the same issues & subsequent SpamCop parser results please?

Cheers!

 

[RobiBue]

The address is in the parsed email.

Clicking on the link below the headers “View entire message” will reveal a base64 block which can be decoded with online tools like:

https://www.base64decode.org/

 

Just paste the whole block (including the last = sign) and vióla! The entire body of the spam including those seemingly obfuscated addresses...

148. 253. 73. 95ashlee . org . perske . club / 204 / 3-2-2019-clickersin
 ^    ^    ^      ^       ^       ^       ^     ^            ^
 |    |    |      |       |     domain   TLD    |            |
 •————————————————————————•                     •————————————•
         subdomains                                  paths

But they aren’t really obfuscated addresses. They are real, the way they are written.

[MIG]

15 minutes ago, RobiBue said:

The address is in the parsed email.

Clicking on the link below the headers “View entire message” will reveal a base64 block which can be decoded with online tools like:

https://www.base64decode.org/

 

Just paste the whole block (including the last = sign) and vióla! The entire body of the spam including those seemingly obfuscated addresses...

148. 253. 73. 95ashlee . org . perske . club / 204 / 3-2-2019-clickersin
 ^    ^    ^      ^       ^       ^       ^     ^            ^
 |    |    |      |       |     domain   TLD    |            |
 •————————————————————————•                     •————————————•
         subdomains                                  paths

But they aren’t really obfuscated addresses. They are real, the way they are written.

Wide eye'd admiration RobiBue, impressive! 

And thanks! You've given grasshopper a new toy!

Happy happy  joy  joy!

Cheers!

[MisterBill]

17 hours ago, RobiBue said:

 

But they aren’t really obfuscated addresses. They are real, the way they are written.

 

Thanks for the info on decoding the message.  And maybe it's not obfuscation in the strict definition of the word but it's not in clear text. And the bottom line is that Spamcop is not recognizing and reporting on it, for whatever reason that may be.

[RobiBue]

I hear you MisterBill, and I understand the frustration when the fight with spammers is being hindered by the own tools that are supposed to help.

I used to be adamant with regard to submitting the links, but eventually I realized that, even though most links are spammer's own links or redirects to them, or even redirects to redirects... and so on and so forth... some links are third party links that
a) have nothing to do with the spam, or
b) are being used as retaliatory measures to get them in trouble.

why this spam isn't parsing the links, unfortunately, I do not know.

entering the address directly into the SC parser works and gives you the abuse address if you want to submit it manually.

https://www.spamcop.net/sc?track=http://148.253.73.95ashlee.org.perske.club/204/3-2-2019-clickersin

[gnarlymarley]

On 3/4/2019 at 1:16 PM, RobiBue said:

why this spam isn't parsing the links, unfortunately, I do not know.

 

On 3/2/2019 at 1:37 PM, MisterBill said:

Here's one of mine so folks can see what the mail looks like.

https://www.spamcop.net/sc?id=z6526542656z686e6200afbb5e1b095fea9160ee8108z

MisterBill,

I can see Base64 decoding works, but I also noticed that when there are no links, i see the following output.  I am thinking this might be in part the cause why it is it is not finding the links is that maybe something in the headers tells it not to check.

The following from: https://www.spamcop.net/sc?id=z6518576003zacb0684ecc1a3a9c08ea7d4865cd6840z

 

Quote

Finding links in message body

Parsing text part
no links found

 

[MisterBill]

On 3/6/2019 at 8:53 AM, gnarlymarley said:

 

MisterBill,

I can see Base64 decoding works, but I also noticed that when there are no links, i see the following output.  I am thinking this might be in part the cause why it is it is not finding the links is that maybe something in the headers tells it not to check.

 

 

Except that I am not seeing that message, and there obviously is a link in my mail body.

 

BTW after sending the URL thru Spamcop and getting the abuse address, I added it as the "Public standard report recipients" option in Spamcop.  I selected that address to get a couple of reports of the spam sent to them (it's not checked by default) and included some comments in one of the reports. Knock on wood and all that, but it's been two days since the last piece of spam was received, and I was getting at least 5 per day. So maybe it did something to at least get my address removed (not sure if the URL was personalized and they would have known who the report came from, I guess it would have to be to be removed, unless they actually shut down the spammer).

Edited March 8, 2019 by MisterBill

[Dilbertic]

Seems this spammer has found another way around fooling spamcop processing engine, this time his headers are somehow fooling spamcop to by pass the main body and the links won't be processed so they can be reported:

https://www.spamcop.net/sc?id=z6532463121z4c0bbe7b8deabc530d29d6bb703fbdf9z

[Lking]

I don't think the header is causing the issue. the email body html contains several html format errors that may be the reason for not finding link.

The errors are simple, and a email app or web email would not dough "forgive" the sender and try to display the links in the email body.

The parser on the other hand MUST be sure that spam reports that are send are valid. Guessing what was meant could result in bogus spam reports.

JMHO

[MIG]

6 hours ago, Dilbertic said:

Seems this spammer has found another way around fooling spamcop processing engine, this time his headers are somehow fooling spamcop to by pass the main body and the links won't be processed so they can be reported:

https://www.spamcop.net/sc?id=z6532463121z4c0bbe7b8deabc530d29d6bb703fbdf9z

Hey Dilbertic (haven't thought of Dilbert for a long time!)

The spam you've submitted looks like you're using Outlook? If yes, for all Outlook spam mail, it's helps to remove the first header: 

Received: from DB5EUR03HT210.eop-EUR03.prod.protection.outlook.com
(2603:10b6:a02:a8::32) by BYAPR02MB4678.namprd02.prod.outlook.com with HTTPS
via BYAPR03CA0019.NAMPRD03.PROD.OUTLOOK.COM; Sat, 23 Mar 2019 09:44:15 +0000

The rationale has been explained as follows:

quote: "A couple of years ago Hotmail had to give up two /16 networks they were using (33,554,432 IP addresses) as they were not assigned to them.  MS had to quickly reconfigure their network and used IPv6 to do so. Unfortunately when doing so, they did not do it carefully and make sure they had full name resolution through out the network, where the forward 
and reverse dns on each server matches.  This means SC can't trust their headers and will often take them as the source of the spam. All is not lost though, as Hotmail's parsing engines when they receive the report does pass through the report to the right party.  It also helps Hotmail block new spam from that source. Microsoft is working on resolving the issue, but it is a couple of 
hundred thousand servers.  They have told us though the fix is measured in years, not weeks or months. " unquote

Using that method results in:

https://www.spamcop.net/sc?id=z6532518175z606177e0f3002ed2e1fb3026a6814020z which may not be a happy result as source is one of a frequently complained about:  amazonaws & it's dev nulled; there's much Forum commentary about how many approach this particular source. 

-------------------------------------------------------------------------------------------------------

Addressing the links issue you've raised, I agree with Lking aka Master,  twud be a dead grasshopper if I didn't!  & confirmed with a code analyzer, don't know enough about coding to work out how to "fix" so SC parser generates a true result, sorry!

Cheers!

Edited March 24, 2019 by MIG

[gnarlymarley]

MisterBill,

I think I found the issue.  I took your spam and submitted it with one header change

https://www.spamcop.net/sc?id=z6533324339z74dcc1bd7d7a1f5d7cd9d6b0c6410d96z

I changed:

Content-Type: multipart/alternative; boundary="B_ALT_"

to this:

Content-Type: text/plain; charset="windows-1252"

From what I know of the message format, the boundary is missing from the message body as defined by the Content-Type.  The type multipart/alternative means that there should be part of the body as text and part as html.  Rather than change the Content-Type like I did.  Maybe you could figure out how to find both types of the body so that you can properly report the full body.