Two young men from the eastern United States have been hit with identity theft and conspiracy charges for allegedly stealing bitcoin and social media accounts by tricking employees at wireless phone companies into giving away credentials needed to remotely access and modify customer account information.
Prosecutors say Jordan K. Milleson, 21 of Timonium, Md. and 19-year-old Kingston, Pa. resident Kyell A. Bryan hijacked social media and bitcoin accounts using a mix of voice phishing or “vishing” attacks and “SIM swapping,” a form of fraud that involves bribing or tricking employees at mobile phone companies.
Investigators allege the duo set up phishing websites that mimicked legitimate employee portals belonging to wireless providers, and then emailed and/or called employees at these providers in a bid to trick them into logging in at these fake portals.
According to the indictment (PDF), Milleson and Bryan used their phished access to wireless company employee tools to reassign the subscriber identity module (SIM) tied to a target’s mobile device. A SIM card is a small, removable smart chip in mobile phones that links the device to the customer’s phone number, and their purloined access to employee tools meant they could reassign any customer’s phone number to a SIM card in a mobile device they controlled.
That allowed them to seize control over a target’s incoming phone calls and text messages, which were used to reset the password for email, social media and cryptocurrency accounts tied to those numbers.
Interestingly, the conspiracy appears to have unraveled over a business dispute between the two men. Prosecutors say on June 26, 2019, “Bryan called the Baltimore County Police Department and falsely reported that he, purporting to be a resident of the Milleson family residence, had shot his father at the residence.”
“During the call, Bryan, posing as the purported shooter, threatened to shoot himself and to shoot at police officers if they attempted to confront him,” reads a statement from the U.S. Attorney’s Office for the District of Maryland. “The call was a ‘swatting’ attack, a criminal harassment tactic in which a person places a false call to authorities that will trigger a police or special weapons and tactics (SWAT) team response — thereby causing a life-threatening situation.”
The indictment alleges Bryan swatted his alleged partner in retaliation for Milleson failing to share the proceeds of a digital currency theft. Milleson and Bryan are facing charges of wire fraud, unauthorized access to protected computers, aggravated identity theft and wire fraud conspiracy.
The indictment doesn’t specify the wireless companies targeted by the phishing and vishing schemes, but sources close to the investigation tell KrebsOnSecurity the two men were active members of OGusers, an online forum that caters to people selling access to hijacked social media accounts.
Bryan allegedly used the nickname “Champagne” on OGusers. On at least two occasions in the past few years, the OGusers forum was hacked and its user database — including private messages between forum members — were posted online. In a private message dated Nov. 15, 2019, Champagne can be seen asking another OGusers member to create a phishing site mimicking T-Mobile’s employee login page (t-mobileupdates[.]com).
Sources tell KrebsOnSecurity the two men are part of a larger conspiracy involving individuals from the United States and United Kingdom who’ve used vishing and phishing to trick work-at-home employees into giving away credentials needed to remotely access their employers’ networks.
Another example of why crime doesn’t pay; the criminals do unto each other as they do unto us. Poetic justice!
That’s what I call Dumb and Dumber. I’m glad these two dumb a$$s got caught. Now hopefully they’ll get the sentence that they deserve (and not just a slap on the wrist like we’ve been seeing lately.)
Peace not war
Treat others like you would want to be treated for we are all human. Oxoxo
wait… so the web portal T-Mobile employees actually use doesn’t require 2FA
or did the phished employees just use their creds and when they didn’t get logged in they failed to report that?
ouch – either way
Phishes are often sophisticated enough to run session stealers that not only steal login credentials but the actual logged in session as well. This is necessary for platforms that allow for 2FA. It is quite simple – once the victim clicks the login button, the phishing server sends a login request to the spoofed site with victim’s credentials upon which the actual site will respond with a 2FA prompt. The phishing server will recognize that the certain victim has 2FA and then it will prompt the victim to enter 2FA value on the phish itself! This stolen 2FA code will then be used by the phishing server to fully complete login authentication thus rendering 2FA useless.
Typically these phishes will also then redirect the victim user to actual domain and if the victim already has an existing login session to the spoofed site, they will be directed to their homepage, see that they are already logged in and not be able to suspect a thing.
That is why I use IBM end point protection call “Trusteer” – It is the only product I’ve tested that passes all AKLT tests to prevent screen or video capture, and password entering; no matter whether infected or not. I’ve been using the free personal one for years with no problems. I am not a shill for IBM, and no one pays my bills but me.
Use of FIDO2/U2F or other hardware credentials for 2FA would have stopped this type of attack. The MITM would not have been able to be successful. Given that every Android phone can be a FIDO credential at no additional cost, moving to FIDO should really be considered.
No, it will not. That’s because this works by stealing and using your credentials in realtime, not offline.
Let’s say I trick you into signing in on my site. I send your credentials to the real site, the real site asks for the 2FA code. I simply relay that request to you, and submit your response. I’m not sure how you think 2FA protects against this sort of MITM attack.
What you need to protect against a MITM attack is a 2FA that’s entered via a different means. So you enter your credentials on the website but enter your 2FA by texting or calling a known number. There’s very few services that implement 2FA in this manner so if you can be tricked into using a fake site, most of the time, you can also be tricked into giving up your 2FA.
Even that is difficult. This very site has published a story where the scammers called the bank, impersonated the victim, had the victim on the phone, and so when the bank requested a 2FA code, they had the victim give it to their colleague on the phone. In this case, the victim screwed up by giving up information in a channel where he did not initiate the connection.
You do not understand how U2F works. It is NOT as basic as typing in an ever changing code. Your comment is entirely incorrect in relation to FIDO U2F.
Smiles November 3, 2020 at 7:34 pm
Phishes are often sophisticated enough to run session stealers that not only steal login credentials but the actual logged in session as well. This is necessary for platforms that allow for 2FA… This stolen 2FA code will then be used by the phishing server to fully complete login authentication thus rendering 2FA useless….
(and)
zboot November 4, 2020 at 3:32 pm
I trick you into signing in on my site. I send your credentials to the real site, the real site asks for the 2FA code. I simply relay that request to you, and submit your response….. What you need to protect against a MITM attack is a 2FA that’s entered via a different means. So you enter your credentials on the website but enter your 2FA by texting or calling a known number. There’s very few services that implement 2FA in this manner so if you can be tricked into using a fake site….
(and)
Steve November 4, 2020 at 7:14 pm
…do not understand how U2F works. It is NOT as basic as typing in an ever changing code. Your comment is entirely incorrect in relation to FIDO U2F.
After reading Smiles’ comment regarding session stealing servers/software, zboot’s comment I am a bit curious as to how the whole thing actually works. I will acknowledge that it is happening but the exact details remain unclear.
I tend to basically agree with Steve’s comment.
This subject has come up before here and after talking with a couple of large company’s tech guys using upper-end firewall equipment, the impression I got was the SSL/TLS session crypto-token contains a lot of data including machine type, browsers type, IP, MAC, time stamps and so on. This data must correspond to the 2F pin data, including the machine and browser type, IP, time stamp and possibly location data to scam the real session and fool the actual server of the telephone company.
I am at loss to explain how all of this data is stolen or copied… unless individual at T-mobile are helping the attackers and supplying time data and so on. But, with complex “session stealers” in the loop it appears to be happening. I would like to know how these “session stealers” actually operate. Anybody care to explain said session stealers?
I currently use a U2F implementation, and yes while you are correct its capabilities exceed just matching a changing code, it depends on whether those capabilities are actually used to their full extent, for example, one of the enterprise solutions I use requires U2F but it does not ask that I authenticate my session by accepting the login request on the same IP or machine – this is not possible for me as not only are my logins on a different network than my phone, but I must login on a device that is not my phone. So in my case, I am still vulnerable to MITM.
Sure location data is great to have but again not only is my login request technically from a different location, but attackers can also still get around this with the use of proxies.
Session stealing is nothing complicated, my apologies for not explaining, its just that attackers now dont primarily rely on stolen credentials but rather the session itself. When you login to most platforms like your email account, Netflix account, etc – after your login attempt is successful the webservice you are authenticated into returns a session – typically in the form of cookies stored in your browser. These sessions are very rarely tied to an IP address meaning if I were to login on one IP address and then swap networks, the session still remains valid – this is something attackers may leverage to a great extent. All a session is really is just a set of cookies that services use to authenticate users.
Smiles November 5, 2020 at 12:30 pm
“…while you are correct its capabilities exceed just matching a changing code, it depends on whether those capabilities are actually used to their full extent…attackers now dont primarily rely on stolen credentials but rather the session itself. When you login to most platforms like your email account, Netflix account, etc – after your login attempt is successful the webservice you are authenticated into returns a session – typically in the form of cookies stored in your browser. These sessions are very rarely tied to an IP address meaning if I were to login on one IP address and then swap networks, the session still remains valid – this is something attackers may leverage to a great extent. All a session is really is just a set of cookies that services use to authenticate users. U2F but it does not ask that I authenticate my session by accepting the login request on the same IP or machine – this is not possible for me as not only are my logins on a different network than my phone, but I must login on a device that is not my phone. So in my case, I am still vulnerable to MITM… location data is great to have but again not only is my login request technically from a different location, but attackers can also still get around this with the use of proxies.” -Smiles
Wow, I did not know that telephone companies allow logging from IP x in location 1 and IP y in location 2 at the same time and allow a SIM swap…unless I mistook your explanation.
For example but not a good example, if I log on to my bank account from computer A and put it my user name and password and the bank ask for a pin number from a phone – then I move to a computer B with a different browser and IP log on to the bank and enter my credential again and the pin from my phone the session is disconnected and the log on process restarted from scratch. If I just change browsers on computer A from the same IP the session with my bank will be disconnected – even working from a fake bank site server with two people working with a session sealer. I would assume the phone company has the same security process – but apparently with session stealers in the loop it the MITM attack works.
I guess the simple way of explaining the hole in the security of “capabilities exceed just matching a changing code” is to use the chip and pin example where a person goes to a store that has a chip and pin merchant terminal only to eventually get the customer with good chip n pin card to swipe the mag-strip via a slider on the side of the terminal and by passing all of the chip and pin security – while saying they have a chip and pin terminal. If am way off base please correct me.
There is a bit of confusion here. The use of certain terms tend to muddy the waters here. Let’s see if I can clarify and get agreement.
“Phishing” is a broad term. Generally its something that gets the victim to interact (link in an email for example) and gets the victim to browse to the attackers website. It can be called a “phishing site”, but I prefer to call it a “spoofed” login webpage.
The “Session” is handled by the browser. And default security setting for both the browser and web servers… should ensure that visiting a “spoofed” site, cannot steal a “session”. Secure storage / cookies are mantained in the browser, and other websites cannot access them, as they would violate CSP/CORS.
So it looks like the above conversation is NOT using the term “session stealing” correctly. This attack certainly is a thing, but generally requires malware on the endpoint or a compromise of either the victim’s computer, web browser, the legit web server, or for a full MITM/MITB. Not the phishing and spoofing of this attack.
“Device fingerprinting” is another concept being discussed. I have not seen many websites utilize this. But I have seen it used for anti-fraud stuff. There is a benefit, because an attacker would need to enumerate information from the victim’s browser. It can cause a fraud alert if the attacker were to just attempt to relay stolen creds/OTP from their own system without first matching device fingerprint.
Keep in mind this is NOT the same as IP whitelisting. Source IP can inform the fraud team and cause alerts if mismatched. But I don’t know of anyone who will reject authentication because the IP wasn’t expected. Also, it is not common for an existing session to be tied to a source IP.
How does 2FA get compromised?
If using OTP (One time pad) rotating codes… yes, a spoofed website can relay/replay the username/password and OTP. It takes more work, because unlike a static password which can be harvested for later use, the attacker must set up the relay beforehand to use the OTP in real time (within 30 seconds).
U2F/FIDO2 solves this very problem. While OTP relies only a preshared secret key, U2F and FIDO2 also incorporate elements of the server’s domain into the challenge to the token. So the spoofed site does not work, since it doesn’t own the domain, it cannot properly challenge the victim’s U2F/FIDO2 token. The browser takes care of this, and doesn’t inherently trust the server.
It basically comes down to validation. OTP validates only the user, while U2F/FIDO2 will validate the user and the server. Oversimplified, but it thwarts the typical “spoofed” login webpage attack.
So the reason this does not work is because, the whole attack is automated. 2FA prompt on the phish only comes up to the victim when the phishing machines detect that the victim credentials need 2FA.
ex. hotmail does not have mandatory 2FA, so if one wants to make a good phish, the harvested user credentials are immediately used in a login attempt – this login attempt will result in a success/fail/2FA prompt. So upon this response the phishing page can respond accordingly – “oh your password is wrong, try again” or “2FA is required please enter your dynamic 2FA key eg. Google Auth” – if the victim enters in the code or verifies via U2F eg. Ping Authenticator – then the attack is successful.
This sort of attack is honestly now very common, my friend fell victim to this as her Steam account was stolen. Steam account security is pretty decent with required 2FA on any asset transfers and logins but same issue as detailed above, the attack happened instantaneously, it did not matter that the 2FA key changed every 10 seconds, the phish itself was able to authenticate itself into her account immediately because the login attempt/session was happening in real time, as she entered her credentials.
Possible mitigation includes IP geolocation of the login attempt and presenting the user with the login attempt’s rough location. Of course this can be bypassed with a large enough array of proxy locations but that seems rather hard to do.
Smiles November 5, 2020 at 12:19 pm
“…the whole attack is automated. 2FA prompt on the phish only comes up to the victim when the phishing machines detect that the victim credentials need 2FA… victim enters in the code or verifies via U2F eg. Ping Authenticator – then the attack is successful… attack is honestly now very common… decent with required 2FA on any asset transfers and logins but same issue as detailed above, the attack happened instantaneously, it did not matter that the 2FA key changed every 10 seconds, the phish itself was able to authenticate itself into her account immediately because the login attempt/session was happening in real time…”-smiles
I am surprised by the nature and complexity of this attack – but not really surprised. When U2F came out it was well documented and sometimes misunderstood. All I can say it is in the wild and happening. Further, it is happening on SSL/TLS sites somehow. B. Krebs should look into situation and find ways to block it. The “real-time” part is very troubling.
Smiles November 3, 2020 at 7:34 pm
Phishes are often sophisticated enough to run session stealers that not only steal login credentials but the actual logged in session as well. This is necessary for platforms that allow for 2FA… This stolen 2FA code will then be used by the phishing server to fully complete login authentication thus rendering 2FA useless….
(and)
zboot November 4, 2020 at 3:32 pm
I trick you into signing in on my site. I send your credentials to the real site, the real site asks for the 2FA code. I simply relay that request to you, and submit your response… you need to protect against a MITM attack is a 2FA that’s entered via a different means. So you enter your credentials on the website but enter your 2FA by texting or calling a known number. There’s very few services that implement 2FA in this manner …you can be tricked into using a fake site….
(and)
Steve November 4, 2020 at 7:14 pm
…do not understand how U2F works. It is NOT as basic as typing in an ever changing code. Your comment is entirely incorrect in relation to FIDO U2F.
After reading Smiles’ comment regarding session stealing servers/software, zboot’s comment I am a bit curious as to how the whole thing actually works. I will acknowledge that it is happening but the exact details remain unclear.
I tend to basically agree with Steve’s comment. This subject has come up before in this blog and after talking with a couple of large company tech guys using upper-end firewall equipment, the impression I got was the SSL/TLS session crypto-token contains a lot of data including machine type, browsers type, IP, MAC, time stamps and so on. This data must correspond to the 2F pin data, including the machine and browser type, IP, time stamp and possibly location data to scam the real session and fool the actual server of the telephone company. I am at loss to explain how all of this data is stolen or copied… unless individual at T-mobile are helping the attackers and supplying time data and so on. But, with complex “session stealers” in the loop it appears to be happening. I would like to know how these “session stealers” actually operate. Anybody care to explain said session stealers?
So, if you’re going to scam US citizens, don’t do it from a US location. It didn’t work for Daft Pirate Roberts and it won’t work for you.
Also, don’t out yourselves.
Best of luck. Seems your going to need it with your pea-sized brains.
‘Stupid is as stupid does.’
Young script kiddies will never learn , the “autism” excuse will be coming shorty as a defense in what they did.
1. How do I defend against SIM card attacks?
2. Why do so many sites only offer text message 2FA and is that better than nothing?
Well crypto exchanges such as Coinbase now allow device based 2FA like Google Authenticator which is nice.
Cell providers like Verizon have this PIN system which supposedly forces all changes made to the account to be manually verified by the account holder as they are the ones with the PIN, but seeing as how prolific these attacks are, there may be a way around it… There is also a “no-port” option available on some USA carries but no idea which specific ones support it. That option is supposed to prevent your number being ported elsewhere, am not sure if it actually prevents sim swapping as the language around it seems vague.
No port means you can’t port that number to another carrier. Changing phones within the same carrier isn’t porting the number, it’s just changing a SIM. Since they’re using employee tools a lot of restrictions go out the window since they’re mimicking employees.
Depending on the carrier employees may not be challenged for PINs when changing SIMs, it can be a separate process that they go through in order to verify the customer’s PIN before they fire up the SIM tool… security as an afterthought is in vogue in corporate america because it leaves more money for executives to take as bonuses. Maybe they don’t do this anymore, I dunno, I just eyeballed the back glass wall of my carrier once as I was swapping phones and saw basically what he was doing on his screen. Yeah, not a great layout for their store, for some reason I’m not with that carrier anymore.
In this case where the attackers are using stolen employee credentials to execute the sim swap it might not matter if there is a pin code protecting your account, as some mobile carriers do not store them as a hash like a password would be. There was a Youtube channel called “h3h3productions” that went into detail about their experience with getting sim swapped and he outlines that not only was the attacker able to retrieve the pin code protecting the account, but actually purposefully triggered the mobile carrier into contacting h3h3 to add a pin, presumably because it was easier to execute the attack on an account this “security” feature.
https://www.youtube.com/watch?v=7IHp1OT3U_s
Rappers are on the “rap-about-scams” game, I always expect more identity based fraud crime than I hear about.
“There is no honor among thieves” – dates back at least to Cicero, about 50 BCE.
“Depends on the thieves..” -Conan
“I didn’t not inhale” -Clinton
sim swapping? no we’re swimming out here in 2020
A bit off topic but I recently got text messages and voice mail from people saying they are part of “Chase Escalation/Complaint” department. I don’t recall making any complaints (only have ccs with them).
So one day I called the number on the cc and ask if there were any issues with my accounts and they said nope.
Then a couple of weeks ago I get a letter that looks to be from Chase (has their logo and stuff on it, sure could be easily faked) saying they were closing the case and provided a case # but no account info (not even the last 4 digits).
That made it seem more legit so I called the number on the letter but the office always seemed closed (asked me to leave a voice mail) or provided some long extension I was supposed to dial but I never did.
So I called Chase directly (not the # on the letter) and again they had no record of anything and suggested I scan the letter and email it to their fraud address. I plan to do that this weekend (need to set up the scanner since I recently moved).
Seems like a pretty elaborate scam if it is one but nothing really adds up for it to be legit.
Anyone else have anything like this happen?
Your fake snail mail message is troubling; I’ve never heard of scams like that. Maybe it is a new way of “spear” phishing? I never return a call or call a number that is suspicious, because once you do that, you condemn your number as a mark for spam calls and all kinds of grifters!
I had a buddy that was always doing that, because he hated such calls so much he couldn’t help but call them back and complain; after changing his number about 30 times he finally realized he needed to stop returning suspicious calls, and finally got some peace.
I suppose if your phone service has a whitelisting feature or other call blocking technology it could be worth the chance, but I NEVER answer numbers that I don’t know, even though I have a call blocking service. Criminals can fake the caller ID on land lines and cell phones, so sometimes you can’t even trust that – but so far they are only numbers with similar area codes or the later suffix three number designations to attempt to fool the person called into thinking it must be someone they know, despite the number not quite matching anyone they know.
I had one incident that occurred, from a phone thief who had tied into that same buddy of mine’s landline and he recorded all of his contact numbers on a wireless phone patched into his telephone box!!! When my buddy interrupted this criminal in the alley, he didn’t think anything of it, but the thief removed his wireless base and started harassing calls to all the people on his phone list, using a throw away burner cell phone with the fake caller ID app installed on his phone. I was one of the victims of that scam, and called the police to tell them, a child had called me wondering why I was calling their family phone. I knew the only way my number could be on the caller ID was if something like this was possible. I told the police to check up on the child, because I assumed she was not being supervised by her parents or guardian and was worried this sicko might try something worse. Of course my phone records did not show me contacting this household at all. So the police knew I was telling the truth; and they at least made sure the victim was safe; but there was no way of tracing such a call in that incident. There are a lot of sicko people out there that do this for no monetary gain and just need to be put in a mental institution, I guess.
Smiles November 3, 2020 at 7:34 pm
Phishes are often sophisticated enough to run session stealers that not only steal login credentials but the actual logged in session as well. This is necessary for platforms that allow for 2FA… This stolen 2FA code will then be used by the phishing server to fully complete login authentication thus rendering 2FA useless….
(and)
zboot November 4, 2020 at 3:32 pm
I trick you into signing in on my site. I send your credentials to the real site, the real site asks for the 2FA code. I simply relay that request to you, and submit your response….. What you need to protect against a MITM attack is a 2FA that’s entered via a different means. So you enter your credentials on the website but enter your 2FA by texting or calling a known number. There’s very few services that implement 2FA in this manner so if you can be tricked into using a fake site….
(and)
Steve November 4, 2020 at 7:14 pm
…you do not understand how U2F works. It is NOT as basic as typing in an ever changing code. Your comment is entirely incorrect in relation to FIDO U2F.
After reading Smiles’ comment regarding session stealing servers/software, zboot’s comment I am a bit curious as to how the whole thing actually works. I will acknowledge that it is happening but the exact details remain unclear.
I tend to basically agree with Steve’s comment. This subject has come up before in this blog and after talking with a couple of large company tech guys using upper-end firewall equipment, the impression I got was the SSL/TLS session crypto-token contains a lot of data including machine type, browsers type, IP, MAC, time stamps and so on. This data must correspond to the 2F pin data, including the machine and browser type, IP, time stamp and possibly location data to scam the real session and fool the actual server of the telephone company. I am at loss to explain how all of this data is stolen or copied… unless individual at T-mobile are helping the attackers and supplying time data and so on. But, with complex “session stealers” in the loop it appears to be happening. I would like to know how these “session stealers” actually operate. Anybody care to explain said session stealers?
moderator, feel free to delete Dup. comments.
You’d think they would require VPN’ing with Internal network IDP/SSO configuration so that these admin users would have to be inside the company network in order to log into a site like this.
Whatever, some people should sue them until their security folks get it right.
That is the thing that I call Dumb and Dumber. I’m happy this two stupid a$$s got captured. Presently ideally they’ll get the sentence that they merit (and not simply a token punishment like we’ve been seeing recently.)
This should be done to the scammers to improve the online world.