By Micah Graf, Security Researcher at CounterTack
Let’s say you’re trying to detect when an end user falls for a malicious email attachment. Now, most organizations have good email filtering solutions (typically signature based) in place, and they may even inspect archived files (so long as they are not password protected) and check attachments for malicious macros. However, let’s assume that some malicious emails are bound to get past these defenses. One way they can do this is to make the body of the email fairly generic, include a malicious link in the attached document, and not use any sort of malicious macro or document exploit. If the attacker can make the email and PDF document look like it came from a legitimate vendor of the organization or within the organization itself, they’ve really struck gold and it will ensure numerous victims.
You might be thinking, this is why we have a web proxy with website reputation scoring (known bad sites get blocked, and good sites are allowed through the proxy). However, what if the site that is included in that PDF document has no reputation (the web proxy has never seen it before, or the proxy has seen it before but they haven’t had a chance for someone to classify the site)? Typically, when this occurs, the user is allowed to visit the site (fail open) because they would rather not hinder the business (in case the site might be a legitimate one).
There will still be evidence in the web proxy logs of the user visiting this site, but so will every other site that the user and all other users in your organization visited. We are now faced with the proverbial needle in a haystack dilemma: how do we know which websites came from links included in a PDF document? The web proxy doesn’t have this data; it only sees the endpoints that request the sites and which sites are requested the sites. An EDR product on the other hand, can make this correlation because it sees what’s happening on the endpoint. If the user clicks a link included in an email or in the attached PDF document, we might see the Microsoft Outlook process or Adobe Reader process spawn a browser child process with the URL included in the command line arguments. However, this could be noisy and might not be the best way to achieve our goal.
Figure 1.1: Adobe Reader process spawning Chrome Browser process with malicious site in command-line
Figure 1.2: CounterTack Relationship Graph showing Adobe Reader launching Chrome Process
Let’s look towards the Windows registry: maybe a registry key is modified when a user clicks a link contained within a PDF document. Sure enough, if we watch for registry modifications (procmonitor can be run locally to detect these changes) we can see Adobe Reader modifies the following registry key “\REGISTRY\USER\S-1-5-21-791577461-4030843794-2252748253-1000\Software\Adobe\Acrobat Reader\DC\TrustManager\cDefaultLaunchURLPerms” with a value of “tHostPerms” and the link can be seen in the data portion of the registry modification (“version:2|http://sales.blackdollz.co.uk:2”, shown below). The reason this key is modified is because the user is being prompted as to whether the request for the site should be allowed or blocked. The user’s selection is then stored in this registry key and is remembered for the next time they click the same link (the next time they won’t be prompted and it will automatically decide based on what is saved in the registry key).
Figure 1.3: User clicks link in PDF document and gets prompted whether to allow or block the site request
Figure 1.4: Regedit view of registry key modified by Adobe Reader when User clicks embedded URL link.
CounterTack can easily be customized and configured to detect this type of anomalous activity and generate a behavior-based detection the next time this occurs on an endpoint in your organization (shown below). CounterTack is highly customizable and strives when it comes to detecting advanced use case scenarios.
Figure 1.5: CounterTack Behavior Detection for cDefaultLaunchURLPerms registry modification