Author: admin

If you think ESD is implementing best practices with security, think again after reading the analysis below. In fact, ESD is guilty of the very activity it is trying to guard and warn against.

Many individuals who have reported that they have been victims of imposter fraud through the WA State Employment Security Department are receiving email notices like the following, actual, email (click on image to enlarge):

Let’s examine ESD’s advice from the above image. ESD says:

“The email address we use will end with @esd.wa.gov or WashingtonESD@public.govdelivery.com. If you get any unemployment related correspondence from any other address, do not open or reply to it.”

The advice regarding “from any other address” certainly makes sense.

But, what if a phishing email shows up with “@esd.wa.gov” or “WashingtonESD@public.govdelivery.com” in the visible FROM field of the email? Fraudsters do this all the time, trying to trick recipients into thinking the email came from a legitimate source. Using someone else’s email address in the FROM field is called email address spoofing and there are articles all over the Internet about this. For example, Wikipedia has an article on email spoofing. Among the statements from that article:

MAIL FROM: – generally presented to the recipient as the Return-path: header but not normally visible to the end user, and by default no checks are done that the sending system is authorized to send on behalf of that address.

From: Joe Q Doe <joeqdoe@example.com> – the address visible to the recipient; but again, by default no checks are done that the sending system is authorized to send on behalf of that address.

WA State even has a law that recognizes and bans spoofing: RCW 9A.90.070 Spoofing. Is this law going to stop fraudsters? Hasn’t yet.

So, let’s say you get an email from an address ending with “@esd.wa.gov” or “WashingtonESD@public.govdelivery.com”. It invites you to visit an official-looking web site where you enter your phone number and perhaps other identifying info.

At this point, you’ve been had.

Then you get a call from someone at the fraudulent website saying they are a member of “OSI from the Employment Security Department”.

There is no way to validate that the caller is really from OSI. ESD creates the same problem with its wording discussed below.

At this point, you’ve been had again!

The only secure way to communicate with ESD’s OSI is to call the number ESD posts on the website.

An email sent out June 8, 2020 has some interesting wording.

“ESD will ask you for information through official correspondence and your ESD eServices account. If we call you, you can ask the agents to identify themselves.”

“If we call you”? ESD wants us to answer a call from someone who claims to be an ESD employee? But banks, the IRS, Social Security, tell us all the time they will not call us and ask for personal information.

ESD is not following best security practices.

Here’s how a call might go:

“Hello”.

“Hi. My name is John Smith. I’m calling from the Washington State Employment Security Department.”

“Great. Been waiting to hear from you folks.”

“Before we can move forward in resolving your application, I will need some additional information from you, including your Social Security number.”

“OK. But before we do that, I need for you to identify yourself.”

“Sure, no problem. My name is John Smith. I work for the Washington State Employment Security Department. My ID# is 19395954.”

“Oh, ok. So you need my Social Security number?”

“Yes, let’s start with that.”

“My Social Security number is 555-555-1111.”

See the problem with this? There is NO WAY for the recipient of the phone call to validate that the person calling really works for ESD.

In essence, ESD is helping applicants lower their guard against calls from fraudsters.

These two examples from ESD come after ESD was foolishly inviting people to send copies of their Social Security card and ID via email.

Washington Employment Security Department Commissioner Suzi LeVine’s prepared remarks Thursday morning, 2020-06-04, were more of a crime report than a help report. Of the approximately 12 minutes of her prepared remarks, with six slides, only 1 minute — maybe 2 — was focused on how applicants with legitimate claims are going to be helped. And even those remarks were empty rhetoric, such as these three snippets (approximate time from the start of the video linked above):

7:33 “Through out this crisis that has meant being as honest and transparent as we can at all times in order to uphold our responsibility to Washingtonians who need our services, even if that means delivering news that is not always welcome.”

She delivered the bad news. Fraud, and more fraud — $500-600 million she thinks, as an early estimate. LeVine reported on the number of dollars recovered — $330 million. LeVine mentioned 25,000 fraudulent applications. What LeVine did NOT report on were, for example:

— how many ESD employees are examining ID documents to verify identity?
— how many applicant IDs are able to be verified each day?
— what is the percentage distribution of ESD workers that represent different functions, e.g.: 80% on phones, 10% on programming, 10% on ID verification?

10:39 “We are calling in every single resource we can and will leave no stone unturned to get the benefits people are due and to catch the criminals and to stop fraudulent claims from going out.”

LeVine did not mention even one “single resource” they were calling in. Why not? Why not explain the triage plan to work on the applications waiting the longest — if such a plan even exists.

12:45 “Everyday we see thousands of suspeciaous claims come in with increasingly convincing false IDs that must be reviewed and dealt with by trained investigators.”

How many investigators? Nine, as has been suggested in social media posts?

The six slides she included in her prepared remarks were:

1. Latest Numbers (of applicants)
2. Preventing Fraud: Helping the Victims
3. Preventing Fraud: Still Under Attack
4. Operation 100% (where she spend no more than 2 minutes, and said the June 15th deadline is going to be extended by at least two weeks)
5. Looking to the future (basically for another extension of PEUC benefits)
6. Fraud: Actions to take

Not one slide was devoted to “Actions to take if you are in limbo” or “Actions and resources we are taking to get you out of limbo”.

Overall, her crime report may be fodder for newspaper and TV reports, but offer little hope to the thousands of legitimate applicants thrown out of work and needing financial assistance.

There have been reports on Social Media that Washington State DSHS is denying food assistance to those who have applied for unemployment benefits from the Washington Employment Security Department. Here’s an official explanation from an authorized spokesperson for DSHS about the relation of food assistance with an application for unemployment benefits. The following is verbatim from the DSHS source on June 3, 2020.

We understand there is a lot of confusion regarding unemployment compensation claims and how they impact public assistance benefits. When people apply for food and cash benefits, DSHS reviews the household information for all countable income and compares it to information provided to us directly from the Employment Security Department. Our eligibility determinations for food assistance must align with WAC 388-450-0005(1) and CFR 273.10(c) regarding budgeting of income that can be expected or anticipated.

We have not received email or other instruction from ESD regarding guidance for processing/denying any pending unemployment claims. If a household shows a pending unemployment claim with ESD, DSHS does not budget this income. If people are hearing or experiencing something different from this, they should please call our Customer Service Contact Center at 877-501-2233. DSHS is willing to review recently denied cases to determine whether the case was correctly decided.

Unemployment compensation is not countable income until approved with an anticipated weekly benefit amount and date of when benefits will be received. If an applicant is denied benefits due to unemployment income they are not receiving, they can call the Customer Service Contact Center at 877-501-2233 for a review.

We also understand that many recipients of unemployment benefits are experiencing delays while the Employment Security Department verifies identity due to recent unemployment fraud. If unemployment benefits are delayed for a time exceeding (or anticipated to exceed) 30 days, please call the Customer Service Contact Center at 877-501-2233 for a review.

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.

1. Hundreds of millions = $200,000,000
2. Average amount taken in each fraudulent account = $5,000
3. 200,000,000 / 5,000 = 40,000 accounts!

1. Hundreds of millions = $300,000,000
2. Average amount taken in each fraudulent account = $5,000
3. 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