Moderator's introduction
We're moving on. And, as you all know, in an ideal situation experts always have all sorts of software tools to extract everything, to work with everything, do it all right and neatly. In short, as it should be. But, as we know, situations are far from always ideal. What to do in that case is what our next speaker, Yuri Pavensky, will tell us. Please welcome him with a round of applause.
— So, what about the presentation?
— Vladislav got carried away and walked off with the clicker, so I run around. Here you go. Thank you.
Talk
So, good afternoon, dear colleagues, dear participants of Moscow Forensics Day 2026. First of all, I'd like to thank the organisers for the invitation and the chance to speak at today's tenth anniversary conference. My name is Yuri Alekseevich Pavensky, I'm speaking here as an independent expert. And today I suggest we work out together how to examine electronic storage media in a situation where the corporate data network is no longer functioning properly, and the usual access to security tools and their telemetry is no longer available.
I'm sure many of you are wondering how such a situation could even arise in practice. After all, we're such a great company, right, we have a huge number of different security tools at our disposal, including certified ones, well, for example, things like SIEM, EDR, DLP, TI, Web Application Firewall, NGFW, antivirus software and many, many others. On top of that, we regularly run pentests, hands-on exercises, we improve our incident response processes and we go through a huge number of audits by various regulators. And again, here you'll probably say, but the results of those audits always get the highest possible marks, so what could threaten us?
It would seem that with that many tools and measures any incident will be detected in time, and the information needed to investigate it will always be right at hand for the information security staff. But, unfortunately, this assumption contains one of the fundamental mistakes. Because no matter how modern and strong your information security system is in practice, it in no way guarantees that, if you face a serious cyberattack, you will necessarily keep access to your usual security tools and their telemetry. And again, you're probably asking yourself, so what do you do in a situation like that, when the corporate network is down, and the usual access to the security tool consoles is gone.
Let's look into this question using a specific incident as an example.
A case: from a leaked database to encryption and extortion
Let's say a database of a well-known online store was published on the public internet, which included customers' personal data, email addresses and the passwords needed to log in to their accounts. That database included an employee who worked at the company developing a well-known IDM system, who used his personal email address as his login.
I think you all understand perfectly well that as soon as any database is published on the public internet, attackers, as a rule, always work with that kind of information. Basically, that's what happened here too. The attackers, using the discovered password, later managed to get access to this employee's personal email and public cloud service. What happened next? Next, using open sources of information, the attackers obtained some contact details about this employee, identified additional personal email addresses, as well as his corporate email address, and also established the employee's position and organisation.
They didn't stop there, and later, while analysing the contents of the compromised resources, that is, his personal email and cloud service, they established info about the customer organisations this employee regularly worked with, information about privileged AD accounts, and also information about the hosts used and the remote connection methods.
Next, the attackers continued the email correspondence with one of the customers and under the pretext of carrying out additional work obtained remote access to one of the organisation's jump hosts. What happened next? During the first week the attackers behaved as if they really were a contractor, didn't raise any suspicions, but after some time they slowly started gathering information about the domain infrastructure, about the specifics of the network architecture, about accounts and rights, and also about critical servers and databases.
All of this subsequently led to the compromise of several AD accounts, to obtaining the information needed for further use of various privileged and service accounts, and in the end they secured a persistent presence in the IT infrastructure of that organisation. But, again, they didn't stop there. The databases they discovered, containing information about finances, employees, customers and logistics operations, they exfiltrated.
And at the same time, while analysing the organisation's workstations, they came upon the workstation of an IT department employee, which held an unencrypted backup of a personal Apple-made mobile device. Naturally, they liked it a lot, they took it, and later, from parsing that backup, they pulled out photos of confidential documents, pulled out the email correspondence stored there, including some that contained information about credentials that had been passed to one of the contractors.
And also, accordingly, there were network diagrams in there, and some other accounts that were kept in the notes. After the data collection stage was over, the attackers moved on to destructive actions, which ended with the destruction of the IT servers' backups, the deletion of the discovered config files of core-level switches, well, not only core-level switches, but basically other switching and routing equipment as well.
And after that, corresponding changes were made to the config of the core-level switches. And all this led to very sad consequences for the organisation. The corporate network stopped functioning properly, its connectivity broke down, and this led to consequences such as degradation of the domain environment, loss of normal access to the security tools, and certain centralised restrictions on the corresponding telemetry.
Yes, and most importantly, on the previous slide, I forgot to mention, that already at this stage, after these consequences had set in, a rapid reconstruction of the attack with standard tools was no longer possible. Next, accordingly, the attackers, well, not even next, I'd say, at the same time as these actions, the attackers changed the access passwords to various databases, after which those databases were encrypted.
Some time later the attackers made contact with the IT department employee via the Telegram messenger, informing him of the compromise of the organisation's IT infrastructure, as well as of a ransom demand for restoring access to the data. In addition, the attackers said they had captured his unencrypted backup, which contained sensitive data, and they also threatened to publish the full package of information online. As you understand, such a package would clearly have damaged the honour, dignity and even business reputation of this employee. And to confirm the reality of that threat, a certain fragment of the data was in fact published in one of the public Telegram channels.
So, let's draw a brief conclusion from this case. As you may have noticed, that the compromise of a single personal account can lead to an incident of this scale. Furthermore, giving contractor organisations remote access without proper control can lead to quite high risks. Beyond that, you also need to bear in mind that unauthorised storage of confidential information on personal mobile devices, as well as in their backups, can cause damage both to the company itself, and to the organisation's employees.
And probably the saddest and most dismal thing is that in conditions where we don't have access to the security tools we're all used to, when we're simply, in principle, not accustomed to such situations in practice and don't even expect them, the only key instrument for restoring the full picture of the incident is exclusively digital forensics.
So, well, thus, yes, having discussed, accordingly, all this information, well, we all understand perfectly, yes, that at this stage the entire attack chain has been established. Well, only we can see that whole attack chain. But in practice, at the moment such an incident is detected, the information security staff don't see that picture yet. All they have is the initial data, such as the corporate network not working normally, failures of specific nodes and databases.
It may be a message received from the attacker, and, accordingly, it may be a fragment of data published on the public internet. That's exactly why, within the response process for this kind of incident, there are ten interrelated stages, from recording the initial report and preliminarily establishing the scale of the incident, through to reconstructing the attack sequence, restoring the IT infrastructure and closing the incident. And, again, I'd like to note that we won't be going through each stage in the most detail today, due to the limited time of my talk, so, if you're interested, yes, and you really want to understand what needs to be done in this situation in the most detail, yes, at each stage, you can scan this little QR code, so, in the first folder there'll be a document, it's called "General Response Procedure", yes.
You can download it, this QR code will also be on all the following slides, so at any convenient moment you'll be able to get access to that information. But if someone doesn't manage to scan it, you can come up to me separately, and I'll give you that information. So, well, again, from here on I'll focus on the core logic of choosing actions toward each node in an incident like this, I'll talk about how to properly preserve volatile artifacts and obtain verifiable data copies. Along with that, we'll also carry out the reconstruction of the attack sequence together.
Isolate, image or leave alone: the logic for each node
So, speaking directly about choosing what to do toward each node, here you need to bear the following in mind. That here there's no such thing as a so-called universal rule. Something like, we absolutely must, with you, immediately isolate every host in our organisation. Or, for example, that we are strictly required, from every host, without exception, to collect absolutely all the information in order to have some kind of complete picture.
That is, I believe these rules overall should be flexible and not categorical. Why? Well, because if we, with you, isolate every host, well, you know, if we, and here I'm still considering a more or less normal case, if some system of ours happens to still be alive after the incident, then after isolation there's a risk that something might then go wrong with it. Especially with some database that, say, data was being copied into at that moment. Or, for example, if it's some, you know, insanely complex incident to investigate, we risk simply and thoughtlessly losing the necessary artifacts that would have let us reconstruct the whole attack chain.
If we're talking about full data collection from every host, let's imagine our organisation has 2,000 hosts, 10,000 hosts, 100,000 hosts. Can you imagine how long we'll be collecting a full data package from every device? I'm afraid we'll be collecting information until our company shuts down because of this incident. So that's also a completely wrong approach, you definitely mustn't do that.
So, you'll probably ask, what are we to do, then, given these nuances? It's all very simple. We need to assess the node's connection to the incident. That's the simplest thing you need to do. If we've established such a connection, the next step is to assess whether the damage is ongoing, both on the host itself and through it, or whether there's any suspicious network connection. If any one of these conditions is present, then we move on. We check whether any network access remains to any systems and resources that are still alive. Again, yes, you'll ask, but our corporate network is down, what access to other resources could there be?
Well, actually, that's very simple too. If our box lives in the same VLAN as those systems, there's a good chance that such access to those resources may well remain. So you also need to keep that in mind. And the last general rule, which applies to everything. It's also important to account for technical limitations, because it may turn out that the box, say, isn't running quite stably. And if you collect data from it in a not-quite-correct way, there's a risk the box will simply stop working. Or, for example, take the same switches and routers. Take Huawei, for instance, let's keep it simple, just as an example.
As you well understand, there's a huge number of models by purpose. The devices can differ from each other. And it might seem there could be one and the same operating system, Huawei VRP, but in practice different commands may actually be used. So they, in turn, when executed, may again have a different impact on those same network devices. So all of that also needs to be kept in mind. So, moving on to specifics. Once again, if we have a connection between the node and the incident, but at the same time no damage is ongoing, there are no suspicious network connections of any kind, if at the same time no network path remains to our resources, then in that case you don't need to drop everything and isolate that host.
Well, you can of course do it if you're very worried, very scared, I don't know, you can cross yourself if you like, but you definitely shouldn't, well, at least I wouldn't do it, because the host, essentially, is already isolated, it has no access to anything at all, in any way, it's essentially running standalone. So in that case we just need to preserve the volatile data, and then not touch that host at all, until we get to obtaining persistent data. Not at all. If we have a host that's connected to the incident, but at the same time active encryption, modification, deletion, copying of data is going on, caused by the attacker, well, probably the first thing you'll say is, that's it, now this host definitely has to be isolated.
No, colleagues, here too this question, I think, is rather philosophical, yes, and making that decision, you have to manage it, because, let me explain, because if, for example, it's some critically important host, yes, if, for example, some operation is currently running against those same databases, there's a risk that we do network isolation, the connection drops, some commands don't complete, who knows, something somewhere, we don't know what scripts the attacker might be using at that moment. And the database itself could go down.
And restoring it, especially in conditions where the AD servers' backups have been deleted, will be problematic. That's an example. So, that's why, if we understand that we have at least two minutes, colleagues, more probably isn't needed. If we understand that in those two minutes no catastrophe will happen to that node, under those conditions we can obtain the volatile data.
Because if, again, we do network isolation, we'll lose a huge number of such artifacts. That's 100%. So while they're there, we have to make use of them. Again, I'm not telling you that, you know, using Linux as an example, I'm not saying you now need to enter about 67 or more commands to obtain all the necessary volatile data. No, of course, you should by no means do that manually.
You won't fit it into two minutes then. For that, it's recommended to use an appropriate automated script. If you don't have one, consider that after today's talk you do. You can also scan the little QR code. There, first of all, you'll find a full list of commands that need to be entered to obtain some top-priority volatile data. Depending on the operating system: the Windows family, macOS, Unix-like operating systems based on the Linux kernel.
I'll get to switches and routers a bit later, but that information is basically there too. And the corresponding automated scripts are there, which you can also use in practice. They're PowerShell ones, you can... Well, some are PowerShell, some are other kinds of scripts. In short, you can use them in practice. In a couple of minutes all the necessary information will be exported for you and a corresponding report will even be generated.
Right, what else did I want to say. If our node is in no way connected to the incident, that node must not be touched under any circumstances. Why would we need it, why waste extra time on it? Let it keep living its own life over there. Now, if during the incident investigation we do somehow end up at that node, then we'll need it, then we'll actually work with it. But as long as it's not connected to the incident, we don't need it. If the node is powered off, there's no need to power it on and boot the preinstalled operating system for this.
Well, at least not within this stage, definitely not... In fact, in principle, you shouldn't do that at all, because then our persistent data will change. So, and the last thing I'll probably mention is virtual machines. So, if we have the technical ability, and if we're confident that the hypervisor cannot make any unacceptable changes to the guest operating system's data, in that case we can create a snapshot preserving the RAM. And I want to say up front that before pressing that little button, creating the snapshot, please don't do anything on that box whatsoever.
So that everything is preserved intact and safe. Again, you'll surely say, what hypervisor could there be here, if our corporate network is down, how would we even connect to it. But actually, that's very simple too. If the servers aren't outsourced, somewhere on the other side of Russia, in another country, but are in your office, of course you can take a non-domain workstation in the form of a laptop and connect either to the corresponding SAN switch, or directly to the management port of that equipment. Then in that case you'll get access to the hypervisor and then, accordingly, to the virtual machine itself.
But, accordingly, the other specifics, which have to do with encrypted drives, with switches and routers directly, in terms of choosing the logic of action, I mean, in terms of some unfinished remote sessions and so on, you can also study all that information in detail by following the link in that QR code.
The order in which volatile data is collected
So, we've now reached the stage itself, which is called the order of collecting volatile artifacts and obtaining data at high risk of loss. So, what needs to be kept in mind here? That at this particular stage, first and foremost, we're not interested in all the info that exists on the media as a whole. I'm talking about this exact stage, we're primarily interested in the data that may somehow be altered or lost as a result of the OS running, as a result of the attacker's actions, or as a result of network isolation. What are we interested in first? First of all, we're interested in basic node information, like the hostname, details of the current user account, the version of the operating system or the loaded kernel, the system date, time, time zone, the time from an independent source.
If there are any time discrepancies, those discrepancies also need to be recorded. And we're also interested in the node's uptime since the operating system booted. Next, we're interested in information about user activity. Here we can talk about such information as data on active users and sessions.
We're interested in cached authentication data for the current sessions, information about running processes and services with their launch parameters, and information about open files. Next, we're interested in local logs with a high risk of being overwritten. You'll probably say, why collect local logs at this stage, they're stored in persistent storage, so we'll take a sector-by-sector, or, as some people say, bit-by-bit copy, and we'll somehow recover those logs from there, somehow pull them out. But you know, colleagues, if something is written there constantly, every second, then again, over that time there's, in general, a risk, especially while you're also still busy collecting some volatile data, that some of the data may get overwritten anyway.
So, if possible, some local logs also need to be exported. You don't need to export all of it. It happens that local logs weigh in at terabytes. And then you'll be exporting until night, I don't know, for a week, probably, exporting, I don't know how long. But, again, we're interested in the info for at least the past 24 hours. I don't think that will be some really huge volume of data.
So, again, I'm talking about logs, and you'll probably ask which logs I mean. Well, if we're talking about Windows family operating systems, for my part I would recommend still exporting part of the data from logs such as System, Security, WinRM Operational, TS-RCM Operational, TS-LSM Operational, OpenSSH Operational, I don't remember if I said it, WinRM Operational. And, most importantly of course, Windows PowerShell and PowerShell Operational. If we're talking about Linux operating systems, in that case we're interested in logs such as syslog, audit, secure, kern, messages, daemon, xrdp and xrdp-sesman. Sesman. Oh, and auth as well, one of the most essential logs.
After that, ah, if we're talking about macOS, here we'll primarily be interested in syslog and Unified. So, what next, yes, what do we do after the logs? Once we've exported those logs, we're interested in information about loaded drivers, kernel extension modules and, accordingly, information about active inter-process communication mechanisms. And the very last thing that should also interest us is information about the host's network state. That is, information about its network interfaces, active established network connections, listening ports, the routing table and information about neighboring hosts. Here I mean ARP and NDP.
As I said, we need all this data. Again, under no circumstances do we save it to the persistent drive, we save it either to external media, or to an isolated network storage, that operates independently of the main corporate network. Well, again, that's if someone happens to have such an option, who knows.
Switches and routers: how to connect and what to collect
So, on this slide we'll discuss collecting volatile data from switches and routers. So, what else needs to be said here? In general, in principle, a loss of connectivity in the corporate network, of course, by no means yet indicates that our network device has somehow been compromised. No, by no means does it indicate that yet. It only indicates that either a technical failure occurred on the equipment, which happens quite often.
It could be the clumsy hands of the IT department staff, who at some point were setting up the corresponding configuration. Or it could indeed be attackers. As it was in this particular case. So, how do we connect to such network devices? Clearly, if there's no connectivity in the corporate network, if we can't somehow connect to these devices over the network, the only correct option, probably, is to connect from a standalone, non-domain laptop using the appropriate console cable.
And then the very first thing you must do before you establish the session is to start recording that very terminal session, so that all further actions are captured, and to establish the time from an independent source. Next, the very first command after you enter your credentials should be the command to view the shell history for all users. Why is that so important? It's so important because later, when you use other commands to obtain volatile data, there's a high risk that old entries will be pushed out by new ones.
So it's better to capture that whole history first. And then, accordingly, what information do we need to obtain. It's all very similar here, actually. Information, that is, the hostname, information about the current account we're working under.
That's the system date, time, time zone. And again its deviation from an independent source. Then it could be the operating system's uptime. The operating system version, it could be local logs, administrative sessions, network routes and whatever data remains in the main operational tables.
What else did I want to tell you about switches. Ah, yes, most importantly, of course, when collecting volatile data we never, under any circumstances, use write commands. That is, again, what I want to say is we use not just commands for viewing information, but commands verified in advance, whose execution should be obvious to us in terms of what result we'll get and what load on the device it may cause. Because, again, speaking of the load on the device, there are nuances there too. That is, again, you have to understand that any connection to a network device, I don't know, any command entered, even a read-only one, has a negative effect on the shell history, on the corresponding local logs, and also, accordingly, it may also be reflected in the AAA systems.
And most importantly, it can cause a short-term increase in load on the device itself. Again, speaking of collecting information, you'll probably say: well, here we go, again you have to enter a huge number of commands manually, again, that'll take a lot of time, and why is it all needed? Agreed, you don't need to enter all these commands manually. That is, again, for such actions you use an appropriate automated script, which I've personally used myself. In maybe one or two minutes it will export all the necessary information for you.
And by the way, it's also available at this link, via the QR code.
Persistent data and verifiable copies
So, now we've moved on to persistent data. I don't know why the letter O is glowing red. Oh well. So, what I want to say here. That is, within this stage, our task is to obtain such a copy of the data whose origin and integrity could subsequently be verified. Yes, for that we record the data source, the method of extracting the information, the tool and its version, we note the storage location, well, where the obtained result is saved, the time of the operation, and we calculate the corresponding checksums.
So, again, yes, what...
[Here the recording breaks off mid-sentence: only part of Yuri Pavensky’s talk made it into the stream, and there is no Q&A for it in the recording. The rest of day 2 (Maxim Sukhanov, Alexander Dmitriev, Viktor Alyushin, Artur Igityan and the closing of the conference) is not in the recording.]