6 Chapter 1 REGISTRY ANALYSIS
in an investigation where a former employee was thought to
have provided sensitive data to a competitor and then accepted
employment with the competitor. An examination of the system
revealed that while the employee was traveling, he’d connected
his corporate laptop to WiFi at a Starbucks near the competitor’s
building and then to the WiFi in the competitor’s offices about an
hour later. A combination of the WiFi access point names and a
geolocation lookup of the medium access control (MAC) addresses
of the access points, along with date and time stamps, revealed
important clues about the employee’s activities.
Analysts need to keep Locard’s exchange principle in mind dur-
ing an examination because it can not only tell them that there are
artifacts, but can also point them to where those artifacts may be
located. Knowing likely sources of artifacts significantly reduces
the time it takes to conduct an investigation; instead of combing
through all of the data, the examiner can target those specific areas
to quickly determine whether they will be fruitful or not. This sort
of data collection and triage can greatly assist incident response
activities as well as increase the throughput of investigations, as a
whole, without sacrificing quality or completeness.
Least Frequency of Occurrence
I first heard the term “least frequency of occurrence” men-
tioned in the context of digital forensics at the SANS Forensic
Summit during the summer of 2009. Peter Silberman (an analyst
with the consulting firm Mandiant) used the term to describe
malware infections on systems. His point was that in the old days,
malware (and in particular worms) would spread rapidly, infect-
ing and reinfecting systems. In short order, a system would be so
heavily infected that it would become completely unusable by
anyone, let alone the attacker. The result was that not only were
infected systems unusable to the attacker, but the failing systems
provided a clear indication to the “victim” organization that they
were infected. In order to address this, malware authors began
using a unique “mutex,” a software programming object that
allows for mutual exclusion, within their malware in order to pre-
vent the system from becoming reinfected. Once the system was
infected, the mutex would be present in memory; upon reinfec-
tion, the malware would check for the mutex and, if found, not
proceed with the infection.
The offshoot of this is that the mutex is very often random
(although sometimes not so random) and always unique. This
became an excellent indicator of a malware infection; in fact, Kris
Harms (at the time an analyst with Mandiant, who later became
剩余203页未读，继续阅读
ramissue
- 粉丝: 354
- 资源: 1487
我的内容管理
展开
最新资源
- 多模态联合稀疏表示在视频目标跟踪中的应用
- Kubernetes资源管控与Gardener开源软件实践解析
- MPI集群监控与负载平衡策略
- 自动化PHP安全漏洞检测：静态代码分析与数据流方法
- 青苔数据CEO程永：技术生态与阿里云开放创新
- 制造业转型： HyperX引领企业上云策略
- 赵维五分享：航空工业电子采购上云实战与运维策略
- 单片机控制的LED点阵显示屏设计及其实现
- 驻云科技李俊涛：AI驱动的云上服务新趋势与挑战
- 6LoWPAN物联网边界路由器：设计与实现
- 猩便利工程师仲小玉：Terraform云资源管理最佳实践与团队协作
- 类差分度改进的互信息特征选择提升文本分类性能
- VERITAS与阿里云合作的混合云转型与数据保护方案
- 云制造中的生产线仿真模型设计与虚拟化研究
- 汪洋在PostgresChina2018分享：高可用 PostgreSQL 工具与架构设计
- 2018 PostgresChina大会：阿里云时空引擎Ganos在PostgreSQL中的创新应用与多模型存储
资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！
点击此处反馈
