Eye Security's ongoing hunt for cyber threats provides valuable insights into critical vulnerabilities and potential risks. Our blog series showcases specific hunts, including identifying unnecessary RDP access, monitoring Bitlocker usage for ransomware attacks, and exploring the impact of malicious advertisements. By sharing our proactive approach and leveraging advanced technology, we aim to enhance organizations' security posture. Stay tuned for more updates and valuable insights from Eye Security.
Context
Within Eye Security, we are always hunting and researching (emerging) threats for our customers. While most of the hunting is done to identify systems containing critical vulnerabilities (with a high likelyhood of exploitation), we are increasingly looking for new angles during our hunts. These hunt topics are selected by our Threat Intelligence team and will always have the following factors in mind:
-
Getting Insights
-
Analyse Behavior
-
Reducing Risk
We plan to release technical blogs like this on a regular basis in which we hope to shine light on our hunting and research activities. To show what we do, what we look for, and why it is relevant. Additionally, we will try to shine some light on our thought process and considerations.
For now, our hunting examples involving hosts will mostly be based on Crowdstrike Falcon XDR and Microsoft KQL for results related to the external searches which we store in Azure. We are not the first to release a hunting series, for Crowdstrike there is an excellent resource called CoolQueryFriday (r/crowdstrike) and for Microsoft, there are very good resources such as FalconForce (Blogs - FalconForce)
Additionally, our research will focus on risks for the Small and Medium Enterprise (SME) sector, but could definitely be translated to enterprise-level companies.
Lastly, the results from these hunts will directly be communicated to our customers when we actually performed these hunts. This series will serve as behind-the-scenes of what we do in addition to our MDR solution for SMEs in Europe.
Hunts
#1) Possible unnecessary RDP:
The first hunt is inspired by a previously published CQF (2021-03-12 - Cool Query Friday - Parsing and Hunting Failed User Logons in Windows). We want to see if there are endpoints at our customers, which have RDP access but have no successful sign-ins. With this information, two questions can be asked:
-
Is RDP required on this device?
-
Do we recognize the RDP access?
With this query, we try to map the number of successful sign-ins, in percentages, against the failed sign-ins. This query gives us an idea about if the device is approachable from the Internet (probably being brute-forced every now and then) and if all the sign-ins could be recognized/matched with known sign-ins.
earliest=-7d event_simpleName=UserLog* LogonType_decimal=10 NOT RemoteAddressIP4=0.0.0.0 NOT UserLogOff
| regex RemoteAddressIP4!="(^127\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$)|(^10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$)|(^172\.1[6-9]{1}[0-9]{0,1}\.[0-9]{1,3}\.[0-9]{1,3}$)|(^172\.2[0-9]{1}[0-9]{0,1}\.[0-9]{1,3}\.[0-9]{1,3}$)|(^172\.3[0-1]{1}[0-9]{0,1}\.[0-9]{1,3}\.[0-9]{1,3}$)|(^192\.168\.[0-9]{1,3}\.[0-9]{1,3}$)"
| fillnull value=NULL UserName
| eval RemoteAddressIP_star = coalesce(RemoteAddressIP4, RemoteAddressIP6, NULL)
| eval UsernameSuccess=case(event_simpleName == "UserLogon", UserName)
| eval UsernameFailed=case(event_simpleName == "UserLogonFailed2", UserName)
| stats values(UsernameSuccess) as Username_Success values(UsernameFailed) as Username_Failed dc(UsernameSuccess) AS "User_Count_Success" count(UsernameSuccess) AS "Logon_Count_Success" dc(UsernameFailed) AS "User_Count_Failed" count(UsernameFailed) AS "Failed_Count" values(RemoteAddressIP_star) as ips by aid, ComputerName, company
| eval percentageFailed=round((Failed_Count/(Logon_Count_Success+Failed_Count))*100,1)
| table aid, ComputerName, company, Username_Success, Username_Failed, User_Count_Success, Logon_Count_Success, User_Count_Failed, Failed_Count, percentageFailed, ips
| sort - percentageFailed, company
Analyst comments:
This query required multiple iterations and still can be improved upon. It was hard (at first) to make a distinction between ‘good’ and ‘bad’ in absolute numbers for certain cases, so we added a percentageFailed variable. We found a 100% percentage failed endpoint at multiple of our customers, suggesting a possible unnecessary risk. It mostly came down to that they accepted the risk, but some will consider adding additional security such as an end-to-end tunnel.
This query will probably be revised in a later stage where it will also try to identify ‘new’ successful sign-ins or changed IPs per user. It can also be upgraded to include all the timestamps of the sign-ins, applying possible 'office hours' logic to the query as well.
Lastly, the above presented query gives too much information (depending on your needs). Internally we changed it a little bit so it gives an overview of possible interesting machines and used above statet query in a later stage to find the actual irregularities.
#2) Bitlocker:
At our customers, we increasingly see the usage of Bitlocker in their environments, which is a good thing! However, during recent research and Incident Response cases, we noticed a company being ‘ransomwared’ using ‘native’ Bitlocker if the original ransomware payload was being killed. Searching for traces that enable Bitlocker in high volumes on multiple devices, can be indicative of a possible ransomware attack.
(CommandLine=*manage-bde.exe* AND CommandLine=*-on*) OR CommandLine=*Enable-Bitlocker*
| stats dc(ComputerName) AS DistinctMachines BY company
| where DistinctMachines >= 15
Analyst comments:
This query does nothing special, it simply looks for CMD and Powershell occurrences of the standard Bitlocker executables and snippets. The main problem with this query is that it basically needs to run every few minutes, as enabling Bitlocker can be very fast. Additionally, BitLocker makes a difference between drives where the OS is installed and other drives. This query is a generalization that does not take protectors or storage information into account. Lastly, compared to our previous example, we used an absolute value (15) for DistinctMachines , as calculating the amount of unique machines per company is taking too long. If the query performs too poorly (generating too many False-Positives), we will generate a lookup table for this to increase the speed.
If you encounter this type of ‘ransomware’ usage of Bitlocker and you have certain policies in place, always try to find if the recovery keys somewhere in your (A)AD environment. It is possible these keys are backed-up by accident by the threat actor.
#3) Malvertising for Adblockers:
Not a query directly related to our own technology stack, but more of a thought spin. We noticed an uptick in malicious advertisements, which was reported about on e.g. Twitter. These malicious advertisements are bought by threat actors to appear high in the Google search results, but link to an attacker-controlled domain instead of the official domain. An example can be seen below:
Additionally, we had incident response cases where the group was also known to apply this technique of buying malicious ads an thus getting the initial access into the network.
We noticed that one of the suggested ‘fixes’ was the usage of an ‘Adblocker’. While this is a valid fix, what will most people do when looking for this solution? Exactly, they will use Google to search for an Adblocker and thus gets might get presented with advertisements about Adblockers. We were interested if this ‘attack vector’ was already being utilized in the wild (region Europe).
We first tried to replicate the reported findings shared on Twitter(such as can be seen in the picture above), to see if we also would get malicious ads ourselves. This seldom appeared to be the case, we found one malicious ad, which was unreproducible within the next hour. However, when we used a VPN via the USA, we encountered multiple which are included in this list (Link).
We did not have much ‘success’ in this hunt in the Europe region. We quickly came to the conclusion that these tactics were not employed (yet) to try to infect people by using malicious ads for Adblockers. Let's hope we do not inspire them if they might read this.
For our customers, we are always hunting and looking for threats which are harder to detect, which are not recognized as malicious or are not abused (yet). By proactively hunting and notifying, we improve the security posture of organizations in Europe, by using the best technology and the best people. See you next time!
