The CISO Signal: True Cybercrime Podcast

The initial signals from the reports was

a was a ransom note.

By the time you see

that, it's a little bit too late.

The threat actors in your house,

the attack surface area can be so massive

you can be overwhelmed

with all the intelligence.

So the challenge really becomes

what's critical to you.

Where do you focus?

Welcome to The CISO Signal

True Cybercrime podcast.

I'm Jeremy Lander.

In late 2020, cybercriminal groups

discovered a weakness in a system

used by hospitals,

universities, financial institutions

and government agencies around the world.

Not a new platform.

An old one Accellion FTA. A file transfer

appliance designed

years earlier

to solve a very specific problem

how to move large, sensitive files

between organizations

without exposing the rest of the network.

In its day, it was cutting edge,

secure corridor

connecting institutions,

a dark box

and a network closet

that did one job quietly and did it well

for nearly 20 years,

organizations like Kroger,

the reserve Bank of New Zealand,

and the University of California

trusted that corridor

with their most valuable data.

Then attackers found it.

What followed was not a single breach,

but a coordinated campaign,

one focused on data theft

and another on pressure,

and in some instances,

seven figure ransom demands.

While defenders tried to understand

what was happening.

Deadlines were already being set,

data was already gone,

and questions were already being asked

not just by attackers

but by regulators, by boards, by lawyers.

Questions like why was the system

still running, who owned it?

And how many other organizations

were exposed in the same way?

This is the story of the Accellion breach,

and to help us answer those questions,

were welcoming back to the podcast.

Christopher Russell

Chris is the CISO at tZERO Group,

bringing deep experience

in threat intelligence,

legacy system risk and incident response,

and joining

Chris and I is

Benjamin Lipczynski

Director of Security

& Regulatory Services

at this episode's sponsor -

Origina. Origina helps enterprises

safely operate, govern,

and extend mission critical systems

that may have outlived

their original vendor support models.

Ben brings

more than 20 years of experience

across

defense, critical infrastructure,

and rapid incident response,

helping organizations reduce risk,

preserve stability

and regain control

without being forced

into rushed,

expensive or unnecessary upgrades.

Ben.

Chris, it's great

to have you both on the show.

How are you gentlemen doing this evening?

Really good.

Jeremy, thanks for having me.

Very well. Thank you for having me.

Excellent.

Let's begin the investigation.

We are in the midst of a ceaseless war.

Not of bombs or bullets, but of breaches,

firewalls and silent incursions.

The targets?

Our borders are banks, our commerce

and the critical infrastructure

that underpins a free civilization.

The enemy is cloaked in code,

fueled by greed,

glory, and a desire for chaos.

This is the story of the unseen

protectors, the nameless

generals, the CISOs,

chief information security officers.

They are the guardians at the gate.

Watchers on the wall.

Ever vigilant and always listening

for The CISO Signal.

For deeper

breach timelines and regulatory analysis

that you can't find anywhere

else, visit theCISOsignal.com

or subscribe to our LinkedIn newsletter.

Act I.

The Corridor: Accellion FTA, was built

to be a corridor,

a controlled passage for sensitive files

to move

between organizations

without needing to open every door

in the building.

Contracts, records, regulated data,

the kinds of files

that do not get a second chance

if they end up in the wrong hands.

This corridor was designed

to be predictable,

invisible, uneventful in the way

critical infrastructure

is supposed to be uneventful.

Quarter closes come,

regulatory reporting happens.

Patient intakes need to be done.

Moments

when the business

cannot afford surprises.

And because it never caused problems

in the past, it stayed open, not

because it was perfect,

but because it was relied upon.

Ben before the breach even begins,

help us set the stage.

When you look at a decades old system

like Accellion, still patched,

still quietly running critical workflows,

what does that tell you

about the organizations

that depend on systems

like that for so long?

Yeah, well, we've seen this,

you know,

a good few times

where there's

that small piece of technology

that's been there for years,

the people kind of forget about and

kind of

forget what it actually serves

and delivers.

And suddenly when you talk about

file transfer technologies,

you know, these were implemented

when you couldn't

email these large files easily enough.

But more recently,

we've seen customers be able

to overcome these,

these challenges of emailing,

large media files, for example,

just over email.

So these older technologies

become neglected and forgotten about.

This is how it happens,

not in dramatic failure,

but in quiet success, measured

by nothing going wrong.

The system that never makes

noise is a system

no one wants to question

until they have no choice.

Equally, the business processes

don't exist there

to revalidate

some of these technologies

because of the silos,

and the nature of these customers.

So they sit there unnoticed,

not causing any alerts,

possibly unmonitored

