In this blog post by SpiderFoot author, Steve Micallef,… | Intel 471 Skip to content
blog article

In this blog post by SpiderFoot author, Steve Micallef, see how OSINT is used to investigate a Bitcoin scam.

Nov 18, 2019
Photo 1518546305927 5a555bb7020d 1024x684

You may have heard about the Elon Musk Bitcoin scam doing the rounds on Twitter this past week. In this article I will explain how the scam was orchestrated and then walk through some of the Open Source Intelligence (OSINT) gained through using some simple but effective techniques.


The Scam


Let’s first quickly walk through the scam itself and how it played out. Here’s an example of one of the promoted tweets:


Aside from the nature of the Tweet (Musk giving away Bitcoin, seriously?), the grammatical errors, the fake Tesla domain name and the mismatch between the Twitter account and name, people still fell for it.

In short, the attackers compromised a number of genuine, verified Twitter accounts such as Capgemini, Target and Google’s G Suite, then changed the name and profile picture to that of Musk’s. To deliver the message to the masses they then used promoted tweets like the one above, linking to websites where the Bitcoin transfer could be made by the victims. And it worked. Despite the obvious indicators: grammatical errors, mismatch between the Twitter user name, name and domain name, apparently over $180,000 worth of Bitcoin was sent to the scammers. Incredible.


Of course, Bitcoin scams on Twitter are nothing new, yet when I came across this live in my Twitter feed this week, I couldn’t resist performing some OSINT on the domain names involved, just to see what might turn up. Being the author of SpiderFoot, I’m always looking for opportunities to test it out to identify areas for improvement, so this seemed like the perfect opportunity. I plugged the domain names into SpiderFoot, selected all 150 modules so as to collect as much data as possible, and let it run.


Alongside the automated data collection by SpiderFoot, I performed some manual analysis to supplement it. I’ll be covering that here too.


Goals of the Analysis


To be honest, I had no goals to begin with except to collect all the data and browse through it in SpiderFoot to see how the tool could be improved. Some things did however catch my eye which is where the inspiration for this article came from. I figured that if I was going to do a write-up, I should put some structure to it and explain the process. So in short, the goals are to:


  • Find all the entities (hostnames, IP addresses, e-mail addresses, names, domain names, etc.) relevant to the scam with the goal of finding those which might reveal the true identities of those behind it, or at least hints towards those identities
  • Learn any characteristics of the scam which might be useful when identifying/investigating future scams or support the investigation of the entities identified
  • Suggest potential next steps for further investigation which may help in this particular investigation, or others in the future

Before continuing, I need to provide the disclaimer that I am not making any claims as to the identity/origin of the scammers, nor even claiming my analysis is comprehensive. This post is intended to provide further insight into the scam as well as guidance for those doing similar investigations.


So let’s get into it…


The Analysis


The starting point for the analysis itself is what we can target for the automated OSINT collection. The Twitter accounts used were compromised legitimate accounts, so investigating them would provide little value. Second, the name behind the scam (Elon Musk) is also fake in the sense that it is obviously not him (although to be fair, that can’t be ruled out either!) So, all we have to go off initially is the domain name mentioned in the tweets themselves. The tweets I saw made reference to these domains, but there were surely more:


  • m-tesla[.]me
  • elonmusk[.]id
  • m-tesla[.]pw

Starting with the Domain Names


What kind of techniques are available to us if we are starting with domain names for OSINT? Well, a domain name should resolve to an IP address, has a Whois record with the registrar for that domain and so on. Let’s call these “chains of information”, which could look something like this:


  • Domain name -> IP address -> Search passive DNS -> Co-hosted sites
  • Domain name -> Whois lookup -> Extract e-mail addresses
  • Domain name -> Fetch web content -> Extract names, etc.
  • And so on…

Obviously the chains above are very simplistic but you get the idea: one piece of information leads to another which can lead to another and so on. In any investigation you could be looking at tens of layers of depth for analysis, depending on the data sources available to you and the quality of each link in the chain.


Finding the IP Address After Take-down


Attempting to resolve the domains reveals they now point to 127.0.0.1 (localhost), so they have already been taken down.


Having IP addresses would be handy because it’s a data point that can be referenced in threat intelligence feeds, network topology/routing data and more. From them we can find other domains pointing to the same IPs, not to mention see if there may be others on the same network subnet of that IP address which could indicate a possible broader network of scam sites.


