# How not to end up needing forensics, and what to do if it can't be avoided

Konstantin Titkov · Gazprombank

MOSCOW FORENSICS DAY ’25 · Day 2 — Friday, 12 September 2025: information security day · Scheduled 14:20–14:50 · In the recording 06:58:14–07:26:12

Talk transcript · https://2025.moscow-forensics-day.workers.dev/en/transcript/16-titkov
Summary: https://2025.moscow-forensics-day.workers.dev/en/summary/16-titkov · Slides: https://2025.moscow-forensics-day.workers.dev/en/slides/15-titkov-kak-ne-dovesti-do-forenziki · Watch from 06:58:14: https://youtu.be/4V7Wez3L_58?t=25094

---

## Moderator's introduction

So, colleagues, let's move on. Usually it goes like this: there's no smoke without fire. But in fact, once it burns, it's too late to put it out. In general, with information security the situation is about the same. So, how not to let it get to a fire, and what to do if it happens anyway? Our next speaker, Konstantin Titkov, will cover that. Let's give him a round of applause.

Konstantin, here's the clicker. Advance the slides over here. And the microphone is on. —

## Talk and Q&A

Thank you. Hello, colleagues. Our organizers sensibly alternate talks of different kinds. I'm essentially continuing, logically, the talk Nikita Vyugin gave earlier. I'll give you a lot of tools that may come in handy when talking to your management, to business owners, to clients. So please, don't hesitate to take photos, take notes, move up closer, unless of course you've got a super telephoto lens. Otherwise you may miss a lot. At the end, links to materials with QR codes. I recommend photographing them and taking them along. So, we're going to talk about what to do if all those preparatory measures, EDR, antivirus, firewalling, didn't deliver the expected result, and your cybersecurity risk has materialized: your infrastructure is encrypted, the data stolen, or everything just wiped.

What do we do about it? A word about me. I head the cybersecurity center for Gazprombank's subsidiaries. I'm also an ambassador for Cyberdom, meaning I help get important cybersecurity information across to Russian business. What's on the agenda today? What's wrong with our typical IT incident response plans? What emergency actions can be taken? Who can help, and how? Spoiler: a company that's genuinely good at DFIR, of course. The stages of incident response, what to do afterwards, the specifics of a personal data leak, and above all, what a business can do in advance to recover faster and make it hurt less.

A few examples that happened literally in July of this year. A large federal beverage producer, a retail chain. Hit by ransomware, shipments stopped, sales stopped. What did customers do? Customers went to another store round the corner, bought it all. There they got a loyalty card and were told: come again, we'll sell you more. Same thing with a federal pharmacy chain. Direct loss of customers. That's only the tip of the iceberg. A major airline was recovering. Two weeks later I read the news. We are still calculating the amount of fuel for refueling our aircraft not with the help of specialized software, but based on fuel consumption statistics for flights on similar routes over recent years. So what can we take from this? Not all of the business could be restored even two weeks later.

Moving on. So what does a business that's been encrypted or wiped try to do first? It tries to recover, to restore its core processes. And in doing so they forget to find the attacker: how he got in, all his persistence points, tunnels, backdoors, web shells, compromised remote-access accounts, newly created remote-access accounts disguised as service accounts, and so on. So they try to restore something, the attackers watch this, delete it, destroy it, see that the efforts are failing, and raise the ransom. Well, if they're financially motivated. Whereas first of all, of course, you do need to kick the attacker off the infrastructure first and only then fix and restore it.

So, an IT incident. What do we usually have? A software failure. One-off or recurring. A hardware failure. Human error. A screw-up, that is. Someone entered it wrong, deleted it, broke it. We restore from backup, replace the hardware, roll back the software version, contact tech support. We have staff for this, because these are expected incidents, we expect them to happen. We train employees for this, we buy technical support for this, we have operating manuals and so on, even some kind of recovery plans. Even backups. Maybe there are even some among you who have at least once tried restoring backups and checking that it works.

If you haven't done that, please do, it's extremely important. Like that story with GitHub, when they went down, they had six backups and couldn't bring any of them up. Okay, what is a security incident? It's a deliberate malicious action against your infrastructure, the whole of it and any element of it, against your personnel, your employees, and it's adaptive, taking into account how you try to resist, and restore it. And if the correct action in this situation is to work from a pre-developed cyber incident response plan, which is drawn up on the assumption that we come to work on Monday, and all we have available is the phone in our pocket and all that was switched off, and all that was switched on, consider it unavailable.

