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.
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”. 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.
Consider this scenario: Fraudster gains entry into a backdoor of the ESD system 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.
How might ESD come up with hundreds of millions dollars of fraudulent payments? Database queries!
Calculating Loss With 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:
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.
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 a sence 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.
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 firstname.lastname@example.org, you own all dotted versions of your address:
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:
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.