Project overview

Repeated failed login attempts can be a sign of password guessing or another authentication-related threat. In this lab, I built a small Python script that reads synthetic login records from a CSV file, counts failed attempts by source IP address, and prints an alert when an IP reaches a configured threshold.

The goal was not to build a production security product. It was to practice the fundamentals behind a simple defensive detection rule: inspect events, group them by a useful field, count relevant activity, and flag patterns that deserve further investigation.

What I built

• A CSV file containing sample timestamps, usernames, IP addresses, and login statuses.
• A Python detector named login_detector.py.
• A threshold-based rule configured for five failed attempts.
• A command-line result that identifies an IP address with repeated failures.

Tools and environment

• Windows Command Prompt — to run commands and execute the script.
• Python — to read and process the records.
• CSV file — to store synthetic login events.
• Visual Studio Code — to inspect and edit the sample data.

How the detection logic works

1. Load the data. The script opens login_logs.csv and reads the rows.
2. Inspect each event. It checks whether the login status is marked failed.
3. Group by IP address. Failed attempts are counted separately for each source IP.
4. Compare with the threshold. The detector checks whether an IP has reached five failed attempts.
5. Print an alert. An IP meeting the rule is displayed for further investigation.

Results

The successful test run reported an alert for the synthetic IP address 203.0.113.25, with seven failed login attempts. The configured threshold was five. This shows that the detector identified an IP whose failure count exceeded the rule.

Evidence from the lab

1. The screenshots below document the sample data, project files, and successful command-line output. They are evidence of this local test run, not evidence of a real-world attack.
   
   Sample login records in Visual Studio Code.

   

What I learned

• How to run a Python script from Windows Command Prompt.
• How structured CSV data is organized into headers and rows.
• Why correct field names and file encoding matter when parsing logs.
• How to count events by IP address and apply a threshold-based rule.
• Why testing both alert and non-alert scenarios is important.

Limitations and responsible use

This prototype uses synthetic data and a simple fixed threshold. It does not determine whether an IP is malicious, correlate activity across multiple systems, or account for the time between attempts. A real monitoring system would need time-window logic, stronger input validation, careful handling of log formats, and context from other security signals. The sample addresses and usernames are test data; no real accounts or systems were targeted.

Next improvements

• Add a time window so only failures occurring within a defined period are counted.
• Export a clear summary report of all IP addresses and their failure counts.
• Add automated tests for below-threshold, exactly-at-threshold, and above-threshold cases.
• Improve error handling for missing columns, malformed rows, and unreadable files.
• Publish the source code and a README in a GitHub repository.

Conclusion

Threat Atlas Lab 01 was my first hands-on exercise connecting Python with a defensive security task. It helped me move from reading about security monitoring to building and testing a small detection rule myself. The next step is to make the project reproducible with clear documentation, test cases, and a public code repository.

Threat Atlas — Learn openly. Investigate carefully. Build defensively.

1. The incident: What happened, and why it mattered . On or around September 10–11, 2023, MGM detected unauthorized activity affecting certain U.S. systems. The company promptly began an investigation with external cybersecurity experts, notified law enforcement, and shut down systems to contain the threat and protect customer data. The shutdown produced immediate, highly visible effects across properties: digital room keys stopped working, slot machines and ATMs went offline, reservation and booking systems failed, point-of-sale and restaurant systems were disrupted, and the company website and email were affected. Guests and staff resorted to manual processes. Operations at affected properties returned to normal over roughly ten days, with the company stating by late September that hotels and casinos were operating normally. In an October 5, 2023 Form 8-K filing, MGM estimated a negative impact of approximately $100 million to Adjusted Property EBITDAR for its Las Vegas Strip Resorts and Regional Operations collectively, plus less than $10 million in one-time expenses for technology consulting, legal fees, and other advisors. The company indicated it did not expect a material effect on full-year financial condition or results and believed cybersecurity insurance would cover much of the impact. The same filing and related statements confirmed that criminal actors obtained personal information belonging to some customers who had transacted with MGM prior to March 2019. This included name, contact information (phone, email, postal address), gender, date of birth, and driver’s license numbers. A more limited number of Social Security numbers and passport numbers were also obtained. MGM stated it had no evidence the data had been used for identity theft or account fraud, and that customer passwords, bank account numbers, and payment card information were not obtained. Systems and data of The Cosmopolitan of Las Vegas were not accessed. The incident mattered because it demonstrated how a social-engineering success against identity processes can cascade into physical-world operational failure at scale—turning a hospitality company’s digital backbone into a single point of failure for guest experience, revenue, and trust.

   

2. The attack path: What public reporting says about social engineering and identity systems MGM’s public filings confirm unauthorized third-party activity, system shutdowns for containment, data exposure limited to older customer records, and the absence of payment-card or banking data compromise. They do not name the threat actors or detail the precise intrusion method. Contemporary reporting, threat-intelligence analysis, and claims attributed to the attackers fill in a consistent picture. The ALPHV (BlackCat) ransomware group publicly claimed involvement. Multiple outlets, citing sources and analysis, linked the initial access to Scattered Spider (also tracked as UNC3944, 0ktapus, Octo Tempest, and related names), an English-speaking cybercriminal cluster known for social engineering, often operating as an ALPHV affiliate. According to accounts relayed by researchers and the attackers themselves (via platforms such as vx-underground), the entry point was straightforward reconnaissance and vishing:

Attackers identified an MGM employee (reportedly with elevated or useful privileges) via LinkedIn and other public sources. They called the IT help desk, impersonated that employee, and persuaded staff to reset the password and multi-factor authentication (MFA) factors. This granted authenticated access into MGM’s Okta environment—the company’s primary identity and single-sign-on platform.

From there, reporting and attacker statements describe escalation to administrator privileges in Okta and the Microsoft Azure tenant. One technique cited in analyses was the addition of a secondary identity provider (inbound federation / Org2Org-style configuration), a legitimate feature sometimes used during mergers that can enable persistent impersonation of users. Attackers reportedly retained access even after MGM took certain Okta synchronization components offline. The final stage, according to ALPHV claims, involved deploying ransomware against more than 100 VMware ESXi hypervisors. Encrypting the virtualization layer simultaneously disabled large numbers of virtual machines supporting hotel operations, gaming systems, and related services. CISA and the FBI later published a joint advisory (AA23-320A) on Scattered Spider that describes precisely these patterns: targeting of IT help desks via phone or SMS, social-engineering of password and MFA resets, use of legitimate remote-access tools, data theft for extortion, and deployment of ransomware variants including BlackCat/ALPHV, often against virtualization infrastructure. Important caveat: MGM has never publicly confirmed the LinkedIn-to-help-desk sequence, the specific Okta/Azure privilege escalations, or the exact number of encrypted hypervisors. Those details rest on threat-actor claims, journalist sourcing, and industry analysis.

3. The business impact: Disruption to operations and the wider consequences The operational disruption was immediate and public. Slot machines, digital keys, reservations, payments, and other guest-facing systems failed across multiple properties for days. Staff improvised with paper processes. Occupancy and booking activity were affected in September, contributing to the $100 million Adjusted Property EBITDAR impact. Beyond direct revenue loss and remediation costs, the incident carried secondary effects: guest inconvenience and reputational damage in a highly competitive leisure market, notification obligations and free identity-protection offers for affected individuals, regulatory and law-enforcement engagement, and heightened scrutiny of hospitality-sector cyber resilience (especially given the near-simultaneous Caesars Entertainment incident, which also involved social engineering and data theft). The data exposure, while limited to pre-2019 records and excluding payment instruments, still created long-tail risk of phishing, identity fraud, and secondary attacks against individuals.

4. The defensive lessons: Help-desk verification, phishing-resistant MFA, least privilege, monitoring, and incident response The MGM case maps cleanly onto several well-documented control gaps: Help-desk verification. Knowledge-based authentication (employee ID, manager name, date of birth, or other details available from LinkedIn or breach data) is insufficient. Effective processes require out-of-band verification that an impostor cannot easily satisfy: callback to a number already on record in the directory, manager or sponsor attestation through a separate channel, video identity proofing, or multi-party approval for privileged or MFA resets. Treat credential and MFA resets—especially for administrators—as high-risk privileged operations with mandatory logging and review. Phishing-resistant MFA. Standard push notifications, SMS, or TOTP can be bypassed by social engineering of the reset process or MFA fatigue. For administrators, help-desk staff, and high-value accounts, enforce FIDO2/WebAuthn security keys or passkeys. Ensure recovery and re-enrollment of these authenticators themselves require the same high-assurance identity proofing; otherwise the reset becomes the weak link. Least privilege and identity segmentation. Standing super-administrator access in Okta or Azure, combined with broad single-sign-on reach into virtualization and operational systems, turns one compromised identity into enterprise-wide impact. Prefer just-in-time elevation, strict separation of identity-provider administration, and isolation of the hypervisor/management plane. Monitoring and detection. Alert on anomalous identity events: MFA factor changes, new identity-provider federation configurations, unusual admin role assignments, and mass authentication from unexpected locations or devices. Identity threat detection and response (ITDR) capabilities are now essential alongside traditional network and endpoint monitoring. Incident response and resilience. Rapid system isolation limited the scope of data access (notably payment systems). Offline, tested backups of critical systems, break-glass accounts protected by phishing-resistant methods, and practiced recovery procedures for identity-provider compromise reduce the duration and cost of disruption. CISA’s guidance on Scattered Spider emphasizes offline backups, phishing-resistant MFA, and application controls.

5. My analysis: Three original observations about what organizations should learn First, identity has become the primary attack surface, and the help desk is its softest perimeter. Technical controls around Okta, Azure AD/Entra ID, or similar platforms can be excellent, yet a single procedural weakness in account recovery or MFA reset can hand an attacker the master key. Organizations should inventory every path that can create, reset, or re-enroll credentials and apply the same rigor to those human workflows that they apply to privileged access management. Second, operational technology and guest-facing systems are now tightly coupled to corporate identity. Encrypting ESXi hypervisors did not merely encrypt “IT assets”; it stopped slot machines, room keys, and reservations. Resilience planning must explicitly address the blast radius from identity compromise into revenue-critical and physical-guest systems. Segmentation and independent recovery paths for those layers are no longer optional for hospitality, gaming, retail, or any industry with real-time customer experience. Third, English-fluent, socially adept threat actors have changed the economics of intrusion. Groups such as Scattered Spider lowered the barrier from “need a zero-day or malware delivery” to “need a phone and public information.” Defenses that assume attackers are non-native speakers or rely solely on technical filters will systematically under-protect against this class of adversary. Continuous training, realistic tabletop exercises that include vishing scenarios, and metrics on help-desk verification compliance are therefore as important as any new security product.

6. Sources and limitations: Primary sources, reliable reporting, and what remains unconfirmed Primary sources for confirmed facts are MGM’s SEC Form 8-K filings (September 2023 disclosure and October 5, 2023 update detailing impact and data exposure) and the company’s public statements. CISA/FBI joint advisory AA23-320A (November 2023, with later updates) provides authoritative TTPs for Scattered Spider and recommended mitigations. Secondary reporting from Reuters, Bloomberg, SecurityWeek, Cybersecurity Dive, and others supplied attribution to Scattered Spider/ALPHV and the help-desk narrative, largely based on threat-actor claims, researcher analysis (including vx-underground relays), and industry sources. Okta publicly stated that its own systems were not breached and that it assisted MGM as a customer. What remains unconfirmed by MGM itself includes the precise initial-access sequence (LinkedIn + specific help-desk call), the exact privileges obtained in Okta and Azure, the use of inbound federation, the number of encrypted ESXi hosts, whether a ransom was demanded or paid, and the full volume of data exfiltrated beyond the described personal information. Attribution relies on open-source intelligence and threat-actor self-reporting rather than official company confirmation. Readers should treat attacker statements with appropriate skepticism; they have incentives to exaggerate capability and minimize friction. The financial and operational impact figures, however, rest on regulatory filings and are therefore more robust. The MGM incident remains a clarifying case study: when identity processes fail, even mature technical defenses can be bypassed, and the consequences extend far beyond the data center into the guest experience and the balance sheet. Strengthening the human and procedural layers around identity is now a core resilience requirement.

https://www.sangfor.com/blog/cybersecurity/casino-hack-las-vegas-mgm-cyber-attack?utm_source=chatgpt.com
https://www.cisa.gov/search?g=mgm#gsc.tab=0&gsc.q=mgm&gsc.page=1
https://www.sec.gov/edgar/search/?utm_source=chatgpt.com

Why I Created Threat Atlas

I'm building my cybersecurity knowledge step by step, exploring security fundamentals, practical labs, threat analysis, and the relationship between cybersecurity and business risk.

I created Threat Atlas to turn that learning process into something more meaningful than private notes. I want to build a place where I can document my progress, investigate real incidents, and share useful lessons with people who are interested in cybersecurity.

The name Threat Atlas reflects the idea behind this project: an atlas helps us understand a landscape, identify important locations, and find our way through unfamiliar territory. In cybersecurity, that landscape is constantly changing. New vulnerabilities appear, attack methods evolve, and organizations face new challenges every day.

My goal is to explore that landscape one topic at a time.

What You'll Find Here

Threat Atlas will focus on four main areas.

1. Threat Research and Incident Analysis

Cyberattacks are often discussed through headlines, but understanding what happened requires looking beyond the headlines.

I'll explore publicly documented incidents, examine how attacks occurred, identify their consequences, and investigate what individuals and organizations can learn from them.

Rather than simply repeating news, I want to ask questions such as:

• What happened, and what do reliable sources confirm?

• How did the incident affect the organization and its users?

• Which security weaknesses or human factors contributed to the incident?

• What defensive measures could help reduce similar risks?

I'll distinguish verified information from my own analysis and acknowledge when details remain uncertain.

2. Hands-On Labs and Projects

Cybersecurity cannot be learned through theory alone. Practical experiments help turn concepts into skills.

I'll document projects and lab exercises involving defensive security, Python, Linux, log analysis, and security tools. Each write-up will explain the objective, the methods I used, the results, and what I learned.

Some projects may be simple at first. That's intentional. I believe small, well-documented projects can be valuable when they demonstrate clear thinking, careful testing, and a willingness to improve.

Where appropriate, I'll share code and project files so others can review the work and learn alongside me.

All practical testing will be conducted in authorized environments using systems and data I'm permitted to access.

3. Learning Notes and Security Fundamentals

Cybersecurity contains many concepts that can seem complicated when you're first introduced to them.

I'll break down topics into clear explanations, practical examples, and lessons that are easier to apply. These may include phishing, authentication, access control, common vulnerabilities, Linux fundamentals, and basic threat detection.

I'll also share mistakes and lessons from my own learning process. Not every experiment will work as expected, and understanding why something failed can be just as useful as understanding why it succeeded.

My aim is not to oversimplify cybersecurity, but to make it easier to approach.

4. Cybersecurity and Business Risk

Security incidents do not affect technology alone. They can interrupt operations, damage customer trust, create financial losses, and affect an organization's long-term decisions.

With my background in International Business and Trade, I'm particularly interested in how cybersecurity connects with business strategy and risk management.

I'll explore questions such as how small businesses can prioritize security with limited budgets, how organizations can prepare for disruptions, and why cybersecurity decisions should consider both technical threats and business consequences.

I want to understand not only how attacks happen, but also how organizations can make better decisions to prevent and respond to them.

How I'll Approach Research

A useful cybersecurity publication should be more than a collection of opinions. It should help readers understand where information comes from and how conclusions are reached.

To keep my work responsible and useful, I'll follow a few principles:

• Verify before publishing. I'll prioritize official advisories, primary documents, technical reports, and reputable sources.

• Separate facts from analysis. I'll make it clear when something is confirmed and when I'm offering my own interpretation.

• Acknowledge limitations. If information is incomplete or a conclusion is uncertain, I'll say so.

• Learn responsibly. Practical security work will focus on authorized testing, defensive learning, and responsible disclosure.

• Keep improving. If I discover an error, I'll aim to correct it rather than leave misleading information unaddressed.

I'm still developing my skills, so I won't present myself as an expert in areas where I lack experience. Instead, I'll show my research process, explain my reasoning, and remain open to constructive feedback.

What I Hope to Build

Over time, I want Threat Atlas to become both a research archive and a professional portfolio.

Each article will document a question I've explored. Each project will demonstrate a skill I've practiced. Together, they will show not only what I've learned, but also how I approach problems, evaluate evidence, and turn knowledge into practical work.

I hope this platform will be useful to other learners, curious readers, and cybersecurity professionals who want to exchange ideas. If something I publish helps someone understand a threat, improve a security habit, or begin their own project, then the effort will have been worthwhile.

The journey will take time. There will be unfamiliar concepts, difficult labs, mistakes, and plenty of things to learn. That's part of the process.

Welcome to Threat Atlas

This is the beginning, not the finished product.

I'll be building the platform one investigation, one experiment, and one lesson at a time. I invite you to follow along, explore the work, and share thoughtful feedback as the project develops.

Cybersecurity is a field that rewards curiosity, careful thinking, and continuous learning. I want Threat Atlas to reflect those values.

Learn openly. Investigate carefully. Build defensively.

Welcome to Threat Atlas.

#cybersecurity #cyberrisk #confidentiality #integrity
#learning-in-public #availability #self-awareness
#threat-research #self-learning