A reader recently commented and asked that the topic of scoping an incident and tracking lateral movement be addressed.  I've performed incident response for some time and been involved in a wide variety of cases, so I thought I'd present something about the types of lateral movement I've encountered and how these types of cases were scoped. Some types of lateral movement are easier to scope than others, so YMMV.

When there's been lateral movement there are usually two systems involved; system A (the source) and system B (the destination).  Throughout this post, I'll try to point out which system the artifacts would appear on, as this can be a very important distinction.

SQL Injection
SQL injection (SQLi) is an interesting beast, as this exploit, if successful, allows an unprivileged user to access a system on your network, often with System-level privileges.  Not all SQLi cases necessarily involve lateral movement, specifically if the web and database servers are on the same system.  However, I have been involved in cases in which the web server was in the DMZ, but the database server was situated on the internal infrastructure.

After gaining access to a system via this type of exploit, the next thing we tended to see was that a reverse shell tool was downloaded and launched on the system, providing shell-based access to the attacker.  Very often, this can be achieved through the use of a modified version of VNC, of which there are several variants (OpenVNC, TightVNC, RealVNC, etc.). It was usually at this point that the intruder was able to orient themselves, perform recon, and then 'hop' to other systems, as necessary.

Tools: Editor, coding skillz


Terminal Services
I was once engaged in a case where an employee's home system had been compromised, and a keystroke logger installed.  The intruder found that the user used their home system to access their employer's infrastructure via Terminal Services, and took advantage of this to use the stolen credentials to access the infrastructure themselves.  The access was via RDP, and after initial access to the infrastructure, the intruder continued to use RDP to access other systems.  Further, all of the systems that the intruder logged into had never been accessed with those credentials.  As such, it was a simple matter to examine a few artifacts on the each of the "compromised" systems in turn, and then to verify other systems on which the user profile was found.

The systems that we dealt with were a mix of Windows XP, and Windows 2000 and 2003 for servers.  As such, the artifacts we were interested in were found in the user profile's NTUSER.DAT hive file.  If the workstation systems had been Windows 7 systems, we would have included Jump Lists (specifically, those with the AppID specific to Terminal Services) in our examination.

The system A artifacts would include Registry values, and for Windows 7 systems, Jump Lists.  Depending upon the actions the user took (i.e., double-clicking a file), there may also be shortcuts/LNK files that point to the remote system.

System B artifacts would include logins found in the Security Event Log...on Win2003 systems, look for event ID 528 type 10 logins.  On Win2008 R2, look for event ID 4624 events, as well as TerminalServices-LocalSessionManager events with ID 21.

Tools: RegRipper tsclient.pl plugin, Jump List parser (system A), Logparser (system B)

Mapping Shares
While the interaction with shares is somewhat limited, it can still be seen as a form of "lateral movement".  Shares mapped via the Map Network Drive wizard appear within the user's Registry hive, in the Map Network Drive MRU key, on system A.

On system B, the connection would appear as a login, accessing resources in the Event Log.

As Event Logs tend to rotate, the artifacts on system A may persist for much longer than those on system B.


Tools: RegRipper mndmru.pl plugin (system A); Logparser (system B)

Shellbags
It's funny that when I sit down to outline some of these HowTo blog posts, I start by typing in subheaders )like this one, which I then italicize) for topics to include in the overall subject of the post.  It's interesting that the shellbags artifacts tend to appear in so many of these posts!  Similar to mapping shares, these artifacts can provide indications of access to other systems.  There are specific top-level shell items that indicate network-based resources, and will illustrate (on system A) a user accessing those remote resources.

Tools: RegRipper shellbags.pl plugin (system A)

Scheduled Tasks
Scheduled Tasks can easily be created through the use of one of two CLI tools on systems:  schtasks.exe and at.exe.  Both tools utilize switches for creating scheduled tasks on remote systems.  On system A, you may find indications of the use of these CLI applications in the Prefetch files or other artifacts of program execution.  On system B, you may find indications of a service being started in the System Event Log (event ID 7035/7036), and on WinXP and 2003 systems, you may find indications of the task being run in the SchedLgU.txt file (although this file, like the Event Logs, tends to roll-over...).  On Windows 2008 R2, you should look to the Microsoft-Windows-TaskScheduler/Operational Event Log...event ID 102 indicates a completed task, and event ID 129 indicates that a task process was created.

PSExec
PSExec and other similar services (I've seen rcmd and xcmd used) can be used to execute processes on remote services.  The artifacts you would look for would be similar to those for Scheduled Tasks, with the exception of the specific event records on system B.

Artifacts on system A might include Prefetch files and other artifacts of program execution.

Artifacts on system B might include System Event Log entries, specifically those with event source Service Control Manager and event IDs of 7035 (service sent a start command) and 7036 (service entered a running state).

Tools: LogParser, TZWorks evtwalk or evtx_view (system B)

Testing, and Artifacts
In order to see for yourself what these artifacts "look like", try running these tools on your own.  You can do so fairly easily by setting up a virtual system and using any of these methods to access the "remote" system.