Finally we were able to do some tests, and we can confirm Bitdefender’s http://labs.bitdefender.com/2012/06/flame-the-story-of-leaked-data-carried-by-human-vector/ finding on USB file transfer of Flame. Again, please first read our original tech report first.

If started by rundll, Flame creates “.” file within minutes.

As the file name is very special, under windows the easiest way to check is dir /a.
Under Linux you can use the good old sleuth kit:

# fls -a ./usb1 r/d 2: . v/v 3368675: $MBR v/v 3368676:$ FAT1 v/v 3368677: $FAT2 d/d 3368678:$ OrphanFiles

But given
# istat ./usb1 2 Directory Entry: 2 Allocated File Attributes: Directory Size: 1024 Name:


Directory Entry Times:

Written:        Thu Jan  1 01:00:00 1970

Accessed:       Thu Jan  1 01:00:00 1970

Created:        Thu Jan  1 01:00:00 1970

Sectors: 1680 1681

So if not file 2, then maybe 3, 4?

It’s surely not what we are looking for.

istat ./usb1 4 Directory Entry: 4 Allocated File Attributes: File, Hidden, System, Archive Size: 172032 Name: HUB001.DAT


Directory Entry Times:

Written:        Tue Jun 12 22:13:50 2012

Accessed:       Tue Jun 12 00:00:00 2012

Created:        Thu Jan  1 01:00:00 1970

Sectors: 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017
Remember the size from the dir command?

HUB001.DAT? :

00d2020: 4855 4230 3031 2020 4441 5426 0000 0000 HUB001 DAT&.... 00d2030: 0000 cc40 0000 b9b1 cc40 0300 00a0 0200 ...@.....@......

Yes. But even ifind could cheat us:

ifind -a -n "HUB001.DAT" ./usb1 2

But fsstat shows the 336 sectors (of standard 512 bytes) we are looking for:


FAT CONTENTS (in sectors)

1680-1681 (2) -> EOF 1682-2017 (336) -> EOF

So Let’s do:

icat-sleuthkit ./usb1 4 >hub001.dat

Great
-rw-r--r-- 1 root root 172032 Jun 12 22:53 hub001.dat

xxd hub001.dat |less 0000000: 217a 30e6 280c b557 da53 ce11 28b5 60ea !z0.(..W.S..(.`. 0000010: 07ea 8282 ea2e b5b5 eaea eabb eaea eaea ................

Ok, It’s encrypted. Get the skywiper techrep for reference! It’s like Figure 24 on Encryption E1.

After decryption:
0000000000: 53 51 4C 69 74 65 20 66 │ 6F 72 6D 61 74 20 33 00 SQLite format 3 0000000010: 10 00 01 01 00 40 20 20 │ 00 00 00 38 00 00 00 00 ► ☺☺ @ 8 0000000020: 00 00 00 00 00 00 00 00 │ 00 00 00 0D 00 00 00 03 ♪ ♥ 0000000030: 00 00 00 00 00 00 00 0E │ 00 00 00 01 00 00 00 00 ♫ ☺ 0000000040: 00 00 00 00 00 00 00 00 │ 00 00 00 00 00 00 00 00

Seems ok, confirmed. Thanks again for Bitdefender for the great job.