So, let’s see if we can find the IP address these domains used to resolve to. Thankfully, passive DNS is a great source of data for which there are many free sources on the Internet. In this case, the Mnemonic Passive DNS search engine found the IPs for two of the three domains: 193.233.15.187 for m-tesla[.]me and 193.233.15.163 for elonmusk[.]id:


Thanks to passive DNS sites like this, we can identify historical IP addresses of a given domain name even after take-down.

Other tools of a similar nature are also worth a mention here: Robtex.com, SecurityTrails.com, HackerTarget.com, Cymon.io and VirusTotal. Due to the nature of passive DNS it’s highly likely that one source will be missing data for your target, so you’ll need to try multiple sources to build a complete picture and not rely on one source alone. In this case, we have the original IP address so we can move forward with further analysis.


Who Owns the IP Addresses?


Interestingly, all three domains use the same hosting provider of “storm-pro.net” according to their Whois data:


steve@dev:~$ whois m-tesla.me
Domain Name: M-TESLA.ME
...
Name Server: DNS2.STORM-PRO.NET
Name Server: DNS1.STORM-PRO.NET
...

But that domain appears to have no website and their Whois records have all useful information masked:


steve@dev:~$ host -t a storm-pro.net
storm-pro.net has no A record
steve@dev:~$ host -t a <a href="http://www.storm-pro.net/" target="_blank" rel="noreferrer noopener">www.storm-pro.net</a>
Host <a href="http://www.storm-pro.net/" target="_blank" rel="noreferrer noopener">www.storm-pro.net</a> not found: 3(NXDOMAIN)
steve@dev:~$ whois storm-pro.net
...
Registrant Name: GDPR Masked
Registrant Organization: GDPR Masked
Registrant Street: GDPR Masked GDPR Masked GDPR Masked
Registrant City: GDPR Masked
Registrant State/Province: GDPR Masked
Registrant Postal Code: 00000
Registrant Country: GDPR Masked
Registrant Phone: +0.00000000
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: <a href="mailto:[email protected]" target="_blank" rel="noreferrer noopener">[email protected]</a>
Admin Email: <a href="mailto:[email protected]" target="_blank" rel="noreferrer noopener">[email protected]</a>
Registry Tech ID: Not Available From Registry
Tech Name: GDPR Masked
Tech Organization: GDPR Masked
Tech Street: GDPR Masked GDPR Masked GDPR Masked
Tech City: GDPR Masked
Tech State/Province: GDPR Masked
Tech Postal Code: 00000
Tech Country: GDPR Masked
Tech Phone: +0.00000000
Tech Phone Ext:
Tech Fax:
Tech Fax Ext:
Tech Email: <a href="mailto:[email protected]" target="_blank" rel="noreferrer noopener">[email protected]</a>
...

Let’s try to directly fetch content from the IP address we found, to see who might be behind it. We get this when visiting https://193[.]233[.]15[.]163:



OK, so it looks like the scammers ran their sites using/behind this provider, which appears to be a hosting and Anti-DDOS company targeting the Russian market:



There is very little information available about the company on their website, but their LinkedIn profile reveals a company registered in Slovakia with four employees — three in Russia, one in Czech Republic. It seems likely at this point that the scam site was a customer of this provider and shut down by either the provider or the scammers themselves.


What Else Is on the Same Server and Network?


Given that multiple IP addresses on the same subnet are involved in the scam, it’s worth checking who owns that subnet, which BGPView.io can be used for:


Searching for the 193.233.15.0/24 subnet, we can see it is part of an autonomous system owned by a Lebanese company (Smart Telecom SARL) and supposedly located in Seychelles.

Looking further to see who is the upstream provider (i.e. who is providing Internet access) to this network, we see StormWall again, which makes sense given that they are currently proxying HTTPS requests to that IP address:


STORMSYSTEMS-AG = StormWall

Performing a Whois on the 193.233.15.0/24 subnet where the scam hosts reside reveals a company named Safe Value Management:


steve@dev:~$ whois 193.233.15.0/24
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
...organisation: ORG-SVL6-RIPE
org-name: Safe Value Limited
org-type: OTHER
address: Global Gateway 8, Rue de la Perle, Providence, Mahe, Seychelles
geoloc: -4.678633 55.467250
abuse-c: SVM142-RIPE
mnt-ref: safevalue-mnt
mnt-ref: FREENET-MNT
mnt-by: safevalue-mnt
mnt-by: FREENET-MNT
created: 2017-03-13T16:19:46Z
last-modified: 2017-04-30T08:54:48Z
source: RIPE # Filteredrole: Safe Value Management
address: Global Gateway 8, Rue de la Perle, Providence, Mahe, Seychelles
abuse-mailbox: <a href="mailto:[email protected]" target="_blank" rel="noreferrer noopener">[email protected]</a>
nic-hdl: SVM142-RIPE
...

Looking at the e-mail address [email protected] we can check out their website for further insight:



There is no information about the company offered on the website, however despite the reference to Seychelles in their network Whois records, there is no mention of it anywhere on the website. In fact, despite there being no language-switcher for the website, you can manually visit a Russian version of the site which still offers English content but with Russian mouse-overs. Attempting this for other languages results in 404 errors:


When going to safevalue.pro/ru, you still get an English site but with Russian mouse-overs. The same behaviour doesn’t exist for other languages — they return 404s.

But what about other subnets neighbouring this one? Where are they located and who manages them? This one-liner script below will perform Whois queries for subnets neighbouring the 193.233.15.0/24 subnet and look for the country and organisation under which it is registered:


steve@dev:~$ for i in `seq 5 25`; do whois 193.233.$i.0/24 | egrep -i country\|org-name | sort -u; done
country: RU
org-name: OOO Avantelecom
country: RU
org-name: Vostok Telecom LLC
country: RU
org-name: OOO Avantelecom
country: RU
org-name: L.Ya.Karpov Institute of Physical Chemistry
country: RU
org-name: Vostok Telecom LLC
country: RU
org-name: State Federal Budgetary Scientific Establishment Baikov Institute of Metallurgy and Materials Science of Russian Academy of Sciences
country: RU
org-name: State Federal Budgetary Scientific Establishment Baikov Institute of Metallurgy and Materials Science of Russian Academy of Sciences
country: RU
org-name: OOO Telecom-V
country: RU
org-name: OOO Telecom-V
country: RU
org-name: Russian National Public Library for Science and Technology
country: SC
org-name: Safe Value Limited
country: RU
org-name: ZAO Redcom-Internet
country: RU
org-name: ZAO Redcom-Internet
country: RU
org-name: ZAO Redcom-Internet
country: RU
org-name: ZAO Redcom-Internet
country: RU
org-name: ZAO Redcom-Internet
country: RU
org-name: ZAO Redcom-Internet
country: RU
org-name: ZAO Redcom-Internet
country: RU
org-name: ZAO Redcom-Internet
country: RU
org-name: Federal Budgetary Educational Enterprise of Higher Professional Education Moscow State Forest University
country: RU
org-name: Federal Budgetary Educational Enterprise of Higher Professional Education Moscow State Forest University

As you can see, all the neighbouring subnets to the one in question are located in Russia, aside from the one involved in the scam. Additionally, none of them are associated with Safe Value Management, only the one associated with the scam.


So let’s quickly re-cap: We have found the historic IP address of the scam sites using passive DNS data. They are both sitting on the same subnet, which is hosted by some combination of StormWall and Safe Value Management. Both entities appear to be Russian, the latter seeming to be attempting to hide that fact. The subnet in which both scam sites are within appears to be quite distinct from neighbouring subnets based on the registry location and organisation. Let’s now expand our search to see what other sites might exist in the scope of this scam.


Expanding the Scope


We can use SpiderFoot to quickly check what other sites were resolving to the same scam site IP addresses by quering multiple passive DNS sources. This time, Robtex, Cymon and Mnemonic revealed a number of sites on the same IP as m-tesla[.]me, which we identified earlier as having had the IP address of 193.233.15.187:


SpiderFoot used multiple Passive DNS data sources to find other sites that resolved to the IP address of m-tesla[.]me.

We can see clearly here that the campaign spanned many other sites, utilising shared infrastructure. Let’s now look across the whole subnet of 193.233.15.0/24 to see what sites are hosted there:


Using a mix of Robtex and others, SpiderFoot found 186 sites on the same subnet as the scam sites.

186 sites is quite a lot, so to identify what might warrant focus within this list, let’s consult some reputation services as the next step.


Malicious and Spammer IPs


A number of threat intelligence, spam detection and IP reputation services have been flagging the implicated IP addresses as risky for some time. For instance VirusTotal goes back to August 2018 as indicating suspicious behaviour for multiple domains in the above list:



SpiderFoot also automatically queried VirusTotal about all the co-hosted sites and sites on the same subnet, and we immediately see a number of problems across many IP addresses on the same subnet as the two we identified earlier:



117 hosts/IPs found in this subnet alone to be malicious, according to VirusTotal. Looking up one of the findings from VirusTotal, we can see that one of the hosts sitting on the same subnet is even hosting malware:



It’s a similar picture when looking up other IPs and hosts from the 193.233.15.0/24 subnet. In fact, Spamhaus appears to have flagged the whole subnet as worthy of blocking at the time of writing.


What About the Who?


As is to be expected, the e-mail addresses found for the domains directly involved in the scam are privacy/abuse e-mail addresses not revealing the identity of any individual or organisation:



In other words, completely useless and meaningless. Some unmasked e-mail addresses were found, associated with sites on the same subnet but looking into those goes beyond the scope of this article, also because those sites do not seem related to this scam (elonmusk[.]ooo, for instance).


Using Context to Go Further


Using the knowledge that there are multiple domains involved in the same scam and sharing the same infrastructure, we can use information from one domain to support investigating the other. Let’s go back to Whois for a moment because it looks like two of the three domains use NameCheap as their registrar, but the other does not:


The above screenshot from SpiderFoot indicates that NameCheap was used for two of the domains, but not the other.

When performing a Whois query, you direct it against a particular server. Quite often, people stop with the first Whois results they see, but there is a critical piece of information in Whois results that could be the difference between an investigation reaching a dead end or finding the golden nugget enabling you to go further:


steve@dev:~$ whois m-tesla.me
Domain Name: M-TESLA.ME
Registry Domain ID: D425500000070248173-AGRS
<strong>Registrar WHOIS Server: whois.namecheap.com</strong>
...

When running Whois, you are querying a default set of Whois servers automatically selected by your client Whois software. The Whois results will often make reference to the authoritative Whois server which will have more information. Such is the case above highlighted in bold, so let’s try it by using the -h flag to the Whois client on Linux:


steve@dev:~$ whois m-tesla.me -h whois.namecheap.com
Domain name: m-tesla.me
Registry Domain ID: D425500000070248173-AGRS
Registrar WHOIS Server: whois.namecheap.com
Registrar URL: <a href="http://www.namecheap.com/" target="_blank" rel="noreferrer noopener">http://www.namecheap.com</a>
Updated Date: 2018-11-07T11:29:42.00Z
Creation Date: 2018-11-07T11:29:42.00Z
Registrar Registration Expiration Date: 2019-11-07T11:29:42.00Z
Registrar: NAMECHEAP INC
Registrar IANA ID: 1068
Registrar Abuse Contact Email: <a href="mailto:[email protected]" target="_blank" rel="noreferrer noopener">[email protected]</a>
Registrar Abuse Contact Phone: +1.6613102107
Reseller: NAMECHEAP INC
Domain Status: clientTransferProhibited <a href="https://icann.org/epp#clientTransferProhibited" target="_blank" rel="noreferrer noopener">https://icann.org/epp#clientTransferProhibited</a>
Domain Status: serverTransferProhibited <a href="https://icann.org/epp#serverTransferProhibited" target="_blank" rel="noreferrer noopener">https://icann.org/epp#serverTransferProhibited</a>
Registry Registrant ID: ti1srjorhfz8q94w
Registrant Name: WhoisGuard Protected
Registrant Organization: WhoisGuard, Inc.
Registrant Street: P.O. Box 0823-03411
Registrant City: Panama
Registrant State/Province: Panama
Registrant Postal Code:
Registrant Country: PA
Registrant Phone: +507.8365503
Registrant Phone Ext:
Registrant Fax: +51.17057182
Registrant Fax Ext:
Registrant Email: <a href="mailto:[email protected]" target="_blank" rel="noreferrer noopener">[email protected]</a>
Registry Admin ID: y8otwk46zno0fdku
Admin Name: WhoisGuard Protected
Admin Organization: WhoisGuard, Inc.
Admin Street: P.O. Box 0823-03411
Admin City: Panama
Admin State/Province: Panama
Admin Postal Code:
Admin Country: PA
Admin Phone: +507.8365503
Admin Phone Ext:
Admin Fax: +51.17057182
Admin Fax Ext:
Admin Email: <a href="mailto:[email protected]" target="_blank" rel="noreferrer noopener">[email protected]</a>
Registry Tech ID: q5fk9pxjotdst0s1
Tech Name: WhoisGuard Protected
Tech Organization: WhoisGuard, Inc.
Tech Street: P.O. Box 0823-03411
Tech City: Panama
Tech State/Province: Panama
Tech Postal Code:
Tech Country: PA
Tech Phone: +507.8365503
Tech Phone Ext:
Tech Fax: +51.17057182
Tech Fax Ext:
Tech Email: <a href="mailto:[email protected]" target="_blank" rel="noreferrer noopener">[email protected]</a>
Name Server: dns1.storm-pro.net
Name Server: dns2.storm-pro.net
DNSSEC: unsigned
URL of the ICANN WHOIS Data Problem Reporting System: <a href="http://wdprs.internic.net/" target="_blank" rel="noreferrer noopener">http://wdprs.internic.net/</a>
>>> Last update of WHOIS database: 2018-11-17T17:46:28.10Z <<<

More information, but still nothing useful. But hold on — we know NameCheap was used for two of the three domains, but maybe it was used by the third too? When we did a Whois of elonmusk[.]id earlier we didn’t see any referral to the NameCheap Whois server, but that could just be a characteristic of the .id Whois server as not all Whois servers return the same formatted data or behave in the same way. Let’s give it a shot:


steve@dev:~$ whois elonmusk.id -h whois.namecheap.com
Domain name: elonmusk.id
...
Registrant Name: Sergey Ishuk
Registrant Organization:
Registrant Street: lenina 131 lenina 131 kv 2
Registrant City: Xarkov
Registrant State/Province: Xarkov
Registrant Postal Code: DN3 6GB
Registrant Country: GB
Registrant Phone: +380.957370883
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: <a href="mailto:[email protected]" target="_blank" rel="noreferrer noopener">[email protected]</a>
...

Now we have something interesting! A name, address, phone number and e-mail address. The details are likely fake, but let’s try searching for the phone number in Google to see what turns up:



Clearly similar themed websites of a scammy nature. We also see reference to more e-mail addresses and names.


Similar Domains: Potential Future Scams?


With a $180,000 bounty from this scam, there will surely be more. Looking at other domain names with similar names but on different Top Level Domains (TLDs), clearly the scammers have banked on using the Elon Musk “brand” again at some point in the future.


Looking at the discovery path visualisation in SpiderFoot, we can see that there are some similar domains on different TLDs which may be of interest in the future.

Conclusions


Let’s wrap up what we know about the scam:


  • The same hosting provider was used for the domains involved in the scam, being StormWall and Safe Value Management. Both entities appear to be Russian, the latter seeming to be attempting to hide that fact.
  • Whilst the domains involved in the scam quickly changed their IPs to 127.0.0.1, passive DNS data was able to reveal the original IP addresses and turned out to be key for the analysis.
  • All Whois information for the directly involved domain names is utilising privacy services making the identification of associated people impossible. It may be possible to infer ownership by looking at ownership of domains on the same subnet as the scam sites, especially given that the whole subnet appears to be a “bad neighbourhood.”
  • Using Whois to query the Whois server of the registrar that was used by two of the three domains seemed to be quite revealing for the third domain.
  • The scam sites were hosted on the same /24 subnet, along with many other domains of similar nature which have been flagged by multiple threat intelligence sources as spammers/malicious.
  • The subnet hosting the scam sites amongst other scam/malicious sites appears to be registered in Seychelles whilst much of the content of the sites themselves appears to be Russian.

Now before anyone goes off screaming about “the Russians” being behind this, keep in mind that attribution on the Internet is far from an exact science. It’s not even a science. So take the above with a good few grains of salt.


Possible Next Steps


  • Look at the Bitcoin address(es) used in the scam and attempt to analyse the money trail using Blockchain.info and BitcoinWhosWho.com.
  • Look more deeply into the content and Whois data for the sites on the same subnet to see if e-mail address or other personal information can be found for people potentially implicated in the scam.
  • Use reverse Whois sites like SecurityTrails and ViewDNS.info to look for other domains registered by the names and e-mail addresses found.
  • Look more deeply into the domains of the same name but on different TLDs to see if any may reveal an e-mail address of someone potentially implicated in this or similar scams.
  • Try and find historic cached content for the sites since taken down and search that for further clues. A good place to start for this are Google and Bing’s caches. There appears to be nothing in the Wayback Machine for the three sites investigated, but older sites may exist there.
  • Search Google and others for text strings from the scam to find other implicated sites not found through the above analysis.
  • Use your creativity! See what Proofpoint did if you’re looking for inspiration.

Check out the write-up here, including some examples of how SpiderFoot fits into the analysis: https://medium.com/@micallst/an-osint-analysis-of-the-elon-musk-bitcoin-scam-778fb1b14b3b