How to Prevent the Worst Monday Imaginable

For most people, Friday is the start of their weekend. At Tetra Defense, formerly Gillware Digital Forensics, it’s actually the start of our work week. Why? Because it’s the start of the work week for the people who are attempting to intrude on and attack your systems.

At Tetra, nearly every data breach investigation and response case has the first malicious action conducted on a Friday evening after everyone has started their weekend. If you’ve been unlucky enough to have to deal with a system that fell victim to a ransomware attack, you probably discovered the encrypted data first thing Monday morning.

Talk about a case of the Mondays.

How to Stop Data Breaches… Before They Happen

In most data breaches and intrusion events, you can find indicators of compromise before any malicious actions, such as data theft, malware deployment, internal password phishing attempts, etc., have even taken place—if you just know where to look.

Office365 login audits:

If you use Office365, as many offices do, and have admin audit logging enabled, you can check the logs for any sign of account compromise. It’s a near-certainty that hacker will test the login credentials they’ve gleaned days or even weeks in advance before they take any real malicious actions if one of your users has fallen victim to a password phishing scam.

If you view the logs before the malicious action took place and find suspicious activities such as:

  • Setting up malicious email forwarding rules
  • Sending phishing emails to co-workers and clients
  • OneDrive and SharePoint data compromises

Then you’ve discovered evidence of a breach-in-progress.

If you see any of these kinds of malicious access, contact Tetra Defense ASAP. We can help you eliminate the breach and determine if the hackers have done any further malicious actions.

To check for these kinds of malicious probing:

  1. Log into your Office365 Admin account.
  2. Go to the “Security and Compliance” App.
  3. Go to Search and Investigation > Audit log search.
  4. Set the start date as far back as you can, typically 90 days.
  5. Find items that indicate that the Activity indicates “UserLoggedIn” and “UserLoginFailed.”
  6. Most events in Office365 will include the IP address that they were initiated from. These IP addresses can be searched on websites like to find out where this IP is coming from. If you see IP addresses from locations that you would not expect logins to come from, or you see numerous failed logins, this can be an indicator of compromise, or an indicator that you are at risk.

Domain Controller Logs for RDP Access:

Many malicious acts are conducted through the millions of computers that have RDP ports that are accessible from outside the network without VPN or other security measures. Many RDP usernames and passwords are for sale on the dark web. If your users remotely access their workstations through any port via RDP, even if it’s not the default port, your systems are likely at risk. Fortunately, you can view Windows Security Event logs to determine if any accounts have been compromised. If you use RDP without a domain controller, you will need to view the security logs on each workstation.

How to View Event Logs Related to RDP Logins on the Domain Controller:

  1. Edit query manually box in the Windows Event Viewer

    Edit query manually box in the Windows Event Viewer

    Open Windows Event Viewer

  2. In the left column, go to Windows Logs and Click on “Security” to view the security log.
  3. In the right pane, click “Filter Current Log…”
  4. Click on the XML tab in this same window, here is where we can filter to only remote desktop logins.
  5. Click on the “Edit query manually” box and click “Yes” if prompted that you will no longer be able to change the filter with the GUI.
  6. In the XML text box, replace the text with the following query, which will show us successful and failed RDP logins:


Now you should be able to see RDP failed and successful logins like the one below (assuming that you use RDP):

RDP logon event log

RDP logon event log

In the image above depicting the successful login, the most important piece of information is the Source Network Address. The Source Network Address is the IP address that the login comes from. If you don’t allow RDP access from outside your local network, then these will all be local IP addresses. However, if you used RDP from outside the network without requiring VPN, these logins will be global IP addresses.

Two Suspicious Events to Look For In Your Domain Controller:

  1. Repeating Event ID 4625s: This event denotes a failed login attempt. In many ransomware cases, we see a pattern of these events that could indicate a brute-force password cracking attempt. These are especially concerning if the IpAddress field is blank or a “-”.
  2. Windows Event ID 4624: This event denotes a successful login attempt. In the Windows security logs, Event ID 4624 has a logon type showing how the user is connected, with a logon type of 10 indicating RDP access. The RDP access will have an IP address field in it which indicates where the user is accessing the computer from. Similarly to the Office365 logs, can be used to identify the location of the IP address. If you see any malicious 4624 events from locations such as foreign countries that you do not have users in, this is an indicator of compromise, and a breach is currently occurring.

Take Suspicious Events Seriously

In most of our breach investigations, the victim identifies suspicious activity after the fact. For example, after we tell the IT staff that a specific user was “Patient Zero” of the breach, they go back into their ticketing system and find that before the breach occurred the user reported abnormal operation of their computer, such as:

  • Suspicious emails clicked by the user
  • Suspicious popups asking for credentials
  • The computer’s language switching to Russian or other foreign languages
  • The computer logging off randomly
  • The computer running slowly and high processing activity occurring
  • Etc.

It’s hard to stay on top of all the issues reported to your IT staff every day. However, some of these reported issues can be indicators of compromise and need to be addressed posthaste to prevent further damage.

Make Sure You Have a Cloud Backup

Most of the data loss incurred due to ransomware can be avoided by having an offsite cloud backup that is not easily accessible from any of the computers/servers on your network that could fall victim to ransomware. Too often we see an organization’s backups stored on a NAS device attached to the compromised computer or server in question. If you’ve stored your backups on a NAS that is currently mapped to a computer or server, and that computer or server get ransomed, your backups will get deleted or encrypted as well.

Ransomware has always evolved to make infections more difficult to recover from without paying the hackers. Modern ransomware even runs software that will clear the free space on the devices it infects, which makes recovery of the deleted backups impossible in these situations.

Keep Us In Mind

Even the most vigilant people can’t catch 100% of the threats that come their way. You should always do the best you can to protect yourself, but for anything that sneaks through, you can always count on us here at Tetra Defense to help you make things right again.

Check out some related content on our blog: