Adversaries may gather credentials for use during targeting. MITRE lists this under Reconnaissance with platform PRE. The credentials may belong to the target organization directly, or they may be personal ones that users reuse at work.
This is the quiet step before an account takeover. When it works, the later login looks like a normal user.
How attackers use it
MITRE lists several ways credentials are collected. Direct elicitation through phishing for information is one. Another is compromising a website and adding content that collects authentication cookies from visitors. Where MFA depends on out of band communication, adversaries may compromise a service provider to reach MFA codes and one-time passwords.
Credentials can also be exposed through leaks to online data sets, which MITRE says include search engines, breach dumps, and code repositories. It adds that adversaries may buy credentials from dark web markets, and may reach Telegram channels that distribute logs from infostealer malware.
The information can lead to more reconnaissance, to compromised accounts used as operational resources, and to initial access through external remote services or valid accounts. MITRE names tendency to reuse passwords across personal and business accounts as part of why this works.
It helps to place this technique in a longer chain. Collection is rarely the last step. A password from an old breach, a cookie from a compromised site, or a log from infostealer malware becomes the key for an external remote service or a valid account later on. The login that follows looks like a normal user.
That is why MITRE's mention of password reuse matters. A credential exposed at a personal service, a forum, or a shopping site can open a work account if the same password was used. The company never saw the breach and cannot control it.
The MFA point is worth noting. MITRE says that where MFA depends on out of band communication, adversaries may compromise a service provider to reach codes and one-time passwords. That is a reminder that not all second factors are equal.
One more detail from MITRE: the sources named include breach dumps and infostealer log channels. Those are not hacks of your company. They are the output of other incidents that happen to contain your people. That is why exposure monitoring and forced resets matter even when your own systems are clean.
How to detect it
MITRE warns that this activity may have a very high occurrence and false positive rate and may happen outside your visibility, so detection at this stage is difficult.
Its advice is to focus on related stages, such as initial access. For credentials, that means the sign-in events: logins from new locations or devices, impossible travel, a successful login right after many failures, use of a service account from an unusual host, and remote access sessions outside normal hours.
A second angle is exposure monitoring. Look for your domains in breach data and for your organization's keys and passwords in public code, because you can catch those before an attacker uses them.
Since collection is hard to see, build detection around the sign-in. Review the sign-in logs of your identity provider for logins from a country or network you do not expect, for a successful login after a series of failures, and for sessions that use a token from a new device.
Add exposure monitoring. Many organizations check whether their domains appear in public breach data and in code repositories, then act on a hit by forcing a reset. A hit is an early warning that costs nothing compared with a compromise.
Do not forget service accounts and API keys. They tend to have no MFA, long lifetimes, and broad rights. An unusual source address for a service account is a high quality alert.
How to reduce the risk
- MITRE says this cannot be easily mitigated with preventive controls and that efforts should focus on minimizing the amount and sensitivity of data available to external parties. The steps below follow that direction.
- Use phishing resistant MFA so a collected password or code is not enough on its own.
- Ask staff not to reuse work passwords elsewhere, and support them with a password manager.
- Scan your repositories and build output for secrets, and rotate anything that has been exposed.
- Reset credentials promptly when your domain appears in a breach or infostealer data set.
- Alert on risky sign-ins and review service accounts, which often have no MFA.
The common thread is to make a stolen credential worth little. Phishing resistant authentication, short session lifetimes, conditional access based on device and location, and quick revocation all do that. Together with the exposure steps above, they follow MITRE's advice to reduce what is available to outsiders and to focus on the stages where you can act.
The demo below walks through secret scanning, which covers the code repository side of this technique.
Test the reset process before you need it. Many organizations find that revoking sessions, tokens, and keys takes longer than resetting a password, and that is the part an attacker will use.
Check your own environment
Read-only checks you can run on a repository you own, using git on Linux, macOS, or Windows:
# list commits that ever touched common secret-bearing files
git log --all --oneline -- .env '*.pem' '*.key'
Then work through these:
- Has any credential ever been committed, even if it was later deleted?
- Do we know which accounts have no MFA?
- Do we monitor for our domains in breach data?
- Can we force a reset and revoke sessions quickly?
Try it yourself
A walkthrough of finding and handling exposed secrets in code before someone else does.
Click through it at your own pace, or open it full screen.
Quick check
Where does MITRE say credentials can be exposed?
In leaks to online data sets, including search engines, breach dumps, and code repositories, and through infostealer logs sold or shared on markets and Telegram channels.
Why focus on initial access for detection?
Gathering is high volume and often outside your visibility, so MITRE advises watching the later stage where the credentials are used.
Sources
- MITRE ATT&CK, Credentials (T1589.001): https://attack.mitre.org/techniques/T1589/001
