Common Malicious Activity Indicators : Have You Been Hacked?

Common Malicious Activity Indicators: How to Tell If You’ve Been Hacked

If you are seeing strange logins, odd browser behavior, or devices that suddenly feel “off,” don’t ignore it. The question behind the search a security administrator wants to set up anomalistic monitoring around behavioral-based user activity. which of the following could the administrator implement for monitoring? (select three.) is really about one thing: how to spot compromise early enough to stop damage.

Malicious activity indicators are the warning signs that something is wrong. Some are obvious, like ransomware notes or locked accounts. Others are subtle, like impossible travel logins, a new mailbox rule, or a service account authenticating at 2 a.m. from a new region.

This article explains what those indicators mean, why attackers leave them behind, how to investigate them, and what to do next. The goal is practical: help you separate harmless noise from real attack signals, then respond fast when patterns start to line up.

One strange event may be a glitch. Repeated strange events across identity, endpoint, network, and logs usually mean compromise.

For a reference point on modern threats and incident response concepts, the NIST Cybersecurity Framework and MITRE ATT&CK are the right starting points. Both help you think in terms of behaviors, not just alerts.

What Malicious Activity Indicators Really Are

Indicators of compromise are artifacts or behaviors that suggest a system, account, or network has already been breached. That can include a malicious file hash, a suspicious registry key, a new admin group membership, or a login from an impossible location.

Not every anomaly is a breach. A software update can create a spike in CPU usage, and a traveling employee can trigger location-based login alerts. The difference is pattern and context. A single outlier may be harmless, but repeated suspicious behavior across systems is harder to dismiss.

Where indicators show up

Attack indicators can surface almost anywhere:

• Endpoints: malware, hidden processes, disabled defenses, persistence tasks.
• Networks: beaconing, unusual ports, rare destinations, exfiltration bursts.
• Applications: mailbox rule changes, strange API activity, failed transactions.
• Identity systems: account takeover, MFA abuse, password resets, privilege changes.
• Logs: authentication failures, remote execution, new services, script activity.

That is why behavioral monitoring matters. A security administrator wants to set up anomalistic monitoring around behavioral-based user activity. which of the following could the administrator implement for monitoring? (select three.) The best answer set in practice usually includes account login activity, security event review, and identity or endpoint telemetry that can reveal abnormal behavior patterns.

For identity and behavioral analytics concepts, Microsoft’s official documentation on sign-in risk and auditing is useful: Microsoft Learn. For endpoint and network detection, vendor documentation and ATT&CK mappings are often the most actionable sources.

Why Attackers Leave Clues Behind

Attackers are not invisible just because they want to be. Their goals usually create traces. If they want data theft, they access files and move data. If they want persistence, they create services, scheduled tasks, or backdoor accounts. If they want disruption, they generate noise very quickly.

Common attacker behavior includes scanning, credential abuse, privilege escalation, and lateral movement. Each of these tends to produce logs. Scanning can trigger firewall alerts. Credential abuse can create failed logins and lockouts. Lateral movement often shows up as remote service creation, SMB activity, or unusual admin sessions.

Attack behavior that usually creates evidence

• Command-and-control traffic: periodic outbound connections to rare hosts.
• Unauthorized access: logins from unfamiliar devices or locations.
• Malware execution: new processes, suspicious child processes, and script launches.
• Privilege escalation: account group changes and token abuse.
• Data exfiltration: large archive creation, cloud uploads, or unusual outbound volume.

Stealth is difficult in real environments because monitoring is layered. Identity logs, endpoint detection and response tools, firewall logs, DNS logs, and SIEM correlation all create overlapping evidence. That is why one weak signal becomes much stronger when you combine it with others.

Attackers can hide from a single log source. Hiding from identity, endpoint, DNS, and proxy telemetry at the same time is much harder.

MITRE ATT&CK is useful here because it maps the tactics and techniques attackers use to observable behavior. Use it to connect suspicious activity to likely next steps, not just to label the event.

Unusual Account and Login Activity

Account takeover usually starts with login anomalies. Watch for repeated failed logins, especially from unfamiliar locations, unusual countries, or odd hours. One failed login may be a typo. Ten in a row from different IPs is a pattern.

Impossible travel is one of the clearest identity indicators. If the same user account logs in from New York and then five minutes later from Singapore, something is wrong. The same applies to new device logins, risky sign-ins, or sessions that start with familiar credentials but unfamiliar hardware or browser fingerprints.

High-value signals to check

• Account login activity from strange IP addresses.
• Repeated lockouts or password reset attempts.
• Changes to MFA settings or recovery methods.
• Mailbox forwarding rules or delegated access changes.
• Privilege changes for admins, executives, or service accounts.

Credential stuffing and brute force attacks often show up as broad, low-and-slow authentication failures across many accounts. Stolen password use is different. It may look clean at first, with successful login and normal browsing, until the attacker adds forwarding rules, downloads sensitive files, or pivots into cloud apps.

For identity and access monitoring controls, review Microsoft Learn for audit logging guidance and CISA for practical defensive recommendations. For a broader workforce and role-based security baseline, the NICE Framework is a strong reference.

Suspicious Device and Endpoint Behavior

Endpoints often show compromise before users understand anything is wrong. A laptop that suddenly slows down, crashes repeatedly, or runs hot may be doing more than “just acting up.” Malware, encryption activity, and post-exploitation tools can all cause abnormal resource use.

Look for unknown processes, unfamiliar startup items, hidden scheduled tasks, and services you did not deploy. Attackers commonly use persistence methods to survive a reboot. They also try to disable antivirus tools, block updates, or tamper with security agents so their activity stays hidden.

Endpoint red flags that deserve attention

• High CPU or disk usage with no clear business cause.
• Security tools disabled, stopped, or excluded unexpectedly.
• New autoruns, startup entries, or scheduled tasks.
• Files renamed in bulk or encrypted and no longer readable.
• Ransom notes or missing documents in shared folders.

These symptoms often show up during persistence or post-exploitation activity. For example, a compromised host may run a PowerShell script at login to pull payloads from a remote server. A user will only notice that the machine “feels slow,” while EDR sees suspicious script execution and a new registry run key.

The best response is to inspect the process tree, check recent security events, review autoruns, and compare the endpoint against known-good baselines. If you need a framework for endpoint hardening, the CIS Controls are practical and widely used.

Network Anomalies That Suggest Intrusion

Normal network behavior is predictable. Users access the same business apps, data centers talk to known services, and traffic tends to follow a daily rhythm. That is why baselining matters. Without a baseline, you cannot tell whether a spike is normal backup traffic or data theft.

Suspicious network signs include strange outbound connections, rare geographic destinations, unusual ports, and traffic at odd hours. A workstation making encrypted connections to a server in a region the business never uses is worth investigating. So is a client suddenly sending large volumes of data late at night.

Common network indicators

• Beaconing to the same host at regular intervals.
• Outbound traffic to unknown domains or newly registered infrastructure.
• DNS requests with odd subdomain patterns.
• Large transfers, repeated uploads, or compressed archives leaving the network.
• Connections on unusual ports that do not match the application.

Command-and-control traffic often looks boring on purpose. It may be low volume, encrypted, and timed at a fixed cadence. That does not make it safe. A short burst every 60 seconds from one workstation to one host is exactly the kind of pattern a SIEM should flag.

Network logs are most useful when they are correlated with identity and endpoint data. A connection alone is a clue. A connection plus a suspicious login plus a new process is a case.

For DNS and network monitoring concepts, the IETF standards ecosystem and MITRE ATT&CK help explain what normal and malicious traffic patterns look like in practice.

Changes to Files, Folders, and Permissions

File system changes are some of the easiest indicators to miss because they often blend into normal work. But unauthorized file creation, deletion, renaming, or modification can point to staging activity, tampering, or ransomware.

Permission changes matter just as much. If users suddenly lose access, if a service account gains broad rights, or if a shared folder ACL changes without a change ticket, treat it as a security event. Attackers often alter permissions to hide evidence or gain control over sensitive locations.

What to look for

• Hidden files in shared or high-value directories.
• Unexpected scripts in temp or startup folders.
• Changed extensions on a large number of documents.
• Mass encryption or files renamed with random strings.
• Backup files deleted, overwritten, or inaccessible.

Ransomware often targets backups and common collaboration locations first because that is where disruption hurts most. A user may notice documents that no longer open, while administrators see hundreds of file modifications within minutes.

For file integrity and secure configuration guidance, review NIST publications and the CIS Benchmarks. These help define what should not change without authorization.

Email, Browser, and Web Activity Red Flags

Email compromise is one of the fastest ways attackers move inside a business. Watch for strange sent messages, especially if the user does not remember sending them. Phishing often leads to mailbox rule changes, forwarding rules, or deleted messages that hide the initial compromise.

Browser behavior can also expose malicious activity. Look for new extensions, homepage changes, redirects, fake login pages, repeated crashes, or suspicious pop-ups. If users keep landing on credential-harvesting pages or download prompts they did not expect, the browser or DNS path may already be compromised.

Email and browser clues to check

• Unexpected sent mail or replies the user denies authoring.
• Mailbox forwarding rules pointing outside the organization.
• Deleted security warnings, phishing emails, or recovery messages.
• Unknown browser extensions or changed search settings.
• Downloads from malicious sites or drive-by prompts.

Web activity logs matter because they can reveal access to malicious domains, malware delivery pages, or OAuth consent abuse. If a user clicks a fake Microsoft sign-in page and enters credentials, the trail often appears in web proxy logs, identity logs, and mailbox changes all at once.

For email and web security controls, official documentation from Microsoft Learn and browser security guidance from vendors are the best technical references. Tie those logs back to user behavior and session history.

Log Entries and Security Alerts to Watch

Centralized logs are where weak signals become actionable. System logs, application logs, firewall logs, identity logs, EDR alerts, and antivirus events should all be reviewed together. The value is not the single alert. The value is correlation.

Recurring authentication failures, account lockouts, privilege changes, remote execution, unusual service creation, script activity, and registry edits often appear before a major incident becomes obvious. A single alert may be noise. A cluster of alerts on the same host, user, and time window is much more serious.

Examples of high-value log signals

• EDR alerts for suspicious process injection or execution chains.
• SIEM correlation of logins, privilege grants, and remote access.
• Antivirus detections followed by the same file reappearing elsewhere.
• Remote service creation or scheduled task creation on a server.
• Registry changes tied to persistence or defense evasion.

Security teams should always ask: did this alert happen alone, or did it happen with other indicators? If a user logs in from a new device, downloads an archive, and then a suspicious service is created on the same endpoint, that is not random noise. That is a sequence worth escalating.

Correlation is what turns security telemetry into evidence.

For log management and incident response structure, reference NIST guidance and your SIEM vendor’s official documentation. If your environment maps security events to risk scores, align that process to your internal incident severity model.

Behavioral and Operational Changes in the Environment

Not every breach starts with an alert. Sometimes it starts with a help desk call. Users complain about strange pop-ups, lost access, slow systems, or settings they never changed. Those are operational symptoms, and they often appear before full-blown incident response is needed.

Watch for unexplained outages, configuration changes, unknown devices on the network, or software that appears without an approved request. When an attacker gains access, they often change settings, create persistence, or disrupt normal operations to hide their actions or push the organization toward panic.

Behavioral clues that deserve review

• New devices appearing in inventory or on the network.
• Help desk tickets reporting repeated login issues or missing files.
• Admin activity that does not match normal change management.
• Unexpected software installs on workstations or servers.
• Configuration drift in security tools, VPNs, or remote access services.

Behavioral baselines help you distinguish normal maintenance from malicious activity. A patching window can explain a spike in reboots. It does not explain new accounts, disabled defenses, or broad access changes. That distinction matters.

For service management and operational controls, the ITIL framework and your organization’s incident procedures help define what “normal change” should look like. Combine that with security monitoring so operational noise does not hide real compromise.

How to Investigate Possible Malicious Activity

Start with triage. Verify the alert, identify the affected systems, and determine how serious it is. Do not assume the first explanation is correct. A failed login, for example, might be a typo, a password spray, or a stolen account in use.

Next, collect evidence. Pull logs from endpoints, network sensors, identity systems, mail systems, and firewalls. Preserve timestamps, hashes, IP addresses, filenames, process details, account names, and any related alert metadata. Those details are what let you reconstruct the sequence later.

Practical investigation steps

1. Confirm the alert and note what triggered it.
2. Identify scope by checking related accounts and systems.
3. Preserve evidence before rebooting or cleaning anything.
4. Review recent security events and correlate them across sources.
5. Look for lateral movement, persistence, and data access patterns.

Scope is critical. One compromised laptop is bad. A compromised host with the same credentials used across file shares, cloud apps, and admin tools is much worse. That is why investigators should look for patterns, not just isolated alerts.

For incident handling structure, use NIST incident response guidance and map activity to MITRE ATT&CK techniques when possible. That makes your findings easier to communicate to other teams.

What to Do If You Suspect You’ve Been Hacked

If you think you have been hacked, act immediately. First contain the problem. Disconnect affected endpoints from the network if you can do so safely. If cloud or email accounts are involved, preserve access logs before making changes.

Then change compromised credentials from a known-clean device. Do not reset passwords from the same machine you think may be infected. Review MFA settings, recovery options, mailbox rules, delegated access, and third-party app permissions. Attackers often abuse those settings to stay in control after a password reset.

Immediate response checklist

• Isolate the device or account.
• Change credentials from a clean system.
• Verify MFA and remove unauthorized methods.
• Scan for malware and remove persistence.
• Check backups before restoring data.

If you are dealing with business systems, involve IT, security, managed detection providers, and legal or compliance teams as needed. Timing matters. A delayed response can turn a single compromised account into a full environment incident.

If the compromise may involve regulated data, do not improvise containment. Follow your incident plan and notification requirements.

People also ask, have i been pwned safe and have i been pwned legit? As a breach-notification lookup service, Have I Been Pwned is widely used and generally trusted for checking whether an email address appears in known breach datasets. It does not prove your account is currently hacked, and it should not replace investigation. If you find exposure, the next question is what to do if you have been pwned: rotate passwords, enable MFA, review account activity, and check for reuse across other services.

Best Practices for Preventing Future Compromises

Prevention is a stack, not a single control. Strong passwords matter, but password hygiene alone will not stop phishing, token theft, or MFA fatigue attacks. Least privilege matters, but only if access reviews are real and regular.

Start with MFA everywhere it is supported. Then reduce standing privileges, patch operating systems and applications quickly, and keep endpoint protection active. Email filtering and secure web controls should catch common delivery paths before users ever interact with them.

Controls that actually reduce risk

• Least privilege for accounts and admin roles.
• Multi-factor authentication on high-value systems.
• Regular patching for endpoints, servers, and network devices.
• Endpoint protection with tamper protection enabled.
• Centralized logging with enough retention to investigate later.

Continuous monitoring is the difference between finding an issue in minutes versus finding it in a post-breach review. Tune alerts so you catch meaningful anomalies instead of drowning in false positives. Security awareness training also matters, especially for phishing, unsafe downloads, and password reuse.

For workforce and control alignment, see the NICE Framework, the CIS Controls, and CISA guidance. These resources help organizations build layered defenses instead of relying on one product or one policy.

Conclusion

Malicious activity indicators are early warning signs, not proof by themselves. A single odd event may be harmless. A pattern across account login activity, endpoint behavior, network traffic, logs, and operational changes is where real compromise becomes visible.

The biggest red flags are usually the simplest: strange logins, new devices, disabled defenses, suspicious outbound traffic, unexpected file changes, and alerts that line up across multiple sources. If those signs appear together, do not wait for a clearer message from the attacker.

Use baselines, review recent security events, and investigate quickly. If you suspect compromise, contain first, preserve evidence, and bring in the right people fast. That approach will do more to limit damage than any single tool.

Next step: review your logs, check recent security events, and confirm whether your monitoring can detect the patterns covered here. If your team is still relying on isolated alerts, it is time to move to correlation-based detection and response.

CompTIA®, Microsoft®, AWS®, ISC2®, ISACA®, and PMI® are trademarks of their respective owners.