until something like this happens.

By 2020, platforms

like Accellion were still moving

sensitive material

between enterprises, universities

and public institutions,

sometimes because they were trusted

and sometimes

because they were simply still

they're still integrated,

still necessary,

still difficult to remove

without breaking something else.

And while the world changed around it,

the corridor stayed.

What I've come to find is

there's a lot of organizations

that took a pretty decent,

set of software hardware

and did some sort of customizations

that really were geared

towards their, business.

It integrated

and was the backbone

and the feeding system

for a lot of other newer systems.

And there really wasn't a lot of options

to... like the newer version of it.

We just need the old customization.

And replacing it

with with new technology

would also need the customization.

So companies really start

relying on this really solid,

you know,

working piece of

software that

doesn't have a ton of support.

And it's doing a very small thing,

but it's integral

to all these other services

to the people who relied on it.

The system felt dependable, predictable,

a small thing that just worked,

but the criminals it looked like leverage,

because the perfect target

is not always the newest technology.

It's the one

the business cannot stop using.

The one stitched into the workflow,

the one nobody wants to replace

in the middle of a quarter,

or a merger, or a crisis.

Every organization has that corridor

that no one wants to look down anymore.

The criminals love those corridors.

Chris, part

of what made the Assyrian breach

so difficult

wasn't just the vulnerabilities,

it was the choreography.

One group

breaking in and taking data at scale,

another applying pressure

and turning that theft

into a countdown clock.

From a defenders perspective,

what changes

when you realize you're fighting

two different problems at the same time?

Well, I think in that scenario

you're really facing

a battle on two fronts,

so you almost have to have

at least the capability

to have two teams doing

parallel moves to deal

with the two different situations.

The group tied to

this campaign had a name, ‘Cl0p’.

Their model was simple break in, quietly

take the files

and then threaten to publish them

unless payment arrives.

Known corruption, no recovery keys,

just pressure and a deadline.

There's a different strategy

to dealing with fallout

with regulators and public opinion

than there is with extortion attempts

and communicating whatever

ransoms and dealing with law enforcement.

And what you can't do

is sacrifice one for the other.

That's the trap.

While one side takes your data,

the other takes your time,

your attention, your executive bandwidth.

The attacker is not only inside

your environment,

the attacker's inside your calendar.

Forcing decisions faster

than certainty can arrive.

Now, not every organization

has two

incentive response teams

that can work at the same time.

But I think this is a scenario

where if an organization

was hit

by ‘Cl0p’ and ‘FIN11’

and they were doing

two very different things,

they should look at getting basically

two teams on retainer,

because while you're dealing with one

and the other one gets angry,

the ramifications of making

some ransomware gang upset

because they don't feel like you're

taking your threat reasonably

could mean your data

just being exposed, or them

selling it, or them acting hasty.

Time is of the essence

when these things go off.

And if you're not equipped to handle

two fronts,

you need to really quickly

get someone on retainer,

bring them in to get up to speed,

and at least handle

the initial triage of the conversation.

Even if the same executives

are making the decisions on the back end.

What defenders were facing

was not a single adversary

improvising in real time.

It was a campaign

built in layers,

access and extraction on one track,

pressure and exposure

on the other,

two movements

of the same symphony timed,

so that while defenders were still trying

to understand what they were seeing,

the next phase was already arriving.

Act II:

Two Fronts

And then came the demands.

In cases tied to this campaign,

ransom demands

were reported in the millions,

in some cases far beyond.

The University of Colorado

disclosed a demand of $17 million

and refused to pay.

Other victims reported demands,

reaching into eight figures.

The offer was always the same. Pay

and the data stays private, refuse

and it appears on a leak

site file by a file

for anyone to download.

There were no guarantees,

no proof of deletion,

just the hope that the clock would stop.

Ben when an incident

like this becomes real,

what's the first question

that goes through your mind?

Not technically, but strategically.

The moment

when you realize

this isn't just an investigation anymore?

It usually starts with “what did I miss?”

“How did we get that far?”

That’s usually the sort of... the first thing

that passes through my head,

but then it quickly goes to, “so what”

and I always ask that question, so what?

What does this mean?

Does this mean we stopped operations?

Have we lost sensitive data?

Either our own intellectual property?

That question sounds technical,

but it really is a question

about ownership,

about decisions made years

earlier by people

who may not even be

in the building anymore.

In that instant,

the incident splits in two

recovery or exposure,

and neither one waits patiently.

Are we no longer able to access it?

If it's just a pure ransomware,

is this a double extortion attack?

You know,

am I going to see my data... sensitive data

or even

personally identifiable information

out there on the web,

which could expose us

