[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-63":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":10,"languages":10,"totalLinesOfCode":10,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":33,"readmeContent":34,"aiSummary":35,"trendingCount":15,"starSnapshotCount":15,"syncStatus":36,"lastSyncTime":37,"discoverSource":38},63,"Impacket-IoCs","ThatTotallyRealMyth\u002FImpacket-IoCs","ThatTotallyRealMyth","This repo contains the results of an internal re-write of impacket I undertook at my current company. It contains some of the IoCs found within the library","",null,300,28,201,1,0,22,26,77,66,4.39,"GNU General Public License v2.0",false,"main",true,[26,27,28,29,30,31,32],"defense-evasion","detection-engineering","impacket","incident-response","indicators-of-compromise","malware-detection","offensive-security","2026-06-12 02:00:07","# Dissecting Impacket\n\nA public reference of protocol-level and implementation-level indicators of compromise(IoCs) for detecting Impacket-driven activity.\n\nFeel free to open an issue if you find something you think I incorrectly stated, for any feedback or if you have a specific protocol or implementation youd like me to add fingerprints for\n\n## Overview\n\nThis repository contains a part of my notes from an internal rewrite\u002Ffork of Impacket that I had undertaken at my current job. I had taken alot of the internal signals produced by Impacket and several of its example tools and provided them here for other blue and red teamers to benefit from. \n\nThe goal is to help defenders understand what Impacket activity can look like at the protocol, authentication, and implementation layers beyond just at the command-line or artifact level. For red teamers, I hope that this repo servers as an inspiration for operators to undertake similar iniatives to improve the operational security of their toolkits as well as serve as a blueprint for how to approach dissecting tooling to understand normal from abnormal.\n\nMuch of offensive tooling detection focuses on things like filenames, service names, temporary paths, command output redirection, scheduled task names, and other surface-level artifacts. Those detections are useful, but they are also often easy to change.\n\nWhile there is some of them, this project tries to focuse on deeper signals: Kerberos request construction, NTLMSSP fields, SPNEGO wrapping, SMB negotiation behavior, DCE\u002FRPC authentication trailers, WMI\u002FDCOM activation details, LDAP object creation patterns, and example-script defaults.\n\nThe intent is to give defenders, especially smaller teams without access to expensive commercial detection content, practical signals they can use to build stronger fingerprints for Impacket abuse. Similarly its to showcase to red teamers the sort of artifacts and signals their tooling could or may leave behind and to better showcase approaching that to improve engagment delivery.\n\n## What is included\n\nThis research currently documents **67 Impacket-related IoCs** across the following categories:\n\n| Category | Count | Examples |\n| --- | ---: | --- |\n| Kerberos and ticketing | 15 | AS-REQ differences, TGS-REQ etype ordering, AP-REQ wrapping, forged ticket defaults |\n| SMB | 3 | SMB2\u002F3 ClientGuid, negotiate context behavior, SMB1 dialect negotiation |\n| NTLM and SPNEGO | 11 | NTLMSSP omissions, NTLMv2 challenge shape, NTLM class spec deviations\u002Fviolations, SPNEGO wrapping differences |\n| LDAP and Active Directory objects | 2 | Default computer\u002Fobject creation naming patterns |\n| DCE\u002FRPC, DCOM, and WMI | 15 | `auth_context_id`, missing verification trailers, WMI\u002FDCOM activation behavior, dummy\u002Ffake OpNum use in RPC relay clients |\n| Example-script execution artifacts | 7 | `psexec.py`, `smbexec.py`, `atexec.py`, `dcomexec.py`, RemCom artifacts |\n| secretsdump, DRSUAPI, and VSS | 4 | DRSBind behavior, DRSGetNCChanges defaults, VSS execution patterns |\n| MSSQL | 4 | LOGIN7 metadata, PRELOGIN behavior, SQL Agent job creation |\n| ntlmrelayx HTTP, WebDAV, RDP, and SCCM | 6 | WPAD, WebDAV, RDP relay certificate, SCCM policy strings |\n\n## How to read this research\n\nNot every IoC in this repository should be interpreted the same way.\n\nSome indicators are strong standalone fingerprints. Others are best treated as enrichment signals, weak features, or noise reducers that become valuable when combined with additional evidence.\n\nA good detection strategy should separate these into three rough groups:\n\n### 1. High-confidence standalone signals\n\nThese are indicators that are unusual enough to be meaningful on their own in many environments.\n\nExamples include:\n\n- Authenticated DCE\u002FRPC using `auth_context_id = 79231 + ctx_id`\n- DCE\u002FRPC authentication padding using `0xff`\n- LDAP Kerberos bind placing a raw Kerberos `AP-REQ` directly in the SPNEGO `mechToken`\n- SMB2\u002F3 negotiate requests with ASCII-letter `ClientGuid` values\n- WMI `IWbemLevel1Login::NTLMLogin` using non spec compliant namespacing slashes `\u002F\u002F.\u002Froot\u002Fcimv2`\n- Hardcoded Kerberos noonce value\n\nThese should still be validated in your own environment, but they are the types of signals that may justify higher-confidence alerting when seen in the right context.\n\n### 2. Cluster-based signals\n\nSome indicators are not reliable enough alone, but become powerful when several appear together from the same source host, user, session, or time window.\n\nExamples include:\n\n- Sparse Kerberos AS-REQ encryption type lists\n- Missing or unusual Kerberos `PA-DATA`\n- TGS-REQ encryption type ordering differences\u002Fduplicate entries\n- NTLM Type 1 messages missing version information\n- NTLM Type 3 messages with null host names\n- Raw NTLMSSP in DCE\u002FRPC instead of SPNEGO\n- Missing DCE\u002FRPC verification trailers\n- Mismatch in Kerberos Auth OIDs specified between the mechList and the KRB_OID\u002FTOK values\n\nThese are well-suited for scoring models, correlation searches, or detection logic that says: “This activity has multiple Impacket-like implementation traits.”\n\n### 3. Noise reducers and supporting context\n\nSome IoCs are better used to reduce noise, enrich other detections, or explain why an alert is suspicious.\n\nExamples include:\n\n- Default filenames or output paths\n- Random service naming patterns\n- Temporary batch file names\n- Default computer account names\n- Tool-specific HTTP, WebDAV, RDP, or MSSQL strings\n- DCE\u002FRPC UUID Entries that dont confer with Microsoft patterns of Versioning\u002FVariants\n\nThese are useful, but they are also more operator-controllable. Treat them as supporting evidence rather than the only reason an alert fires.\n\n## Why protocol-level detection matters\n\nMany Impacket fingerprints exist below the level most operators interact with.\n\nAn operator can rename a service, change an output file, modify a command string, or patch an example script. They may not notice that the library is still shaping Kerberos, NTLM, SMB, LDAP, or DCE\u002FRPC traffic in a way that differs from normal Windows behavior.\n\nThat is where durable detection often lives.\n\nThe best detections come from understanding three things at the same time:\n\n1. What the protocol allows\n2. What Windows normally emits\n3. Where Impacket consistently behaves differently enough that it can be a statical anomoly\n\nThis research attempts to document those differences in a way that defenders can turn into practical network, endpoint, or telemetry-driven detections. While also in a way for red teamers to learn from, and expand on in their own tooling\n\n## Recommended usage\n\nUse this repository as a reference for building, validating and (if youre a red teamer) defeating detections, not as a direct copy\u002Fpaste alert library.\n\nFor each IoC, consider:\n\n- Does this field appear in my telemetry?\n- Can I decode or extract it reliably?\n- Does my environment have legitimate software that behaves similarly?\n- Is this strong enough to alert on alone?\n- Should this instead be used as a correlation feature?\n- Does the signal become stronger when paired with Kerberos, SMB, NTLM, LDAP, or DCE\u002FRPC activity from the same host?\n- Would I be able to leverage statistical modeling and data analysis tricks to elevate the effectiveness of the signal?\n\nWhenever possible, build detections around clusters of behavior rather than a single field.\n\nFor example, a single missing NTLM version field may not be enough. But a client that also shows raw NTLMSSP over DCE\u002FRPC, missing verification trailers, an Impacket-style `auth_context_id`, and unusual WMI activation behavior is much more interesting and almost always garunteed to be an impacket user as opposed to a real windows device. \n\n## Caveats\n\nThis research should be interpreted with context.\n\n- Some behaviors may vary by Impacket version, fork, or local modification. I used the last\u002Fmost current main\n- Some behaviors may vary by Windows version, domain policy, authentication type, or service being accessed. Testing was done on Windows server 2022 and Windows Server 2012\n- Some indicators may overlap with Samba, Linux clients, legacy software, appliances, or custom implementations.\n- Some detections require decrypted traffic, endpoint telemetry, ETW, Zeek-style protocol parsing, PCAP analysis, or service-side visibility.\n- Line numbers in source references may drift over time as Impacket changes.\n- A single protocol field rarely tells the whole story.\n\nThe safest way to operationalize this work is to test against your own baseline and then promote detections gradually from enrichment, to hunting, to alerting.\n\n## Suggested detection philosophy\n\nA practical approach is:\n\n1. Use high-confidence protocol quirks as direct alerts where your environment supports it.\n2. Use weaker implementation quirks as scoring features.\n3. Correlate across protocol layers.\n4. Prefer clusters over single-field assumptions.\n5. Treat tool defaults as supporting evidence, not the whole detection.\n6. Re-test detections when Impacket or Windows behavior changes.\n\nAs these things usually are, its a cat and mouse game. I have no doubt that the detections spelled out here will soon become obselete but when they do, I hope that the next person out does me and the rest : ) \n","该项目是对Impacket库进行内部重写后提取出的协议级和实现级的入侵指标（IoCs），旨在帮助检测Impacket驱动的活动。核心功能包括提供67个与Impacket相关的IoCs，涵盖Kerberos票证、SMB行为、NTLM\u002FSPNEGO字段、LDAP对象创建模式等深层信号。这些信号超越了表面级别的文件名和服务名检测，有助于构建更强大的指纹识别机制。适合场景为网络安全防御者特别是资源有限的小团队，以及希望提升工具安全性并了解其潜在痕迹的红队成员使用。",2,"2026-06-11 02:30:40","CREATED_QUERY"]