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.
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.
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.
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.
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.
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?"
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.)
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.
$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.
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.
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.
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:
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?
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.
[+] [-] beastcoast|9 years ago|reply
[+] [-] walshemj|9 years ago|reply
Given this story I would bet there is a fair bit of undiscovered internal fraud at google and fb
[+] [-] SeeDave|9 years ago|reply
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.
[+] [-] mipmap04|9 years ago|reply
[+] [-] emmelaich|9 years ago|reply
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.
[+] [-] CobrastanJorji|9 years ago|reply
[+] [-] codemac|9 years ago|reply
[+] [-] acchow|9 years ago|reply
Blockchain?
[+] [-] mpeg|9 years ago|reply
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?"
[+] [-] planteen|9 years ago|reply
[+] [-] cwkoss|9 years ago|reply
[+] [-] user5994461|9 years ago|reply
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.
[+] [-] yoaviram|9 years ago|reply
[+] [-] lucasmullens|9 years ago|reply
[+] [-] josu|9 years ago|reply
[+] [-] ballenf|9 years ago|reply
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.)
[+] [-] 97262733837373|9 years ago|reply
[+] [-] celticninja|9 years ago|reply
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.
[+] [-] appetizer|9 years ago|reply
[+] [-] fjdlwlv|9 years ago|reply
Admins, please change the link.
[+] [-] dpark|9 years ago|reply
[+] [-] Waterluvian|9 years ago|reply
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.
[+] [-] noxToken|9 years ago|reply
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.
[+] [-] mike_hearn|9 years ago|reply
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...
[+] [-] jlebrech|9 years ago|reply
[+] [-] peter303|9 years ago|reply
[+] [-] SA500|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] r00fus|9 years ago|reply
[+] [-] xrjn|9 years ago|reply
[+] [-] jgalt212|9 years ago|reply