In the past two years or so, have you ever received a number of messages from a smishing scam (=SMS phishing), where you receive an SMS message from Amazon or your bank with a URL that, when tapped, sends you to a scam site? Well, I don’t think young people would fall for such a stupid scam, but the fact that it comes to me is annoying. You might be thinking, “How did they know my phone number? You might be thinking, “How did they know my phone number?” Well, it seems that criminals send out SMS at random (or in bulk with sequential numbers), so it just happened to reach your phone.

I’d like to analyze the modus operandi of these scammers and try to come up with a way to fight back. I hope you enjoy it half as much as Jordan did.

Actual scam SMS received

Look at the URL.” It says “https:abnrno.com”. No, it’s so uninspiring that you should at least put “amazon” in there somewhere. But I guess it doesn’t matter to old people, because they’ll just click on the URL without looking at it. And here’s what I found when I tapped the URL.

It’s an amazon login screen! It’s a scam where you enter your real amazon account into this and your personal information will be extracted. The real Amazon login screen is below, and it looks a little different.

Is there any information about scammers written anywhere?

The WHOIS command doesn’t seem to give any information about the owner of the domain. All I can tell is that the domain is owned by namesilo.com.

I typed dig and got the following information.

abnrno.com.    0   IN   A       172.67.142.151

I checked this IP and found it was the server location of CloudFlare. Of course, I can’t find any information about the owner of this site or domain. Well, if I could find out the owner of this site or domain, I’m sure the police would be working on it.

little research on phishing sites.

Next, let’s take a look at some of the sources of this phishing site.

<form method="post" action="../checklogin.php">
<h1 class="common-div">ログイン</h1>
<div class="common-div">
    <label>
        Eメールまたは携帯電話番号
    </label>
    <input type="text" name="email" maxlength="128" required="required">
</div>
<div class="common-div" style="margin-top: 25px">
    <input type="submit" class="submit-button" value="次へ進む">
</div>
<div class="common-div">
    続行することで、 Amazonの
    <a href="#">利用規約</a>
    および
    <a href="#">プライバシー規約</a>
    に同意するものとみなされます。
</div>
<div class="common-div">
    <a href="#">
        お困りですか?
    </a>
</div>
</form>

First of all, when you enter your email address and submit, you will see that it will be posted to “checklogin.php”. What’s interesting is that the other links, “Terms of Use” and “Privacy Policy”, are not linked to, so nothing happens when you press them. It’s so clean! They don’t care about anything other than login, they just want you to enter your email. What’s strange is that the input tag type is “email” even though it says “email or cell phone number”. If grandma and grandpa really tried to log in and put in their own phone numbers, they could have gotten that information. I wonder why they put such a restriction.

And the next screen was the following.

Here is part of the source for this screen.

<form method="post" action="../checklogin.php">
  <h1 class="common-div">ログイン</h1>
  <div class="common-div">
      [email protected]            <a href="index.php">変更</a>
  </div>
  <div class="common-div">
      <label style="float:left">
          パスワード
      </label>

      <a href="#" style="float:right">パスワードを忘れた場合</a>
      <input type="password" name="pwd" maxlength="128" required="required">
  </div>
  <div class="common-div" style="margin-top: 25px">
      <input type="submit" class="submit-button" value="ログイン">
  </div>
  <div class="common-div" style="font-size: 13px!important;">
      <input style="width: 13px;height: 13px;float:left" type="checkbox" name="remember" value="1">
      ログインしたままにする
      <a href="#">詳細</a>

  </div>
</form>

The password is also posted in the same checklogin.php file. If you enter the appropriate password, you will be redirected to the following screen.

I don’t need to show you the source of this screen. Everything except for entering the desired information is just a bunch of junk and none of the links work. In fact, the “You can’t access your account until you update it” part was pretty cheap looking.
And this is the next screen.

This is it. It’s the card information we’re looking for. Let’s try entering a dummy card, which is often used in credit card API implementations. This brings me to the next screen.

I did some research on this and found out that even though there are six credit card company icons displayed at the top of the screen, only some of the credit card companies seem to be accepting input. I don’t know what the “Web Service ID” and “Password” are, so I don’t think they usually let you enter any more. That means that when you reach this screen, your card information has already been obtained. (What you entered in the previous screen)

In addition, I’ve found the source code for the transmission of the card information in the previous screen, so I’ll post it here. By the way, under the law, it is illegal to obtain card information directly from a server operated by a service provider. So, it is illegal at this point. (I’m sure they’ll be fine with this since they’re already committing fraud.)