What will you do, and how long will it take to restore the whole infrastructure, data and processes? Well, actually, in practice, it usually starts with time lost to panic. The IT department tries changing passwords, tries restoring something from backups, the drives with backup copies get connected to the infected infrastructure, the attackers, of course, wait for this, and those backup copies on those connected drives, what? They delete them. Great. And an hour, two, three, a day later, I know cases where on day three it dawns on us that we're doing something wrong, that we've wasted our time, effort and money, and we must respond to the incident, that is, do DFIR, Digital Forensics and Incident Response, rather than just trying to fight it as an IT failure.

Well, when does it usually happen? Friday, public holidays, weekends; lately it's started happening on Thursdays sometimes. Why? Because ransomware or a wiper needs time to destroy the whole infrastructure. They're write operations, they take time, so ideally you don't get in their way. And here it's vital to have employees' phone numbers to call them in to work, recall them from the dacha, a picnic, vacation or a business trip. You do have the numbers of employees' relatives, so you can reach them on a day off, printed out on paper, right? And you have to rely on all the groundwork the company has done in advance. Because only that will let you (a) recover, and (b) do it as fast as possible.

And here, of course, the ability to call in help is invaluable. Why do I draw that conclusion? Because I've spent several Fridays on the phone talking to my friends, who came to me for help and advice when the infrastructure they were responsible for had been encrypted. And we were discussing, you understand, not old classmates, but the sequence of steps for restoring their infrastructure. And after two or three such conversations I concluded that this is probably not how to spend a Friday. My colleagues shown on the slide and I drew up recommendations, because, unfortunately, we couldn't find any publicly available recommendations online that were sufficiently complete, correct and exhaustive. And so today I'm presenting them to you, I'll run through them briefly, with links at the end to download them for use.

The purpose of the recommendations is to give an understanding of what to do, what needs to be done in advance so that you're able to do it, and an understanding that you have to act, and act fast. We describe how it could've happened, the main intrusion vectors, so that you can convey to the client, to the business owner, to the CEO, what exactly, if you don't deal with it, will increase the likelihood of this sad event. We consider whether to pay the ransom. In a nutshell, we remember that ransomware is a program, and if you try to buy the decryption keys from the attackers, first of all, they may not work, because what matters to the attackers is encrypting your infrastructure, while decrypting is a secondary task for them, they may not have tested it, that's one thing. Secondly, you may simply not get the encryption keys for your money, especially being in the.ru zone, a Russian company and so on.

And you have to understand that your bank may not just fail to help you but refuse to process a payment to the attackers, citing anti-money-laundering and counter-terrorist-financing rules. And worst of all, if you do manage to push that payment through, it may later be classified precisely as financing of terrorism, with all the sad consequences for everyone who took part in making that payment. So, the main emergency actions, and this is only the tip of the iceberg. Check online banking transactions. Because of course your accountant has a printout with the addresses, phone numbers of whom to call, with what details, to verify the payment orders that were sent but perhaps not yet executed. Maybe there are malicious ones that can still be cancelled and the money recovered.

Don't power off or reboot the equipment, to preserve the forensic data in memory. Isolate what's valuable, above all the backup system and the backups. Take snapshots of the VMs, if still possible, the virtualization system isn't destroyed. Examine outbound traffic, to see what was downloaded from you, stolen, and assume a possible data leak. Consider network isolation of the company as a whole or of certain segments. Take care of the staff's work schedule, since the company is now switching to 24/7 mode, most likely for several days, or maybe weeks. HR — take care of how they'll pay for the overtime, how they'll process it. PR — how they'll interact with the regulator, with clients and with the press, preferably with press release drafts prepared in advance.

IT — where they'll restore from and which contractors they'll bring in to help as extra pairs of sysadmin hands and onto what hardware or into which cloud they'll do that, Security — which DFIR expert firm they'll bring in, and so on. The roles are spelled out there too. Each can carve out their own piece of the recommendations and do their preparatory homework in advance. As for help, yes, of course, we mean companies that are good at DFIR. There are recommendations on choosing the company and the engagement mode. Obviously you agree on the number of experts, date and time of the visit, address, contacts, meeting, passes, parking, kick-off meeting, planning. What do we want?

Do we, say, want not just to investigate but also to prosecute? Or do we want to investigate and, if possible, avoid publicity? Prosecute without publicity? Those are hard to combine with each other. The experts will point that out. Analysis of the compromised hosts, identifying all the entry points, disk analysis, and so on, and so on, and so on, clean-up, and only then do you get on with recovery. Obviously you're interested in restoring the company as quickly as possible, we have to save time, you need to know how many DFIR experts will be working, and it's important that you can provide the same synchronous working mode for your own specialists.

Otherwise they'll sit and wait for you to wake up and come to work, and they'll be idle. Need I say that all CII entities must first of all report to GosSOPKA or to an accredited GosSOPKA centre, or to the NKTsKI. What to prepare for the expert's arrival? That's a workplace, and communications outside the affected infrastructure. Because otherwise the attackers will be reading your email, your messenger, your personal messengers, if you logged into them from equipment connected to your infrastructure, they'll read them and take measures to obstruct you, knowing what you're preparing to do. Moreover, they'll post screenshots of your correspondence online and mock you in every possible way. So it's better to set up communications outside the infrastructure

at once. We talked about synchronous mode. Cancel vacations, business trips, resignations. That is, everyone who can work must be called to arms. Now let's run through the response stages. Many variants here, based on the SANS guide. But I'd like to point out that the first one is incident preparation. What you as a company, your clients, can do in advance. OS, application, DBMS and security tool logs. Do they exist at all? Are they detailed enough? For how long are they retained, and where? Won't they be wiped or erased or encrypted together with the infrastructure? Disks. Physically, a DFIR expert can find, together with you, exactly where those hard drives are, in which server.

That is, map an IP address to a specific rack unit. Pick them up, physically unscrew them, make sure there are no locks. And if you used, say, your own protection tools like BitLocker, then decrypt them too. Artifacts. Can you run the necessary program on every host in your infrastructure? Do you have network access? And access rights, an account, and do you remember the password for it? And it's surely not written in a file on the server that's going to be encrypted? Such cases, unfortunately, are unheard of. Reserves. Do you have a financial reserve for bringing in a contractor, for computing capacity that you'll be restoring onto, since some of your equipment may later be subject to seizure?

Backups and so on. And have you backed up the installation packages? And the license keys for those packages, have you backed those up too? Especially for "trophy" software, where you can't request them from the vendor again.

Stage two is identification. It's great if you use TI feeds. You may learn of a planned attack on your infrastructure before anything has happened. A kind of shift-left. Then perhaps your whole response comes down to two or three hours, and there won't really be any downtime. A compromise assessment will be enough. If not, worse. Perhaps your SOC will react and say something suspicious is going on. If you don't have one, well, maybe you at least have managed EDR, and the partners will say, guys, something's suspicious on those hosts. No managed, then maybe at least your own EDR. Well, it's worse when we just see in IT monitoring antiviruses being methodically disabled on hosts. Also suspicious, you'll agree, if antiviruses get switched off. And attackers will disable security tools, they simply get in the way. They might block, say, the ransomware launch, or whatever. Well, worst case, if you haven't taken care of the rest, you'll read in a Telegram channel on vacation that there's no point coming back, nowhere to come back to.

Containment. That's probably the last thing a company can do on its own, without any help. Isolate the equipment, don't reboot, but disconnect from the LAN. VMs, physical machines, other interfaces too, and disconnect from the SAN. Particularly cunning and nasty malware can, for example, trigger encryption if it loses contact with its command centre. That is, you've cut your infrastructure off the internet so that nobody interferes with your investigation and recovery. And some ransomware launches precisely at that moment. So, accordingly, if you have a mature infrastructure, all your data is on storage arrays, accessible via the SAN, the data network. You disconnect that network, and whatever's running in the OS, the ransomware, has nothing to encrypt. All on disconnected storage.

Cleanup. This is exactly where you need experts, of course. That's essentially finding and removing every single backdoor, no exceptions. Restoring security controls that may have been disabled, tampered with, or had exclusions added to them. And then changing passwords. Everywhere. Domain, local, on *nix boxes, Macs, Windows, standalone workstations, in DBMSs, VPNs, applications, external online accounts, access certificates, one-way and two-way, the tax service (FNS) portal accounts, and so on. It's crucial, I'll explain why a bit later, not to forget anything at all. And don't forget the system accounts either.

