fix: [lastline_api] fix MITRE ATT&CK galaxy tag operand order

[elhoim]

The defect

LastlineResultBaseParser._get_mitre_techniques() in misp_modules/lib/lastline_api.py built the MITRE ATT&CK galaxy tag with the operands in the wrong order:

@staticmethod
def _get_mitre_techniques(result):
    return [
        'misp-galaxy:mitre-attack-pattern="{} - {}"'.format(w[0], w[1])
        for w in sorted(
            set(
                [
                    (y["id"], y["name"])
                    for x in result.get("malicious_activity", [])
                    for y in result.get("activity_to_mitre_techniques", {}).get(x, [])
                ]
            )
        )
    ]

w is (id, name), so this produced tags like misp-galaxy:mitre-attack-pattern="T1134 - Access Token Manipulation" — id first, name second. Every other MITRE ATT&CK galaxy tag built in this repository uses the opposite order, "name - id" (see misp_modules/lib/joe_parser.py:125), which matches the actual cluster value name in the misp-galaxy:mitre-attack-pattern galaxy.

Impact

Because the tag string didn't match any real galaxy cluster value, MISP could not resolve it to the corresponding MITRE ATT&CK galaxy cluster. An analyst enriching a sample via the Lastline module would get a tag attached to the event that looks like a MITRE technique reference but silently fails to link to the galaxy cluster in the UI — no cluster metadata, no navigation to the technique, no consistency with tags produced by other enrichment modules (e.g. Joe Sandbox) for the same techniques.

The fix

Swapped the format operands so the tag is built as "{name} - {id}", matching the convention used elsewhere in the codebase (joe_parser.py) and the format MISP's mitre-attack-pattern galaxy actually expects.

No behaviour change beyond correcting the tag string — this is a straightforward bug fix, not a change of default or contract.

Verification

• python -m py_compile misp_modules/lib/lastline_api.py — clean (this file is under misp_modules/lib/ and is excluded from flake8 per this repo's CI convention).
• Full test suite: 1 failed, 160 passed, 4 skipped, 5 subtests passed in 22.69s. The one failure, test_macvendors, is an HTTP 429 rate limit from the third-party MacVendors API, unrelated to this change; re-running it in isolation passed. There is no dedicated test file exercising lastline_api.py or _get_mitre_techniques() in tests/ (confirmed by search), so the full-suite pass with only that unrelated failure is the available verification.

Found during a review of the repository; other findings are being submitted as separate PRs.

🤖 Generated with Claude Code

https://claude.ai/code/session_018dfYpyaSZd1nxSRLr8suj8