$.post("../checkcard.php", $("#cardinfo").serialize(),
    function(result) {
        if(result==="0"){
            setTimeout(function() {
                    $(location).attr("href", "vbv.php")
                },
                100);
        }else if(result==="3"){
            setTimeout(function() {
                    $(location).attr("href", "cardInfo.php?debiterror=1")
                },
                100);
        }else if(result==="2"){
            setTimeout(function() {
                    $(location).attr("href", "cardInfo.php?cvv_error=1")
                },
                100);
        }else{
            setTimeout(function() {
                    $(location).attr("href", "cardInfo.php?error=1")
                },
                100);
        }
    })

Is it possible to retaliate against a scam page?

There are a few things I’ve learned from my research so far. There are a few things I’ve learned so far, and this could be a weakness on the part of the scammer who created this phishing site.

• The SessionID of the cookie is sent at the time of Post of all forms.
• The browser (js) is checking whether the credit card is valid or not.
• Credit card information is being sent as is

Here’s one hypothesis. Supposedly, the scammer is saving the card information that has been entered and sent until above on this site. After that, the “secure authentication” screen comes up, but this authentication is not necessary for the scammer. The fraudsters don’t need this authentication, because the card information that has already been sent is likely to be correct.
However, you have to make sure in some way that the card information is really valid. Maybe you have to manually enter the information, or maybe you have to authorize it with the credit card API.
If we were able to send a large amount of unusable, non-identical card information, wouldn’t the fraudster be in trouble? In the case of manual verification, of course, but also in the case of credit card APIs, if a large number of failed authorizations are generated, won’t it be easier to trace them?

Credit Card Validation

I found the following part in the JS source. If the last true is returned, it seems to pass validation on the server.

if (/[^0-9 \-]+/.test(a)) return !1;
var c, d, e = 0, f = 0, g = !1;
if (a = a.replace(/\D/g, ""), a.length < 13 || a.length > 19) return !1;
for (c = a.length - 1; c >= 0; c--) d = a.charAt(c), f = parseInt(d, 10), g && (f *= 2) > 9 && (f -= 9), e += f, g = !g;
return e % 10 === 0

Don’t think about the details, but something like “65555555555554444” will pass. It seems to be OK to simply pass the above validation as well as a dummy number when implementing a general card payment API. Also, the validity of the name, expiration date, and security code is only minimally checked. In other words, it seems to be easy to make up appropriate card information in logic and pass the validation.

Submit credit card information

Next, I investigated the endpoint where the card information is sent.

• Access from IPs outside Japan is blocked.
• Error 403 if the information in the request header does not have the same structure as the one sent by the browser.

After some tinkering, I was able to POST using cURL. In the following, some of the values are not appropriate just in case, but I got a successful response as usual.

# cURLの例
curl -X POST -H "accept: */*" -H "accept-encoding: gzip, deflate, br" -H "cache-control: no-cache" -H "content-type: application/x-www-form-urlencoded; charset=UTF-8" -H "cookie: PHPSESSID=id" -H "origin: https://abnrno.com" -H "pragma: no-cache" -H "referer: https://abnrno.com/mobile/view/cardInfo.php" -H "sec-ch-ua: ' Not A;Brand';v='99', 'Chromium';v='96', 'Google Chrome';v='96'" -H "sec-ch-ua-mobile: ?1" -H "sec-ch-ua-platform: 'Android'" -H "sec-fetch-dest: empty" -H "sec-fetch-mode: cors" -H "sec-fetch-site: same-origin" -H "user-agent: Mozilla/5.0 (Linux; Android 10;) Hoge" -H "x-requested-with: XMLHttpRequest" -d "cardname=test&cardnum=1234123412341234&expyear=12&expmonth=2030&cvv=123" https://abnrno.com/mobile/checkcard.php

By the way, even if you need the transition data from the first screen for SessionID, the site is designed in such a way that it can be easily operated by robots.Reference

Would fraud be reduced if gave away a lot of credit card information?

Come on, I guess I can program the unusable card information and present it to you as a bot. This is a complete nuisance, but you’re the one who sent me the URL of an illegal phishing site without permission.
Well, I’m just writing this article as a pun, so I won’t do anything special. I’m not on the side of the national power, and I’m not even a victim. I’m not on the side of the state, and I’m not even a victim, but it occurred to me that the Internet fraudsters always want valuable personal information. And it’s hard for anyone to guarantee the validity of personal information. So, I thought that if we give away a lot of unvalidated personal information, the personal information that people have really been tricked into sending will be buried in the huge amount of information, and it will be expensive to find it. And if the cost of finding the information exceeds the profit from the scam, then this kind of phishing scam will disappear. (I don’t know.)