As i’m sure i’ve mentioned before, event logs are a great source of evidence when performing incident response. In particular, lateral movement can be one of the hardest things to identify when investigating network based intrusions.
Event ID 1024 in log file Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx is an event that can sometimes be overlooked and it relates specifically to ActiveX controls in remote desktop.
In built ActiveX controls allow an administrator to configure the RDP user experience by providing scriptable interfaces and can allow embedding RDP ActiveX control in web pages and configuring URL security zones, as a couple of examples.
Event ID 1024 which contains the following message:
“RDP ClientActiveX is trying to connect to the server (IP.ADDRESS OR HOSTNAME)”
Whether IP or hostname display here, will depend on what is entered in “Computer” files in the GUI for remote desktop.
This event ID appears (in testing) to be generated when a user initiates an RDP connection using the RDP client MSTSC.exe in Windows by pressing ‘connect’.
The great thing is, event 1024 entries will be created whether a session is connects or not.
This means while an attacker may not have successfully connected via RDP to another computer, we may still see evidence of their attempts. This log may also persist longer than other logs too, where a Security log may only cover a days worth of activity, you may find months worth of evidence in this log.
When paired with 4648 Security events and other remote computer RDP logs, this can show both attempted or successful connection and authentication to a remote (target) computer.
One of the interesting things about brute-forcing accounts and passwords effectively is that it requires either some prerequisite knowledge of the target, accounts, passwords or at very least some high level information about how and where they operate. Most account names in spraying attacks tend to be the day-to-day combinations of administrator, manager, reception, finance and so on. We do however, sometimes see account name usage which appears to be more specific. This occurs when an attacker has somehow captured or identified previously exposed credentials.
4625 Security events are a great place to see account and password spraying attacks against poorly configured RDP services. Unfortunately, the systems where we see these kind of attacks occurring are usually poorly configured. This means that logging generally doesn’t tend to surpass the Windows default retention period and the only place we may be able to look for further logs is in backups, if they exist.
However, if we have identified brute-force activity and we have access to logs going back far enough, we might be able to pull some extremely useful information from them.
When it comes to attribution, we can spend a lot of time looking for evidence of known domain or local accounts being compromised and used by the attackers. By focussing solely on these elements we may sometimes overlook the obvious.
One thing I like to do during initial log review is to spend some time scrolling and looking for any strangeness, patterns or commonalities in the data. As I mentioned before, the majority of account names that feature in RDP brute-force attacks tend to err toward standard expected account names, sometimes combined with a mixture of account names in other languages like Spanish, French or German.
What sort of account names have we seen used which may provide further information about the attacker?
Use of specific external domain names owned by the company (firstname.lastname@example.org)
Use of mail account names for users in the company (email@example.com)
Use of named users in an environment (donald.trump)
Use of external domain names or mail addresses in the same country owned by external companies (firstname.lastname@example.org)
Use of external domain names or mail addresses in other countries owned by external companies (email@example.com)
What does all this mean?
We should always try to remove ourselves from the specifics of an investigation and try to take a wholistic view. This might give ussome useful insight to the attackers overall knowledge of the company, general capabilities and overall sophistication of the attacker based on their word lists. Lastly, you may also identify a potential compromise of a third party system through your review, which can lead to some interesting legal discussions.
If you’ve been working in Digital Forensics or Incident Response in Australia then you should be aware of the new legislation relating to notifiable data breaches by the Office of the Australian Information Commissioner (OAIC).
In amongst the OAIC’s website, there is some very useful information for incident responders as well as companies who are unsure as to whether they need to disclose when they’ve have had a data breach. You may already work for a mature organisation that has had appropriate legal and technical council in relation to this but if it’s all new to you then I suggest now is a very good time to start reading.
The OAIC outlines a data breach as so:
A data breach occurs when personal information that an entity holds is subject to unauthorised access or disclosure, or is lost.
Personal information is information about an identified individual, or an individual who is reasonably identifiable. Entities should be aware that information that is not about an individual on its own can become personal information when it is combined with other information, if this combination results in an individual becoming ‘reasonably identifiable’ as a result.
A data breach may be caused by malicious action (by an external or insider party), human error, or a failure in information handling or security systems.
Examples of data breaches include:
loss or theft of physical devices (such as laptops and storage devices) or paper records that contain personal information
unauthorised access to personal information by an employee
inadvertent disclosure of personal information due to ‘human error’, for example an email sent to the wrong person
disclosure of an individual’s personal information to a scammer, as a result of inadequate identity verification procedures.
The OAIC has recently released quarterly statistics and there are some interesting points which have come out of this.
1: The highest number of individuals affected were 1,000 or fewer across 107 different breaches.
2: It would seem that healthcare organisations are still top of the list for all sorts of targetted attacks in Australia. This comes as no surprise and a statistic that is common in most developed countries.
Investment in security and infrastructure are clearly still lacking in this area since the WannaCry outbreak hit so many systems worldwide.
3: The number of breaches being reported has gradually increased since the start of 2018. Presumably, this will continue to increase.
4: The largest amount of data loss relates to contact information such as names, addresses, email addresses. This is closely followed by financial details. This reflects the businesses which are predominantly targeted (health and finance).
This is also a clear indicator that the low hanging fruit is going to be the most leveraged by attackers. It should come as no surprise that we should expect to see just as many, if not a marked increase in targetted phishing campaigns.
5: Human error still accounts for 36% of data breaches, this indicates there is still a major gap in staff awareness across all industries. Interestingly, the most accidental disclosures happened by PI being sent to the wrong email address but the largest amount of affected individuals was due to loss of paperwork or storage device.
6: 59% of breaches were due to malicious or criminal attacks. Again, this clearly shows there needs to be further investment in education and security.
The highest of these types of malicious or criminal breaches were classed as Cyber Incidents and the breakdown of this can be seen as such: