PeteFinnigan.com Limited Products, Services, Training and Information

breach

Home/breach

Breach

This is the second presentation I did at the UKOUG 2024 conference in Birmingham, UK. This is a discussion on what you should do if your database is hacked.

Slide 1 - If your Oracle Database is Hacked

Slide 2 - Legal notice

If your Oracle Database is Hacked, What should you do?

Published by
PeteFinnigan.com Limited
Tower Court
3 Oakdale Road
York
England, YO30 4XL

Copyright © 2025 by PeteFinnigan.com Limited

No part of this publication may be stored in a retrieval system, reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, scanning, recording, or otherwise except as permitted by local statutory law, without the prior written permission of the publisher. In particular this material may not be used to provide training of any type or method. This material may not be translated into any other language or used in any translated form to provide training. Requests for permission should be addressed to the above registered address of PeteFinnigan.com Limited in writing.

Limit of Liability / Disclaimer of warranty. This information contained in this course and this material is distributed on an “as-is” basis without warranty. Whilst every precaution has been taken in the preparation of this material, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions or guidance contained within this course.

TradeMarks. Many of the designations used by manufacturers and resellers to distinguish their products are claimed as trademarks. Linux is a trademark of Linus Torvalds, Oracle is a trademark of Oracle Corporation. All other trademarks are the property of their respective owners. All other product names or services identified throughout the course material are used in an editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this course.

Slide 3 - Background

Pete Finnigan – Background, Who Am I?

Oracle Security specialist and researcher
CEO and founder of PeteFinnigan.com Limited in February 2003
Writer of the longest running Oracle security blog
Author of the Oracle Security step-by-step guide and “Oracle Expert Practices”, “Oracle Incident Response and Forensics” books
Oracle ACE for security
Member of the OakTable, SYM 42
Speaker at various conferences UKOUG, PSOUG, BlackHat, more..
Published many times, see http://www.petefinnigan.com for links

Slide 4 - Agenda

Background
How do attacks happen
Overall steps
How to handle a breach
Next steps

Slide 5 - Background

Background

Slide 6 - Data Gold Rush

Data is the new gold – think 1896 to 1899 klondike in the Yukon
Usage patterns
User and customer behaviour
Company data
Tracking data – all GDPR
Companies are starting to realise the importance of data
Social media is massive
Data driven advertising
Facebook, Google, Snowden and the NSA!
Cultivated data is the way forwards
Not necessarily massive computing power and big data
Not always volume and velocity of data

Slide 7 - The Data Gold Rush - 2

Companies produce inordinate amounts of data every day
Companies main product may not be data (initially?)
Lack of AI specialists out there to help this growth

Slide 8 - UK ICO – Second Biggest GDPR Fine

UK ICO – Second Biggest GDPR Fine

Slide 9 - Oracle Reference Customer - Promoted

Oracle Reference Customer - Promoted

Slide 10 - What Do Attackers do?

Examples of what attackers do
Read data (steal)
Update data (increase a payout for instance)
Delete Data (ruin a business)
Change the database settings and permissions
Change the application for later attacks

Slide 11 - How do Attackers Attack?

At a high level
You give data away (not intentionally)
Attackers read data via web attacks or SQL Injection
Attackers exploit flaws in the data model, the application, the hosting and more
Your staff access the data and sell/give away
DBA and super user staff can access any data
Steal backups or other copies of the data

Slide 12 - Who Attacks?

The public – external
Internal employees with access to the application
Internal employees no access to the application
Access to data left lying around – reports, paper, files…
Exploiting the application or database
DBA staff with access to everything
Third parties with system access

Slide 13 - Why?

Application design and code flaws
Application deployment flaws
Application permissions
Database security flaws
Network flaws
Copies of data
External data

Slide 14 - Skilled or Unskilled

An unskilled attack is like a thief walking down streets trying car doors or house doors and entering the house or car if its open
The database equivalent would be running tools such as SQL Map to locate “open doors”
In these cases the attacker probably doesn’t know Oracle
A skilled attack is finessed and much harder to detect.
The skilled attacker would be an expert
Little to no noise; hard to detect
Straight to the point

Slide 15 - Overall Steps

Overall Steps

Slide 16 - Scope

I am not going into technical details of:
Data,
Redo and blocks,
Analysing changes in depth
Reviewing data
I am going to focus on the process of managing the breach
And how to deal with the breach

Slide 17 - What is Obvious Before We begin?

As I will show in upcoming slides
If we secured the data, database and applications then the simplest way to avoid managing a breach is not to have a breach
Some elements will help breach response massively such as already having audit enabled
Having a plan before a breach means not randomly running around when there is a breach
Having a team in advance avoids mistakes
Being able to recognize a breach will reduce the impact of that breach

Slide 18 - What are the Main Steps?

Be aware of a breach having taken place
Confirm the breach
Enter breach response mode
Transfer control to the breach team
Do not turn off / shut down
Investigate that the attack is actually an attack
Document the system
Do live response

Slide 19 - Main Steps (2)

Collect less volatile data
Break the network connection
Copy evidence
In the PC world this means copying disks
Not practical in Oracle because of license, size, continuity
Checksum collected evidence
Perform forensic analysis
Build a timeline
Document the attack
Shutdown, restore, fix, lessons learned

Slide 20 - The Team and Reporting

The Team and Reporting

Slide 21 - How and Who?

Before we talk about how a breach is reported and to who (The incident response team!) we must talk about the team leader and then the team
This must be in place before any breach
The leader of the team should not be compromised by the attack (i.e. were they involved) and not swayed by the business (i.e. coerced to ignore and gloss over to keep the business running
They should have a management role only
They should manage the steps and PR

Slide 22 - The Team

The team leader should be a manager
Of the process, not necessarily a manager per-se
The team leader must have a deputy; substitute as we do not know when the breach will happen
The team should include
Security
Oracle – DBA
Business
Management
All of these people need duplicates to reduce the risk of swaying the response if they are involved

Slide 23 - How to Report

All reports of a breach must be to one central location
This must be to the breach response team
They do not need to have this as a full time role as it only kicks in if there is a breach
The simplest approach is two fold
Training internally as to recognize what could be a potential breach
A simple email breach@example.com
Internal and external report to one location
Think of this as a funnel

Slide 24 - Stop Random Investigations

This can only be resolved by training and investigations
For instance, if a DBA notices or is told of a broken process or corrupt data and this is sudden then they should not assume a bug
Was there a release?
Was there a data change?
NO, then do not investigate and instead report to the breach team
All potential breaches must not be randomly investigated all over the company

Slide 25 - A Breach comes in

A potential breach comes in through the funnel
Transfer control to the incident team leader
How: The incident team leader (or a sub-ordinate) manages this list / email
The leader should assign someone to investigate based on the evidence so far
i.e. do we need a developer / DBA / Business Analyst or what?
Make a judgement on who could be involved – i.e. don’t get a DBA to investigate something he/she did
No changes at this point made to any system

Slide 26 - An Example

I investigated a potential breach as requested by a customer
They “thought” the breach had just happened and I travelled by car to the organisation in the North West of England
I was able to determine that the breach was real quite quickly from the evidence they had already
Further digging to find the start of the breach revealed it was likely hacked 3 years and 2 months before
BUT, they were still right to get me there quickly

Slide 27 - How to Verify a Breach?

This is difficult in the sense there is no simple “yes/no” way to do this
Is it a real breach depends
The simplest is that it comes to light that data was leaked
Its posted to Facebook, Twitter, Dropbox…
Check the data is not in the public domain already
Check the validity of the data – i.e. its real data
Identify if possible where it came from (65 records in prod but 52 leaked, 52 exist in test!)
Remember the breach can be internal

Slide 28 - No Technical Details

The focus of this talk is to discuss the process and how to deal with a breach
We are not getting into the details of how to do live response and how to investigate forensically
Next time!!
Beware of time stamps
Beware of correlation
Beware that it is hard to find evidence of some changes
Beware that read actions without audit trails are very hard to find

Slide 29 - Do Live Response and Forensic Analysis

Collect the most transient data
Collect less transient data
Build a time line of evidence
Check sum the evidence
Correlate evidence together – i.e. an action in an apache log can be correlated to database records and also users used.
If the attack came via Apache then we know what database user was used to connect BUT the attacker could escalate via bugs in definer rights PL/SQL
Work out when the attack started and ended and started

Slide 30 - Training and Awareness

In advance of a breach staff should be trained
The response team should be trained
On the process
On how to recognize a breach
On how to investigate a breach
All staff should be trained
To recognize that something may be a breach
They should be aware of the process and breach team
They should be aware to submit to the breach funnel

Slide 31 - Public Relations

Ensure a consistent and uniform response to the media and customers and interested parties
I DO NOT MEAN LIE!!!
Ensure that all news of the breach to customers, internal staff, managers, the press comes from one person / channel
Ensure the message is vetted to provide accurate status or mechanicals of the investigation but no detail
Ensure all staff know they cannot speak to anyone

Slide 32 - Detailed Report

At the end of the whole process we can create a report detailing
When did the attack start and end
How did the attacker gain access
What did the attacker steal or change
What could the attacker have done with more skills
The last one is interesting and I have seen many times. An attacker does something but didn’t have Oracle skills or knowledge to go further BUT they could have done

Slide 33 - Fix or NOT and update Core security

At this point we can decide to fix the database/data
OR
restore
Be very careful
If the attack happened months or even years ago restoring is not an option
The backups will also be corrupt
It is completely impractical to restore to a long time ago

Slide 34 - Fix the Security!

Fix the flaws that allowed the hack to happen
In the database
In the applications
In the webservers
In the network
Enable audit trails
Enable / design database security
Enable overall security
Enable monitoring

Slide 35 - Inevitable Conclusion

It should be obvious that there are things we must do now irrespective of a potential breach
Appoint and create an incident response team and leader and substitutes; this is not a full time job; think fire warden or first aider
Set up a breach / potential breach reporting system. This is a funnel – can be an email address
Train the team on how to respond and deal with a breach
Create a breach response process
Enable a good detailed audit trail to help with forensic analysis

Slide 36 - Conclusions