The San Francisco Municipal Transportation Agency (SFMTA) was hit with a ransomware attack on Friday, causing fare station terminals to carry the message, “You are Hacked. ALL Data Encrypted.” Turns out, the miscreant behind this extortion attempt got hacked himself this past weekend, revealing details about other victims as well as tantalizing clues about his identity and location.
A copy of the ransom message left behind by the “Mamba” ransomware.
On Friday, The San Francisco Examiner reported that riders of SFMTA’s Municipal Rail or “Muni” system were greeted with handmade “Out of Service” and “Metro Free” signs on station ticket machines. The computer terminals at all Muni locations carried the “hacked” message: “Contact for key (cryptom27@yandex.com),” the message read.
The hacker in control of that email account said he had compromised thousands of computers at the SFMTA, scrambling the files on those systems with strong encryption. The files encrypted by his ransomware, he said, could only be decrypted with a special digital key, and that key would cost 100 Bitcoins, or approximately USD $73,000.
On Monday, KrebsOnSecurity was contacted by a security researcher who said he hacked this very same cryptom27@yandex.com inbox after reading a news article about the SFMTA incident. The researcher, who has asked to remain anonymous, said he compromised the extortionist’s inbox by guessing the answer to his secret question, which then allowed him to reset the attacker’s email password. A screen shot of the user profile page for cryptom27@yandex.com shows that it was tied to a backup email address, cryptom2016@yandex.com, which also was protected by the same secret question and answer.
Copies of messages shared with this author from those inboxes indicate that on Friday evening, Nov. 25, the attacker sent a message to SFMTA infrastructure manager Sean Cunningham with the following demand (the entirety of which has been trimmed for space reasons), signed with the pseudonym “Andy Saolis.”
“if You are Responsible in MUNI-RAILWAY !
All Your Computer’s/Server’s in MUNI-RAILWAY Domain Encrypted By AES 2048Bit!
We have 2000 Decryption Key !
Send 100BTC to My Bitcoin Wallet , then We Send you Decryption key For Your All Server’s HDD!!”
One hundred Bitcoins may seem like a lot, but it’s apparently not far from a usual payday for this attacker. On Nov. 20, hacked emails show that he successfully extorted 63 bitcoins (~$45,000) from a U.S.-based manufacturing firm.
The attacker appears to be in the habit of switching Bitcoin wallets randomly every few days or weeks. “For security reasons” he explained to some victims who took several days to decide whether to pay the ransom they’d been demanded. A review of more than a dozen Bitcoin wallets this criminal has used since August indicates that he has successfully extorted at least $140,000 in Bitcoin from victim organizations.
That is almost certainly a conservative estimate of his overall earnings these past few months: My source said he was unable to hack another Yandex inbox used by this attacker between August and October 2016, “w889901665@yandex.com,” and that this email address is tied to many search results for tech help forum postings from people victimized by a strain of ransomware known as Mamba and HDD Cryptor.
Copies of messages shared with this author answer many questions raised by news media coverage of this attack, such as whether the SFMTA was targeted. In short: No. Here’s why.
Messages sent to the attacker’s cryptom2016@yandex.com account show a financial relationship with at least two different hosting providers. The credentials needed to manage one of those servers were also included in the attacker’s inbox in plain text, and my source shared multiple files from that server.
KrebsOnSecurity sought assistance from several security experts in making sense of the data shared by my source. Alex Holden, chief information security officer at Hold Security Inc, said the attack server appears to have been used as a staging ground to compromise new systems, and was equipped with several open-source tools to help find and infect new victims.
“It appears our attacker has been using a number of tools which enabled the scanning of large portions of the Internet and several specific targets for vulnerabilities,” Holden said. “The most common vulnerability used ‘weblogic unserialize exploit’ and especially targeted Oracle Corp. server products, including Primavera project portfolio management software.”
According to a review of email messages from the Cryptom27 accounts shared by my source, the attacker routinely offered to help victims secure their systems from other hackers for a small number of extra Bitcoins. In one case, a victim that had just forked over a 20 Bitcoin ransom seemed all too eager to pay more for tips on how to plug the security holes that got him hacked. In return, the hacker pasted a link to a Web server, and urged the victim to install a critical security patch for the company’s Java applications.
“Read this and install patch before you connect your server to internet again,” the attacker wrote, linking to this advisory that Oracle issued for a security hole that it plugged in November 2015.
In many cases, the extortionist told victims their data would be gone forever if they didn’t pay the ransom in 48 hours or less. In other instances, he threatens to increase the ransom demand with each passing day.
WHO IS ALI REZA?
The server used to launch the Oracle vulnerability scans offers tantalizing clues about the geographic location of the attacker. That server kept detailed logs about the date, time and Internet address of each login. A review of the more than 300 Internet addresses used to administer the server revealed that it has been controlled almost exclusively from Internet addresses in Iran. Another hosting account tied to this attacker says his contact number is +78234512271, which maps back to a mobile phone provider based in Russia.
But other details from the attack server indicate that the Russian phone number may be a red herring. For example, the attack server’s logs includes the Web link or Internet address of each victimized server, listing the hacked credentials and short notations apparently made next to each victim by the attacker. Google Translate had difficulty guessing which language was used in the notations, but a fair amount of searching indicates the notes are transliterated Farsi or Persian, the primary language spoken in Iran and several other parts of the Middle East.
User account names on the attack server hold other clues, with names like “Alireza,” “Mokhi.” Alireza may pertain to Ali Reza, the seventh descendant of the Islamic prophet Muhammad, or just to a very common name among Iranians, Arabs and Turks.
The targets successfully enumerated as vulnerable by the attacker’s scanning server include the username and password needed to remotely access the hacked servers, as well as the IP address (and in some cases domain name) of the victim organization. In many cases, victims appeared to use newly-registered email addresses to contact the extortionist, perhaps unaware that the intruder had already done enough reconnaissance on the victim organization to learn the identity of the company and the contact information for the victim’s IT department.
The list of victims from our extortionist shows that the SFMTA was something of an aberration. The vast majority of organizations victimized by this attacker were manufacturing and construction firms based in the United States, and most of those victims ended up paying the entire ransom demanded — generally one Bitcoin (currently USD $732) per encrypted server.
Emails from the attacker’s inbox indicate some victims managed to negotiate a lesser ransom. China Construction of America Inc., for example, paid 24 Bitcoins (~$17,500) on Sunday, Nov. 27 to decrypt some 60 servers infected with the same ransomware — after successfully haggling the attacker down from his original demand of 40 Bitcoins. Other construction firms apparently infected by ransomware attacks from this criminal include King of Prussia, Pa. based Irwin & Leighton; CDM Smith Inc. in Boston; Indianapolis-based Skillman; and the Rudolph Libbe Group, a construction consulting firm based in Walbridge, Ohio. It’s unclear whether any of these companies paid a ransom to regain access to their files.
PROTECT YOURSELF AND YOUR ORGANIZATION
The data leaked from this one actor shows how successful and lucrative ransomware attacks can be, and how often victims pay up. For its part, the SFMTA said it never considered paying the ransom.
“We have an information technology team in place that can restore our systems and that is what they are doing,” said SFMTA spokesman Paul Rose. “Existing backup systems allowed us to get most affected computers up and running this morning, and our information technology team anticipates having the remaining computers functional in the next two days.”
As the SFMTA’s experience illustrates, having proper and regular backups of your data can save you bundles. But unsecured backups can also be encrypted by ransomware, so it’s important to ensure that backups are not connected to the computers and networks they are backing up. Examples might include securing backups in the cloud or physically storing them offline. It should be noted, however, that some instances of ransomware can lock cloud-based backups when systems are configured to continuously back up in real-time.
That last tip is among dozens offered by the Federal Bureau of Investigation, which has been warning businesses about the dangers of ransomware attacks for several years now. For more tips on how to avoid becoming the next ransomware victim, check out the FBI’s most recent advisory on ransomware.
Finally, as I hope this story shows, truthfully answering secret questions is a surefire way to get your online account hacked. Personally, I try to avoid using vital services that allow someone to reset my password if they can guess the answers to my secret questions. But in some cases — as with United Airlines’s atrocious new password system — answering secret questions is unavoidable. In cases where I’m allowed to type in the answer, I always choose a gibberish or completely unrelated answer that only I will know and that cannot be unearthed using social media or random guessing.
Farsi is my first language so if you need any help translating anything that Google Translate can’t decipher do let me know.
What was the cost of recovery? and does it really matter in this case?
Even if it was lower, the ransom amount can be adjusted accordingly.
You need to be able to laugh this type of attack off or you’ll never sleep well 🙂
Secret questions or security questions that could be used to reset someone’s password are the worst thing that befell the humanity!
If I see them being used I try to stay away from that site (if I can) as that tells me that developers of that site do not understand security.
The best way to secure your important online account is with an account ID (or user ID) that cannot be easily guessed or tied to you. And most importantly with a good password generated by a password manager (LastPass or such) and a two-factor authentication enabled, that is done via time based generated codes like what is generated by the Google Authenticator app (NOT sms messages!)
It would be awesome if e-mail services let you set a different user name to actually access them instead of making it very public.
You could just create an email alias that forwards emails received from your public address to your private one.
Pretty awesome
An interesting view into ransomware victims and the threat actor behind one operation. Considering the lucrative nature of this tactic, and how many others are basically doing a similar style of operation, we can be sure that a great deal of money is, and will continue to enrich the underground economy now and into the future. Security 101 in the form of backups / disaster recovery has always been important, but now that threat actors have weaponized encryption in this manner, it should be a policy requirement that backup systems are audited frequently in order to ensure their reliability in the case of an opportunistic or targeted campaign detonating successfully.
Oh great. I ride MUNI almost every day. It was just the fare system, but … ugh.
It doesn’t say for sure if this particular instance involved Primavera, but it’s heavily insinuated. MUNI talks about their crack IT team restoring from backups, but doesn’t address 1) a server/tool like this being exposed directly to the Internet (probably) with no VPN, and 2) lack of patching for the last year or more.
On the one hand, it sucks and it’s scary for this type of thing to sorta randomly happen to one of the ten largest public transportation systems in the nation, but on the other, they were asking for it by maintaining an inept or inattentive security team or policies.
My monthly pass and everyone else’s daily fares are going up January 1. Hopefully MUNI will use those extra dollars to do a simple white hat penetration test, which I’m guessing will expose even more vulnerabilities. Then maybe some heads will roll.
Heads roll in a government bureaucracy? Surely you jest!
Its been posted that attacker said that the initial injection was via an administrator downloaded a malware infected utility.
Even if we put aside the topic of needing backups for all important data, or why these ransoms should NEVER be paid, I still have one question:
Is there ANY valid reason that Internet addresses in Iran can access systems for something like the SFMTA?
Sure, I know about proxies and that blocking IP addresses is not 100% foolproof. But known proxy sources like Tor exits CAN also be blocked which will reduce the risk.
I’m protecting my client’s systems from unwanted foreign traffic, why aren’t you!??!
This remind me of when preparing to travel from Europe to USA and neededing to search an address in yellowpages.com I discovered to have the IP range of my university banned.
Their assistance said that since I’m a foreigner they don’t give a damn.
We are turning more and more from internet to a nationalnet.
That. Still, maybe restrict who can access internal systems could help.
So then they compromise a system in the US to do their dirty work, or rent time on a US-based botnet. Their costs go up, sure, but ultimately its futile. US contains hackers the same as all countries contain hackers, and the US contains systems capable of being compromised the same as all countries. Nationalism will not help. The great firewall of China hasn’t helped China, it won’t help anywhere else either.
These organizations either aren’t taking IT seriously or have outsourced their IT to incompetent organizations. Patches from 2015 should have been a historic footnote in their patch log by the end of 2016.
Unfortunately at many organizations security is an afterthought. Even when upper management’s transgressions are exposed by acts like this, they often blame anyone but themselves. They, and only they, need to make it a priority. I would make upper management’s treasured bonus compensation contingent on the lack of security breaches (among other things). Nothing quite gets a suit moving like the specter of not being able to buy another ivory backscratcher.
Often its access to an external resource(server) that has further access to internal servers through improper network segmentation.
It’s amazing that this hacker didn’t even use VPN to hide his real email address, unless it’s an elaborate diversion tactic to use Iran IP and Islamic language for misdirection.
@Chris, because of the current shortage in IPv4 blocks, there is a large ‘market’ where the IP blocks are being sold, especially from poorer countries towards the richer ones (or towards cloud providers).
See this article of what can happen when people start acting on IP geolocation data..
In Dutch: https://decorrespondent.nl/2675/dit-gebeurt-er-allemaal-achter-de-schermen-als-je-naar-de-vs-vliegt/130264475-b9f887ba
In English: https://translate.google.com/translate?hl=&sl=nl&tl=en&u=https%3A%2F%2Fdecorrespondent.nl%2F2675%2Fdit-gebeurt-er-allemaal-achter-de-schermen-als-je-naar-de-vs-vliegt%2F130264475-b9f887ba&sandbox=1
The Dutch article is really good, but written in a style which makes translation difficult. Not least of the problems is that the man’s last name is “Pas”, which is also a common, and multi-definition word (meanings include “only just”, “access card”, and “to fit”) among others. I submitted a bunch of Google translate contributions, but they will take a while to wend their way through the system.
Gerrit,
Thank you for taking the time to do this.
Here’s another example in the United States… http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/
[quote]The attacker appears to be in the habit of switching Bitcoin wallets randomly every few days or weeks.[/quote]
A Bitcoin wallet is a collection of Bitcoin addresses. We really don’t know if he is switching wallets even when the addresses change. Also, it is common practice to use different addresses for different purposes. All in one Wallet.
So did the anonymous source not provide the answer to the password reset question or did you choose not to publish? I’m curious to know the rationale for either.
Geolocation based on source IP works. It does have some very small amount of collateral damage (desired traffic blocked) but the amount of bad stuff stopped far, far outweighs the good stuff stopped. Our spam percentage is around 70% when it was 98%+ when we did not geoblock. Our customer base is 100% USA so the only thing we block are internationally traveling customers or military personnel and we make exceptions for those when they advise us.
The amount of IPv4 blocks being horse-traded is still very, very small and if the user properly registers it, it will not be geo-blocked. This, of course, does not stop a global company with a /16 allocation from ARIN from using it worldwide but that is still a very, very small amount of traffic and an acceptable risk.
I use a random password generator to create an answer for any secret questions. Then I save this in password management software.
Even this can be unsafe. Read this comment (from a notorious cybercriminal covered on this blog): https://news.ycombinator.com/item?id=13018492
This is unsafe. See https://news.ycombinator.com/item?id=13052325
From now on all my secret answers will start with “beware of social engineering:” sheesh!
Maybe make a script or an excel spreadsheet that can randomly generate for you? I bet there’s info on the internet with info on how.
If I use a web password generator, I always mix up the order and change a couple letters too, just to make sure.
My recommendation, which is the method I’ve recommended to clients since 2011, is Diceware. To simplify I created an adaptation it using Excel and LibreOffice. Every account has a very strong unique passphrase using character superposition, always using greater than 15 characters, and those get stored in an encrypted spreadsheet that is on an encrypted drive. This method has been very effective in protecting client accounts and my own.
Diceware is at: http://world.std.com/~reinhold/diceware.html
The Excel/OpenOffice (though cobwebbed) versions are available here: http://happycattech.com/security-apps/spreadsheet-diceware-passphrase-generation
Great article , better then most of the ones on the internet regarding this news story .
Secret questions are just additional passwords and should be treated as such. I prefer to use the exact same methodology to generate answers for secret questions as I do any other passwords.
This works as long as the answers (pseudo-passwords) are unique. I’ve seen some sites that encrypt the passwords but not the “secret question” answers. When the site gets hacked (not if it gets hacked), all those secret question answers are going into the wild.
Very good recon Brian…and interesting read. Moreover, I wonder if the victims of the ransom paid it secretly without public visibility, and didn’t bother reporting it to the NCCIC or other government Cyber experts? Information sharing and reporting is being highly promoted (under anonymous conditions) by the government. I just don’t have good fidelity that companies are willing to do this. Maybe out of pride or embarrassment? Another great article.
Excellent reporting Brian.
“Reza” is the Arabic/Farsi spelling, “Riza” would be the Turkish equivalent.
Arabic would be Ridha or Rida. Reza is very Persian.
About geolocation blocking, and spam? Blocking cuts off all traffic from a location, a good spam filter let’s thru the business from that area. There may be customers there. After all, to cut off the major spam, one would have to block the US. Would you not?
So a good filter is needed. World wide businesses, would need some world wide solutions, not a cut off.
Jim,
Not all businesses in the U.S. do business world-wide. Some, due to the nature of their business have only U.S. customers and others are legally required to have only U.S. customers.
Does vigilante justice bother anyone else?
Usually, but since your question prompted me to consider the issue I’d say I’m more comfortable with vigilantism online than anywhere else. Not the mob-mentality ‘name and shame’ of social media, but the at least vaguely responsible white-hat hacking as described here. (Vague responsibility which doesn’t make it at all legal, but that’s on the vigilante’s head as usual – heck, even Bat Man has that problem.) I wouldn’t go so far as to condone hacking even an obvious miscreant’s email – but then I’m in the luxurious position of not having to, while still being able to find the results interesting.
I’m sorry but this is funny as hell. d00d gets a hefty dose of karma by losing control of 2 email accts and one server. hope his btc acct was attached to one of them
Obviously it’s important to keep your machines patched, just like locking your front door before leaving to go to work. When the bad guys come along testing every doorknob, you don’t want your door to open right up. You don’t want to be a low-hanging fruit.
But the reality is that any door lock can be picked and you will be hacked sooner or later. All you can do is limit your exposure and make recovery swift. Like Brian said, off-site backups and tested recovery procedures are the way to go.
” I just don’t have good fidelity that companies are willing to do this. Maybe out of pride or embarrassment?”
In my experience, a complete lack of confidence that the .gov can protect the data, anonymity, etc. is a major contributor to companies not being willing to share.
That’s kind of funny that the .gov had a working backup and recovered, but according the hackers own email, it’s the private sector that succumbs the most
Ok this is a very well written story, why can’t all journalists write like this??? Very thorough, accurate and good.
Great read. Interesting that the attacker is working with victims (post-payment) to help secure their systems. I would wonder if they are using that as a distraction to leave other potential security-holes open.
Or directing the victim to a booby trapped site where the attacker can install even more malware on the same or new victims computers. Why would you ever trust him?
Nice to have this extra detail on the ransomware attack against the SFMTA. As to the confusion about whether the perpetrator is Russian or Iranian, consider the possibility that he (probably not she) may be a Tajik.
The Tajik language is similar enough to Persian that scholars argue whether or not the two are different dialects of the same language. There are 200,000 Tajiks living in Russia, 6 million in Tajikistan and probably more than a million in Uzbekistan and the other Central Asian republics. A Tajik hacker in a former Soviet republic would fit with the mix of Persian notes and Yandex accounts.
I’m curious where Brian or his contact determined that +78234512271 maps to a Russian mobile provider. Most sources give +79 as the prefix for Russian mobile phones and say that +7823 is unallocated: http://www.itu.int/dms_pub/itu-t/oth/02/02/T02020000AD0002PDFE.pdf
It would be great to have Brian’s view on the response from SFMTA: https://www.sfmta.com/about-sfmta/blog/update-sfmta-ransomware-attack
In particular, the following statement stuck out to me:
“However, the SFMTA network was not breached from the outside, nor did hackers gain entry through our firewalls. Muni operations and safety were not affected.”
While that may be intended to comfort Muni riders, clearly the most likely scenario is that the network was breached from the outside (unless the malware came in on an infected USB stick or third-party device, which doesn’t really make things any better.)
Also, the statement that “Muni operations and safety were not affected” seems hard to support. At the very least, Muni was compelled to leave fare gates open all weekend, which itself amounts to an effect on operations (and revenue). That this action was taken indicates that there was some possibility that the fare gates could have been affected, so presumably they are not on an isolated network.
I do hope that the train control and signalling systems are fully isolated, and the age of the technology involved itself provides some assurance that damaging these would have been difficult. But to state categorically at such an early stage that there was no affect on safety or operations seems to be driven more by panic than by careful analysis.
The SFMTA’s statement about not getting hacked from the outside seems wishful, unless they consider internet-facing Oracle servers to be not external. They mean the trains still moved on time, not that there wasn’t a departure from the normal, I think.
My read of the reporting in SF leads me to believe they left the gates open because they couldn’t vouch for the security of the payment terminals because the attacker was still in the network, so they decided to close down the kiosks so as not to run that risk.
I would imagine the safety systems for the rail system is separate from any Internet-facing operations, but then again I’m far from a subway/railcar/transportation expert.
As they should be. Essential infra-structure should be tightly sealed off from pretty much any external modification unless from specific, secure points (ie: read only from outside the internal network). The fact that these systems were not affected is a positive thing for them.
Thanks for the response, Brian.
Your suggestion that “they left the gates open because they couldn’t vouch for the security of the payment terminals because the attacker was still in the network” makes a lot of sense.
Interestingly, they apparently only stopped collecting fares on the Metro portion of the Muni system. When I took a Muni bus on Saturday, I still had to swipe my Clipper card as usual. When I transferred to Muni light-rail at a station the fare gates displayed “Free Entry”. The mobile systems on buses are apparently only reconciled with the central system at the end of the travel day (at best), but that doesn’t mean they’re invulnerable to malware that it able to propagate over SFMTA’s network to these embedded systems.
I’m not sure whether the decision to open the fare gates was a consequence of the decision to turn off the ticket machines (to make sure people could travel even if they couldn’t buy tickets), or if there was a perceived risk that malware could be present in the fare gate systems. Certainly, the fare gates need to transmit usage data for Clipper and other RFID fare cards (and receive top-up data for some Clipper users). Whether they’re connected more directly to the SFMTA network is unclear.
I agree that Muni’s safety systems probably are and certainly should be isolated from all other networks (both public and internal corporate systems).
The Clipper system is independent of SF MUNI and was completely unaffected by the hack.
That’s what sh . . I was just gonna say, Contributor.
Internet-facing Oracle servers are not external, when you consider
them from the entire Universe’s POV, or the SFMTA spin doctors’.
🙂
Secret questions are certainly a problem, but so are draconian restrictions on passwords. For example, Delta Airlines does not permit any “special characters” to be used in passwords for its website.
Many sites are limiting password characters to only those characters found on most mobile devices. They don’t want people to set a password from a desktop and be unable to type the same password on most any cell phone. That situation might generate support calls from panicked users unable to type their passwords from the mobile browser or app.
I apologize for leaving this here, but I don’t know how to get in touch with Mr. Krebs to suggest subjects for articles.
I would love to read what he has to say about hacking voting machines. Has it been done? How would we know?
This would be an interesting topic and bring Brian huge traffic but would probably cause the site to turn into a Yahoo! message board on a bad day.