Six Hours of Suspicious Activity
At 06:40 on a Tuesday, an alert shows 4,300 failed logins in 12 minutes from three IP ranges, one of which is the office VPN. At 07:15 a service account named integration@, which normally makes about 2,000 API calls a day, makes 180,000, including 60 report exports. At 09:00 the security team asks three questions: who changed the Account sharing rules last month, what user J. Alvarez exported and when, and can we prove no one edited the 12,000 Opportunity Amount values over the last two years. The org has 1,400 users, Event Monitoring has not been purchased, and the admin who left in March never enabled field history on Opportunity.
1. How do you triage the failed-login spike using tools the org already has, and what does the spike from the office VPN range change about your conclusion?
Read the worked answer
Start with Login History - the LoginHistory object retains six months, and the Setup UI shows recent attempts per user. Filter on the failure status to separate the causes, because they mean different things: 'Invalid Password' suggests credential stuffing or a bad password; 'API security token required' or 'Failed: API' suggests a misconfigured integration, not an attacker; 'Blocked by IP restrictions' suggests a policy doing its job.
The VPN range is the important clue and cuts both ways. It may be an internal actor or a compromised internal device - the most dangerous case, because perimeter controls assume the VPN is trusted. It may equally be a device on the VPN running stale cached credentials against an API, hammering a login it will never win. Pivot on the source IP, not just the count: check whether any login succeeded from those ranges in the same window, and whether it was for a privileged user.
The 07:15 service-account surge correlates in time and probably shares a cause - if the integration password was changed or a security token rotated, the integration would retry in a loop, producing both failures and volume.
Actions: kill active sessions for any account that succeeded after repeated failures, confirm MFA coverage, reset the service account credentials through the secret store, and add a Transaction Security policy if Shield is available - that is the only standard mechanism to block in real time, and it requires Event Monitoring.
2. Which of the security team's three questions can the org answer today, and which can it not? Be specific about the evidence.
Read the worked answer
Answer them one at a time, separating what exists from what does not.
Who changed the Account sharing rules last month - yes, probably. The Setup Audit Trail records setup and configuration changes, including sharing rule edits, with user, timestamp and the before/after values, and it retains 180 days. If the change was within that window it will be there. If the change was to a record rather than to configuration, it is not in the audit trail at all.
What J. Alvarez exported and when - no, not with what the org has. Export and report-run events are captured by Event Monitoring, which the org has not purchased, and whose event log files are retained only 30 days. Setup Audit Trail does not record data exports. The honest answer is that the evidence was never collected, and buying Event Monitoring now only captures the future. The 60 report exports by the service account make this the most damaging gap.
Can we prove no one edited 12,000 Opportunity Amounts over two years - no, and no configuration can change that. Field history was never enabled on Opportunity, and it is not retroactive; even if it had been, standard field history has a per-object field cap and limited retention, and Field Audit Trail would have been needed for a two-year archive.
Say this plainly. An answer that overstates the evidence is worse than a gap, because it will be relied on.
3. What would you put in place now so that the same three questions are answerable next year?
Read the worked answer
Design backwards from the questions that were unanswerable.
- Enable field history now, and be deliberate about it. Turn on history for Opportunity Amount and the other financially material fields, and adjust page layouts and related lists so the history is actually visible. Note the per-object field cap - you cannot track everything, so choose based on what an auditor will ask. If the retention requirement exceeds what standard history offers, Field Audit Trail is the mechanism, and it is an add-on, so there is a commercial conversation to have.
- Purchase Event Monitoring if data exfiltration is in scope. It is the only way to answer 'who exported what', and the retention trap matters operationally: log files are available for a limited window, so if nobody is downloading and storing them, you have paid for nothing. Automate the extract into external storage.
- Stand up Transaction Security policies for the scenarios you already saw - a spike of failed logins followed by a success, and an abnormal API volume from a service account. These block rather than report, which is the difference between observing and preventing.
- Close the monitoring hygiene gap. The admin who left in March left with knowledge of what was never enabled; a quarterly review of audit settings, field history coverage, and integration account permissions belongs on someone's calendar with a name attached.
- Fix the service account model - least-privilege, dedicated credentials in a secret store, and an alert on volume deviation from baseline, which is the control that would have caught the 180,000-call day in minutes rather than hours.
Each of these is cheap now and expensive after the next incident.