Well, recovery and lessons learned. This is where you restore all your data from backups. And most likely you'll first set up the apps from the installation packages, applying all the patches, and only then restoring the data from backups. If you still have them, of course. For example, if you use the 3-2-1 backup scheme. Three backup copies on two media, one of which is outside your infrastructure. And preferably with integrity checking, too. You've recovered, you've restored the data. Those without backups start looking for test environments. Listen, I think on the test environment we once deployed production data for testing. Let's restore from that.

Bad idea, of course, production data in test, but everyone does it differently. And some say, well, so now, in three shifts, the whole team will key data into the database from the paper originals. Two weeks or so. That happens too. Incident response report. Recommendations, a plan of work so it doesn't happen a second time. All this can take a while. I mean, as I said, if the ransomware hasn't launched yet, maybe in 2-3 hours you'll sort out the whole situation and kick the bad guys out. But if your IT team now goes and mass-changes passwords, then the attacker goes, oh, they're changing passwords. They've probably noticed me.

Well, we launch. Godspeed. And we go straight on to the second one. Encryption has run, and here it's already measured in days, weeks. Well, if you prepared, then days; if you didn't, then weeks. It can be done online, remotely. Especially relevant for those whose infrastructure is far from the federal centres. It just takes the experts ages to get there, 3 days by dog sled. But here it's very important that the hands on site will be yours, your staff. If you don't have enough people or enough expertise, say they're all juniors, that happens, then it may end up only worse and take longer than if the experts came to you.

And unfortunately that's not all, plenty of fun awaits you afterwards. That is, you go to law enforcement with the complaint materials, the DFIR report that you prepared either yourselves or together with the experts you brought in, crime report register (KUSP) entry, getting a number, then possibly a seizure, opening a criminal case, a certificate recognizing the company as victim, so that when dealing with other government bodies, say, if you got encrypted at the end of a tax or reporting period, you're able to say: we're not hiding our financial statements from you, we just can't submit them on time, don't execute us.

But that's not all either. They may have stolen data, for example, personal data. And if you paid the ransom earlier, for example, then it's a nice move to ask you for a second ransom for deleting that data. But as a rule, nobody deletes it. Even if they got the ransom, it's still sold, published later. And then roughly 6 billion people, give or take, the adult population of our planet, can do whatever they want with that data. What will they do? Now, for the personal data, the regulator comes straight to you. Customers, obviously, will be unhappy and will file complaints. If there's customer data in there with the contract terms, then your competitors go, oh, good customers, they pay on time, let's give them a small discount and poach them. Interesting?

Your intellectual property, for example, source code. Great, convenient. Keys and passwords. This is exactly the big problem: roughly several billion people can now calmly parse your data, and everything they find there, logins and passwords, try to use in your interface or in those of your counterparties, customers, and government regulators, to log in as you and do something nasty. So back at that stage we changed everything. If personal data leaks, the notifications. And the most fun part. Be prepared that in future, 100% and more than once, maybe even every day, information will appear on the internet that you've supposedly been hacked again and your data stolen again. And sample data will be published, it's your old data, plus enriched with made-up, generated data or data from other leaks. And now every time you'll have to go proving your innocence.

You'll be comparing this data posted on the internet with what you have now and what you had at the time of the incident, and trying to work out if we've been hacked again. Or if attackers are just trying to pass off a compilation as a new breach. So either we say it's all a lie, or we say we need to do the DFIR all over again. And if it isn't all a lie, then in fact in every real case you must notify Roskomnadzor within 24 hours, including about a fake leak. You still have to notify within 24 hours, and within 72 hours send a report on the internal investigation's results. And we said that DFIR takes several days even if prepared. It's not some other 72 hours.

CII entities must notify NKTsKI, entities under the Central Bank, FinCERT. Well, maybe someone also complies with GDPR, I don't know. So for every body you have to inform, it's advisable to figure out in advance who will do it, based on what template, where to submit the report, who to coordinate with, who they are, whether they're authorized, and so on. And if the interface is unavailable, through your fault or not, how do you deliver it on paper and where, and how do you get a receipt stamp. Well, accordingly, my personal recommendation for preparing any report is to make it complete and exhaustive, because government regulators have little time either, and getting into correspondence isn't worth it. Better to describe in full right away what happened, what's been done, what we plan to do.

