Facebook and Google were conned out of $100M in phishing scheme(theguardian.com)
theguardian.com
Facebook and Google were conned out of $100M in phishing scheme
https://www.theguardian.com/technology/2017/apr/28/facebook-google-conned-100m-phishing-scheme
66 comments
I used to do Accounts Payable for a large tech company. Any invoice >$5,000 had to be matched to a PO. POs had to be approved by an appropriate level. Payment information was maintained by a separate team and POs were linked to that payee. Nearly all payments were done via ACH; we actively discouraged wire transfers wherever possible by charging ridiculous fees. The payment process itself was also audited daily by the payments team. We also had an entire org of finance people responsible for controllership. This fraud would have been hard, though not impossible to pull off in this system.
Sounds like a lot of sv companies don't have the internal oversight /internal security taken for granted by older companies.
Given this story I would bet there is a fair bit of undiscovered internal fraud at google and fb
Given this story I would bet there is a fair bit of undiscovered internal fraud at google and fb
Same, I did accounts for a government department once.
But it is amazing how bad some private companies accounts are. We ended up effectively advising them on their accounts receivable.
The thing about this particular scam is the size; no-one goes hunting for POs and invoices for $100m. (or everyone assumes someone else has). It's the success of the big lie.
But it is amazing how bad some private companies accounts are. We ended up effectively advising them on their accounts receivable.
The thing about this particular scam is the size; no-one goes hunting for POs and invoices for $100m. (or everyone assumes someone else has). It's the success of the big lie.
I hope someone writes a book or they make this one into a movie. It would be awesome if the scammers had an account name using a very similar name or a unicode hack. Too bad they didn't have a better getaway plan.
Note to self: when fishing, send multiple invoices of $4000.
I wrote an application that's primary function is reclamation of unclaimed AP credits / duplicate payments. You might be surprised by how much space there is for better controls here in large (Fortune 500) companies.
Also look out after any publicized fundraising. The phishing attacks begin with similar things where people impersonated the CEO to the head of finance pretty much a few months after fundraising. They know the small companies don't have the same sized finance & legal teams.
Public key cryptography of any sort would also probably help here. PGP keys on their website, Facebook page, annual report?
Blockchain?
Blockchain?
Blockchain would be WORSE because you have much less of a shot at reversing and recovering the fraudulent transactions.
True, but can't you still trace the transactions as they are processed or converted into real cash?
Bitcoin tumblers obfuscate the trail
Tumbling $100 million seems slightly painful.
Blockchain doesn't seem like the most appropriate solution here because what you really care about is basically document signing. The ledger can be maintained by a central authority (accounts payable).
If a vendor sent their bank details via a signed message in the block chain then a change of bank details could be arranged by sending a new signed message from the same address with the new details. Obviously it would need to be agreed in advance that this is the method of changing payment details, then the buyer can absolve responsibility to the vendor as it will require the vendor to maintain security of their private key.
A blockchain wouldn't improve the security of sending a signed message at all it just provides a shared storage of the message.
In a former life I worked with a large procure-to-pay ERP system, and we were even stricter.
Vendors had to be pre-approved and their bank details managed, who were explicitly matched to POs, explicitly matched to invoices, and finally... invoices had to be matched to inventory receipts before any sort of payment was triggered. POs had to be approved by someone internally with specific approval levels as well.
Not sure if we were insanely overboard but... no idea how this happened.
Vendors had to be pre-approved and their bank details managed, who were explicitly matched to POs, explicitly matched to invoices, and finally... invoices had to be matched to inventory receipts before any sort of payment was triggered. POs had to be approved by someone internally with specific approval levels as well.
Not sure if we were insanely overboard but... no idea how this happened.
A guy I used to work with emailed the CEO of our company, a certain cloud software shop with thousands of employees, asking for the company to buy him a plane.
There was some more to it, about using it to participate on a competition representing the company, but it was absolutely ridiculous.
Instead of the email getting filtered out right away, the story goes that it rolled downhill through several layers of management, and apparently, people were asking each other "who is this guy? do we need to buy him a plane?"
There was some more to it, about using it to participate on a competition representing the company, but it was absolutely ridiculous.
Instead of the email getting filtered out right away, the story goes that it rolled downhill through several layers of management, and apparently, people were asking each other "who is this guy? do we need to buy him a plane?"
What? So he an actual employee and wasn't phishing or committing fraud? And asked the company to buy him an airplane?
If you don't ask you don't get.
Sounds like they knew he wasn't an employee. What they didn't know was if he was associated with some high profile account and whether an employee (generally in sales or marketing) had inadvertently signed up the company to sponsor the guy in that competition.
Better to check internally (and chew out your employee for overpromising if needed) than to accidentally jeopardize a large account by calling the guy a fraud or ignoring him and it turning out to be true.
Better to check internally (and chew out your employee for overpromising if needed) than to accidentally jeopardize a large account by calling the guy a fraud or ignoring him and it turning out to be true.
He was an employee
Never hurts to ask!
You miss every shot you don't take.
Stealing the money => 10% of the work.
Laundering the money and not getting caught => 90% of the work.
The dude made a big fraud and got caught in 5 minutes. That's amateur hour.
Laundering the money and not getting caught => 90% of the work.
The dude made a big fraud and got caught in 5 minutes. That's amateur hour.
If he wasn't caught, I doubt we would have heard about it.
Sure, but when 'big' is $100M, I wouldn't really call that amateur.
It's amateur hour. There's a sort of paradox: It's actually easier to steal a lot more money. The problem is that draws eponentially more attention and the likelihood of getting caught grows to the point where it's pretty much guaranteed.
If they'd done $1M nobody would have heard about it, nobody would bother investigating too thoroughly, and they'd just shrug and move on.
The "pro" thing to do is to take your $1M and walk away even though you know there's more money at that tap.
There's a lot of casino cheats that talk about their craft. The good ones work extra hard to give the constant illusion of losing money which helps them win a little bit more without drawing too much attention. There's a whole art to knowing where the line is and not crossing it, flying completely under the radar.
That's what professionals do.
If they'd done $1M nobody would have heard about it, nobody would bother investigating too thoroughly, and they'd just shrug and move on.
The "pro" thing to do is to take your $1M and walk away even though you know there's more money at that tap.
There's a lot of casino cheats that talk about their craft. The good ones work extra hard to give the constant illusion of losing money which helps them win a little bit more without drawing too much attention. There's a whole art to knowing where the line is and not crossing it, flying completely under the radar.
That's what professionals do.
The real professionals are the ones who don't talk about it.
You only become a pro when you actually get money.
Ah, that's fair. Wasn't thinking literal definitions of pro/amateur.
Really? I'd agree if he weren't caught.
[deleted]
This does not sound like phishing to me. It's not like they mistakenly gave their banking credentials away.
Agreed. This scam originated long before the internet existed. Businesses have long been warned to watch out for fake invoices. They're usually for office supplies and <$500, but the scam is very old.
A common variation on the them is where they actually ship some low value item, wait just long enough for UCC return rights to expire and then send a ridiculous invoice. If ignored, a threatening follow-up comes that includes the proof of delivery of the item and late penalty threats. The item was usually shipped signature-required, so the proof more intimidating. (If you're wondering, the law is generally still on your side but you shouldn't just ignore the letters and keep the item even though they will likely give up anyway.)
A common variation on the them is where they actually ship some low value item, wait just long enough for UCC return rights to expire and then send a ridiculous invoice. If ignored, a threatening follow-up comes that includes the proof of delivery of the item and late penalty threats. The item was usually shipped signature-required, so the proof more intimidating. (If you're wondering, the law is generally still on your side but you shouldn't just ignore the letters and keep the item even though they will likely give up anyway.)
How would criminals actually get away with this kind of scam? Where do you hide $100m?
It essentially gets moved around banks, at each stage the account owner is taking a cut but ultimately it requires a friendly bank to hold the majority of the funds and not give it back when requested, usually because you have set up some kind of plausible route for the funds to be in your possession.
https://en.m.wikipedia.org/wiki/Bangladesh_Bank_heist
$81m was sent to a bank in the Philippines and less than 25% was recovered. Other banks had success is recovering all the funds sent through them as part of the same heist.
https://en.m.wikipedia.org/wiki/Bangladesh_Bank_heist
$81m was sent to a bank in the Philippines and less than 25% was recovered. Other banks had success is recovering all the funds sent through them as part of the same heist.
Well the one in the article didn't, so there's your answer?
well... unless it was shot in the blue sky - how did someone plan to launder that much money? i mean such amount will certainly attract attention from local bank, wouldn't it?
I doubt they thought it would really work so hadn't actually thought through how to launder the money. On the other hand, it was Lithuania so who knows how hard or easy it might be there.
I'm sure there are any number of bankers in various countries who would gladly help you out for a 30-50% cut.
If I was in the con game and knew a loophole to get my hands on $100m, I doubt I'd wait around too long to figure out all the details and risk the loophole being closed.
Also, side note, you have to wonder if the conman had some detailed insider knowledge of existing legitimate PO #s, like from the actual vendor's insecure systems. Hack a vendor, get PO #s and beat them to sending the invoice. Hope you get the money and can disappear faster than the vendor sends his invoice and alarm bells go off.
I'm sure there are any number of bankers in various countries who would gladly help you out for a 30-50% cut.
If I was in the con game and knew a loophole to get my hands on $100m, I doubt I'd wait around too long to figure out all the details and risk the loophole being closed.
Also, side note, you have to wonder if the conman had some detailed insider knowledge of existing legitimate PO #s, like from the actual vendor's insecure systems. Hack a vendor, get PO #s and beat them to sending the invoice. Hope you get the money and can disappear faster than the vendor sends his invoice and alarm bells go off.
What's wrong with Lithuania?
Sorry, on re-reading I can see how my comment could be read as somewhat dismissive or insulting of Lithuania. I meant it quite the opposite and more literally as in it's not a well-known data point, so there aren't a lot of people who can speak to the subject of whether money laundering is more or less difficult there vs. the US.
Nothing. It's not a part of the Soviet Union anymore. Granted, it's the poorest of the baltics, but it's still a civilized place.
right, it was a half baked plan, but its not impossible. typically you would want either a corporate account in a country with little accurate banking information required, and then you would obfuscate the origins with casinos. (Fake players losing, or simply exchanging large amounts of chips which have no record of ownership, but this is a nuance because it only need to happen on paper)
To get it back to you in large amounts as clean money, you would need to have another corporation that contracts with the casino or other service provider, and it is paid with money that is clean for all intents and purposes.
To get it back to you in large amounts as clean money, you would need to have another corporation that contracts with the casino or other service provider, and it is paid with money that is clean for all intents and purposes.
Basically what Bitcoin laundering does: create a bunch of users, route the money in small transactions a million times, and repeat the process. Except what you're also suggesting is doing it in a country where that specific information would be obscured even further.
yeah I didn't want to derail the discussion with cryptocurrency, as it is better and requires less cooperation, between partners.
but the problem here is the name on the bank accounts even if you wanted to get to cryptocurrency, you would really want a nominee director on the corporate bank account, but then you have to trust they don't take the money (there are plenty of reputable ones though).
if you had that much in cash already then you could buy mining hardware. set up a solar powered mining farm and get cryptocurrency over the next 6-12 months, then you have the liquidity. if you are interested in national currency and bigger material things, then you will still need to contract w/ a crypto-service so that you could report income, but the crypto-service's funding source would be a deadend for auditors.
There are many reasons to mine at a loss.
but the problem here is the name on the bank accounts even if you wanted to get to cryptocurrency, you would really want a nominee director on the corporate bank account, but then you have to trust they don't take the money (there are plenty of reputable ones though).
if you had that much in cash already then you could buy mining hardware. set up a solar powered mining farm and get cryptocurrency over the next 6-12 months, then you have the liquidity. if you are interested in national currency and bigger material things, then you will still need to contract w/ a crypto-service so that you could report income, but the crypto-service's funding source would be a deadend for auditors.
There are many reasons to mine at a loss.
Or a country where you can bribe some clerk to "lose" the paper work. So basically anywhere.
The Guardian is reblogging original content from http://fortune.com/2017/04/27/facebook-google-rimasauskas/
Admins, please change the link.
Admins, please change the link.
Does this actually count as "reblogging"? If an independent news agency writes a substantial story about something a separate news agency covered first, I wouldn't think that's reblogging.
I'm very naive to how large sums of money transfer. But couldn't you presumably do a public and private key share with your suppliers and validate every transaction request?
I hear about a kind of phishing at my company. It is as primitive as pretending to be our CEO, who is trying to reoncile an invoice for a supplier.
I hear about a kind of phishing at my company. It is as primitive as pretending to be our CEO, who is trying to reoncile an invoice for a supplier.
The last time this came up, the same thing was suggested. Someone brought up that whoever needed to verify the keys would eventually stop doing so unless the key verification process could be automated from beginning to end.
The argument was that the person who needed to verify the key wouldn't be bothered to actually verify. The key would be so commonplace that as long as a nonsensical string of characters appeared, the verifier would check the box using the it's-good-enough mentality. The crux is still the same: fool the human, get the goods.
The argument was that the person who needed to verify the key wouldn't be bothered to actually verify. The key would be so commonplace that as long as a nonsensical string of characters appeared, the verifier would check the box using the it's-good-enough mentality. The crux is still the same: fool the human, get the goods.
Well, then you make them personally responsible and liable - likely having a third-party company who provides the verifier and keeps a close eye on them? They'd also be liable. That could be a very successful company if you get the fortune 1000 on board.
You can make me personally liable all you want for the transaction, but if you think you can recoup $100M from me, good luck.
Hence why needing to be associated with a larger 3rd party company who'd be insured + have fortune 1000 clients.
This is called an escrow company. They've been around for about 500 years. They're not cheap.
I am currently working on a project that hopes to more fully digitise inter-organisational trading and workflows (corda.net).
There are numerous problems to solve to make this kind of attack unviable. The key thing to understand is that whilst the software industry has done a good job of automating and improving intra-business work, through things like office and enterprise software, it's had relatively little impact on inter-business work, which is still mostly paper based. Even when workflows are theoretically digitised, it's often simply by sending scans of paper forms or Word/PDF files via email. There are exceptions in the travel and financial industries (with SABRE and SWIFT respectively), but those are relatively restricted networks - for instance I doubt Google or its suppliers are directly connected to SWIFT.
There's some low hanging fruit. Email has DKIM and DMARC. Deploying these widely would make the From header reliable, at least assuming unhacked machines. It isn't intuitive that the From header can't be trusted and office workers typically assume that it is ... after all, it's normally correct and why would something as critical as email allow anyone to impersonate anyone else? But by default, it does.
Unfortunately DMARC is a fairly recent standard and the email space is quite stagnant, so many organisations don't use it, making email-based phishing trivial. It also hits the problem that lots of organisations have developed insecure mail practices over time in which impersonation is common, like marketing firms that send email on another organisations behalf, so deploying DMARC isn't as simple as just switching it on. It can often take months to track down and fix all the mail being sent with a "From: [email protected]" header but which actually wasn't sent by foo.org servers. That means it's a project that needs a budget, and that in turn means it often doesn't get proposed or worked on. Especially because the victims of email phishing are typically other companies, not the company being impersonated.
But because DKIM and DMARC are fundamentally based on digital signatures, and because the workflows being attacked are so often email based, setting up DKIM/DMARC is one of the best practical ways to secure modern business.
Now ... longer term, email with Word documents attached is not a solid base on which to link businesses together, DKIM/DMARC or not. It's hard to automate. It's very susceptible to human error. It suffers strange limitations, like tiny attachment sizes. Organisations often mutilate it, like with mandatory headers/footer legal disclaimers that are larger than the messages itself, or with vacation responders that don't understand mailing lists. And as nobody really coordinates or is responsible for the email network, nobody is incentivised to improve it. When improvements happen, they happen slowly and mostly because Google or Yahoo employees made it happen through sheer force of will.
Corda is an open source project that is trying to build a new inter-business network, focused (for now) on finance. So things like invoicing and bill paying is very much in scope. It uses digital signatures and encryption pervasively from the start. It takes a lot of inspiration from Bitcoin and the block chain space, although it does not use chains of blocks or proof of work itself. Some of what it does is focused on building a kind of shared global database, albeit one with rather different properties to a normal database, but part of what it does is make it easy to build structured workflows between firms using straight-line blocking code that resembles a written English description of the process. So there's plans to support human interaction in these workflows, but ultimately, the goal is to try and get them off email and paper based processes and onto something more secure and more structured. There's a paper here that goes into some of the details:
https://docs.corda.net/_static/corda-technical-whitepaper.pd...
There are numerous problems to solve to make this kind of attack unviable. The key thing to understand is that whilst the software industry has done a good job of automating and improving intra-business work, through things like office and enterprise software, it's had relatively little impact on inter-business work, which is still mostly paper based. Even when workflows are theoretically digitised, it's often simply by sending scans of paper forms or Word/PDF files via email. There are exceptions in the travel and financial industries (with SABRE and SWIFT respectively), but those are relatively restricted networks - for instance I doubt Google or its suppliers are directly connected to SWIFT.
There's some low hanging fruit. Email has DKIM and DMARC. Deploying these widely would make the From header reliable, at least assuming unhacked machines. It isn't intuitive that the From header can't be trusted and office workers typically assume that it is ... after all, it's normally correct and why would something as critical as email allow anyone to impersonate anyone else? But by default, it does.
Unfortunately DMARC is a fairly recent standard and the email space is quite stagnant, so many organisations don't use it, making email-based phishing trivial. It also hits the problem that lots of organisations have developed insecure mail practices over time in which impersonation is common, like marketing firms that send email on another organisations behalf, so deploying DMARC isn't as simple as just switching it on. It can often take months to track down and fix all the mail being sent with a "From: [email protected]" header but which actually wasn't sent by foo.org servers. That means it's a project that needs a budget, and that in turn means it often doesn't get proposed or worked on. Especially because the victims of email phishing are typically other companies, not the company being impersonated.
But because DKIM and DMARC are fundamentally based on digital signatures, and because the workflows being attacked are so often email based, setting up DKIM/DMARC is one of the best practical ways to secure modern business.
Now ... longer term, email with Word documents attached is not a solid base on which to link businesses together, DKIM/DMARC or not. It's hard to automate. It's very susceptible to human error. It suffers strange limitations, like tiny attachment sizes. Organisations often mutilate it, like with mandatory headers/footer legal disclaimers that are larger than the messages itself, or with vacation responders that don't understand mailing lists. And as nobody really coordinates or is responsible for the email network, nobody is incentivised to improve it. When improvements happen, they happen slowly and mostly because Google or Yahoo employees made it happen through sheer force of will.
Corda is an open source project that is trying to build a new inter-business network, focused (for now) on finance. So things like invoicing and bill paying is very much in scope. It uses digital signatures and encryption pervasively from the start. It takes a lot of inspiration from Bitcoin and the block chain space, although it does not use chains of blocks or proof of work itself. Some of what it does is focused on building a kind of shared global database, albeit one with rather different properties to a normal database, but part of what it does is make it easy to build structured workflows between firms using straight-line blocking code that resembles a written English description of the process. So there's plans to support human interaction in these workflows, but ultimately, the goal is to try and get them off email and paper based processes and onto something more secure and more structured. There's a paper here that goes into some of the details:
https://docs.corda.net/_static/corda-technical-whitepaper.pd...
We get fake invoice on the Fax and email all the time. Know your venders.
Seems like a fairly simple scam. All you would need is an email thread with relevant invoices and you would be well on the way. Surprised all the money was recovered after the fact though?
[deleted]
And this is why automated industry standards like Ariba cXML are valuable - it allows you securely automate the bulk of your invoicing (with ties back to requisition/purchase order chains) and also, more relevant to this discussion, to force multiple levels of approvals for manual invoicing without a req/PO chain.
Is Ariba cXML an open standard? In my experience working with SAP stuff is incredibly complicated coming from a more traditional development background.
It's open and free [1] as of 1999. It has nothing to do with SAP specifically, many vendors and enterprise software systems support it.
[1] http://cxml.org/license.html
[1] http://cxml.org/license.html
So funny, I thought this was another article about Levandowski.