As many of you have heard, Tesla Motors’ website was “hacked” on Saturday as well as its official Twitter account. The teslamotors.com website was redirected to a server hosted in Amsterdam. Within a few minutes, the account began sending tweets promising free Tesla cars to those who called a certain phone number, which belonged to a computer repair shop in Illinois, and was presumably tweeted out to flood the number’s owner with calls. Later that same day it was revealed that Tesla founder Elon Musk’s Twitter account was compromised. According to Dave Smith at Business Insider “though the parties claiming responsibility offer up different names, it appears to be one coordinated attack on all of Musk’s online and social properties.”
Let’s take a deeper dive into what happened.
1) This was not a “hack,” but a series of related defacements
We’d first like to communicate that we believe this to be a compromise, and not necessarily a “hack.” This attack (and we use the term loosely) involved the redirecting of legitimate traffic destined for teslamotors.com to an IP address of the attackers’ choosing.
Visitors to the domain were presented with the following page (as captured by David Maynor via his Twitter feed):
Oh wow…That can’t be good. #tesla #hacked pic.twitter.com/IjASf2ZCw3
— David Maynor (@Dave_Maynor) April 25, 2015
At roughly the same time, the corporate Twitter account for Tesla was compromised. Once controlled by the attackers, several tweets appeared from the @TeslaMotors Twitter account and the name of the account was changed to “#RIPPRGANG.” The account also tweeted the number to call to get a free Tesla. The number was that of a small computer repair shop in Illinois.
Elon Musk’s account also began tweeting messages about free cars and where they can be picked up–at the same address in Illinois.
2) The domain registrar may have been socially engineered to give up control of the teslamotors.com domain
It appears that very little sophistication was involved in this defacement. As such, there was initial speculation of a social engineering (SE) attack against the domain registrar but sources close to the investigation inform us that the SE attack vector was not exploited.
A SE attack against the registrar would explain how the attackers were able to gain access to both the corporate Twitter account and the account of founder Elon Musk. By controlling the domain, and by association the MX (mail exchange) records, the attackers could request a password reset for the Twitter accounts.
By controlling the MX record, the e-mailed password resets would have given the attacker control of the social account passwords.
The official statement from Tesla, as told to Thomas Fox-Brewster of Forbes, was that
“Posing as a Tesla employee, somebody called AT&T customer support and had them forward calls to an illegitimate phone number. The impostor then contacted the domain registrar company that hosts teslamotors.com, Network Solutions. Using the forwarded number, the imposter added a bogus email address to the Tesla domain admin account. The impostor then reset the password of the domain admin account, routed most of the website traffic to a spoof website and temporarily gained access to Tesla’s and Elon’s Twitter accounts.”
Tesla’s corporate network, cars, and customer database were not affected and everything has been restored to normal, according to the spokesperson.
“We are working with AT&T, Network Solutions, and federal authorities to further investigate and take all necessary actions to make sure this never happens again,” the spokesperson added.
So the domain registrar was not SEd, but rather AT&T. This is not the first time that AT&T was tricked into redirecting calls to an illegitimate phone number.
3) DNS shows a timeline of changes during the attack
As you can see from OpenDNS Investigate results for teslamotors.com, the domain’s IP address was changed on April 25th from 220.127.116.11 to 4 additional IP addresses not owned or controlled by Tesla.
OpenDNS Investigate’s new WHOIS information shows that the domain is back to using UltraDNS for its name servers.
The historical (and expected) IP address for teslamotors.com is associated with AS 40913 owned by Quality Technology Services Santa Clara, LLC. This is where the domain is usually hosted.
The new IP addresses are shared between hosting providers Digital Ocean (AS 200130), VOXILITY (AS 3223), and OVH (AS 16276). As you can see below, at least 2 of the IP addresses have a questionable track record.
4) So far, nothing indicates visitors were at risk for malware downloads
The teslamotors.com domain received a surge in visits between 04:00 and 07:00 UTC. The most significant spike to the domain occurred on April 26th at 05:00 UTC as shown below.
This was likely due to the attackers publicizing the “hack.” The subsequent Internet frenzy to visit the site ensued and was noticed by more than a few individuals.
There is no indication of any malware being dropped, nor were visitors redirected to another site to download malware. This can be verified by the HTML dump of the fraudulent site on Pastebin: http://pastebin.com/j6kz0Kdk.
5) The Islamic State of Iraq and ash-Sham (ISIS) was not likely involved, but Lizard Squad may have been?
At one point during the campaign, the teslamotors.com site was redirected to another fear-inspiring domain: isis[.]camp.
Now http://t.co/Y0Ab1JRkjM points to a domain with ISIS in it. #tesla#hackpic.twitter.com/LHItCZcJbT
— David Maynor (@Dave_Maynor) April 25, 2015
The newly created domain was registered at ENom and hosted at DreamHost Web Hosting for a brief time. So was this the work of ISIS? In a word, unlikely. It’s incredibly unlikely that ISIS would have it out for Tesla as a company. It’s even more unlikely that they’d direct their anger at a small Illinois-based computer repair shop. There are speculations around the research community, as well as the targeted individual, that this breach was the work of “Ryan” aka “zeekill” aka “Julius Kivimäki”, a Finish national with alleged ties to Lizard Squad.
Receiving reports that Julius Kivimaki hacked Tesla and Elon Musk’s Twitter accounts and websites by Social engineering NetworkSolutions
— r000t (@rootworx) April 26, 2015
OpenDNS can neither confirm nor deny attribution at this time.
The use of Jihadist-inspired defacements is not new. As many of these defacements are meant to drive traffic to the hijacked site, instill fear, and increase publication int he popular media, the use of controversial (yet unrelated) imagery and messaging is becoming common place.
As always, please let us know if you have any additional information or would like to talk to us about our findings.
The post Five Things To Know About The Tesla Motors Compromise appeared first on OpenDNS Security Labs.
Reports show that as little as 10 percent of businesses have formally adopted Internet of Things (IoT) devices in their IT environments. But if the security community has learned one thing from the history of shadow IT, it’s that informal adoption of IoT devices in the enterprise is already much higher. OpenDNS Security Labs invites its readers to participate in this quick and anonymous survey regarding IoT use on business networks.
Create your free online surveys with SurveyMonkey , the world’s leading questionnaire tool.
The post Internet of Things Security? appeared first on OpenDNS Security Labs.
Do you need to be a hardcore malware reverser to understand how malware works under the covers? No, not always. Here’s an example of using some free tools and OpenDNS Investigate to expedite the analysis process and rapidly protect your organization.
Subject: Urgent Notification N443111645 Thank you for placing order with our company now! Your purchase is processing right now. Outright Purchase: 4200 AUD Please check the statement given with this email to see more details about your order. ORDER DETAILS Purchase Number: AGS873904473 Order Date: 12:45 Monday, Mar 2 2015 Customer Email: <victim email address>
Attached to the email is a Microsoft Compiled HTML Help file (.chm) that, according to VirusTotal at the time of this writing, has been uploaded 28 times since 2015-03-02 23:11:38.
The file most commonly utilizes the pattern payment_ddddd.chm, where ‘ddddd‘ is a seemingly random generated integer five digits in length.
Full dynamic analysis of this file can be viewed here: https://www.virustotal.com/en/file/0d18bc9bd50080598f9d69032de95b2ed438e77884a6389755f523f3901c0b39/analysis/.
When executed, the .chm file downloads an executable named tv.exe from www[.]igloofire[.]com. The tv.exe file generates domain names using a DGA, tries to resolve the domain names, and finally contacts those domains with a single HTTP GET request and 20 HTTP POST attempts. The VirusTotal dynamic analysis for the tv.exe file can be viewed here: https://www.virustotal.com/en/file/8e801b9171291c11b0a3fcbd4314a078ff2c43305808fd49434858654e4e4bde/analysis/
“But Andrew,” you ask, “how do you know that? We don’t see anything in the VirusTotal analysis to substantiate that.”
That’s absolutely correct. In fact, the dynamic analysis from VirusTotal only shows communication to 18.104.22.168 on UDP port 123 – which is a Microsoft NTP server that the Windows virtual machine likely called out to in order to sync its time.
This exact situation illustrates some of the issues with relying entirely on dynamic analysis engines. That being said, we strongly suggest that you try multiple engines/platforms when performing dynamic analysis to see what shakes out. One alternative is The Shadowserver Foundation’s Malwr.com platform. Analyzing the downloaded tv.exe file on Malwr.com (https://malwr.com/analysis/MTY5MTAxZjE3OTk5NGVkZDkyYTFhNGMwZTVjOTBjNzc/#) shows us that several signatures have been trigged.
As well as interaction with the DGA in question – perviylich[.]ru
Additionally, we can observe the system level communication flow and the Windows hooks involved in said communication.
Now reversing the malware would have eventually given us this domain but we’re in triage mode right now. We can always reverse the malware later to confirm and/or expand our findings.
Looking up the perviylich[.]ru domain in OpenDNS Investigate, we can tell several things:
1) The domain is blocked by OpenDNS
2) The domain only recently became active
3) The majority of clients requesting the domain are from Australia (80%) – perhaps a targeted attack on a particular region?
4) The threat model identifies this domain as having a high likelihood of being a DGA
5) The domain utilizes the following IP addresses: 22.214.171.124 (also the name server) and 126.96.36.199
6) The IPs are allocated to AS’ in Ukraine and Russia, respectively
7) The IP addresses also host a number of other DGA-looking domains
8) In looking at some of the other domains on that infrastructure, we can see a similar pattern across the entire hosting IP addresses
9) We can also see a pattern emerge that shows pairings of DGA registrations utilizing the same domain name combined with both a .ru (Russia) TLD and a .su(Soviet Union) TLD.
10) Using this information, we can create a master list of domains involved in this particular malware infrastructure run:
If you’re a visual person, you can also graph the domains, using the OpenDNS Investigate API and the open source OpenGraphiti tool, to show the linkages. The image below shows the domains (outside edge of circle) and how they’re associated with the two IP addresses found earlier in this post.
To confirm findings, however, you can (and probably should) analyze the memory of the running binary to ensure that there are no subsequent IP addresses or domains called out to that may have been missed by your dynamic analysis engines. In this particular case, there were no additional domains or IP addresses.
11) Digging even further into the domain list, we can query Investigate for any IP addresses these domains resolved to in the past
Placing the domains into Maltego and using OpenDNS’s Investigate transform, we found two IP addresses these domains resolved to. Both
Both of these IP addresses were also the IP addresses of the domains’ name servers. This add to the suspiciousness of the domain names.
12) Identifying the name server domains, we queried Whois to find more information about the registrant of the name server domains.
It turns out the email account, email@example.com, used to register the name server domains also registered a handful of other domain names.
|Domain Name||Creation Date|
All of which had similar subdomains of ns1, ns2, ns3, and ns4 and all of which were registered through the notoriously abused BizCN.com registrar and were acting as name servers for fastflux as well as command and control domains.
We dumped all these domains, their subdomain, and their IP addresses into our Maltego graph and found some interesting connections.
13) Noting that YopMail is a free temporary email service, we visited the site and checked the web-based inbox of firstname.lastname@example.org (the registrant of all these name servers associated with malicious domains)
It turns out the registrar confirmation emails were still there, dating March 1 through March 3. This confirms the whois records.
14) It should be noted that AS48031 is a rogue AS that has been serving malicious sites for a while in addition to performing various evasive actions.
We’ve been monitoring it for a while and discussed it in March 2014 in this webcast (minute 19:25 in “Rogue and Stealth ASNs”) and at Virus Bulletin here.
AS48031, XSERVER-IP-NETWORK-AS PE Ivanov Vitaliy Sergeevich,UA, that a lot of security folks will recognize has been hosting all kinds of malicious and shady content (malware, browser-based ransomware, porn sites, spam, radical forums) and it’s been “fluxing” on and off the routable IP space. For example, in earlier 2014, it disappeared off the global routing table but as of early March 2015, AS48031 is online and advertising its prefixes by verifying our BGP routing tables and as shown below.
At the time of this writing, there are 1900+ live IPs on AS48031 IP space, and further checking them reveals finer granularity of allocation. A few suspicious small hosters are selling this sub-allocated IP space for customers via VPS, VDS, and dedicated servers. justhost.in.ua is one of these hosters that warrants further scrutiny. We discussed similar rogue or abused small hosting providers in our recent talks at BlackHat, DefCon and Virus Bulletin.
We wouldn’t be surprised to see a few domains start using dns-pupkin-vasya.com as an authoritative zone very soon and can with confidence, say they are domains you don’t want your devices connecting to.
At this point you should have a good idea of how to leverage OpenDNS Investigate to perform detailed malware triage and infrastructure investigations to protect your organization and its users – all without having to open a hex editor or manual debugger.
Until next time!
The post Investigating A Malicious Attachment Without Reversing appeared first on OpenDNS Security Labs.