Updated after 2020-06-04 with report of $333M loss
Links to related articles at bottom.
The Seattle Times ran an article called How missed ‘red flags’ helped Nigerian fraud ring ‘Scattered Canary’ bilk Washington’s unemployment system amid coronavirus chaos. This post supplements that article. Links at the bottom of this post provide more detail on ESD systems mentioned in the Times article.
Detecting Fraud
40,000 Fraud Accounts?
Are the fraudsters more efficient than ESD? They might be, considering that Commissioner LeVine is reported as saying the fraud could be in the “hundreds of millions of dollars”. (Before her report on June 4, 2020 of $333 million recovered.) Let’s make some simple assumptions.
- Hundreds of millions = $200,000,000
- Average amount taken in each fraudulent account = $5,000
- 200,000,000 / 5,000 = 40,000 accounts!
- Hundreds of millions = $300,000,000
- Average amount taken in each fraudulent account = $5,000
- 300,000,000 / 5,000 = 60,000 accounts!
Commissioner Suzi LeVine has been adamant there has been no data breach — data stolen — and insisting all the fraud is because of data from other sources, such as the Equifax breach. She has said “This is happening because bad actors have acquired people’s personal information through other data breaches outside of the agency. Criminals then use this information to fraudulently apply for unemployment benefits in someone else’s name. There has been no data breach from ESD’s system.” Note the word “from”.
If there are really 40,000 or 60,000 accounts used for funneling money to the fraudsters, this suggests a degree of automation. Imagine the organizational logistics of getting enough computers and enough people to sit at computers to manually and individually create accounts or gain access to an accounts to set email address, routing, and bank account information.
The people who stole data from Equifax and other sources were not sitting in front of computers typing data of 140 million peole into a spreadsheet. They were using a more administrative-type hacked access that allows commands to run database queries or grab database files for download. Doesn’t it make sense that 40,000+ ESD accounts used for fraud also be implemented in a more efficient administrative fashion — rather than hundreds or thousands people sitting in front of computers creating accounts one-by-one? And consider this: what about setting up bank accounts for each of these ESD accounts? That would be a chore in itself. So, if all fraudulently accounts were created manually for 40,000+ accounts, there would need to be a huge logistical orchestration of people and computers. Creating that many bank accounts and then corresponding ESD accounts is simply mind-boggling. Wouldn’t it be simpler to gain access through the back door and tell several ESD accounts to send money to the same bank account? (See Detecting Fraud below.)
Consider this scenario: Fraudster gains entry into a backdoor of the ESD system with administrative-type access and figures out that 1) a properly structured file of data (account activation, fraudulent email addresses, routing numbers and account numbers) could be uploaded and 2) a process could be run on the ESD server to process all the data in a batch. Fast and efficient. This could all be done without taking any data from the ESD server.
Whether there was intrusion or not, it seems reasonable that automation was used if there really are 40,000 or 60,000 accounts used for funneling money to the fraudsters.
Detecting Fraud
Detecting the fraud could certainly happen in various ways.
LeVine has said ESD has become aware of many accounts used for fraud from victims whose identity has been stolen.
On June 4, 2020 LeVine said “Everyday we see thousands of suspicious claims come in with increasingly convincing false IDs that must be reviewed and dealt with by trained investigators.” In other words, there is no sure method to even stop the creation of a fraudulent account. That means detection AFTER account creation and BEFORE payment. This is likely part of the reason for delayed payment.
Just how might ESD detect fraud before payment? One method would be database queries. Here’s a possible example. Unless couples using the same shared checking accounts are both unemployed and receiving benefits at the same time, there are probably very few ESD accounts using the same bank account for direct deposit payments.
Using that assumption, ESD could run a query to a) determine how many ESD accounts are associated with the same bank account. A simple SQL database query would like this:
SELECT bankaccount, COUNT(*) FROM database GROUP BY bankaccount.
This would return something like this:
bankaccount | number of ESD accounts
111111 | 5
222222 | 13
333333 | 9
Red flags! These results then allow ESD to a) flag accounts for non-payment, again using another example query:
update database set holdflag = ‘yes’ where bankaccount = ‘111111’.
Then, ESD moves all the non-holdflag records into a batch for payment.
ESD can use bankaccount number to generate a report so suspect records can be examined:
select recordID from database where bankaccount = ‘111111’
This generates a simple report:
recordID
40,001
41,343
43,049
55,000
Using more sophisticated, but similar, database queries could also help give a count of ESD accounts used in a fraudulent manner and also an amount lost.
Calculating Loss With Database Queries
How might ESD come up with hundreds of millions dollars of fraudulent payments? Database queries!
How would ESD calculate loss to fraud? Here are some scenarios:
Assuming ESD has the ability to construct and run different queries on the ESD Claimant database, they might use any or all of these techniques (and probably more on data we don’t know about):
Throw-Away Email Addresses
Throw away email addresses
Some domain names are used for throw-away email addresses, such as yopmail.com, and those associated with it:
@yopmail.fr
@yopmail.net
@cool.fr.nf
@jetable.fr.nf
@nospam.ze.tc
@nomail.xl.cx
@mega.zik.dj
@speed.1s.fr
@courriel.fr.nf
@moncourrier.fr.nf
@monemail.fr.nf
@monmail.fr.nf
So, with the right query — something like this admittedly simple query — can generate a number:
select (sum)amountpaid from datatable where emailaddress LIKE “%yopmail%”
Run this on each domain, add the numbers, and you get an approximation of the amount paid out.
Routing numbers
Probably most ESD applicants would be using a bank within Washington State. (Exceptions, of course, like USAA out of Texas, used a lot by military, ex-military, and families). By looking at the routing number for direct deposit ESD could get an idea of where payments are going. Routing numbers include number designations for the Federal Reserve district a financial institution is on. There have been reports that payments went to an institution in Oklahoma. Oklahoma is in Federal Reserve district 10. The Bank of Oklahoma routing number is 103900036. Washington is in District 12. Most Banner Banks in Washington start with 12, such as 121141903. There are variations, of course. Many credit unions begin with 3, such as Boeing Employees Credit at 325081403.
Using a simple query as an example, ESD could get estimate of how much money was being sent outside of Federal Reserve District 12:
select (sum)amountpaid from datatable where routingnumber NOT LIKE “12%”
Because each financial institution has a unique routing number, suspicious financial destinations could be determined or verified. There have been reports of fraud victims receiving Green Dot cards in their mail as a result of a fraudulent creation of an account at Green Dot Bank and then at ESD. ESD could run a query like this to see number of accounts using the Green Dot Bank (aka GOBank): 124303162
select count(*) from datatable where routingnumber = “124303162”.
If you end up with something like 12,243 in the total count, then eyebrows would probably be raised.
Getting a total amount paid to 124303162 would be something like this:
select (sum)amountpaid from datatable where routingnumber = “124303162”.
No doubt the database ESD keeps its data in is more complex, and thus more complex queries would be needed.
Google Email
The Seattle Times reported this:
“Scattered Canary also used so-called “google.dot” accounts, that is, variations of the same Gmail address that can be used to set up a separate ESD account but, which all deliver to a single Gmail email address, according to Agari.”
This is actually a feature of Gmail. Rather than simply affix a specific combination of characters to a mail ID, Gmail uses a concept they used to call “namespace”. In this concept, variations on the name will still be accepted by the Gmail server as a valid email address and delivered to the same inbox as the original ID a user set up. From the Google help page “Dots don’t matter in Gmail addresses”. Google gives this example:
For example, if your email is johnsmith@gmail.com, you own all dotted versions of your address:
john.smith@gmail.com
jo.hn.sm.ith@gmail.com
j.o.h.n.s.m.i.t.h@gmail.com
These variations are useful to determine if a service or company is selling an email address.
Another way to use the Gmail namespace is to add an identifer after the name with the plus sign:
john.smith+esd@gmail.com
Developing a query to detect if the same basic name was used in different accounts is possible, but might require additional processing outside of a database query. For example, ESD could run a query to compile a list of all gmail addresses used. Then remove with search and replace all periods (dots). Then put the email addresses back into a database and run a query like this:
SELECT COUNT(DISTINCT emailaddress) AS emailaddress FROM datatable
You could end up with something like this:
johnsmith@gmail = 15 (total)
marysmith@gmail = 14 (total)
Results like this will give ESD heart attacks. Presumably, if there was no fraud, there would be only one email address for each account and appear only once in the entire database.
Related Pages
Seattle Times Editorial Misses Important Details on Employment Security Department
Ticking along with ESD
WA State CIO apparently OK with ID sent by email
Washington State Sets Unemployment Benefit to $0 by making up job title