to not only just financial losses

to operations,

but we, you know, certainly in Europe

and things like GDPR,

we could be exposed to considerable fines.

By the time an organization understands

what kind of incident this is,

the technical questions

begin to lose their urgency.

Another set of questions

enters the room.

They're quieter, heavier, more expensive.

Who knows? Who will be told?

And who will be forced to explain

why this system is still running at all?

This is the moment fear arrives,

not as a feeling, but as a force.

Fear is a terrible basis

for any upgrade strategy here, and

we often see a lot of pressure piled on

by the OEMs

to make that decision,

and it can come at considerable cost.

Fear was not a side

effect of this attack.

It was part of the leverage

fear of regulatory judgment,

fear of public exposure,

fear of being asked

in a roomful of executives

why this system was still running at all.

Ben a lot of organizations

hear the word

‘noncompliance’ and immediately

feel boxed in.

From your experience,

what are regulators actually

looking for in moments like this,

once the breach has already happened?

So I have yet to come across a regulation

that says you must

apply the latest patch fix

regulations are there to ensure

these critical industries,

such as financial services

or power

or medical, are taking

proactive, correct evidential decisions

to secure those environments

and on the data within. In the aftermath,

another assumption began to crack.

Many regulators

were not looking for proof

that organizations

had upgraded fast enough.

They were looking for evidence

that someone understood

what they were operating.

That risk had been examined deliberately,

and that ownership existed before

the crisis, not invented during it.

The other thing

I hear is you're non-compliant.

Usually just hearing

that word is enough fear...

you know, that the customer

sometimes doesn't even challege...

Non-compliant to what? You know...

Where am I non-compliant?

So all this pressure comes

down to the customer to act now!

Accellion exposed, a quiet truth.

Compliance is not measured

by version numbers alone.

It's measured by intent, documentation,

and whether control exists before

pressure arrives.

And now for this episode's quick question

which category of risk worries

you most right now?

Legacy systems, third-party exposure,

Agentic attacks, or identity and access?

Share your view in the comments.

Act III

Ownership & Fear

‘Cl0p’ understood something

about modern institutions.

If you want payment,

you don't just threaten the company,

you threaten the company in public.

Victims names listed, sample files

released, proof

before pressure escalated.

This wasn't about theft,

it was about control.

By this point, technology

alone could not explain

what happened next.

Organizations facing similar exposure

began to diverge not because of tools,

but because of culture. Chris.

When you look at organizations

that were exposed in similar ways,

some managed the fallout

far better than others.

What do you think it is

that usually separates

them at that point?

If it's not the technology itself,

it comes down to an organization's desire

to just keep

knowledgeable people

for their systems, versus

we're just going to let

this run to the ground,

and once it stops running,

then we'll just divest and move on.

Legacy risk is rarely an accident.

It's a slow decision, made again

and again and again

until it becomes the default.

But organizations

that are concerned with things

like business continuity

and reputation and,

you know, want to have

a good customer experience.

If they have a system

they want to manned with experts,

they want

someone that knows how to use it

and fix it and deal with it.

And as soon as they don't have

that, their,

you know, their skin crawls a little bit

and they decide,

well, maybe I need to find someone

who knows how this works

and can fix this

if there's a problem or

I need to move on from it.

In moments

like this, the difference

between two organizations is not

whether a system is old,

it's whether anyone truly owns

that system when it starts to fail.

I think it's just a mentality

on the business side of how

they want to deal with that problem.

They want to proactively

spend the money to keep the expertise,

to keep people trained on it,

to bring in new people

or do they want to just let it run

until it's dead.

This was the end of patience,

the moment when investigation

stopped being the priority

because the damage

was no longer hypothetical.

Act IV: Damage Control

There's a moment in every incident

when curiosity becomes a liability,

when understanding how it happened

matters less than accepting

what is already happened.

This is the moment

the hunt stops and damage control begins.

Chris, there's a point in an incident

where understanding what happened

stops being the priority.

From your experience,

how do you know when it's time

to stop investigating and start

focusing purely on recovery and response?

Well, you're jumping from investigation

and searching in logs

and trying to determine

what's going on

and how bad it is

to knowing how bad it is

and really shifting into damage

control and recovery.

So you basically take your incident

response script

and you skip

almost the first third of it,

and you jump right into

talking with the legal team and PR.

There's going to be releases.

You've determined

this is something that's

going to be reportable.

Depending on what industry you're

in. You can go back

and figure out with forensics

what happened later,

but there's really no value in the moment

to do as much of that,

as much as to focus on the recovery

and the response.

At this stage,

the breach is no longer contained inside

logs and timelines.

It's crossed

in to disclosures,

notifications and public consequence.

The question is no longer

how deep the intrusion went.

It is

how much of the organization

can survive intact.

But we must also think about

resilience when we tie

that incident response

and defense together,

which is quite often misunderstood.

But, you know,

sometimes risks are realized.

You do succumb to malicious actions

or failing technologies.

So it's really about how do you respond?

Can I continue my operations

even though they might be limited?

You know,

I might only be at 30% production rate.

And that's far

better than going to your customers

and saying,

“I've had to shut shop now”. And then.

Ultimately,

okay, you know, I've fallen victim

to this. Like the Accelion incident.

How quickly can I recover or restart

my full operations?

Recovery is rarely graceful.

It's measured in percentages

30% capacity,

limited operations, partial service.

But in the middle of a crisis, survival

at 30%

can be the difference between rebuilding

and disappearing.

Chris, if a CSO

calls you in a panic

and says we've just been hit,

a legacy system

we depended on for years

has been breached,

what would you tell them to focus on

first?

I would talk to them about what their

response plan is...

what their recovery plan is and say,

you know what,

we can talk about

all the misses that led up to this later.

But let's focus on recovery right now

and everything we can do

to get the company back on track,

to get systems online,

to get things migrated.

Because that's the only thing

that's a priority in that moment,

figuring out who we want

to point fingers at later

and where

shortcomings just in the moment

is just not going to be helpful.

And a lot of people

are going to push for that.

Tell everyone, that's for later.

Now we just got to fix the problem and

and we need all hands on deck

for that

Accellion

did not just expose a vulnerability.

It exposed how many organizations

were running critical systems

without clear ownership,

without independent perspective,

and without a clear plan

for what happens

when the world around them changes.

Ben, for teams

quietly running critical parts

of the business

on older systems,

what's the most important lesson

from Accellion,

especially when it comes to

having options,

getting independent advice

and staying in control

of your modernization timeline?

What would you suggest?

Certainly from a security perspective

as we've said,

you can't defend what you don't know.

And that's not just knowing

what version it is and which servers

it's deployed on,

but what is it connected to?

Who uses it?

What does it deliver to the business?

What would happen

if one of these scenarios happened...

you know, occurred,

the data was removed

from your control or,

or exfiltrated into the public domain?

I would also encourage them,

if you will, to read the small

print of their current support provided,

even if that's the OEM,

because what we find

is that the vulnerabilities

or the risk,

if you will, is not introduced

because of the core product,

but it's all those small bits around it.

Either

the implementation,

the configuration,

which is often out of support scope, or

it's those little open

source components that are shipped

with that core product.

Often there to provide interoperability

that are not supported,

ironically, by the OEM.

But ultimately...

You can't defend

what you don’t know. Ben,

thank you so much for being on the show.

Really appreciate it.

Hope you come back again soon.

Thank you Jeremy.

My pleasure. And Chris, of course.

Thanks for coming back,

doing a second show with us

and looking forward

to having you back for a third time.

You know, I love answering

and asking questions.

And now our closing. The Accellion breach

did not arrive as a thunderclap.

It arrived as a quiet consequence.

A corridor built

for a simpler era,

still standing long after

the map had changed,

still trusted,

still carrying the files

that mattered most,

and then a criminal crew

found the weak point

and did what criminals always do.

They took what they could carry,

and then they threatened to display it.

For some victims,

the pressure arrived

as a demand

that would reshape budgets,

careers and boardrooms overnight.

For others,

the damage arrived

as disclosure and uncertainty,

the kind that lingers

long after the incident ticket

is closed.

What remains after a breach like

this is not just a fear of a zero day.

It is suspicion of the ‘quiet systems’,

the ones that sit in the dark

and never complain

because technical debt is not only code,

it is governance deferred, ownership

Unclear. Decisions postponed.

Because tomorrow feels easier than today.

Systems will continue

to outlive their assumptions.

Adversaries will keep studying

where trust concentrates and

attention slips.

The difference is whether we close

the corridor on our own terms, or wait

until someone else decides

what it's worth to us.

And so we remain forever vigilant

and always listening for The CISO Signal.

If you enjoyed this episode, please like,

share, and subscribe.

If you didn't,

thanks for listening this long.

We'll see you on the next episode

of The CISO Signal.

All episodes are based on publicly

available reports, post-mortems,

and expert analysis.

While we've done our best

to insure accuracy,

some cybersecurity incidents

evolve over time

and not all details have been confirmed.

Our goal is to inform and entertain,

not to assign blame

where facts are unclear.

We've used cautionary language

and we always welcome your corrections.

Thanks for listening to The CISO Signal.