Insider DBA Executes Lottery Scam
Key Points
- The scam involved outside fraudsters buying winning lottery tickets at a small profit and colluding with an inside “bad actor” – a database administrator (DBA) – who inflated the ticket values in the system before cashing them.
- After the fraudulent cash‑out, the DBA reverted the ticket values back to their original amounts, erasing obvious evidence of the manipulation.
- Auditors eventually discovered the scheme when a consultant’s laptop captured the DBA’s activity logs, exposing the insider’s unauthorized changes.
- Preventative measures discussed include stronger identity‑and‑access‑management controls, strict segregation of duties, and continuous monitoring and review of database logs to detect anomalous activity.
Sections
- Insider Database Lottery Scam - An external group buys winning lottery tickets at a discount while a colluding database administrator inflates the ticket values, cashes the profit, and then resets the amounts to evade detection.
- Zero Trust, Auditing, and AI - The speakers explain how logs, Zero Trust architecture, continuous auditing, and AI-driven anomaly detection create a proactive security foundation, illustrating the approach with IBM Guardium.
Full Transcript
# Insider DBA Executes Lottery Scam **Source:** [https://www.youtube.com/watch?v=9QEpg9PFHTU](https://www.youtube.com/watch?v=9QEpg9PFHTU) **Duration:** 00:04:26 ## Summary - The scam involved outside fraudsters buying winning lottery tickets at a small profit and colluding with an inside “bad actor” – a database administrator (DBA) – who inflated the ticket values in the system before cashing them. - After the fraudulent cash‑out, the DBA reverted the ticket values back to their original amounts, erasing obvious evidence of the manipulation. - Auditors eventually discovered the scheme when a consultant’s laptop captured the DBA’s activity logs, exposing the insider’s unauthorized changes. - Preventative measures discussed include stronger identity‑and‑access‑management controls, strict segregation of duties, and continuous monitoring and review of database logs to detect anomalous activity. ## Sections - [00:00:00](https://www.youtube.com/watch?v=9QEpg9PFHTU&t=0s) **Insider Database Lottery Scam** - An external group buys winning lottery tickets at a discount while a colluding database administrator inflates the ticket values, cashes the profit, and then resets the amounts to evade detection. - [00:03:04](https://www.youtube.com/watch?v=9QEpg9PFHTU&t=184s) **Zero Trust, Auditing, and AI** - The speakers explain how logs, Zero Trust architecture, continuous auditing, and AI-driven anomaly detection create a proactive security foundation, illustrating the approach with IBM Guardium. ## Full Transcript
If you've been following this channel,
there's no doubt you've probably seen one or more of our cybersecurity videos featuring Jeff Crume,
and one thing he loves to talk about are bad actors.
And today, I've invited an expert in this field to explain how one of these bad actors actually pulled off a lottery scam.
Can you explain it to us? Yep.
So my name is Ebenezer Grover Hewitt, and I'm a cybersecurity specialist at IBM.
In this lottery scam, there was an organization losing a lot of money out their lotteries.
And the way that was happening was because of bad actors on the outside and a bad actor from the inside,
which is a database administrator.
And the way this would happen is there would be winning numbers.
Okay, so for example, this is a winning ticket.
Great. Yep.
So these winners would sell their tickets, their winning numbers to the group of scammers.
They'd sell them for, like, $4 more so they'd buy them for $5.
I see. So they're happy they made a few dollars.
Exactly.
And these scammers would then call the database administrator,
and this person from the inside would change the values from $1 to $100, for example.
I see. And then they cash in the ticket.
Exactly.
With a $95 profit. Exactly. Pretty sweet.
And now you ask the question, "But wouldn't they get caught if they keep on leaving it [like that]?"
Right, right, right!
Exactly. So the database administrator would then go and remove the zeros
and change it back to the value of how it initially was.
So they did that right after they cashed, so there's no evidence left behind.
Exactly.
So what's the next part of this story?
Yeah. So that lottery group brings in consultants and audit group,
and they keep on auditing the different things that were happening.
Initially, they thought it was the circle thing that,
Oh, yeah. The balls a mix up to get a random number. Sure!
Exactly. So they thought those numbers were fixed, but actually wasn't.
So then they thought it was an IT issue in the background.
So then they bring in an auditor and they check the database.
What happens is the auditor plugs in his laptop and sees everything that was going on.
So this DBA is now being watched.
But he doesn't know it.
Okay.
So he was changing these numbers and he was getting the log files of everything that was happening. And then he got caught.
Okay, so that's the end of his story.
But the next part of the story is how could they have prevented this in the first place?
Yeah. So there might have been something they might have done right with the identity and access management [IAM].
We could say that the database administrator had the right access to the database.
So that verifies you're the right person and you have the proper authority.
But in this case, we had a bad actor on the inside.
Exactly.
I see. So points for that. But IAM didn't solve the problem.
Yep. That did not solve the problem.
So what they could have been doing is they could have been reviewing the log files
because they would have logged everything that was changing in the database.
And that would have been able to help them detect exactly what was going on, especially with changing the numbers.
Well, especially in this particular case, you have a database table
which is supposedly not going to change at all.
Exactly.
I see. So logs would have helped them detect.
Yes. And this falls under the bigger umbrella of the Zero Trust architecture,
which states "trust no one"
even people inside of your perimeter, not only on the outside.
So IAM was mostly about maintaining a perimeter.
This next step with Zero Trust is really about putting that across to everyone.
Yes, exactly.
I see it over the last step.
Audit + AI. What does that mean?
So you probably heard Jeff say that security is not an afterthought.
Instead, it's something that we should build our infrastructure on.
And they should have had a process of auditing and maybe an AI system
that would tell them-- a detection of an anomaly or something that was out of the ordinary.
So, for example, an AI system that looks for a change, it shouldn't be occurring at a certain time or change occurs very rapidly.
Exactly.
I see.
That would have notified them of the issue.
Okay, so you get the final word. What would you recommend to our viewers?
I mean, they have to deal with security.
How should they approach it?
Yeah. So thanks for that.
So like I mentioned before, security should not be an afterthought
Instead, it should be something that we build our foundation on.
At IBM we use IBM Guardium for our security suite.
To learn more about it, check down the link below.