WFH Lateral Movement TTPs
With the increase of remote working arrangements due to the ongoing pandemic, corporate endpoints are now located far beyond the standard corporate perimeter.
This presents attackers with new attack paths that may not have been present behind well-secured corporate firewalls.
With this in mind, the aim of this post is to outline one possible attack scenario given this new shifting perimeter and to provide some defense guidance around these Tactics, Tools, and Procedures (TTPs).
Let’s start by laying the groundwork for our fictional attack path.
Traditionally, corporate endpoints sat behind a managed and maintained corporate firewalls.
These corporate endpoints are now often located on home networks which may not be as secure as the traditional corporate perimeter. Importantly, home networks also contain less-trusted and unmonitored devices.
In our scenario, we have a network with both a corporate endpoint which we will call Win10-1, and a student machine, which we will call Win10-2.
An attacker is targeting the corporate endpoint and through Open Source Intelligence (OSINT), our adversary determines that a “soft” target is present on a target network.
A laptop used by a student will often have fewer controls than a corporate endpoint and therefore makes an attractive target for attackers.
Students also do not have the same corporate training on how to identify phishing lures, so it is not a huge stretch to assume that, under certain circumstances, students might be more susceptible to such phishing attacks.
In addition, unlike a monitored corporate network, the corporate SOC or Blue Team does not have the same levels of visibility into home networks.
With these aspects in mind, let’s take a closer look at our attack path TTPs.
Building the Attack Path
|Action / Technique
|MITRE ATT&CK Map
|Attacker lands on student machine via phish
|Attacker identifies corporate endpoint on the network
|Attacker brute forces corporate endpoint from internal LAN
|Attacker uses stolen credentials to move to corporate endpoint
|Attacker starts a keylogger on corporate endpoint
|Attacker uses credentials to access corporate SharePoint
Now that we have our attack TTPs mapped out to MITRE, we can proceed with our fictional attack.
Performing the Attack
Through phishing, our attacker lands on a laptop used by a student in a household.
This student laptop (Win10-2) is located on the same local network (LAN) as the attackers end-goal: the corporate asset (Win10-1).
The attacker executes some basic enumeration commands on the student laptop in order to locate and target the corporate asset:
Our attacker now has an IP address to target and proceeds to brute force the corporate asset in hopes of finding a weak administrative credential.
It is important to note here that this attack is occurring on the local LAN using the local account of the corporate asset which may skirt around brute force alarms that look for domain-level authentications only.
We can see from the above that the attacker has now found a valid credential for a local account used by the Service Desk.
Normally an attacker would not be able to directly brute force via SMB due to corporate firewall restrictions, but since the attacker is already on the internal LAN with a line of sight to our victim host, this attack can be performed.
Now that the attacker has valid credentials for the corporate workstation, they can use the foothold they have on our victim student machine and move laterally to our corporate endpoint.
Our attacker now has access to the corporate endpoint – the ultimate target – and proceeds to use the
migrate command to inject into the Chrome process so that they can monitor any keystrokes being entered into this web browser with the hopes of catching credentials being entered to internal company portals or various cloud services.
The attacker can now wait until our victim enters their corporate credentials into Chrome. Once the attacker views the keystroke buffer, the credentials are revealed in plain text.
Now that the attacker has valid credentials, they can access the corporate SharePoint site and examine the contents within it:
This attack path is interesting as it does not rely on any domain-level credentials which are monitored via SIEM and potentially User Behavior Analytics products.
Since the corporate endpoint was on the same LAN as the softer target (the student laptop) the attacker cleverly decided to take the path of least resistance and attack the corporate endpoint via the student laptop, rather than attacking the corporate laptop directly.
Now that we have examined the somewhat unorthodox attack path, let’s look at some of the defenses that can be put in place in order to catch and alert on this malicious activity.
We can look at the failed authentication attempts via the 4625 Windows Event ID which logs failed logins With the following Splunk query:
| stats count by TargetUserName
This query shows us how many times a failed authentication occurred, sorted by the account name.
Looking at the image above, we can see that the ServiceDeskUser account failed to authenticate to our corporate endpoint ten times.
If we then broaden our query a little bit with the following:
| stats count by TargetUserName,WorkstationName,Target_Domain
We get the following results:
What is interesting here is that the Target_Domain field is the name of our victim host and not the corporate domain, this indicates that this particular brute force attack took place using a local rather than the domain account.
It is important to note that these particular 4625 events are found on the endpoint on which the authentication occurred and not on a domain controller or other central authentication server.
At this point, we know that the local account was used in a brute force attempt so let’s keep digging for some more attacker activity.
When the attacker used Metasploit to gain a foothold on the corporate asset, the
psexec_psh module was used. This module starts a service on the victim endpoint with a randomly generated name, we can see this activity by looking at the 7045 Event Code with the following Splunk query:
| table AccountName,ServiceName,ImagePath
Which produces the following results:
A few things stick out in the above image. We can see the randomly generated service name, which does not match the typical pattern of Windows service names.
We can also see the ImagePath field is filled with long encoded PowerShell strings – a sure sign of trouble.
Since we now know that PowerShell is involved in our attack chain, we can use Sysmon logs to see what network connections the PowerShell process made. I am including the ProcessGuid field in my query so that it can be used as a pivot.
We execute our query:
index=sysmon EventCode = 3 Image=*powershell*
| table SourceIp,DestinationIp,DestinationPort,Image,ProcessGuid
And look at the results:
We can now see the source IP address of our attacker machine and the default Metasploit port of 4444. If we use the ProcessGuid as a pivot with the following query:
| stats values(RuleName)
We can also see what else our PowerShell process was up to:
These RuleName values come from the Sysmon Config we are using: https://github.com/olafhartong/sysmon-modular which maps various Sysmon config rules to a corresponding MITRE ATT&CK IDs.
One of my favorite things about Sysmon is that you are able to create your own rules for various techniques.
We can add a rule to show us when something suspicious injects into the Chrome process, as that is a necessary step in the attack chain prior to keylogging from that process.
Let us update our Sysmon config with the following logic under the ProcessAccess RuleGroup:
Here I am telling Sysmon to log an event when the TargetImage is
C:\Program Files\Google\Chrome\Application\chrome.exe and the CallTrace contains
UNKNOWN as this typically means that some kind of injection occurred in memory.
The corresponding event is revealing:
We can see the PowerShell process injecting into Chrome with various “UNKNOWN” values in the CallTrace field.
Standing alone, this event may not clue you into nefarious activity, however, if we combine this with the other events discussed above, we start to get a more clear picture of what our attacker did.
In addition to host-based logging, it is also important to look at SharePoint logs to detect our attacker activity.
After sending our Office 365 Logs to Splunk via the Office 365 API, we can use the following query:
index=o365 Workload=SharePoint Operation=FileAccessed
| table ClientIP,ObjectId,SiteUrl,UserId,UserAgent
To examine what activities took place on our SharePoint site:
This type of visibility is critical, as we can now compare the IP addresses and UserAgents as well as time of access to “normal” access in order to separate authorized versus unauthorized access.
The aim of this post was to highlight a somewhat atypical attack path and to provide some defensive guidance around such attacks.
Some key takeaway points:
- The traditional corporate perimeter for your organization may have shifted and it may be necessary to adjust detection and response programs, threat models, and risk calculations accordingly
- The presence of “softer” targets on the same LAN as hardened corporate endpoints may present attackers with previously unavailable attack paths
- Collecting logs from endpoints is critical as more endpoints are disconnected from their corporate networks
- Additional reliance on cloud services necessitates visibility into these areas
This new perimeter is something Lares COO Andrew Hay has coined the “Forcibly Converged Network“. Please join us on Wednesday, October 14th, 2020 at 12pm ET for a roundtable discussion on the technical and management challenges of securing and monitoring this new work-from-home converged network architecture.
Sign up for the free webinar here and join the conversation: https://attendee.gotowebinar.com/register/775648688884026384
Anton is a BSides Toronto speaker, C3X volunteer, and an OSCE, OSCP, CISSP, CSSP certificate holder. Anton enjoys the defensive aspects of cybersecurity and loves logs and queries.