Lennar Corporation and Lennar Mortgage, LLC filed separate breach notifications with the California Attorney General three days apart this month. Both letters are signed from 5505 Waterford District Drive in Miami. Read together, they describe two intrusions nine weeks apart — and the second one started while the first was still under investigation.
The Lennar Corporation notice says an unauthorized party "used sophisticated social engineering tactics to access some of our systems between March 24, 2026, and March 30, 2026." The company became aware March 30 and concluded its assessment of the data involved on July 30.
The Lennar Mortgage notice uses the identical phrase for access "between May 26, 2026 and June 1, 2026," with awareness June 1 and the assessment concluded August 4.
The second intrusion began 57 days after the first was detected, and ended 65 days before anyone closed the book on the first.
A Lennar spokesperson told HousingWire these were "two separate and, we believe, unrelated social engineering-based cybersecurity events." Take that at face value. It is the more useful reading, and also the worse one.
Unrelated is the harder problem
If the two intrusions were one actor coming back, the finding is narrow: an access path survived remediation. Bad outcome, bounded cause, fix scoped to whatever the attacker kept.
If they were genuinely unrelated, the same technique defeated the same organization twice in nine weeks with nothing shared between the attempts. That is not a missed indicator. It is a control failing an unscheduled test, twice, during the exact period when the company knew it had a social-engineering problem and had — per both letters — "implemented additional technical security measures to further protect our systems."
Neither letter names the technique, and as of August 18, 2026 nothing public establishes whether this was help-desk impersonation, an MFA factor reset, or a vishing call — so what follows is about the class of failure rather than this particular one.
That class is well understood. Social engineering that yields a working credential leaves nothing for monitoring to catch, because what follows is a legitimate login by an authorized account — the same property that makes a compromised remote management console hard to spot, where the tool doing the work is the tool you approved. Six days of dwell time in both incidents fits that shape.
The practice: retest the remediation while the incident is still open
After an incident, most organizations schedule their next adversarial test for the next budget cycle. The useful move is smaller and much sooner — a narrow test of one question: does the thing that worked still work? Four steps, none needing a dedicated security function.
- Write the access path as one operational sentence. "Someone called the help desk, claimed to be an employee, and got an MFA factor reset." Not "an unauthorized third party gained access through social engineering." Forensic language is written to survive a lawyer's review, and it names no action anyone can attempt.
- Write the control change as an assertion that can be defeated. "The help desk cannot reset an MFA factor without a callback to a number already on record and a manager's approval." If you can't phrase it this way, it isn't specific enough to have fixed anything.
- Have someone try to defeat it who was not part of the response — with real permission to try, and without already knowing the answer.
- Do it within 30 days of the change, not at the next annual assessment.
The cost is why this gets skipped. In the 60 days after an incident, the people who understand what happened are consumed by forensics, legal calls, notification list-building, and customer conversations. Asking them to also run an adversarial test is how it slides into next quarter. And nobody writes the second cost in a ticket: this test is designed to embarrass a remediation somebody already reported to executives as complete.
Both costs point at the same fix. Give the retest to someone who was not on the response — they aren't buried in it, and they have no stake in the remediation being correct. Steps 1 and 2 fit on one page, so scope it while the details are fresh and run it once the response team stands down.
If you can't test at all, alert on the specific action from step 1. If the path was a help-desk MFA reset, every factor reset for 90 days should notify a person who will actually look at it. Weaker than checking whether the control holds, much better than assuming it does.
What to check this week
- For your most recent incident, can you state the access path in one operational sentence? If the only written version is the forensic report's phrasing, nobody can test it.
- What control changed as a result, and is it written as an assertion someone could try to defeat?
- Who tested that change, and were they on the response? If yes, the work was graded by its own author.
- For the specific action in your access path — factor reset, password reset, privileged group change — does anyone get alerted today?
One thing this story is not about: 134 days elapsed between Lennar Corporation's detection and its California filing, which looks alarming until you read the statute. SB 446 took effect January 1, 2026 with a 30-day deadline and an explicit allowance for time "necessary to determine the scope of the breach," and both filings landed within two weeks of their assessment conclusions. Notification clocks are a real problem in other cases, just not the one worth studying here.
North InfoSec runs AI-assisted penetration testing and security assessments, including the kind of post-incident control retesting described above. northinfosec.com