Detecting and Mitigating Staged Malware Uploads (T1608.001)

Upload Malware (T1608.001) is a Resource Development sub-technique of Stage Capabilities. Its platform is PRE, because the work happens before the adversary reaches your environment. The adversary puts malware somewhere a victim can fetch it, so that later stages such as User Execution or Ingress Tool Transfer have something to deliver.

You will rarely see the upload. You will see the download. That makes this a technique where defense lives at the point where your people and your build systems pull in files.

How attackers use it

MITRE describes malicious software that can include payloads, droppers, post-compromise tools and backdoors. It may be uploaded to third-party or adversary controlled infrastructure so it is reachable during targeting, for instance on an internet-accessible web server that supports Ingress Tool Transfer.

The page lists several places malware gets staged:

• Infrastructure the adversary bought or rented, or infrastructure they compromised.
• Web services such as GitHub or Pastebin.
• The InterPlanetary File System (IPFS), where decentralized storage makes removal of malicious files difficult.
• The blockchain, saved as smart contracts, which resist takedowns that would affect traditional infrastructure.

A second pattern matters a lot to software teams. Adversaries may upload backdoored files such as software packages, application binaries, virtual machine images or container images to third-party software stores, package libraries, extension marketplaces or repositories. MITRE names GitHub, CNET, AWS Community AMIs, Docker Hub, PyPI and npm as examples. Victims may download and install these by chance, and masquerading, including typosquatting legitimate software, raises the odds of someone running the wrong file.

The MITRE page lists many groups with documented examples. A few that show the range: APT32 hosted payloads in Dropbox, Amazon S3 and Google Drive. BlackByte staged tools at public file sharing and hosting sites. FIN7 staged legitimate software trojanized with an Atera agent installer on Amazon S3. Contagious Interview hosted malicious payloads on code repositories used as lures. EXOTIC LILY uploaded payloads to file-sharing services including TransferNow, TransferXL, WeTransfer and OneDrive.

Notice how many of those are ordinary services your own employees use. A block on one hosting domain would break normal work, so reputation and context matter more than the domain alone.

How to detect it

MITRE's detection strategy is candid about the limits. If infrastructure or patterns in malware have been identified before, internet scanning may uncover that an adversary has staged malware. Much of this takes place outside the visibility of the target organization, so detection efforts are better focused on post-compromise phases such as User Execution and Ingress Tool Transfer.

For defenders that translates into a few places to look:

• Downloads from file sharing and code hosting services by processes that do not normally use them, such as a script interpreter or an Office application.
• New executables and archives that appear shortly after a browser or mail client fetches from a public storage service.
• Newly added dependencies in builds. A package that appeared this week with a name close to a popular one deserves a look before it is installed.
• Container images and VM images pulled from public registries or community image catalogs that are not on an approved list.

How to reduce the risk

MITRE's mitigation entry for this sub-technique states that it cannot easily be mitigated with preventive controls, since it is based on behaviors performed outside the scope of enterprise defenses. That is true of the upload. The download and execution steps are fully in your hands, and these controls apply there:

1. Limit who can install software. Standard users should not be able to run arbitrary downloaded installers.
2. Use an approved source list for packages, extensions and images. Pull through an internal mirror or proxy where you can.
3. Pin and review dependencies. Lock files, hash checks and a human look at any new package name catch the typosquat case.
4. Check names carefully. Typosquatting works because people and scripts accept near matches. Review spelling, publisher and publish date on anything new.
5. Scan what you pull in. A scan of your dependency list against known malicious or vulnerable packages is cheap insurance before a build ships.

For the dependency side, Safeguard offers a free in-browser dependency scan at gold.safeguard.sh/scan. It needs no login, the file never leaves your machine, and it handles up to 100 dependencies. The Gold directory is also a quick place to look up a package before adding it.

Check your own environment

• List every public registry, image catalog and extension marketplace your teams pull from. Is each one intentional?
• Search your lock files for packages added in the last 30 days and read their names out loud. Do any look one letter off from something popular?
• Check whether build agents can reach arbitrary file sharing sites.
• Look at which processes made outbound downloads from Dropbox, Google Drive, OneDrive, Pastebin or GitHub raw content in the past week. Are script hosts or document apps on the list?
• Confirm that images in production came from a registry you control.

Read-only example on a Linux or macOS machine with Node.js tooling (lists direct dependencies and their declared versions):

npm ls --depth=0

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK T1608.001 Stage Capabilities: Upload Malware