Well, accordingly, if the worst hasn't happened yet, but there's a suspicion it might, you can carry out a compromise assessment. It's a sort of light version of DFIR: logs are collected, traffic is collected and a probabilistic conclusion is made: has your infrastructure been compromised, the attackers are already inside, or not compromised yet. Why? From the reports of the largest cybersecurity companies and the reports of digital forensics labs, we see that before launching encryption or a wipe in the infrastructure, attackers may spend 3, 6, or even 9 months there, doing reconnaissance, downloading all they can, looking for backups to delete them too, or encrypt them, so it's harder for you to get back up.

And it may be that during that not-so-short period, if you get suspicious, you run a CA and find yes, the attackers are there, they're preparing to destroy your company, and with far fewer people and resources it'll be much cheaper to counter them and throw them out. How to prepare? CISOs, CIOs, CTOs, directors of IT and cybersecurity can develop in advance a response plan for exactly the case of a successful cyberattack with the most dire consequences. And it's not an IT recovery plan at all, it's a completely different kind of plan. Create the necessary reserves for this case, including finances, hardware, software, and a lot of printed paper, in advance.

Pay special attention to the security not only of data backups, but also of backups of application software and license keys, and protect the backup system itself. Because this story, where the backup system, its server sits in a flat network with the hosts it backs up, and the workstation from which the backup system is administered is also in that flat network, and domain-joined as well. So, do you think you'll have any backups left if ransomware runs? No, of course not. And, actually, run response exercises, even if only tabletop ones. We came in on Monday, nothing works except what was powered off.

How much time will we need to restore operations fully or to whatever extent the business needs? And is the business okay with that timeframe? Is it fine? If not, investment is needed. And there are two kinds of investment. Investment in reducing the likelihood of an incident. That's antivirus, firewalls, SOC, EDR, and so on. And then there are investments, reducing downtime and reducing the damage when an incident does happen. Those are different measures. And some of them, just as with hardening, you can do in advance, calmly, for free. Not all of them, but a great many. Including choosing your DFIR partners in advance, or running a compromise assessment periodically, or something else.

How can a CEO prepare for this? First, pass the recommendations to your IT and security teams, check, make sure that everyone can do it all, knows how, and nobody's embarrassed to say they can't do something or lack something. If needed, give them what they need. Estimate the operational downtime of the company in an incident with the grimmest consequences. And decide, honestly, am I OK with that downtime? Are these losses, reputational damage, customer churn, fines, inspections and so on, acceptable to me or not. During an incident, bring in every possible resource, support with everything you've got, support the team, support the employees. And the main thing to remember: any employee who let an incident happen, through their own fault or not, but who is demotivated, will have no interest in cleaning it up. But the one who took all measures and every effort to get the company back on its feet, to eliminate the consequences for the company, is worth two new ones.

Recommendations linked, they're published together with Cyberdom, formatted, available for download. Please use them for the good health of your companies, your partners, your clients. Thank you for your attention.

Konstantin, thank you very much. Questions? Thank you, very interesting. Here's my question. Isn't it a bit late to shut the barn door after the incident? So, from experience: cases where encryption, including of the backups, has already been done, versus cases where it was caught only at the very start, that is, an incident still in preparation versus one already carried out, Which is there more of, as a rule? You see, it would be more correct to put that question to the companies that get called in to do DFIR. Because you and I can look at it from the outside, but survivorship bias is a thing. Many of those who couldn't recover don't come to these conferences don't talk about it. Because the business is completely destroyed. Well, sure, so they hide the information, but we all see it once it's already happened, but overall...

Our job, yours and mine, is to prepare so that when, or if, this happens, a) we recover, b) we do it as fast as possible. —

— Well, that's clear. Thank you. And a lot can be done in advance, easily and for free. Start by printing out what will be unrecoverable in case of encryption but will be needed first. I basically said that at the very beginning too, so thank you. —

— So, colleagues, more questions?

Konstantin, I see no hands, so thank you very much. Let's see Konstantin off with a round of applause. Right, the microphone. And we, colleagues, are now going on a break, and we meet again in this hall at 3:30. Thank you.

Thank you. On to a separate block of today's conference. So I ask everyone to please return to the hall. You can bring along whatever you picked up in the catering area. And in literally a couple of minutes we'll start moving on. Thank you.

*[music]*

*[music]*

*[music]*

*[A break (14:55–15:30 in the program) is cut from the recording; about a minute and a half of music remains from it.]*