Jump to content

RobiBue

Membera
  • Content Count

    229
  • Joined

  • Last visited

Everything posted by RobiBue

  1. I use (since recently because it handles https as well) https://www.webconfs.com/http-header-check.php for redirects... Used to use Sam Spade, but sadly, it doesn't handle https well, still use Sam Spade for other stuff, but just like NetDemon, it's not maintained anymore...
  2. to Amazon I would writethe following (adding the spam at the end): you are harboring a spamvertised porn site: spamvertised link: http://se2. mogenromance-svenska. club/ redirects as follows: HTTP/1.1 302 Found => Server => nginx Date => Sat, 09 Mar 2019 07:04:17 GMT Content-Type => text/html; charset=utf-8 Content-Length => 75 Connection => close Location => https:// crazytrackings. com/ ?a=100225&c=102723&s1=232 X-Served-By => Namecheap URL Forward HTTP/1.0 302 Found => Cache-Control => private Content-Length => 226 Content-Type => text/html; charset=utf-8 Date => Sat, 09 Mar 2019 07:04:42 GMT Location => https:// cyberblueberry. com/ ?a=100225&c=102723&s1=232&ckmguid=5eaf0d44-97f6-419a-bf50-4dc7daa946ba HTTP/1.0 302 Found => Cache-Control => private Content-Length => 250 Content-Type => text/html; charset=utf-8 Date => Sat, 09 Mar 2019 07:05:03 GMT Location => https:// kewkr. girlstofu**. net/ c/da57dc555e50572d?s1=12951&s2=153430&s3=100225&s5=&click_id=22381729&j1=1&j3=1 P3p => CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT" Set-Cookie => c100916=B0u1wB9CbYmmbLsSFz+i2AKhvFRakvmMJc94KAGrH+9633KgqJ4kxg==; domain=.cyberblueberry.com; expires=Mon, 08-Apr-2019 07:05:04 GMT; path=/; HttpOnly HTTP/1.1 200 OK => Server => nginx Date => Sat, 09 Mar 2019 07:05:24 GMT Content-Type => text/html; charset=UTF-8 Content-Length => 12475 Connection => close Set-Cookie => scriptHash=49415_12951_153430; expires=Mon, 08-Apr-2019 07:05:24 GMT; Max-Age=2592000; path=/; HttpOnly X-Powered-By => PHP/7.0.32 and this last redirect is on IP address Host kewkr. girlstofu**. net (checking ip) = 34.194.20.115 whois -h whois.arin.net 34.194.20.115 ... [...] NetRange: 34.192.0.0 - 34.255.255.255 CIDR: 34.192.0.0/10 NetName: AT-88-Z NetHandle: NET-34-192-0-0-1 Parent: NET34 (NET-34-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Amazon Technologies Inc. (AT-88-Z) RegDate: 2016-09-12 [...] OrgAbuseHandle: AEA8-ARIN OrgAbuseName: Amazon EC2 Abuse OrgAbusePhone: +1-206-266-4064 OrgAbuseEmail: abuse@amazonaws.com OrgAbuseRef: https://rdap.arin.net/registry/entity/AEA8-ARIN [...] I believe this is your IP space. please enforce your AUP. offending message with munged headers follows (and I always munge the headers with my name and address since I send it from a dedicated spam reporting email address which is in name and address different from any other) and see if they say that it's not their IP space
  3. Ever wanted to follow the http or https headers but not visit potentially dangerous websites? here I found a perfect toy: https://www.webconfs.com/http-header-check.php for example, today I received a sex-spamvertised email (no need to post the tracking URL, as here I'm only interested in the redirects that the spammer goes through) so in the spam I have the following html line (without the spaces, so that nobody damages their computer by following the link): <a href="https: //bit.ly/ 2IQVHa2"> I enter the address in the text box, and receive the following result: HTTP/1.1 301 Moved Permanently => Server => nginx Date => Wed, 06 Mar 2019 05:00:02 GMT Content-Type => text/html; charset=utf-8 Content-Length => 139 Connection => close Cache-Control => private, max-age=90 Content-Security-Policy => referrer always; Location => http: //trk.linoaura.com/ c/ 1a57c646b0bf375e?src=issam Referrer-Policy => unsafe-url Set-Cookie => _bit=j26502-4d7f647156d7ea24c4-00y; Domain=bit.ly; Expires=Mon, 02 Sep 2019 05:00:02 GMT oh, Referrer-Policy => unsafe-url !!! (again, the location with spaces to prevent someone to inadvertently follow the link) so I enter that Location => link into the box and get: HTTP/1.1 302 Found => Server => nginx Date => Wed, 06 Mar 2019 05:05:45 GMT Content-Type => text/html; charset=UTF-8 Content-Length => 0 Connection => close Location => https: //lintwor.com /198f1cdb040fb11800 //aijxs5c7f55298ff4e752045131/ Set-Cookie => tid=aijxs5c7f55298ff4e752045131; path=/; HttpOnly Status => 302 Found yet another redirect (I again added spaces) so I follow that one: HTTP/1.1 200 OK => Date => Wed, 06 Mar 2019 05:08:39 GMT Content-Type => text/html; charset=UTF-8 Content-Length => 133 Connection => close Server => Apache Set-Cookie => uid9599=814165625-20190305230839-05d567ed43eab684d1ec95bd5d3f4aff-; expires=Sat, 06-Apr-2019 04:08:39 GMT; Max-Age=2674800; path=/ end station HTTP/1.1 200 OK => so all I need to do now, is get the IP for the last domain with netDemon, SamSpade, or just a simple ping from the cmd line, and send manual complaints with my specific anti-spam email to abuse[at]name.com (since they are the registrar for the domain) and nforce.com: who is the administrative IP block owner of spamvertised IP address as well as knownsrv.com: who is the owner of IP block of spamvertised IP address the latter two found in the RIPE db with the IP address from the ping.
  4. RobiBue

    http/https header check

    Hi MIG, with re to the first q, no, it wasn’t then. It is now, though, but bit.ly already removed their link shortcut, so the original spam link wouldn’t work anyway. i do have the feeling, hat my complaint to name.com, nforce and knownsrv was fruitful since the spammer had to change their link redirect to your latter q: Let’s start with sc on lintwor.com: https://www.spamcop.net/sc?track=lintwor.com there i get both, IP address and reporting/abuse address. now i’m Not done, as I want to make sure that I don’t just email the spammer, so I look up the ripe.net db: https://apps.db.ripe.net/db-web-ui/#/query?searchtext=194.145.208.166%23resultsSection gives me more or less the same info, but at the end of the page, I see MNT-NFORCE entry, so I check there https://apps.db.ripe.net/db-web-ui/#/lookup?source=RIPE&key=MNT-NFORCE&type=mntner and in the end decide also to contact the admin-c entry listed. that’s how I got name.com, knownsrv and nforce And as you can see by the absence of the last redirect the way I had it at the beginning, something worked
  5. if you click on the top [Report spam] "tab" it should reload the page without the current spam, just the empty report box but possibly with the following : is the Remove all unreported spam link missing, but the Report Now link there?
  6. 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
  7. 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.
  8. 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.
  9. Cache refresh disabled to avoid rate-limiting of whois servers [refresh cache] $ whois NET-3-128-0-0-1@whois.arin.net [whois.arin.net] ERROR 503: Unable to service request due to high volume. hmmm interesting.... in the end, although it would go to /dev/nul for amazonaws, it can't find an owner now... No reporting addresses found for 3.208.7.29, using devnull for tracking.
  10. that, as far as I know, is no longer needed to be done since the SC v5 update. The gmail problem was solved with the update. Outlook (hotmail, et.al.) is still not fixed though, but that is definitely on their end...
  11. Oooh! This last part means that RIPE is blocking ironport/SpamCop/Cisco from accessing their Whois database... now that’s bad.
  12. RobiBue

    Any point in reporting spam from AMAZONAWS?

    yeah, pretty sure there's money involved. if someone complains they'll probably slap them on their wrist... if too many complain, they'll probably close the account, but the spamvertiser can easily open a new account and start anew...
  13. RobiBue

    Spamcop forum doesn't use HTTPS?

    First, why https for the forum? There is nothing going on that needs extra encryption overhead. At least not that I know of. Besides, https doesn't necessarily mean secure: Heartbleed vulnerability? Second, unless it's bank or credit card related, I hate every place that requires me to have a 2-step verification. Google or otherwise. Besides, even a place that has 2-step verification can get hacked and the information stolen... google plus rings a bell... oh, right, google authentication... While the spamposts are annoying if you are up before Lking, they are easy to spot and overlook (or just mark them as read - I also mark them as spam while I'm at it)
  14. RobiBue

    "No body text provided" with Bcc: header

    As I mentioned in my previous message, I did a test between Yahoo! and GMail with Bcc: header test. Here the "munged" but true header results: Outgoing test message with Bcc: from Yahoo!: ------------------------------------------- Date: Thu, 21 Feb 2019 15:57:40 +0000 (UTC) From: RobiBue <MyFakeYahooAccount@yahoo.com> Bcc: "RobiBue" <MyFakeGMailAccount@gmail.com> Message-ID: <1883948137.3003972.1550764660065@mail.yahoo.com> Subject: test with Bcc: address MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3003971_1789674874.1550764660064" References: <1883948137.3003972.1550764660065.ref@mail.yahoo.com> X-Mailer: WebService/1.1.13123 YMailNorrin Mozilla/5.0 (Windows NT 6.1; WOW64; rv:67.0) Gecko/20100101 Firefox/67.0 Content-Length: 505 The above outgoing message (in the sent folder) shows that the Bcc: was there when it left the Yahoo! mailbox. Next comes the GMail inbox part: incoming test message in GMail (removed arc seal and other long winding headers in the middle): ----------------------------------------------------------------------------------------------- Delivered-To: MyFakeGMailAccount@gmail.com Received: by 2002:a0c:9de7:0:0:0:0:0 with SMTP id p39csp979189qvf; Thu, 21 Feb 2019 07:57:44 -0800 (PST) X-Google-Smtp-Source: AHgI3IZpr/3XS19bX4AwkcuhfNfYJk7Gk3+ZDjldlb8JVrbDaiU3jh2zVZyJNu8Lr6TtSb9PrFN8 X-Received: by 2002:a37:a407:: with SMTP id n7mr27806250qke.46.1550764664718; Thu, 21 Feb 2019 07:57:44 -0800 (PST) Return-Path: <MyFakeYahooAccount@yahoo.com> Received: from sonic312-20.consmr.mail.bf2.yahoo.com (sonic312-20.consmr.mail.bf2.yahoo.com. [74.6.128.82]) by mx.google.com with ESMTPS id p1si2743950qtp.365.2019.02.21.07.57.44 for <MyFakeGMailAccount@gmail.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 07:57:44 -0800 (PST) Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Thu, 21 Feb 2019 15:57:44 +0000 Date: Thu, 21 Feb 2019 15:57:40 +0000 (UTC) From: RobiBue <MyFakeYahooAccount@yahoo.com> Message-ID: <1883948137.3003972.1550764660065@mail.yahoo.com> Subject: test with Bcc: address MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3003971_1789674874.1550764660064" References: <1883948137.3003972.1550764660065.ref@mail.yahoo.com> X-Mailer: WebService/1.1.13123 YMailNorrin Mozilla/5.0 (Windows NT 6.1; WOW64; rv:67.0) Gecko/20100101 Firefox/67.0 Content-Length: 505 As you can see, the Bcc: seen in the outgoing message was dropped, as it is not expected nor needed. Next, I reply (with Bcc:) to the above message (keep in mind that I am only showing the headers to keep it concise: outgoing reply to test message from GMail: ------------------------------------------ MIME-Version: 1.0 Received: by 2002:a0c:acd6:0:0:0:0:0 with HTTP; Thu, 21 Feb 2019 08:00:49 -0800 (PST) Bcc: RobiBue <MyFakeYahooAccount@yahoo.com> In-Reply-To: <1883948137.3003972.1550764660065@mail.yahoo.com> References: <1883948137.3003972.1550764660065.ref@mail.yahoo.com> <1883948137.3003972.1550764660065@mail.yahoo.com> Date: Thu, 21 Feb 2019 10:00:49 -0600 Delivered-To: MyFakeGMailAccount@gmail.com Message-ID: <CABr3MG+L8J5N2tp5bWir+PyrYOeo5aJs=XsfDeKqROayovyTRQ@mail.gmail.com> Subject: Re: test with Bcc: address From: RobiBue <MyFakeGMailAccount@gmail.com> To: undisclosed-recipients:; Content-Type: text/plain; charset="UTF-8" and Yahoo! receives the following: incoming reply from GMail in Yahoo!: ------------------------------------ X-Apparently-To: MyFakeYahooAccount@yahoo.com; Thu, 21 Feb 2019 16:00:51 +0000 Return-Path: <MyFakeGMailAccount@gmail.com> Received-SPF: pass (domain of gmail.com designates 209.85.160.178 as permitted sender) X-Originating-IP: [209.85.160.178] Authentication-Results: mta4039.mail.bf1.yahoo.com header.i=@gmail.com; header.s=20161025; dkim=pass (ok) Received: from 127.0.0.1 (EHLO mail-qt1-f178.google.com) (209.85.160.178) by mta4039.mail.bf1.yahoo.com with SMTPS; Thu, 21 Feb 2019 16:00:50 +0000 Received: by mail-qt1-f178.google.com with SMTP id z25so10287996qti.13 for <MyFakeYahooAccount@yahoo.com>; Thu, 21 Feb 2019 08:00:50 -0800 (PST) X-Received: by 2002:ac8:2bc1:: with SMTP id n1mr31583604qtn.176.1550764849978; Thu, 21 Feb 2019 08:00:49 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a0c:acd6:0:0:0:0:0 with HTTP; Thu, 21 Feb 2019 08:00:49 -0800 (PST) In-Reply-To: <1883948137.3003972.1550764660065@mail.yahoo.com> References: <1883948137.3003972.1550764660065.ref@mail.yahoo.com> <1883948137.3003972.1550764660065@mail.yahoo.com> From: RobiBue <MyFakeGMailAccount@gmail.com> Date: Thu, 21 Feb 2019 10:00:49 -0600 Message-ID: <CABr3MG+L8J5N2tp5bWir+PyrYOeo5aJs=XsfDeKqROayovyTRQ@mail.gmail.com> Subject: Re: test with Bcc: address To: undisclosed-recipients:; Content-Type: text/plain; charset="UTF-8" Bcc: MyFakeYahooAccount@yahoo.com Content-Length: 82 As you can see, Google leaves the Bcc: in the headers (although I didn't test it, but I believe if I had more bcc addresses there, only the end recipient getting the message would be listed alone) I do note, that if the Content-Length: header wouldn't have been added, the Bcc: line would have been at the bottom and with it, SC would have trimmed the body off, but it's there, and SC parses it for me. To recap: if you have a Bcc: cutting off the body in SC, remove the Bcc: as it's not needed anyway and nobody expects it to be there anyway.
  15. RobiBue

    "No body text provided" with Bcc: header

    while I admit, that the "test" message gets the message body stripped if the Bcc: header line is the last one, I do have a question: Is there an email software that actually does send/receive the Bcc: header as the last line? I tried gmail and yahoo. sending from yahoo to gmail, the bcc header was not the last header line and it works. Sending from yahoo to gmail, the bcc header got removed, so it worked as well. While I understand that there is a problem with the parser, and believe me, it's by far not the only one, the workaround is to remove the bcc header before submitting. Since bcc headers are not expected to appear in headers according to rfc2822, it doesn't matter if the spam is reported without it anyway.
  16. RobiBue

    "No body text provided" with Bcc: header

    Please forgive my ignorance here, but I've never seen receiving headers with bcc in them... afaik they get stripped by the sending mail host and never shown to any recepient. ok, after reading rfc2822 section 3.6.3, I stand corrected that there might be mail software that includes a bcc: header to the recipient. BUT after running a test with case 2 but using a "validly formed" email address, it parses correctly for me... https://www.spamcop.net/sc?id=z6523542341z5a77154fb65b822d44a3e26a007ad52dz
  17. the SC forum software inserts the underscore to prevent spamers/scammers/hackers to run <java s c r i p t> either remotely or locally on the servers or the hosts. it's a security feature
  18. I've had some of those, but when I go to the past reports history, I see: Submitted: 2/8/2019, 8:19:08 PM -0600: Notice: Please verify your address "x" zoid_binding: sp1_ms2_120 No reports filed and of course, I have deleted the spam already... so, even if I wanted to, I couldn't, as SC doesn't let me, if you know what I mean...
  19. RobiBue

    SC parser: average reporting time

    psst 🤫 it's known to be faulty, and has been for ages 🙄 (see this reply ) I just look at it and say "cool" and move on
  20. FYI reporting that specific address (the one given in the "obviously" fake received s.okazik.pl header) is pointless and makes no sense. all it is, is a fake injected header line by the spammer or by the spammer software. the actual Received: header line is Received: from fervently.site (fervently.site. [103.1.12.91]) by mx.google.com with ESMTP id c16si308648pgh.545.2019.02.09.06.43.54 for <x>; Sat, 09 Feb 2019 06:43:54 -0800 (PST) Received-SPF: temperror (google.com: error in processing during lookup of return@asciidic.com: DNS error) client-ip=103.1.12.91; Authentication-Results: mx.google.com; spf=temperror (google.com: error in processing during lookup of return@asciidic.com: DNS error) smtp.mailfrom=return@asciidic.com but as you can see, even Google mail sees a DNS problem with that IP address. everything below these headers in the original spam is injected by the spammer's software
  21. sorry to hear that. hope y'all are ok though. btw I wasn't expecting a reply, just passing information I find for the good of everyone if someone does have info that doesn't support my theory, I would gladly look at it from a different objective standpoint. 🔭🔍🔬
  22. yeah, that's why I'm saying, I believe that injected Received line acts somewhat as a signature placed there by the designer of the malware... that IP might, at one time, have been assigned there... I don't know if there is a historical IP database available but I understand now what you meant. thanks.
  23. hehe I noticed, on google maps, that okazik.pl is a fully "blacked-out" 24h internet c@fe in a Polish city called Poznań, right between Berlin and Warsaw... might even be the home of the original developer of the spamming malware...
  24. Sorry, could you explain what you mean here? other language maybe? Deutsch? Español? Italiano? Français? Portugues? I Know that the spammer is placing this there. or at least the software he uses. that's why I said that whoever wrote the spammer's software it is using it as some kind of a signature. maybe to see how many different spammers are using his software...
  25. refresh/show shows the right address now sometimes (I learned this just recently) you have to hit the refresh/show link to refresh the cache...
×